蒸馏大模型时最烦的问题，「老师风格不一致」终于有人给了解法
模型蒸馏有一个常见陷阱：精心挑了一个更强的模型来做 on-policy 蒸馏，结果学生的表现死活提不上去，甚至不如照着 SFT 数据直接跑一版。
问题多半出在「老师」的说话方式上。
MIT 的 Yecheng Wu、Song Han 和 Han Cai 刚放出来的论文《Lightning OPD 2.0: Mitigating Style Bias in Cross-Teacher On-Policy Distillation for Large Reasoning Models》，讨论的就是这个问题。
为什么跨老师蒸馏会翻车
跨老师蒸馏的标准流程是：拿一批数据做 SFT（监督微调），这些数据可能是 GPT-4 写的，也可能是某个开源模型生成的。然后换一个更强的模型来做 on-policy distillation（OPD），在每一步给学生提供 token 级别的密集监督。
理想情况下，学生应该从第二个老师那里学到更好的推理能力。
但实际情况是——如果教 SFT 的老师（A）和做蒸馏的老师（B）不是同一个模型，学生很容易学到的是 B 的措辞、格式、语气、推理节奏这些「风格」，而不是真正的推理逻辑。论文把这叫做 style-token bias——那些被学生误以为是推理信号、实则只是老师个人表达习惯的东西。
这直接导致一个反直觉的结果：OPD 老师明明更强，但学生在 cross-teacher 设置下几乎没比纯 SFT 版本好多少。
解法：把风格信号剥离出去
Lightning OPD 2.0 的核心动作听起来不复杂：先识别出哪些 token 层面的差异是「重复出现的风格信号」，然后把它减掉，剩下的才是真正有用的 teacher-specific 推理证据。
这套方法叫 cross-fitted style residualization，利用 rollout 级别的交叉拟合，把风格成分作为可估计的偏差项剥离出去，再构建 token-level 的 OPD 更新信号。
举个例子：老师 A 喜欢写「Let's think step by step」，老师 B 写「We can approach this by」，而学生面对同一种数学题时在两种表达之间摇摆，这套方法会把这种措辞偏好当作噪声扣除，让学生真正学到背后的推理路径，而不是学谁更像谁。
结果有多硬
论文里给的数字很直接。从 Klear-Reasoner-8B-SFT 出发做蒸馏，用 Lightning OPD 2.0 在 AIME 2024 上拿到 82.4%，在 LiveCodeBench v5 上拿到 63.0%。
这两个 benchmark，一个主攻数学推理，一个主攻代码生成，覆盖了推理模型最核心的两个能力面。8B 这个参数量级意味着它不是靠吞算力硬撑出来的结果，是蒸馏方法本身的提升。
代码还没放出来，论文写了「Code will be released soon」。考虑到作者里有 Song Han（MIT 高效 ML 方向的代表人物，之前 TinyEngine、MCUNet 这些项目都很扎实），这个 release 应该靠谱。
谁该关注这篇论文
只在 API 上调模型的话，这篇论文关系不大。做模型训练、微调、蒸馏的人——也就是要把一个开源基座往特定能力方向反复压榨的人——cross-teacher 风格偏差是每天在碰但不一定叫得出名字的问题。
常见场景有几个：
- SFT 数据是 GPT-4 写的，蒸馏用 Llama 系模型来干——这是最典型的 cross-teacher 场景，因为数据采购和蒸馏选型往往不是同一批人拍板。
- 多轮迭代里换过基座——上一轮的 SFT checkpoint 是用 Qwen 做的，这一轮想切到 DeepSeek 做蒸馏，这时候风格偏移会直接吃掉蒸馏收益。
- 开源蒸馏流程里用了混合来源的 SFT 数据——数据来自不同的标注模型，没有人能确切说清每一条是谁写的。
Lightning OPD 2.0 提供的是一个可以插进现有蒸馏 pipeline 的修正层，不需要重训全套流程。如果已经在跑 on-policy distillation，加一层 style residualization 的边际成本不会太高。
一点保留意见
论文在数学和代码两个 benchmark 上做了验证，但推理模型的评估生态本身还有不少坑——LiveCodeBench 和 AIME 的题目集相对固定，数据污染风险始终存在。style residualization 的参数设置（交叉拟合的折数、rollout 采样策略）对结果有多敏感，论文目前没有展开讨论。
另外，8B 模型的蒸馏成功能不能 scale 到 70B 或更大尺寸，也需要更多实验验证。
这篇论文指出的问题很实际——亲手调过模型的人多半见过「老师教的东西学生学歪了」的案例，style bias 是其中一个被低估的元凶。Lightning OPD 2.0 至少给出了一个干净的、直觉上合理的修正方向。
代码出来后，我会第一时间拉下来在自己的训练流程里试一遍。到时候再来汇报实测体感。