← 返回 PaperDaily 视觉与图像

把代码转成图片发给AI，Token能省86%？Anthropic、OpenAI、Gemini 实测揭秘

把代码转成图片发给AI真的能省Token吗？这篇论文用675次真实API调用，把Anthropic、OpenAI、Gemini三家计费黑盒捅了个透。龙哥看完直呼：省钱是有套路，但踩坑也是一踩一个准，尤其Gemini的小代码场景能让你多掏6倍钱。搞编码助手的朋友，这篇不可不读。

龙哥读论文 阅读 4 查看原文
#大视觉语言模型 #多模态 #AI应用
原论文信息如下：
论文标题:
Pixels for Programs? A Cross-Provider Case Study of Input-Token Accounting for Source Code as Text and Images
发表日期: 2026年7月
发表单位: 个人研究（作者Ronak Bhalgami）
原文链接: https://arxiv.org/pdf/2607.21672v1.pdf
开源代码链接: https://github.com/ron-42/code-image-token-accounting

代码图像化能否省令牌？三大API提供商实测

近年来，随着大语言模型（LLM）能力的爆发，把代码喂给AI来辅助开发已经成了不少程序员的日常。但大家很快发现一个大问题：代码上下文动不动就几千上万行，即便是用最牛的模型，光是处理这些文本token，钱包就有点顶不住。
于是，一个脑洞大开的想法出现了：把代码渲染成图片再发给模型。毕竟现在已经有很多视觉语言模型（VLM）了，它们能理解图片内容。既然一页图片可以承载大量字符，而API报告图片token的方式又很不同，那是不是意味着，把代码转成图片能大幅削减输入的token数量呢？
这个猜想听起来很美好，但在真正掏钱之前，我们得搞清楚一个问题：那些API提供商们到底是怎么计算图片输入的token的？它们的计价规则对短代码和长代码一样友好吗？不同提供商之间又有多大差异？
这就是这篇论文要解决的核心问题。作者Ronak Bhalgami不是来推销一种新技术的，而是做了一个非常实在的测量实验：用同一份代码，分别以纯文本和紧凑渲染图片的方式发给三家主流API提供商——Anthropic（Claude系列）、OpenAI（GPT系列）和Google Vertex AI（Gemini系列），然后对比它们自己报告的input token数量。注意，这里仅测量报告的token数字，不涉及语义保真度、任务准确率、延迟或金钱成本。
实验共涉及675个完整的text/image对比对，覆盖了Python、JavaScript、Rust、Go、Java五种主流语言，以及从20行到2000行的九种代码长度。每个对比对都包含完全相同的代码前缀和任务指令，唯一的变量是输入模态（文本 vs 图片）以及图片分支中额外的缩进变换。这种配对设计确保了任何token计数的差异都可以归因于模态和表示形式的改变，而不是代码内容的不同。
下面这个是整个测量流程的示意图，简单明了。
图1：配对测量流程。文本和图像两条路径共享同一份源代码前缀和任务指令，但图像分支额外对缩进进行了变换，然后渲染为PNG页面。报告的使用量是整个管线的结果，而非仅由模态决定的因果效应。
图1：配对测量流程。文本和图像两条路径共享同一份源代码前缀和任务指令，但图像分支额外对缩进进行了变换，然后渲染为PNG页面。报告的使用量是整个管线的结果，而非仅由模态决定的因果效应。
文本请求发送的是未经改动的原始源码和一条摘要指令。图像请求则发送所有渲染好的PNG页面，以及相同的指令。图片源文件来自五个知名开源项目：CPython的asyncio/base_events.py、Lodash的JavaScript、Rust编译器表达式解析器、Go的net/http/server.go、以及Guava的LocalCache.java。每个文件的URL都固定到特定的Git提交版本，保证了实验的确定性。这种设计使得任何人在任何时间复现实验时，都能获得完全相同的源文件内容，消除了因代码版本变化带来的不确定性。
在图像处理方面，论文采用了一种称为“紧凑图像”的渲染策略。这并非简单的代码截图，而是先对缩进进行变换：每级4个空格替换为一个“>”符号，不规则的空格数替换为“^N”标记（其中N为空格数）。然后使用pxpipe-proxy工具将处理后的代码渲染为一个或多个PNG页面。这种做法的目的是最大化减少图片中的无效空白区域，从而可能降低图片的token计费（因为图片token通常与分辨率相关）。值得注意的是，这是文本和图片两种变换的组合，不能简单归因于“变成图片”这一单一因素。

