推理与系统 · Inference-time Scaling

推理时加算力，关键不是“想更久”，而是把预算花对地方

Test-time Compute（测试时计算，也常称 Inference-time Compute）是在服务阶段增加生成、采样、搜索、评分或工具执行。它能让同一模型在部分复杂任务上做得更好，但提升并不自动发生：还要看候选里有没有正确答案、选择器能否认出来、总工作量多大，以及延迟是否达标。

Test-time scaling 方法族：问题连同延迟、成本和风险约束进入预算与方法路由器，然后可选择延长单条推理轨迹、并行采样并投票或打分、使用树搜索或过程验证器迭代扩展与剪枝、调用检索和执行环境核验局部结论。各路径可以组合，最终记录验收门槛、停止原因与总成本；候选覆盖不等于选择正确，验证通过也不等于整份答案必然正确。 — 增加计算的位置决定了成本形状：长轨迹偏串行，多样本可以并行，搜索依赖中间评分，工具验证只覆盖它实际检查的部分。它们可以组合，但没有一种天然保证“算得越多、答案越准”。

00 · 先抓住

它更像“草稿纸 + 多份答卷 + 检查工具”，不是单纯把回答写长

生活类比

同一个学生多拿三分钟，可以打草稿、换解法、验算，也可能在简单题上反复改错。额外时间只是资源；是否增益，取决于解题策略和检查方法。

小例子

“找明天最便宜且不红眼的航班”不能只靠内部思考。系统要先检索实时航班，再生成候选、执行价格与时间约束检查，最后在延迟预算内给出带时间戳的结果。

初学者抓什么	CoT 是显式中间步骤；Self-consistency 是多条路径后聚合；Best-of-N 是多份候选后选择；Verifier 是检查器或打分器，不等同于 Reward Model。
产品上怎么想	先看任务能否验证、出错代价与 SLA。事实题可能要检索，数学题可能要执行验算，简单题则可能直接作答。
核心权衡	准确率、成本与延迟经常互相制约，但动态路由、并行执行和更好的验证器可以改变这条前沿，并非固定三选一。

01 · 定义

训练时学参数，推理时决定这一题要调用多少计算

训练计算改变模型参数；推理计算在参数通常固定时，为当前请求追加轨迹、候选、搜索节点、评分或外部工具。任务类型只是先验，真正的预算决策还应结合难度、可验证性、业务风险与服务等级协议（Service Level Agreement，SLA）。

CoT Chain of Thought

让模型生成一系列显式中间推理步骤。它在部分多步任务上有效，但隐藏的 recurrent 或 latent computation 不能一概叫 CoT。

Search Sampling / Revision / Tree

采样多条候选、反复修订或扩展搜索树；搜索质量取决于扩展策略和中间评价信号。

Verifier Checker / Scorer

可以是规则、单元测试、执行器、定理检查器，也可以是学习到的 reward model。后者只是 verifier 的一种。

Tools Retrieval / Execution

检索、代码执行和模拟器能产生可核对 observation，但只证明已检查的局部命题，不自动证明最终答案整体正确。

02 · 四本账

只报一个“准确率提升”不够，至少要同时报四类指标

账本	它回答什么	常见指标	最容易混淆的地方
候选覆盖	N 个候选中是否至少有一个正确答案？	oracle pass@N、coverage	需要标准答案事后判定，不是线上最终准确率。
选择质量	有正确候选时，投票或 verifier 能否选中？	selected accuracy、conditional hit rate、ranking accuracy	候选越多，学习到的分数越可能被利用或“刷分”。
总工作量	系统实际做了多少生成、评分、路由与工具工作？	token、FLOPs、GPU-seconds、工具调用数	只数输出 token 会漏掉 verifier、检索和难度估计。
墙钟与 SLA	用户等了多久，长尾是否达标？	P50 / P95 / P99 latency、timeout rate	并行 N 条可缩短墙钟时间，但不会把 N 份逻辑工作变成一份。

两条最小公式

若每条候选独立且正确率都为 p，oracle 覆盖率才可写成 C_oracle = 1-(1-p)^N。再假设“没有正确候选时一定答错”，且选择器在已有正确候选时以概率 α 选中它，才有简化式 Acc_selected = C_oracle × α。真实系统通常不满足独立、同分布与固定 α，所以应实测整条曲线。

03 · 方法族

方法差别不只在“算几次”，还在怎样聚合和验收

