推測式解碼 (Speculative Decoding)：讓 LLM 推理速度起飛的「快慢速」協作機制

在 LLM 的推理過程中，最令人頭痛的瓶頸始終是 **Token-by-Token** 的自迴歸生成模式。無論模型多麼強大，生成 100 個詞就必須經過 100 次完整的模型前向傳播。對於參數量巨大的模型（如 Llama-3-70B 或 GPT-4），這意味著極高的延遲。

為了打破這個瓶頸，學術界和產業界引入了一種極其巧妙的方案：**推測式解碼 (Speculative Decoding)**。

核心邏輯：用「快」猜，用「慢」驗

推測式解碼的核心思想是：**並非所有 Token 的預測難度都一樣。**

在一段話中，「我喜歡吃」後面大概率跟著「蘋果」或「米飯」，這種簡單的預測不需要 70B 的參數量也能完成；而涉及到複雜的邏輯推理或專業知識時，才需要大模型的全力支持。

推測式解碼透過引入一個**小規模的草稿模型 (Draft Model)** 和一個**大規模的目標模型 (Target Model)** 來協作：

1. **推測階段 (Speculation)：** 小模型（速度極快）連續預測接下來的 $K$ 個 Token（例如 5 個）。由於小模型輕量，這 $K$ 次前向傳播的時間遠低於大模型一次傳播的時間。

2. **驗證階段 (Verification)：** 大模型一次性將這 $K+1$ 個 Token 輸入，並行計算它們的機率分佈。

3. **接受與修正：** 大模型檢查小模型的預測是否在自己的機率分佈可接受範圍內。

- 如果前 3 個是對的，第 4 個錯了 $\rightarrow$ 接受前 3 個，修正第 4 個，丟棄後續所有推測結果。

- 如果全部正確 $\rightarrow$ 一次性產出 $K+1$ 個 Token。

工程實作中的關鍵權衡

在實際部署推測式解碼時，工程師需要面對三個核心挑戰：

1. 草稿模型的選擇 (The Draft Model Gap)

如果小模型太弱，預測準確率低，大模型會頻繁地拒絕 (Reject) 推測結果並觸發重新生成。此時，推測式解碼不僅不能加速，反而因為增加了小模型的運行開銷而導致整體延遲增加。理想的草稿模型應該是目標模型的「精簡版」（如透過蒸餾得到），在保持基本語言分佈一致的前提下盡可能輕量。

2. 接受準則 (Acceptance Criterion)

不能簡單地要求大模型輸出的 Token 與小模型完全一致（因為 LLM 是機率性的）。通常採用 **$\text{argmax}$** 或 **核採樣 (Nucleus Sampling)** 的變體。只要小模型選出的 Token 在大模型的分佈中具有足夠的機率權重，就被視為「正確」。

3. KV Cache 的同步

為了實現高效驗證，大模型必須能夠快速處理推測序列。這意味著 KV Cache 需要支援快速的追加和回滾操作。當推測失敗時，系統必須能迅速將 Cache 回退到最後一個被接受的 Token 位置。

實戰效果與適用場景

推測式解碼在以下場景中表現最為顯著：

- **低熵文字生成：** 如程式碼補全、格式化文件、重複性較高的對話。在這種場景下，小模型的命中率極高，加速比可達 $2\times \sim 3\times$。

- **高延遲 API 服務：** 當使用者對首字延遲 (TTFT) 不敏感但對整體吞吐量有要求時，推測式解碼能顯著提升每秒生成的 Token 數 (TPS)。

然而，在進行深度邏輯推理或創意寫作時，由於 Token 的不可預測性增強，推測式解碼的加速效果會明顯下降。

總結

推測式解碼本質上是一種**用計算換時間**的策略。它承認了 LLM 推理中存在冗餘計算的事實——我們不需要每次都動用整個大腦來決定下一個詞是不是「的」。透過建構一套高效的「快慢協作」機制，AI 系統能夠在保證輸出品質完全不打折的前提下，大幅度降低推理延遲。