Opus 4.7 新分词器实测：实际成本上涨 12–27%
Opus 4.7's New Tokenizer: What It Actually Costs
OpenRouter 基于超一百万条请求，对比从 Opus 4.6 切换到 4.7 的用户群，发现 Opus 4.7 的新分词器使原生 token 数增加 32–45%，实际成本上涨 12–27%。
基于超百万请求的切换用户对照数据，量化了新分词器对实际账单的影响，并拆出缓存吸收这一关键变量。
Anthropic 宣布，Claude Opus 4.7 通过新的分词器提升了模型对输入的理解能力。这意味着，尽管模型价格未变（输入 $5/百万 token，输出 $25/百万 token），但相同的输入将比之前的模型花费更多。他们披露，根据内容类型的不同，膨胀幅度在 1.0–1.35 倍之间。在 OpenRouter 上，Opus 的使用严重偏向编程和技术领域，其中代理式编码工作流占据了 token 消耗量的大部分。
我们想知道：这在实践中究竟是什么样的？真实用户看到了什么？我们研究了从 Opus 4.6 转向 4.7 的使用情况，比较了两种模型的使用模式。
我们发现成本增加了 12–27%，但短提示词例外，其成本效率实际上有所提高。
我们使用自己的分词器来获得可比较的基线
OpenRouter 为每个请求记录两种 token 计数：
- OpenRouter tokens：我们自有的统一分词器，名为“QuadChars”，这是一种轻量级、与模型无关的字符计数方法，将每 4 个可打印 ASCII 字符归为一个 token，同时将每个非 ASCII 字符（例如 Unicode、emoji）计为单独的 token
- 原生 tokens：提供商报告的计数，使用模型实际的分词器
当提供商更改其分词器时，原生计数会发生变化，而我们的计数保持不变。两者之间的比率将分词器变化与提示词内容的任何差异隔离开来。
我们确定了在 Opus 4.7 发布前按请求数计算其首选模型为 Opus 4.6、随后将首选模型切换为 Opus 4.7 的用户。这个“切换者群体”为我们提供了同一用户群在不同模型版本之间的受控前后对比。
Opus 4.7 生成的原生 token 多出 32–45%
我们计算了每个模型的原生 token 与 OpenRouter 提示词 token 比率的中位数，并按提示词大小分桶（使用 OpenRouter tokens 作为一致基线）：
| 提示词大小 | Opus 4.6 比率 | Opus 4.7 比率 | 分词器膨胀 |
|---|---|---|---|
| < 2K tokens | ~1.11x | ~1.62x | ~45% |
| 2K – 10K | ~1.00x | ~1.41x | ~42% |
| 10K – 25K | ~1.14x | ~1.52x | ~34% |
| 25K – 50K | ~1.19x | ~1.58x | ~32% |
| 50K – 128K | ~1.25x | ~1.65x | ~32% |
| 128K+ | ~1.30x | ~1.73x | ~33% |
对于生产规模的提示词（10K+ tokens），在等效文本下，4.7 分词器生成的原生 token 比 4.6 多 32–34%。较小的提示词膨胀率更高，达到 42–45%。我们不仅在提示词上，在补全 token 上也观察到了相同的分词器膨胀。
为什么大多数分桶的绝对比率都高于 1.0？OpenRouter 的分词器通常比 Anthropic 的原生分词器生成更少的 token，因此即使是 Opus 4.6，其比率也接近或高于 1。重要的是版本之间的变化，这归因于新的分词器。
注意：这些膨胀百分比衡量的是原生 token 与 OpenRouter 比率的变化，而非在相同文本上直接比较分词器。作为参考，Simon Willison 独立测量了使用 Anthropic 分词器时系统提示词约 1.46 倍的膨胀。
缓存吸收了大部分 token 膨胀
分词器生成的原生 token 多出 32–45%。然而，提示词缓存吸收了很大一部分膨胀（缓存 token 按 90% 折扣计费），因此进入缓存的额外 token 对成本的影响极小。
| 提示词大小 | 平均 Δ 原生 tokens | 平均 Δ 缓存 | 平均 Δ 未缓存 | 缓存吸收百分比 |
|---|---|---|---|---|
| < 2K tokens | +266 | -149 | +415 | —* |
| 2K – 10K | +2,768 | +1,561 | +1,207 | 56% |
| 10K – 25K | +6,445 | +577 | +5,868 | 9% |
| 25K – 50K | +13,695 | +8,800 | +4,896 | 64% |
| 50K – 128K | +26,304 | +20,257 | +6,046 | 77% |
| 128K+ | +108,559 | +100,410 | +8,149 | 93% |
*在 < 2K 分桶中缓存率极低，不到 10% 的请求命中缓存，导致负增量。
对于超过 25K 的提示词，新分词器产生的额外 token 大部分被缓存捕获。在最长的提示词（128K+）中，93% 的额外 token 落入缓存。
Opus 4.7 的补全长度因提示词大小而异
使用 OpenRouter 一致的 token 计数，我们还测量了不同模型之间补全长度的变化：
| 提示词大小 | 补全中位数（4.6） | 补全中位数（4.7） | 变化 |
|---|---|---|---|
| < 2K tokens | 302 | 114 | -62% |
| 2K – 10K | 338 | 351 | +4% |
| 10K – 25K | 191 | 248 | +30% |
| 25K – 50K | 119 | 135 | +13% |
| 50K – 128K | 108 | 129 | +19% |
| 128K+ | 113 | 142 | +26% |
Opus 4.7 在短提示词下明显更简洁，对于 2K 以下的简单查询生成的 token 减少了 62%。对于较长的上下文提示词（10K+），它生成的回复略长，中位数 token 数增加了 13–30%。
实际成本影响
使用切换用户群中超过一百万次请求的计费成本，我们计算了每百万 OpenRouter token 的平均成本。这消除了提示词长度的影响，从而可以直接比较成本效率。
| 提示词大小 | 平均 $/M OR Tokens（4.6） | 平均 $/M OR Tokens（4.7） | 变化 |
|---|---|---|---|
| < 2K tokens | $14.60 | $14.37 | -1.6% |
| 2K – 10K | $6.65 | $8.46 | +27.2% |
| 10K – 25K | $3.82 | $4.78 | +25.2% |
| 25K – 50K | $2.25 | $2.73 | +21.3% |
| 50K – 128K | $1.66 | $1.86 | +11.9% |
| 128K+ | $1.29 | $1.49 | +15.3% |
每个因素对最终成本的影响各不相同。以下是分词器膨胀、缓存吸收和补全长度变化如何共同作用：
| 提示词大小 | 分词器膨胀 | 缓存吸收 | 补全 Δ | 净成本 Δ |
|---|---|---|---|---|
| < 2K tokens | +45% | — | -62% | -1.6% |
| 2K – 10K | +42% | 56% | +4% | +27.2% |
| 10K – 25K | +34% | 9% | +30% | +25.2% |
| 25K – 50K | +32% | 64% | +13% | +21.3% |
| 50K – 128K | +32% | 77% | +19% | +11.9% |
| 128K+ | +33% | 93% | +26% | +15.3% |
我们对真实 Opus 4.7 使用情况的研究表明，在考虑缓存吸收后，对于超过 2K token 的提示词，实际成本增加了 12–27%。2K 以下的短提示词是例外，显著更短的补全完全抵消了分词器的开销。
方法论
- 来源：OpenRouter 的请求日志
- 用户群：按请求数计算，顶级模型为 Opus 4.6，随后切换为 Opus 4.7 作为其顶级模型的用户。
- 样本量：超过一百万次请求，分布在 4.6 和 4.7 之间，纯文本、未取消
- 归一化：OpenRouter 独立于 Anthropic 原生计数来统计 token。原生计数与 OR token 计数之间的比率隔离了分词器的变化。
- 成本指标：每百万 OpenRouter token 的平均成本，按 OR 提示词 token 数分桶。除以 OR token 数可消除不同模型版本之间提示词长度的差异。
- 控制项：排除了媒体（图像、文件、音频、视频）、已取消的请求和零 token 请求
- 输出分词器膨胀数据也可能反映每个模型版本组织其回复方式的差异，因为不同的措辞或格式可能会独立于分词器本身而改变原生与 OpenRouter 的 token 比率。
来源：OpenRouter Blog · openrouter.ai