9.5 解码侧的推理时扩展：生成、搜索与验证

前面几节回答的都是“下一个词元选哪个”。推理时扩展换了一个问题：要不要为同一个问题多花一些生成、验证或搜索的计算。模型怎样通过训练学会长思考、过程奖励模型怎样训练，放在 14.6 节；本节只站在解码系统一侧，回答三个问题：多采几条能好多少，要花多少，在引擎里怎样实现。

从解码系统看，它有三种形态：

• 单路径加长。 让模型先写出更长的思维链，再给答案。

• 多路径采样与选择。 对同一个 Prompt 并行采出多条回答，用多数投票、奖励模型或验证器选一条。

• 按步骤搜索。 把推理组织成树，在中间步骤打分、剪枝、扩展。

三者与 9.3 节的采样互补：采样决定每条路径怎样展开，推理时扩展决定展开几条、怎样选、预算怎样分。

9.5.1 多采几条能好多少：多数投票的算式

做法。 自洽性（self-consistency）对同一道题采 n 条带推理过程的回答，只取各自的最终答案，选出现次数最多的那个。

二元简化下的算式。 设每条回答独立、答对的概率是 p，答案只有对错两种。n 取奇数时，多数票正确的概率是

$$P_{\text{maj}}(n, p) = \sum_{k=(n+1)/2}^{n} \binom{n}{k} p^{k} (1-p)^{n-k}$$

取 p = 0.6、n = 5：5 条里至少对 3 条，三项分别是 C(5,3) × 0.6³ × 0.4² = 0.3456、C(5,4) × 0.6⁴ × 0.4 = 0.2592、0.6⁵ = 0.0778，合计 0.6826。表 9-11 给出更多取值。

单条正确率 p	n = 1	n = 5	n = 15	n = 41
0.7	0.700	0.837	0.950	0.996
0.6	0.600	0.683	0.787	0.904
0.4	0.400	0.317	0.213	0.097

表 9-11：二元答案、样本独立时，多数投票的正确率。

从表中读出两点。收益递减：p = 0.6 时，前 5 条把正确率提高 8 个百分点，从 15 条加到 41 条再提高 12 个百分点，却多花了 26 条。第三行是反例：单条正确率低于一半时，票越多错得越稳。

三个前提。

• 样本要有差异。 temperature = 0 时 n 条回答相同（暂不计 9.3.9 的数值扰动），投票没有意义。自洽性依赖 9.3 节的采样提供多样性，温度太低则各条高度相关，太高则单条正确率 p 下降。

• 正确答案要是众数，不必过半。 真实题目的答案不止两种。设正确答案的概率是 0.4，三种错误答案分别是 0.3、0.2、0.1，取相对多数，票数并列时随机取一个。精确枚举的结果是：n 为 1、5、15、41 时，正确率为 0.400、0.490、0.622、0.763。单条正确率不到一半，投票仍然有效，因为错误是分散的。反过来，模型若系统性地偏向同一个错误答案，投票只会放大它。

• 样本并不真正独立。 同一个模型、同一个 Prompt 采出的回答共享同一套系统性偏差，表 9-11 是上界。

工程上还要多做一步：从自由文本里抽出最终答案并归一化（1/2、0.5、50% 算同一个答案），否则票会被表面形式分散。

9.5.2 采到与选到：覆盖率、验证器与过度优化

采到很容易。 n 条里至少有一条正确的概率，即覆盖率（coverage，代码评测中称 pass@k），是

$$\text{pass@}k = 1 - (1-p)^{k}$$

p = 0.2 时，k 取 1、4、16、64，覆盖率依次是 0.20、0.59、0.97、约 1.00；p = 0.05 时是 0.05、0.19、0.56、0.96。单条正确率只有 5% 的题，采 64 条就几乎一定能采到一条对的。Large Language Monkeys 一文报告，覆盖率随样本数的增长可以持续四个数量级；在 SWE-bench Lite 上，同一个模型的解决率从单样本的 15.9% 升到 250 个样本的 56%。

选到才是瓶颈。 上面这个 56% 的前提是有单元测试自动判对错。同一篇论文指出，在没有自动验证器的领域，多数投票和奖励模型的效果在几百个样本之后就不再提升。覆盖率是上限，实际正确率取决于选择器能从 n 条里认出对的那一条的能力：

• 答案可机械验证（单元测试、形式化证明、可代入检验的方程）时，覆盖率几乎可以全部兑现。

• 只能靠奖励模型打分时，选择器本身的错误率成为上限。

n 越大，越容易选中钻空子的样本。 奖励模型是对真实质量的不完美近似。Gao 等人用一个“金标准”奖励模型充当真实质量，研究对代理奖励模型做 Best-of-N 时两者的关系：随着 n 增大，代理分数一直上升，金标准分数先升后降。n 很大时，选中的是最会讨好代理模型的样本，未必是最好的样本。

9.5.3 要花多少：并行采样的成本账

“采 N 条，成本 N 倍”只对了一部分。沿用 9.2.4 的口径：Llama 3 8B，Prompt 长 1,000，每条生成 500 个词元，N = 8。

