LLM Token 用量：一个 4-token 的答案为什么要计 217 个 token

问 GPT-5.6 一道一行的数学题，输出账单里有 88% 是你永远看不到的 reasoning：可见的 token 只有 10 个，计费却是 81 个。而且 GPT-5.6 还算温和的。同一道题，GLM 5.2 上一个 4-token 的答案计了 217 个 completion token，Qwen3.7-max 上同样的答案计了 1104 个。这不是异常，reasoning 模型的计费设计本就如此。这只是几类 token 中的第一类，而大多数成本看板从来不会把它们单独拆出来。本文用一个真实的 usage 对象，逐类拆解，配上实测数字。

TL;DR

• GPT-5.6 默认设置下，一个 10-token 的答案计了 81 个 token，其中 88% 是 reasoning；GLM 5.2 是 98%，Qwen3.7-max 是 99.3%。
• Claude Sonnet 5 在一个 5-token 的答案上计了 114 个 thinking token，而请求里根本没传 thinking 参数。
• 有五个家族在不 thinking 的情况下答错了（399、400、427、466、467）；只有 GPT-5.6 不 thinking 也答对了，而所有开了 reasoning 的运行都给出了 401。
• 一次 1181-token 的 Claude 缓存写入再读取，分别花了 $0.01246 和 $0.00566，和列表价完全对得上。

我们用什么来测

本文每一项测量用的都是同一个单轮 prompt，发给各个模型时都用默认设置，除非某一行另有说明：

How many positive integers n <= 1000 are divisible by 3 or 5
but not by 15? Reply with just the number, nothing else.

正确答案是 401（3 的倍数有 333 个，加上 5 的倍数 200 个，减去被重复计的 66 个，得 467；再去掉 15 的倍数 66 个，剩下 401）。这道题是我们特意挑的：可见答案很短，在所有 tokenizer 上都固定是 3-4 个 token；正确答案唯一，所以「thinking 到底有没有用」是可验证的；难度又恰好高到让模型想去 think，而这正是我们要审查的行为。

账单上的五类 token

一次现代的 completion 请求，最多会按四种不同的费率，对五类不同的 token 计费。一个笼统的「已用 token」数字把这些全都藏了起来。

上面的字段名是 OpenAI 兼容格式。Claude 里同样是这五类，只是换了名字：input_tokens 和 output_tokens，thinking 部分放在 output_tokens_details.thinking_tokens 里，按 output 计费，缓存写入则按 TTL 进一步拆分到 cache_creation 对象里（ephemeral_5m_input_tokens 是 1.25x，ephemeral_1h_input_tokens 是 2x）。结构一样，标签不同，这个解析问题后面还会再提到。

五个类别及其价格倍率，同时标注了 OpenAI 兼容格式和 Anthropic 的字段名。88% 这个数字来自上面例子里实测的 GPT-5.6 reasoning 占比。

下面是那个笼统数字背后真正的对象，GPT-5.6 用默认设置回答测试问题时的结果：

{
  "prompt_tokens": 38,
  "completion_tokens": 81,
  "total_tokens": 119,
  "prompt_tokens_details": { "cached_tokens": 0, "cache_write_tokens": 0 },
  "completion_tokens_details": { "reasoning_tokens": 71 },
  "cost": 0.000524
}

账单的算术就藏在这里，值得完整地算一遍。你收到的答案是 completion_tokens 减去 reasoning_tokens：81 − 71 = 10 个 token，也就是「401」这个词加上它的格式。剩下的 71 个 token 是 chain-of-thought，按完整的 output 费率计费，占了 output 费用的 88%，而在 GPT-5.6 上你一个字都看不到。这篇文章里所有的「可见答案」数字都是这么算出来的。换个模型这个比例只会更夸张：GLM 5.2 回答同一个问题用了 217 个 completion token，答案却只有 4 个 token。所以一个把 completion_tokens 当成「模型说了什么」的成本模型，在这里差了 8 倍，在那里差了 54 倍。

推理就是预算，而且可以调节

同一个只有一行的问题，跑遍三个支持调节的模型家族接受的所有 thinking 设置，全部走一个 gateway，测试日期为 2026-07-13/14（每个家族内部按推理量从少到多排序；其余家族旗舰模型的默认表现见下一节）：

这张表里有四点值得认真读一读：

