推理力度预算编制：当思维 Token 成为财务账单的独立细目

当你的财务团队第一次问，为什么单个用户在回答一个价值 0.1 美分的问题时产生了两美分的账单，那个电话讨论的不会是模型，而是发票上那行十二个月前还不存在的项目：推理 Token (reasoning tokens)。在账单上它们看起来像输出 Token，在大多数服务商那里也按输出 Token 的费率计费，而且它们没有天然的上限。一个在非推理模型上只需产生 400 个 Token 回复的查询，可能会悄无声息地消耗 8,000 个内部思考 Token 才能得出答案——唯一注意到这一点的人是核对支出的人。

在 API 时代的大部分时间里，“使用的 Token 数”是一个诚实的数字。你输入提示词，得到响应，账单是两者的清晰函数。推理模型打破了这种直觉。模型现在在发出调用者将阅读的答案之前，会生成一个隐藏的、可计费的、仅内部可见的思维链，而该链的大小取决于模型自身对问题难度的评估。用户可见的输出可能只有一句话，而账单可能长达十页。

这种错位使得“这个查询是否应该思考”成为了新的成本控制界面。一年前，针对每个任务的决策是关于质量的——这个提示词是否需要更聪明的模型。今天，它还关乎支出、延迟以及财务部门会提出尖锐问题的预算空间。那些将思考视为免费升级的团队，其月度发票会在一个季度内翻倍且没有明显原因；而那些将其视为具有测量产出曲线的旋钮的团队，其 CFO 就不再打电话催问了。

推理 Token 不是输出 Token，即使它们按此计费

这里的底层逻辑比看起来更重要。Anthropic 在 Claude 上的扩展思考、OpenAI 的推理模型以及大多数第三方推理 API，都按输出 Token 的费率对模型的内部推理轨迹计费。轨迹本身并不返回给调用者——只返回摘要，或者什么都不返回——但它计入 max_tokens 并计入账单。一个包含 500 个可见 Token 的答案在计入思考后，总计可达 2,000 到 3,000 个计费 Token；长篇分析通常会达到 8,000 到 16,000 个。从业者报告称，在代码审查等常规工作负载中，成本开销高达 4 到 5 倍。

如果你设置了上限，它可能也不在你预期的地方。在 Claude 上，budget_tokens 是思考的软目标，而 max_tokens 是思考加文本总和的硬上限。两者会相互作用。如果 max_tokens 设置得太低，模型会烧掉思考预算，导致没有空间留给用户实际阅读的答案。如果激进地设置 budget_tokens，你限制了支出，但也限制了模型在推理中途从死胡同中恢复的能力。默认设置并非“不思考”。在像较新的 Opus 层级这样仅支持自适应思考的模型上，你无法通过传递旧的启用思考格式来退出——它会返回 400 错误。思考是底线，而不是上限。

这是财务部门不喜欢的点：账单具有一种旧账单所不具备的非确定性。同样的提示词运行两次，思考时长可能大不相同。上周思考了 2,000 个 Token 的提示词，这周可能会思考 12,000 个，因为模型内部对“这很难”的启发式判断随着例行更新而发生了变化。你的单位经济效益现在取决于一个你无法完全控制的数字，你的仪表盘必须将其作为独立项展示，否则你将察觉不到它的波动。

思考产出比是你可能还没有的评估指标

基准测试的问题已经改变。“启用了思考的新模型得分是否更高”是一个错误的框架。正确的框架是“思考产出比” (thinking yield) ——即每个推理 Token 带来的质量提升，而非绝对意义上的质量提升。如果没有这个指标，你就无法区分两种截然不同的情况：在困难任务上能回本的思考，以及为 1% 的准确度提升而增加 30 秒延迟和 8 倍支出的思考。

研究界已经意识到了这一点。最近关于推理效率的研究一致表明，大多数推理模型都处于效率前沿之下——它们的推理 Token 产生的质量收益不成比例，而且它们通过在那些不使用任何思维链也能正确解决的问题上燃烧 Token，从而过度思考简单的问题。推理模型的 Token 经济有其自身的缩放法则，而大多数生产部署都在不知不觉中运行在曲线的平坦部分。

构建这种评估在原理上很简单。对于每一类任务——提取、分类、摘要、多步推理、代码修复——在一组代表性样本中测量两个数字：开启思考时的准确率（在一个或多个预算级别下），以及达到该准确率的中位推理 Token 数。减去不思考的基准值。每准确率点的成本增益就是你的产出比。产出比为负或接近于零的任务应默认不思考，或者完全路由到非推理模型。具有高产出比的任务应允许思考，甚至可能使用最高层级。

这暴露了一个令人不安的事实：相当大比例的 Agent 步骤——工具参数验证、简单的 JSON 提取、“该字符串是否包含 X”——意外触发了推理，产生了比非推理模型多三到七倍的 Token，却得出了完全相同的答案。那些统一将 Agent 轨迹传递给推理模型的工具，实际上在每一步都在悄悄资助这种开销。

路由是你可能尚未尝试的最廉价的优化方案

投资回报率（ROI）最高的单一架构模式是一个在调用推理模型之前，先决定是否值得进行深思熟虑的路由器。一个小型、快速的分类器——甚至是微型模型前端的一个正则表达式和规则层——可以根据预测的难度为传入的查询打上标签，只有高难度的分支才会路由到昂贵的推理模型。研究界已经证明，路由可以在大约三分之二的推理计算量下达到大型模型的准确度，而且这还是使用现成的分类器；带有特定领域信号的生产部署通常表现得更好。