75%-86%令牌缩减？背后藏有玄机

先看最吸引眼球的总体结果：
表2：各提供商加权平均的输入token比率和缩减百分比。“缩减”基于提供商报告的输入token总和计算，不代表金钱或计算量的节省。
表2：各提供商加权平均的输入token比率和缩减百分比。“缩减”基于提供商报告的输入token总和计算，不代表金钱或计算量的节省。
乍一看，这简直是开发者省钱的法宝：Anthropic (Claude) 缩减了86.5%，OpenAI (GPT) 缩减了80.6%，连最不理想的Gemini也达到75.8%。以Claude为例，这意味着如果100个文本token计费，换成图片后API只报告13.5个token，六分之一的量！
但是！龙哥提醒大家，这里到处都是坑。首先，这个数据是加权后的结果，也就是说大量长代码样本“稀释”了短代码的高昂代价。如果改用简单平均（每个provider/language/size组合同等权重），结果立刻变脸：
- 加权 vs 非加权：Anthropic 0.135 vs 0.186 - 加权 vs 非加权：OpenAI 0.194 vs 0.261 - 加权 vs 非加权：Gemini 0.242 vs 1.548（即图片反而增加了54.8%的token！）
这就很说明问题了：Gemini的图片计费存在严重的“固定成本”，短代码用图片反而多花钱。加权平均把这种负面影响给掩盖了。所以，任何一个告诉你“图片压缩能省XX%”的笼统结论，你都得多长个心眼。
此外，模型的别称也是一个大变量。论文测量了15个模型别名，但其实只有大约5种不同的计费特征：
表4：各模型别名的加权token缩减比。重复值标识了在此数据集中具有相同计费报告的模型，不意味着内部计算完全一致。
表4：各模型别名的加权token缩减比。重复值标识了在此数据集中具有相同计费报告的模型，不意味着内部计算完全一致。
比如OpenAI的所有6个模型返回的文本和图像token数目完全一样，而Anthropic的Haiku 4.5明显比其他三个模型“贵”一些。这意味着，开发者不能简单地“对Provider X使用图片策略”，还得精确到具体模型版本。论文中详细列出了每个模型别名的加权token缩减比，例如Claude Opus 4.8的比值为0.130，而Claude Haiku 4.5为0.165，两者相差约27%。这种差异虽然不如跨提供商那么大，但在大规模部署时仍然会累积成可观的成本差异。
更值得注意的是，论文发现OpenAI的所有模型（包括GPT-4o、GPT-4o-mini、GPT-4.1、GPT-4.1-mini、GPT-4.1-nano和o3）在相同输入下都报告完全相同的文本和图像token数量。这表明OpenAI可能在后端使用统一的tokenizer和图像处理管线，而不因模型能力差异而改变计费逻辑。相比之下，Anthropic的模型之间则存在明显差异，Haiku 4.5的图片token计数比Opus 4.8高出约27%，这暗示不同模型可能使用了不同的图像编码策略或分辨率阈值。

Gemini小代码反而更贵，页面边界出现反常

