论文专题讲解：EAGLE-3：为什么 draft model 要在训练时“见过自己犯错”

论文信息

论文题名： EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test。

作者： Yuhui Li、Fangyun Wei、Chao Zhang、Hongyang Zhang。

机构： Peking University、Microsoft Research、University of Waterloo、Vector Institute。

时间 / 主题： 2025-03；高效推理。

arXiv / 官方报告： arXiv：2503.01840。

GitHub / 项目： GitHub：github.com/SafeAILab/EAGLE。

元数据来源与核验口径： 来源：arXiv；GitHub API / repo；Checked Date：2026-06-15；Repro Status：Paper / official materials reviewed, independent reproduction not claimed。

EAGLE-3 继续解决投机解码里的同一个问题：怎么让便宜 draft path 猜出 target LLM 更可能接受的未来 token。它和 EAGLE 的关键差别不是“又换了一个小模型”，而是指出：draft model 训练时如果只看真实前缀，推理时却要吃自己上一轮生成的前缀，多步 draft 就会分布偏移。

EAGLE-3 的回答是 training-time test：在训练阶段就模拟测试时的递归 draft，让 draft model 见过自己生成的中间状态。这样它往后猜第 2、第 3、第 4 个 token 时，不会因为输入分布突然变成“自己造出来的前缀”而崩。

从 EAGLE 到 EAGLE-3：放弃 feature regression 约束

EAGLE 用 target LLM 的 second-to-top-layer feature 做 draft。这个思路很聪明，但原版 EAGLE 要求 draft head 预测 target feature，本质上有一个 feature regression constraint。这个约束让第一步 draft 比较稳，但也把 draft model 的表达空间绑死在“像不像 target feature”上；训练数据继续变多时，speedup 和 acceptance 的提升会变钝。

EAGLE-3 做了三件事：

改动	解决什么
Direct token prediction	不再强迫 draft output 回归 target feature，直接服务 token acceptance
Training-time test	训练时模拟多步 draft，缓解推理时 exposure bias
Multi-layer feature fusion	不只看 top-layer feature，而是融合低层、中层、高层特征

图源：EAGLE-3，Figure 1。原图表达：在 LLaMA-Instruct 3.1 8B + MT-bench 上，EAGLE 随 draft 训练数据增加收益有限，而 EAGLE-3 的 speedup 和 acceptance length 随数据规模继续提高。本站读法：这张图的关键是“数据规模能不能转成更多 accepted tokens”。

Training-time test 是什么

普通训练类似 teacher forcing：模型总是看到真实前缀。投机解码的测试时刻不是这样。第 1 个 draft token 由 target feature 条件生成；第 2 个 draft token 的输入已经包含 draft model 自己刚才的输出；第 3 步又吃第 2 步的输出。越往后，输入越不像训练数据。

EAGLE-3 把这个过程搬到训练里：

target features
  -> draft step 1 -> draft hidden/output a1
  -> feed a1 and sampled token back
  -> draft step 2 -> draft hidden/output a2
  -> feed a2 and sampled token back
  -> draft step 3 ...

训练时已经让 draft model 处理自己的中间输出，推理时多步递归就不再陌生。这就是 training-time test 的名字来源：把 test-time 的 draft 过程提前放进 training。

图源：EAGLE-3，Figure 3。原图表达：EAGLE-3 不再预测 target feature，而是直接预测 token；训练阶段模拟测试阶段的多步生成。本站读法：看箭头如何把 draft model 自己的输出继续喂回下一步。

多层 feature fusion 为什么有用

EAGLE-3 推理时仍然依赖 target LLM 的一次前向。target model 会产生低层、中层、高层 feature，论文记作 $l,m,h$。它把这些 feature 拼接后投影成融合 feature：

$g = W[l;m;h]$

这里 $[l;m;h]$ 表示把三层 feature 串接，$W$ 是全连接投影，$g$ 是给 draft model 的条件表示。读这行式子时，重点不是矩阵乘，而是信息来源：低层 feature 保留局部和词法线索，中层 feature 保留结构，高层 feature 更接近语义和 logits。