• 有效的时候，这个杠杆很大。 reasoning_effort: none 用 $0.000062 就答对了，只有 luna 默认成本的 1/8.5，而在更难的任务上我们测到过 GLM 5.2 上 20 倍的差距。选哪个档位也是这同一个杠杆的一部分：GPT-5.6 的旗舰模型默认不做任何推理就答对了这道题（见下一节），所以一个不需要思考的大模型，反而可能比一个需要思考的小模型更便宜。
• 无效的时候，它几乎纹丝不动。 这个旋钮能转多远，是各家族的固有特性：Sonnet 5 上是单调变化，成本相差 5 倍（84 到 249）；GPT-5.6 上变化温和且不呈单调；Qwen3.7-max 上几乎无效（low 仍然花了 974 个推理 token，而默认是 1,096）；DeepSeek V4 Pro 上完全失效（267 对 269）。
• 档位标签不单调，默认值也不确定。 这里 GPT-5.6 的 high 花的 token 比 medium 还少；我们上一篇里 GLM 的 low 花得比 high 还多；Sonnet 5 在一个完全没带 thinking 参数的请求上思考了 114 个 token；同一个 GLM 默认请求，一次跑出来花了 213 个推理 token，另一次花了 1,312 个，相差六倍。要在你自己的负载上实测这个旋钮的真实效果，别照着标签去猜。
• 又便宜又错，是反复出现的失败模式。 这里两个不思考就作答的家族都答错了（GLM 399，Sonnet 5 467）；五个家族的完整名单见下一节。推理是一笔用来保证正确性的预算，砍掉它划不划算，取决于任务本身，而不是模型。

实践中的规则：把 reasoning_tokens 当成一个头等的账单项来对待。它按 output 费率计费，规模常常远超可见的答案本身，而且它对参数的响应必须由你亲自实测。在 GPT-5.6 上还要注意，定价规则也变了；GPT-5.6 成本指南讲了 write 溢价和 cache-key 的要求。

你真的能读到自己付费买的东西吗？

「和答案分开」并不总是意味着「隐藏」，这个区别值得说清楚。我们检查的是响应体本身，而不只是 usage：

• GLM 5.2、DeepSeek、Qwen3.7-max 和 MiniMax 会返回完整的推理文本，放在答案旁边的 reasoning_content 字段里（本例中分别是 3987、1604、2509 和 581 个字符）。开发者能读到每一个计费 token；终端用户只有在你把它渲染出来时才看得到，而大多数应用并不会这么做。
• GPT-5.6 不给出原始思维链，最多只能拿到一份摘要。 响应里可以带一个由模型生成的 reasoning.summary（本例中 359 个字符），但计费的 91 个 token 是被隐藏的原始文本，而非那份摘要。最接近这段文本的是 reasoning.encrypted_content：一段加密数据，你可以在多轮对话中把它传回去以保持连贯，但永远无法解密。你付了钱的那些 token 就躺在你自己的响应体里，却读不出来。
• Claude 取决于你怎么问。 我们对开启自适应思考的 Sonnet 5 发起调用，返回了一个 thinking 块，文本为空，而 thinking_tokens 计费 114：证明它思考了，但没有内容可读。Fable 5 在其默认的常开模式下表现相同（计费 59，空块）。可同样是 Sonnet 5，如果调用时显式指定了推理预算，就会返回真正的思考文本（计费 73 个 token，文本存在）。你能看到什么，取决于你怎么问。

所以计费是普遍的，可见性不是：每个模型家族都按 output 费率对推理收费，而你能不能审计买到的文本，则从「完整可见」到「仅摘要」再到「一个签名的空块」不等。

只要文本真的返回了，你就能机械地给它打分。我们的问题有五个固定的中间结果（333、200、66、467、401），返回的每一段推理文本都包含了全部五个：GLM 5.2、DeepSeek V4 Pro、Qwen3.7-max、Kimi K2.7 Code 和 MiniMax M3 各自给出了完整的推导，而 low-effort 版本每个都漏掉了一步。对于需要过程而不只是答案的人来说，分界就在这里：有了 reasoning_content，你能验证自己付了什么钱；只有摘要或空块时，你只能选择相信。Invisible Tokens, Visible Bills 把这种问责缺口做了形式化，而 PALACE 则尝试从外部估算被隐藏的推理量。

各家族最强模型面对同一个问题

前面的调优表格用具体的档位来展示各个旋钮。这里换成各家族最新的旗舰模型，用默认配置回答同一个问题：

每个旗舰模型针对同一问题的计费输出 token 数（橙色斜纹 = 推理占比；绿色 = 可见答案）。MiniMax 上的星号表示：其用量不含推理计数，因此该占比通过相减重建，并根据它返回的推理文本进行验证。GPT-5.6 sol 上的对勾标记了唯一正确的零推理运行；Gemini 3.5 Flash 上的叉号标记了唯一错误的旗舰答案（466）。

一张图里囊括了所有的上报方式：

