同一道题，让模型立即给出答案，或者允许它生成多个候选、运行检查、修正后再提交，得到的结果可能不同。这个差别把注意力从“模型有多大”扩展到另一个问题：处理这一次请求时，怎样花额外的计算预算？

这篇文章解释推理时计算（test-time compute）的几种典型方式，并给出一个可以照着设计评测的例子。它是一篇研究方向入门，不是模型排行榜，也不把更长输出直接当作更强推理。

1. 先分清训练预算与推理预算

阶段 发生了什么 影响范围
预训练 从大量数据中学习语言与知识模式，更新参数 后续大量请求
后训练 用示范、偏好或奖励改进模型行为，更新参数 后续大量请求
推理时计算 对当前问题增加生成、搜索、验证或修订 当前请求及其候选结果

本文讨论的是固定权重下的推理策略。也有研究在测试阶段调整模型，这属于更广义的测试时适应，不能与这里的“多生成、多检查”直接画等号。

在 推理计算分配研究 中，Snell 等人讨论了验证器引导的搜索和响应分布的自适应改进。一个关键观察是：方法收益随题目难度变化，因此固定给所有题相同的额外预算未必划算。论文中的效率比较依赖具体模型、任务和计算口径，不能直接转换成任意服务的成本承诺。

2. 额外预算可以花在哪里

这张图是教学用的通用工作流，不代表某个闭源模型的内部实现。

并行采样：增加候选的多样性

从同一个问题生成多个候选，然后选择一个。它有两个独立问题：候选里有没有好答案，以及系统能不能把好答案选出来。

如果每次成功概率为 p，并且各次完全独立，那么 N 次里至少一次成功的概率是 1-(1-p)^N。例如假设 p=0.4、N=4，这个理想概率是 87.04%。这是概率公式的自拟算例，不是实测模型成绩。

实际生成经常存在共同错误，例如都误解了同一个约束；独立假设就不成立。即使候选中确实有正确答案，选择器也可能挑错，所以“候选至少一个正确”仍不等于“最终交付正确”。

答案投票：适合能够归一化的结果

Self-Consistency 论文 研究了采样多条推理路径并聚合最终答案的方法。对于数学题，可以先把 0.5、1/2 等等价答案归到一组，再统计一致性。

但一篇文章或一份设计方案很难用字符串计数选出最佳版本。即使是数值答案，多数也可能共同出错。因此，投票提供的是一致性信号，不是真值证明。

验证器：检查候选满足了哪些条件

验证器可以是测试程序、约束检查器，也可以是训练出的打分模型。选择哪种验证方式，会决定系统擅长排除什么错误。

检查方式 可以发现什么 仍可能漏掉什么
编译与单元测试 语法错误、覆盖到的功能错误 未覆盖输入、复杂度问题
形式化检查 形式化命题或约束是否成立 命题本身是否忠实表达需求
引用核对 答案与提供证据是否吻合 证据是否过时或来源本身有误
模型打分 某些复杂语义或质量差异 打分偏差与共同盲点

“检查通过”必须附着在具体检查范围上。只有输出一个高分，读者还不知道高分意味着哪些错误被排除了。

3. 用一道动态规划题想象完整流程

以本站 动态规划两题 中的 Cut Ribbon 为例，假设生成了三种解法：

候选 做法 应用什么检查
A 一直选最短的一段 用 7 2 3 5 检查是否会留下余料
B DP，但所有状态都初始化为 0 用 7 2 4 7 检查是否从不可达前驱转移
C DP，显式区分不可达状态 继续做穷举对拍、边界和复杂度检查

A 和 B 都可能在少量样例上显得合理。额外预算只有用于覆盖这种语义差别，才会产生实质收益。如果只是让它们互相称赞，或者用同一份错误解释重复评分，候选再多也可能保持错误共识。

上述候选是人为构造的教学案例，没有调用模型，也没有声称测出某个系统的准确率。

4. 强化学习与推理计算怎样衔接

训练阶段可以用奖励信号调整模型，使其更倾向于生成有效的求解和检查行为；推理阶段再决定每个请求允许多少候选、多少轮修订。前者改变策略，后者分配执行预算。

DeepSeek-R1 研究 展示了强化学习用于激励可验证任务推理行为的一条路线。阅读时应区分训练流程、模型版本和评测任务；不能把一个数学或代码实验的结果直接外推到所有开放式问题。

如果已经读过 策略梯度入门，可以沿着“什么行为得到奖励、奖励依据什么判断”来理解这条研究路线。把输出长度本身当奖励，可能鼓励冗长；把单个不完善的检查器得分当唯一目标，也可能让系统偏向检查器的漏洞。这是设计实验时需要排查的可能性，不是对某个具体模型的测量结论。

5. 一个可复用的评测方案

以下是作者提出的实验设计建议，不是引用论文中的实验记录。

准备固定题集，按任务类型和基线通过率分组。保留独立测试集，不用它来调提示词、挑验证器或决定采样次数。接着对比四组配置：

配置 生成策略 选择方式 要回答的问题
单次基线 一次生成 直接提交 原始能力怎样
多候选 N 次生成 固定聚合规则 多样性有没有帮助
验证选择 N 次生成 预先固定的检查器 选择器能否识别好答案
反馈修订 初始候选后允许修订 同一套检查标准 反馈是否纠正了错误

不要只固定 N。各候选长度不同，验证器也有开销；至少同时记录总生成量、调用次数、验证耗时与端到端延迟。如果比较“相同预算下谁更好”，必须先写明预算究竟是 token、费用还是计算量，它们并不等价。

每题至少记录：是否最终正确、候选中是否存在正确答案、选择器是否选中它、总成本、总延迟和失败原因。重复试验时保留分布或不确定性范围，避免把一次偶然成功当成稳定提升。

把生成能力与选择能力分开看

假设在一个虚构的 100 题算例中：

  • 70 题的候选集合里至少存在一个正确答案；
  • 选择器最终只在 55 题提交了正确答案；
  • 另外 30 题从未生成正确候选。

那么最终准确率是 55%，不是 70%。15 题属于“有正确候选却没选中”，30 题属于“候选生成失败”。前者提示改进选择器，后者提示补知识、换求解方法或改善候选生成；只增加候选数未必同时解决两类问题。

统计“候选中有正确答案”需要离线评测的真值。线上部署通常不知道真值，不能把这个诊断上界当成可直接获得的产品能力。

6. 与 RAG 放在一起看

RAG 增加可用证据，推理时计算增加处理当前问题的工作量；两者可以结合，但解决的瓶颈不同。

如果回答错是因为缺少最新版制度，先增加检索和版本过滤可能更有效；如果证据已经完整，却把多个条件组合错了，再考虑结构化检查与修订。这个分流可以衔接 RAG 评测文章 的失败诊断。

对日常应用，可以先建立单次基线，在验证集上找出哪些任务值得追加预算，再设置明确的停止条件。公开评测中的涨分、用户能否等待、每次成功的实际成本，应该放在同一张决策表中观察。

7. 原始资料与阅读顺序

资料核对日期：2026-09-05。下面按概念顺序排列，年份表示研究的首次公开时间，并不表示它们是当日最新论文。

  1. Self-Consistency Improves Chain of Thought Reasoning in Language Models（2022）：先理解“多个候选”和“最终答案聚合”。
  2. Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters（2024）：再看为什么难度和预算分配会改变策略收益。
  3. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning（2025）：最后把训练出的推理行为与推理阶段的预算联系起来；arXiv 页面列有后续修订。

阅读时始终保留三个问题：增加的计算具体花在哪里，正确性由什么验证，以及结论适用于哪些模型和任务。