LLM Token 用量：为什么只回答 4 个 Token，却按 217 个 Token 计费

让 GPT-5.6 回答一道一行就能写完的数学题，输出费用中有 88% 来自你永远看不到的推理：可见答案只有 10 个 token，计费却是 81 个。GPT-5.6 还算克制。同一道题，GLM 5.2 用 4 个 token 给出答案，却按 217 个 completion token 计费；Qwen3.7-max 给出相同答案，计费量更是达到 1,104 个。这不是异常，而是推理模型本来就采用的计费方式。推理 token 只是成本面板通常不会单独列出的多个 token 类别之一。本文会结合实测数据，逐类拆解一个真实的 usage 对象。

TL;DR

• GPT-5.6 默认配置用 10 个 token 给出答案，却按 81 个 token 计费，其中 88% 是推理；GLM 5.2 的占比为 98%，Qwen3.7-max 为 99.3%。
• 请求中没有发送 thinking 参数时，Claude Sonnet 5 仍为一个 5-token 答案计费了 114 个 thinking token。
• 关闭 thinking 后，有五个模型家族答错，答案分别是 399、400、427、466、467；只有 GPT-5.6 不推理也答对了，所有启用推理的运行都回答 401。
• Claude 对 1,181 个 token 先写入缓存、再读取缓存，费用分别为 $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；再排除 66 个 15 的倍数，剩下 401 个）。我们特意选择了这道题：在所有 tokenizer 下，可见答案都固定且很短，只有 3-4 个 token；答案唯一，因此可以验证“推理是否值得”；同时它又没有简单到模型完全不想推理，正适合审计这种行为。

账单中的五类 Token

一次现代模型调用最多会产生五类 token，并按四种不同费率计费。只看一个笼统的“已用 token”数字，会把这些差异全部隐藏起来。

以上字段名采用 OpenAI 兼容格式。Claude 也包含相同的五类 token，只是命名不同：输入和输出分别是 input_tokens 与 output_tokens，thinking 位于 output_tokens_details.thinking_tokens，按输出计费；缓存写入还会在 cache_creation 对象中按 TTL 进一步拆分，ephemeral_5m_input_tokens 按 1.25x 计费，ephemeral_1h_input_tokens 按 2x 计费。结构相同，字段名不同。后文还会讨论由此带来的解析问题。

五类 token 及其价格倍数，同时标出了 OpenAI 兼容格式和 Anthropic 的字段名。图中的 88% 来自上例中 GPT-5.6 的实测推理占比。

下面是标题中那次 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 是思维链，按完整输出费率计费，占输出费用的 88%，而且在 GPT-5.6 上一个都看不到。本文所有“可见答案”数据都按同样方式计算。其他模型的比例更夸张：GLM 5.2 回答同一道题时，4-token 答案对应 217 个 completion token。如果成本模型把 completion_tokens 当成“模型说出来的内容”，这里会高估 8 倍，在 GLM 5.2 上则会高估 54 倍。

推理才是预算大头，而且可以调节

我们通过同一个网关，在 2026-07-13/14 用这道一行数学题测试了三个支持调节推理的模型家族。每个家族内部按推理 token 从少到多排序；其他家族旗舰模型的默认配置见下一节：

从表中可以直接得出四个结论：

• 参数生效时，节省幅度很大。 reasoning_effort: none 只花 $0.000062 就答对了，比 luna 默认配置便宜 8.5 倍。对于更难的任务，我们在 GLM 5.2 上测到过 20 倍差距。模型档位也是同一套调节手段的一部分：GPT-5.6 的旗舰模型默认不做推理也答对了这道题（见下一节），因此不需要推理的大模型，可能比必须推理的小模型更便宜。
• 参数不生效时，几乎调不动。 旋钮的有效范围取决于模型家族：Sonnet 5 基本单调，费用从 84 个推理 token 到 249 个，相差 5 倍；GPT-5.6 变化较小，而且不按档位顺序递增；Qwen3.7-max 几乎不受影响，low 仍用了 974 个推理 token，默认配置则是 1,096 个；DeepSeek V4 Pro 基本没有变化，分别为 267 和 269 个。
• 档位标签不保证单调，默认行为也不确定。 这次测试中，GPT-5.6 的 high 比 medium 用得更少；之前的文章中，GLM 的 low 反而比 high 用得更多；Sonnet 5 在请求未发送任何 thinking 参数时仍推理了 114 个 token；完全相同的 GLM 默认请求，一次用了 213 个推理 token，另一次用了 1,312 个，相差 6 倍。必须在自己的工作负载上实测参数效果，不能根据档位名称推断。
• 便宜但答错是反复出现的问题。 这里两个关闭 thinking 的模型家族都答错了：GLM 回答 399，Sonnet 5 回答 467。下一节列出了全部五个家族的情况。推理预算也是正确率预算，是否值得削减取决于任务，而不是模型本身。

