Pixels for Programs? A Cross-Provider Case Study of Input-Token Accounting for Source Code as Text and Images

技术摘要：像素换程序？关于源代码作为文本与图像输入的 Token 计费跨厂商案例研究

问题陈述
长源代码上下文往往会超过语言模型的 Token 限制，这促使人们提出将代码渲染为图像以供视觉语言模型（VLM）使用的方案。虽然近期的研究调查了模型在经过此类转换后是否仍能解决代码任务，但一个关键的系统性问题仍未得到解答：商业 API 提供商如何计算由此产生的请求？具体而言，目前尚不清楚当代码以原始文本形式传输与以紧凑渲染图像形式传输时，输入 Token 的计费方式如何变化，这种关系如何随源代码长度进行缩放，以及“视觉压缩”是否能在不同提供商和模型别名之间实现报告 Token 总数的净减少。

研究方法
本研究采用了一种可复现的黑盒测量协议，旨在比较三大主要提供商（Anthropic、OpenAI 和 Google Vertex AI）之间的输入 Token 计费情况。

• 语料库： 数据集由五个经过版本固定的源代码文件（Python、JavaScript、Rust、Go 和 Java）组成，这些文件选自著名的开源项目。这些文件被切分为九个嵌套的前缀，范围从 20 行到 2,000 行。
• 处理方式（紧凑图像）： 图像分支采用两阶段转换：
  1. 缩进压缩： 将前导空格替换为紧凑标记（例如，用 > 代替 4 空格缩进，用 ^N 代替不规则的连续空格）。
  2. 渲染： 将转换后的文本渲染为 PNG 页面。
• 实验设计： 针对每种源代码规模和语言，向 15 个可用的模型别名（4 个 Anthropic、6 个 OpenAI、5 个 Gemini）发送配对请求。两个分支均包含相同的单句总结指令（“用一句话总结这段代码的功能”）。
• 指标： 主要指标是提供商报告的图像输入 Token 数 ($I$) 与文本输入 Token 数 ($T$) 的比例。研究报告了加权聚合比例（汇总整个数据集中的所有 Token）和规模分层的比例，以确定盈亏平衡点。
• 约束条件： 本研究明确将“Token 计费”与语义保真度、任务准确性、延迟、货币成本或编程智能体效率区分开来。本文并不声称图像 Token 在计算上等同于文本 Token。

核心贡献

1. 可复现的人造物： 一个包含 1,350 次成功的 API 调用和 675 对完整的文本/图像对的数据集，包括原始使用记录、验证器和确定性分析脚本。
2. 规模分层测量： 提供了经验证据表明，Token 减少并非均匀分布；它随源代码长度和提供商的不同而显著变化。
3. 模态审计： 一项针对性的调查揭示了图像计费中的非单调行为，特别是在页面边界处。
4. 有效性边界： 明确划分了 Token 计数指标与信息保留之间的界限，防止将“更少的 Token”与“更好的性能”或“更低的成本”混为一谈。

结果

• 聚合减少量： 在整个基准测试中，紧凑图像接收到的报告输入 Token 数明显少于原始文本：
  • Anthropic: 0.135 比例（减少 86.5%）。
  • OpenAI: 0.194 比例（减少 80.6%）。
  • Gemini: 0.242 比例（减少 75.8%）。
• 盈亏平衡行为： 聚合比例掩盖了关键的差异：规模缩放表现各异。
  • Anthropic 和 OpenAI： 在所有测试规模（20 到 2,000 行）下，图像输入的 Token 计数都低于文本。
  • Gemini： 图像在短上下文中会产生巨大的开销。在 20 行时，Gemini 图像所需的 Token 数是文本的 6.95 倍。图像方法只有在 200 行之后才变得具有优势（跌破等价线）。
• 模型别名： 在同一提供商内部，许多模型别名共享相同的计费特征（例如，研究中的所有六个 OpenAI 模型返回了相同的聚合比例），这表明它们遵循的是共同的内部计费规则，而非独立的模型行为。
• 非单调性： 对 Gemini 的针对性审计显示，报告的图像 Token 数在页面边界处可能会出现非单调变化。例如，将源代码从 800 行增加到 1,200 行（增加了第二个页面）导致其中一个模型的报告图像 Token 数反而下降，这与 Token 计数应随内容线性增长的预期相悖。

意义与主张
本文主张，虽然紧凑图像渲染可以大幅减少长上下文下的报告输入 Token 数，但这种收益具有高度的条件性：

1. 提供商特异性： 不存在通用的“视觉压缩”优势。像 Gemini 这样的提供商具有高额的固定成本，使得图像在短上下文中适得其反。
2. 路由含义： 编程框架不能依赖全局策略来“将代码作为图像发送”。相反，路由逻辑必须针对每个提供商和源代码规模进行校准，或者在短上下文或页面边界引入不连续性时回退到文本模式。
3. Token 计数的局限性： 研究强调，报告 Token 数的减少并不意味着等效的信息量、更低的货币成本或更低的计算量。缩进标记可能会被误解码，且光栅化过程可能会模糊标点符号或结构。
4. 未来工作： 作者将本研究定位为一个“测量表面”，供未来的研究在其基础上构建。他们认为，下一步必要的步骤是研究表示形式与任务质量（例如，精确转录、缺陷定位）之间的交叉关系，以确定 Token 的节省是否能转化为实际的编程效用。

文章结论指出，紧凑渲染的代码在特定场景（长上下文、特定提供商）下是 Token 计费的一种可行策略，但需要精细的、针对特定提供商的校准，并需进一步验证其信息保真度。