← 返回 PaperDaily
大模型与智能体
给OPD换老师不再怕跑偏，英伟达新方法让数学代码双提升
跨教师蒸馏这个大坑，英伟达来填了！Lightning OPD 2.0用交叉拟合把“风格噪音”从token级信号里剥离，让换更强的教师也有稳定收益，数学推理AIME 2024直接冲到82.4%。
龙哥读论文
发布于 2026-08-14 09:12:02
阅读 4
查看原文
原论文信息如下：
如果给大模型换一个更强的老师，学生的成绩反而更差，你信吗？
跨教师蒸馏的痛点：为什么“教师一致性”是天花板？ 先交代一下背景。大模型训练到 SFT 之后，还会继续“上课”，这堂课叫在线策略蒸馏（On-Policy Distillation，简称 OPD）。OPD 的流程很像师徒制：学生模型自己生成一段回答，然后由一个更强的教师模型给这段回答的每一个 token 打分，告诉学生“这个 token 说得对，那个 token 说得不对”。这种逐 token 的密集监督，比单纯给一个最终分数要细致得多，训练稳定性也更好，因而成为推理模型后训练中一个性价比很高的选择。
但这里藏着一个很容易被忽略的“潜规则”——教师一致性（Teacher Consistency）
不巧的是，真实工程场景里，教师一致性恰恰很难满足。一方面，很多 SFT 数据的来源早就说不清了，可能由好几个模型混合生成，根本找不到一个“原始数据老师”；另一方面，即使知道数据是谁生成的，换一个更强的老师来做 OPD，往往需要重新生成演示数据、重新做 SFT，成本高得吓人。更核心的问题在于：最适合生成 SFT 数据的模型，和最适合做 OPD 打分教师的模型，未必是同一个。让一个更强的模型去生成演示数据、再让另一个更合适的模型去当 OPD 老师，才是更合理的分工。
于是问题来了：一旦跨教师（cross-teacher）设置，OPD 的效果就肉眼可见地崩。哪怕新老师比原来的老师更强，学生对齐后成绩反而可能下降。这就是英伟达这篇新论文要处理的刚性约束。
风格偏差：被忽视的token级噪音 为什么换一个更强的老师，效果反而更差？论文仔细拆解了教师的打分信号，发现回答里的 token 其实分两类。
第一类 token 承载着真正的推理内容，比如“这里应该代入公式”“这一步推导方向错了”。如果教师给这类 token 打低分，那是在提供有价值的纠正信号。第二类 token 则纯属“风格层”的表达差异，比如换一种措辞、换一个连接词、多写两行推导过程、改变一下格式排版。这些token本身没有对错，教师打低分仅仅是因为“我不喜欢这么说话”。
麻烦在于，OPD 的目标函数面对这两种 token 一视同仁：只要教师概率低，就把梯度怼上去。跨教师设置下，风格差异会成片出现，累积的“风格惩罚”远比零散的推理纠错信号更密集，于是训练信号被严重带偏。
那怎么把这两种信号分开？论文提出了一个非常巧妙的操作化假设：风格偏差是可预测的，推理信号是不可预测的。
这里需要解释一个概念：意外度（Surprisal）
Lightning OPD 2.0：交叉拟合给风格“瘦身” 接下来看方法论。Lightning OPD 2.0 是在前作 Lightning OPD 基础上的升级。前作的核心贡献是离线化：把学生 rollout 和教师打分一次性预计算缓存，训练时不再需要实时跑教师模型，大幅降低系统开销。但前作有一个前提，就是教师一致性。2.0 的使命，就是把这个前提解耦掉。
给定一个缓存 rollout，设教师模型对第 t 个 token 的打分为 ℓᵀ_ᵢₜ，参考模型打分为 ℓᴿ_ᵢₜ。两者的差 d_ᵢₜ = ℓᵀ_ᵢₜ − ℓᴿ_ᵢₜ 被称为教师-参考分歧。初始状态下学生模型就是参考模型，这一项会直接进入训练优势函数。问题在于，d_ᵢₜ 里既有推理信号，也有风格偏差。
论文把 d_ᵢₜ 做了一次分解：d_ᵢₜ = b(z_ᵢₜ) + v_ᵢₜ。其中 b(z_ᵢₜ) 是“在相同坐标 z 下反复出现的分歧”，v_ᵢₜ 是剩余的部分。坐标 z 由两类信息构成：一是 token 身份本身，也就是“这个词本身是否被老师偏爱”；二是粗粒度上下文，即归一化响应位置加上参考模型的意外度 bin。这种拆分是一种操作化代理，目的是让风格偏差可以被估计出来。
估计方法采用交叉拟合（Cross-Fitting）
交叉拟合在这里的核心作用是防止自拟合。如果直接用当前 rollout 的数据估计其自身的风格偏差，很容易把推理信号也吸收进去。通过 K 折切分，当前 rollout 不会参与自己那折的统计，从而保证估计出的偏差确实是“其他回答里也反复出现的模式”。同时，等权平均 token 表和上下文表的预测，能避免单一坐标维度把数据切得过碎，保持估计的稳定性。
最终训练时，把残差化后的分歧放回 Lightning OPD 的优势函数：A_res(θ) = ℓᵀ_ᵢₜ − ̂b_ᵢₜ − log π_θ(y_ᵢₜ | h_ᵢₜ)。这个形式非常优雅：相当于把教师打分“修正”成了 ̃ℓᵀ_ᵢₜ = ℓᵀ_ᵢₜ − ̂b_ᵢₜ，再去计算标准的 OPD 更新。整个过程离线一次性完成，训练期间没有任何额外开销。
实验结果：数学与代码双丰收 论文在两种典型的跨教师设置下做了验证。第一种从 Qwen3-4B-SFT 出发，该模型的 SFT 演示数据由 Qwen3-8B 生成；第二种从 Klear-Reasoner-8B-SFT 出发，它的 SFT 数据源自 DeepSeek-R1-0528 蒸馏得到的思维链数据。两种设置统一选择 Qwen3-30B-A3B-Thinking-2507 作为跨教师 OPD 教师，教师与学生来自完全不同的训练管线，这更贴近真实生产环境。
训练数据方面，数学用 DAPO-Math-17k，代码用 KlearReasoner-CodeSub-15K，每个 prompt 从 SFT 参考模型采样一条回答并缓存教师打分。对比基线包括：不训练的 SFT 参考模型、原始 Lightning OPD、以及两个针对性 baseline——IW-OPD（按累积差异给 token 加权）和 TA-OPD（预测可学习位置）。所有方法共用同一份 rollout 和教师打分缓存，训练预算一致。
*表格超出部分左右可以滑动
设置
方法
数学平均 Pass@1 (%)
代码平均 Pass@1 (%)
Qwen3-4B-SFT
SFT reference
48.3
32.6
Qwen3-4B-SFT
Lightning OPD
48.6
34.3
Qwen3-4B-SFT
IW-OPD
48.2
35.5
Qwen3-4B-SFT
TA-OPD
45.6
33.1
Qwen3-4B-SFT
Lightning OPD 2.0
51.7
35.7
Klear-8B-SFT
SFT reference
73.6
54.9
Klear-8B-SFT
Lightning OPD
73.6
57.1
Klear-8B-SFT
IW-OPD
73.9
57.4
Klear-8B-SFT
TA-OPD
73.9
57.6
Klear-8B-SFT
Lightning OPD 2.0
74.6
58.5
表1：两种跨教师设置下数学推理与代码生成的 Pass@1 平均结果。蓝色行为 Lightning OPD 2.0。
在 Qwen3-4B 场景下，原始 Lightning OPD 几乎在 SFT 基础上升不上去（数学 48.3→48.6，代码 32.6→34.3），这正是跨教师 mismatch 的典型症状。而 Lightning OPD 2.0 直接把数学平均拉到 51.7，代码平均拉到 35.7，相比 Lightning OPD 分别提升了 3.1 和 1.4 个点。在 Klear-8B 场景下同样稳定提升，数学平均 74.6，代码平均 58.5。
值得注意的细节是，在 Klear-8B 设置下，三个基线方法（Lightning OPD、IW-OPD、TA-OPD）都只能在代码任务上有微弱提升，数学任务上基本原地踏步甚至略有退步。Lightning OPD 2.0 是唯一一个在五个 benchmark 上全部超过 SFT 参考的方法。从 Klear-Reasoner-8B-SFT 出发，2.0 在 AIME 2024 上达到 82.4%，在 LiveCodeBench v5 上达到 63.0%，刷新了该设置下的新纪录。
为什么残差化能带来这么一致的提升？论文做了一项机制分析：把残差化前后的训练信号，与“教师一致时”的理想信号做对比。结果发现，原始分歧中很大一部分绝对偏差来自风格 token 的重复性分歧；残差化之后，训练信号与教师一致场景下的信号显著更接近。这说明 2.0 确实在做“减噪”，而不是简单地对所有分歧都打折扣。
加上 Lightning OPD 系列本身的离线缓存设计，训练期间不需要实时跑教师模型，30B MoE 级别的教师在单节点 8 张 H100 上也能轻松搞定。这种成本优势，配合跨教师解耦带来的模型选型自由，让 Lightning OPD 2.0 的产品化潜力比大多数蒸馏方法都要实际。
总结与展望 Lightning OPD 2.0 的核心价值在于：它用交叉拟合的查表法，把“跨教师 OPD 效果崩坏”这一普遍问题归因于风格偏差，并给出了一个训练零额外开销的修正方案。教师一致性不再是必要条件，SFT 数据生成器和 OPD 教师可以独立选型——这两点对工业界落地非常有吸引力。方法本身不依赖特定的教师或学生架构，只要 tokenizer 兼容，就能直接套用。
当然，方法也有明显的边界。风格偏差的估计只是操作化代理，不是真正的语义标签；如果某个推理缺陷恰好在相似位置反复出现，有可能被误当成风格偏差减掉。另外，tokenizer 不兼容的师生组合目前仍无法直接处理。未来如果能把风格分布建模得更加细粒度，或者引入可学习的残差权重，这个框架还有进一步扩展的空间。
龙迷三问 什么是 OPD？和 SFT 有什么区别？
为什么要用交叉拟合，而不是直接计算风格偏差？
这个方法能直接用到不同 tokenizer 的模型上吗？
如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~
龙哥点评 论文创新性分数： ★★★★☆
把教师一致性这个隐性约束摆上台面，并用交叉拟合查表的方式剥离风格偏差，思路新颖、实现轻量，相比前作是实打实的增量创新。实验合理度： ★★★★☆
两组跨教师设置覆盖了“已知来源”和“混合未知来源”两种典型场景，对比基线控制在同一 rollout 和同一训练预算下，公平性较好。若能在更多教师组合上验证会更有说服力。学术研究价值： ★★★★☆
打破了“OPD 必须教师一致”的惯例，为跨教师蒸馏提供了一种可解释的诊断框架，对后续研究有较强的启发意义。稳定性： ★★★★☆
在两个不同规模的模型、两个不同来源的 SFT 初始化上均稳定提升，表现出一致的稳健性。对数据量和 fold 数量的敏感度仍需进一步探索。适应性以及泛化能力： ★★★☆☆
对同 tokenizer 的师生组合泛化良好，但跨 tokenizer 场景仍无法处理，通用性受限。硬件需求及成本： ★★★★☆
风格残差化只发生在离线预计算阶段，训练时零额外开销；结合 Lightning OPD 的离线缓存，单节点 8×H100 即可完成 30B MoE 蒸馏，成本友好。复现难度： ★★★★☆
代码将以开源形式发布，方法实现简单，主要依赖 token 查找表和上下文查找表，复现门槛低。产品化成熟度： ★★★★☆
离线设计天然适配现有训练管线，只需在缓存阶段多一步查表校正，几乎不增加工程复杂度，具备较好的落地潜力。可能的问题：
风格偏差的 proxy 定义可能把“反复出现的推理错误”误判为风格；实验规模只覆盖了两组设置和三类 benchmark，跨领域泛化能力需要更多验证。论文缺少对 fold 数、bin 数等超参数的敏感性分析。此外，方法基于离线缓存，如果 rollout 分布与最终部署分布差异较大，校正效果可能衰减。主要参考文献
Wu Y, Han S, Cai H. Lightning OPD 2.0: Mitigating Style Bias in Cross-Teacher On-Policy Distillation for Large Reasoning Models. arXiv:2607.28449v1, 2026. Agarwal R, et al. On-Policy Distillation for Reasoning Models. 2024. Lu and Lab. On-Policy Distillation for LLM Post-Training. 2025. Yu et al. DAPO: An Open-Source LLM Reinforcement Learning System at Scale. 2025. DeepSeek-AI. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. 2025. Kwai-Klear. KlearReasoner: Model and Data. 2026. Xie et al. IW-OPD: Importance-Weighted On-Policy Distillation. 2026. Wang et al. TA-OPD: Learnability-Aware Token Selection for On-Policy Distillation. 2026. *本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～ 想了解更多原文细节的小伙伴，可以点击 "阅读原文"， 查看更多原论文细节哦！
