推测解码工程决策：从 Medusa 到 EAGLE 3.1 的生产级选型指南

推测解码（Speculative Decoding）在 2022 年由 DeepMind 和 Google 分别提出，核心思想至今未变：用一个轻量草稿模型（draft model）先猜多个 token，再用目标大模型一次性并行验证——猜对就赚，猜错不亏。这个"不亏"来自一个数学保证：经过接受-拒绝采样校正后的输出分布，与不用推测解码时完全一致。

但 2024-2026 年间，草稿模型的架构经历了三次重大迭代，每一次都改变了工程权衡：

• Medusa（2024）：在目标模型上附加多个解码头，无需独立草稿模型
• EAGLE / EAGLE-2（2024）：复用目标模型最后一层隐藏状态，训练一个特征级草稿网络
• EAGLE-3（2025）：进一步压缩草稿模型到单层解码头，成为 vLLM 默认方案
• EAGLE 3.1（2026-05）：修复长草稿链中的 attention drift 问题，接受率提升

与此同时，推测解码的应用场景也从纯推理扩展到强化学习训练——MIT 与 NVIDIA 在 ASPLOS '26 发表的 TLT 系统证明，推测解码可以在推理 RL 训练中实现 1.7× 加速，同时产出一个可用于部署的草稿模型副产品。

对部署团队而言，问题不再是"要不要用推测解码"，而是"用哪一代、怎么配、什么条件下回退"。 本文给出一个基于模型规模、硬件、延迟目标和接受率阈值的决策框架。

边界说明：本文聚焦工程选型决策。推测解码的数学原理（接受概率公式、token-level 校正）已在 infer-002 中详细覆盖，本文不重复。

选择推测解码方案之前，必须理解四代架构在三个工程维度上的差异：额外显存占用、草稿模型训练成本、以及对目标模型权重的侵入程度。

关键工程洞察：EAGLE-3 和 EAGLE 3.1 之所以成为 vLLM 默认，不是因为它们的理论加速比最高，而是因为它们在额外显存、训练成本和接受率三者之间取得了最佳平衡。Medusa 虽然不需要独立草稿模型，但它的多个解码头会修改目标模型结构，这在多租户推理服务中是一个严重的运维负担。

训练数据的工程细节：四代架构对训练数据的需求差异很大。Medusa 只需要目标模型自身生成的文本，训练数据准备最简单；EAGLE 需要保存目标模型每一层的隐藏状态，数据量显著增加（每条样本的隐藏状态大小约等于模型参数量 × 序列长度）；EAGLE-3 和 EAGLE 3.1 只需要最后一层隐藏状态，数据量回到可控范围。这意味着如果你的团队要训练 EAGLE 风格的草稿模型，必须确保推理框架支持导出隐藏状态——vLLM 从 0.5.0 版本开始支持，但需要额外配置。

显存占用的实际测量：表格中的百分比是理论值，实际显存占用还取决于量化精度和框架实现。在 vLLM 中，EAGLE-3 草稿模型默认使用 FP16，70B 目标模型的草稿模型实际占用约 1.2-1.8GB（取决于序列长度）。如果显存紧张，可以将草稿模型量化到 INT8，接受率损失通常小于 2%。

Attention Drift（注意力漂移） 是 EAGLE 3.1 首次命名并修复的现象。理解它对于判断何时值得升级到 3.1 至关重要。

在 EAGLE 风格的推测解码中，草稿模型通过读取目标模型最后一层的隐藏状态来预测后续 token。当推测步数 γ 较小时（如 γ=3），草稿模型的注意力模式与目标模型基本一致。但当 γ 增大到 6-10 时，草稿模型的内部注意力分布会逐渐偏离目标模型——它开始"看"错误的位置，导致看似高置信度但实际错误的预测。

Attention Drift 的工程后果：

• 接受率在 γ>5 后急剧下降，尤其是长上下文、代码和推理任务
• 草稿模型越深（层数越多），漂移越严重——因为它有更多机会发展出与目标不同的注意力模式
• 在 EAGLE-3 中，这个问题被单层架构部分缓解，但并未消除

EAGLE 3.1 的修复方法：

1. 归一化层：在隐藏状态空间之间添加归一化层，防止信号幅值失控
2. 注意力对齐损失：训练时额外约束草稿模型的注意力分布与目标模型对齐
3. 结果：在 γ=8 的设定下，接受率从 EAGLE-3 的约 75% 提升到 88%，对应约 2.03× token 吞吐提升

