分布式训练为什么一做在线蒸馏就开始 teacher 很稳 student 却学不动：从 Logit Delay 到 Distill Replay Window 的工程实战

很多团队做模型压缩时都会把在线蒸馏当成一条看起来更省事的路。Teacher不用提前离线跑完整数据集Student也能边训练边吸收软标签纸面上少了一次全量推理预算似乎更友好。⚠️ 真到分布式训练线上最先冒出来的却常常不是提效而是Student loss忽高忽低、专项集突然掉点。根子通常不在蒸馏这个想法错了而在软标签进入训练图时已经“不新鲜”。多机流水一拉长Teacher产出的 logits 往往滞后于当前批次的参数代际再叠加 packing、混合精度和长短样本混训Student实际学到的可能是几步之前、甚至不同掩码形态下的旧分布。 这时蒸馏项不是在稳训练而是在把延迟放大成噪声。图 1在线蒸馏常见问题不是没标签而是标签到得太晚在线蒸馏失效先看 logits 是不是跨代污染最常见的坑是Teacherlogits 与Student前向并不对应同一批有效 token。 有些链路为了追吞吐会把Teacher推理异步化再把结果塞回后续 step只要logit delay超过2 - 3个优化步软标签就可能对应旧温度、旧采样裁剪甚至旧sequence pack。️ 表面看 batch 没丢真正丢的是监督时效性。第二个坑是 replay 机制只顾节省Teacher计算没有限制旧样本覆盖范围。很多实现把最近几轮 logits 缓存在队列里谁先取到就先蒸可一旦长样本把流水线拖长短样本就会不断吃到过期监督KL loss看起来还能下降验证集却开始在工具调用、结构化输出这类窄任务上退化。 在线蒸馏最怕的不是 teacher 不够强而是强监督被错误时间窗复用。图 2旧 logits 被重复喂给新 batch蒸馏项很容易变成噪声源一组 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/s1.9482.1%收敛稳但专项上限有限朴素在线蒸馏205 k tokens/s1.9179.6%总 loss 好看专项退化明显新鲜度门控 replay window211 k tokens/s1.8884.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,}图 3限制 logits 时效和样本身份比一味加大蒸馏权重更关键生产上应把在线蒸馏当成易腐监督而不是常驻缓存更稳的做法是把Teacherlogits 当成一种有保质期的训练特征来治理。 只要样本跨过 freshness budget就直接回退到纯监督或局部蒸馏只要pack_id、掩码哈希或 tokenizer 版本不一致就不让旧 logits 继续进入Student的损失图。 线上真正该监控的不只是总 loss还要盯stale_logit_ratio、distill_hit_rate和专项切片回落。笔者认为未来3 - 6个月更成熟的训练系统会把在线蒸馏做成带版本、带时效、带身份校验的监督总线而不是一个简单的额外 loss。 如果系统回答不了“这批软标签来自哪一代 teacher、命中了哪一批 token、过期后是否被丢弃”那它大概率还没有真正把蒸馏做成工程能力。你们现在看到的是蒸馏让 loss 更好看还是让模型真的更会做事图 4把在线蒸馏做成新鲜度治理student 才不会被旧监督拖偏