在各个团队中表现一致的模式大致如下。一个典型的企业分布是：大约 70% 的查询分发给预算较低的非推理模型，20% 分发给带轻度思考的中级模型，10% 分发给最重的推理模型。具体的数字因领域而异，但形态是一致的：平庸查询的长尾永远不应该接触推理模型，只有少数流量值得消耗完整的思考预算。跳过路由器并将所有请求发送给最强大的推理模型，相当于使用一个 200 兆瓦的数据中心来渲染一个 CSV 文件。

分类器本身不需要很复杂。基于长度的启发式方法、首个 Token 的意图检测以及简单的难度回归器就能捕捉到大部分简单的优化机会。难点不在于模型，而在于真正将路由器接在推理模型之前的自律性，并抵制为了“重要”请求而绕过它的诱惑，否则路由器会在一个季度内退化为形同虚设。

预算上限既是技术控制，也是组织控制

budget_tokens 上限就是刹车。如果没有它，模型就没有动力——且在架构上越来越没有倾向性——去短路其自身的思考过程。主要提供商的最低限额是 1,024；最高限额则是你对单个失控请求所能承受的最大损失。设置得太高，一个格式错误的提示词或对抗性输入就可能在单次调用中消耗掉 20 美元的计算费用。设置得太低，你最难的查询会在思考中途被截断，产生比无推理基准更差的答案。

合理的默认设置应该是按任务而定，而不是按调用。一个处理段落长度输入的摘要端点可能永远不需要超过 2,000 个推理 Token；一个多步规划智能体可能需要 16,000 个。将预算视为数据库连接池的大小：它是一种资源形态，你需要根据工作负载进行调整，并在调用达到上限时发出告警，因为这通常是上游出现问题的信号——要么是提示词格式错误，要么是输入具有对抗性，或者任务确实比你预估的要难。

组织层面的控制则更为困难。如果没有预算治理规范，每个产品团队都会自行设置思考预算，而编写提示词的人往往不是看账单的人。行之有效的模式是由平台拥有的默认设置——LLM 网关根据路由的任务类别设置 budget_tokens，超过此值需要显式覆盖。覆盖操作会被记录并每月进行审查。那些在没有这一层的情况下发布产品的团队，最终会在 30 个端点上产生 30 种不同的预算选择，其中一半是由当时处理延迟投诉的值班人员随意设置的。

FinOps 集成：推理 Token 需要专属仪表盘

如果在你的仪表盘中，推理 Token 的支出被聚合到“输出 Token”中，你将无法发现模型正在为了一个廉价问题进行过度思考并产出昂贵答案的情况。这种聚合恰恰隐藏了你最需要暴露的失效模式。解决方案平淡无奇：独立的计数器、独立的告警、独立且细化到租户的归因。

推理工作负载的最小可行 FinOps 技术栈包含四个部分。首先，记录输入 Token、可见输出 Token、作为独立字段的推理 Token，以及模型和预算配置的单次请求日志。其次，归因元数据——用户、团队、功能、路由——以便你可以通过比“API”更有意义的维度来细分支出。第三，实时仪表盘，将推理 Token 支出作为一个独立面板，而不是埋没在输出中。第四，针对每个用户、每个功能和每个路由的推理 Token 速率设置阈值告警，因为账单从不会均匀地爆炸——它总是在周五发布的单个功能上爆炸。

隐私和存储方面的影响不容忽视。记录完整推理模式元数据的单次请求日志比旧的“只记录输入和输出”的方法更重，而且在提供商暴露推理轨迹（thinking traces）的情况下，这些轨迹本身可能会泄露有关你的提示词和数据的信号。大多数团队应该记录 Token 计数和配置，而不存储原始推理轨迹，并对其余数据应用常规的保留规范。

这个仪表盘能捕捉到而通用 LLM 成本仪表盘无法捕捉到的东西是“思考产出漂移”（thinking-yield drift）：即上周同样的任务提示词消耗了 2,000 个推理 Token，这周却消耗了 6,000 个，而准确度却没有变化。这是一个模型更新信号、提示词退化或流量偏移信号——但在没有将推理 Token 作为独立条目列出的情况下，它是不可见的，因为输出 Token 的绝对支出可能不会有明显变动，直到累积漂移在一个季度后显现出来。

“思考是免费的”让你付出的代价

默认的心智模型——“思考只会让模型变得更好，为所有重要的事情都开启它”——是当前 LLM 技术栈中最昂贵的默认设置。这种做法影响最严重的往往是那些看起来无害的情况：一个启用了思考功能的 JSON 提取端点，只因最初的 Prompt 设计师觉得这可能有帮助；一个在说出“我会为你连接人工”之前先思考了 12,000 个 token 的客服代理；或者是一个文档解析流水线，其中的推理模型陷入了啰嗦地列举其解析的每个条款结构的困境。这些在产品指标中都不会表现为明显的问题，但最终都会变成财务部门会追问的账目细项。

需要培养的准则不是“停止思考”，而是将推理开销（reasoning effort）视为一种可调优的资源——通过产出率来衡量，受预算约束，按难度进行路由分发，并在仪表盘上作为独立的条目进行汇报。拥有这种准则的团队，在需要推理的查询中获得了推理模型带来的质量优势，而在不需要的查询中保持了非推理模型的成本构成。而没有这种准则的团队，会让他们的财务团队以一种痛苦的方式学会“token”这个词。

这种做法的前瞻性版本非常直接：随着模型在推理层面持续专业化——自适应思考、独立计费的推理费率、结构化推理摘要——单项任务的核算只会变得更加细粒度。那些在 2026 年建立了思考产出评估和按路由分配预算的团队，其单位经济效益在 2027 年依然能算得过来。而那些在每个端点都按默认预算上线的团队，将不得不花费一整年的时间，仓促地为那些已经将错误逻辑固化在错误层级的系统补救治理方案。