实用原则很简单：把 reasoning_tokens 当成独立的一等成本项。它按输出费率计费，经常远大于可见答案，而且会受参数影响，但实际效果必须实测。GPT-5.6 的定价规则也有变化；GPT-5.6 成本指南介绍了写入溢价和 cache key 要求。

付费购买的推理内容真的能看到吗？

“与答案分开”不一定等于隐藏，需要把两者区分清楚。我们检查了完整响应体，而不只是 usage：

• GLM 5.2、DeepSeek、Qwen3.7-max 和 MiniMax 会在答案旁边的 reasoning_content 字段中返回完整推理文本，本次测试分别为 3,987、1,604、2,509 和 581 个字符。开发者可以读取每一个计费 token；终端用户是否能看到，取决于应用是否渲染，而大多数应用都不会展示。
• GPT-5.6 不返回原始思维链，最多只提供摘要。 响应可以包含模型生成的 reasoning.summary，本次为 359 个字符，但计费的 91 个 token 对应隐藏的原始文本，而不是摘要。最接近原始文本的是 reasoning.encrypted_content：它是加密数据，可以在多轮对话中原样传回以维持上下文，但无法解密。你付费购买的 token 就在自己的响应体里，却无法读取。
• Claude 是否可见取决于调用方式。 我们调用采用自适应 thinking 的 Sonnet 5 时，响应返回了文本为空的 thinking block，但 thinking_tokens 仍计费 114 个：可以确认模型做过推理，却看不到内容。Fable 5 的默认配置始终启用 thinking，表现相同：计费 59 个 token，block 为空。但对同一个 Sonnet 5 显式设置推理预算后，响应返回了实际 thinking 文本，计费 73 个 token。调用方式决定了推理内容能否查看。

因此，所有模型家族的计费规则一致，但可见性并不一致：推理都按输出费率收费，而你对已购买内容的审计能力，可能是“全文可见”“只能看摘要”，也可能只是“拿到一个带签名的空 block”。

如果能拿到推理文本，就可以自动评估过程。测试题包含五个固定中间结果：333、200、66、467、401。所有返回的推理文本都包含这五个结果：GLM 5.2、DeepSeek V4 Pro、Qwen3.7-max、Kimi K2.7 Code 和 MiniMax M3 都给出了完整推导，低推理强度版本则各自少了一步。需要过程而不只是答案时，区别就在这里：有 reasoning_content，就能验证自己购买的内容；只有摘要或空 block，就只能相信模型。Invisible Tokens, Visible Bills形式化描述了这种问责缺口，PALACE则尝试从外部估算隐藏推理。

各模型家族旗舰的同题表现

上一张表使用特定档位展示了可调参数。下面是各家族最新旗舰模型在默认配置下回答同一道题的结果：

各旗舰模型回答同一道题时的计费输出 token（橙色斜线区域为推理占比，绿色为可见答案）。MiniMax 上的星号表示其 usage 没有推理数量，因此占比通过相减重建，并用它返回的推理文本做了验证。GPT-5.6 sol 上的对勾表示它是唯一一个不推理也答对的模型；Gemini 3.5 Flash 上的叉号表示它是唯一答错的旗舰模型，答案为 466。

一张图就覆盖了所有报告方式：

• 八个旗舰模型中有七个答对，但得到同一个 401 的成本差异极大。 Qwen3.7-max 使用了 1,096 个推理 token，耗时 22 秒，费用为 $0.0084；GPT-5.6 旗舰模型没有使用推理 token，费用为 $0.00031。同一个正确答案，成本相差 27 倍，延迟相差 7 倍，这就是推理预算的实际影响。
• MiniMax 返回推理文本，但不报告推理数量。 3-token 可见答案对应 260 个 completion token：响应在 reasoning_content 中提供了完整推导，但 completion_tokens_details 没有推理项。缺少数量时，可以用减法重建：completion token 减去可见 token，就是隐藏输出的数量。
• Gemini 3.5 Flash 是例外：它是唯一答错的旗舰模型，答案是 466；completion token 为 3，任何字段中都没有推理数量。它的同家族模型 2.5 Flash 曾用 12.5 秒生成一个 3-token 的 401，账单里完全看不出时间花在哪里；重复运行时又回答了 427。
• 错误答案主要出现在小模型档位和关闭 thinking 的配置中。 GLM 关闭 thinking 后回答 399；Sonnet 5 禁用 thinking 后回答 467；旧版 qwen3-max 完全没有推理，只用 3 个 token 回答了 400；没有推理通道的 Kimi K2.5 在可见输出中写了 144 个计费 token 的推理过程，中间推导出了 401，最后却得出 400。五个模型家族给出了五个不同的错误答案：399、400、427、466、467；只有 GPT-5.6 不推理也答对了。

