很多团队做模型压缩时，都会把在线蒸馏当成一条看起来更省事的路。Teacher不用提前离线跑完整数据集，Student也能边训练边吸收软标签；纸面上少了一次全量推理，预算似乎更友好。⚠️ 真到分布式训练线上，最先冒出来的却常常不是提效，而是Student loss忽高忽低、专项集突然掉点。🎯
根子通常不在蒸馏这个想法错了，而在软标签进入训练图时已经“不新鲜”。多机流水一拉长，Teacher产出的 logits 往往滞后于当前批次的参数代际；再叠加 packing、混合精度和长短样本混训，Student实际学到的，可能是几步之前、甚至不同掩码形态下的旧分布。🔍 这时蒸馏项不是在稳训练，而是在把延迟放大成噪声。🧠
在线蒸馏失效，先看 logits 是不是跨代污染
最常见的坑，是Teacherlogits 与Student前向并不对应同一批有效 token。📦 有些链路为了追吞吐，会把Teacher推理异步化，再把结果塞回后续 step；只要logit delay超过2 - 3个优化步，软标签就可能对应旧温度、旧采样裁剪，甚至旧sequence pack。🛠️ 表面看 batch 没丢，真正丢的是监督时效性。🚨
第二个坑，是 replay 机制只顾节省Teacher计算，没有限制旧样本覆盖范围。很多实现把最近几轮 logits 缓存在队列里，谁先取到就先蒸；可一旦长样本把流水线拖长，短样本就会不断吃到过期监督，KL loss看起来还能下降，验证集却开始在工具调用、结构化输出这类窄任务上退化。📌 在线蒸馏最怕的，不是 teacher 不够强，而是强监督被错误时间窗复用。🔒
一组 34 B 对 7 B 的回放里，决定收敛的是时间窗不是 loss 权重
这次回放的是34 B Teacher -> 7 B Student的指令微调，硬件为16 x H100，序列长度上限8192，任务同时混有聊天、工具调用和代码修复样本。🧪 基线组不做蒸馏；第二组开启朴素在线蒸馏；第三组保留在线蒸馏，但只接受2个 step 内的新 logits，并按样本pack_id做 replay 对齐。📊 结果很直接：蒸馏收益主要取决于监督新鲜度，而不是KL权重调得多激进。✅
| 方案 | 峰值吞吐 | 验证集 loss | 工具调用成功率 | 典型现象 |
|---|---|---|---|---|
| 不做蒸馏 | 218 k tokens/s | 1.94 | 82.1% | 收敛稳，但专项上限有限 |
| 朴素在线蒸馏 | 205 k tokens/s | 1.91 | 79.6% | 总 loss 好看，专项退化明显 |
| 新鲜度门控 + replay window | 211 k tokens/s | 1.88 | 84.3% | 蒸馏收益稳定，退化被压住 |
这组数据最值得记住的地方，是第二组并不是蒸馏强度不够，而是把跨代监督当成了免费增益。📉 当Student学到的是旧 logits，它会在高频 token 上显得更平滑，却在真正需要时序一致性的任务上更脆。把时间窗收紧、把 replay 键从“到达顺序”改成“样本身份 + 代际”之后，收益才开始稳定兑现。🔧
distill_runtime={"temperature":1.8,"max_logit_delay_steps":2,"replay_window":64,"match_keys":["sample_id","pack_id","mask_hash"],"drop_stale_logits":True,"kl_weight":0.25,}生产上应把在线蒸馏当成易腐监督，而不是常驻缓存
更稳的做法，是把Teacherlogits 当成一种有保质期的训练特征来治理。🚧 只要样本跨过 freshness budget，就直接回退到纯监督或局部蒸馏；只要pack_id、掩码哈希或 tokenizer 版本不一致，就不让旧 logits 继续进入Student的损失图。🧭 线上真正该监控的，不只是总 loss，还要盯stale_logit_ratio、distill_hit_rate和专项切片回落。📈
笔者认为，未来3 - 6个月更成熟的训练系统，会把在线蒸馏做成带版本、带时效、带身份校验的监督总线，而不是一个简单的额外 loss。🚀 如果系统回答不了“这批软标签来自哪一代 teacher、命中了哪一批 token、过期后是否被丢弃”，那它大概率还没有真正把蒸馏做成工程能力。你们现在看到的，是蒸馏让 loss 更好看，还是让模型真的更会做事？💬
