一、研究背景与问题
同策略蒸馏(On-Policy Distillation, OPD)是大型语言模型后训练中一种有效方法,通过让学生模型匹配更强教师的token级分布来提升推理能力。但标准OPD存在一个关键瓶颈:训练全程需要在线教师服务器,对每个学生rollout进行评分,导致大量基础设施开销,使大规模实验成本高昂且难以复现。
核心研究问题是:能否在消除在线教师服务器的同时,保留同策略监督的益处?
二、关键发现:教师一致性
作者发现,简单地将教师对数概率离线预计算并重用会失败。根本原因不在于离线近似本身,而在于一个此前被忽视的条件——教师一致性(Teacher Consistency):
OPD涉及两个教师:SFT阶段生成训练轨迹的教师,和OPD阶段提供参考分布的教师
教师一致性要求这两个教师必须是同一个模型
现有流程常违反此条件(如用QwQ-32B生成SFT数据,却用Qwen3-32B做OPD教师)
违反一致性会引入梯度偏差,同时损害离线和在线OPD性能,对离线变体影响更严重
三、方法:Lightning OPD
基于教师一致性原则,作者提出Lightning OPD,一个离线同策略蒸馏框架,包含两阶段:
四、理论分析
论文提供了严格的理论保证(基于四个标准假设):
五、实验结果
性能(表1):
在Qwen3-4B和Qwen3-8B两个规模上,Lightning OPD在数学(AIME 2024/2025、HMMT 2025)和代码(LiveCodeBench v5/v6)基准上达到与标准OPD相当甚至更优的性能
8B规模:AIME 2024达69.9%,LCB v5达49.5%
4B规模:显著超越ExOPD基线(AIME 2024: 68.1% vs 61.0%;LCB v6: 40.3% vs 29.0%)
训练效率(表2):
4B规模:3.6×3.6×加速(72→20 GPU小时)
8B规模:4.0×4.0×加速(120→30 GPU小时)
实际OPD训练仅占小部分预算,其余为一次性离线操作
MoE扩展:
应用于Qwen3-30B-A3B,在单个8×H100节点上达到AIME 2024的71.0%、LCB v5的60.8%
标准OPD在此规模因内存不足不可行,Lightning OPD消除了这一瓶颈
六、与相关工作的区别
与离线RL:离线RL的核心挑战是OOD动作高估和稀疏奖励,需要保守机制;Lightning OPD有密集教师监督,无OOD问题,真正障碍是教师不一致
与离线知识蒸馏:离线KD在教师生成序列上训练,Lightning OPD在学生自身rollout上评估教师信号,保留同策略优势
与Rang等人[26]:后者将SFT和蒸馏视为独立阶段,无教师一致性约束和理论保证;Lightning OPD强调整体设计并提供形式化分析
七、局限性与未来方向
实验局限于数学推理和代码生成,尚未扩展到多轮智能体交互、工具使用、开放式指令遵循等任务
采用新教师时需重新生成SFT数据集,对大型教师模型资源密集,但为一次性摊销成本
核心贡献总结:论文识别了教师一致性这一被忽视的关键设计原则,提出Lightning OPD离线框架,在理论上证明其与标准OPD共享最优解并具有隐式正则化,在实验上实现相当性能的同时带来4.0×训练效率提升,大幅降低了LLM后训练的学术研究门槛。这里是自己的论文阅读记录,感兴趣的话可以参考一下,如果需要阅读原文的话可以看这里,如下所示:
项目地址在这里,如下所示:
摘要:同策略蒸馏(On-policy distillation, OPD)是一种有效的大语言模型后训练范式,但需要在整个训练过程中保持教师服务器在线运行,从而导致大量的基础设施开销。我们研究了OPD是否可以通过在SFT rollout上一次性预计算教师对数概率并在训练期间重用来实现离线化。我们发现,简单地这样做无法可靠地达到标准OPD的效果,并将根本原因追溯到一个此前被忽视的条件,我们将其称为教师一致性(teacher consistency),即要求监督微调和OPD阶段使用同一个教师。违反这一条件会引入梯度偏差,从而降低离线和在线OPD的性能。基于这一洞察,我们提出了Lightning OPD,一个离线同策略蒸馏框架,它强制满足教师一致性并完全消除了对在线教师服务器的需求。我们证明,在教师一致性条件下,Lightning OPD与标准OPD具有相同的最优解,梯度差异有界,并具有隐式正则化效应,有助于防止策略漂移。在数学推理和代码生成上的实验表明,Lightning OPD在达到与标准OPD相当性能的同时,训练效率提高了4.0×。从SFT初始化的Qwen3-8B-Base模型出发,Lightning OPD仅在30 GPU小时内就在AIME 2024上达到了69.9%。Lightning OPD进一步扩展到MoE架构,在单个8× H100节点上将Qwen3-30B-A3B训练到AIME 2024上的71.0%,大幅降低了LLM后训练学术研究的门槛。
图1| (上)Lightning OPD与标准OPD及SFT基线在Qwen3-4B-Base和Qwen3-8B-Base模型上的性能(Pass@1,%)和训练成本对比。Lightning OPD在两个规模上的数学和代码基准测试中均达到与标准OPD相当的性能,同时消除了训练期间对在线教师服务器的需求。在8B规模上,Lightning OPD仅在30 GPU小时内就在AIME 2024上达到了最先进的69.9%,训练效率比标准OPD高4.0×。(下)GPU资源分配的直观对比。标准OPD需要同时托管学生和教师模型,导致GPU资源碎片化。Lightning OPD离线收集rollout和教师对数概率,将所有GPU专用于学生训练。
1. 引言
大语言模型(LLM)在数学推理、代码生成和多步智能体规划等任务上取得了显著进展[1, 2, 3, 4, 5]。这一成功得益于精心设计的后训练流程[6],通常包括在高质量数据上进行监督微调(SFT)[7],随后进行强化学习(RL)阶段以激发更强的推理能力。同策略蒸馏(OPD)[8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18]已成为RL阶段的一种特别有效的替代方案。它使用密集的逐token优势信号训练学生模型以匹配更强教师的token级分布。与可验证奖励强化学习(RLVR)[19, 20, 1, 21]相比,OPD提供更丰富的监督信号、更高的训练稳定性,并且训练成本显著更低,同时在广泛任务上达到有竞争力或更优的性能[9, 22, 10, 14, 23, 5]。
然而,标准OPD需要在训练期间对每个学生rollout进行教师评分,这引入了持续的基础设施瓶颈。一个专用的多GPU教师服务器必须与训练任务并行运行,导致大量的计算开销,使得大规模实验成本高昂且难以复现,特别是对于没有大量服务基础设施的学术研究人员而言。
一个自然的问题是:能否在消除在线教师服务器需求的同时保留同策略监督的益处?同策略训练由学生当前的rollout分布定义,该分布在每个梯度步骤都会演变,使得教师似乎不可或缺。然而,最近的实证研究表明,经过RL训练的模型与其SFT初始化之间保持着惊人的接近:RL模型中的推理轨迹在很大程度上是SFT模型中存在的轨迹的重新加权子集[24],而同策略更新本质上偏向于最小化与参考策略KL散度的解[25]。我们在OPD训练中观察到类似现象,学生的分布在OPD阶段相对于SFT参考仅表现出适度的漂移。这一观察表明了一种实用的离线替代方案[26]:在训练前对SFT rollout一次性预计算教师的对数概率,并在整个OPD过程中重用这些值,从而消除对在线教师服务器的需求。
然而在实践中,简单地应用这种离线预计算无法可靠地匹配标准OPD的性能。在探究根本原因时,我们发现问题的根源主要不在于离线近似本身,而在于此前OPD工作中被忽视的一个更基本的条件,我们将其称为教师一致性。与RLVR中模型行为仅由奖励信号塑造不同,OPD涉及两个不同的教师:一个在SFT阶段用于生成训练轨迹,另一个在OPD阶段用于提供参考分布。教师一致性要求这两个教师是同一个模型。在实践中,现有流程往往遵循从RLVR继承的惯例而违反这一条件,即SFT数据集使用能产生最高质量演示的教师来整理,而不考虑OPD阶段使用的教师。例如,Thinking Machines Lab [9]在OpenThoughts-3 [7]上训练Qwen3-8B-Base模型,其轨迹由QwQ-32B生成,而使用Qwen3-32B作为OPD教师,导致了一种我们的分析预测为有害的不匹配。我们表明,这种教师不一致会引入梯度偏差,降低离线和在线OPD的性能,且对离线变体的影响更为显著。这些发现确立了教师一致性作为任何OPD流程的重要设计原则,而非仅针对离线设置。
在教师一致性被确立为关键条件后,我们提出了Lightning OPD(Lightning On-Policy Distillation),一个由强制这一原则自然产生的离线蒸馏框架。在SFT阶段,基础模型在由选定教师πT生成的轨迹上进行微调,以获得参考策略πref。在OPD阶段,πref采样rollout,并对这些固定响应一次性预计算同一教师的对数概率,消除了训练期间对在线教师服务器的需求。我们提供了严格的理论分析,表明在教师一致性条件下,Lightning OPD可证明与标准OPD具有相同的最优解。此外,两者之间的梯度差异在整个训练过程中保持有界,且离线目标引入了隐式正则化效应,自然地防止策略漂移,无需任何显式惩罚。
3. 方法
3.1. 预备知识
3.2. Lightning同策略蒸馏
遵循LLM后训练的常见实践[6, 1],Lightning OPD包含两个阶段。我们下面描述每个阶段,并强调Lightning OPD与标准OPD的不同之处。
3.3. 理论分析
所有证明推迟到附录A。分析基于三个标准假设,第四个用于教师不匹配分析。
4. 实验
4.1. 实验设置
模型。我们在Lightning OPD流程下训练两个学生模型,覆盖Qwen3模型家族[22]的不同模型规模。第一个使用Qwen3-4B-Base作为学生,Qwen3-8B作为教师。第二个使用Qwen3-8B-Base作为学生,Qwen3-32B作为教师。两个流程均遵循第3.2节描述的两阶段过程。基础模型首先在教师生成的轨迹上微调以获得πref,然后用于采样rollout并为OPD阶段预计算教师对数概率。
训练数据。SFT阶段使用OpenThoughts-3 [7]的提示,响应由各自的教师模型生成。对于OPD阶段,我们在两个领域上训练。数学推理使用DAPO-Math-17k [21],提供17K个涵盖广泛难度的竞赛级数学问题。代码生成使用EpiCoder-func-380k [65]的30K采样子集,提供多样化的函数级代码合成问题。对于每个提示,我们从πref采样单个响应,并在训练前一次性预计算相应的教师对数概率,OPD阶段不需要教师服务器。
基准测试。对于数学推理,我们在AIME 2024 [66]、AIME 2025 [67]和HMMT 2025 [68]上评估。对于代码推理,我们在LiveCodeBench v5和v6 [69]上评估。在所有评估中,我们将温度设为0.6,top-p设为0.95,数学基准的最大生成长度为32,768,代码基准为40,960。数学基准每个问题采样32个解,代码基准每个问题采样4个解,报告平均pass@1。
训练设置。SFT阶段使用LlamaFactory [70]实现,OPD阶段使用slime [71]实现。OPD阶段训练150步,我们发现这足以收敛,如图3b所示。标准OPD和Lightning OPD在OPD阶段共享相同的训练设置,仅rollout来源不同——标准OPD从当前学生在线采样rollout,而Lightning OPD重用训练前从πref预计算的rollout。完整超参数细节见附录B。
4.2. 主要结果
表1展示了两个模型规模(4B和8B)在五个基准测试上的评估结果。核心发现是,Lightning OPD尽管在训练期间完全消除了在线教师服务器,但在所有设置下均达到与标准OPD相当的性能,在某些情况下甚至略有超越。这验证了我们的理论分析,即在教师一致性下,离线近似保持与标准OPD相同的性能最优解。OPD阶段相对于SFT基线的增益在数学和代码基准上均显著且一致,确认了同策略蒸馏提供了强大且可迁移的后训练改进。在4B规模上,与最近的OPD基线ExOPD [10]相比,Lightning OPD取得了显著更好的结果,在AIME 2024上达到68.1%对61.0%,且在代码生成上差距更大,Lightning OPD在LCB v6上达到40.3%对ExOPD的29.0%。在8B规模上,Lightning OPD在AIME 2024上达到69.9%,在LiveCodeBench v5上达到49.5%。这些结果共同证明了Lightning OPD作为跨模型规模和任务领域的通用高效后训练框架的有效性。
4.3. 训练成本
表2比较了标准OPD和Lightning OPD的训练成本。Lightning OPD在4B规模上实现了33.6×的加速,将总GPU小时从72降至仅20,在8B规模上实现了4.0×的加速,将完整流程从120降至仅30 GPU小时。我们还提供了Lightning OPD流程的逐阶段分解。实际OPD训练阶段仅消耗该预算的一小部分,其余成本分配在rollout收集和教师对数概率预计算之间
表1| 数学和代码推理基准上的Pass@1。Lightning OPD在两个模型规模的所有基准上均达到与标准OPD相当的性能,同时训练期间不需要在线教师服务器。在4B规模上,Lightning OPD大幅超越ExOPD [10],在AIME 2024上达到68.1%对61.0%,在LCB v6上达到40.3%对29.0%。在8B规模上,Lightning OPD在AIME 2024上达到69.9%,在LCB v5上达到49.5%。粗体表示每个模型规模内的最佳结果。
| 方法 | AIME 2024 | AIME 2025 | HMMT 2025 | 平均 | LCB v5 | LCB v6 | 平均 |
|---|---|---|---|---|---|---|---|
| 学生:Qwen3-4B-Base,教师:Qwen3-8B | |||||||
| SFT | 56.7 | 52.1 | 34.0 | 47.6 | 33.8 | 31.5 | 32.6 |
| ExOPD [10] | 61.0 | 56.0 | 34.4 | 50.5 | - | 29.0 | - |
| OPD | 65.4 | 57.9 | 39.9 | 54.4 | 44.2 | 39.3 | 41.8 |
| Lightning OPD | 68.1 | 58.4 | 39.8 | 55.4 | 42.8 | 40.3 | 41.5 |
| 学生:Qwen3-8B-Base,教师:Qwen3-32B | |||||||
| SFT | 63.7 | 51.7 | 36.9 | 50.8 | 44.7 | 36.8 | 40.8 |
| OPD | 68.5 | 59.0 | 39.4 | 55.6 | 47.3 | 41.2 | 44.2 |
| Lightning OPD | 69.9 | 59.2 | 41.9 | 57.0 | 49.5 | 43.9 | 46.7 |
表2| 标准OPD与Lightning OPD的训练成本(GPU小时)。Lightning OPD在4B上实现3.6×加速,在8B上实现4.0×加速,分别仅需20和30 GPU小时即可训练推理模型。下方面板按阶段分解Lightning OPD成本,显示实际OPD训练仅消耗总预算的适中部分,突显了Lightning OPD的最小基础设施需求如何使训练高度高效。
| 方法 | Qwen3-4B-Base | Qwen3-8B-Base |
|---|---|---|
| OPD | 72 | 120 |
| Lightning OPD | 20 | 30 |
| 加速比 | 3.6× | 4.0× |
| Lightning OPD分解 | ||
| Rollout收集 | 10 | 10 |
| 教师对数概率预计算 | 2 | 4 |
| OPD训练 | 8 | 16 |
一次性离线操作,不需要专门的基础设施。这与标准OPD形成鲜明对比,后者需要专用的多GPU教师服务器在整个训练过程中持续运行。Lightning OPD的最小基础设施需求使高质量同策略蒸馏对没有大规模训练和服务系统的从业者也可及。
4.4. 扩展到混合专家模型
我们进一步将Lightning OPD应用于Qwen3-30B-A3B-Base,一个具有3B激活参数的30B参数MoE模型,使用Qwen3-30B-A3B-Thinking-2507作为教师。我们遵循与第4.1节8B实验相同的两阶段流程和训练设置。标准OPD在此规模上在单个8×H100节点上不可行,因为同时托管30B学生和30B教师进行训练和评分超出可用GPU内存。Lightning OPD通过离线预计算教师对数概率消除了这一瓶颈,允许所有GPU专用于学生训练。如表3所示,Lightning OPD在AIME 2024上达到71.0%,在LiveCodeBench v5上达到60.8%,在此模型规模的开源MoE模型中达到了最先进的性能。