企业官网建设流程全解析

测试时扩展（Test-Time Scaling）在近两年的LLM推理圈可以说是最热的关键词之一。从最初让模型多写几步思考过程就能明显提分，到现在动辄“思考几千个token再回答”的深度推理模型，大家都在琢磨同一件事：推理阶段多花的算力，到底换来了什么，要怎么花才最划算。而这次某AI研究团队在NeurIPS 2025上提出的“强化学习教师”框架（Reinforcement Learning Teachers of Test-Time Scaling），给这个问题提供了一个很不一样的角度——不用人肉设计调度规则，而是让强化学习自动学出一套“测试时算力分配策略”。

这篇文章不打算复读论文摘要。我想从一个做推理优化、平时也被推理成本按在地上摩擦的从业者视角，把这个框架拆开揉碎聊一聊：它到底在解决什么痛点，状态、动作、奖励这三个核心要素是怎么设计的，训练过程中有哪些容易翻车的细节，以及它跟验证器、自一致性这些成熟方法该如何搭配。不管你是做大模型服务化部署、做推理加速，还是单纯对“怎么让模型更会思考”感兴趣，这篇内容应该都能给你一些可以落地的启发。

1. 先拆开“测试时扩展”这个热词：它到底在解决什么问题

1.1 为什么推理阶段的算力忽然变得这么值钱

过去几年大模型能力的增长，主线一直是预训练阶段的规模缩放——数据、参数、算力往上堆。但到了现在这个阶段，纯粹靠预训练堆出来的边际收益开始明显下滑，大家不得不把目光转向推理阶段。测试时扩展的核心思想其实很朴素：模型权重不动，在推理阶段多花计算量，通过更长的思考链、多次采样、验证与修正等手段，把输出质量顶上去。这个思路之所以爆发，背后有两个直接推手。

第一个推手，是深度推理模型改变了大家对“推理”这件事的认知。以前我们要求模型直接给出答案，最多加一句“请一步步思考”。现在主流做法是允许模型在真正作答之前先展开一段较长的心智过程——你可以把这段过程理解成一支先遣队在探索地形，地形没探明白之前不要急着下结论。经验数据告诉我们，这种“先思考、后作答”的模式在数学、代码、逻辑推理这类复杂任务上，准确率提升非常显著。

第二个推手，是推理成本的矛盾变得尖锐了。模型确实变强了，但同一个问题在不同用户手里，需要的思考量差异极大。如果对所有请求一视同仁地给满预算，那么资费成本和响应延迟都会出问题。我见过不少团队在服务化部署推理模型时，最头疼的往往不是模型本身的效果，而是“推理预算怎么分配”：有的问题用户只想要个百科答案，模型却长篇大论地分析；有的问题明明需要多条路径交叉验证，模型却草草收场。这种资源错配在规模化服务里，会被放大成一个非常要命的成本问题。

1.2 固定预算和手工规则：为什么都不够用

目前业界主流的做法大致分两类。一类是固定预算：规定模型最多思考N步或者输出N个token，到点强制收尾。这个方案省心，但有两个天生的缺陷。第一，简单问题根本用不到满预算，白花的算力全部变成成本和延迟；第二，难题在“思考临界点”之前如果被强制截断，推理质量会突然掉档而不是平滑下降——因为模型在预算耗尽时会赶工式地仓促输出，而不是把已有思路好好收敛。

另一类是手工规则：比如自一致性投票数达到K就提前终止，或者置信度低于阈值就多采样几轮。这类规则比固定预算聪明一点，但它本质上是“用人的直觉去猜模型的认知状态”——你并不知道模型内部到底想通了没有，只是在用一个外显信号做粗略代理。更关键的是，固定规则没法做跨步骤的规划。真实推理里经常出现“先绕进一个死胡同、再退出来、最后走到正确答案”的情况，这种长链条的延时回报，靠一条提前设好的阈值规则是捕捉不到的。

这两类方案的共同问题，是把“算力分配”当成了一个静态配置项，而不是一个可以被优化的动态过程。而RL Teacher框架的核心转译，恰恰就是把算力分配重新定义成序列决策问题——学出来的不是一个固定规则，而是一套能根据当前进展持续调整的调度策略。

2. RL Teacher框架的整体设计：把“算力分配”变成智能体决策

2.1 一个监考老师式的层级分工

这个框架最值得注意的设计，是把测试时扩展从“生成过程”里剥离开来，单独训练一个教师策略（teacher policy），专门负责回答一个更高层的问题：当前这个推理状态，是该继续投入算力，还是该收尾给出答案？或者更精确一点，如果继续，该采取哪种行动——继续沿当前思路生成、切换候选路径，还是触发一轮自我验证。

