测试时计算（Test-time compute）

这个说法指什么

语言模型的能力来自两笔分开的计算。一笔花在训练阶段：参数被设定下来，训练结束后就固定了。另一笔花在回答问题的当下：多采样几次、多做搜索、多拿验证器核对几遍。后一笔就是测试时计算（test-time compute）^[1]。两者的区别在于，它们花的是同一种货币——浮点运算——但决定的时间点不同：一笔在训练前就定死了，另一笔可以在每道题上临场决定花多少。

测试时计算要回答的问题是：这笔钱到底买到了什么。2024 年 8 月，Snell 等人发表了一项关于测试时扩展（test-time scaling）的研究，问的是：给模型一道真正有挑战的题，并允许它使用一份固定但不算少的推理期算力，它能提升多少^[1]。这个提法本身就把算力当成预算来看：先把额外算力固定住，再看其中有多少被有效地花掉。

两种花法

论文分析了两种机制^[1]。

第一种是拿密集的、基于过程的验证器奖励模型（dense, process-based verifier reward model）来做搜索^[1]。在这种设置里，模型不急着给出唯一答案，而是产生若干候选，另有一个验证器给候选打分。「基于过程」意味着验证器评的是解题的中间步骤，而不只是最后的答案；「密集」意味着它给出的是能一步步引导搜索的分数，而不是简单的一个通过或不通过。搜索据此决定哪条思路值得继续往下走。

第二种是给定题目后，自适应地更新模型对回答的分布^[1]。这种做法不把模型第一遍给出的回答分布当成固定不变，而是结合当前问题重新调整它，把概率质量挪向这道题所需要的回答类型。

两种机制都在把额外的推理算力换成更好的答案，但花的姿势不同：一种花在「多生成、多打分」上，另一种花在「改变模型怎么答」上。

难易程度决定哪种更划算

作者的核心经验观察是：两种方法的效果都随题目难度显著变化^[1]。哪种机制更划算，不是机制自身的属性，而取决于面前这道题。

正是这个观察促成了他们的算力最优（compute-optimal）策略：不对所有题目套同一个配方，而是逐题自适应地分配测试时计算^[1]。

得到了什么

两个结果值得注意。

与 best-of-N 基线相比——也就是「生成 N 个候选再挑一个」这种最直白的做法——算力最优策略把测试时计算扩展的效率提升了 4 倍以上^[1]。换句话说，同样的质量只需一小部分推理预算，或者同样的预算能换来更高的质量。

更能说明问题的是同等浮点运算量（FLOPs-matched）下的比较：把总计算量对齐之后，测试时计算让一个较小的基座模型胜过了大它 14 倍的模型^[1]。这个结论是有条件的：它成立的范围，是那些较小模型本身已经有一定成功率的问题^[1]。额外的推理算力放大的是以微弱形式已经存在的能力，论文并没有说它能凭空造出原本不存在的能力。

为什么不止是一篇论文的结论

作者把这个结果联系到一个更宏观的问题：未来的预训练预算与推理预算应当如何权衡^[1]。如果原本要投进一次更大规模预训练的那部分算力，可以改为在回答时花掉，那么「想要更强就得训得更大」就不再是唯一选项；两笔预算从此需要相互平衡。这也正是论文标题所指向的东西：把测试时计算扩展做好，效果可以超过扩大模型参数。

结论的边界也很清楚。同等算力下的胜出，是在较小模型已有一定成功率的问题上成立的^[1]；而策略本身是逐题自适应的，也就是说它的收益取决于按题分配这件事做得对不对^[1]。它更像一张说明「在什么条件下把推理算力花得更值」的路线图，而不是一条无条件成立的捷径。