williamliu.ai
EN中文
← 返回文章

Opus 4.7 的输入 token 比 GPT-5.5 多 58%

一组相同测试样例的受控对比显示，Opus 4.7 使用了更多输入 token；输入计数、输出效率和任务质量需要分别衡量。

6 分钟读完
  • token 成本
  • 模型基准测试

要点

  • 在相同测试样例上，Opus 4.7 的输入 token 比 GPT-5.5 多约 58–59%。

  • 我在上一篇关于 Opus 4.7 的文章中问过：Opus 的质量是否值得多花这些 token 成本？

  • 现在的公开比较显示，GPT-5.5 的质量与 Opus 4.7 大体相当。

  • 这让取舍变得具体：Opus 存在明显的输入 token 额外开销。

  • 当质量相当时，OpenAI 在输入效率上的优势就很难忽略了。

  • 本文聚焦输入 token 的计数；输出 token 效率是另一项比较。

  • 你可以用 token-count-compare 复现这项基准测试。

🚨 大家忽略的部分

我用 21 个受控测试样例对比了 Claude Opus 4.7 与 GPT-5.5。这次对比的重点，不在于选出了哪个赢家。它证实了我在上一篇文章中提出的同一个取舍：在整套测试中，Opus 4.7 报告的输入 token 比 GPT-5.5 多约 58–59%。

关于输出 token 效率，已有其他讨论；本文有意把范围收窄，只看输入端：在模型开始生成之前，同样的任务材料会被算成多少 token。如果你想看更广泛的输出和定价分析，可以参阅 GPT 5.5 与 Claude Opus 4.7：基准测试、定价，以及真正重要的因素。

质量这个前提很重要。MindStudio 的编程对比认为，两款模型在大多数基准任务上的表现“足够接近”，没有明确的总体赢家；Mashable 的基准测试综述则指出，Opus 4.7 在高级编程和智能体编程上有优势，但 GPT-5.5 在多数基准测试中表现更好（MindStudio、Mashable）。这些已经足以支撑我的结论：质量大体相当时，输入 token 效率就成了产品决策，而不只是一个冷知识。

🛠️ 自己跑一下基准测试

我用 token-count-compare 做了这次比较。项目包含运行框架和测试样例，你可以换上自己的任务，看看它们会被算成多少 token。

📊 对比一览

  • 完整基准测试提示词总量：Opus 21,374，GPT-5.5 13,504（Opus 多 7,870 个 token，增加 58.28%）。

  • 原始文本总量：Opus 18,644，GPT-5.5 11,749（Opus 多 6,895 个 token，增加 58.69%）。

  • 普通文章样例：Opus 1,519，GPT-5.5 993（Opus 多 526 个 token，增加 52.97%）。

  • 长文样例：Opus 2,290，GPT-5.5 1,386（Opus 多 904 个 token，增加 65.22%）。

  • 代码密集的注释样例：Opus 428，GPT-5.5 240（Opus 多 188 个 token，增加 78.33%）。

  • Java 样例：Opus 1,305，GPT-5.5 802（Opus 多 503 个 token，增加 62.72%）。

这不能证明两者使用相同的分词器，也不能说明这是一次完全同条件的分词比较。但它说明了一件更实际的事：在输入端，Opus 4.7 明显更吃 token。

🔍 公开文档到底说了什么

Anthropic 的 Claude Opus 4.7 发布公告说明，这款模型采用了更新后的分词器。Simon Willison 直接测量了影响，发现一段以文本为主的系统提示词变为 1.46x，一份以文本为主的 PDF 则为 1.08x（Claude Token Counter 现在支持模型对比）。

OpenAI 的 GPT-5.5 最新模型指南讲的是另一件事。它指出，即使在相同的推理强度下，GPT-5.5 也能比先前模型用更少的推理 token取得出色结果。OpenAI 的发布文章进一步表示，GPT-5.5 完成同样的 Codex 任务时，使用的 token 显著更少，同时在真实服务中保持与 GPT-5.4 相当的单 token 延迟。

此前围绕分词器的分析，我也发表过一篇：Opus 4.7 的 token 膨胀是真的，质量上的取舍也是真的。

那篇文章问的是，Anthropic 更细粒度的分词器是否值得付出代价。这次测试让答案清晰了许多，因为在这类任务上，GPT-5.5 的质量已经相当。

关键区别就在这里：

  • Anthropic 让输入计数变得更加明确，有时也更贵。

  • OpenAI 则让任务执行更加高效。

两者有关联，却不是同一件事。

⚙️ 专家们注意到了什么

Simon Willison 的看法很务实，没有站队：如果任务定义明确，他想要一个正确答案，就倾向于 GPT-5.5；如果他想展开对话，或者做一类“更像 Claude Code 的工作”，就倾向于 Opus 4.7。

Zvi Mowshowitz 在关于 GPT-5.5 的评论中也表达了相近观点：对于“只要事实”或直接明确的请求，GPT-5.5 看起来是更好的选择；对于开放式或需要解读的工作，他仍觉得 Opus 4.7 更强。

这是我最想强调的部分：认真使用这些工具的人，并不在问“哪个品牌赢了”，而是在问“哪个模型更适合这类任务，以及完成它花了多少成本”。

🧪 这次测试如何改变了我的想法

我的基准测试套件并不是一番公开评论，而是一次受控比较，目的是看模型在同样的样例上会如何表现。结果让我不再那么关心分词器的宣传，转而更关注端到端的工作流。

如果在受控测试中，Opus 4.7 完成同样的工作需要明显更多的输入 token，那么迁移时该问的问题就变了。

不再是：“哪个模型的分词器更巧妙？”

而是：“面对我的实际工作负载，哪个模型完成任务的整体性价比最高？”

这很重要，因为提示词成本、重试成本和上下文余量都会累积影响。

一个模型的能力可以更强，但如果它让提示词消耗膨胀，对你的产品来说仍然可能更差。一个模型也可以更高效，却不一定最适合复杂、开放式的工作。

🧗 我的结论

我不认为 Anthropic 的路线是错的。

但我确实认为，OpenAI 展示了另一条可信的路线：在质量上保持竞争力，同时让输入端高效得多。因为 GPT-5.5 对这项工作而言质量相当，这就是实实在在的产品优势。

对构建产品的人来说，这才是真正的启示。

胜出的模型，不是分词器故事讲得最好听的那个，而是每花一美元、每重试一次、每用一个上下文窗口，都能完成更多有效工作的那个。

现在，我相信的是这个指标。

🧪 附录：我是怎么做实验的

我运行了 github.com/williamliu-ai/token-count-compare 项目，使用 21 个受控的合成测试样例，配置仅来自项目本地的 .env 文件。

下面的原始文本对比，仅把样例文本提交给模型提供方的 token 计数端点，没有生成请求，也没有基准测试包装内容。这样能尽量排除其他因素，在相同条件下比较计数差异。

  • 21 个样例，放在同一个平铺的 fixtures/ 文件夹中

  • Claude Opus 4.7 与 GPT-5.5 使用完全相同的输入

  • 基准测试用量验证：42 项通过 / 0 项失败 / 0 项跳过，token 容差为 ±0

  • 在相同样例上验证了提供方返回的原始文本 token 数量

相同测试样例的输入 token 计数：Opus 4.7 与 GPT-5.5 对比
fig 01 相同测试样例的输入 token 计数：Opus 4.7 与 GPT-5.5 对比

这是我最信任的部分：原始计数、相同样例、可重复运行的框架，以及任何人都能查看的代码仓库。