如果说总体数据只是有误导性，那Gemini的表现简直就是一记暴击。
论文中最精彩的图之一来了——按源代码长度分层的加权token比率图：
图2：按源代码长度分层的加权image/text input-token比率（对数坐标）。虚线为平衡线（比率=1）。Anthropic和OpenAI始终低于平衡线，而Gemini在20行处比率高达6.95，直到约200行才首次低于文本。
图2：按源代码长度分层的加权image/text input-token比率（对数坐标）。虚线为平衡线（比率=1）。Anthropic和OpenAI始终低于平衡线，而Gemini在20行处比率高达6.95，直到约200行才首次低于文本。
这张图信息量极大：
- Anthropic和OpenAI 在所有测试长度下都低于平衡线。即使只发20行代码的图片，它们的token计数也比纯文本更低。比如Anthropic在20行时比值为0.397，OpenAI为0.514，都已经开始省钱。
- Gemini 在20行代码时，图片消耗的token是文本的6.95倍！也就是说，如果你为了测试或小功能，只发了20行代码的图片给Gemini，你会被扣比纯文本多近6倍的token！
具体的缩减比表格更直观：
表3：按长度分层的加权输入token缩减比。负值意味着图片报告了比纯文本更多的token。
表3：按长度分层的加权输入token缩减比。负值意味着图片报告了比纯文本更多的token。
在20行处，Anthropic和OpenAI的缩减分别是60.3%和48.6%，而Gemini的“缩减”是惊人的-595.1%，也就是比纯文本多花近6倍。这种差异直到200行才消失，Gemini首次实现正缩减（36.6%）。从200行到2000行，Gemini的缩减比逐渐提高，在2000行时达到87.4%，与Anthropic的90.4%和OpenAI的87.8%相当。这意味着Gemini的图片计费存在一个很高的固定成本门槛，只有代码足够长时才能摊薄这个成本。
更诡异的是页面边界。 作者在RQ4（计费异常问题）中发现了一个令人费解的现象：Gemini 2.5 Flash模型在处理Python代码时，800行的单页图片被报告了2,322个image token；而当代码扩展到1,200行（变成两个页面）时，图片token反而骤降到516！当然，作为对比的Gemini 3.5 Flash从1,060正常增加到2,183。
这种非单调变化意味着，你不能简单地认为“代码越多，图片token越多”。在黑盒API背后，可能存在分页逻辑变更、分辨率阈值触发、或者后端预处理变化。这给建立可靠的成本模型又增加了一层不确定性。论文作者推测，这种异常可能与Gemini后端对单页大图片的分辨率缩放策略有关——当图片尺寸超过某个阈值时，后端可能采用不同的下采样算法，导致token计数不升反降。但具体原因只有Google内部才知道。
图3（推测）：对Gemini 2.5 Flash的针对性复查显示出非单调的页边界行为。800行时的单页PNG图像token计数显著高于1200行时双页PNG的总和。

测量设计步步为营，局限在哪一目了然

这篇论文的测量设计非常扎实，主要体现在以下几个方面：
1. 可复现性优先：所有代码、数据、脚本、校验器和分析工具都已开源。每个源文件都锚定到特定的Git提交版本，保证了任何人下载到的都是相同的内容。实验脚本还包含一个校验器，会检查重复的provider/language/model/size/mode键、未知模型、非正数文本计数等，确保数据整洁。
2. 嵌套前缀设计：每个文件都从20行开始，逐步增加到50、100、200、400、600、800、1200、2000行。由于是依次增加内容，你可以在不同长度间直观对比边界效应。这种设计使得每个长度级别的代码都是前一个级别的超集，从而消除了因代码内容不同而引入的变量。
3. 紧凑图像处理：这并不是简单地把代码截图。而是先对缩进进行变换——每级4个空格替换为一个>符号，不规则的空格数替换为^N标记。然后渲染成PNG页面。这样最大化减少了图片中的无效空白，某种意义上也减少了渲染后的像素量。论文还使用了固定的字体、字号和页宽，以确保所有图片的渲染参数一致。
4. 完善的校验体系：实验脚本会拒绝覆盖已有结果，校验器会检查重复的provider/language/model/size/mode键、未知模型、非正数文本计数等，确保数据整洁。此外，每个API调用都记录了时间戳，以便后续分析API本身的变化。
但同时，这篇论文对其局限性也毫无保留。龙哥认为这是最值得学习的地方：
- 构造效度有限：测量的是provider报告的input token数，这不等同于模型计算量、金钱成本、延迟或理解质量。不要混淆！图片token的单价通常与文本token不同，且各提供商的定价策略也不透明，因此token缩减并不直接等同于成本缩减。
- 内部效度受干扰：图像处理同时改变了模态（文本vs图片）和表示形式（缩进替换）。没有纯文本-紧凑文本+无缩进替换的对照臂，无法把效果归因于某一项。此外，缺少空白图片和纯提示基线，导致无法推断固定开销。
- 外部效度狭窄：只有5个文件（每种语言一个），不能代表所有代码风格。且没有测试minified代码、配置、测试或混合语言场景。不同编程语言的语法密度、注释比例、空行数量等都会影响token计数，但论文的样本量不足以覆盖这些差异。
- 没有任务质量评估：这是最关键的一点。就算token被大幅缩减，如果模型无法正确理解渲染后的代码，那节省的token也毫无意义。论文明确声明“不测量语义保真度、任务准确率、延迟或编码代理的效率”。这意味着所有关于“代码图片化能省钱”的讨论，都建立在“模型能准确理解图片中的代码”这一尚未验证的前提之上。
- 时间稳定性未知：所有675次调用在约24小时内完成，但API提供商的计费规则可能随时变化。论文中观察到的比率和异常现象可能只是某个时间点的快照，不具备长期有效性。

给编码工具开发者的实用建议

