TECH ARTICLES
LLM 推理优化 Speculative Decoding

推测解码：让大模型推理快 3 倍的"草稿纸"魔法

Jackie Zhan 2026-03-28
目录
为什么你的 GPU 在"摸鱼"？ 推测解码到底是怎么回事？ 凭什么能做到质量零损失？ 从 Medusa 到 EAGLE-3：草稿模型在进化 Intel 的突破：打破词表壁垒 实战落地：今天就能用的工具链 尾声：两个预测

10%。

这是大模型在逐 token 生成时，GPU 算力的实际利用率。

你没看错。你花几万块买的 H100，或者每小时烧好几美元租的云端显卡，在大模型推理的时候，有将近 90% 的算力是闲置的。

这就好比你请了一位年薪百万的顶级专家。结果他每天 90% 的时间不是在思考，而是在等电梯。

等什么？等数据从显存搬到计算单元。这个过程叫"访存"（memory access），它才是大模型推理真正的瓶颈——不是算力不够，而是数据搬运太慢。

2022 年，Google 的研究团队想到了一个绝妙的办法：既然大模型生成一个 token 和生成五个 token 花的时间差不多（因为瓶颈在访存，不在计算），那为什么不让一个小模型先猜五个 token，然后让大模型一口气验证？

这个想法叫做推测解码（Speculative Decoding）。它在 2026 年已经从论文走进了每一个主流推理框架。

接下来，我带你搞懂三件事：它为什么有效、它凭什么零损失、以及你今天就能怎么用。

为什么你的 GPU 在"摸鱼"？

要理解推测解码为什么有效，你得先理解一个违反直觉的事实：大模型推理的瓶颈不是计算，而是搬运。

你可以把 GPU 想象成一个超级快的厨师。他切菜、翻炒、装盘的速度快到惊人。但问题是，食材全锁在一个巨大的冰库里，每次只能用一辆小推车运出来。厨师刀已经举起来了，食材还在路上。

这就是 GPU 推理的真实处境。现代 GPU（比如 H100）的算力是每秒千万亿次浮点运算（PFLOPS 级别），但显存带宽只有 3.35 TB/s。对于一个 70B 参数的模型，每生成一个 token，就需要把几乎所有模型权重从显存读一遍。

这意味着什么？

意味着不管你让大模型验证 1 个 token 还是 5 个 token，时间几乎一样。因为瓶颈在"把权重从显存搬到计算单元"这一步，而不是"拿到权重后做了多少计算"。

数据说话
Google 的原始论文测量发现：Transformer 推理时每从显存读取一个字节，只执行了不到 10 次浮点运算。而现代 GPU 的设计比例是每字节几百次运算。这意味着超过 90% 的算力在空转。

标准的自回归生成（autoregressive generation）是怎么工作的？大模型一次只生成一个 token，然后把这个 token 加到输入序列里，再生成下一个 token。一个字一个字地蹦。

每蹦一个字，都要把整个模型权重读一遍。

这就像你去食堂打饭，每次只能打一个菜，打完要重新排队。明明你已经知道要吃什么了，但食堂规定：一次只能打一个菜。

有人看着这个局面，问了一个关键问题：能不能一次打五个菜？

答案是：大模型自己不行，但可以找个"帮手"。这就是推测解码的起点。

GPU 不是不够快，是不够忙。推测解码要做的，就是让 GPU 忙起来。

推测解码到底是怎么回事？

推测解码的核心思路，用一句话概括：

让小模型打草稿，让大模型审批。

想象你是一家公司的 CEO。你的时间很贵，每个决策都需要你亲自做。但你发现，80% 的决策其实你的实习生也能做对。

于是你换了一个工作方式：让实习生先把一批决策草案写好，你花 5 分钟通篇浏览一遍，对的就签字，错的再改。

这比你一个一个地做决策快多了。因为你"浏览"的速度远快于"从头思考"的速度。

推测解码的流程，就三步：

第一步：小模型快速打草稿

一个参数量小得多的"草稿模型"（Draft Model），快速生成 K 个候选 token。比如你让 Llama 70B 做推理，草稿模型可能是 Llama 8B，甚至更小。

