EAGLE 3.1：修复LLM推理中注意力漂移的推测解码算法

推测解码是一种加速大型语言模型推理的技术，通过一个小型快速的起草模型预先提出多个令牌，再由大型目标模型并行验证。如果接受，推理速度提升；若拒绝，系统优雅回退。

EAGLE团队、vLLM团队和TorchSpec团队此前推出了EAGLE系列算法（EAGLE 1、2、3），该系列已成为研究和生产系统中最广泛采用和部署的推测解码算法之一。今天，该家族迎来了针对性可靠性升级——EAGLE 3.1。

问题所在：当使用不同聊天模板、长上下文输入或分布外系统提示时，推测解码性能会下降。EAGLE团队将这一脆弱性归因于一种称为“注意力漂移”的现象：随着推测深度增加，起草模型逐渐将注意力从原始上下文（固定令牌）转移到自身生成的令牌上。简言之，起草模型开始关注自身之前的输出而非原始上下文，导致接受长度和输出稳定性下降。

更深层原因有二：首先，融合输入表示变得不平衡，高层隐藏状态主导起草模型输入；其次，由于未归一化的残差路径，隐藏状态幅度在推测步骤中不断增长。两者共同导致起草模型在深度推测时稳定性降低。

EAGLE 3.1的解决方案：两项关键架构改进。第一，FC归一化——在每个目标隐藏状态之后、FC层之前应用归一化，保持隐藏状态幅度有界。第二，归一化后隐藏状态反馈——将归一化后的隐藏状态送入下一步解码，使起草模型的行为更接近递归调用，而非简单附加层。

基准测试结果：与EAGLE 3相比，EAGLE 3.1在训练到推理的外推能力、长上下文鲁棒性、对不同聊天模板和系统提示的适应性以及跨多样化服务环境的接受长度稳定性方面均有提升。在长上下文任务中，EAGLE 3.1的接受长度比EAGLE 3提升高达2倍。

训练基础设施：TorchSpec现为EAGLE 3.1和未来推测解码算法提供高效训练支持。基于TorchSpec和vLLM，研究团队还训练并开源了用于Kimi K2.6的EAGLE 3.1起草模型（HuggingFace上可用），展示了真实服务模型上的部署范例。

vLLM集成：EAGLE 3.1以配置驱动的方式扩展了vLLM中现有的EAGLE 3实现，包括FC归一化支持、归一化后隐藏状态反馈以及去除对目标隐藏状态的硬编码假设。完全向后兼容现有EAGLE 3检查点——EAGLE 3.1起草模型可直接通过相同的推测解码代码路径使用。

部署示例（vLLM v0.22.0）：

vllm serve nvidia/Kimi-K2.6-NVFP4 \
--trust-remote-code \
--tensor-parallel-size 4 \
--tool-call-parser kimi_k2 \
--enable-auto-tool-choice \
--reasoning-parser kimi_k2 \
--attention-backend tokenspeed_mla \
--speculative-config '{"model":"lightseekorg/kimi-k2.6-eagle3.1-mla","method":"eagle3","num_speculative_tokens":3}' \
--language-model-only

基准测试（Kimi K2.6，SPEED-Bench代码数据集，GB200 TP=4）：并发数1时每用户输出吞吐量提升2.03倍；并发数4时提升1.71倍；并发数16时提升1.66倍。

关键要点：EAGLE 3.1修复了注意力漂移问题；两项架构改进稳定起草模型；长上下文接受长度提升2倍；吞吐量提升显著；完全向后兼容；已合并至vLLM主线，v0.22.0发布。技术详情可查阅官方博客，欢迎关注团队推特、加入Reddit社区或订阅新闻通讯。