这篇论文虽然测量范围有限，但对于正在开发编码助手类应用的团队来说，以下几个建议非常有价值：
1. 采用条件式架构而非一刀切 不要下“所有代码都转图片”的死命令。短代码（特别是几十行）应保留文本，尤其是在Gemini场景下。长代码、只读为主的上下文可以考虑图片表示。一个合理的策略是：用图片来提供广泛的仓库上下文，但在需要精确编辑、编译错误修复、diff比对时，仍然使用文本。具体来说，对于Anthropic和OpenAI，从20行起就可以开始使用图片；对于Gemini，至少等到200行之后再尝试图片。
2. 按provider和模型进行校准 论文中的最优策略是provider特定的。对于Anthropic和OpenAI，从20行起就可以开始使用图片；对于Gemini，至少等到200行之后再尝试图片。而且，即使同一provider的不同模型（如Haiku 4.5 vs Opus 4.8）也有差异。因此，校准策略应该版本化、定期重新测试，而不是从论文里抄一个数字永久使用。建议团队建立一个自动化的测试流水线，每周或每月运行一次校准实验，以捕捉API提供商计费规则的变化。
3. 考虑更简单的替代机制 图像转换并不是唯一的token节省途径。检索（忽略不相关文件）、文本压缩（如LLMLingua、LongLLMLingua）、prompt缓存（重用共享前缀的注意力状态）等方案同样有效，而且不需要改变模态带来语义损失。图像方案只有在它与其他方案相比，能同时改善有用信息、任务质量、延迟和成本时，才是真正诱人的。例如，对于只读的代码上下文，使用检索+文本压缩可能比图像化更可靠。
4. 监测页面尺寸与分页效果 由于出现了非单调的token变化，开发者在构建流水线时，不仅要关注代码行数，还要监测实际的页面数、图像尺寸和分辨率。不要把简单的线性模型套用到计费预测上。建议在日志中记录每次请求的图片数量、每张图片的像素尺寸，以及API返回的token计数，以便后续分析异常行为。
5. 在真实任务上验证质量 在将图片策略投入生产前，务必在目标任务（如代码补全、bug定位、重构建议）上测试模型对图片代码的理解准确率。论文没有提供任何这方面的数据，因此任何关于“图片化不影响质量”的假设都是危险的。建议设计一个包含代码理解、编辑和生成任务的测试集，对比文本输入和图片输入下的模型表现。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文解决了什么问题？这篇论文提供了一个经过精心控制的测量实验，量化了将源代码渲染为紧凑图片后，三家主流API提供商（Anthropic、OpenAI、Google Vertex AI）报告的input token数量变化。它回答了什么代码长度下使用图片能省钱、什么情况下会亏钱，并且发现了图片token计数可能非单调变化的异常现象。具体来说，它给出了每个提供商、每个模型、每种代码长度下的精确token比率，为开发者制定成本优化策略提供了数据基础。

论文中的"紧凑图像"处理具体指什么？这里的"紧凑图像"不是直接把代码截图。它首先对缩进进行变换，将每4个空格替换为>标记，不规则空格数替换成^N标记。然后使用pxpipe-proxy将处理后的代码渲染为一个或多个PNG页面。这样做的目的是减少图片中的空白区域，从而可能降低图片的token计费（因为图片token通常与分辨率相关）。这是文本和图片两种变换的组合，不能简单归因于"变成图片"。论文没有单独测试“仅改变模态而不改变缩进”的效果，因此无法区分token缩减中有多少来自缩进替换、多少来自模态转换。

为什么作者要特意声明"不测量语义保真度和任务准确率"？这是为了严格限定论文结论的适用范围。读者自然会被"省86.5% token"的标题吸引，但很容易误以为"模型也能准确理解这些图片"。作者明确指出，他们只测量"API报告的数字"，这跟"模型能否正确理解代码"是两码事。类似之前的DeepSeek-OCR在中等压缩比下达到97% OCR精度，但那是专门针对OCR训练的任务，不能直接类推到商业VLM对所有代码的理解能力上。所以，在使用这项技术前，必须在自己的任务（如代码补全、bug查找、重构）上验证准确率损失。作者在论文中反复强调这一限制，正是为了避免读者过度解读实验结果。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★✰✰研究问题本身不算全新的发现（代码转图片已被多方探索），但将研究视角从"模型能不能理解"转向"API黑盒是如何计费"的，这个视角切换是新颖的。对三家主流提供商的大规模、系统化黑盒测量是一个有价值的贡献。不过，论文本质上是一份工程测量报告，缺乏方法论或理论层面的创新。