小模型生成速度飞快——因为它模型小，权重读取快。

第二步：大模型一口气验证

大模型拿到这 K 个候选 token，在一次前向传播中同时验证所有 token 的概率分布。

关键来了：验证 K 个 token 和验证 1 个 token 花的时间几乎一样。因为瓶颈在读权重，不在算数。

第三步：接受或拒绝

大模型逐个检查草稿 token：如果这个 token 的概率符合大模型自己的分布，接受；如果不符合，拒绝，并从该位置开始用大模型自己的分布重新采样。

草稿模型 (小而快) 生成 K 个 token 候选 Token t₁ t₂ t₃ t₄ t₅ 并行验证 目标模型 (大而准) 接受 或拒绝
推测解码三步流程：草稿→验证→接受/拒绝

来看个具体例子。假设输入是"法国的首都是"：

小模型快速生成 5 个 token：巴黎，一座美丽的。耗时 50ms。

大模型一次性验证这 5 个 token。发现前 4 个都 OK，但第 5 个 token 它更倾向于生成"著名"而不是"美丽"。于是接受前 4 个，拒绝第 5 个，从"著名"继续。耗时 200ms。

结果：250ms 生成了 5 个 token。如果走传统自回归？5 × 200ms = 1000ms。快了 4 倍。

关键区别
推测解码和"用小模型替代大模型"是完全不同的事。小模型只负责猜，大模型负责判。最终输出的每一个 token，都经过了大模型的严格验证。质量零妥协。

这里有个美妙的不对称性：小模型猜错了，代价很小——大模型只是多做了一次正常的生成。小模型猜对了，收益很大——省掉了好几次大模型的前向传播。

让小模型跑腿，让大模型拍板。这就是推测解码的全部哲学。

凭什么能做到质量零损失？

到这里你可能会想：小模型猜，大模型验，听起来是近似方法吧？输出质量多少会打折扣？

反直觉的答案是：完全零损失。不是"差不多一样好"，是数学上严格证明的"分布完全一致"。

这是推测解码最让人拍案叫绝的地方。

它用的数学工具叫拒绝采样（Rejection Sampling）。这个技巧来自统计学，已经有几十年历史了。核心逻辑是这样的：

对于小模型生成的每个 token，用大模型计算它在当前位置的真实概率 Ptarget，同时拿到小模型给出的概率 Pdraft。然后做一个判断：

一旦某个 token 被拒绝，后续所有草稿 token 都被丢弃，大模型从拒绝位置按自己的分布重新采样。

这个机制有一个优美的数学性质：无论草稿模型多差，最终输出的 token 序列服从的概率分布，都和大模型独立生成时完全相同。

打个比方。你去参加开卷考试，允许翻笔记。笔记里的答案有些是对的，有些是错的。但考试规则是：每个答案你都要自己验一遍，算对了才写上去，算不对就自己重做。

最终你交的卷子，和你不看笔记独立做出来的，答案分布完全一样。唯一的区别是速度更快——因为"验证"比"从零思考"快得多。

常见误解
很多人以为推测解码是一种"模型蒸馏"或"近似推理"。错了。推测解码不改变模型，不改变权重，不改变输出分布。它改变的是计算调度——用巧妙的并行策略让同样的数学计算跑得更快。这就是为什么它能和量化、剪枝等技术叠加使用，效果相互正交。

这带来了一个重要的实践意义：你可以放心地在生产环境使用推测解码，不需要做额外的质量评估。因为它在数学上保证了输出与原始模型完全等价。

不是近似，是精确等价。这一点让推测解码从众多加速技巧中脱颖而出。

从 Medusa 到 EAGLE-3：草稿模型在进化

推测解码的核心瓶颈是什么？是草稿模型的准确率。

小模型猜得越准，大模型接受的 token 越多，加速比越高。猜得不准，大模型频繁拒绝，推测解码就退化成了普通的自回归生成，白白浪费了运行小模型的时间。

所以过去两年，整个领域都在围绕一个问题发力：怎么让草稿模型更准、更快？

这场进化经历了三个阶段，每一步都有意思。

