推理时计算：多想一会儿到底值不值

模型能力不只由参数决定，也可以由推理时投入多少计算决定。best-of-N 并行采样、更长思维链、搜索与验证都属于测试时计算。问题在于，这些策略并非免费，也不保证每个任务都受益。

两种预算

并行采样生成多个候选，再由验证器或多数投票选择。若单次成功率为 $p$，独立采样 $N$ 次，至少一次成功的概率为：

$$1-(1-p)^N$$

串行思考让一次生成使用更多 token，尝试分解、反思和自检。它不增加候选数量，而是改变单条轨迹的长度与结构。

两者可以组合，但训练与推理成本、延迟和可观测性不同。

验证器是杠杆

若验证器准确率为 $v$，从 $N$ 个候选中选中正确答案的概率不仅取决于候选是否正确，也取决于验证器是否能识别正确项。验证器弱时，增加 $N$ 可能提高“正确答案出现在候选中”的概率，却无法把它变成最终输出。

对代码、数学和结构化任务，执行器或单元测试可以提供较强验证信号；开放式写作、战略判断和事实核查则更难自动验证。

评价成本

一个实用指标是：

$$C_{\text{success}} = \frac{\text{总推理成本}}{\text{可靠答案数}}$$

还要加上截止期。一个在 30 秒内给出 90% 可靠答案的方案，可能优于 5 分钟后给出 92% 的方案。在线系统需要把思考预算视为调度变量。

推理预算分配器 可以演示采样数、单次成功率和验证器准确率如何共同影响结果。

工程结论

先把任务分成“可自动验证”“可多数投票”“只能人工判断”三类；再为每类设置最大候选数、总 token 预算和降级路径。不要用平均准确率掩盖长尾延迟，也不要把“会思考”当作不需要评测的理由。

把“多思考”拆成预算问题

推理时计算并不是一个单一旋钮。常见策略至少包括延长思维链、并行采样、best-of-N、树搜索、验证器重排和迭代修订。它们消耗的 token 与延迟不同，依赖的失败假设也不同。若把“采样次数翻倍”直接等同于“效果更好”，就会忽略样本相关性、验证器偏差和排队成本。

在一个简化的独立同分布模型里，单次成功率是 $p$，采样 $N$ 次后至少一次成功的概率是：

$$P(\text{至少一次成功}) = 1 - (1-p)^N$$

但系统最终交给用户的不是“存在一个正确答案”，而是验证器选中的答案。若验证器准确率为 $v$，一个粗略可靠率上界是 $P \times v$。当 $p=0.25$、$N=8$ 时，至少一次正确的理论上限约 90%；若验证器只有 60% 的判别能力，实际可靠率会显著降低。验证器越弱，增加采样的收益越可能被错误选择吞掉。

更真实的模型还应加入样本相关性：同一个模型多次采样往往会重复同样的错误。可以把有效独立样本数写成 $N_{\text{eff}} \le N$，则可靠率应使用 $1-(1-p)^{N_{\text{eff}}}$。这会迫使团队先测错误是否独立，而不是只看采样次数。

成本不只是一串 token

推理预算可以写成：

$$\text{总成本} = N \times (C_{\text{sample}} + C_{\text{verify}})$$

同时，端到端延迟约等于串行采样时间加验证时间，再叠加调度与网络延迟。并行采样能用更多算力换更短墙钟时间，但会提高瞬时显存、批处理和能耗。对于在线服务，用户愿意等待的时间可能只有几秒，超过截止期的更优答案没有业务价值。

策略	主要收益	主要代价	适合场景
延长推理链	可能减少局部错误	单路径延迟高，错误会累积	可检查、步骤清晰的推理
并行采样	覆盖多解，适合 best-of-N	计算和显存成倍增长	有可靠验证器的离线任务
树搜索	在部分正确前缀上继续探索	调度复杂，容易重复状态	组合搜索和可剪枝问题
验证器重排	不改生成分布，只选答案	验证器偏差决定上限	代码、数学、结构化输出
迭代修订	可以利用失败反馈	需要可靠反馈和停止条件	有测试或编译器反馈的工程任务

什么时候模型扩展更划算

“推理时多算”与“训练一个更大模型”不是同一种投资。前者按请求持续付费，适合低频、高价值、可验证的任务；后者把成本前置到训练和部署，但每次请求的边际计算更低。一个简单判断是：任务分布是否稳定、错误是否可被自动发现、流量是否足够大。如果验证器可靠且流量低，推理预算可能划算；如果错误难以验证且请求量巨大，更大模型或更好的数据可能更经济。

这把问题从“哪种方法更强”改写成了“在目标延迟、预算和验证能力下，哪一种资源分配更合理”。论文中的比较也必须带着任务分布、模型族、训练阶段和采样参数阅读。把它们抽象成“思考越久越聪明”会丢失最关键的条件。

工程落地顺序

