1. 这篇论文到底在解决什么问题大模型推理这件事过去几年大家的默认思路基本是“堆参数”——参数量越大效果越好。从早期几亿参数到后来的千亿级这条路线确实work但代价也肉眼可见训练成本指数级上升推理时延和显存占用也跟着水涨船高。于是有一个问题开始被反复讨论如果我不继续把模型做大而是把推理阶段的计算量拉满能不能达到同样的效果这篇论文的核心命题就是这件事。它系统性地研究了**测试时计算Test-Time Compute**的扩展规律并给出了一个相当反直觉的结论在特定条件下把推理阶段的计算预算用对地方其收益可以超过单纯增加模型参数带来的收益。换句话说一个小模型如果“想得足够久、想得足够对”有可能打赢一个比它大好几倍但“脱口而出”的大模型。这个结论对做推理优化、模型部署、成本控制的人来说意义重大。它意味着你手里的算力预算可以有两种花法一种是花在训练更大的模型上另一种是花在推理时让模型做更多的“思考”。论文要回答的就是——这两种花法哪种性价比更高以及在什么条件下更高。适合读这篇内容的人包括做LLM推理优化的工程师、负责模型选型和成本评估的技术决策者、对推理策略如CoT、self-consistency、beam search等感兴趣的研究者以及想理解“为什么有些小模型用起来感觉比大模型还聪明”的开发者。2. 核心概念拆解什么是Test-Time Compute2.1 测试时计算的定义与范畴Test-Time Compute直译就是“测试时计算”指的是模型在推理阶段而非训练阶段额外消耗的计算量。它不是一个单一的技术而是一类方法的统称。常见的形态包括延长思维链Longer CoT让模型在给出最终答案前生成更多的中间推理步骤。比如从“直接回答”变成“先分析、再推导、再验证、最后回答”。采样多次再投票Self-Consistency / Majority Voting同一个问题让模型采样N次然后对答案做多数投票或加权聚合。树搜索类方法Tree Search / Beam Search over reasoning把推理过程建模成一棵树逐步扩展、评估、剪枝类似AlphaGo的搜索思路。迭代修正Iterative Refinement让模型先给一版答案再自我批评、自我修正反复多轮。验证器重排序Verifier-based Reranking生成多个候选答案用一个验证模型打分选最高分的。这些方法的共同点是模型参数不变但推理时消耗的FLOPs增加了。论文要研究的就是这些额外FLOPs的“投入产出比”。2.2 为什么“最优扩展”这四个字是关键标题里有个词很关键——Optimally。不是随便增加测试时计算就有用而是要“最优地”分配。这背后有一个很现实的观察测试时计算的收益是高度非线性的而且和问题难度强相关。举个直观的例子。一道简单题比如“35等于几”你让模型想100步它不会变得更好反而可能因为过度思考而出错。但一道难题比如一道复杂的数学证明你让模型多想几步、多采样几次效果可能立竿见影。所以“最优”的含义是根据问题的难度动态地分配测试时计算预算把算力花在刀刃上。论文的一个核心贡献就是提出了一个计算最优的扩展策略而不是简单地“越多越好”。2.3 与“缩放模型参数”的对比框架论文把两条路线放在同一个框架下比较维度缩放模型参数缩放测试时计算成本发生阶段训练阶段为主推理阶段为主成本特性一次性投入但门槛极高按需投入弹性大收益曲线对数线性边际递减非线性依赖问题难度灵活性训练完就固定可针对每个请求动态调整适用场景通用能力提升难题攻坚、高价值任务这个对比框架是理解全文的基础。论文并不是说“参数缩放没用了”而是说在推理预算有限的前提下测试时计算的边际收益在某些区间内高于参数缩放的边际收益。3. 论文的核心方法论如何做到“最优扩展”3.1 问题难度的估计与分级要做到“最优”第一步是知道问题有多难。论文采用了一种基于模型自身置信度的难度估计方法。具体来说它会让模型先对问题做一个初步判断或者用一个小规模的采样来估计答案的分布。如果模型在少量采样下就高度一致说明这题对它来说简单如果采样结果发散说明这题难。这个思路的实操含义是你不需要一个外部的难度分类器模型自己的输出分布就是难度信号。这一点很重要因为它让整个策略可以端到端地部署不需要额外训练一个难度预测模型。在实际操作中你可以这样近似对每个问题先采样k次k取一个较小的值比如4或8计算答案的一致性。一致性高就走“短推理”路径一致性低就走“长推理多采样”路径。3.2 计算预算的动态分配策略论文提出的策略可以概括为一个分层的预算分配机制第一层快速筛查。用少量计算判断问题难度决定是否值得投入更多。第二层按难度分配。简单问题用标准推理中等问题用延长CoT难题用多采样验证器。第三层提前终止。如果模型在推理过程中已经高度确信就提前停止不再浪费计算。这里有一个很关键的工程细节提前终止Early Stopping的判据。论文用的是模型输出的熵或者验证器的分数。如果连续几步推理的置信度都很高就停。这个机制在实际部署中能省下大量算力因为很多问题其实不需要“想很久”。3.3 验证器的作用与训练在多采样和树搜索类方法中验证器Verifier是核心组件。它的作用是给候选答案打分从而选出最好的那个。论文对验证器的训练和使用做了详细分析核心结论是验证器的质量直接决定测试时计算的收益上限。如果验证器很弱采样再多也选不出好答案。验证器不需要和生成模型一样大。一个较小的验证器只要训练得当就能有效筛选。验证器的训练数据可以用模型自己生成。这是一种自举Bootstrapping的思路让模型生成大量答案用最终正确性作为标签训练验证器。实操中如果你不想自己训练验证器也可以用一些启发式规则替代比如答案的一致性、推理步骤的连贯性等。但论文的数据显示专门训练的验证器带来的收益明显更高。4. 实验设计与关键发现4.1 实验设置概述论文在多个推理密集型任务上做了实验包括数学推理、代码生成、逻辑推理等。对比的基线包括不同参数规模的模型从较小到较大在标准推理无额外测试时计算下的表现。同一模型在不同测试时计算方法下的表现。在固定总计算预算下参数缩放 vs 测试时计算的对比。评价指标主要是准确率同时记录了实际消耗的FLOPs或token数用来计算“单位算力收益”。4.2 核心发现一测试时计算的收益存在“甜点区”论文发现测试时计算的收益并不是单调递增的。对于每个问题存在一个最优的计算量区间计算量太少模型没想清楚答案质量低。计算量适中收益快速上升。计算量过多收益饱和甚至因为过度思考而下降。这个“甜点区”的位置和问题难度相关。简单问题的甜点区很靠左几乎不需要额外计算难题的甜点区靠右需要大量计算。最优策略的本质就是找到每个问题的甜点区。4.3 核心发现二小模型多计算可以打赢大模型这是论文最有冲击力的结论。在固定计算预算下一个较小模型配合最优的测试时计算策略在某些任务上可以超过一个更大模型的标准推理表现。具体来说在数学推理任务上小模型多采样验证器的组合准确率接近甚至超过了大模型直接推理。在代码生成任务上小模型迭代修正的策略效果显著优于大模型的一次性生成。但在一些需要广泛世界知识的任务上参数缩放的收益仍然更明显。这个发现的边界条件很重要测试时计算的优势主要体现在“推理密集型”任务上而不是“知识密集型”任务上。因为推理可以通过“多想”来弥补但知识不能。4.4 核心发现三最优策略因任务而异论文没有给出一个“万能公式”而是强调了任务依赖性。不同任务的最优测试时计算策略不同任务类型推荐策略原因数学推理多采样验证器重排序答案可验证采样多样性收益高代码生成迭代修正单元测试验证有明确的正确性信号逻辑推理延长CoT树搜索推理步骤可分解开放问答适度延长CoT过度计算收益低这个表格是我根据论文结论整理的实操参考实际使用时需要根据你的具体任务做调整。5. 实操落地如何在自己的项目中应用这些结论5.1 第一步判断你的任务是否适合测试时计算不是所有任务都值得投入测试时计算。你可以用下面这个清单快速判断任务是否有明确的正确性信号如果有比如数学题有标准答案、代码能跑测试那测试时计算的收益会很高因为验证器容易做。任务是否依赖推理而非记忆如果任务主要是“回忆知识”那参数缩放更有效如果是“多步推理”测试时计算更有效。你的推理预算是否弹性如果推理预算很紧比如实时对话那测试时计算的空间有限如果是离线批处理空间就大。问题难度分布是否分散如果大部分问题都很简单那动态分配策略的收益有限如果难度分布广收益就大。5.2 第二步搭建最小可行的测试时计算框架如果你想快速验证效果可以从最简单的方案开始# 伪代码示意基于一致性的动态采样策略 def adaptive_inference(model, question, max_samples16, confidence_threshold0.8): answers [] for i in range(max_samples): answer model.generate(question, temperature0.7) answers.append(answer) # 每采样4次检查一次一致性 if (i 1) % 4 0: consistency compute_consistency(answers) if consistency confidence_threshold: break # 提前终止 # 多数投票 return majority_vote(answers)这个框架的核心是提前终止如果模型已经足够确信就不再浪费计算。实测下来这个简单的策略在很多任务上就能带来明显提升。5.3 第三步引入验证器提升筛选质量当你有了多采样的基础后下一步是引入验证器。验证器的选择有几种规则验证器适用于有明确规则的任务比如数学题的数值验证、代码的单元测试。模型验证器用一个较小的模型给答案打分。可以用论文提到的方法自举训练。混合验证器规则模型结合先用规则过滤明显错误的再用模型排序。注意验证器的训练数据要覆盖模型可能犯的错误类型否则验证器会“漏判”。论文里提到验证器的泛化能力是关键瓶颈。5.4 第四步动态分配计算预算这是最复杂但也最有价值的一步。你需要一个难度估计器然后根据难度决定计算量。实操中可以用这样的分级简单一致性0.9单次生成不额外计算。中等一致性0.5-0.9采样4-8次多数投票。困难一致性0.5采样16次以上验证器重排序必要时迭代修正。这个分级阈值需要根据你的任务做校准。建议先用一批标注数据跑一遍看看不同难度下的最优计算量再定阈值。6. 常见问题与避坑指南6.1 为什么我加了测试时计算效果反而下降了这是最常见的问题。原因通常有几个过度思考Overthinking模型在简单问题上想太多反而引入了错误。解决办法是设置提前终止条件。验证器太弱采样了很多答案但选错了。解决办法是提升验证器质量或者用更保守的筛选策略。采样温度不当温度太高导致答案质量下降温度太低导致多样性不足。建议在0.5-0.8之间调。问题本身不适合如果是知识密集型任务测试时计算收益本来就低。6.2 验证器怎么训练才有效论文的经验是数据量要够至少几千条带标签的样本。负样本要多样不能只有“明显错误”的负样本要有“看起来对但实际错”的难负样本。验证器和生成器要解耦不要让验证器看到生成器的中间过程只看最终答案。定期重新训练生成模型更新后验证器也要跟着更新。6.3 计算预算怎么估算你需要知道每个操作的成本操作大致成本相对值单次生成1x延长CoT2倍长度2x采样8次8x采样8次验证器8x 验证器成本树搜索深度3宽度4约12-16x然后根据你的预算上限选择对应的策略。论文的核心观点是在预算约束下动态分配比固定策略更优。6.4 小模型测试时计算真的能替代大模型吗要分场景看。论文的结论是“在某些任务上可以”不是“所有任务上都可以”。具体来说可以替代的场景数学推理、代码生成、逻辑谜题等有明确验证信号的任务。难以替代的场景开放域问答、创意写作、需要广泛知识的任务。部分替代的场景中等难度的推理任务小模型计算可以接近大模型但极端难题仍然需要大模型。我的建议是不要把测试时计算当成“免费午餐”它是在特定条件下的一种性价比优化手段。如果你的任务适合它能帮你省下大量训练成本如果不适合硬上只会浪费推理算力。7. 对行业实践的影响与个人思考这篇论文对做推理服务的人来说最大的启发是推理策略需要从“静态”转向“动态”。过去我们部署一个模型推理配置基本是固定的temperature固定、max_tokens固定、不做额外采样。但论文告诉我们每个请求的最优推理配置是不同的应该根据问题难度动态调整。这意味着推理系统的架构需要变化你需要一个难度估计模块、一个预算分配模块、一个验证器模块以及一个能动态调整推理流程的调度器。这套东西的工程复杂度不低但收益也是实打实的。另一个启发是验证器的价值被低估了。过去大家更关注生成模型本身但论文的数据显示验证器的质量直接决定了测试时计算的收益上限。未来可能会出现专门做验证器的团队和产品就像现在有专门做embedding、reranker的团队一样。从成本角度看测试时计算把一部分训练成本转移到了推理成本。这对训练资源有限但推理资源充足的团队是利好对推理成本敏感的团队则是挑战。最终的选择取决于你的成本结构和任务特性没有一刀切的答案。我个人在实际操作中的体会是先从简单的多采样多数投票开始验证收益后再逐步引入验证器和动态分配。不要一上来就搞复杂的树搜索那个调参成本很高而且收益不一定比简单方法好。另外难度估计器的校准很关键阈值定得太松会导致简单问题被过度计算定得太紧又会让难题得不到足够计算。建议用A/B测试的方式逐步调优而不是一次性拍脑袋定参数。 
长河君 · 2026/10/20 18:04:00 · 阅读 1.2k 测试时计算最优扩展：小模型如何通过推理计算超越大模型
1. 这篇论文到底在解决什么问题大模型推理这件事过去几年大家的默认思路基本是“堆参数”——参数量越大效果越好。从早期几亿参数到后来的千亿级这条路线确实work但代价也肉眼可见训练成本指数级上升推理时延和显存占用也跟着水涨船高。于是有一个问题开始被反复讨论如果我不继续把模型做大而是把推理阶段的计算量拉满能不能达到同样的效果这篇论文的核心命题就是这件事。它系统性地研究了**测试时计算Test-Time Compute**的扩展规律并给出了一个相当反直觉的结论在特定条件下把推理阶段的计算预算用对地方其收益可以超过单纯增加模型参数带来的收益。换句话说一个小模型如果“想得足够久、想得足够对”有可能打赢一个比它大好几倍但“脱口而出”的大模型。这个结论对做推理优化、模型部署、成本控制的人来说意义重大。它意味着你手里的算力预算可以有两种花法一种是花在训练更大的模型上另一种是花在推理时让模型做更多的“思考”。论文要回答的就是——这两种花法哪种性价比更高以及在什么条件下更高。适合读这篇内容的人包括做LLM推理优化的工程师、负责模型选型和成本评估的技术决策者、对推理策略如CoT、self-consistency、beam search等感兴趣的研究者以及想理解“为什么有些小模型用起来感觉比大模型还聪明”的开发者。2. 核心概念拆解什么是Test-Time Compute2.1 测试时计算的定义与范畴Test-Time Compute直译就是“测试时计算”指的是模型在推理阶段而非训练阶段额外消耗的计算量。它不是一个单一的技术而是一类方法的统称。常见的形态包括延长思维链Longer CoT让模型在给出最终答案前生成更多的中间推理步骤。比如从“直接回答”变成“先分析、再推导、再验证、最后回答”。采样多次再投票Self-Consistency / Majority Voting同一个问题让模型采样N次然后对答案做多数投票或加权聚合。树搜索类方法Tree Search / Beam Search over reasoning把推理过程建模成一棵树逐步扩展、评估、剪枝类似AlphaGo的搜索思路。迭代修正Iterative Refinement让模型先给一版答案再自我批评、自我修正反复多轮。验证器重排序Verifier-based Reranking生成多个候选答案用一个验证模型打分选最高分的。这些方法的共同点是模型参数不变但推理时消耗的FLOPs增加了。论文要研究的就是这些额外FLOPs的“投入产出比”。2.2 为什么“最优扩展”这四个字是关键标题里有个词很关键——Optimally。不是随便增加测试时计算就有用而是要“最优地”分配。这背后有一个很现实的观察测试时计算的收益是高度非线性的而且和问题难度强相关。举个直观的例子。一道简单题比如“35等于几”你让模型想100步它不会变得更好反而可能因为过度思考而出错。但一道难题比如一道复杂的数学证明你让模型多想几步、多采样几次效果可能立竿见影。所以“最优”的含义是根据问题的难度动态地分配测试时计算预算把算力花在刀刃上。论文的一个核心贡献就是提出了一个计算最优的扩展策略而不是简单地“越多越好”。2.3 与“缩放模型参数”的对比框架论文把两条路线放在同一个框架下比较维度缩放模型参数缩放测试时计算成本发生阶段训练阶段为主推理阶段为主成本特性一次性投入但门槛极高按需投入弹性大收益曲线对数线性边际递减非线性依赖问题难度灵活性训练完就固定可针对每个请求动态调整适用场景通用能力提升难题攻坚、高价值任务这个对比框架是理解全文的基础。论文并不是说“参数缩放没用了”而是说在推理预算有限的前提下测试时计算的边际收益在某些区间内高于参数缩放的边际收益。3. 论文的核心方法论如何做到“最优扩展”3.1 问题难度的估计与分级要做到“最优”第一步是知道问题有多难。论文采用了一种基于模型自身置信度的难度估计方法。具体来说它会让模型先对问题做一个初步判断或者用一个小规模的采样来估计答案的分布。如果模型在少量采样下就高度一致说明这题对它来说简单如果采样结果发散说明这题难。这个思路的实操含义是你不需要一个外部的难度分类器模型自己的输出分布就是难度信号。这一点很重要因为它让整个策略可以端到端地部署不需要额外训练一个难度预测模型。在实际操作中你可以这样近似对每个问题先采样k次k取一个较小的值比如4或8计算答案的一致性。一致性高就走“短推理”路径一致性低就走“长推理多采样”路径。3.2 计算预算的动态分配策略论文提出的策略可以概括为一个分层的预算分配机制第一层快速筛查。用少量计算判断问题难度决定是否值得投入更多。第二层按难度分配。简单问题用标准推理中等问题用延长CoT难题用多采样验证器。第三层提前终止。如果模型在推理过程中已经高度确信就提前停止不再浪费计算。这里有一个很关键的工程细节提前终止Early Stopping的判据。论文用的是模型输出的熵或者验证器的分数。如果连续几步推理的置信度都很高就停。这个机制在实际部署中能省下大量算力因为很多问题其实不需要“想很久”。3.3 验证器的作用与训练在多采样和树搜索类方法中验证器Verifier是核心组件。它的作用是给候选答案打分从而选出最好的那个。论文对验证器的训练和使用做了详细分析核心结论是验证器的质量直接决定测试时计算的收益上限。如果验证器很弱采样再多也选不出好答案。验证器不需要和生成模型一样大。一个较小的验证器只要训练得当就能有效筛选。验证器的训练数据可以用模型自己生成。这是一种自举Bootstrapping的思路让模型生成大量答案用最终正确性作为标签训练验证器。实操中如果你不想自己训练验证器也可以用一些启发式规则替代比如答案的一致性、推理步骤的连贯性等。但论文的数据显示专门训练的验证器带来的收益明显更高。4. 实验设计与关键发现4.1 实验设置概述论文在多个推理密集型任务上做了实验包括数学推理、代码生成、逻辑推理等。对比的基线包括不同参数规模的模型从较小到较大在标准推理无额外测试时计算下的表现。同一模型在不同测试时计算方法下的表现。在固定总计算预算下参数缩放 vs 测试时计算的对比。评价指标主要是准确率同时记录了实际消耗的FLOPs或token数用来计算“单位算力收益”。4.2 核心发现一测试时计算的收益存在“甜点区”论文发现测试时计算的收益并不是单调递增的。对于每个问题存在一个最优的计算量区间计算量太少模型没想清楚答案质量低。计算量适中收益快速上升。计算量过多收益饱和甚至因为过度思考而下降。这个“甜点区”的位置和问题难度相关。简单问题的甜点区很靠左几乎不需要额外计算难题的甜点区靠右需要大量计算。最优策略的本质就是找到每个问题的甜点区。4.3 核心发现二小模型多计算可以打赢大模型这是论文最有冲击力的结论。在固定计算预算下一个较小模型配合最优的测试时计算策略在某些任务上可以超过一个更大模型的标准推理表现。具体来说在数学推理任务上小模型多采样验证器的组合准确率接近甚至超过了大模型直接推理。在代码生成任务上小模型迭代修正的策略效果显著优于大模型的一次性生成。但在一些需要广泛世界知识的任务上参数缩放的收益仍然更明显。这个发现的边界条件很重要测试时计算的优势主要体现在“推理密集型”任务上而不是“知识密集型”任务上。因为推理可以通过“多想”来弥补但知识不能。4.4 核心发现三最优策略因任务而异论文没有给出一个“万能公式”而是强调了任务依赖性。不同任务的最优测试时计算策略不同任务类型推荐策略原因数学推理多采样验证器重排序答案可验证采样多样性收益高代码生成迭代修正单元测试验证有明确的正确性信号逻辑推理延长CoT树搜索推理步骤可分解开放问答适度延长CoT过度计算收益低这个表格是我根据论文结论整理的实操参考实际使用时需要根据你的具体任务做调整。5. 实操落地如何在自己的项目中应用这些结论5.1 第一步判断你的任务是否适合测试时计算不是所有任务都值得投入测试时计算。你可以用下面这个清单快速判断任务是否有明确的正确性信号如果有比如数学题有标准答案、代码能跑测试那测试时计算的收益会很高因为验证器容易做。任务是否依赖推理而非记忆如果任务主要是“回忆知识”那参数缩放更有效如果是“多步推理”测试时计算更有效。你的推理预算是否弹性如果推理预算很紧比如实时对话那测试时计算的空间有限如果是离线批处理空间就大。问题难度分布是否分散如果大部分问题都很简单那动态分配策略的收益有限如果难度分布广收益就大。5.2 第二步搭建最小可行的测试时计算框架如果你想快速验证效果可以从最简单的方案开始# 伪代码示意基于一致性的动态采样策略 def adaptive_inference(model, question, max_samples16, confidence_threshold0.8): answers [] for i in range(max_samples): answer model.generate(question, temperature0.7) answers.append(answer) # 每采样4次检查一次一致性 if (i 1) % 4 0: consistency compute_consistency(answers) if consistency confidence_threshold: break # 提前终止 # 多数投票 return majority_vote(answers)这个框架的核心是提前终止如果模型已经足够确信就不再浪费计算。实测下来这个简单的策略在很多任务上就能带来明显提升。5.3 第三步引入验证器提升筛选质量当你有了多采样的基础后下一步是引入验证器。验证器的选择有几种规则验证器适用于有明确规则的任务比如数学题的数值验证、代码的单元测试。模型验证器用一个较小的模型给答案打分。可以用论文提到的方法自举训练。混合验证器规则模型结合先用规则过滤明显错误的再用模型排序。注意验证器的训练数据要覆盖模型可能犯的错误类型否则验证器会“漏判”。论文里提到验证器的泛化能力是关键瓶颈。5.4 第四步动态分配计算预算这是最复杂但也最有价值的一步。你需要一个难度估计器然后根据难度决定计算量。实操中可以用这样的分级简单一致性0.9单次生成不额外计算。中等一致性0.5-0.9采样4-8次多数投票。困难一致性0.5采样16次以上验证器重排序必要时迭代修正。这个分级阈值需要根据你的任务做校准。建议先用一批标注数据跑一遍看看不同难度下的最优计算量再定阈值。6. 常见问题与避坑指南6.1 为什么我加了测试时计算效果反而下降了这是最常见的问题。原因通常有几个过度思考Overthinking模型在简单问题上想太多反而引入了错误。解决办法是设置提前终止条件。验证器太弱采样了很多答案但选错了。解决办法是提升验证器质量或者用更保守的筛选策略。采样温度不当温度太高导致答案质量下降温度太低导致多样性不足。建议在0.5-0.8之间调。问题本身不适合如果是知识密集型任务测试时计算收益本来就低。6.2 验证器怎么训练才有效论文的经验是数据量要够至少几千条带标签的样本。负样本要多样不能只有“明显错误”的负样本要有“看起来对但实际错”的难负样本。验证器和生成器要解耦不要让验证器看到生成器的中间过程只看最终答案。定期重新训练生成模型更新后验证器也要跟着更新。6.3 计算预算怎么估算你需要知道每个操作的成本操作大致成本相对值单次生成1x延长CoT2倍长度2x采样8次8x采样8次验证器8x 验证器成本树搜索深度3宽度4约12-16x然后根据你的预算上限选择对应的策略。论文的核心观点是在预算约束下动态分配比固定策略更优。6.4 小模型测试时计算真的能替代大模型吗要分场景看。论文的结论是“在某些任务上可以”不是“所有任务上都可以”。具体来说可以替代的场景数学推理、代码生成、逻辑谜题等有明确验证信号的任务。难以替代的场景开放域问答、创意写作、需要广泛知识的任务。部分替代的场景中等难度的推理任务小模型计算可以接近大模型但极端难题仍然需要大模型。我的建议是不要把测试时计算当成“免费午餐”它是在特定条件下的一种性价比优化手段。如果你的任务适合它能帮你省下大量训练成本如果不适合硬上只会浪费推理算力。7. 对行业实践的影响与个人思考这篇论文对做推理服务的人来说最大的启发是推理策略需要从“静态”转向“动态”。过去我们部署一个模型推理配置基本是固定的temperature固定、max_tokens固定、不做额外采样。但论文告诉我们每个请求的最优推理配置是不同的应该根据问题难度动态调整。这意味着推理系统的架构需要变化你需要一个难度估计模块、一个预算分配模块、一个验证器模块以及一个能动态调整推理流程的调度器。这套东西的工程复杂度不低但收益也是实打实的。另一个启发是验证器的价值被低估了。过去大家更关注生成模型本身但论文的数据显示验证器的质量直接决定了测试时计算的收益上限。未来可能会出现专门做验证器的团队和产品就像现在有专门做embedding、reranker的团队一样。从成本角度看测试时计算把一部分训练成本转移到了推理成本。这对训练资源有限但推理资源充足的团队是利好对推理成本敏感的团队则是挑战。最终的选择取决于你的成本结构和任务特性没有一刀切的答案。我个人在实际操作中的体会是先从简单的多采样多数投票开始验证收益后再逐步引入验证器和动态分配。不要一上来就搞复杂的树搜索那个调参成本很高而且收益不一定比简单方法好。另外难度估计器的校准很关键阈值定得太松会导致简单问题被过度计算定得太紧又会让难题得不到足够计算。建议用A/B测试的方式逐步调优而不是一次性拍脑袋定参数。