你训的模型为什么「越训越长」？—— arXiv 2609.20511 找到蒸馏长度膨胀的真正元凶

  • 关联论文：2609.20511

做 LLM 蒸馏的工程师这两年大概都被这个现象折磨过 😩：

用 Qwen3-Instruct 当 teacher，去蒸馏一个 4B student。 SFT 一开始还好，student 输出长度和 teacher 差不多。 训到第 3 个 epoch，student 开始越说越长—— 原本 200 token 能答完的问题，现在能写到 600、800 token； 严重时直接撞到 generation budget 上限，截断、复读、绕圈。 你以为是「学生学到了老师啰嗦的毛病」，把 teacher 换成 concise 版本，重训。 没用——还是越训越长。

这个现象在 On-Policy Distillation（OPD）里有个专名：长度膨胀（length inflation）。业内默认的诊断是「teacher 长 student 也长」，于是改 loss、改 prompt、改采样温度——但根本止不住。

arXiv 2609.20511（When EOS Tokens Disagree）做了件粗暴的事：把长度膨胀从「行为现象」拉回到「机制层面」，给出一个具体、可证伪、可干预的根因——

base student 和 post-trained teacher 虽然声明了相同的「停止集合」（</s>、<|im_end|> 都在停止列表里），但它们实际生成终止信号时落在集合里不同的 token 上。 后果：student 偏好的终止动作被压制，teacher 偏好的替代动作又没学到位——于是既停不下来，又学不好替代停止模式，最后只能靠「多说点」来回避错误。 论文给出修正方案：在 decoding 阶段把功能等价的 EOS token 合并为同一个「语义停止动作」，让 teacher 与 student 之间的概率比较有了 fine-grained 的对齐基础。

对所有走「后训练 teacher 蒸馏小模型」管线的团队来说——这件事 2026 年下半年会改变「为什么我的模型越训越长」的诊断手册。

0 · TL;DR（30 秒版）

arXiv 2609.20511 解决一件具体的事：

在 On-Policy Distillation 训练后期，student 输出越来越长的根因不是「老师啰嗦」也不是「学生没学好」——而是 teacher 和 student 的 EOS 终止 token 在「声明层一致」但「概率层错位」。把功能等价的 EOS 在 decoding 阶段合并为同一个「语义停止动作」，长度膨胀在 Qwen3 / Llama / Gemma 三族上都能得到稳定缓解。

对从业者最直接的工程含义：如果你的蒸馏管线最近遇到了「越训越长」，先别改 prompt 改 reward——画一下 teacher / student 的 EOS 概率热力图，看看是不是 termination-token mismatch。

1 · 痛点：长度膨胀为什么这么难诊断

1.1 算账：长度膨胀到底烧多少钱

蒸馏出来的 student 一般是 1B-8B 规模，部署在客服、代码补全、长文档总结、搜索增强等场景。这类场景的推理成本是按 token 数 × 调用量 算的。

举例：原本平均输出 200 token 的客服模型，越训越长变成 350 token——单次调用成本上升 75%。在百万 QPS 的产品里，这是千万级别的年化算力账。

更糟的是体验侧：用户拿到一个本来该 200 字答完的回复，结果给了一篇 600 字的小作文——该讲清楚的没讲清楚，反而在重复强调已知信息。NPS 下滑比成本上升更难挽回。

1.2 业内默认诊断为何都不顶用

诊断假设 修法 为什么没用
teacher 输出太长，student 模仿了 把 teacher 换成 concise 版本 teacher 短了 student 也跟着短两 epoch，然后又开始膨胀
学生没学会停止，加 stop penalty 在 decoding 里加 length penalty / frequency penalty 数学上能压住长度，但牺牲了正确率——pass@1 掉 2-3 pp
训练数据里长样本太多 重采样，让短样本比例上升 长度膨胀是训练后期出现的，不是数据分布偏差
reward model 偏好长答案 改 reward，加 brevity bonus 影响有效，但只调 reward 不调终止机制等于治标

arXiv 2609.20511 的洞察是：这些诊断都默认了一个前提——「student 停不下来是因为它不会停」。但论文证明：student 会停，但它停的位置和 teacher 不一样——它在另一个等价的 EOS token 上学会了「停」，但训练信号把它压回去了。

1.3 为什么 2026 年这件事变得关键

2026 年 Q3 开始，主流后训练管线（K2-Horizon、Llama-3 instruct、Qwen3 instruct、Gemma-2 IT）都走「多阶段、长周期」的 OPD 蒸馏路径。阶段数从 3 段涨到 7-10 段，阶段漂移工程成本被严重低估——

  • 早期偏好 EOS_A；
  • 中段可能漂到 EOS_B；
  • 后期又可能回头偏 EOS_C。

一次性静态校正不够，理想做法是在每个 stage 重做 termination alignment——但这意味着要在每个 checkpoint 跑一次分布对齐脚本，CI/CD 管线要改。

这件事不解决，多阶段长周期 OPD 就是「训得越久输出越长」的代名词。

2 · 机制：终止 token 错位 + 语义停止动作合并

2.1 终止 token 错位——「集合相同」≠「token 相同」

假设 teacher 声明的停止集合是 T_tea = {</s>, <|im_end|>}，student 声明的也是 T_stu = {</s>, <|im_end|>}。业内默认「停止集合一致 = 终止机制对齐」。

但论文给出一个反例：

T_tea == T_stu    （集合等价）
但
argmax p_tea(t ∈ T_tea) = </s>     （teacher 偏好 </s>）
argmax p_stu(t ∈ T_stu) = <|im_end|>   （student 偏好 <|im_end|>）