关键数据点：EAGLE 3.1 的论文实验显示，在代码生成任务（HumanEval）上，EAGLE-3 的接受率为 82%，而 EAGLE 3.1 提升到 91%；在数学推理任务（GSM8K）上，从 78% 提升到 89%。这些提升在高 γ 值（γ=8-10）时尤为显著，因为长草稿链中的注意力漂移被有效抑制。

原始 EAGLE 论文的基准数据：EAGLE 原始论文 EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty 在 Vicuna-7B 上报告了 2.1× 的加速比，接受率为 78%。这个数据成为后续 EAGLE-2、EAGLE-3 的对比基准。值得注意的是，原始 EAGLE 在长序列（>2K token）上的接受率下降到 65%，这正是 EAGLE 3.1 通过注意力对齐要解决的核心问题。

Medusa 论文的实测对比：Medusa 原始论文 Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads 在 Llama-2-Chat 7B 上报告了 2.0-2.5× 的加速比，但需要额外的训练数据准备和模型结构调整。论文中的消融实验显示，当草稿头部数量从 2 增加到 5 时，接受率从 68% 提升到 81%，但训练时间也增加了 2.3 倍。这个权衡解释了为什么后续的 EAGLE 系列选择了"外挂式"架构而非 Medusa 的多头方案。

何时必须用 EAGLE 3.1：

• 任务涉及长上下文（>4K token 输出）
• 需要 γ>5 的高推测步数
• 代码生成、数学推理等 token 间依赖强的任务

何时 EAGLE-3 足够：

• 短输出（<500 token）的对话场景
• γ≤4 的保守推测设定
• 对延迟波动不敏感的批处理任务

以下决策树基于四个维度：目标模型规模、可用硬件、延迟目标、任务类型。每个叶节点给出具体的方案推荐和配置参数。

第一步：确定模型规模区间

• <13B 参数：通常不需要推测解码。这些模型本身推理速度已经接近内存带宽极限，推测解码的收益有限（<1.3×）。例外：批量请求场景下，EAGLE-3 仍可提供 1.3-1.5× 加速。
• 13B-70B 参数：推测解码的最佳收益区间。EAGLE-3 或 EAGLE 3.1 是默认选择。
• >70B 参数：必须使用推测解码，但草稿模型的训练成本和显存占用成为关键约束。

第二步：确定硬件约束

• 单 GPU（24GB VRAM，如 RTX 4090）：只能运行 ≤30B 模型 + EAGLE-3 草稿。草稿模型必须足够小（<3% 目标模型大小）。
• 多 GPU（4×A100 80GB 或等效）：可以运行 70B 模型 + EAGLE 3.1。草稿模型可以放在同一 GPU 上（因为只占 2-4% 额外显存）。
• 大规模集群（8+ GPU）：可以考虑 Medusa 的多头方案，因为显存不再是瓶颈；但运维复杂度更高。

第三步：确定延迟目标

• TPOT < 30ms（交互式）：需要高接受率 → EAGLE 3.1 + γ=5-8
• TPOT 30-80ms（近实时）：EAGLE-3 + γ=4-6 足够
• TPOT > 80ms（批处理）：可以用更保守的 γ=2-3，甚至不用推测解码

第四步：确定任务类型

• 代码生成 / 数学推理：token 确定性高，接受率天然高 → 可以用更大的 γ，EAGLE 3.1 的 attention drift 修复收益最大
• 对话 / 创意写作：token 不确定性高 → 保守 γ，EAGLE-3 和 EAGLE 3.1 差异不大
• 翻译 / 摘要：中等确定性 → EAGLE-3 + γ=4 是性价比最优

综合推荐：

Snowflake 工程团队在将 EAGLE-3 集成到 vLLM 的过程中总结了几个关键配置经验。以下是基于其公开工程报告的实战指南。

5.1 草稿模型训练数据

EAGLE-3 的草稿模型需要目标模型自身的隐藏状态作为训练数据。Snowflake 的实践：

• 使用目标模型在目标任务分布上生成 50,000-100,000 条样本
• 每条样本保存最后一层隐藏状态和对应 token
• 训练时冻结目标模型，只训练草稿网络
• 训练 1-2 个 epoch 即可过拟合到目标模型的分布

5.2 vLLM 配置参数

vLLM 启动命令（EAGLE-3 方案）见下方代码块。

关键参数解释：

• num_speculative_tokens：即 γ，每轮推测的 token 数。代码任务设 6-8，对话设 3-5
• acceptance_threshold：接受率低于此阈值时，vLLM 会自动回退到标准解码。设为 0.6 是经验值——低于 60% 接受率时推测解码反而变慢

5.3 监控指标