项目	单条	N = 8，共享 Prompt	N = 8，不共享
Prefill 处理的词元	1,000	1,000	8,000
Decode 生成的词元	500	4,000	4,000
处理词元合计	1,500	5,000	12,000
KV 缓存峰值	1,500 个词元，约 188 MiB	5,000 个词元，625 MiB	12,000 个词元，1,500 MiB
每轮 Decode 耗时下界	约 4.8 ms	约 5.2 ms	约 5.2 ms
生成吞吐上界	约 207 词元/秒	约 1,525 词元/秒	约 1,525 词元/秒

表 9-12：并行采样 8 条的成本。KV 按每词元 128 KiB 计；耗时下界取“每轮要读的字节 ÷ 显存带宽”，带宽取 10.1 节的 3.35 TB/s，权重取整为 16 GB（同 11.7.4），KV 取末轮的长度；吞吐上界 = 并行条数 ÷ 每轮耗时下界。

三行结论：

• Prefill 只做一次。 N 条样本的 Prompt 完全相同，共享后总处理量是 1,000 + 8 × 500 = 5,000，不是 8 × 1,500 = 12,000。共享靠写时复制或前缀缓存实现（见 11.4 节和 11.5 节）。

• 延迟几乎不变。 Decode 受显存带宽限制，每轮耗时约等于“读一遍权重和 KV”的时间。单条是 (16 + 0.197) GB ÷ 3.35 TB/s ≈ 4.8 ms；8 条并行时每条各读自己的 1,500 行 KV，是 (16 + 1.573) GB ÷ 3.35 TB/s ≈ 5.2 ms，只慢约 8%，吞吐上界却是 7.4 倍。对单个用户，采 8 条再投票的等待时间与采 1 条相差无几。

• 真正按 N 倍增长的是生成的词元数和它们的 KV。 这 8 行占掉的批容量，本可以服务 8 个不同的用户。批足够大、把 GPU 推过 10.1 节的拐点之后，延迟也会开始随 N 增长。

接口上，OpenAI 风格的 API 和 vLLM 的 SamplingParams 都用参数 n 表示“同一个 Prompt 采几条”。

9.5.4 单路径加长：思考预算的解码期实现

推理模型把思考过程写在一对特殊标记之间，再写答案。“思考多久”可以完全在解码期控制，不改模型。s1 一文称之为预算强制（budget forcing），两个方向各一种操作：

• 截短。 思考词元数超过预算时，直接把“结束思考”的分隔符追加到序列里，模型随即转入写答案。这是一次强制写入，不经过采样。

• 延长。 模型想结束思考时，压住“结束思考”标记不让它被选中，并追加一个 “Wait”，模型通常会接着检查前面的推理。前一半是对单个词元 ID 的掩码，属于图 9-1 的第①环，做法与 min_tokens 压住 EOS 相同；后一半是强制写入。

该文报告，对微调后的 32B 模型施加预算强制延长思考，AIME24 的成绩从 50% 升到 57%。

成本结构与并行采样相反。思考词元是串行生成的，延长一倍，延迟和 KV 占用都近似翻倍，无法靠并行摊薄。对本来就简单的题，强制延长还可能让模型把对的答案改错。延迟敏感的场景应当设预算上限，并按题目难度分配预算。

9.5.5 按步骤搜索：束搜索换了单位

第三种形态把 9.2.2 的束搜索原样搬过来，只换两样东西。扩展的单位从“一个词元”换成“一个推理步骤”，例如以换行为界的一段。打分从累积对数概率换成过程奖励模型（Process Reward Model，PRM，见 14.6.4）对部分解的评分。每一轮：W 条部分解各采 M 个候选的下一步，PRM 给 W × M 个候选打分，保留最高的 W 条（束宽仍按 9.2.2 记作 W）。

解码系统一侧的含义与束搜索相同：保留下来的候选要继承父节点的 KV 缓存，分页缓存下是改块表加写时复制；被剪掉的分支立即释放。额外的开销是 PRM 自己的前向，每个候选步骤一次。

预算怎样在“加长、多采、搜索”之间分配，取决于题目难度。Snell 等人的结论是，不同方法的效果随 Prompt 的难度显著变化；按难度自适应分配预算，达到同样效果所需的计算量可以比固定的 Best-of-N 少 4 倍以上。

9.5.6 边界

• 没有验证手段的任务受益有限。 开放式写作没有“最终答案”可投票，奖励模型又有 9.5.2 所说的上限。

• 前提是模型偶尔能做对。 单条正确率为 0 的题，采多少条覆盖率都是 0。推理时扩展放大的是模型已有的能力，不创造新能力。

• 成本不对称。 并行采样多花的是吞吐，单路径加长多花的是延迟，选哪一种要看系统缺的是哪一样。

三条边界指向同一件事：推理时扩展买到的是“同一个模型多花计算”，不是一个更强的模型。要不要花、怎样花，先看这道题有没有可靠的判对手段，再看系统缺的是延迟还是吞吐，最后才调预算的大小。

到此为止，本章讲过的策略都站在同一个前提上：文本从左到右、一次一个词元地生成，推理时扩展也只是把这条链重复几遍或者拉长。下一节把这个前提本身换掉。