方法	机制	增加的工作	证据边界 / 主要风险
Self-consistency	采样多条推理路径，对规范化后的最终答案做一致性聚合或多数投票。	通常近似增加 N 份生成。	不要求另有 verifier；适合答案可稳定归一化的任务，相关错误会一起投错。
Best-of-N	生成 N 个候选，再用规则、执行结果或学习到的分数选一个。	N 份生成 + N 份评分或执行。	选择器不是 oracle；不完美 reward model 下，N 继续增大可能诱发 reward hacking，真实质量反而下降。
PRM / 过程验证	Process Reward Model（过程奖励模型）对中间步骤评分，再用于排序、剪枝或搜索。	逐步打分与搜索调度。	过程监督是训练评分器的方式；只有评分器在推理期参与选择或搜索时，才构成 test-time scaling。
Revision / Tree Search	根据反馈修订轨迹，或扩展、评分、剪枝搜索节点。	多轮串行生成，或宽度 × 深度的分支。	早期错误评分会剪掉有效路径；更多节点不保证单调提升。
外部工具验证	检索、代码执行、单元测试、定理证明器或模拟器返回 observation。	工具延迟、沙箱资源与结果解析。	检查范围必须明确；测试通过不等于规格完备，检索命中不等于来源可靠。
Budget Forcing	s1 的具体做法包括提前截断，或模型试图结束时追加 “Wait” 让其继续生成。	改变单轨迹长度。	这是 s1 论文中的特定干预，不是所有 reasoning model 都适用的通用单调旋钮。

伪代码

Best-of-N + Verifier

generate, score, then select

candidates = []
for _ in range(N):
  trace, answer = model.solve(problem, temperature=τ)
  score = verifier(problem, trace, answer)
  candidates.append({"score": score, "answer": answer, "trace": trace})

winner = max(candidates, key=lambda item: item["score"])
return winner["answer"]  # 同时记录 N、总成本与停止原因

可手算：pass@N 不是 Best-of-N 最终准确率

假设每条独立候选正确率 p=0.4。4 条里至少一条正确的 oracle 覆盖率是 1-(1-p)⁴=1-0.6⁴=87.04%；若 verifier 在“至少有一条正确”时只有 80% 概率选中正确候选，且没有正确候选时一定答错，则简化最终准确率是 87.04%×80%=69.63%。同一模型、同一提示造成的正相关通常会让 IID 估计偏乐观；刻意增加多样性也可能降低相关性，因此不能只凭“相关”二字断言方向。

04 · 动态预算

先小额试算，再依据可验证信号决定继续、停止或升级

Compute-optimal 的目标不是给每题相同上限，而是在质量约束下选择轨迹长度、候选数、搜索方式与验证工具。难度路由本身也会耗费计算并产生误判；这部分成本不能从端到端账本里消失。

Test-time compute 动态预算路由：任务类型与难度、可验证性、业务风险和价值、延迟与成本 SLA 进入带开销的难度及预算路由器，给出初始 token、候选数和搜索宽度；生成、搜索或验证一轮后，依据执行测试、证据检查、候选收敛、分数间隔与边际收益判断是否达到经校准的验收门槛。有预算则增加下一档计算，无预算则返回带不确定性的最佳候选、拒答或转人工；全程记录路由、生成、评分与工具总成本。 — 动态预算是一条闭环，不是单一 token 上限。停止条件只能表示“按当前检查契约验收”，不能把 verifier 分高画成“答案必然正确”。

信号	怎么用	风险与补偿
初始探测 / 难度路由	用小预算试答、题型特征或预测器选择第一档策略。	路由也有成本与误差；应计入端到端基线，并报告错配率。
可验证性	能执行、检索或形式化检查的任务优先把预算投向验证。	验证器只覆盖检查契约；未覆盖约束仍可能出错。
Verifier 分差 / 候选收敛	领先分差足够或多次答案收敛时考虑停止。	分数可能失准或同源相关；阈值需在留出集和线上漂移下校准。
剩余 SLA 与边际收益	估计再加一档计算是否值得，超预算则降级、拒答或转人工。	同时看质量、P95/P99 延迟、GPU-seconds 与工具费用。

产品里的“思考旋钮”名称相似，但不是同一把尺子

官方接口（截至 2026-07-14）	公开控制方式	不能据此推断什么
OpenAI reasoning models	`reasoning.effort` 控制内部 reasoning effort；可用档位依模型而异。	档位不是跨模型固定 token 数，也不是准确率保证。
Anthropic Claude	较新模型文档推荐 adaptive thinking 配合 effort；兼容模型或旧式流程可见手动 `budget_tokens`。	不能把 legacy token budget 外推到所有 Claude 模型。
Google Gemini	官方文档按模型提供 `thinking_level` 等思考控制。	档位、默认值与可关闭性均依模型；不能直接和其他厂商档位换算。