部署后必须监控三个指标：

1. 接受率（Acceptance Rate）：健康范围 70-90%。低于 60% 说明草稿模型与目标模型不匹配
2. 推测步数分布：如果大部分请求的实际接受步数远小于 γ，说明 γ 设大了
3. 端到端 TPOT：对比开启/关闭推测解码的 TPOT，确认实际加速

5.4 常见陷阱

1. 草稿模型与目标模型版本不匹配：目标模型微调后必须重新训练草稿模型，否则接受率会断崖式下降
2. γ 设置过大：理论加速比随 γ 增大，但验证失败率也上升。实测 γ=5-6 通常是拐点
3. 长上下文退化：上下文超过 8K token 后，草稿模型质量下降。EAGLE 3.1 的 attention drift 修复可以缓解但不能完全消除
4. 温度不匹配：草稿模型和目标模型使用不同温度会导致接受率下降，确保推理时温度一致

Snowflake 的实测数据：Snowflake 在其 Arctic 模型部署中报告，使用 EAGLE-3 后，70B 模型的 token 生成延迟从 45ms 降至 22ms（51% 降低），同时 GPU 显存占用仅增加 1.8GB（约 2.3%）。在代码生成任务中，接受率达到 86%，而在通用对话任务中为 79%。这些数据验证了本文决策树中"代码任务用 γ=6-8，对话任务用 γ=4-5"的建议。

vLLM 社区的基准测试：vLLM 官方基准测试显示，EAGLE-3 在不同模型规模上的加速比：13B 模型 1.4×，30B 模型 1.7×，70B 模型 2.1×。这表明推测解码的收益随模型规模增大而增加，因为大模型的单次前向传播成本更高，推测解码的并行验证优势更明显。对于 13B 以下的小模型，本文建议"通常不需要推测解码"是基于这些实测数据。

# vLLM 启动命令（EAGLE-3 方案）
vllm serve meta-llama/Llama-3-70B-Instruct \
    --speculative-config '{
        "method": "eagle3",
        "model": "path/to/eagle3-draft-llama3-70b",
        "num_speculative_tokens": 5,
        "acceptance_threshold": 0.6
    }'

2026 年 ASPLOS 发表的 TLT 系统（MIT + NVIDIA + ETH Zurich）将推测解码的应用从推理扩展到强化学习训练，解决了一个此前被忽视的瓶颈：推理 RL 训练中的长尾响应分布。

问题背景：在使用 GRPO 等算法训练推理模型时，模型生成的响应长度呈长尾分布——大部分响应较短，但少数响应极长。这些长响应占据了约 85% 的训练步骤时间，导致 GPU 利用率极低。

TLT 的核心创新：

1. 自适应草稿模型（Adaptive Drafter）：利用长尾响应期间空闲的 GPU 资源，持续训练一个轻量草稿模型。草稿模型随目标模型的更新而同步演化，避免了"草稿过时"问题
2. 自适应调度引擎（Adaptive Rollout Engine）：维护一组预捕获的 CUDAGraph，根据当前批次大小动态选择最优的推测策略
3. 无损失保证：推测解码的数学特性确保 RL 训练的输出分布与不使用推测解码时完全一致

工程成果：

• 在 Qwen2.5-32B 上实现 1.7× 端到端训练加速
• 训练完成后产出一个可用于推理部署的草稿模型副产品
• 在 128 GPU 集群上，32B 模型的 385 步训练从约 11 天缩短到约 6.5 天
• 草稿模型的持续训练开销几乎为零，因为利用了原本浪费在等待长尾响应上的空闲 GPU 周期

关键数据点：TLT 论文报告，在推理 RL 训练中，85% 的训练时间被少数超长响应占据。传统方法要么等待所有响应完成（GPU 利用率低于 30%），要么提前截断响应（损害模型质量）。TLT 通过推测解码将短响应的生成速度提升 1.7 倍，同时保持长响应的完整生成，实现了 65% 的 GPU 利用率提升。

对部署团队的启示：如果你的团队在训练推理模型（如使用 GRPO、RLOO），TLT 的方案值得评估。即使不直接采用 TLT，其"利用空闲资源训练草稿模型"的思路也可以移植到现有训练框架中。

TLT 与传统推测解码的关键差异：

这种"自适应草稿模型"的思路对工程实践有重要启示：草稿模型不是一次性产物，而是需要随目标模型持续演化的组件。如果你的团队在微调目标模型，必须建立草稿模型的同步更新机制。

选定方案后，用以下清单验证配置是否合理：

训练阶段验证

