我的知識庫

AI · 2026-07-17

閱讀時間約 8 分鐘

推測解碼(Speculative Decoding)讓大型語言模型在不改變輸出品質的前提下加速 2 到 4 倍,核心手法是用一個「小草稿模型」先猜好幾個 token,再讓「大目標模型」一次平行驗證這串猜測。它在 2025 到 2026 年間從研究實驗變成 vLLM、SGLang、TensorRT-LLM 的內建標配,是目前推論優化最實用的技術之一。

📖 學(核心)

為什麼一次只吐一個字這麼浪費

自回歸(autoregressive)生成的本質是「一次前向傳播只產生一個 token」。對大模型來說,每一步的瓶頸不是算力,而是把幾百 GB 的權重從 HBM 記憶體搬進運算單元的頻寬成本。既然你每一步都要付這筆搬運費,只換來一個 token 實在划不來。推測解碼的洞見就在這裡:如果能在同一次權重載入中「驗證好幾個候選 token」,等於把昂貴的記憶體頻寬攤提到多個 token 上,吞吐量自然上去。這也是為什麼推測解碼在 batch size 小、記憶體受限的場景(例如單使用者互動、on-device 推論)效益最明顯。

Draft-and-Verify:草稿與驗證兩步驟

標準流程分兩階段。第一階段用一個便宜的草稿模型(可以是同家族的小模型,例如用 Llama-1B 當 70B 的草稿),快速自回歸生成 k 個候選 token。第二階段把「原始輸入 + 這 k 個候選」一次餵給大目標模型做單次平行前向傳播,同時算出每個位置的機率分布。接著用一套拒絕採樣(rejection sampling)規則逐一比對:只要草稿 token 落在目標模型認可的機率範圍內就接受,一遇到不合格的 token 就丟棄其後全部,並用目標模型的分布重新採一個 token 補上。關鍵在於這套接受/拒絕的數學設計能保證「最終輸出分布與原始大模型逐 token 生成完全等價」,也就是位元級(byte-identical)一致,不是近似,不會犧牲品質。

從獨立草稿到自我推測:Medusa 與 EAGLE

外掛一個獨立草稿模型要額外佔記憶體、還要對齊詞彙表,於是出現「自我推測」路線。Medusa 直接在目標模型上加裝多個平行解碼頭(decoding heads),每個頭預測未來不同距離的 token,免除獨立草稿模型;缺點是各頭之間不共享上下文,在較長的推測長度與多變 prompt 下接受率掉得快。EAGLE 系列則更進一步,把目標模型的深層隱藏狀態(hidden states)餵給一個輕量草稿頭,並用樹狀草稿(draft tree)一次展開多條候選路徑。2026 年的 EAGLE-3 在程式碼與指令遵循任務上接受率達 0.80 至 0.88,在 H100/H200 上帶來 3 到 4 倍吞吐,實測比 EAGLE-2 與 Medusa-2 快 15 至 25%。接受率(acceptance rate)是這條路線的核心指標:草稿被接受的比例越高,平均每次前向傳播吐出的 token 越多,加速越明顯。

2026 年的新進展:更省、更快、更聰明

這個領域仍在快速迭代。Apple 的 Mirror Speculative Decoding 嘗試打破草稿與驗證的序列瓶頸,讓兩者更能重疊平行。DeepSeek 的 DSpark 宣稱在 V4、Qwen、Gemma 上帶來 57 至 85% 的加速,且輸出位元完全一致、無需重新訓練。也有像 Cacheback 這種「只靠快取、不需額外草稿模型」的極簡路線,直接從歷史 token 的 n-gram 快取猜候選。Google 則在回顧文章中分享,推測解碼早已部署在 AI Overviews 等產品,支撐大規模低延遲的實際流量。研究前沿還在探索如何直接以「序列接受率」而非「token 相似度」來訓練草稿模型,讓草稿更貼近目標模型真正會接受的東西。

🧠 記

  • 推測解碼加速的來源是攤提記憶體頻寬,不是減少計算量,所以在小 batch、記憶體受限時效益最大。
  • Draft-and-Verify 兩步驟:草稿模型猜 k 個 token,目標模型一次平行驗證。
  • 拒絕採樣的數學設計保證輸出分布與原始大模型「完全等價」,不犧牲品質。
  • 接受率(acceptance rate)是核心指標:越高代表每次驗證吐出的 token 越多。
  • Medusa 加平行解碼頭免用獨立草稿;EAGLE-3 用隱藏狀態+樹狀草稿,接受率與穩定度更高。
  • 2026 年 EAGLE-3 在 H100 上可達 3 到 4 倍吞吐;DeepSeek DSpark 宣稱 57 到 85% 加速。
  • 已是 vLLM、SGLang、TensorRT-LLM 內建功能,可直接開啟使用。

✍️ 實踐

  1. 在 vLLM 啟動時加上推測解碼設定,選一個同家族的小模型當草稿(例如 --speculative-model 指定小版本),先跑 baseline 對照吞吐。
  2. 觀測接受率與每步平均接受 token 數(vLLM 有相關指標),接受率偏低就代表草稿與目標分布不夠貼近。
  3. 調整推測長度 k:太短加速有限,太長會浪費被拒絕的草稿計算,依你的接受率找甜蜜點。
  4. 若不想維護獨立草稿模型,改用 EAGLE-3 或 n-gram/prompt-lookup 這類自我推測方案,少一個模型要管。
  5. 用固定 seed 對同一批 prompt 比對「開啟前後的輸出」,確認位元級一致,驗證品質沒被動到。
  6. 針對你的實際流量分布(對話 vs. 程式碼 vs. 長文)分別量測加速比,不同任務接受率差異很大。

🔗 延伸學習

💬 問 AI

我想在 {推論框架,例如 vLLM} 上為 {目標模型} 開啟推測解碼。
請幫我:
1. 建議合適的草稿模型或自我推測方案(例如 EAGLE-3),並說明理由。
2. 給出啟動指令與關鍵參數(推測長度 k、草稿模型設定)。
3. 說明我該監測哪些指標(接受率、每步接受 token 數)來調校。
4. 提醒在 {我的任務類型:對話/程式碼/長文} 下可能的接受率落差與注意事項。

反向連結