自适应思考与成本预测
更新于 September 1, 2026 · 首次发布 September 1, 2026
推理预算过去是你自己设定的一个数字。你传入 thinking: {type: "enabled", budget_tokens: N}，N 既是控制手段，也是预测依据：最坏情况下，每次请求都消耗 N 个推理 Token，财务只需把次数乘上去。
该参数在 Opus 4.6 和 Sonnet 4.6 上已被弃用；在最新模型上——Fable 5 和 5.1、Sonnet 5、Opus 5、4.8 和 4.7——传入它会直接返回 400。替代方案是 thinking: {type: "adaptive"}，由模型根据请求难度自行决定思考多少。
平均而言，这样每美元的输出质量更高。但它也取消了一道上限。如果你的预测是基于这道上限建立的，那么预测现在已经错了，只是要等到月底结账时才会暴露出来。
数字层面的变化
单次请求的平均成本通常会下降，因为简单请求不再为用不上的推理付费。方差会上升，因为困难请求不再被上限截断。两者走向相反，而以单次最大值表达的预算也就无处可依。
实际出问题的不是平均值，而是尾部：一次提示词修改、一种新的文档类型，或者用户开始问更难的问题，都会把一部分流量推入更深的推理，而你的配置里没有任何东西能限制它。
按分布预测，而不是按上限
三项改动，按收益大小排序。
把推理 Token 作为独立序列追踪。它们已经包含在每次响应的 usage 对象里。把它们与输入、输出分开记入遥测，就能在变化发生的当天看到，而不是等到月末。
按百分位做预算。把“每次请求 N 个 Token”替换为每条路由的 p50 和 p99。p50 告诉你工作负载的常规成本；p50 与 p99 之间的差距，则说明一个糟糕的星期会让你暴露多少。
对比例而非总量设告警。每条路由中推理 Token 占总 Token 的比例，是提示词变化让模型更费劲时最先移动的数字。总支出告警通常要等用量累积到一定程度才会触发，往往晚好几天。
上限仍应设在哪里
去掉单次请求的旋钮，并不等于取消所有限制。路由级和租户级的支出上限依然有效，依然能拦住失控的循环，护栏现在应该放在这里——放在你自己掌控的边界上，而不是放在一个已经不存在的请求参数里。对于延迟敏感、深度推理永远不值得的路径，手段应该是选模型，而不是设 Token 预算。
相关阅读
相关文章
想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 →