第一阶段：独立草稿模型

最早的做法最朴素：找一个同系列的小模型当草稿模型。用 Llama 70B 做推理？那就用 Llama 8B 当草稿。

好处是简单直接。坏处也明显：你需要额外加载一个模型，占用显存；而且小模型和大模型的"想法"未必一致——小模型的概率分布和大模型差异越大，草稿被拒绝的概率越高。

这就像你找了一个外部的翻译来帮你起草文件。他不了解你的思维习惯，经常猜错你想说什么。

第二阶段：Medusa——给大模型装"多个脑袋"

2023 年底，一种叫 Medusa 的方法横空出世。它的思路很巧妙：别用外部小模型了，直接在大模型头上加几个额外的预测头（Medusa Heads）。

第一个头预测下一个 token，第二个头预测下下个 token，第三个头预测下下下个……这些头共享大模型的主干特征，只是最后一层不同。

好比给你的大脑装了几条平行的思考通道。每条通道负责预测不同位置的 token，然后同时输出草稿。

好处是不需要额外的模型，显存开销极小。坏处是需要对大模型做轻量级训练来安装这些"头"，而且每个头是独立预测的，缺少 token 之间的上下文关联。

延伸思考
Medusa 这个名字来自希腊神话中的美杜莎——一个长着多条蛇头的怪物。每条蛇头独立行动，就像 Medusa 架构中的每个预测头独立生成不同位置的 token。命名者的文学素养可见一斑。

第三阶段：EAGLE 家族——让草稿模型"住进"大模型脑子里

2024 到 2025 年，EAGLE（Extrapolation Algorithm for Greater Language-model Efficiency）系列把草稿模型的设计推向了新高度。

EAGLE 的核心洞察是：与其从大模型外部猜测，不如直接利用大模型内部的隐藏层特征来做草稿。它在大模型的中间层插入一个轻量的"EAGLE Head"，只有 1-2 层 Transformer，就能基于大模型的内部表示来预测后续 token。

到了最新的 EAGLE-3，进化更彻底：

效果如何？EAGLE-3 在 Llama 3.3 70B 上实现了 4-6 倍的加速。而且因为草稿模型直接利用了大模型的内部特征，准确率远高于外部小模型。

再往前一步，2026 年 3 月 AWS 发布的 P-EAGLE，更是解决了 EAGLE 系列的最后一个瓶颈：原本 EAGLE 需要逐个生成草稿 token（虽然每个很快），P-EAGLE 把这个过程改成了一次前向传播生成所有 K 个草稿 token，在 NVIDIA B200 上比标准 EAGLE-3 又快了 1.69 倍。

方案草稿来源加速比额外显存
独立草稿模型外部小模型2-3x需加载小模型
Medusa额外预测头2-3x极小
EAGLE-3内部特征融合4-6x极小
P-EAGLE并行内部特征5-8x极小

最好的草稿模型，不在大模型之外，而是住在大模型自己的脑子里。

Intel 的突破：打破词表壁垒

前面说的方案，不管是独立草稿模型还是 EAGLE，有一个共同的限制：草稿模型和目标模型通常需要共享同一套词表（vocabulary）。

这意味着什么？意味着你只能用 Llama 家族的小模型给 Llama 大模型当草稿，不能用 Qwen 的小模型给 Llama 当草稿。模型是"门当户对"的。

这个限制在实际部署中非常恼人。假设你手上有一个效果特别好的 3B 小模型，但它的词表跟你的目标大模型不一样——抱歉，不能用。

2025 年年中，Intel Labs 和以色列 Weizmann 研究所在 ICML 上发表了一项研究，彻底解决了这个问题。

他们提出了三种新算法，核心思路是：把推测解码从词表对齐中解耦出来。不管草稿模型和目标模型的 tokenizer 是否相同，不管它们是不是同一个公司开发的，都能配对使用。

效果：跨词表推测解码依然能实现最高 2.8 倍的推理加速，输出质量完全无损。

打个比方。过去的推测解码像 Apple 的 Lightning 接口——只有苹果自家的线能用。Intel 做的事，是把它变成了 USB-C——任何厂家的草稿模型都能给任何厂家的大模型当助手。

