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。