我的知識庫

AI · 2026-07-09

閱讀時間約 12 分鐘

推測解碼（Speculative Decoding）是目前把大型語言模型推論速度拉高 2 到 3 倍、又不損失輸出品質的主流做法。它的核心觀察很簡單：自迴歸模型一次只吐一個 token，但驗證多個 token 幾乎不用額外時間，因為 GPU 在單 token 生成時算力嚴重閒置。用一個「便宜的草稿模型」先猜好幾個 token，再讓「昂貴的目標模型」一次平行驗證，就能把被閒置的算力換成吞吐量。

2025 到 2026 年這項技術已經從論文走進生產環境。vLLM、TensorRT-LLM、SGLang 都內建了推測解碼支援，NVIDIA 在 H200 上展示了 3.6 倍吞吐量提升。更關鍵的是，EAGLE-3 這類方法把「草稿命中率」推到新高，讓推測解碼不再只是實驗室數字，而是任何自架 LLM 服務都該打開的預設優化。今天拆解它的運作原理、主流方法差異，以及實際上線時的取捨。

📖 學（核心）

為什麼推測解碼不會改變輸出結果

推測解碼最反直覺的一點：它加速了推論，卻能保證輸出分布與原模型「完全一致」。這不是近似，而是數學上等價。

運作流程分成兩步。草稿階段（draft），一個小模型或額外的預測頭快速生成 k 個候選 token，例如 k=4。驗證階段（verify），目標模型把這 k 個 token 一次餵進去做一次前向傳播，同時算出每個位置的真實機率分布。接著用「拒絕採樣」（rejection sampling）逐一比對：如果草稿 token 在目標模型的分布下夠可能，就接受；一旦某個位置被拒絕，就從一個修正後的分布重新採樣該位置，並丟棄後面所有草稿 token。

這個拒絕採樣的設計是關鍵。它保證最終被接受的 token 序列，其機率分布與「直接用目標模型逐 token 生成」完全相同。所以推測解碼不是拿品質換速度，而是純粹的效率壓榨——把原本浪費的平行算力用起來。實務上，如果草稿模型每輪平均被接受 2.5 個 token，那麼原本要跑 2.5 次目標模型前向傳播的工作，現在只要 1 次，速度自然接近 2.5 倍（扣掉草稿本身的開銷）。

決定加速比的核心指標叫「接受率」（acceptance rate），也就是草稿 token 被目標模型接受的比例。接受率愈高，加速愈明顯；草稿模型與目標模型愈像，接受率愈高。這就是後續各種方法拼命優化的方向。

三大流派：草稿模型、EAGLE、n-gram

推測解碼的方法可以依「草稿從哪來」分成幾個流派，各有適用場景。

獨立草稿模型（draft model）是最原始的做法。找一個與目標模型同家族但小很多的模型當草稿，例如用 Llama-1B 當 Llama-70B 的草稿。優點是概念直觀，缺點是要額外載入一個完整小模型，佔顯存，而且小模型與大模型的分布差距可能不小，接受率有限。

EAGLE 家族是目前的 SOTA。它不另外訓練一個獨立模型，而是在目標模型的特徵層（feature）上接一個輕量預測頭，直接重用目標模型已經算出的隱藏狀態來預測下一步特徵，再解碼成 token。EAGLE-2 引入了動態草稿樹（dynamic draft tree），不再是線性猜一條 token 鏈，而是同時展開多條候選分支成樹狀，大幅提高單輪命中的 token 數。EAGLE-3 更進一步，放棄了原本「預測特徵」的做法，改成直接預測 token，並用多層特徵融合搭配一種叫 training-time test 的訓練技巧，讓草稿頭能吃下更大的訓練資料量而持續受益。結果是接受率再上一個台階。

n-gram 與 suffix decoding 是最輕量的一派，不需要任何額外權重。它們純粹用演算法：根據已生成的上下文，在提示或歷史中查找重複出現的片段當作草稿。這對「輸出常引用輸入」的任務特別有效，例如摘要、程式碼補全、RAG 引用原文。它的加速幅度不如 EAGLE，但零訓練成本、零額外顯存，適合尖峰流量時開啟而不增加負擔。

生產環境的真實取捨