图源：EAGLE-3，Figure 5。原图表达：target model 的低层、中层、高层 feature 被融合后送入 draft model；后续 draft step 使用 draft model 自己的中间输出继续递归生成。本站读法：第一步依赖 target feature，后续步骤逐渐转为 draft 自回归。

相比只用 top-layer feature，多层融合给 draft model 更完整的上下文条件。再配合 direct token prediction，draft model 不必先“像 target feature”，而是直接学习“哪些 token 更可能被 target 接受”。

消融实验怎么读

论文 Table 2 清楚展示了三步增益。这里的 $\tau$ 是 average acceptance length，也就是一次 target verification 平均能接受多少 draft token。

Method	MT-bench Speedup	MT-bench $\tau$	GSM8K Speedup	GSM8K $\tau$
EAGLE-2	3.16x	4.05	3.39x	4.24
+ remove feature constraint	3.82x	5.37	3.77x	5.22
+ fused features (EAGLE-3)	4.40x	6.13	4.48x	6.23

表源：EAGLE-3，Table 2。原表表达：去掉 feature constraint 已经显著提高 acceptance length，多层 feature fusion 进一步提升 speedup。

这张表的读法是：EAGLE-3 的核心收益先来自“解除 feature regression 约束”，再来自“用多层 feature 补足条件信息”。如果只看最终 speedup，很容易误以为是更大 draft 或更多数据；其实训练目标和输入分布才是关键。

接受率为什么没有随深度崩掉

投机解码最怕 draft 越往后越不准。EAGLE-3 的 Figure 7 比较了不同 draft 位置的接受率：EAGLE 随递归步数下降更明显，而 EAGLE-3 保持更平稳。

图源：EAGLE-3，Figure 7。原图表达：在 LLaMA-Instruct 3.1 8B + MT-bench 上，EAGLE-3 的 draft 接受率随递归步数增加仍保持稳定。本站读法：这张图是 training-time test 的机制证据，不只是速度结果。

这里的直觉是：如果训练时已经模拟了第 2、第 3 步会看到的“draft 自己生成的输入”，推理时往后滚就不会快速偏离。接受率平稳意味着更深的 draft tree 变得值得验证。

Runtime 结果不能只看单请求

EAGLE-3 报告了 SGLang 和 vLLM 的集成结果。SGLang 表中，LLaMA-Instruct 3.1 8B 在 batch size 64 时仍有约 1.38x throughput improvement；单请求下，SGLang + EAGLE-3 的 token/s 高于无投机和 EAGLE-2。

这说明 EAGLE-3 不是只在离线 benchmark 上好看，它能进入 runtime 的 batch、KV、verify 路径。但线上判断仍然要分桶：

请求桶	可能更适合 EAGLE-3 的原因
低温、长输出	draft 更容易连续被接受
数学/代码/格式稳定任务	模式更强，acceptance 更高
小 batch 交互请求	target decode 更容易有空闲计算可利用
高温创作、短输出、工具 agent	draft 不确定性高，overhead 可能吃掉收益

EAGLE-3 的 speedup 不是免费午餐。draft model 训练、feature export、tree attention、verification mask、KV 生命周期和 runtime 集成都要一起做。

和 EAGLE、EAGLE-2 的连续关系

论文	关键问题	解法
EAGLE	draft 不一定是完整小 LLM	feature-level draft + shifted-token
EAGLE-2	静态 draft tree 浪费候选预算	dynamic draft tree
EAGLE-3	draft 训练分布不像测试时多步输入	direct token prediction + training-time test + fused features

把三篇连起来看，主线很清楚：先找到 target feature 这个低成本接口，再把候选树按上下文动态分配，最后让 draft model 在训练时见过推理时的递归输入。

训练和推理接口要逐项对齐

EAGLE-3 最容易被讲成“训练时也做一次测试”，但工程上要拆成三个接口。第一个接口是 target feature export：target LLM 的低层、中层、高层 hidden states 必须在一次 forward 中稳定取出，并且和 LM head、position、attention mask 对齐。第二个接口是 draft recursion：draft model 第一轮吃 target fused feature，后续轮次吃自己的中间表示和采样 token。第三个接口是 target verification：候选树必须被构造成 target model 可以一次验证的 token/mask/KV 形状。

