Speculative decoding:让推理快 2-3 倍

如果你做过 LLM 推理 benchmark,发现延迟被「token 一个一个生成」主宰 —— 每个 token 都要完整 forward pass 一次模型 —— 那你就找到了 speculative decoding 的对的舞台。它是过去三年最有效的推理优化。OpenAI、Anthropic、Google 内部都在用,vLLM、SGLang、TGI 自架版本也都有。

洞见很优雅:LLM 生成的大部分 token 都是简单的,小模型也猜得到。那为什么不让小模型猜,只在需要验证的时候才花大模型的算力?

根本瓶颈

H100 上 70B 参数模型单流服务生成大约 80-100 tokens/sec。为什么这么慢?

70B 参数一次 forward pass 从 VRAM 读约 140GB 权重(fp16)。
H100 HBM 带宽约 3TB/s。
理论下限:140 / 3000 = 每次 forward pass 47ms。
一次 forward pass = 一个 token。实际 overhead 推到 10-12ms。
1000ms / 10ms = 100 tokens/sec。

生成每个 token 是个内存带宽问题,不是算力问题。GPU 算力大部分时间闲置,在等权重从 VRAM stream 过来。如果你可以在一次 forward pass 里验证多个 token,内存成本就被摊掉了。

Speculative decoding 做的就是这件事。

算法

核心想法,Leviathan et al.(2022)跟 Chen et al.(2023):

一个草稿模型(小、快)autoregressively 生成 K 个候选 token,便宜。
目标模型(大、慢)并行处理原 prompt + K 个草稿 token —— 一次 forward pass。
比较目标模型每个位置的分布跟草稿模型的。接受最长的 prefix,只要草稿在那段「概率上够接近」。
第一个被拒绝的位置,从目标模型的分布采样。
把草稿剩下的丢掉。

净结果:每次目标模型 forward pass,接受 2-4 个 token 而不是 1 个。即使加上跑草稿模型的成本,还是 2-3× 加速。

接受测试(Chen et al 的无损变体)在数学上等于只从目标模型采样 —— 输出分布完全一样。这不是近似,你拿到一样的答案,只是更快。

为什么有用

大部分文字是可预测的。「法国的首都是巴」—— 下一个 token 几乎肯定是「黎」。小模型轻松答对。大模型只在真正不确定的分支被调用:罕见人名、技术术语、创意答案的前几个 token。

实务上,常见工作负载 60-80% 草稿 token 被接受。每轮 4 个草稿 token,平均每次目标 forward pass 接受约 3 个,约 3× 加速。

挑草稿模型

草稿模型必须:

跟目标同 tokenizer。 不然分布没法比。
比目标小很多。 70B 目标配 7B-1B 草稿是甜蜜点。草稿要跑得比目标快 5-10×。
分布合理对齐。 微调差异很大的草稿模型接受率很低(< 30%),加速消失。

2026 年标准配对:

Llama 3.3 70B(目标)+ Llama 3.2 1B(草稿)。 通常 ~3× 加速。
Qwen 2.5 72B + Qwen 2.5 0.5B。 通常 ~2.5×。
Claude / GPT-5 / Gemini 3。 厂商跑自己内部草稿模型,你不用挑。

你会听到的变体

EAGLE / EAGLE-2。 草稿模型不是独立小 LLM,而是接在目标 hidden state 上的额外 head,跟目标一起联合训练。接受率更高(常 70%+)。2025 认真自架者的默认。
Medusa。 多个预测 head 接在目标上,各自预测 K 个位置以后。比独立草稿便宜,接受率略差。
Lookahead decoding。 Self-speculation:模型用自己过去的 activation 提议自己的续写,不需要草稿模型。
Tree attention / multi-draft。 树状生成多条草稿,接受最佳路径。更复杂,加速 +10-20%。

2026 大部分团队:EAGLE-2 是务实甜蜜点。最佳加速、vLLM 跟 SGLang 都好支持、好设定。

vLLM 设定(真实范例)

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.3-70B-Instruct \
  --speculative-model meta-llama/Llama-3.2-1B-Instruct \
  --num-speculative-tokens 5 \
  --use-v2-block-manager

就这样。一对 flag 就开了。vLLM 2026 也支持 EAGLE:

  --speculative-model yuhuili/EAGLE-Llama-3-70B \
  --num-speculative-tokens 5

看 log 里的接受率。低于 50% 代表草稿不对盘,换个草稿模型。

取舍

Speculative decoding 不是免费。三个真实成本:

内存。 同一张 GPU 上现在跑两个模型。70B + 1B 草稿多 5-10% VRAM。EAGLE 加得少(只多一个 head)。
吞吐 vs 延迟。 Speculative decoding 优化单流延迟。高批次吞吐服务时可能变差 —— GPU 本来就被并行工作饱和,加草稿运算抢走容量。vLLM 在某些配置下高负载时会自动关掉。
设定复杂度。 挑对草稿、tokenizer 对齐、配接受率。第一次加 1-2 天。

什么时候不要用 speculative decoding

高并发流量,目标是吞吐。 纯批次更有效。
超低延迟需求而你不需要 70B。 直接用小模型端到端。
小模型(7B 以下)。 草稿模型 overhead 吃掉收益。
你在用托管 API。 厂商内部管。OpenAI / Anthropic / Gemini API 没法明确开,厂商根据流量 pattern 决定。

真实数字

我在 H100 单张上 Llama 3.3 70B 配各种草稿量到的加速:

没 speculative:单流 85 tok/sec。
- Llama 3.2 1B 草稿,5 token:220 tok/sec,~2.6× 加速,65% 接受率。
- EAGLE-Llama-3 head,5 token:280 tok/sec,~3.3× 加速,73% 接受率。
高并发(16 流)EAGLE:总吞吐比没 spec 掉 5%。(批次服务别用。)

对用户面对的聊天,延迟重要时这是「感觉快」跟「感觉慢」的差别。有 speculative 70B 感觉像 30B,没有的话延迟下限就是延迟下限。

接下来会出现的东西

2026 年推理优化前沿:

Prompt-level speculation。 用户前一轮变成 tool use 场景的部分草稿。
训练时 multi-token prediction(MTP)。 DeepSeek V3 等模型训练时就原生预测每位置多 token,让 speculative decoding 更有效。
并行采样 + 验证。 并行生成 K 个完整候选响应,挑最好的 —— 不同的加速轴。

Speculative decoding 已经是 table stakes。自架而且延迟重要的话,你应该在用。

下一步

Fast Inference from Transformers via Speculative Decoding(Leviathan et al, 2022)。
Accelerating Large Language Model Decoding with Speculative Sampling(Chen et al, 2023)。
EAGLE / EAGLE-2 论文(Li et al, 2024)。
vLLM 跟 SGLang 的 speculative decoding 文档。
查这些词:Medusa、Lookahead decoding、EAGLE、multi-token prediction。