williamliu.ai
EN中文
← 返回文章

Opus 4.7 的 token 膨胀是真的，质量上的取舍也是真的

分词器变化会影响上下文容量、推理成本和模型表现，因此升级 Opus 4.7 需要重新衡量完整工作流程中的收益与代价。

8 分钟读完
  • token 成本
  • 语言模型

要点

  • Opus 4.7 对同一输入重新分词后，token 数可能变为约 1.0x–1.35x，从而改变成本和可用上下文。

  • 膨胀到 1.35x 时，预填充计算量约增加 82%，KV 内存约增加 35%，可容纳原始文本的有效上下文约减少 26%。

  • 不同影响仍与 API/调用方式的变化交织在一起，因此版本切换带来的干扰，可能看起来比分词器本身的影响更严重。

  • 更合适的讨论框架是质量与效率之间的取舍：更细的分词可能有利于代码密集、含噪声和多语言输入。

  • 把 Opus 4.7 当作一次推理服务系统迁移：重新调整预算、上下文压缩、输出策略和重试设置。

  • 跟踪整个会话的支出与任务结果，而不只是 token 数的增减，以免只省了 token，却损失了每美元支出换来的质量。

为什么不能用一句话解释

这周围绕 Opus 4.7 的讨论，常常带着个人情绪，但反映出的模式是一致的：

这些现象可以同时发生，因为多项改动是一起上线的。

Anthropic 关于 Opus 4.7 的文档提到了分词器变化、API/调用方式的行为更新，以及思考内容可见性和输入处理默认值的调整（新特性、迁移指南、token 计数）。当这些变化叠加，团队可能觉得只是某一个环节坏了，实际看到的却是模型层和 API 层多项变化的叠加。

发布当周的信号，究竟说明了哪些变化

把反馈分成两类，实际区别就清楚了：

**A 类：同样的文本，占用的 token 数变了。**同样的输入可能产生不同的 token 数量。本文草稿列出的范围约为 Opus 4.6 的 1.0x 到 1.35x，与发布期间的信号和实践者记录一致（Anthropic 发布说明、token 膨胀讨论）。

**B 类：集成或迁移不匹配。**默认参数行为和工具/API 兼容性发生了变化，可能破坏旧的请求模式，即使核心问题并不是 token 数量（迁移指南、GitHub 迁移问题报告、Claude Code 问题）。

如果用户只看 count_tokens，或者只单独测一个提示词，就可能漏掉全貌。完整会话的支出包括输入、输出、推理、工具调用和重试，只有把这些都算上，信号才真实（token 计数、Anthropic 定价）。

为什么分词器变化会影响整个系统

分词器不是无关紧要的预处理步骤。它定义了上下游一切操作所使用的表示单位。

如果同样的原始文本映射成更多 token，团队马上会看到三个影响：

  • **可容纳的文本量改变：**相同的上下文预算，只能容纳更少的原始字符。

  • **按 token 计费的用量增加：**即使单价不变，按 token 计量的用量也会上升。

  • **模型解析行为改变：**面对难处理的字符串，模型看到的细粒度结构不一样了。

所以，有的团队感受到“成本冲击”，有的团队感受到“质量变化”，还有的团队觉得遇到了“集成缺陷”。

序列越长，计算量增长越快

分词，是工程成本开始放大的地方。

在标准 Transformer 推理中，自注意力计算 token 两两之间的交互，因此预填充计算量与序列长度大致呈平方关系，即 O(n²)（Vaswani 等，2017）。如果分词让序列长度大致翻倍，最坏情况下，预填充计算量可能升到约 4x。

所以，一个 token 和多个 token 的差别，不只是记账方式。一段原本为 2,000 个 token 的内容，如果现在变成 4,000 个，模型甚至在开始生成输出之前，就可能花掉多得多的计算量。

你前面关于“unbelievable”的说法也是如此：一个单位是被紧凑表示，还是被拆成许多子单元，会影响计算成本花在哪里。运行时有 n 个 token，这也会改变首 token 延迟（TTFT），因为预填充高度依赖预处理，而且对延迟很敏感（ByT5、延迟深度分析）。

这就是为什么，token 带来的波动会同时表现为成本问题和延迟问题。

推理的经济账：内存与延迟

token 数会从三个方面影响推理服务成本，而不只是账单上的项目。对一些团队来说，1.35x 的 token 膨胀不是线性增加的一点麻烦，而是会叠加放大的服务开销。

  • **预填充计算开销（平方关系）：**注意力工作量约为 O(n²)。增加 82%（1.35² = 1.8225）。

  • **KV 缓存开销（线性关系）：**KV 内存大致为 O(n)。增加 35%。

  • **延迟开销（顺序解码）：**生成仍然逐 token 进行。增加 35%。

  • **吞吐量下降：**即使原始 TPS 看起来相近，这些影响也会减少每秒真正交付的有效内容。在价格竞争中，这会直接挤压利润空间。

  • **有效上下文窗口：**1/1.35 = 0.741（可容纳的原始文本约减少 26%）。

因此，如果没有系统级优化来缓解，分词器导致的 1.35x 膨胀可能显著提高推理服务成本，并降低长上下文容量。

Anthropic 为什么要这么做？