接口会更新，生产系统应读取目标模型当日官方文档，并在自己的数据、并发和价格条件下重新标定。

05 · 证据边界

研究已经证明“推理期扩算”是一条轴，但没有证明一条万能曲线

案例	原始结果 / 机制	应该怎样读
OpenAI o1（2024）	OpenAI 官方报告 o1 在 AIME 2024 上单样本约 74%、64 样本共识约 83%、用学习到的评分器重排 1,000 个样本约 93%。	这是厂商自报的特定评测；pass@1、consensus@64 与 rerank@1000 是三种不同计算和选择契约，不能只写成“准确率 93%”。
Snell et al.（ICLR 2025）	论文在 MATH 的 500 道测试题、能力专用微调的 PaLM 2-S*、修订（用 Outcome Reward Model，结果奖励模型，ORM 选优）与 PRM 搜索设置中，报告 compute-optimal 策略相对 Best-of-N 可达 4×+ 推理计算效率；在有非平凡小模型成功率的子集上，FLOPs 匹配时可胜过参数量 14× 的大模型。	4× 是论文定义的推理计算效率，不是端到端 API 加速。其难度分析包含每题 2,048 次采样构造的 oracle 分箱，论文明确未计部署时估难成本；不能外推成“小模型普胜 14×”。
s1（2025）	论文用提前截断或追加 “Wait” 的 budget forcing；摘要报告 s1-32B 在 AIME24 从 50% 提到 57%。	它证明特定模型、提示与评测下轨迹长度可被干预，不证明所有模型追加 token 都单调变好。
DeepSeek-R1（2025）	R1-Zero 探索纯强化学习；正式 R1 还包含 cold-start 数据、reasoning-oriented RL、rejection-sampling SFT 与后续 RL，并发布蒸馏模型。	训练配方与推理预算共同塑造结果，不能把 R1 简化为“只靠 GRPO”或“只靠长 CoT”。
Plan-and-Budget / T1（ICLR 2026）	Plan-and-Budget 把问题拆成子问题后分配局部 token 预算；T1 把工具结果接入小型 verifier，针对计算与事实核查等仅靠小 verifier 较弱的环节。	前者说明预算可以局部分配，后者说明“外部可核对 observation + 模型判断”是另一条扩算路径；两者都依赖具体任务和工具覆盖。

06 · 常见误区

多算、会选、可验证，是三件不同的事

误区 1：token 越多越准

长轨迹会出现收益递减、过度思考或偏离；应测按难度分层的质量—计算曲线。

误区 2：pass@N 就是线上准确率

pass@N 是候选覆盖的 oracle 指标；线上还要乘上选择器的真实命中能力。

误区 3：Verifier 就是 Reward Model

Verifier 是职责；规则、执行器与学习评分器都能承担。Reward Model 只是其中一个实现。

误区 4：Verifier 分高等于正确

分数会分布外失准，也可能被候选利用。Best-of-N 的 N 过大时，真实质量甚至可能下降。

误区 5：并行后总计算也变少

并行和 batching 主要改变墙钟与硬件利用率；总 token、FLOPs 和费用必须另记。

误区 6：厂商 effort 档位可横向换算

不同模型的控制语义、隐藏 token 和默认策略不同；同名 low / high 不是统一 benchmark。

资料来源

论文、模型报告与官方接口文档

来源	链接
OpenAI o1	Learning to reason with LLMs · o1 System Card
CoT / Self-consistency	Chain-of-Thought Prompting · Self-Consistency Improves Chain of Thought Reasoning
过程验证	Let’s Verify Step by Step（PRM800K / process supervision）
Compute-optimal scaling	Scaling LLM Test-Time Compute Optimally…（ICLR 2025）
DeepSeek-R1 / s1	DeepSeek-R1 · s1: Simple test-time scaling
Best-of-N 边界	Is Best-of-N the Best of Them?（imperfect reward model 与 reward hacking）
动态预算 / 工具验证	Plan-and-Budget · T1: Tool-integrated Verification（ICLR 2026）
产品接口	OpenAI Reasoning · Anthropic Extended Thinking · Gemini Thinking

核查日期：2026-07-14。凡涉及多采样或额外思考的结果，应同时说明模型与版本、数据集、单次或多次采样、选择规则、token / FLOPs 口径、难度路由成本和延迟统计；否则数字无法公平比较。