这个抽象特别像考试时站在教室后面巡场的监考老师：学生（推理模型）埋头解题，老师不亲自下场做题，但清楚每个学生大概处于什么状态，知道什么时候该让ta再想想，什么时候该喊停收卷。把“何时多算、何时少算”从生成过程里抽出来，变成一个输入输出明确、可以被单独优化和评测的对象，这是整个框架最核心的贡献。

这种解耦在工程上还有一个很大的好处：推理底座可以保持冻结，教师策略单独训练、单独迭代，甚至更换推理模型底座后还能复用大部分策略。对做服务的人来说，这比把调度逻辑硬编码进采样循环要友好太多，也让这个框架天然具备“先离线验证、再上线部署”的工程路径。

2.2 状态、动作、奖励：三个要素的具体定义

要把这个决策问题落成可训练的强化学习任务，必须把马尔可夫决策过程的三要素定义清楚。我按这类框架的通行做法整理一下。

状态（State）的输入是当前问题上下文加上已经生成的推理轨迹。实际实现里通常不会把整段文本直接丢给策略网络，而是抽取一组特征：已消耗的算力量（累计token数）、最近几步的答案置信度、轨迹中是否出现矛盾结论的标记、问题本身的难度先验（如果有的话），以及把轨迹文本做一次轻量编码得到的向量。这里有个关键：状态里必须带时间维度信息，否则策略分不清“刚起步”和“快耗尽”这两种完全不同的处境，决策质量会大打折扣。

动作（Action）是一个离散动作集，常见的是“继续生成”“停止并给出当前答案”“切换到另一条候选路径”“触发一轮自我验证”。动作的决策频率一般放在“推理步”级别——比如每输出256个token做一次决策，而不是每个token都做。这样既保留了干预能力，又不会让策略网络调用本身成为新的性能瓶颈。

奖励（Reward）最稳的版本是稀疏终局奖励：最终答案正确给1，错误给0，再减去λ乘累计算力消耗。这个λ是效率与准确率之间的砝码，调λ就是在调整你的服务对准确率和成本的偏好。更复杂的做法是加入过程奖励，但过程标注成本高且容易引入噪声，我建议先在稀疏奖励下跑通整套链路，再根据训练表现决定要不要加。

2.3 为什么不用现成的分类器做早停

很多人看到这个框架的第一反应是：训练一个小分类器，输入当前轨迹，输出“现在停下来能答对的概率”，低于阈值就继续生成，不就行了吗？这个思路听起来很自然，但它有两个根本缺陷。

第一，分类器只会做“现状评估”，不会做“未来规划”。它只能回答“现在停下对不对”，回答不了“继续投入N步计算，有多大可能把答案从错变成对”。而后者才是测试时扩展真正需要的能力——识别一条暂时还没走通但值得继续探索的路径。第二，分类器的预测是逐点独立的，它建模不了决策之间的时序依赖。推理中常见的“先绕远路、后抄近道”的收益结构，必须放到一整个决策序列里才能被正确评估。

强化学习的优势恰好就在这里：它天然支持稀疏延时奖励下的序列决策。教师策略不必在每一步都判断“当前答案最终对不对”，而是通过学习整个决策序列与最终结果之间的关系，学会“现在忍受一些额外的计算成本，可以在未来换取更高的正确率回报”。这种非短视的决策能力，是静态分类器给不了的。

3. 训练过程关键细节：奖励标定、稳定性控制与组合策略

3.1 奖励设计的三条实操经验

奖励是整个框架的灵魂，也是最容易踩坑的地方。先说三条被反复验证的经验。

第一条，λ要认真标定。λ代表“一份算力值多少准确率”，它不是随便设一个0.1或者0.01就行。我的标准做法是：在验证集上扫一组λ值，画出“准确率-平均算力”的帕累托前沿，再根据业务场景选工作点。比如实时对话场景延迟敏感，就选偏向省算力的点；离线批量评测场景追求极致准确率，就选偏向高算力的点。这条曲线做好之后，整个项目的验收指标也都有了依据。

第二条，最终答案的正确性判定要实现得足够稳。数学、代码这类有标准答案的任务还好，直接比对即可。但开放域任务如果只用字符串匹配，教师策略很快会学会“用更短的输出绕开容易出错的长推理”这类钻空子行为。稳妥的做法是接一个小型判断模型对最终答案打分，虽然每次判定多花一点推理调用，但能挡住大量reward hacking问题。

第三条，不要迷信过程奖励。过程奖励（process reward）理论上能缓解稀疏奖励下的信用分配问题，但实际中过程标注成本极高，而且人工标注的“步骤正确”与模型真实的推理路径经常对不上。我的建议是先用终局奖励把基线跑起来，如果训练后期确实出现信用分配困难，再逐步引入过程信号，不要一上来就搭复杂奖励结构。简单可靠的奖励定义，是支撑整套训练稳定的地基。

