5分钟搞懂Speculative Decoding：如何用EAGLE和Medusa加速LLM推理

从“猜字游戏”到工业级加速：深入拆解EAGLE与Medusa的推理加速哲学

如果你最近在部署或使用大语言模型，大概率会碰到一个让人头疼的问题：生成速度太慢。无论是写代码、生成报告还是进行多轮对话，那种等待模型“一个字一个字往外蹦”的感觉，确实有些考验耐心。这背后的核心瓶颈，在于当前主流大模型普遍采用的自回归解码方式——它就像一位极其谨慎的作家，必须写完上一个字，才能思考下一个字，整个过程严格串行。

但有没有可能让这位“作家”变得更高效一些？比如，让它能同时构思好几个词，然后快速筛选出最合适的那个？这就是推测解码（Speculative Decoding） 技术试图回答的问题。它不是一个单一的方法，而是一整套旨在打破串行枷锁的“加速哲学”。今天，我们不只停留在概念科普，而是要深入到当前最受瞩目的两个实战派方案——EAGLE和Medusa的内部，看看它们是如何用截然不同的设计思路，在保证生成质量无损的前提下，将推理速度提升数倍的。无论你是正在为API响应延迟发愁的工程师，还是对底层优化感兴趣的研究者，这篇文章都会为你提供清晰的原理地图和实用的选型参考。

1. 自回归解码的“阿喀琉斯之踵”与推测解码的破局思路

要理解EAGLE和Medusa的价值，首先得看清它们要解决的核心矛盾是什么。

1.1 为什么自回归解码这么慢？

现代大语言模型的推理，本质上是一个序列生成任务。给定一段输入（Prompt），模型需要预测下一个最可能的词（Token），然后将这个词加入输入，再预测下一个，如此循环。这个过程被称为自回归解码。

其速度瓶颈主要来自两方面：

1. 内存带宽限制（Memory-Bound）：模型参数通常存储在GPU的高带宽内存（HBM）中。每次前向计算，都需要将庞大的参数从HBM加载到GPU的片上缓存进行计算，但最终只生成一个微小的Token（可能只是几个字节）。这就好比用巨型货轮每次只运送一个小包裹，运输工具（计算单元）的利用率极低。计算与数据搬运的比值（算术强度）很低，导致GPU的算力无法被充分利用。

2. 严格的串行依赖：第N个Token的生成，必须严格依赖第1到第N-1个Token的结果。这种依赖性阻止了任何形式的并行化，使得生成速度与序列长度线性相关，无法通过堆砌更多计算资源来加速。

注意：这里说的“算力无法充分利用”指的是在生成单个Token的瞬间。虽然GPU的矩阵乘法单元很强大，但大部分时间都在等待数据从内存中加载过来。

1.2 推测解码的核心思想：大胆假设，小心求证

推测解码的灵感非常直观：既然一次只生成一个Token太慢，那我们能不能想办法一次生成多个候选Token，然后让大模型（我们称之为目标模型）来快速验证这些候选是否靠谱？

这个“生成-验证”的范式，就是推测解码的基石。它包含两个关键阶段：

• 草稿阶段（Drafting Phase）：由一个快速的“草稿模块”一次性生成K个连续的候选Token。这个模块需要足够轻量，生成速度远快于目标模型。
• 验证阶段（Verification Phase）：目标模型并行地对这K个候选Token进行打分验证。由于候选序列是已知的，目标模型可以一次性并行计算所有位置的下一个Token概率分布，这比串行跑K次要高效得多。

验证的逻辑基于一个巧妙的采样策略：对于每个草稿Token，比较目标模型认为它正确的概率（q）和草稿模型认为它正确的概率（p）。以 min(1, q/p) 的概率接受这个Token。如果某个Token被拒绝，则丢弃它及其之后的所有草稿Token，回退到目标模型自己生成。

为什么这个策略能加速？ 因为语言生成中存在大量“简单”或“可预测”的片段。例如，输入“法国的首都是”，后面紧跟“巴黎”的概率极高。一个哪怕很简单的草稿模型也能大概率猜对。当这些容易的Token被批量生成并接受时，我们就用一次低成本的前向传播，“跳过”了原本需要K次串行计算的过程。

下表对比了传统解码与推测解码的关键差异：