EAGLE-4技术分享：前成员揭秘核心设计与研发细节

2026-10-27 09:16:48

文章摘要

近日，EAGLE-4相关技术内容发布，作为前EAGLE团队成员，结合技术报告的设计思路，聊聊研发过程中的实验与取舍。先介绍研发背景：2025年8月至2026年6月，我在EAGLE团队任职，之后加入Lo

近日，EAGLE-4相关技术内容发布，作为前EAGLE团队成员，结合技术报告的设计思路，聊聊研发过程中的实验与取舍。

先介绍研发背景：2025年8月至2026年6月，我在EAGLE团队任职，之后加入LongCat，目前在Kimi从事MTP/投机解码相关优化工作。团队期间，我主导设计并验证了EAGLE Efficient LM Head的两阶段方案与training-free版本，这也是本次回顾的重点。

本次技术报告聚焦两大核心组件：EAGLE-Harness与EAGLE Efficient LM Head，以下先梳理EAGLE-Harness的设计逻辑，再深入探讨我更熟悉的LM Head部分。

EAGLE-Harness的设计逻辑

EAGLE-Harness是一套用于接入SGLang/vLLM的动态序列解码（SD）相关代码，核心逻辑与DSpark的动态验证机制类似：结合 draft 模型与目标模型的成本、draft 的置信度等因素，动态构建 draft 树并交由目标模型验证。与DSpark的动态验证相比，主要有三点差异：

DSpark仅在已生成的draft块中选择待验证的前缀；而EAGLE是自回归架构，因此Harness额外考虑了draft过程的早停：若继续draft的收益不足以覆盖额外计算开销，可直接停止，无需生成至预设最大深度。
EAGLE-Harness支持draft树结构，无论是早停还是验证前剪枝，均可在draft树场景下实现；而DSpark的动态验证仅针对链结构设计。
两者对期望接受token数的估计方法不同：EAGLE-Harness无需额外训练置信度头，而是复用draft概率并结合启发式规则；DSpark则依赖专门训练的置信度头。

关于EAGLE-Harness，外界常将其视为DSpark-Harness的后续工作，但据团队期间了解，其原型来自前同事Yinrong Hong等人的相关研究（CAST，2025年10月发布于arXiv），即便后续有优化，年初时这套方案已较为成熟。

EAGLE Efficient LM Head的研发过程

接下来聚焦EAGLE Efficient LM Head，这部分方案由我在团队期间设计并验证，以下梳理当时的核心思路。

2025年底，行业已意识到draft模型的LM Head计算成本较高，对于EAGLE这种仅含一层的draft模型，部分配置下LM Head的计算开销占draft模型前向传播的一半左右。

当时主流解决方案是FR-Spec这类方案：按token出现频率裁剪词表，保留低频token占比低的小固定词表，EAGLE-3也采用该方案，通常将词表大小裁剪至32000。

但后续实验发现，将词表从32000恢复至全词表时，接受长度可提升约1，这是非常明显的性能增益。裁剪词表虽降低了LM Head开销，但也损失了draft的预测能力。

基于此，我们思考能否同时兼顾全词表带来的高接受长度，以及LM Head的低成本？当时我尝试了三条技术路线：

1. 直接优化LM Head的计算成本，如采用低秩分解、量化等，直接使用近似后的logits；

2. 两阶段token级方案：第一阶段用低成本方法筛选候选，第二阶段用完整LM Head计算这些候选对应的logits；

3. 两阶段cluster级方案：将token分组（如每组128个），先选择若干组，再计算组内所有token的logits并采样，后续Google Gemma 4也采用了类似思路。

最终我们选择了第二条路线，核心原因是：在当时的测试配置中，仅该方案能做到与完整LM Head相比几乎不损失接受长度；第一条路线的接受长度损失较大，第三条路线也有明显损失。

关于第一阶段的实现，我们试过低秩分解、量化及两者结合，最终综合考量后选择了纯低秩方案，不采用量化。

由此形成了EAGLE Efficient LM Head的核心流程：

第一阶段：用低秩头对全词表做低成本打分，通过Top-k选出候选；
第二阶段：索引完整LM Head中这些候选对应的行，利用原有隐藏状态重新计算logits。

从计算流程看，该方案与DSA类似：先用低成本模块筛选，再对选中部分做完整计算。

我当时绘制了相关示意图，结合图示理解会更清晰。

值得一提的是，该思路在当前时间点并不少见：2026年2月的SpecVocab就提出了几乎相同计算流程的方法，但我们这套两阶段方案在2025年12月就已基本成形。

training-free的优化方案：Freq-aware SVD

与当前技术报告中的版本不同，我们最早使用的是无需额外训练低秩头的方案，命名为Freq-aware SVD，即结合token频率的SVD截断方法。