推測解碼不是打開就一定變快，批次大小（batch size）是最關鍵的變數。

推測解碼的紅利來自「單 token 生成時 GPU 閒置」。當服務的批次很小（例如低併發、單使用者互動），GPU 確實閒置，推測解碼能大幅降低延遲。但當批次很大、併發很高時，GPU 本來就被塞滿了，推測解碼多做的草稿與驗證計算反而變成負擔，可能拖慢整體吞吐。因此許多生產系統會做「自適應」策略：低負載時開啟推測解碼降延遲，高負載時關閉或縮小草稿長度。

草稿長度 k 也要調。k 太小，加速有限；k 太大，一旦前面某個 token 被拒絕，後面全部白算，浪費更多。最佳 k 取決於接受率，接受率高的模型可以用比較長的草稿。EAGLE 這類方法還要注意部署限制：EAGLE 的草稿頭通常要在 tensor parallel size 為 1 的情況下跑，主模型才能用張量平行，這在多卡部署時需要特別配置。

實務落地建議照這個順序評估。先試 n-gram，因為零成本、對特定任務立即見效；需要更高加速再上 EAGLE-3，但要接受它需要對應目標模型的預訓練草稿檢查點，不是每個模型都現成有。最後務必在自己的真實流量分布下量測，不要只看論文的理想數字——論文常在批次為 1 的極端條件下測接受率，而你的線上批次可能完全不同。

🧠 記

  • 推測解碼用「小模型猜、大模型一次平行驗證」的方式加速，靠的是壓榨單 token 生成時閒置的 GPU 算力。
  • 拒絕採樣保證輸出分布與原模型「完全等價」，是加速而非近似，不損失品質。
  • 核心指標是接受率（acceptance rate）：草稿 token 被接受的比例愈高，加速愈明顯。
  • 三大流派：獨立草稿模型（直觀但佔顯存）、EAGLE 家族（SOTA，重用特徵層）、n-gram/suffix（零成本、對摘要與程式碼補全特別有效）。
  • EAGLE-3 放棄預測特徵改為直接預測 token，用多層特徵融合把接受率再推高。
  • 批次大小是關鍵取捨：低併發時大幅降延遲，高併發時反而可能拖慢，需自適應開關。
  • vLLM、TensorRT-LLM、SGLang 都已內建，2025–2026 已是生產標準做法。

✍️ 實踐

  1. 先在自己的 LLM 服務上量測目前的 baseline 延遲與吞吐，記錄不同併發數下的數字，作為後續比較基準。
  2. 從 n-gram 推測解碼開始試，在 vLLM 設定 {"method": "ngram", "num_speculative_tokens": 4, "prompt_lookup_min": 2, "prompt_lookup_max": 5}，特別針對摘要、RAG、程式碼補全這類「輸出常引用輸入」的任務觀察加速。
  3. 若需要更高加速，查找目標模型是否有現成的 EAGLE-3 草稿檢查點，啟用時記得把 speculative_draft_tensor_parallel_size 設為 1，主模型才用張量平行。
  4. 掃描草稿長度 k（例如 2、4、8），對每個值量接受率與實際加速比，找出你這個模型與任務的最佳點，而不是照抄論文數字。
  5. 針對真實流量做壓測：分別在低併發與高併發下測，確認高負載時推測解碼沒有反而拖慢，必要時實作「高負載自動關閉」的自適應策略。

🔗 延伸學習

💬 問 AI

我在自架一個 LLM 推論服務，模型是 ｛請填入模型名稱與規模，例如 Llama-3-70B｝，
部署在 ｛請填入硬體，例如 2 張 H100｝，主要任務是 ｛請填入任務，例如 RAG 問答／程式碼補全／摘要｝，
典型併發量約 ｛請填入併發數或每秒請求數｝。

請幫我評估推測解碼（speculative decoding）的導入策略：
1. 以我的任務與批次特性，n-gram、EAGLE-3、獨立草稿模型三者哪個最合適？為什麼？
2. 建議的初始草稿長度 k 與量測接受率的方法。
3. 高併發時是否該關閉推測解碼？若要做自適應開關，判斷門檻怎麼設？
請給出具體的 vLLM 設定範例與一份上線前的量測檢查清單。

反向連結