大模型推理提速这件事，大多数人想到的是换更强的显卡、或者把模型量化到更低的精度。但有一条路线既不用换硬件、也不用牺牲精度，甚至从数学上保证输出和原来一字不差，就能把生成速度提升 2 到 3 倍——这就是推测解码（Speculative Decoding）。它背后藏着一个反直觉但极其漂亮的洞察：大模型生成 token 之所以慢，慢的其实不是”算”，而是”等”。
自回归解码到底慢在哪
要理解推测解码，先得把大模型生成文本的底层机制看清楚。
大语言模型生成文本是自回归的：一次只吐出一个 token，而且下一个 token 必须等上一个 token 算出来之后才能开始。用公式表达就是每一步从条件分布里采样一个词：xt+1 ~ p(· | x1, x2, …, xt)。这带来两个致命问题。
第一是串行依赖：第 100 个 token 依赖前 99 个 token 的结果，这个依赖链条没法并行化。你要生成一个 1000 token 的回答，就必须老老实实做 1000 次前向传播，一次都不能少。
第二、也是更隐蔽的问题是访存瓶颈。每次生成一个 token，都要把几百 GB 的模型权重从显存（HBM）读到计算单元里做一次矩阵乘法，然后只产出 1 个 token。也就是说，你花了巨大的力气”读”了整个模型，结果只换来一个 token。以 H100 上的 Llama-3.1-70B 为例，单个 token 的生成延迟大约 14 毫秒，一个 1000 token 的回答就要 14 秒。更尴尬的是，在单序列推理（batch=1）时，GPU 的计算单元利用率常常不足 10%——大部分时间都花在”等数据从显存里搬过来”上，而不是”算”上。
这就引出了推测解码赖以成立的那块基石：一个关键的、几乎是”免费”的特性。
核心洞察：验证是并行的，生成才是串行的
Transformer 有一个重要的性质：单次前向传播处理 k 个 token 的延迟，和只处理 1 个 token 的延迟差不多。原因正是上面说的访存瓶颈——读一遍模型权重这个动作，不管你这次要”算”多少个 token，读权重的代价是基本固定的。在内存带宽受限的区域里，一次算 1 个 token 和一次算 8 个 token，墙钟时间几乎一样。
这就打开了一扇门：既然”生成”必须串行，但”验证”可以并行，那我们能不能把一部分串行的生成，偷换成并行的验证？
推测解码的思路正是这样：用一个轻量的小模型（草稿模型，draft model）快速”猜”出接下来的几个 token，然后让大模型（目标模型，target model）一次性、并行地验证这几个猜测对不对。对的前缀直接收下，猜错的在第一个出错的位置停下来，由大模型自己补一个正确的 token。这样一轮下来，大模型只做了一次前向传播，却可能”通过”了好几个 token。
打个比方：大模型就像一个严格的老师，正常情况下学生每写一个字都要拿给老师看一次，老师看一个字要花很久。推测解码则让一个写字很快的”草稿助手”先一口气写下五六个字，再把这五六个字一起交给老师，老师一眼扫过去：”前三个字对了，第四个字错了。”——于是前三个字直接通过，只改第四个字。老师还是那个老师，答案还是那个答案，但效率高了好几倍。
两个模型、一篇奠基论文
推测解码的正式诞生，来自 2023 年两篇几乎同时独立提出的论文：
| 维度 | Leviathan et al.（Google） | Chen et al.（DeepMind） |
|---|---|---|
| 标题 | Fast Inference from Transformers via Speculative Decoding | Accelerating LLM Decoding with Speculative Sampling |
| arXiv | 2211.17192 | 2302.01318 |
| 发表 | ICML 2023 Oral | DeepMind 技术报告 |
| 核心术语 | Speculative Decoding | Speculative Sampling |
| 草稿长度参数 | γ（gamma） | K |
| 验证目标 | T5-XXL（11B） | Chinchilla 70B |
| 实测加速 | 2~3× | 2~2.5× |
两篇论文不约而同地证明了一件至关重要的事：这个方法无损——不管草稿模型猜得有多差，最终输出的 token 分布都和”直接用大模型生成”完全一致。这一点，是推测解码能被工业界大规模采用的根本原因：它不是一个”牺牲一点质量换速度”的近似，而是一个”数学上严格等价”的免费加速。
draft-then-verify：算法一步步拆开
推测解码的完整流程，可以分成三个阶段，每一轮循环里都会走一遍。
阶段一：Draft（起草）。给定已有的上下文，让草稿模型 q 自回归地生成 γ 个候选 token。因为草稿模型很小（比如目标模型 70B，草稿模型可能只有 7B 甚至更小），这一步快得几乎可以忽略。
阶段二：Verify（验证）。把”已有上下文 + 这 γ 个候选 token”整体作为输入，喂给大模型 p，做一次前向传播。大模型一次性输出这 γ+1 个位置各自的完整词表概率分布。
阶段三：Accept / Reject（接受 / 拒绝）。从第一个候选 token 开始逐个判断：对第 i 个候选 token xi，算出大模型给它概率 p(xi)、草稿模型给它概率 q(xi)，接受概率为 αi = min(1, p(xi) / q(xi))。用一个随机数 r（0 到 1 之间均匀采样）和 αi 比较：r 小于 αi 就接受这个 token，继续判断下一个；一旦在某一步拒绝，就从”大模型概率减去草稿模型概率”的残差分布里重新采样一个正确 token，然后停止本轮、进入下一轮。
这里的玄机在于那个接受概率公式 min(1, p/q)。当大模型比草稿模型更”看好”某个 token（p ≥ q）时，直接接受；当大模型没那么看好（p < q）时，也以 p/q 的概率”碰运气”接受。这个看似随意的设计，恰恰是保证最终输出无损的数学关键，下面专门讲。
为什么它是”无损”的：一段漂亮的证明
推测解码最让人放心的一点，是它有一个严格到不能再严格的保证：最终生成的 token 序列，其分布和”直接用大模型逐 token 采样”一模一样。这意味着你完全不用担心”加速之后模型变笨了”。
证明的核心只用一个单 token 的情形就能说清。假设我们要输出一个 token t，它有两种来源：
情况一：草稿模型采样到了 t，并且 t 被大模型接受了。这个概率是 q(t) × min(1, p(t)/q(t)) = min(q(t), p(t))。
情况二：草稿模型的候选被拒绝，t 是从”残差分布” max(0, p(t) − q(t)) 里重新采样出来的。这个概率是拒绝概率 × 残差里 t 的占比，整理后恰好等于 max(0, p(t) − q(t))。
把两种情况加起来：P(输出 t) = min(q(t), p(t)) + max(0, p(t) − q(t))。而数学上恒等式 min(a, b) + max(0, a − b) = a 对任意 a、b 都成立，所以 P(输出 t) = p(t)。
换句话说，无论草稿模型 q 有多差，最终输出都精确等于大模型 p 的分布。草稿模型猜得准，只是让”被接受的 token 更多”、从而更快；猜得再不准，也不会让输出偏离大模型一丝一毫。这个性质，让推测解码成为推理优化里少有的”没有代价的免费午餐”。
决定收益的关键：接受率和草稿模型
虽然无损，但推测解码不一定总能加速。它到底能快多少，取决于一个核心指标：接受率（acceptance rate）——草稿模型猜出来的 token，有多大比例能被大模型接受。
逻辑很直观：草稿模型猜得越准，一轮验证能通过越多 token，省下的大模型调用次数就越多；猜得越差，草稿模型等于白跑，反而还搭进去了草稿模型自己的开销。业界测出来的典型接受率是：
- 代码生成：65%~80%（代码有大量固定语法、常见句式，最好猜）；
- 结构化输出（JSON、SQL）：60%~75%；
- 英文聊天：50%~65%；
- 多语言或创意写作：35%~55%（越”出其不意”越难猜）。
有个经验红线：接受率一旦掉到 40% 以下，推测解码很可能就”净负收益”了——草稿模型的开销盖过了省下来的时间。所以落地时，接受率是一个必须先测、再决定开不开启的指标。
那怎么选草稿模型？有三条经验法则：
- 大小差 4~10 倍：草稿模型要明显比目标模型小，这样它起草的速度优势才够大；但也不能小到完全猜不中。
- 尽量同族：草稿模型和目标模型要来自同一模型家族（Llama 配 Llama、Qwen 配 Qwen）。因为同族模型共享相同的分词器（tokenizer）和相近的 token 分布，接受率会显著更高。跨家族配对是常见误区——分词器对不上会直接毁掉接受率。
- 数据同源：有条件的话，让草稿模型在目标模型训练数据相似的语料上做微调，能进一步提高接受率。
还有一个容易被忽略的限制：草稿模型和目标模型得共享显存、各自维护自己的 KV cache。这意味着推测解码更适合”有富余算力”的场景，在高并发大 batch 下收益会衰减——这点放到后面专门讲。
从”一个小模型”到一整片变体家族
原始推测解码要额外准备一个独立的草稿模型，这带来一个麻烦：多一个模型就多一份显存、多一份部署复杂度。于是研究者们围绕”草稿 token 从哪来”这个问题，发展出了一整片变体。
Medusa（美杜莎）：不给目标模型配小模型，而是在大模型上加几个额外的”预测头”，让它们直接预测”接下来第 1、2、3…个 token”。这样就不再需要独立的草稿模型了，属于”自推测”（self-speculative）路线。
EAGLE（1/2/3 代）：进一步利用大模型自己的隐藏状态来生成草稿 token，草稿质量更高、接受率也更高，据报告能带来 3~4 倍的加速。
Multi-Token Prediction（MTP，多 token 预测）：这个思路已经进入了前沿开源模型的标配。DeepSeek-V3 发布时自带 MTP 头，让它天然支持推测解码，成为旗舰开源模型部署的组成部分。
此外还有 SpecInfer（用树状结构一次性投机多个候选序列）、Lookahead Decoding（借用雅可比迭代做并行解码）、ReDrafter（循环神经网络草稿）等变体，各自在不同维度上优化草稿生成的效率。
这些变体万变不离其宗，都遵循同一个骨架：用一个”便宜”的方式快速产出候选，再用大模型一次性并行验收。理解了原始版本，再看任何变体都只是”候选从哪来”的差异。
真实效果：2~3 倍是常态，但要分场景
论文里报的是 2~3 倍，那生产环境里到底能拿到多少？综合多个部署实践的公开数据，一个诚实的答案是：取决于你的任务类型和草稿模型选得好不好。
以 70B~123B 量级的目标模型、3B~14B 量级的草稿模型为例，聊天类负载通常能拿到 p50 吞吐 1.8~2.5 倍的提升、p99 延迟 1.5~2 倍的改善；代码生成因为最好猜，能达到 2.5~3.5 倍；而长文本创意写作这类”高熵”任务，往往只有 1.3~1.7 倍。
值得注意的是，这些是”实测的真实数字”，而不是某些论文里假设了理想批处理或窄场景后才出现的 5~10 倍。AMD 在其 MI300X 加速卡上的官方测试也给出了类似结论：在 batch size 为 1 的情况下，推测解码相对朴素 LLM 推理能带来 1.3 倍到 3 倍的吞吐提升。
还有一个规律：目标模型越大、越慢，推测解码的百分比收益越明显。一个每秒只能吐 7 个 token 的 70B 模型，草稿模型那点几乎固定的开销相对它省下的时间微不足道；而一个每秒已经 75 token 的 8B 模型，本身就不怎么”带宽饥饿”，推测解码能榨出的空间就小得多。
哪些场景适合，哪些要慎重
推测解码不是万金油，它的收益高度依赖场景。适合的场景包括：
- 代码补全与生成：接受率最高、收益最稳定，是最”无脑开”的场景；
- 结构化输出：JSON、SQL、配置文件这类格式固定的输出，草稿模型很好猜；
- 长文本生成：token 数量大，加速效果能充分复利；
- 单用户、低并发的交互：此时”验证并行化”的红利最大。
反之，以下场景要慎重：
- 高并发大 batch：batch 很大时，GPU 已经靠”批处理”把带宽吃满了，推测解码”一次算多个 token”的优势被稀释，甚至可能负收益；
- 短问答：回答只有几十个 token，加速来不及”复利”，草稿模型的开销反而占比高；
- 高温度采样、创意写作：温度越高、越随机，草稿模型越难猜，接受率越低；
- 预填充（prefill）为主：推测解码只加速”生成（decode）”阶段，长 prompt 的预填充阶段它帮不上忙。
一个稳妥的落地姿势是：按任务类型分别测接受率，接受率低于 40% 的路由就关掉推测解码，高于阈值的才开启。很多生产团队正是这么做的——推测解码是”默认开、按需关”，而不是一刀切。
主流推理框架都已内置
好在今天的开发者基本不用从零实现推测解码——主流推理框架都已经把它做成了开箱即用的开关。
vLLM：作为最流行的开源推理框架之一，原生支持推测解码，可以指定草稿模型做加速。
NVIDIA TensorRT-LLM：支持 EAGLE-3、多 token 预测（MTP）等先进的推测解码技术，配合英伟达硬件能把收益压满。
SGLang：在结构化生成上做了大量创新，同样内置推测解码支持。
Hugging Face Transformers：在推理接口里提供了推测解码的 assistant model 参数，写几行代码就能挂一个草稿模型。
这意味着，对绝大多数用户来说，开启推测解码的复杂度已经从”实现一个算法”降到了”选一个合适的草稿模型、再配一个开关”。真正需要花心思的，只剩下那件最朴实的事：量一下你自己的负载，接受率到底是多少。
为什么它和量化、批处理”搭”而不”抢”
推测解码常常被拿来和另外两类推理优化放在一起讨论，但它们解决的是不同维度的问题，彼此可以叠加。
量化解决的是”每个权重占多少位”——通过降低精度减少显存占用和计算量；连续批处理（continuous batching）解决的是”GPU 的利用率”——让请求随时进出、GPU 别闲着；而推测解码解决的是”生成阶段的串行依赖”——把串行的生成偷换成并行的验证。三者不是非此即彼，而是可以从不同方向叠加：一个做了 FP8 量化、开了连续批处理的服务，照样能再叠加推测解码，进一步榨出延迟。
但也要清醒：推测解码和批处理之间确实存在张力。批处理越大，推测解码的边际收益越小，因为 GPU 已经不”闲”了。所以在高吞吐优先的离线批处理场景，推测解码的意义有限；而在低并发、延迟敏感的在线交互场景，它才是主角。理解这层关系，才能避免”盲目堆优化”。
小结：一个几乎没有代价的免费午餐
推测解码之所以值得被单独拿出来讲，是因为它在推理优化里占据了一个很特殊的位置：它是少数几个”数学上无损、几乎不需要改模型、却能实打实提速”的技术之一。它不要求你换硬件，不要求你接受精度损失，甚至不要求你重新训练——只要求你多准备一个小一点的草稿模型，就能把生成速度提升 2 到 3 倍。
它的核心思想只有一句话：既然验证可以并行、生成只能串行，那就用一个小模型把”生成”偷换成”验证”。这个洞察，从 2023 年两篇论文出发，已经演化成了 Medusa、EAGLE、MTP 一整片变体，并进入了 vLLM、TensorRT-LLM 等所有主流推理框架，成为生产部署的标配。
落到实践，记住三件事就够了：选一个和目标模型同族、小 4~10 倍的草稿模型；先测你真实负载的接受率，低于 40% 就关；在低并发、代码和长文本场景里优先开启。做到这三点，这顿”免费午餐”你就能吃得明明白白。
