理解test-time scaling:推理范式、评测与复现之道

发布时间:2026/8/27 4:53:32
理解test-time scaling:推理范式、评测与复现之道 这两年只要跟跑过推理模型的人聊 test-time scaling几乎都会听到同一种困惑同一个模型同一个题目别人把“思考预算”调高分数明显上涨自己换到另一类任务反而越思考越差。更常见的是论文里报一个 85% 的 passk自己照着重跑怎么都只到 78%。这种现象很少是因为模型权重不同更多是因为对 test-time scaling 的理解还停在表面。我想先把结论放在前面test-time scaling 的本质是把推理阶段的算力当作一种可分配资源。它不是一个“思考更久”的开关而是一组推理范式、一套评测方法和一份复现协议的组合。只打开 max_tokens 而不去设计推理范式、不做预算敏感评估、不记录完整实验变量最后得到的只会是一堆不稳定数字。1. 先搞清楚 test-time scaling 到底改变了什么1.1 从训练时缩放到推理时缩放在传统训练 scaling 时代我们习惯用参数规模、训练数据和训练算力预测能力。训练结束后模型权重固定推理阶段通常只做一次前向生成。这个阶段的算力开销被认为是成本项而不是能力项。但 o1、R1 这一类推理模型出现之后情况变了。研究者发现在推理阶段给同一个模型分配更多计算——允许它写更多推理中间步骤、采样更多候选答案、或者搜索多条路径——就能在数学、代码、逻辑题上获得明显提升。这就是 test-time scaling 想要研究的问题推理时算力应该如何分配才能稳定换回准确率这里有一个关键前提不是所有模型都适合“思考更久”。一个没有经过长推理训练的模型即便你给它 10 倍 max_tokens它可能只是把错误思路写得更长。能有效消耗额外计算并在后半段纠正自己是一种需要训练才能获得的能力。在强化学习训练中模型通过奖励信号学会什么时候该回溯、什么时候该换一种思路这比单纯生成更多字难得多。1.2 它带来的三个新问题regime、评测、复现test-time scaling 让原本只属于训练阶段的计算规划突然变成了推理阶段也要做好的事情。于是三个新问题浮出水面推理范式问题预算到底是花在单条轨迹长度上还是花在采样数量上又或者花在树搜索上评测问题不同预算之间的准确率如何公平比较pass1 显然不够只看单点分数又会被随机性欺骗。复现问题解码参数、提示词模板、验证器实现、答案解析器任何一项没记录结果就很可能无法复现。这三个问题不会自己消失。它们决定了同一个模型在不同人手里为什么跑出完全不同的“推理能力”。2. 推理范式不是一个参数四类 regime 的取舍2.1 顺序扩展给模型一条更长的思考跑道最直观的 regime 是顺序扩展也就是让模型单次生成更长的推理轨迹。打开推理模型后模型会输出很长一段思考过程再给出最终答案。从效果上讲这相当于把中间计算写在纸上避免模型在“脑内”推算时信息溢出。这一类方法实现最简单但有两个坑。第一不是所有模型都支持长推理。如果模型没有经过相应训练长序列会变成自我重复甚至编出越来越长的幻觉链条。第二难易任务都开长思考会浪费大量延迟。服务端如果不做路由简单问题也会背上几倍 token 成本。2.2 并行采样不需要验证器的自一致性第二种 regime 是并行采样用自一致性或者多数投票聚合答案。流程是固定同一个提示词用 temperature 0 采样 k 条独立答案然后对答案做投票或聚类选择多数答案。在数学和选择类任务里这常常是性价比最高的起点。这里最容易被忽略的是采样多样性。若 temperature 设为 0每个候选都一样k 个样本等同于 1 个样本。若 temperature 过高格式解析失败会变多。实际操作中我通常会先把 temperature 调到 0.6 到 1.0 之间先跑一小组题目看答案多样性再决定是否投入更大的 k。2.3 并行采样 验证器best-of-N 的前提是验证器可靠当任务不能靠投票轻松聚合或者模型在某个题型上存在系统性偏差时自一致性会失效。因为所有采样都共享同一套先验它们会以类似的方式犯错。这时更合理的做法是采样 k 条候选再用一个验证器给每条候选打分选择最高分。这个 regime 的前提是验证器足够好。验证器如果是简单规则或者弱奖励模型best-of-N 未必比多数投票强。实践中可以先算 oracle best-of-k也就是用真实答案从 k 个候选中挑出正确的那个看准确率上限。如果 oracle best-of-k 都不高问题主要出在采样质量而不是选择策略。2.4 搜索式推理高性能和高复杂度并存更重的 regime 是搜索式推理。这一步不再以完整答案为单位而是把推理过程拆成若干步用树搜索、beam search 或 MCTS 在步骤之间做规划。每一步用过程奖励模型评估局部状态引导后续生成。理论上这类方法上限最高因为它能把计算花在最有希望的路径上。但它对工程的要求也最高搜索宽度、深度、PRM 分数校准、路径剪枝每个环节都有一堆参数。对大多数实际业务来说我不会建议一开始就上搜索除非任务是数学证明、程序合成这类结构化极强的场景。Regime把预算花在哪关键依赖实现成本典型适用顺序扩展单次生成更长 CoT模型有长推理能力低分析型问答并行采样 自一致性多次生成 投票答案可聚合、采样多样低数学、多选题并行采样 验证器多次生成 选择可靠验证器中复杂推理、代码搜索式推理步骤级搜索PRM 搜索框架高数学证明、规划、程序合成选型时不要把 regime 当二选一。它们可以叠先并行采样再对其中较优的路径做更长展开也可以用搜索固定前几步再用自一致性选最终答案。关键是一次只改一个变量。3. 评测别只报一个准确率要画出准确率-预算曲线很多 test-time scaling 评测报告只有一列准确率pass1 多少pass8 多少verifier8 多少。这个信息量不够。因为每次你增加采样数、增加 max_tokens