这些算法已经集成到 Hugging Face Transformers 开源库中，数百万开发者可以开箱即用。
—— Intel Newsroom, 2025

这个突破的战略意义不亚于技术意义。它意味着：

当任何小模型都能给任何大模型当助手，推测解码才算真正成年。

实战落地：今天就能用的工具链

说了这么多原理，你可能最关心的问题是：我今天就能用吗？

答案是：能，而且非常简单。

2026 年，推测解码已经内置在所有主流推理框架中。你不需要自己实现算法，只需要改几行配置。

以最流行的 vLLM 为例（当前稳定版 v0.17.1，2026 年 3 月发布），启用推测解码只需要在启动参数里指定草稿模型：

# 使用 vLLM 启用推测解码
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.3-70B \
  --speculative-model meta-llama/Llama-3.2-3B \
  --num-speculative-tokens 5

关键在第二行和第三行：--speculative-model 指定草稿模型，--num-speculative-tokens 指定每次猜几个 token。就这么简单。

如果你想用 EAGLE-3 头而不是独立草稿模型：

# 使用 EAGLE-3 头做推测解码
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.3-70B \
  --speculative-model eagle3-llama70b-head \
  --speculative-method eagle
踩坑记录
推测解码在低并发场景下收益最大（单请求延迟降低 2-3 倍），但在高并发场景下，由于 GPU 本身已经因为大 batch 而利用率较高，推测解码的额外开销反而可能拖慢速度。经验法则：并发数 ≤ 8 时大胆开启，超过 32 时建议跑 benchmark 再决定。

除了 vLLM，其他框架的支持情况：

推测解码已经不是前沿技术，而是基础设施。你今天不用，不是因为它不成熟，而是因为你还不知道。

尾声：两个预测

回顾一下推测解码的故事线：

2022 年，Google 发现 GPU 推理时 90% 的算力在空转，提出"让小模型打草稿、大模型审批"的思路。

2023-2024 年，Medusa 和 EAGLE 把草稿模型从"外部助手"变成了"内部器官"，加速比从 2-3 倍提升到 4-6 倍。

2025 年，Intel 打破词表壁垒，让跨模型家族的推测解码成为现实。

2026 年，vLLM、TensorRT-LLM、SGLang 等所有主流框架已原生集成推测解码，从论文变成了一行配置。

这条技术演进线告诉我们一件事：AI 推理优化的下一个 10 倍提升，大概率不来自更大的模型或更贵的硬件，而是来自更聪明的计算调度。推测解码就是这个方向上最漂亮的证明。

基于此，我做两个预测，给自己设个 deadline：

预测一：2026 年底之前，推测解码将成为所有商用 LLM API 的默认推理策略（而不是可选项）。Google 的 AI Overviews 已经在用了，OpenAI 和 Anthropic 跟进只是时间问题。

预测二：2027 年 Q2 之前，会出现专门为"做草稿"而训练的草稿模型赛道——就像今天有专门做 embedding 的模型一样，会有团队专门优化"在推测解码中当草稿"这个目标函数。

半年后回来看看，我说得对不对。

在那之前，如果你正在部署大模型推理服务，推测解码是你今天就应该打开的开关。不改模型，不改输出，一行配置，速度翻倍。

这种好事，不用白不用。

参考资料

  1. Google Research - Looking Back at Speculative Decoding
  2. NVIDIA - An Introduction to Speculative Decoding for Reducing Latency in AI Inference
  3. Intel Newsroom - Intel and Weizmann Institute Speed AI with Speculative Decoding Advance
  4. PyTorch - A Hitchhiker's Guide to Speculative Decoding
  5. SafeAILab - EAGLE: Official Implementation (ICML'24, EMNLP'24, NeurIPS'25)
  6. AWS - P-EAGLE: Faster LLM Inference with Parallel Speculative Decoding in vLLM
  7. BentoML - LLM Inference Handbook: Speculative Decoding
  8. NVIDIA - TensorRT-LLM Speculative Decoding Boosts Inference Throughput by up to 3.6x