• 八个旗舰里有七个答对了，但对于同一个 401，价格天差地别。 Qwen3.7-max 花了 1,096 个 reasoning token、22 秒、$0.0084；GPT-5.6 的旗舰花了零个 reasoning token、$0.00031。同一个正确答案，成本相差 27 倍，延迟相差 7 倍，这就是把 reasoning 预算摆到了明面上。
• MiniMax 返回了 reasoning 文本，但没有计数。 260 个 completion token 对应一个 3 token 的可见答案：reasoning_content 里带着完整的推导过程，可 completion_tokens_details 里却没有 reasoning 这一项。缺少计数时，用减法还原：completion 减去可见 token，就是隐藏输出的数量。
• Gemini 3.5 Flash 是异类：唯一一个答错的旗舰（466），只有 3 个 completion token，任何地方都没有 reasoning 计数。它的同门 2.5 Flash 曾经花了 12.5 秒产出一个 3 token 的 401，账单里却没有任何东西说明原因，重跑一次答案变成了 427。
• 答错的都出现在较小的档位和关闭思考的情况下。 关闭思考的 GLM 答了 399；关闭思考的 Sonnet 5 答了 467；更老的 qwen3-max 完全没有思考（3 个 token），答了 400；没有 reasoning 通道的 Kimi K2.5 用 144 个可见的计费 token 把推理写了出来，在自己的正文里推导出了 401，最后却得出 400 的结论。五个家族，五个不同的错误答案：399、400、427、466、467；只有 GPT-5.6 在不 reasoning 的情况下答对了。

缓存 token：两个方向，价差 12 倍

prompt caching 把输入又拆成两类，而两者之间的价差正是这种拆分存在的理由：在 Claude 上，写入按输入价的 1.25 倍计费（1 小时 TTL 则是 2 倍），读取按 0.1 倍计费。我们实测了一对 Opus 4.8 调用，system prompt 缓存 1181 个 token，第一次调用（写入）花了 $0.01246，第二次（读取）花了 $0.00566，两者对照 list price 都能精确到小数点后第六位，输入侧的费用在两次调用之间降到了约 1/11。这篇文章要说的重点在账务本身：如果你把 cache_creation_input_tokens 和 cache_read_input_tokens 都算进「input tokens」，那你既无法核实这笔折扣，也发现不了折扣在什么时候悄悄失效。而它失效的频率比文档说的要高：我们的缓存实测发现实际生效的阈值比文档里的最低值高出 1.4 到 2.4 倍，prompt caching 指南则详细讲了各家 provider 的具体机制。

为什么你本地估算的数字永远对不上账单

常见做法是在客户端用 tokenizer 库估算成本，之后再对账。数字对不上有三个原因：

• 各家的 tokenizer 不一样。 用 OpenAI 的 tokenizer 去数发给 Claude 的文本，等于拿错了尺子；同一段字符串在每个模型家族里切出来的 token 数都不同。
• 计费范围比你的消息大。 system prompt 和 tool schema 在每次携带它们的请求里都算 input token，而本地估算时很容易漏掉。
• 推理开销在拿到响应前无法预测。 没有任何客户端计数能预测模型会花掉多少 thinking token，你只能从返回的 usage 里得知。

返回的 usage 对象就是上游自己的计费记录，所以最省事又准确的计数方式，就是别再估算，直接读它。麻烦在于每家 provider 给出的格式都不一样：光是缓存 token，根据模型家族的不同就可能叫 cached_tokens、prompt_cache_hit_tokens、total_cached_tokens 或 cache_read_input_tokens。

detail 对象也不是固定 schema。OpenAI 的参考文档在 completion 侧列了四个字段：reasoning_tokens、audio_tokens，以及 Predicted Outputs 的一对 accepted_prediction_tokens / rejected_prediction_tokens；被拒绝的预测 token 从不出现在输出里，却仍按 completion token 计费。在 prompt 侧，同样的结构在 cached_tokens 旁边又加了 text_tokens、audio_tokens 和 image_tokens；GPT-5.6 增加了 cache_write_tokens，我们还在实际中见过 video_tokens。各家厂商随意扩展：Kimi K2.7 返回过一个文档里没有的 completion_tokens_details.text_tokens，Gemini 则用自己的字段名单独统计 thinking 和 tool-use token。解析时要防御性一点：把未知的 detail 字段当作意料之中，也别假设某个字段缺失就等于零。

这正是 gateway 体现价值的地方：Synthorai 把这些全部归一成一个对象，在 OpenAI、Anthropic、Gemini 以及各开源权重家族之间，都会填好 reasoning_tokens 和两个缓存方向的字段，这样一套解析器就能覆盖你路由到的每一个模型。

从「看得见」到「停得住」

看账单只是完成了一半的工作，另一半是让超支根本不可能发生，而不只是事后能看到。月底的仪表盘等于是在钱花光之后才通知你出了意外，而卡在重试循环里的 agent 根本不会去看仪表盘。在网关上，每个 key 都带有 quota，会跟踪 used_quota 和 RPM 上限，并在请求时强制执行：预算用尽的 key 会在下一次请求时直接返回明确的报错，而不是三周后给你寄来一张更大的账单。每次请求的归因（哪个 key、哪个模型、BYOK 还是平台计费）会在同一个响应信封里返回，所以按功能算成本只是一次 group-by，而不是一个需要重新拼凑的工程。

从这些度量得出的操作顺序是：优化任何东西之前先读 reasoning_tokens 和 cache 相关字段，按任务设置 reasoning 档位，并给每个失败模式是死循环的 key 都加上硬性 quota。想知道特定的模型组合和 token 类别在你的量级下要花多少钱，用成本优化器按上面同样的按 token 费率算一遍即可。

← 返回博客