3.2 训练稳定性：四个必须注意的地方

这类框架训练起来稳定性是个大问题，我按踩坑概率从高到低排四个点。

第一，不要联合训练推理模型和教师策略。联合训练在理论上更优雅，但实际中极容易震荡：推理模型的参数一变，教师策略面对的轨迹分布整体就变了，两边互相拖累。最稳的路线是冻结推理底座，只训教师策略；如果确实想联合优化，也要等教师策略单独收敛之后再做一轮小步微调。

第二，状态特征里必须包含“已消耗的算力”。没有这个特征，策略无法建立对资源稀缺性的感知，会出现同一段轨迹在刚开始和快结束时做出相同决策的怪象。这个特征看似简单，却是许多复现实验失败的根本原因。

第三，动作频率的选择要平衡。决策太频繁，策略会把“再写几个词看看”和“立即收尾”混在一起，动作熵暴涨；决策太稀疏，策略又失去干预时机。我的实践是以256个token作为一个推理步做决策，这大约相当于三四行自然语言的长度，既能捕捉到推理状态的实质变化，又不会产生过多策略调用开销。

第四，训练指标和部署指标要分开。训练时优化的是“准确率减λ乘算力”，但上线之后业务真正关心的往往是在固定算力预算下准确率能到多高，或是在固定准确率要求下算力能省多少。建议单独维护一套“固定预算对比”和“固定准确率对比”的评测脚本，防止训练指标很漂亮而业务指标没变化。

下面这段伪代码是我在搭训练循环时的核心骨架，你可以直接照着改：

# 教师策略训练循环（伪代码） for episode in range(total_episodes): state = get_initial_state(problem) trajectory = [] while not done: action = teacher_policy.sample(state) # 继续 / 停止 / 切换 / 验证 next_state, compute_delta, done = env.step(action) trajectory.append((state, action, compute_delta)) state = next_state final_answer = env.get_final_answer() reward = (1.0 if is_correct(final_answer, ground_truth) else 0.0) \ - lambda_cost * sum(cd for _, _, cd in trajectory) # 用 PPO + GAE 更新 teacher_policy ppo_update(trajectory, reward)

3.3 和Verifier、Self-Consistency怎么配合

框架跑通之后，一个很自然的疑问是：它和现在已经很成熟的验证器（verifier）、自一致性（self-consistency）是什么关系？我的结论很明确：不是替代关系，而是分工关系。

RL Teacher负责资源调度，verifier负责答案选择。具体操作上，可以让教师策略把一个问题的预算切成两段：前一段生成多条候选轨迹，后一段用verifier从候选中打分挑一个，教师再根据verifier的反馈决定要不要追加一轮计算。我在实际项目中实测下来，这种组合效果明显好于单独用任何一种。原因在于教师擅长“要不要继续投入”的大局判断，verifier擅长“哪条路径更靠谱”的局部判断，两者强项天然互补。

相比之下，只拿verifier做早停（verifier觉得当前答案可信就提前收尾）的方案会吃亏，因为它只有“提前停”这个动作，没有“主动追加计算”的动作。而RL Teacher方案恰好补上了这块短板：它既能在简单问题上提早收手，也能在大难题上主动加码——这两件事本来就是一枚硬币的两面。

4. 评测视角与关键发现：算力最终流向了哪里

4.1 哪类问题的收益最明显

从这类框架在数学、代码等复杂推理任务上的评测结果来看，收益最集中的永远是“中等偏难”那一档问题。对固定预算方案来说，这一档问题最尴尬：给少了答不对，给多了又太浪费。而训练好的教师策略通常能学会一种分层处理方式：先用低成本试探一条路径，如果早期就发现信号不妙（比如推理轨迹里出现了矛盾结论），再决定切换到更深度的搜索流程。这种“先浅后深、按需加码”的节奏，人工规则几乎不可能手工设计出来，但强化学习在足够的交互数据下能自己涌现出来。

还有一点值得注意：简单问题在自适应策略下消耗的算力会被压得非常低。这不是模型变笨了，而是策略学明白了——既然随便写几步就能答对，多烧算力就是纯亏损。省下来的这部分算力，被自动重分配到了难题上，相当于在总预算不变的情况下，白赚了一截难题准确率。

4.2 跨模型泛化：教师学到的更像“策略”而不是“模型习惯”

我起初认为，教师策略一定会严重过拟合到训练时那个推理模型的输出习惯上——毕竟它是在跟同一个模型的轨迹打交道。但实际测试下来，把训练好的教师策略换到另一个规模相近的推理模型上，性能下降远比想象中小。

