尧图网页设计 
一、研究背景与问题同策略蒸馏On-Policy Distillation, OPD是大型语言模型后训练中一种有效方法通过让学生模型匹配更强教师的token级分布来提升推理能力。但标准OPD存在一个关键瓶颈训练全程需要在线教师服务器对每个学生rollout进行评分导致大量基础设施开销使大规模实验成本高昂且难以复现。核心研究问题是能否在消除在线教师服务器的同时保留同策略监督的益处二、关键发现教师一致性作者发现简单地将教师对数概率离线预计算并重用会失败。根本原因不在于离线近似本身而在于一个此前被忽视的条件——教师一致性Teacher ConsistencyOPD涉及两个教师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%训练效率表24B规模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模型上的性能Pass1%和训练成本对比。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 OPDLightning 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.6top-p设为0.95数学基准的最大生成长度为32,768代码基准为40,960。数学基准每个问题采样32个解代码基准每个问题采样4个解报告平均pass1。训练设置。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| 数学和代码推理基准上的Pass1。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 2024AIME 2025HMMT 2025平均LCB v5LCB v6平均学生Qwen3-4B-Base教师Qwen3-8BSFT56.752.134.047.633.831.532.6ExOPD [10]61.056.034.450.5-29.0-OPD65.457.939.954.444.239.341.8Lightning OPD68.158.439.855.442.840.341.5学生Qwen3-8B-Base教师Qwen3-32BSFT63.751.736.950.844.736.840.8OPD68.559.039.455.647.341.244.2Lightning OPD69.959.241.957.049.543.946.7表2| 标准OPD与Lightning OPD的训练成本GPU小时。Lightning OPD在4B上实现3.6×加速在8B上实现4.0×加速分别仅需20和30 GPU小时即可训练推理模型。下方面板按阶段分解Lightning OPD成本显示实际OPD训练仅消耗总预算的适中部分突显了Lightning OPD的最小基础设施需求如何使训练高度高效。方法Qwen3-4B-BaseQwen3-8B-BaseOPD72120Lightning OPD2030加速比3.6×4.0×Lightning OPD分解Rollout收集1010教师对数概率预计算24OPD训练816一次性离线操作不需要专门的基础设施。这与标准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模型中达到了最先进的性能。 Lightning OPD: Efficient Post-Training for LargeReasoning Models with Offline On-Policy Distillation
一、研究背景与问题同策略蒸馏On-Policy Distillation, OPD是大型语言模型后训练中一种有效方法通过让学生模型匹配更强教师的token级分布来提升推理能力。但标准OPD存在一个关键瓶颈训练全程需要在线教师服务器对每个学生rollout进行评分导致大量基础设施开销使大规模实验成本高昂且难以复现。核心研究问题是能否在消除在线教师服务器的同时保留同策略监督的益处二、关键发现教师一致性作者发现简单地将教师对数概率离线预计算并重用会失败。根本原因不在于离线近似本身而在于一个此前被忽视的条件——教师一致性Teacher ConsistencyOPD涉及两个教师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%训练效率表24B规模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模型上的性能Pass1%和训练成本对比。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 OPDLightning 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.6top-p设为0.95数学基准的最大生成长度为32,768代码基准为40,960。数学基准每个问题采样32个解代码基准每个问题采样4个解报告平均pass1。训练设置。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| 数学和代码推理基准上的Pass1。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 2024AIME 2025HMMT 2025平均LCB v5LCB v6平均学生Qwen3-4B-Base教师Qwen3-8BSFT56.752.134.047.633.831.532.6ExOPD [10]61.056.034.450.5-29.0-OPD65.457.939.954.444.239.341.8Lightning OPD68.158.439.855.442.840.341.5学生Qwen3-8B-Base教师Qwen3-32BSFT63.751.736.950.844.736.840.8OPD68.559.039.455.647.341.244.2Lightning OPD69.959.241.957.049.543.946.7表2| 标准OPD与Lightning OPD的训练成本GPU小时。Lightning OPD在4B上实现3.6×加速在8B上实现4.0×加速分别仅需20和30 GPU小时即可训练推理模型。下方面板按阶段分解Lightning OPD成本显示实际OPD训练仅消耗总预算的适中部分突显了Lightning OPD的最小基础设施需求如何使训练高度高效。方法Qwen3-4B-BaseQwen3-8B-BaseOPD72120Lightning OPD2030加速比3.6×4.0×Lightning OPD分解Rollout收集1010教师对数概率预计算24OPD训练816一次性离线操作不需要专门的基础设施。这与标准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模型中达到了最先进的性能。