这三个接口任何一个错位，都会让论文里的 acceptance length 变成线上 bug。例如 fused feature 的层号和训练不一致，draft 会看到分布外输入；tree mask 如果让候选分支互相泄漏，就会破坏 speculative decoding 的分布保持；verification 阶段如果没有正确处理被拒绝 token 后的 KV cache，下一步 decode 会带着错误上下文继续跑。

可以把 EAGLE-3 的上线检查写成一条状态机：

prefill target LLM
  -> collect multi-layer features
  -> draft recursive candidates
  -> build tree attention mask
  -> target verifies all candidate paths
  -> accept prefix / reject branch
  -> commit only accepted KV and tokens

这个状态机解释了为什么论文同时报告 algorithm speedup 和 runtime integration。方法本身只让 draft 更准；真正落地还需要 scheduler 知道候选树占多少 token，KV manager 知道哪些 token 可以提交，sampling module 知道拒绝后从 target distribution 继续。

证据链：不是一张速度图就够了

EAGLE-3 的论文证据可以按“机制、规模、系统”三层读。

证据节点	支撑的 claim	不能证明什么
Figure 1 scaling law	direct token prediction 和 training-time test 能把更多数据转成 speedup / acceptance length	不证明任意领域流量都能同样随数据扩展
Figure 3 training-time test	训练过程显式模拟多步 draft recursion	不证明 draft 输出质量本身优于 target
Table 2 ablation	remove feature constraint 和 fused features 都贡献增益	不证明多层 feature 的最优层组合已经穷尽
Figure 7 acceptance by recursion step	接受率随 draft 深度更稳定	不证明无限深 tree 都值得扩展
SGLang / vLLM runtime 表	方法能嵌入真实 serving runtime	不证明所有 batch size、所有硬件和所有 prompt 分布下都更快

这个分层很重要。投机解码的质量保持来自 target verification，不来自 draft model “更聪明”。因此 EAGLE-3 的核心指标不是 perplexity 或回答分，而是 accepted tokens、verification overhead、end-to-end throughput / latency。读 speedup 时还要确认 baseline 是否包含同等 runtime 优化、是否启用 tree attention、是否相同 sampling temperature、是否同样 batch size。

部署时最容易踩的坑

第一类坑是 request mix。EAGLE-3 对低温、长输出、模式稳定的请求更友好；对短输出、工具调用、强随机采样和频繁 stop 的请求，draft 成本可能没有足够 token 可以摊销。线上不应只开全局开关，而应该按 route、temperature、max output、历史 acceptance rate 做 gating。

第二类坑是 memory accounting。draft tree 会增加一次 verification 的 token 数，target KV cache 也会临时承载候选路径。即使最终只提交 accepted prefix，中间 verification 的显存和 kernel 时间仍是真实成本。长上下文服务里，PagedAttention、prefix cache、speculative tree 和 batch scheduler 会互相影响。

第三类坑是训练域。论文使用公开对话和 benchmark 说明 scaling 趋势，但企业流量可能包含代码补全、结构化 JSON、检索引用、工具轨迹、数学证明和多语言文本。EAGLE-3 的 training-time test 解决 exposure bias，不自动解决 domain mismatch。更稳的做法是对目标流量采样，按任务桶统计 acceptance，再决定是否补训 draft。

第四类坑是验证口径。只看单请求 latency 会低估 batch serving 的资源竞争；只看吞吐会掩盖 P95/P99 延迟；只看 accepted length 会忽略 tree construction 和 draft overhead。最终验收至少要同时看：target forward 次数、accepted tokens per verify、draft token cost、GPU memory peak、batch occupancy、P50/P95/P99 latency 和输出一致性。

最小复现实验应该怎么设计

复现 EAGLE-3 不必一开始就接完整线上 runtime。更稳的是先做三层小实验。

第一层是离线 acceptance 实验。固定 target model、prompt 集合、temperature 和 max tokens，比较原始 EAGLE-2、去 feature constraint、加入 fused features、加入 training-time test 后的 average acceptance length。这个实验不追求最高 tokens/s，只验证机制是否按论文方向工作。

第二层是单请求端到端 latency。把 draft、tree construction、target verification 和 sampling 都放进同一条推理路径，统计每个模块耗时。这里要防止“只测 target 少跑几步”而漏掉 draft overhead。若 acceptance length 提高但端到端 latency 不降，说明 bottleneck 已转移到实现。