集合等价，token 不等价。

后果是双向负面的：

  1. 抑制 student 偏好的终止动作：teacher 在训练信号里给了高概率给 </s>，student 的自然分布更倾向 <|im_end|>，于是在 SFT 信号下 <|im_end|> 的概率被压制。
  2. 没把 teacher 偏好的替代动作可靠传给学生：teacher 用 </s> 停，但 student 的解码器未必把这个信号学到位——结果是 student 既停不下来，又学不好替代停止模式。

论文把这个机制命名为 termination-token mismatch。

2.2 关键修正：把等价 EOS 合并成「语义停止动作」

传统做法只校验「declared stopping set 是否相同」，这是 coarse-grained 的对齐——你只看了集合，没看集合内部的概率分布。

论文的修法是在 decoding 阶段，把功能等价的 EOS 视为同一个「语义停止动作」：

# 伪代码：termination-aware decoding
for step in generation:
    logits = model(...)
    for t in declared_EOS_set:
        if t != canonical_EOS_for(model_family):
            # logsumexp：把等价 EOS 的概率合并
            logits[t] = logsumexp([logits[t_e] for t_e in semantically_equivalent(t)])
        else:
            logits[t] = max([logits[t_e] for t_e in semantically_equivalent(t)])
    next_token = sample(logits)

这一改的核心是：整个等价类塌缩成一个「语义停止动作」上的概率，student 与 teacher 之间的概率比较才有 fine-grained 的对齐基础。

2.3 跨模型族验证 + 阶段漂移观察

论文沿着 K2-Horizon 的训练阶段做追踪，发现两件之前被掩盖的事：

  1. 终止偏好在训练中会显著漂移：早期偏好 EOS_A，到中段可能漂到 EOS_B——意味着一次性静态校正不够。
  2. 训练后期出现独立的长度膨胀：即使做了 termination alignment，OPD run 后期仍残留一种与终止错位无关的长度增长——终止错位是长度膨胀的「重要来源之一」而非全部。

跨模型族验证：Qwen3 / Llama / Gemma 三个族结果同向——不是单一模型现象，是 OPD 范式的通病。

3 · 工程落地与坑点

3.1 三个立刻能用的工程行动

  1. 画 EOS 概率热力图：固定 prompt 集，画 teacher 与 student 在每个 stage checkpoint 上的 EOS argmax 分布。不一致率 ≥1% 就该修。
  2. 插 termination handler 进 OPD loop：在训练侧的 termination step 做一次等价 EOS 合并，比 inference 阶段做更直接（影响 loss signal）。
  3. 加「停止分布一致性」评测指标：把 teacher / student 在固定 prompt 下的 EOS 概率分布差异作为 OPD 训练的健康度检查项——**训完不查这个指标，就不知道模型稳了」。

3.2 三个不能忽视的工程坑点

  1. logsumexp 每步 decoding 引入计算开销：等价类 token 数 N=2（Qwen3 典型）时开销 <5%，可接受；N=4+ 时需做 latency profiling 评估。
  2. teacher 与 student 必须共享 tokenizer 族：跨 tokenizer（teacher=Qwen / student=Mistral）蒸馏时本文方法不直接适用——这是强约束，不是建议。
  3. 静态校正 vs 动态对齐的工程成本被低估：论文建议「每 stage 重做 alignment」，但实际工程中意味着要在每个 stage checkpoint 上跑一次对齐脚本——stage 数 5+ 时，工程开销不小。

3.3 与下游任务的权衡

论文 abstract 没有量化「长度缓解 vs 下游任务质量（pass@k / 正确率）」的权衡。这意味着——

长度降了 20%，但 pass@1 可能掉了 1-2 pp，工程团队无法事前评估「这个 trade-off 值不值」。

建议：在 own 数据集上先做小规模 ablate，再决定是否全量上 termination alignment。

4 · 一句话总结 + 适合谁读

arXiv 2609.20511 把「学生越训越长」从「行为现象」变成「机制问题」——终止 token 错位是长度膨胀的重要来源，对齐停止集合 ≠ 对齐终止机制。

  • ✅ 强烈推荐给：LLM 后训练工程师（OPD / GKD / DPO 蒸馏路径优化者）、推理系统工程师（termination handler / stop token 配置）、RLHF 研究者。
  • ⚠️ 谨慎推荐给：跨 tokenizer 蒸馏团队（需自评扩展方案）、超长序列（≥8K tokens）部署团队（latency 影响待核）。
  • ❌ 不推荐给：纯应用层 LLM 用户、非自回归生成研究者、扩散 / 检索-生成管线工程师（不在论文覆盖范围）。

5 · 来源与待核

  • arXiv：https://arxiv.org/abs/2609.20511
  • GitHub：github.com/UNCSciML/opd-eos（按 abstract 链接）
  • 精修稿：/shared/research-kb/organized/promo/explainers/2609-20511.md
  • 待核 PDF §X：跨模型族长度缓解具体数值、K2-Horizon 阶段百分比、teacher/student checkpoint 版本、终止 handler 延迟、与 KL/RKL/GKD/DPO 对照表。

写作立场：本文基于 paper card + abstract + explainer 精修稿公开内容改写，未下载 PDF / 未跑代码 / 未生成新数据。所有推断已逐条标注 ⚠️，涉及具体数值的均为 abstract 直接给出的内容或论文自报数据，工程落地前请以原 PDF 主表与附录表为准。