蒸出来的模型为什么话那么多

如果你跑过 on-policy distillation，大概率撞上过这个：学生模型开始生成比老师长得多的回答，有时候长到把整个生成预算烧完都不停。每个人都有一套民间解释。微软研究院和合作者的一篇论文，arXiv 2609.20511，去把真正的原因找出来了，而它比那些民间解释更蠢，也更好修。

问题出在停止符上。一个 base 学生和一个 post-trained 老师，可能把停止概率放在不同的 EOS token 上，哪怕两边声明的 stopping set 完全一致。学生想用 A 这个 token 收尾，老师的分布说概率不在 A 上，于是蒸馏目标就老老实实地把学生从它自己的终止动作上推开，却没能可靠地把老师那个替代动作交给它。结果是学生没有任何一个有把握的收尾方式。于是它就不收尾。

论文证明这在 Qwen3、Llama、Gemma 上都成立，这才是它值得读而不是当成某个 tokenizer 怪癖归档的原因。三个家族，三套词表，同一个失效。而且显而易见的那个修法没用：只对齐解码的 stopping set 不够，因为出问题的情况下两边的集合本来就一样。有用的做法是把功能等价的 EOS token 当成同一个语义层面的停止动作，让目标函数不再因为学生想用自己的方言结束句子而惩罚它。代码已开源。

为什么这该放在一个讲 agent 的站上而不是训练方法站上：长度膨胀是一张账单。任何一个跑在 agent 循环里的蒸馏模型，每步长百分之二十，就是每步贵百分之二十，而 agent 循环的步数很多。蒸馏的全部意义就是拿到一个更便宜的模型，一个悄无声息的终止 bug 能把你当初蒸馏想省的利润吃回去。更糟的是它在准确率 benchmark 上是隐形的。模型最后答对了，只是啰嗦了一点，你的 eval 是绿的，你的推理账单不是。

这也接上了整个月的一个规律。HarnessTax 发现同样任务在不同 harness 上有五倍的成本差。Zoom 的 harness 设计研究量出了此前没人测过的逐组件效应。现在一个 token 级的记账 bug 解释了蒸馏成本的一部分。跑 agent 真正贵的地方，一次又一次被证明是管道而不是智能。论文在 arxiv.org/abs/2609.20511。