别盯着 API 价格表看了，推理 Token 才是隐藏的成本陷阱

很多在做大模型选型或成本核算的同学，习惯性地把不同供应商的 Price List 摆在一起对比。看到 A 模型的每百万 Token 单价比 B 模型便宜 30%，就觉得切换过去能省下一大笔预算。但实际部署后，很多人的账单反而翻了倍，这种现象在最近流行“推理增强”的模型中极其普遍。

最核心的坑在于一个被大多数人忽略的变量：推理 Token（Reasoning Tokens）。

现在的模型趋势是引入内部思考链，模型在给出最终答案之前，会在后台进行一段冗长的逻辑推演。关键点在于，这些思考过程产生的 Token 是实打实计费的，但它们在 API 的最终返回值中往往不可见，或者被隐藏在特定的元数据字段里。这意味着你看到的“输出长度”可能只有几十个字，但后台计费的 Token 数量可能已经高达几百个。

我之前在做一次实际的成本压力测试时，遇到了一个非常极端的案例。当时对比的一个候选模型，标价确实比当前在用的方案便宜 30%，但当我们跑一次真实请求并拆解账单明细时，数据触目惊心：

• Prompt Tokens: 274
• Completion Tokens: 132
• 其中 Reasoning Tokens: 123
• 实际可见的答案 Tokens: 9

在这个请求中，用户为 132 个 Completion Tokens 付了钱，但真正能读到、能产生业务价值的答案只有 9 个 Token。如果按照这个比例折算，有效输出的实际单价竟然是标价的 14.7 倍。这种“隐形消费”让所谓的便宜模型在实际运行中贵得离谱。

除了成本失控，这种机制还会引发一个非常诡异的工程 Bug：响应截断。

在调用 API 时，我们通常会设置 max_tokens 参数来限制输出长度，防止模型由于幻觉而没完没了地输出。然而，不可见的推理 Token 同样占用这个额度。如果你的 max_tokens 设置得比较严格，模型在后台进行逻辑推演时会迅速吃掉所有配额。结果就是，模型还没来得及把最终答案吐出来，请求就被强制截断了。此时你收到的是一个空响应或者不完整的句子，很多开发者第一反应是“模型能力不行”或者“Prompt 没写好”，但实际上，这只是因为预算被内部思考过程给占满了。

针对这种情况，给正在做模型迁移或成本核算的同学一个实操建议：

千万不要迷信官网的价格表，必须通过真实请求来验证。在发送请求后，不要只看最终的文本结果，而要仔细检查响应体（Response Body）中的这个特定字段：

"completion_tokens_details": {
    "reasoning_tokens": 123
}

只有通过 总计费 Token 减去 reasoning_tokens，你才能算出该模型在你的具体业务场景下，真正有效输出的单价。如果你的供应商在响应体中不提供这个字段，那么你根本无法量化该模型的真实成本，这种不透明度本身就是一种风险。

最后，建议大家跳出“贵的一定聪明，便宜的一定笨”的线性思维。在处理简单任务时，便宜模型与顶级模型的表现分差可能只有 4%，但在处理“拒绝错误请求”这类边界 Case 时，低价模型往往会出现严重的幻觉。选型时不能只看平均分，更要看它在哪个环节会翻车。