1. 先做验证器：没有可靠判分，采样只是在放大选择噪声。
2. 再测错误相关性：同一模型重复犯错的概率，决定有效采样数。
3. 设置硬预算：单请求最大 token、最大尝试数、截止期和降级路径。
4. 记录每次尝试：输入、候选、验证结果、耗时和最终选择。
5. 按任务分层：简单查询直接回答，高价值问题才进入多候选流程。
6. 固定评测集：每次改动采样策略后，报告质量、P95 延迟和成功成本。

推理时计算最值得保留的思想，不是“让模型想更久”，而是把测试、反思和选择显式化，并用预算约束它们。能够证明“什么时候值得多想”的系统，比单纯增加模型参数量更接近可运营的智能系统。

一个严谨的评测计划

首先固定底座模型、提示模板、采样温度、最大输出和评测集，然后只改变推理预算。至少比较四组：单次 greedy、固定预算的延长思考、best-of-N、带验证器的 best-of-N。每组报告准确率、P50/P95 延迟、token 数、成功答案成本和人工复核率。若只看准确率，系统可能用十倍成本换一个难以感知的提升；若只看成本，又会把需要多步验证的高价值任务误判为不值得。

其次要区分“答案存在”与“系统能选中”。对代码任务可以用测试和编译作为验证器，对数学任务可以用符号检查或人工抽样，对开放式问答则很难自动判定。验证器本身也要评测：假阳性会让系统自信地返回错误答案，假阴性会浪费正确候选。一个完整的推理预算方案，必须把验证器的错误率纳入预算，而不是把验证器当作真值。

最后做消融。把采样次数固定，只改验证器；把验证器固定，只改采样；再改变并行与串行调度，观察墙钟时间和资源峰值。这样可以判断收益来自更多候选、更好的选择，还是更宽松的等待时间。只有消融清楚的结论，才能迁移到另一个模型或另一类任务，而不是停留在“这个方法在我们的 demo 上有效”。

还要防止评测集泄漏。推理模型生成更长的中间步骤后，若训练或系统提示中提前出现过答案，表面上的“思考收益”可能只是记忆。使用新的题目、改动词表述并保留私有测试集，是比扩大公开 benchmark 更有效的验证方式。对于线上系统，记录模型版本、采样种子和验证器版本，才能在质量变化时知道究竟改了哪一环。

推理预算还应与上下文管理联动。长思维链会增加 token 数，也可能触发缓存、限流和上下文截断；如果截断了关键工具输出，更多思考反而会让答案偏离。工程上应优先保留任务目标、失败反馈和验证结果，丢弃重复的中间叙述。把“保留哪些上下文”当作预算的一部分，往往比单纯提高候选数更有效。

对产品团队来说，最好把推理预算显式展示成“快速回答、深入分析、验证后回答”三个服务等级，而不是一个隐藏的模型开关。每个等级对应不同费用、延迟和可靠性承诺，用户可以选择，系统也可以根据风险降级。这样“思考预算”就从后台参数变成了可解释的产品契约。

实现上，应把采样和验证分开计费与计时，避免一个慢验证器拖垮整个服务。验证超时可以退回候选中最高置信度答案，也可以明确失败并要求重试。关键是让降级路径可预测、可观测，而不是在超时后随机返回一个未经检查的结果。

这也是推理预算比单次模型调用更适合做产品契约的原因。

当预算、延迟和验证器都需要独立观测时，才能把“多想一会儿”变成可运营的系统能力。

从组织流程看，推理预算需要产品、模型、平台和安全共同定义。产品决定可接受的等待时间，模型团队负责采样和验证，平台负责调度与成本，安全团队定义哪些动作必须人工确认。只由模型团队调一个“思考深度”参数，通常无法满足全部约束。

上线后还要监控预算漂移：同一档服务等级的候选数、验证耗时和失败率是否会随着流量、模型版本或工具延迟变化。若某个版本让平均候选数暴涨，成本可能在无人察觉时失控。把预算使用量和最终答案质量一起记录，才能持续校准。

评审一个推理预算方案时，可以固定检查：验证器是否有独立测试集；候选错误是否相关；总截止期是否硬限制；失败是否显式返回；成本是否可以按租户归因；质量提升是否超过统计噪声。把这些答案写进方案，比给出一个漂亮的平均准确率更能说明系统是否可运营。

当答案质量、延迟和成本都能按任务分层汇报时，团队才能判断哪些推理策略值得继续投资，哪些只是在为演示制造更大的数字。

如果任务必须做到“可以解释为什么选这个答案”，验证器还应保留候选间的差异和拒绝理由。只返回一个分数，既不利于审计，也不利于下一次改进。

因此，可靠答案的选择记录本身就是系统资产，而不是可以随手丢弃的中间日志。

如果日志能还原候选、验证和最终选择，团队就有机会复盘错误，而不是只看到一次成功或失败的结果。