该方案的核心直觉是：普通截断SVD近似LM Head时，不会区分对应高频token与低频token的行；而实际生成中高频token出现更频繁，因此希望在有限秩下给高频token分配更多近似精度。

具体实现为：先按词频对LM Head的每一行加权，再做截断SVD，最后还原行上的缩放；推理时仍近似原始LM Head，不会直接将词频乘到输出logits上。

设完整LM Head为矩阵，词频权重矩阵为，其近似low-rank分解，被计算为：

其中，是保留前k个奇异值及其对应向量后的结果。词频权重需要做平滑，保证相关计算的稳定性。

这就是我们用来筛选候选的低秩头：给定隐藏状态，直接计算，再取Top-k即可。

该方案仅需统计词频并做一次分解，无需额外训练。尽管技术报告中未提及该版本，但公开代码中仍保留了对应实现。

有意思的是，直到我离职，团队仍在使用这个training-free方案：在当时测试的模型与配置中，它能做到几乎不损失接受长度；同时我们也试过一些简单的训练策略，如SVD初始化后再训练，但结果要么打平，要么不如training-free版本，因此没有动力继续优化。

从EAGLE-4的技术报告来看，后续版本通过训练低秩候选头获得了收益：报告中固定drafter其余部分，单独训练低秩头的两个因子，这是后续的进展。

基于Local Top-k的高效变体

团队当时还尝试了一个更高效的变体。

原方案虽减少了矩阵乘法开销，但第一阶段仍需将全词表的近似分数写入HBM，再读出做全局Top-k，这部分开销在当时的实现中也不小。

原流程大致为：

u = B @ h
scores = A @ u       # 全词表分数写回HBM
ids = topk(scores, C).indices  # 再读出来做全局Top-k
logits = W[ids] @ h

因此我们尝试将全局Top-k改为局部Top-k，直接融入矩阵乘法的tile计算中：

u = B @ h
# 概念伪代码：每个GPU program处理一个词表tile
parallel_for tile in vocab_tiles:
    scores = A[tile] @ u   # 完成rank维累加，分数留在片上
    local_ids = topk(scores, k_tile).indices
    store(candidate_ids[tile], tile.token_ids[local_ids])
ids = concat(candidate_ids)  # 总候选数约为tile数 × k_tile
logits = W[ids] @ h

该思路与Google的分桶近似Top-k类似，将局部筛选与矩阵乘法融合：每个tile仅保留少量候选，将选中的token索引写出，再合并各tile的候选交给第二阶段完整LM Head重算，可省去全量近似分数的HBM写回及全局Top-k操作。

该方法无法保证选出与全局Top-k完全一致的候选，若重要token集中在同一tile，可能被候选名额挤掉；但在当时测试中，接受长度几乎未损失，下降幅度在0.05以内。

还有一个关键细节：最好先打乱词表行的顺序再做局部Top-k。当时发现，按原词表顺序分块会影响候选召回，打乱后分块的召回率明显提升，Graphcore的相关研究也讨论过随机重排对召回的改善作用。

EAGLE-3.1的归一化改进

顺便聊聊EAGLE-3.1，EAGLE-4继承了其中两项归一化改进：FC Norm与Post-norm。

先说FC Norm：它的位置是，取出目标模型的几层隐藏状态后，分别做RMSNorm，再拼接起来过全连接层（FC）。

该方案由我和前同事Haochen Gu在训练GPT-OSS的draft时发现：我们注意到目标模型的隐藏状态经过FC后，输出的隐藏范数很大，因此尝试在FC前加入归一化。当时实验显示，加入后训练收敛更快，训练准确率提升约2个百分点，因此保留下来。

EAGLE-3.1发布后，有人讨论FC Norm的作用有限，我们当时也观察到：它确实比较依赖模型，并非在所有模型上都有明显提升。至少在我们的实验中，它在GPT-OSS上有效，但换到其他模型后差异不明显。

不过，我们未观察到加入后效果劣化的情况，因此个人倾向于保留：有的模型能获得一定收益，有的模型基本打平。当然，这只是当时的实验经验，“加上总没坏处”不能作为普遍结论。

另一项是Post-norm：简单来说，就是将经过输出RMSNorm的隐藏状态传给下一个draft步骤，避免未归一化的隐藏在递推中不断累积范数。这部分并非我主导，相关内容在Attention Drift的论文中已有详细阐述，感兴趣可直接阅读原文，此处不再展开。

关于发布时间的讨论

最后聊聊大家可能好奇的问题：既然EAGLE-Harness与Efficient LM Head很早就已成形，为何现在才公开？

据我在团队期间的体感，当时大家没有太强的出版压力，主要精力放在提升EAGLE的效果上，没有急于发表论文或做宣传。当然，这仅代表我在团队期间的情况，不能直接解释后续的整个发布过程。

当时我们也试过一些其他有意思的设计，但未在本次技术报告中提及，涉及未公开内容，此处不展开。