思考预算怎么切：推理模型的资源分配工程取舍

去年调推理模型的 API，我主要关心两件事：模型答得对不对，以及一张账单能扛多久。到了今年，几乎所有主流模型都在接口里塞进了一个跟“想多久”相关的参数，问题变成第三个：这笔预算到底该给谁、给多少。思考预算（thinking budget）听起来像个体贴的设计，实际用起来更像一个必须自己校准的旋钮，拧错方向既费钱又掉准确率。

从“能不能想”到“想多少”

推理强度可调这件事，2025 年初迅速铺开。按 IBM 的梳理，IBM Granite 3.2 在 2025 年 2 月成为首个提供可开关“思考”模式的大模型，同月 Anthropic 的 Claude 3.7 Sonnet 为 API 用户加了细粒度控制思考时长的能力，谷歌随后给 Gemini 提供思考预算调节，OpenAI 则允许对 o1、o3 设置“低、中、高”推理强度。此后这套做法基本成了行业标准。推理模型这条线本身更早：OpenAI 2024 年 9 月的 o1-preview，同年 11 月阿里 QwQ-32B-preview，12 月 Gemini 2.0 Flash Experiment，2025 年 1 月 DeepSeek-R1 开源并公开技术论文，让其他团队有了可参考的实现路径。

参数形态各家不同。有的给的是 token 上限，比如一份汇总里提到某家 API 参数最多可到 128K token；有的直接在命名上做开关，比如 Qwen3 的 /think 标签；还有的让模型自己评估查询复杂度再决定深度，Gemini 2.5 Flash 和 Claude 3.7 都被归于这一类。作为调用方，这三种形态的运维手感完全不一样。

预算和准确率不是线性关系

最容易踩的坑，是把思考预算当成“多花点钱换更准”的单调函数。实际上大量样本处在一条很平甚至想回头的曲线上：分类、信息抽取、格式化改写这类任务，给 512 token 和给 8192 token，最终答案几乎没差，多出来的部分只是把同样的结论绕了几圈。真正吃思考预算的是多步推导——代码里跨文件的调用链、数学题里的中间变量消元、长文档里需要比对多个时间点的判断。

更麻烦的是长度本身的风险。DeepSeek 在 R1-Zero 的技术报告里直接写明，纯 RL 路线遇到了无休止重复、可读性差和语言混合的问题。预算放宽，这类退化就有更多空间发生。我的做法是按任务设三档预算，而不是全局一个数：低档给路由、分类、抽取，中档给单轮问答和常规代码补全，高档只留给明确需要长链推理的入口，并且高档默认带超时和最大输出长度两个闸门。

自动评估不能完全托管

自动复杂度评估看上去省事。输入进来，模型先判断难易，再决定想多久。这套机制在生产环境的问题在于不可预测性：同一类请求的预算分布会随措辞、上下文长度漂移，压测时很难复现某条请求为什么突然想了三倍长。计费和限流都跟着 token 走，这种漂移会直接体现在账单尾部的长尾上。

更稳的工程方式是在调用方做路由，而不是把判断全交给模型。可以用小模型或者规则先打一个难度标签，再映射到预算档位；高风险入口强制走高预算并要求带推理轨迹，低风险入口干脆关掉思考模式。Granite 3.2 那种可开关设计在这种切分下最省心：绝大多数流量走快路径，只有真正需要的请求才打开。

省下来的钱去哪了

降低单价这件事，国内几家推得很快。字节跳动的 Seed-Thinking-v1.5 在 2025 年 4 月 17 日通过火山引擎开放接口，官方称单位推理成本比 DeepSeek R1 降低 50%，模型采用 MoE 架构，总参数 200B、激活参数 20B。腾讯的快思考模型混元 Turbo S 给出的定价是输入 0.8 元每百万 token、输出 2 元每百万 token，称约为 DeepSeek API 成本的一半到四分之一。这些数字说明推理成本在往下走，但用得越多，预算分配的错配被放大得越明显。单价降一半，不代表可以把所有请求的思考预算翻倍。

还有一条常被忽略的路径：与其把单个请求的思考拉长，不如在多个候选之间做选择。自一致性（多数投票）对同一提示采样多次再取高频答案；best-of-N 采样后用结果奖励模型（ORM）打分挑一个。IBM 的资料转述了卡内基梅隆大学的一个观点：采用搜索或采样类推理算法的小模型，相比传统大模型可以实现更好的性能—效率权衡。这意味着“多花算力”未必等于“单个请求想更久”，后者的延迟直接压在用户等待上，前者可以并行摊销。

延迟和预算是两个独立约束。思考预算管的是单位请求的成本上限，并行采样管的是总吞吐。混在一起调，结果往往是延迟和账单同时失控。

奖励信号决定“想得值不值”

预算分配的上限其实由训练时的奖励设计决定。结果奖励模型（ORM）只看最终答案对不对，计算效率高，但可能奖励那些过程有缺陷、答案却蒙对的推理，模型学到的就是更长的低质量思考。过程奖励模型（PRM）按步骤打分，信号更细，早期如 OpenAI 的 PRM800K 依赖大量人工标注，后续 Math-Shepherd 一类工作用“该步骤推出正确答案的概率”来自动推断步骤质量，降低了成本。DeepSeek-R1-Zero 则走更轻的路线：用 <think> 与 <answer> 的格式奖励加答案正确性奖励，不用专门奖励模型解析整条回复。

这些选择会传导到调用侧。一个用结果奖励训出来的模型，给它更多思考预算，未必换来更可靠的中间过程；需要审计推理轨迹的场景，就得把预算和可验证性一起考虑。

落到代码里的几条规矩

• 预算按任务分层，入口处打标签，不指望模型每次自己判断准。
• 任何高预算调用都要有硬超时和最大思维 token 上限，双保险，防止重复和语言混杂把请求拖死。
• 监控按预算档位拆分 p95 延迟和 token 成本，而不是看全局均值——长尾永远藏在最高档里。
• 新任务上线前跑一遍预算梯度实验，至少试三档，确认曲线到哪儿就平了。
• 对延迟敏感的交互路径，优先考虑并行采样或更小的模型，而不是把单请求的思考拉满。

思考预算这个参数本身不复杂，难的是它把“任务难度”“延迟要求”“成本结构”三件事绑到了同一个旋钮上。工程上能做的，是承认每个请求的需求不一样，然后把这个判断搬到自己可控的路由层里，而不是点一下自动模式就撒手。