我的看法是，沿用 Opus 4.6 分词器继续提升性能，他们已经碰到了瓶颈。

字符级与子词 BPE 的取舍（CodeBPE、分词器取舍测量）

  • **字符级：**序列更长，预填充 FLOPs 更高，生成过程中的 KV 内存占用更大，TTFT/尾延迟通常也更高；但对含噪字符串和词形变化的覆盖更好。

  • **子词 BPE：**表达相同内容时，预填充 FLOPs 更低、KV 占用更小，TTFT/尾延迟更平稳；但在少见的边界模式上，可能损失表达精度。

延迟由多个环节构成，这也是调优 token 预算时需要从头到尾测量的关键原因：既看输入预填充，也看输出的流式生成。

为什么这种质量取舍可能值得

当粗粒度切分容易出错时，更细的分词可能有助于处理困难输入：

过去，团队往往推迟这种转变，因为它通常伴随可预期的代价：序列更长、计算和内存压力更大、延迟和成本更高。随着推理系统更强、缓存方式更好，以及对每美元对应的质量的优化更成熟，这种取舍在许多工作负载上变得更容易接受。

一套现实可行的迁移方案

最优秀的团队把 Opus 4.7 当成一个调优项目，而不是一次性的版本升级（分词器选择、字符分词设计）：

  1. 用真实流量重新建立 token 数量基线，而不是用合成提示词。

  2. 跟踪完整会话支出，并拆分各个组成部分。

  3. 针对新的 token 特征，收紧压缩和重试阈值。

  4. 对负载最高的工作流，重新调整最大 token 预算和推理强度设置。

  5. 以每美元对应的质量和任务完成质量判断成败，而不只看 token 数量。

这种思路能避免陷入僵局。不再围着一个症状争论，而是开始管理一项系统级变化。

结论

与其把 Opus 4.7 看作一次简单的版本升级，不如把它理解为表示层迁移。分词器变化可能增加 token 数量，降低实际的原始文本密度；与此同时，它也会改变模型行为，可能让模型在困难输入上更稳健。

应对方式不是否定这种转变，也不是为上一代模型辩护，而是把工作落到实处：仔细测量，区分分词器效应与迁移效应，再根据新情况重新调优。

参考资料

Anthropic 文档与发布材料

  1. Anthropic，《Claude Opus 4.7 新特性》。

  2. Anthropic，《迁移指南》。

  3. Anthropic，《定价》。

  4. Anthropic，《统计消息中的 token》。

  5. Anthropic，《Claude Opus 4.7 发布介绍》。

发布期间的公开信号

  1. GitHub 迁移故障报告：promptfoo 问题：以大模型为裁判的断言默认使用 temperature=0，#8175；pi-mono 问题：Claude Opus 4.7 在 Bedrock 和 Anthropic 上启用推理时失败；claude-code 问题：[BUG] Opus 4.7 的思考内容为空。

  2. GitHub Community 配额/定价讨论：对 GitHub Copilot Premium 极度失望。

  3. Reddit 关于膨胀幅度的讨论：Opus 4.7 的新分词器带来指数式放大。

分词与模型行为文献

  1. Sennrich、Haddow、Birch（2016），《使用子词单元进行罕见词的神经机器翻译》（Neural Machine Translation of Rare Words with Subword Units）。

  2. Kudo、Richardson（2018），SentencePiece。

  3. Song 等（2021），《快速 WordPiece 分词》（Fast WordPiece Tokenization）。

  4. Xue 等（2022），《通过预训练字节到字节模型迈向无 token 的未来》（Towards a Token-Free Future with Pre-trained Byte-to-Byte Models，ByT5）。

  5. Clark 等（2022），《CANINE：预训练高效的免分词编码器》（CANINE: Pre-training an Efficient Tokenization-Free Encoder）。

  6. Tay 等（2022），《Charformer：通过基于梯度的子词分词实现快速字符 Transformer》（Charformer: Fast Character Transformers via Gradient-based Subword Tokenization）。

  7. Dagan 等（2024），《在预训练和领域适配中充分发挥分词器的作用》（Getting the most out of your tokenizer for pre-training and domain adaptation）。

  8. Ali 等（2024），《大模型训练中的分词器选择：无关紧要还是至关重要？》（Tokenizer Choice for LLM Training: Negligible or Crucial?）。

  9. Petrov 等（2023），《语言模型分词器引入了语言间的不公平》（Language Model Tokenizers Introduce Unfairness Between Languages）。

  10. Limisiewicz 等（2023），《评估跨语言的词表分配与重叠》（Assessing Vocabulary Allocation and Overlap Across Languages）。

  11. Chirkova 等（2023），《CodeBPE：探索源码大模型预训练中的子词切分选项》（CodeBPE: Investigating Subtokenization Options for Large Language Model Pretraining on Source Code）。

  12. Vaswani 等（2017），《注意力就是你所需要的全部》（Attention Is All You Need）。

  13. Sean Trott，《大语言模型中的分词》（Tokenization in Large Language Models）。

  14. G. Zhou，《理解大模型响应延迟：深入分析输入与输出处理》（Understanding LLM Response Latency: A Deep Dive into Input vs Output Processing）。