第三层是 batch serving。用真实或合成的请求长度分布测试 batch size 1、8、32、64 等不同并发。记录 throughput、P95 latency、peak KV memory 和 acceptance rate。EAGLE-3 的论文结论可以作为预期方向，但最终上线阈值应来自本地 workload。

实验层级	必看指标	失败信号
离线 acceptance	accepted length、acceptance by depth	training-time test 后深层接受率仍快速下滑
单请求 latency	draft time、verify time、total token/s	draft overhead 超过 target step 节省
Batch serving	throughput、P95/P99、peak memory	高并发下 tree verification 挤占 KV 或 scheduler

这样设计的好处是能快速定位失败原因：机制没起作用、实现太慢、还是 workload 不适合。它也符合 EAGLE-3 的证据结构：先证明 draft 更会猜，再证明 runtime 真能获益。

和其他推理优化的组合边界

EAGLE-3 属于 decode-side acceleration，主要减少 target LLM 逐 token 前进的次数。它和 quantization、KV cache 压缩、PagedAttention、continuous batching 不是同一层优化。

优化	作用层	和 EAGLE-3 的关系
Weight / activation quantization	降低每次 forward 的算力和带宽	target 和 draft 都可能受益，但量化误差会影响 acceptance，需要复测
KV cache paging / prefix cache	管理长上下文和多请求 KV	draft tree 会增加临时候选 token，必须和 KV manager 协同
Continuous batching	提高 GPU 批处理利用率	大 batch 下 target 已接近饱和，EAGLE-3 的边际收益可能下降
Disaggregated prefill	分离 prompt 和 decode 资源	EAGLE-3 主要作用在 decode，prefill-heavy 流量收益有限
Routing / model cascade	按请求选不同模型或路径	可以只给适合请求开启 EAGLE-3，避免全局 overhead

这个表帮助避免一个常见误解：EAGLE-3 不会自动解决所有推理成本。它最擅长的是“target 每次 decode 很贵，而 draft 能连续猜中多个 token”的区间。若系统已经被 prefill、网络队列、工具调用或 CPU sampling 卡住，EAGLE-3 的接受率再高也不一定改善用户感知延迟。

从项目取舍看，EAGLE-3 更像“decode path 的二级发动机”，不是新的 target model。它的评估要和容量规划放在一起：多一个 draft 模型意味着更多权重、更多调度路径和更多监控指标；少跑 target decode step 则意味着更低的高价模型调用成本。最终是否值得上线，取决于这两边的账能否在真实流量上闭合。

一个合格的 EAGLE-3 实验报告最好不要只贴 speedup。它应该写清 target model、draft model、训练数据量、temperature、tree size、prompt/output 长度分布、runtime、batch size 和硬件；还要报告拒绝后的回退逻辑是否保持 target 分布。这样读者才能判断提升来自方法机制、实现优化，还是 benchmark 条件本身。

如果这些条件没有列清，EAGLE-3 的结论只能作为方向参考，不能直接变成容量规划假设；真正的部署决策还要用本地请求回放验证。尤其是 agent 流量和代码流量，常常混合短回答、工具调用、长 JSON、重试和 stop sequence；它们的 acceptance pattern 可能和 MT-bench 完全不同，所以最好单独分桶统计，而不是把所有请求揉成一个平均 speedup。

外部精读

• EAGLE-3 论文：方法、scaling、消融和 runtime 表。
• EAGLE GitHub：系列实现入口。
• EAGLE 原论文：理解 feature-level draft 和 shifted-token 的起点。
• 缓存、路由与投机解码：把 EAGLE-3 放回服务系统的请求生命周期里看。

阅读结论

EAGLE-3 的核心不是“更强的草稿模型”，而是“draft 训练分布要像线上推理分布”。它放弃 feature regression 约束，直接服务 token acceptance；用多层 target feature 给 draft 更完整的条件；用 training-time test 让 draft model 在训练时就处理自己的递归输出。理解这三点后，EAGLE-3 的 speedup 表才有意义：收益来自 accepted tokens 增多，但能否落地还取决于请求桶、batch size、runtime 集成和 verification overhead。