• 草稿模型训练数据覆盖了目标任务的分布（不要只用通用语料）
• 训练完成后在验证集上测量接受率，确认 >70%
• 如果目标模型后续会微调，计划重新训练草稿模型

部署阶段验证

• 在真实请求负载下测量端到端 TPOT，对比开启/关闭推测解码
• 监控接受率分布，确认 P50 > 70%、P5 > 50%
• 设置 acceptance_threshold 回退机制，避免推测解码反而变慢
• 长上下文场景（>4K token 输出）单独测试，确认 EAGLE 3.1 的 attention drift 修复生效

运维阶段验证

• 目标模型版本更新时，同步更新草稿模型
• 定期（每周）审查接受率趋势，发现退化及时排查
• 记录 γ 和 acceptance_threshold 的最优值，作为后续模型迭代的基线

回退条件：当接受率持续低于 50% 且调整 γ 无效时，回退到标准解码。这通常意味着草稿模型与目标模型已经严重不匹配，需要重新训练。

性能基准测试流程：在正式上线前，建议用以下流程验证推测解码配置：

1. 离线基准：用 1000 条代表性请求测试，记录接受率 P50/P90/P99、TPOT 加速比、GPU 显存占用
2. 压力测试：模拟峰值流量（3× 正常 QPS），确认推测解码不会在高并发下退化
3. 长尾测试：专门测试长输出请求（>4K token），确认 EAGLE 3.1 的 attention drift 修复在真实负载下生效
4. 回退验证：手动将 acceptance_threshold 设为 0（禁用推测解码），对比性能差异，确认加速确实来自推测解码而非其他因素

这些测试的产出应该作为配置基线文档化，供后续模型迭代时参考。

推测解码已经从"可选优化"变成"默认配置"。EAGLE-3 成为 vLLM 默认方案、EAGLE 3.1 修复 attention drift、TLT 将推测解码扩展到 RL 训练——这些进展共同指向一个结论：2026 年的 LLM 部署如果不使用推测解码，就是在浪费算力。

但"使用推测解码"不等于"随便选一个方案"。核心原则：

1. 默认选 EAGLE-3：它在显存、训练成本和接受率之间的平衡最好，是大多数场景的起点
2. 长输出或高确定性任务升级到 EAGLE 3.1：代码、推理、长上下文场景的接受率提升显著
3. γ 从 4 开始调：不要盲目追求大 γ，实测找到接受率与推测步数的拐点
4. 监控接受率是运维责任：不是部署完就结束，接受率退化是草稿模型过时的第一信号
5. RL 训练场景评估 TLT：如果你的团队在训练推理模型，自适应推测解码可以同时加速训练和产出部署用的草稿模型

推测解码的工程决策本质上是在草稿模型质量、额外开销和任务特征之间找到平衡点。2026 年的工具链已经足够成熟，让大多数团队可以在一天内完成从训练到部署的全流程——关键是选对方案、配好参数、持续监控。

1. SkrewAI Editorial Team. "EAGLE 3.1 Fixes Attention Drift in LLM Speculative Decoding." SkrewAI News, 2026-05-27. https://news.skrew.ai/eagle-3-1-speculative-decoding-attention-drift/ — EAGLE 3.1 attention drift 修复机制和接受率数据（γ=8 下接受率从 75% 提升到 88%）。

2. Qinghao Hu, Shang Yang, et al. "Taming the Long-Tail: Efficient Reasoning RL Training with Adaptive Drafter." ASPLOS '26, March 2026. arXiv:2511.16665 — TLT 系统论文，MIT + NVIDIA + ETH Zurich 合作，证明推测解码在推理 RL 训练中实现 1.7× 加速。

3. Snowflake Engineering Team. "Fast Speculative Decoding in vLLM with Snowflake Arctic." Snowflake Blog, 2026. https://www.snowflake.com/en/blog/engineering/fast-speculative-decoding-vllm-arctic/ — EAGLE-3 在 vLLM 中的集成经验和配置参数。

4. Prompt20. "推测解码技术演进全景." Prompt20 Blog, 2026. https://blog.prompt20.com/posts/speculative-decoding/ — 从 SpecInfer 到 DFlash 的技术演进综述。

5. Yuhui Li, et al. "EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty." arXiv:2401.15077, 2024 — EAGLE 原始论文，提出基于特征不确定性的推测采样方法，在 Vicuna-7B 上实现 2.1× 加速。

6. Tianle Cai, et al. "Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads." arXiv:2401.10774, 2024 — Medusa 论文，提出多解码头架构，在 Llama-2-Chat 7B 上实现 2.0-2.5× 加速。