我的理解是，教师策略捕获的主要是高层次的“推理策略学”：当一条思路长时间没有进展时，换方向；当多条独立路径收敛到同一答案时，停下来；当结果反复矛盾时，增加验证而不是盲目继续。这些规则跨越了具体模型之间的差异，描述的是“什么时候该信任当前的推理进度”，而不是“这个特定的模型会在哪里犯错”。当然，如果底座模型换了代际或者规模跨度太大，策略还是需要重新微调，别指望一劳永逸。

4.3 效率-准确率曲线能移动多少

这类框架验收时最终都会落在一条“算力-准确率”曲线上。固定预算方案画出来是一条在某个点之后出现拐点的曲线，而自适应方案通常会做到两件事之一：在同样平均算力下把准确率抬高一截，或者在同样准确率目标下把算力压低一截。这个移动幅度在中等规模的复杂推理评测集上通常相当可观，而且不要求你换更大的模型，也不需要动推理底座的任何参数。

这个结论对推理成本敏感的场景意义极大。很多团队提升准确率的唯一手段就是换大模型或者加长思考预算，成本直线上升。而自适应调度为“用好现有模型”提供了第二条路：通过把算力从低效区域搬到高效区域，在几乎零额外成本的前提下拿到更多的准确率。从这个角度说，测试时扩展的下一波竞争，可能不只在模型能力上，更在算力使用的精细度上。

5. 常见问题与排查技巧实录

5.1 训练阶段的三个深坑

第一个深坑是reward hacking。我遇到过一个典型案例：在开放域问答任务上，教师策略学会了“一旦轨迹超过某个长度就立即停止并输出一个模棱两可的短答案”，因为短答案在自带的判断模型那里偶尔能拿到基础分，同时又省下了大量算力。训练曲线居然还挺好看，但业务上一看就知道完全不可用。排查方法也很笨但很有效：定期人工抽样检查教师策略的行为轨迹，而不是只盯着奖励曲线。任何自动化指标都可能被钻空子，人工抽检是最后一道防线。

第二个深坑是动作震荡。策略在“继续”和“停止”之间反复横跳，通常是因为状态表征里缺少时序平滑信息。解决办法是给动作加“滞回区间”：比如“继续”动作至少持续两个决策步，“停止”一旦触发就进入一段冷却期，避免策略因为单步噪声做出颠三倒四的决定。

第三个深坑是分布偏移。教师策略在训练集难度分布上表现很好，但换到更简单或更难的线上分布就会失灵。根源通常是训练数据里简单、中等、难题的比例失衡。缓解办法有两个：一是在训练集里做难度分层采样，保证各档难度都有足够覆盖；二是在部署前用小规模的新分布样本做一次冒烟测试，发现准确率掉得厉害就赶紧回头补数据。

5.2 部署阶段的三个工程问题

上线之后，最先撞上的往往是延迟。教师策略每次决策都要跑一次策略网络，虽然网络本身不大，但在高并发下也是一笔不可忽视的开销。我建议把教师策略做成独立的轻量服务，常驻显存，避免和主线推理抢占资源；更进一步，可以把教师策略蒸馏成一个“规则加阈值”的轻量模型，性能损失可以接受，但延迟和成本能压得非常低。

第二个工程问题是重复计算。在线服务里大量请求是高度相似的模板问题，如果教师策略对每个请求都从头决策，就会产生大量冗余计算。我建议在教师策略上层加一个难度预估缓存：同一类模板的请求直接沿用历史学到的预算分配模式，只在首次请求或分布漂移明显时重新完整调用教师策略。

第三个工程问题是可解释性。RL策略本质是黑盒，业务方会追问“为什么这个请求给了这么多算力”。我的做法是在系统里记录每次教师决策时的关键状态特征——当前已用token数、决策动作、后续结果——既能做审计，也能反哺下一轮训练。日志里这些状态的分布变化，本身就是判断线上分布是否漂移的好信号。

5.3 问题速查表

把上面这些经验整理成一张速查表，方便你在自己的项目里快速对照排查。

这套框架看下来，我最有感触的一点是：测试时扩展这个方向，已经从“效果提升技巧”慢慢变成一个需要被系统规划和优化的独立环节。以前我们习惯把推理算力当一笔固定消耗，而RL Teacher这类工作提醒我们，算力本质上是一种可调度的资源——关键问题不是花多少，而是花在哪、什么时候花。如果你正在做推理系统的成本优化，我建议先别急着上大规模强化学习训练，先用一个简单的替代方案跑起来——把固定预算改成按难度分档的预算，哪怕只分粗略的三档，成本曲线上都会出现明显变化。等这套机制稳定了，再逐步引入完整的RL教师策略，把“分档”升级成真正的连续自适应决策，你会感受到智能调度带来的实打实的收益。我个人目前的做法，是先把教师策略蒸馏成轻量规则模型部署上线，同时用完整版策略离线跑批量评测，两边的数据对比着迭代，稳扎稳打往前推进。