在线蒸馏(on-policy distillation,OPD)有个怪现象困扰着不少团队:学生模型明明答对了,却怎么也停不下来。9 月 17 日挂上 arXiv 的论文(arXiv:2609.20511,微软联合 UNC 团队,30 页)给出意外定位——问题多半不在 reward、不在数据,而在几乎没人检查的细节:师生双方的 EOS 终止 token 对不上。
症状:答案正确,然后狂写废 token
一条 Qwen3 rollout 在第 1,094 个 token 就写出了正确答案,随后又生成 7,098 个冗余 token;另一条在第 462 个 token 答对,然后把 8,192 token 预算的 94% 花在重复标点上。答案是对的,评分是对的,但几乎整段生成都是浪费。
且这不是个别样本,而是训练的收敛方向:200 次更新后,平均回复长度一路爬满 token 预算,被截断(从未主动终止)的回复比例接近 100%,换 prompt 模板也一样。
病根:终止概率压在采不到的 token 上
作者测量了症状对应的那个量:在学生实际停下的位置,它给「停下」分配了多少概率。Qwen 学生起初是学会终止的——第 35 步左右终止概率升到约 0.87,随后开始遗忘,到第 150 步,停下的概率与零无异,长度恰在此刻饱和。Llama 和 Gemma 则从未学会。
机制上:base 学生把一个 token 当作终止符,而 post-trained 教师在另一个 token 上结束回合——Qwen 对里是 <|endoftext|> 对 <|im_end|>,Llama 对是 1 个终止 id 对 3 个。教师确信回合该结束,但这份置信落在 base 学生解码器永远采不出的 token 上——既不进 rollout、也拿不到梯度;学生能发出的终止 token 又得不到教师支持。「停」成了目标函数无法奖励的动作,只剩「继续」。
修复:把「停」当一个语义动作
对齐解码停止集本身是不够的——论文专门验证了这一点。真正起效的是把师生功能等价的 EOS token 聚合成一个语义停止动作来监督(EOS_MODE=semantic_class)。修复后长度膨胀直接反转:Gemma 从饱和 7,168 token 预算、约 100% 截断率,回落到均值约 2,000 token(接近教师在同批 prompt 上的中位数),截断近乎归零;Llama 降到约 3,500-4,000,截断率大约减半。该结论在 Qwen3、Llama 3.2、Gemma 3 三族复现,评测覆盖 AIME24/25 与 AMC23。
没修完的部分与社区反应
修复并非全剧终:K2-Horizon 师生对的 400 步长程实验里,终止对齐后训练后期仍冒出一种独立的长度膨胀——错配是重要来源,但不是全部。代码已开源(github.com/UNCSciML/opd-eos,含 5 种 EOS 条件消融),论文页下有从业者感慨:追了半天的长度膨胀居然可能是 token id 错配而非 reward hacking,「我们一群人可能一直在 debug 错的东西」。
对正在跑 OPD 的团队,论文给的启示是一套诊断顺序:遇到长度失控,先查师生终止 token 对齐(看教师在学生终止位置的概率分布),再怪目标函数、数据或训练 horizon。一个 token 级细节,决定一次蒸馏 run 的大半 token 开销与墙钟时间。