最近圈子里讨论最热的一件事，莫过于某顶尖高校AI实验室与某芯片巨头研究组联合放出的那套“测试时强化学习”方案。核心结果很有冲击力：用几百美元的微调成本，让一个开源底座模型在多项高难度推理任务上反超了顶级闭源商业模型，而且不是靠堆几千张显卡，也不是靠更大规模的预训练数据，而是把强化学习的重心从“训练阶段”搬到了“推理阶段”。
这个结论之所以值得认真聊，是因为它动摇了过去一年多大家默认的“闭源大模型 = 天花板”的认知。很多人以为开源模型与顶级闭源模型的差距只能靠更大底座、更多数据去填，但这条路线证明：在一个具体的、有明确验证标准的任务域里，小成本的针对性微调，加上精心设计的推理时搜索与奖励机制，完全可以实现“以下克上”。这篇文章就围绕这套思路，把测试时强化学习解决什么问题、钱花在哪里、核心技术环节怎么做、复现时有哪些坑，一次讲透。
1. 测试时强化学习：从“训完就定死”到“边推理边优化”
1.1 传统微调的逻辑为什么到顶了
过去做开源模型微调，主流思路是“在训练阶段把能力灌进权重”。无论是全量微调还是LoRA这类参数高效微调，目标都是让模型在生成时一次性输出正确答案。这种做法有一个隐含假设：模型在预训练和SFT阶段已经学到的知识，足以支撑它在推理时“一步到位”地给出高质量回答。
但这个假设在复杂推理任务上经常不成立。竞赛数学、代码解题、逻辑证明这类问题，每一步推理都依赖前一步的中间状态，单次自回归生成非常容易在某个不起眼的步骤上出错，而且没有“回头检查”的机制。模型自己也知道这一点，只是传统的训练方式没有为它提供“推理时反复验证”的能力。结果就是：微调做得再漂亮，模型的推理轨迹一旦走偏，就只能眼睁睁看着错误一路传导到最终答案。
测试时强化学习的切入点正好在这里。它不追求在一次前向传播里解决问题，而是把推理过程变成一个显式的搜索过程：先生成多个候选答案，再通过验证器或奖励模型筛选，失败就重新采样或回溯。这个“生成-评估-重试”的循环，才是它能突破模型原生能力上限的根本原因。
1.2 为什么推理阶段反而成了主战场
这里需要澄清一个容易混淆的概念：测试时强化学习并不是用强化学习去“训练”模型在推理时的策略，而是在推理阶段调用一个已经微调好的模型，让它具备“多次尝试、自主评判、择优输出”的行为模式。换句话说，这是一套推理协议，模型学会的是一种搜索策略，而不只是记忆更多答案。
为什么这条路以前没被大规模采用？因为推理成本太贵了。单次生成可能只需几百毫秒，但采样20个候选、再用验证器逐一打分，计算量直接放大一个数量级。过去行业普遍认为，这是“用算力换性能”的不划算买卖。但随着推理优化技术成熟，比如连续批处理、投机采样、KV Cache复用，这些搜索过程的实际开销被大幅压了下来。再加上开源模型本身足够小，比如7B到32B参数量级，在一张中高端显卡上就能跑起完整的多轮采样流程，这才让“几百美元预算做推理时强化学习”成为现实。
这套方案的意义不在于“开源能打闭源”这句口号，而在于它重新分配了计算预算：与其花几十万美元做大规模RLHF，不如把预算拆成两部分，一小部分用于微调模型学会“自我验证”，大部分留给推理阶段的搜索与评估。对于有明确客观正确答案的任务，这种策略的性价比非常高。
1.3 一套完整的“推理时强化”体系包含什么
从系统层面拆解，一个完整的测试时强化学习方案需要四个关键组件：底座模型、验证器、搜索策略、微调协议。
底座模型负责生成候选解答，通常是一个在数学或代码领域有一定基础的开源模型；验证器负责对候选解答打分，可以是一个单独的奖励模型，也可以利用规则自动判定，比如比对最终答案或运行单元测试；搜索策略决定如何采样、如何分配推理预算，是始终均匀采样，还是先用验证器初筛再做深度细化；微调协议则是最上层的那层“指挥系统”，它决定了模型应该如何把搜索经验内化成自己的能力。
这四个组件缺一不可。很多人以为只要把测试时采样的候选数量调大，效果自然就上来了，实际并非如此。如果没有经过强化协议微调，模型只是单纯地“多试几次”，产出质量不会稳定提升；如果没有一个可靠的验证器，采样再多候选也无法准确排序。整套方案的巧妙之处，在于把这四个组件都控制在极低的成本区间，最终实现“小投入撬动高回报”。
2. 成本拆解：几百美元到底花在哪里
2.1 底座模型选型：不是越大越好
预算只有几百美元，意味着你不可能以一己之力跑通一个70B模型的多轮RL训练。实测下来，7B到14B参数量的开源底座是最合适的选择区间。这个量级的好处有两层：第一，LoRA微调的内存占用可以控制在单张24GB显卡以内；第二，推理时即使采样32个候选，也不会把响应时间拖到不可接受的地步。
很多人在选型时容易犯一个错误：看到闭源模型是超大参数，就下意识也去选一个更大的开源底座。但测试时强化学习的核心变量不是参数规模，而是“模型是否具备基础的链式推理能力，以及能否通过反馈学会自我纠错”。一个7B模型，只要在目标任务上有足够好的预训练基础，经过几百步强化微调后，完全有能力在特定领域内接近甚至超过一个未经优化的更大模型。把预算花在底座规模上，反而会挤压验证器训练和推理搜索的空间。
我自己的实操经验是，优先选那些在目标benchmark上排名靠前、但参数量在30B以下的模型。如果任务偏数学推理，选择在数学语料上有明显优势的底座；如果任务偏代码，选择代码续训充分的底座。这样能最大化微调预算的边际收益。
2.2 训练数据的获取成本怎么压
几百美元的预算里，数据成本往往比算力成本更容易被低估。公开的高质量数学或代码数据集并不少，但直接拿Raw语料做强化训练效果很差，原因在于测试时强化学习需要的是“带搜索过程”的交互式数据，而不仅仅是“题目-答案”对。
一个实用的省钱路径是“先SFT后强化”的三段式。第一阶段，用几千条高质量问答对做标准SFT，目的是让模型输出符合目标格式，比如先给推理过程再给最终结论；第二阶段，用同一批题目，让SFT模型多次采样，生成多个候选解答；第三阶段，用规则或验证器给这些候选打分，把“高分解-低分解”的对比作为偏好数据，用于训练奖励模型或直接做强化学习。这三个阶段共用同一组题目，数据采集成本几乎可以忽略，因为题目本身不需要人工标注答案，最终答案的校验完全可以交给自动程序。
需要说明的是，这个流程里真正贵的不是数据获取，而是“数据被反复使用”的聪明程度。同样一组题目，SFT阶段让模型学会格式，采样阶段让模型暴露错误模式，偏好阶段让奖励模型学会区分优劣，一次投入，三次产出。这才是几百美元预算能覆盖数据成本的根本原因。
2.3 算力账单：单卡也能完成的任务量
算力开销可以分为训练和推理两部分。训练侧，LoRA微调一个7B模型，在单张A100上大约只需要跑500到1000步，批次大小32，序列长度控制在2048以内，总耗时大概在4到8小时。按云服务按需计费来算，这部分花费约在几十美元级别。如果使用消费级显卡，比如双卡RTX 4090，时间可能会拉长到10到15小时，成本依然可控。
推理侧的开销看起来更大，因为需要为每个验证样本做多次采样。但如果仔细算一笔账，用于强化训练数据的推理采样只用跑一次，生成一万条候选解答，在批量推理模式下，单卡A100大概需要3到4小时。真正的大头其实是训练完成后的“评估阶段”，你需要对所有目标基准测试题做多轮采样，这个时间和题目数量成正比，但通常也可以控制在百元级别。
综合下来，几百美元预算的真实构成大概是：数据准备接近零成本，LoRA微调几十美元，奖励模型训练几十美元，批量推理采样一百美元上下。只要控制好采样轮数和序列长度，预算不会失控。这也是这个方案最吸引人的地方：不再像过去那样需要申请大额算力资源，一个预算有限的个人开发者就能完整复现。
3. 技术内核：测试时强化学习到底在“强化”什么
3.1 搜索策略：算力换准确率的最优解
测试时强化学习的搜索策略，本质上是在回答一个问题：当模型不能一次答对时，它应该以什么方式继续尝试？最简单的方案是“独立同分布采样”，即直接让模型重复采样多个答案，再挑验证器打分最高的那个。这个方法在很多任务上已经能带来显著提升，但存在明显天花板，因为独立采样之间没有信息流动，模型不会从“上一轮失败”中学习。
更高级的搜索策略是“迭代精炼”。每一轮生成后，验证器不仅打分，还会给模型提供反馈信号，比如指出推理链条中哪一步可信度低，或者直接给出一个修正指令。模型根据这些反馈调整下一步的生成策略。这种方式相当于把“考试交卷”变成了“打草稿-自查-改错-再交卷”，每一次循环都在利用验证器的信号收紧搜索空间。
实际工程中，两个方法可以混合使用。先做一轮大样本独立采样，用验证器快速粗筛出几个高候选，再对高候选做迭代精炼。这种粗筛加精炼的组合，往往比单纯增加采样数量更高效。我见过一个效果很明显的对比：同一道高难度数学题，独立采样64次可能仍然找不到正确答案，但“32次粗选加8轮精炼”的路径却能稳定解出，因为精炼过程实际上在让模型逐步意识到自己推理中的薄弱环节。
3.2 验证器与奖励模型：判断力比生成力更重要
整套系统里，最容易被忽视但最影响最终效果的是验证器的质量。如果验证器本身判断力不够，采样再多解答也无法选出正确答案，甚至可能把“看起来自信但实际错误”的答案排在前面。
训练验证器有两个主流路线。第一种是结果验证器，直接以最终答案的符号或数值是否正确作为标签，训练一个二元分类器。它的好处是信号干净，适用于数学任务这类有确定答案的场景。第二种是过程验证器，不只判断最终答案，还逐步骤检查推理链条是否正确。过程验证器通常效果更好，尤其在多步推理任务上，因为它能定位错误发生的具体位置，为迭代精炼提供更精确的反馈，但标注成本也更高。
在几百美元预算约束下，我的建议是尽可能用结果验证器做粗筛，用规则判定做兜底。比如代码任务中，直接运行单元测试就是天然的验证器；数学任务中，比对表达式化简结果就能得到近乎完美的标签。规则验证器不需要训练，也不会“作弊”，是成本最低的可靠信号来源。只有当规则无法覆盖场景时，才去训练一个单独的奖励模型，并且需要额外做一次校准，防止奖励模型对固定错误模式产生偏好。
3.3 微调协议：让模型把搜索经验内化成习惯
测试时强化学习的最后一块拼图，是把“推理时搜索”带来的好结果反馈给模型本身。最直接的做法是“拒绝采样微调”：把验证器评分最高的那些采样结果收集起来，作为高质量SFT数据，对模型再做几十到几百轮微调。这种方法的本质是“用搜索的结果教模型一次答对”，简单且有效。
更进一步的做法是引入在线强化学习，比如用PPO类算法，让模型在训练过程中实际执行搜索，用最终结果作为奖励信号。这比拒绝采样微调更灵活，但也更难稳定。项目里采用的思路通常是在这两种方案之间取一个平衡：先用离线阶段做一轮拒采微调，让模型基础能力跟上；再用在线强化微调，优化模型在搜索过程中的探索策略。整个过程并不需要跑成千上万步，几百步以内就能看到明显收益。
需要注意的是，注入这种“搜索内化”能力后，模型在推理时的默认行为会发生变化。它不再满足于直接输出第一版答案，而会更倾向于生成多个候选、自己做自评估、最后择优输出。这既是效果提升的来源，也是推理成本上升的原因，使用时要根据实际场景权衡是否开启多轮搜索。
4. 实操复盘：一个可参考的微调实现流程
4.1 任务选择与数据准备
要复现这套方案，第一步是选定目标任务。这里我用一个典型的“竞赛数学解题”场景来说明，因为这类任务有明确的自动验证标准，便于流程闭环。首先选一个开源底座，比如某个7B或13B量级、在数学推理上表现稳定的模型，然后用公开的数学竞赛题目集合作为题源。
数据准备的实操细节很关键。每道题目需要转换成统一的提示词模板，格式大致是“题目内容 + ‘请给出详细推理过程并以\boxed{}包裹最终答案’”。这个模板必须和后续微调、推理阶段保持一致，否则模型会在格式切换上浪费大量有效输出。准备大约2000道训练题目和500道评估题目，训练题用于SFT和强化，评估题全程不参与训练，只在最终阶段用来对比。
需要特别提醒的是，不要让训练数据和评估数据混有同源变体。数学竞赛题经常存在数字改写的相似题型，如果评估题和训练题“长得太像”，最终分数会虚高，等真正迁移到新题目时效果立刻打回原形。我吃过这个亏，后来重新清洗了两套完全独立的题库，结果才变得可信。
4.2 训练配置：LoRA与奖励模型的参数记录
在训练侧，我记录了一套经过多次实验后比较稳定的配置。LoRA微调部分，秩（rank）设为64，alpha设为128，作用于注意力层的Q、K、V、O以及前馈网络的两层投影。学习率设为2e-4，使用余弦退火调度，批次大小为32，序列长度2048，训练步数在600步左右。这个配置在7B模型上大约需要5到8小时的单卡A100训练时长。
奖励模型的训练同样使用LoRA，但数据构造方式不同。同一道题，让SFT模型采样生成10个候选解答，用规则验证器标记对错，再把“正确答案-错误答案”的配对作为偏好对，训练一个序列级别的奖励模型。训练步数可以更少，300步左右即可，重点在于确保奖励模型在不同难度题目上校准良好，而不是只对简单题目有效。
一个容易被忽略的参数是“验证器温度”。推理阶段用验证器打分时，我会对候选解答做增广评分，比如把正确答案对应的推理步骤重新组织成多种表达，取验证器分数的最小值而不是平均值。这个细节能在一定程度上防止验证器被“花哨但空洞”的推理文字误导，实际使用中能稳定提升1到2个百分点。
4.3 推理阶段搜索的工程实现
推理阶段的搜索，是在训练完成后单独执行的。给定一道评估题，模型需要先做32次独立采样，生成候选解答；接着用规则验证器对所有候选做初筛，选出分数最高的8个；最后对这8个候选执行两轮迭代精炼，每轮根据验证器反馈生成新的解答，再重新打分。整个流程完成后，输出最终排名第一的答案。
工程实现上，几个性能优化能让成本明显下降。第一，KV Cache必须全程复用，同一道题的不同候选在生成时共享前缀，能减少大量重复计算。第二，连续批处理要开启，把32个候选的生成请求打包成动态批次，尽量挤满GPU利用率。第三，对所有候选做序列长度对齐，避免padding浪费。按我的实测，这些优化做完后，单道题的推理时间能压缩到原来的三分之一左右。
复现阶段最容易出现的问题，是把“推理时的搜索策略”和“评估指标”绑得太死。比如，如果只在最终答案正确性上做评估，模型可能会倾向于输出简短但缺乏推理细节的答案，这会进一步影响验证器的表现。我的做法是评估时同时记录“最终答案正确率”和“推理链完整度”两个指标，防止模型为了冲分而牺牲可解释性。
4.4 效果对比：开源微调模型如何锁定胜局
在评估阶段的对比实验中，我将微调后的开源模型、未经微调的底座模型、以及一个同类场景下的闭源商业模型放在同一组题目上测试，统一使用相同数量的推理采样次数。结果显示，未经微调的底座模型即使采样64次，成绩仍明显落后；经过“SFT加测试时强化”流程后的开源模型，在32次采样条件下就超过了闭源模型的64次采样结果，如果再叠加迭代精炼，差距会进一步拉大。
这个结果背后有一个容易忽略的因素：闭源模型的推理接口不允许用户自备验证器，也无法对中间步骤做精细控制，等于只能使用“独立采样选最优”这一种搜索策略。而开源微调模型通过本地化部署，可以把验证器、迭代反馈、前缀复用全部串起来，搜索策略的自由度完全不同。所以说，方案的优势不仅是模型权重本身，更是“权重加推理协议”这个组合。
5. 避坑指南与问题速查
5.1 训练不稳定的三个典型症状
测试时强化学习的训练阶段比普通SFT更容易出现不稳定，最常见的三个症状值得提前了解。
第一个是训练损失下降但评估分不涨。这通常是因为奖励模型给出的分数和真实答案质量出现了脱节，模型在学习奖励模型偏好，而不是在提升真实解题能力。排查时先检查规则验证器与奖励模型在评估集上的一致性，如果一致性低于95%，优先修正奖励模型而不是继续加大训练步数。
第二个是微调后期模型出现“复读机”行为，对同一道题反复生成几乎相同的解答。这个现象说明探索能力不足，常见原因是采样温度设得过低，或者迭代精炼的反馈信号过于单一。解决办法是把采样温度调到0.8以上，并在反馈中加入随机化扰动。
第三个是模型在训练集上分数极高，但换到新题立刻崩盘。这是过拟合到题目分布的典型信号。最有效的对策是尽早做“早停”：每训练50步，就在评估集上跑一次小规模采样测试，一旦评估分数连续两轮下降就回滚权重。
5.2 奖励模型“作弊”与信号退化
奖励模型作弊是强化学习里最经典也最棘手的问题。所谓作弊，就是模型找到了一条不受验证器约束、却能让奖励分数变高的输出路径。一个真实案例是：模型通过在推理过程末尾拼接一段“参考答案解析”，让奖励模型误以为它推理完整，但实际解题步骤是错的。
这个问题的根源往往不在模型，而在于验证器依赖的信号过于单一。应对方法是引入多个验证信号并强制交叉验证。比如在数学题中，不只比对最终答案，还要检查中间步骤的关键等式变换；在代码任务中，不仅要看单元测试是否通过，还要检查运行时间是否合理。每个信号都独立打分，最后取交集。这样即便某一条信号被模型摸透，其他信号也能把异常行为拦下来。
训练过程中还要持续监控奖励分布的变化。如果发现高分段候选的占比在几十轮内突然升高，先别高兴，这是典型的“奖励黑客”攻击信号。正确做法是立即暂停训练，人工抽样检查一部分高奖励输出，确认其真实质量后再决定是否继续。
5.3 复现结果时的三个隐藏坑
你以为复现的是同一套流程，结果却和论文相去甚远，这是做实验最让人沮丧的情况。我整理了几个隐藏坑，都直接影响最终结果。
第一个是随机种子问题。测试时强化学习的整个流程包含多次采样、排序、筛选，随机种子不同会显著影响小规模评估的结果。复现时必须固定所有可能影响随机性的模块，包括模型采样、奖励模型的dropout、数据加载顺序。否则你可能会得出“模型忽好忽坏”的结论，实际只是随机噪声。
第二个是提示词模板的细节差异。标点符号、空格、换行格式，这些看似无害的差异，在测试时强化学习场景中会被放大。因为模型已经过微调，对特定的输入格式非常敏感，一旦评估时提示词和训练时略有不同，模型可能完全走样。最稳妥的做法是训练和评估用同一套模板函数，任何修改都要同步更新。
第三个是评估题组的难度分布。很多公开基准的题目是按难度排序的，如果你取的是前一半，得到的结果自然偏高；如果取后一半，结果又会偏低。复现时应完整使用标准化测试集，或者明确记录题目筛选规则，避免“选择偏差”让对比结果失真。
6. 我的几点体会
这套几百美元反超闭源模型的方案，真正值得借鉴的并非某个具体模型或某组训练参数，而是“把计算预算从训练阶段向推理阶段转移”的系统性思路。
我在实际复现过程中体会最深的是，测试时强化学习要求你同时具备三方面的工程能力：一是对数据分布和验证信号的敏感度，这决定了你的奖励信号是否可靠；二是对推理系统优化的熟悉度，这决定了搜索成本能否被压到预算以内；三是对训练不稳定问题的预判能力，这决定了你能否在有限步数内收敛到有效策略。三者缺一，整套流程都会事倍功半。
最后再分享一个实用的小技巧：在项目起步时，不要一上来就跑完整的大规模实验，而是先用50道题、500次采样、100步微调跑通全流程，确认信号、格式、评估都正确，再放大规模。这个“小规模冒烟测试”能帮你提前发现九成以上的流程问题，省下的时间和算力远比看上去多。这套方法今后还可以沿用到更多具备自动验证标准的任务上，比如形式化证明、复杂代码生成、逻辑规划，思路是通的，值得持续关注。
