Eagle 3.1：EAGLE团队、vLLM团队和TorchSpec团队之间的合作

# EAGLE 3.1：通过EAGLE团队、vLLM和TorchSpec合作推进推测解码 来源：https://vllm.ai/blog/2026-05-26-eagle-3-1 EAGLE系列——包括EAGLE 1、EAGLE 2和EAGLE 3——已成为研究及生产系统中应用最广泛、部署最普遍的推测解码算法家族之一。 今天，[EAGLE团队](https://github.com/SafeAILab/EAGLE)、[vLLM团队](https://github.com/vllm-project/vllm)和[TorchSpec团队](https://github.com/lightseekorg/TorchSpec)共同推出**EAGLE 3.1**——在推测解码的鲁棒性、效率及可部署性方面迈出的重要一步。 ## EAGLE 3.1 创新点 尽管推测解码在受控环境下表现良好，但在不同的对话模板、长上下文输入或分布外系统提示下，其性能往往会下降。 EAGLE团队将这一脆弱性追溯到一种被称为**注意力漂移**的现象（[论文链接](https://arxiv.org/pdf/2605.09992)）——随着推测深度的增加，草稿模型逐渐将注意力从sink token转移到自身生成的token上。 我们发现了两个根本问题。首先，融合输入表示变得越来越不平衡，因为高层隐藏状态主导了草稿模型的输入。其次，由于未归一化的残差路径，隐藏状态的幅度在推测步骤中不断增长。这些效应共同导致草稿模型在更深层的推测中逐渐变得不稳定。 图1：EAGLE 3 与 EAGLE 3.1 架构对比。EAGLE 3.1 在每个目标隐藏状态后添加了FC归一化，并将归一化后的隐藏状态输入下一个解码步骤。 为了解决这个问题，EAGLE 3.1引入了两项关键的架构改进： - 在每个目标隐藏状态之后、FC层之前，进行FC归一化 - 将归一化后的隐藏状态反馈到下一个解码步骤 直观上，后归一化设计使得该方法更像是在解码步骤之间递归调用草稿模型，而不是简单地在目标模型之上叠加额外层。 这些改进显著提升了模型在各种部署场景下的鲁棒性。与EAGLE 3相比，EAGLE 3.1表现出： - 更好的训练时间到推理时间的外推能力 - 更强的长上下文鲁棒性 - 对对话模板和系统提示变化的更高适应能力 - 在多样化服务环境中更稳定的接受长度 在长上下文任务中，**EAGLE 3.1的接受长度相比EAGLE 3最高提升2倍**。 ## 基于TorchSpec的EAGLE 3.1训练 [TorchSpec](https://github.com/lightseekorg/torchspec)现在为EAGLE 3.1（[合并请求](https://github.com/lightseekorg/TorchSpec/pull/97)）及未来的推测解码算法提供高效的训练支持。 通过降低训练开销并简化实验工作流，TorchSpec有助于加速下一代推测解码研究和部署中的迭代与探索。 基于TorchSpec和vLLM，我们还训练并开源了一个针对Kimi K2.6的EAGLE 3.1草稿模型： https://huggingface.co/lightseekorg/kimi-k2.6-eagle3.1-mla 该模型作为在实际服务模型上使用TorchSpec训练和vLLM服务支持来部署EAGLE 3.1的一个示例。 ## EAGLE 3.1在vLLM中的集成 EAGLE 3.1以[配置驱动扩展](https://github.com/vllm-project/vllm/pull/42764)的形式落地[ vLLM ](https://github.com/vllm-project/vllm)，作为现有EAGLE 3实现的一部分。 集成内容包括： - FC归一化支持 - 后归一化隐藏状态反馈 - 移除关于目标隐藏状态的硬编码假设 同时，与现有EAGLE 3检查点的向后兼容性得到完全保留。因此，EAGLE 3.1草稿模型可以直接通过相同的推测解码代码路径接入，例如： ``` 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 ``` 这使得生产环境中vLLM服务的草稿模型升级变得平滑且简单。 该支持已合并至vLLM当前的主分支，并将通过vLLM的夜间版本以及即将发布的**v0.22.0**版本提供。 作为早期数据点，我们在Kimi-K2.6-NVFP4上使用vLLM（TP=4，GB200，非分离模式）对Kimi K2.6 EAGLE 3.1草稿模型在SPEED-Bench编码数据集上进行了基准测试。EAGLE 3.1在并发数为1时实现了**2.03倍的单用户输出吞吐量提升**，并且随着并发数增加，加速效果依然显著（C=4时为1.71倍，C=16时为1.66倍）。 图2：使用vLLM在Kimi-K2.6-NVFP4（TP=4，GB200）上针对SPEED-Bench编码任务的单用户输出吞吐量（TPS）。EAGLE 3.1-MLA vs. 无推测基线。 ## 跨生态系统的开源协作 EAGLE团队、vLLM团队和TorchSpec团队之间的此次合作，是算法研究、系统优化与训练基础设施之间开源协作的典范。 EAGLE团队持续推动推测解码算法的进步，vLLM帮助将这些创新大规模引入生产推理系统，而TorchSpec则为未来推测解码算法提供了高效的训练和快速实验能力。 我们期望共同继续提升推测解码的整体基线，并在更广泛的LLM生态系统中推动token效率的进一步改进。