缓存 Token：两个方向，价格相差 12 倍

Prompt caching 会把输入拆成另外两个类别。两者价差很大，这也是必须分开统计的原因：Claude 的缓存写入按输入费率的 1.25x 计费，1 小时 TTL 则按 2x；缓存读取按 0.1x 计费。我们实测了一组 Opus 4.8 调用，缓存 system prompt 为 1,181 个 token：第一次写入费用为 $0.01246，第二次读取为 $0.00566。两次费用都能按公开价格精确核算到小数点后六位，第二次调用的输入侧费用约降至第一次的 1/11。这里的重点是计费分类：如果把 cache_creation_input_tokens 和 cache_read_input_tokens 都归入“输入 token”，既无法验证折扣，也发现不了缓存何时悄悄失效。而实际失效频率比文档描述的更高。我们的缓存实测发现，有效阈值比文档标注的最低值高 1.4 到 2.4 倍；prompt caching 指南则详细介绍了各提供商的具体机制。

为什么本地估算永远对不上账单

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

• 各厂商使用的 tokenizer 不同。 用 OpenAI tokenizer 统计发往 Claude 的文本，相当于拿错了尺子；同一个字符串在每个模型家族中的 token 划分都不同。
• 计费内容不只包括你的消息。 只要请求中携带 system prompt 和工具 schema，它们每次都会计入输入 token，但本地估算很容易漏掉。
• 响应返回之前，推理量无法预测。 客户端无法提前知道模型会使用多少 thinking token；只能从返回的 usage 中读取实际数量。

返回的 usage 对象就是上游自己的计费记录。要准确计数，最省事的方法不是估算，而是直接读取它。问题在于每家提供商的结构都不同：仅缓存 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。被拒绝的 prediction token 不会出现在输出中，却仍按 completion token 计费。Prompt 侧则在 cached_tokens 之外加入了 text_tokens、audio_tokens 和 image_tokens，xAI 的文档也采用同样结构；GPT-5.6 还新增了 cache_write_tokens，实际响应中甚至见过 video_tokens。厂商可以自由扩展：Kimi K2.7 返回了未写入文档的 completion_tokens_details.text_tokens，Gemini 则用自己的字段名分别统计 thinking 和工具调用 token。解析时要做好兼容：未知 detail 字段是正常情况，也不要把缺失字段直接当成 0。音频字段还有自己独立的计费逻辑；我们另外对七个专用 ASR 模型的语音转文字成本做了按计费音频分钟的实测。

这正是网关能发挥价值的地方：Synthorai 将这些格式统一成一个对象，在 OpenAI、Anthropic、Gemini 和开放权重模型家族之间统一填充 reasoning_tokens 及两个缓存方向的字段，因此一套解析器就能覆盖所有路由模型。

从看见成本到阻止超支

读取账本只完成了一半。另一半是让超支无法发生，而不只是等它发生后才看见。月底面板只能在钱花完之后报告意外支出，陷入重试循环的 agent 也不会去看面板。网关上的每个 key 都有 quota，会跟踪 used_quota，同时设置 RPM 上限，并在请求时强制执行。预算耗尽后，下一个请求会收到明确错误，而不是三周后收到更高的账单。每次请求的归因信息，包括使用了哪个 key、哪个模型，以及采用 BYOK 还是平台计费，都会在同一个响应 envelope 中返回。因此，按功能统计成本只需要一次 group-by，不必事后重建。

根据这些实测结果，操作顺序应该是：优化之前先读取 reasoning_tokens 和缓存字段；按任务设置推理档位；所有可能因循环失控的 key 都设置硬性 quota。如果想计算一组具体模型和 token 类别在实际流量下的成本，可以使用成本优化器，它采用与本文相同的逐 token 费率。

← 返回博客