实验合理度：★★★★✰实验设计严谨，嵌套前缀设计、紧凑图像处理、可复现的脚本和校验器都做得很扎实。缺点是没有包括纯文本+紧凑缩进对照臂、缺少空白图片控制，以及675次调用分布于不同时间段，可能引入API本身变化的影响。此外，每个语言只测试了一个文件，样本代表性有限。

学术研究价值：★★★✰✰研究价值中等偏上。它为后续编码助手类应用的Token成本建模提供了宝贵的基础数据。但它更像一个工程测量报告，缺乏更深层的方法论或理论创新。不过其对"报告现象"的细致记录和对异常页边区间的发现，对方法论本身有贡献。未来研究者可以基于这些发现，设计更精细的实验来探究API计费规则的内在机制。

稳定性：★★✰✰✰低。API提供商的计费规则是黑盒，随时可能变化。今天用Claude Haiku 4.5得到的0.165比率，明天可能完全不同。而且非单调的页边界行为直接表明计费逻辑本身就不稳定。论文中观察到的异常现象（如Gemini 2.5 Flash的页边界token骤降）可能只是某个特定版本的行为，后续更新后可能消失或改变。

适应性以及泛化能力：★★✰✰✰低之又低。测试范围极其狭窄——只有5个文件（每个语言一个）、9种长度、一种渲染方式。无法推广到minified代码、不同字体/语法高亮/页宽、不包含测试或配置代码、没有混合语言场景。作者自己也明确列出了这些限制。因此，论文的结论不能直接推广到所有代码场景，只能作为特定条件下的参考。

硬件需求及成本：★★★★✰从计算成本角度，本地渲染PNG页面的开销很低（仅需一次CPU渲染），而节省的云API token费可能非常可观。但需要注意本地渲染耗时、图片传输带宽等额外成本。论文未涉及这些。此外，图片token的单价通常与文本token不同，且各提供商的定价策略也不透明，因此token缩减并不直接等同于成本缩减。

复现难度：★★★★✰论文对可复现性下了很大功夫。开源了完整代码、脚本、数据、校验器，源文件锚定到具体Git提交。唯一限制是使用商用API需要密钥和付费。对于任何有API访问权限的团队，复现门槛极低。论文还提供了详细的README文档，说明了如何配置环境、运行实验和解析结果。

产品化成熟度：★★✰✰✰极低。仅测量了token比率，完全没有触及模型对图片代码的理解质量、延迟、端到端真实成本（图片token一般不按文本token单价计费）、以及缓存行为。在产品落地前，必须自行验证这些核心指标。论文更像是提供了一个“前期调研”的数据基础，而非可直接投入生产的解决方案。

可能的问题：论文称其贡献是“测量了token节省”，但图像处理将紧凑缩进+图片模态合并为一个变量，无法分离出纯图像效果与缩进替换对token计数的影响。此外，缺少空白图片和纯提示基线，导致无法推断固定开销。本质上是工程报告而非科学实验。另一个潜在问题是，论文没有讨论API提供商的速率限制和并发控制对实验结果的影响，这些因素可能导致不同时间点的调用结果不一致。


主要参考文献

[1] Bhalgami, R. (2026). Pixels for Programs? A Cross-Provider Case Study of Input-Token Accounting for Source Code as Text and Images. arXiv:2607.21672.
[2] Cheng, J. et al. (2025). Glyph: Scaling Context Windows via Visual-Text Compression. arXiv:2510.17800.
[3] Jiang, H. et al. (2023). LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models. EMNLP.
[4] Gim, I. et al. (2023). Prompt Cache: Modular Attention Reuse for Low-Latency Inference. arXiv:2311.04934.
[5] DeepSeek-OCR (2025). A high-fidelity optical character recognition system for LLMs. DeepSeek research blog.
[6] LongCodeOCR (2025). Long-context code summarization, question answering, and completion under visual compression. arXiv.
[7] 开源代码仓库: https://github.com/ron-42/code-image-token-accounting

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～ 想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！       

end
把代码截图发给AI真的省钱吗？实测三大API各有脾气，你的代码长短决定了选用策略。
欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如 代码智能+上海+某大厂+小张），根据格式备注，可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群
进群与各路开发者一起探讨Token优化实战，别让API计费规则坑了你！
wechat_helper dianzan
转发文章 微博 X LinkedIn Facebook
龙哥读论文 · PaperDaily

本文基于龙哥读论文 PaperDaily 数据库整理，结合论文原文与工程视角进行解读。