EAGLE团队、vLLM和TorchSpec联合发布EAGLE 3.1,修复了推测解码中一个真实的生产bug:随着推测深度增加,drafter模型将注意力从sink token转向自己生成的token,降低了接受长度和输出稳定性。修复是两个架构改动——在每个target hidden state之后、FC层之前应用FC归一化以约束hidden state幅度,加上post-norm hidden state反馈使drafter表现得像递归调用而非附加层。已合并入vLLM main,在v0.22.0中发布,向后兼容现有EAGLE 3检查点。

报告的收益是具体的。在长上下文工作负载上,接受长度比EAGLE 3长达2倍。在Kimi K2.6-NVFP4 SPEED-Bench编码上,每用户吞吐量在并发1时提升2.03倍、并发4时1.71倍、并发16时1.66倍。模式——低并发时最大提升,随并发上升而收窄——是构建者应该期待从任何推测解码收益中得到的:推测解码在模型每请求受限于内存带宽时获胜,这就是低并发的状况。高并发时你受限于聚合吞吐量,推测的赢面更小。发布中没有针对Medusa或vanilla draft-model基线的直接对比,这是要标记的方法论缺口。

生态系统解读寓于集成路径多于数字。EAGLE两年来一直是生产级推测解码家族;vLLM是自托管LLM的默认推理引擎;TorchSpec提供训练端。当三者汇聚于一个用向后兼容的算法变化修复已知不稳定性的发布时,那是推理stack在减少其load-bearing方差,而不是添加功能。Kimi K2.6开源的draft model在HuggingFace上意味着Kimi上的构建者已经有了制品;对其他基础模型,训练端的工作在TorchSpec上。带有不断增长上下文窗口的agentic loops是注意力漂移伤害最大的地方——长agent痕迹、长文件中的代码补全、文档QA——而这些正是2倍接受长度转化为用户可见延迟胜出的工作负载。

如果你在生产中运行vLLM:安排0.22.0升级,并在能力所及时在TorchSpec上重新训练你的draft模型。如果你构建推理SaaS:这是为所有使用你stack的人静默改善长上下文成本曲线的变化。