Draft Model（草稿模型）

3 秒看懂

Draft Model 是推測解碼（Speculative Decoding）中的”快速猜測者”——用一個小而快的模型先生成一串候選 token，再交給大型模型一次性並行驗證，命中即用，未命中則回退修正。整個過程保證輸出分佈與大型模型完全一致，但推論吞吐顯著提升。

一句話等價：用”猜得快 + 查得準”替代”每一步都慢慢算”。

3 分鐘產業解釋

問題：LLM 推論為什麼慢？

大語言模型推論的核心瓶頸是自迴歸解碼：每生成一個 token 都需要完成一次完整的前向傳播（讀取全部權重、搬運全部 KV Cache），而每步只產出 1 個 token。這意味著——

• 計算量大但利用率低：單 token 解碼時，GPU 的算力（FLOPS）利用率極低，瓶頸在視訊記憶體頻寬（memory-bound），而非計算（compute-bound）。
• 延遲與吞吐的矛盾：想降低單請求延遲，往往要犧牲批處理大小；想提升吞吐，就要加大 batch，但延遲隨之上升。

一個 70B 引數模型在單張高階 GPU 上，單請求生成速度通常在每秒幾十個 token 的量級 [業界實測區間，具體取決於硬體、量化方案與 batch 大小]。

Draft Model 的破局思路

Draft Model 的核心洞察：驗證（verification）比生成（generation）快得多。

• 大型模型做一次前向傳播，可以同時處理多個輸入 token（prefill/驗證階段天然並行）。
• 但自迴歸生成階段只能一次一個 token，因為每一步的輸入依賴上一步的輸出。

Draft Model 就是把”一次一個”的慢路徑，交給一個輕量模型去完成（因為它小、快），然後讓大型模型”一次性稽核”這串候選 token。如果草稿質量足夠好，大型模型一步就能”吞下”多個 token，等效於跳過了多次自迴歸步驟。

產業意義：在不改變模型權重、不損失輸出質量的前提下，直接提速推論 2-3 倍 [典型範圍，取決於任務與草稿模型質量]，這對降低推論服務成本、改善使用者體驗有立竿見影的效果。

15 分鐘專家深入

1. 推測解碼的完整流程

推測解碼（Speculative Decoding）由 Leviathan et al.（2023, “Fast Inference from Transformers via Speculative Decoding”）和 Chen et al.（2023, “Accelerating Large Language Model Decoding with Speculative Sampling”）分別獨立提出並形式化。其完整流程如下：

┌─────────────────────────────────────────────────────────┐
│  Step 1: Draft 模型自迴歸生成 K 個候選 token               │
│  (x₁, x₂, ..., x_K)                                     │
│  → 因為 Draft 模型小，這 K 步很快                          │
│                                                          │
│  Step 2: Target 模型一次性並行驗證這 K 個 token             │
│  → 輸入 [已有上下文, x₁, x₂, ..., x_K]                    │
│  → 一次前向傳播，同時輸出 K 個位置的 logits                  │
│                                                          │
│  Step 3: 從左到右逐位置做接受/拒絕判定                      │
│  → 第 1 個位置：根據接受準則判定，若接受 → 繼續              │
│  → 若某位置被拒絕 → 從修正分佈中取樣一個新 token，停止        │
│  → 若全部 K 個都接受 → 額外從 Target 模型分佈中再取樣 1 個   │
│                                                          │
│  一輪結束，輸出 1 ~ K+1 個 token                           │
└─────────────────────────────────────────────────────────┘

2. 接受-拒絕準則：為什麼輸出分佈完全正確？

這是推測解碼最關鍵的理論保證。設：

• Target 模型在位置 $t$ 的輸出分佈為 $p(x)$
• Draft 模型在位置 $t$ 的輸出分佈為 $q(x)$
• Draft 模型提議的 token 為 \hat{x}

接受準則：

$$ \text{Accept with probability } \min\left(1, \frac{p(\hat{x})}{q(\hat{x})}\right) $$

若被拒絕，從修正分佈中重新取樣：

$$ \text{Sample } x \text{ from } \text{norm}\left(\max(0,\ p(x) - q(x))\right) $$

數學證明的關鍵（直覺）：

• 當 Draft 模型”猜對了”（即 p(\hat{x}) \geq q(\hat{x})）：接受機率為 1，直接採納。
• 當 Draft 模型”高估了”某個 token 的機率（p(\hat{x}) < q(\hat{x})）：以 p(\hat{x})/q(\hat{x}) 的機率接受；否則拒絕並從差值分佈中重取樣。
• 綜合來看，每個位置最終取樣得到的 token 的邊際分佈恰好等於 $p(x)$。

核心結論：推測解碼是無損的。它不會改變大型模型的輸出質量，不會改變取樣分佈，沒有近似誤差。

3. 為什麼不是簡單地用小模型代替大型模型？

這是一個常見的直覺疑問。答案有三層：

維度	簡單用小模型	推測解碼（Draft + Target）
輸出質量	降級（小模型能力弱）	與大型模型完全一致
適用場景	可接受質量損失時	要求質量零損失時
速度提升來源	模型小所以快	驗證比生成快 + 並行化

推測解碼的核心價值在於：在零質量損失的前提下獲得加速。這不是在速度和質量之間做 trade-off，而是利用”驗證的計算特性優於生成”這一不對稱性來”白撿”速度。

4. 加速比取決於什麼？

推測解碼的理論加速比（忽略 overhead 的理想情況）：

$$ \text{Speedup} \approx \frac{1}{1 - \alpha} \quad (\text{其中 } \alpha \text{ 為平均接受率}) $$

更精確地，如果平均每輪 Draft 步數為 $K$，平均接受的 token 數為 E[\text{accepted}]，則：

$$ \text{有效 tokens/step} = E[\text{accepted}] + 1 \quad (\text{最後一步的修正取樣}) $$

而驗證 $K$ 個 token 的 Target 前向傳播代價，大致等於一次自迴歸生成的代價（因為驗證階段是 compute-bound 的並行操作，而非 memory-bound 的逐 token 生成）。因此，如果平均接受率足夠高，一輪就能”吞下”多個 token，實現加速。

關鍵影響因素：

• Draft 模型與 Target 模型的分佈對齊程度：越接近，接受率越高，加速越大。
• 任務型別：翻譯、摘要等”確定性較高”的任務接受率通常高於開放生成。
• Draft 步數 K：K 越大，可吞下的 token 潛力越大，但 K 太大會導致被拒絕的 token 浪費增加。
• Target 模型的 memory-bound 程度：模型越大、batch 越小，memory-bound 越嚴重，驗證的相對優勢越明顯。

5. 額外開銷

推測解碼並非”免費午餐”，需要付出以下代價：

• Draft 模型本身的推論開銷：需要在 GPU 上額外載入一個模型（或使用同一模型的簡化路徑）。
• KV Cache 管理複雜度：Draft 階段產生的 KV Cache 可能被拒絕，需要回滾機制。
• GPU 視訊記憶體佔用：如果 Draft 是獨立模型，需要額外視訊記憶體。
• 實現複雜度：需要修改推論引擎的排程邏輯。

因此，實際加速比通常低於理論值，典型在 1.5x-3x 範圍 [業界報告與學術實驗的常見區間]。

---

技術原理

完整數學架構

問題定義

給定一個大語言模型（Target）M_p 引數量為 \theta_p，其在位置 $t$ 的輸出分佈為 p_t(x | x_{<t})。自迴歸生成的每一步需要一次完整的前向傳播 f_p，代價為 C_p。

目標：在不改變 p_t 的前提下，減少呼叫 f_p 的次數。

演算法：Speculative Decoding

演算法：Speculative Decoding (一步)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

輸入：字首序列 x_{<t}，Draft 模型 M_q，Draft 步數 K

1. 【Draft 階段】（快速，序列）
   for i = 1 to K:
       根據 q(· | x_{<t+i}) 取樣得到 x̂_i
       將 x̂_i 追加到序列

2. 【Verify 階段】（並行，單次前向傳播）
   將 [x_{<t}, x̂_1, x̂_2, ..., x̂_K] 輸入 Target 模型 M_p
   一次前向傳播，得到每個位置 i ∈ {1,...,K} 的分佈 p_t+i

3. 【Accept/Reject 階段】（逐位置，CPU 上可完成）
   for i = 1 to K:
       以機率 min(1, p_t+i(x̂_i) / q(x̂_i)) 接受 x̂_i
       若拒絕：
           從 norm(max(0, p_t+i(·) - q(·))) 中取樣 x_new
           輸出 [x̂_1, ..., x̂_{i-1}, x_new] → 結束本輪
   若全部接受：
       從 p_{t+K+1}(·) 中額外取樣一個 token x_{K+1}
       輸出 [x̂_1, ..., x̂_K, x_{K+1}] → 結束本輪

輸出：本輪生成的 token 序列（長度 ∈ [1, K+1]）

並行驗證的計算結構

┌────────────────────────────────────────────────────────┐
│                   Target Model Forward Pass             │
│                                                        │
│  輸入 token 序列 (長度 N = 已有上下文 + K 個候選):        │
│  [tok_1, tok_2, ..., tok_N, x̂_1, x̂_2, ..., x̂_K]       │
│                                                        │
│  ┌─────────────────────────────────────────────────┐   │
│  │        Transformer Layers (L 層)                 │   │
│  │  ┌─────────────────────────────────────────┐    │   │
│  │  │  Self-Attention (含 KV Cache 增量計算)    │    │   │
│  │  ├─────────────────────────────────────────┤    │   │
│  │  │  FFN                                     │    │   │
│  │  ├─────────────────────────────────────────┤    │   │
│  │  │  ... 重複 L 層                           │    │   │
│  │  └─────────────────────────────────────────┘    │   │
│  └─────────────────────────────────────────────────┘   │
│                                                        │
│  輸出: 每個位置的 logits → 各位置分佈 p(x)               │
│  → 一次前向傳播產出 K 個驗證結果                          │
└────────────────────────────────────────────────────────┘

為什麼驗證比生成快？ 在驗證階段，K 個 token 可以一起做 attention 計算（類似 prefill 的計算模式），GPU 計算利用率高。而在自迴歸生成階段，每步只處理 1 個 token，計算量小但每步都要搬運全部權重，是典型的 memory-bound 操作。驗證 K 個 token 的耗時遠小於 K 次單獨自迴歸生成的耗時。

接受率分析

設 Draft 分佈 $q(x)$ 與 Target 分佈 $p(x)$ 的 total variation distance 為 \delta = \text{TV}(p, q)，則期望接受率的下界為：

$$ E[\text{acceptance rate}] \geq 1 - \delta $$

因此，Draft 模型越接近 Target 模型，接受率越高。

---

技術演進史

時間	里程碑	關鍵內容
2022-2023	原始論文	Leviathan et al. (Google) 和 Chen et al. (DeepMind) 分別獨立提出推測解碼的數學架構與演算法 [可檢索學術論文確認]
2023	獨立 Draft 模型應用	社群開始用小模型（如 68M/1B）作為大型模型（如 7B/70B）的 Draft 模型進行推論加速
2023	Self-Speculative Decoding	提出讓大型模型自己做 Draft（如跳過某些層、使用早期退出），避免載入額外模型 [學術論文方向]
2023-2024	Medusa	Cai et al. 提出在 Target 模型上附加多個預測頭（MLP heads），每個頭並行預測未來不同位置的 token，本質上是一種”內建 Draft”方案
2024	EAGLE / EAGLE-2	Li et al. 提出利用 Target 模型的特徵向量（而非僅 token embedding）來訓練 Draft 頭，在特徵空間進行外推，顯著提升接受率
2024	Lookahead Decoding	另一種無需 Draft 模型的加速思路，利用 Jacobi 迭代並行生成多個 token
2024-2025	引擎整合	vLLM、TensorRT-LLM、SGLang 等主流推論引擎開始原生支援推測解碼，Draft Model 從論文走向生產部署

---

技術路線對比

路線	Draft 來源	需要額外訓練？	需要額外視訊記憶體？	典型接受率	實現複雜度	代表方案
獨立小模型	同系列更小的模型（如 TinyLlama-1.1B Draft → LLaMA-70B Target）	否（使用已有小模型）	是（需載入兩個模型）	中高（取決於小模型質量）	中	Leviathan et al.; Chen et al.
同模型層剪枝 / 早退	Target 模型的前幾層（early exit）	否	否（複用同一模型）	中	低	Self-Speculative Decoding
多頭預測（Medusa）	Target 模型上附加多個並行預測 MLP 頭	是（需訓練 Draft 頭）	否（頭很小）	中	中	Medusa
特徵外推（EAGLE）	基於 Target 模型中間特徵的 Draft 頭	是（需訓練 Draft 頭）	否（頭很小）	高	中	EAGLE / EAGLE-2
N-gram / 檢索	從上下文中檢索重複 n-gram 作為候選	否	否	低-中（取決於文本重複度）	低	Prompt Lookup Decoding

選型權衡：

• 追求最大加速：EAGLE 系列通常接受率最高（特徵空間比 token 空間資訊量更大），但需要額外訓練。
• 追求零額外成本：Self-Speculative（跳層）或 N-gram 方案不需額外模型/訓練，但加速幅度有限。
• 追求工程簡潔：獨立小模型方案概念簡單，但需管理兩個模型的視訊記憶體與排程。

---

上下游

上游依賴

環節	具體內容
Target 模型	任意自迴歸 LLM（LLaMA、GPT、Qwen、Mistral 等），推測解碼不改變其權重
Draft 模型來源	同系列小模型 / 同模型的簡化路徑 / 需訓練的輕量預測頭
推論引擎	vLLM、TensorRT-LLM、SGLang、DeepSpeed-FastGen 等需要支援推測解碼的排程邏輯
硬體	GPU 需要足夠視訊記憶體容納 Draft 模型（如使用獨立模型方案）；GPU 並行能力決定驗證效率

下游應用

環節	具體內容
推論服務	線上 API 服務降低單 token 延遲和每 token 成本
互動式應用	聊天、程式碼補全等對首 token 延遲（TTFT）和吞吐（tokens/sec）敏感的場景
邊緣部署	在算力受限的裝置上，用 Draft Model 彌補自迴歸解碼的頻寬瓶頸
與其它加速技術組合	可與 KV Cache 量化、連續批處理、PagedAttention 等技術疊加使用

---

關鍵指標

指標	含義	量級參考
Acceptance Rate（接受率）	Draft token 被 Target 接受的比例	典型 0.5-0.8 [取決於 Draft 質量與任務]
Tokens per Verification Step	每輪推測解碼平均產出的 token 數	理論上限 K+1，實際通常 2-4
Speedup Ratio	相比純自迴歸解碼的加速比	典型 1.5x-3x [業界實驗常見區間]
Draft Latency Overhead	Draft 階段耗時佔總推論時間的比例	需控制在合理範圍內，否則抵消收益
Memory Overhead	額外視訊記憶體佔用（載入 Draft 模型/頭）	獨立模型方案：取決於 Draft 模型大小；預測頭方案：通常可忽略
Quality Degradation	輸出質量變化	理論上為零（無損），實際因浮點精度可能有極微小差異

---

供需與市場資料

推論成本的核心矛盾

LLM 推論正在成為 AI 基礎設施中成本最高的環節之一。隨著模型規模增大（數百 B 引數）和應用場景擴充套件（長上下文、多輪對話），推論成本呈指數級增長。行業報告普遍指出，推論計算已佔 AI 算力總消耗的大多數（具體比例因口徑而異）[行業估算，各家資料不一致，此處不編造具體數字]。

Draft Model 的成本節約邏輯

• 直接降低單請求推論成本：如果接受率足夠高，同等 QPS 下所需 GPU 數量減少。
• 無需重新訓練 Target 模型：與量化、蒸餾等方法相容，可在已有部署上直接疊加。
• 邊際成本低：預測頭類方案（Medusa/EAGLE）額外引數量極小，訓練成本低。

量化估算（粗略）

假設一個 70B 模型，推測解碼平均加速 2x，意味著：

• 同等吞吐下 GPU 需求減半（理論上限，實際考慮 overhead 會打折）。
• 按 GPU 雲端服務典型定價推算，推論成本可降低 30%-50% [粗略估算，取決於具體場景與部署方式]。

---

代表公司與資本對映

角色	代表	與 Draft Model 的關係
推論引擎	vLLM (UC Berkeley 開源)	原生支援推測解碼，支援配置 Draft Model
推論引擎	NVIDIA TensorRT-LLM	支援推測解碼最佳化，針對 NVIDIA 硬體深度最佳化
推論引擎	SGLang (UC Berkeley)	支援多種推測解碼方案整合
模型廠商	Google DeepMind	推測解碼原始論文出處之一 (Chen et al. 2023)
模型廠商	Meta (LLaMA 系列)	同系列模型大小組合天然適合做獨立 Draft 方案
學術前沿	EAGLE (原作者團隊)	特徵外推 Draft 方向的代表，被多家推論架構整合
雲端服務	各大雲端廠商	推論服務中採納推測解碼以降低服務成本

資本對映思路：Draft Model 本身不是一個”賽道”，而是推論最佳化技術棧中的一層。相關主體包括推論密度高（即推論成本佔營收比例大）的 LLM 服務商和推論晶片/引擎廠商。研究時可觀察：① 推論引擎對推測解碼的支援成熟度；② 大規模部署中實際獲得的加速比資料。

---

投資邏輯

核心判斷

Draft Model / 推測解碼是 LLM 推論最佳化技術棧中的高性價比元件：

1. 無損加速，邊際成本低：不需要重訓模型，預測頭方案額外引數量極小（通常佔 Target 模型的 <1%）。

2. 與其他最佳化技術正交疊加：可同時使用量化（INT4/INT8）、連續批處理、PagedAttention、FlashAttention 等技術，加速效果可疊加。

3. 隨模型變大，價值遞增：模型越大越 memory-bound，推測解碼的相對收益越大。

風險與不確定性

• 工程成熟度：推測解碼的 KV Cache 回滾、排程策略等工程細節仍在演進中，大規模生產部署的經驗尚在積累。
• 與硬體協同：新一代硬體如果大幅提升視訊記憶體頻寬（如 HBM4），memory-bound 瓶頸緩解，推測解碼的相對收益可能下降。
• 替代方案競爭：連續批處理、模型蒸餾、更激進的量化等技術也在持續進步，推測解碼的比較優勢需要動態評估。

---

常見誤讀糾偏

❌ 誤讀 1：“Draft Model 會降低大型模型的輸出質量”

糾偏：推測解碼的數學保證是無損的。接受-拒絕取樣機制確保最終輸出的每個 token 的邊際分佈嚴格等於 Target 模型的分佈。這不是近似，而是精確等價（在浮點精度範圍內）。這是推測解碼區別於”直接用小模型”的本質差異。

❌ 誤讀 2：“Draft Model 就是知識蒸餾的小模型版本”

糾偏：知識蒸餾是訓練時讓小模型學習大型模型的輸出分佈，目標是讓小模型獨立替代大型模型；推測解碼是推論時用小模型作為”提議者”，最終輸出由大型模型決定。兩者目標完全不同：蒸餾追求用小模型替代大型模型（有質量損失），推測解碼追求用小模型加速大型模型（零質量損失）。

❌ 誤讀 3：“Draft 模型越大越好，接受率越高”

糾偏：Draft 模型越大，接受率確實可能越高，但推論開銷也越大。存在一個最優平衡點：當 Draft 模型大到其推論開銷抵消了接受率提升帶來的收益時，總加速比反而下降。實踐中，Draft 模型大小通常是 Target 模型的 1/10 到 1/100 量級 [典型範圍，具體取決於架構與任務]。

❌ 誤讀 4：“推測解碼只適用於貪心解碼（greedy decoding）”

糾偏：推測解碼最初的形式確實對貪心解碼最直觀，但完整的接受-拒絕取樣架構支援 temperature sampling 和 top-k/top-p 取樣。Chen et al. (2023) 的 Speculative Sampling 明確給出了帶溫度取樣的數學推導，保證取樣分佈完全一致。

---

學習路徑

入門（1-2 小時）

1. 理解自迴歸解碼為什麼是 memory-bound 的——做一道簡單的計算題：一個 70B 模型在 H100 上單 token 解碼的 arithmetic intensity 是多少？（會發現遠低於 roofline 的 compute-bound 區域）
2. 閱讀推測解碼的直覺性介紹文章（社群部落格中有大量優質科普）

進階（3-5 小時）

3. 精讀 Leviathan et al. (2023) 和 Chen et al. (2023) 兩篇原始論文，理解接受-拒絕取樣的數學證明
4. 在 vLLM 或 SGLang 上實際配置一個 Draft Model 進行推論，觀察實際加速比與接受率

深入（1-2 周）

5. 閱讀 Medusa 和 EAGLE 論文，理解”內建 Draft”方案的設計思路
6. 研究推測解碼與連續批處理、KV Cache 管理的互動——這是工程實現中最複雜的部分
7. 嘗試實現一個最簡版推測解碼（用 Hugging Face Transformers + 一個小模型和一個大型模型）

拓展

8. 關注 Lookahead Decoding、Jacobi Decoding 等無需 Draft 模型的替代方案
9. 關注推測解碼在多模態模型（如視覺 token 生成）中的擴充套件應用

---

一句話總結

Draft Model 是推測解碼的核心元件——用一個輕量模型快速猜測候選 token、再由大型模型一次性並行驗證，在輸出質量嚴格不變的前提下，將自迴歸推論的吞吐提升 1.5-3 倍，是當前 LLM 推論最佳化中價效比最高的”白撿”加速手段之一。

---

延伸閱讀與來源

核心論文

• Leviathan, Y., Kalman, M., & Matias, Y. (2023). Fast Inference from Transformers via Speculative Decoding. ICML 2023. [Google Research]
• Chen, C., Borgeaud, S., Irving, G., et al. (2023). Accelerating Large Language Model Decoding with Speculative Sampling. arXiv:2302.01318. [DeepMind]
• Cai, T., Li, Y., Geng, Z., et al. (2024). Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads. ICML 2024.
• Li, Y., Cai, T., Zhang, Y., et al. (2024). EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty. ICML 2024.

工程實現參考

• vLLM 官方文件：Speculative Decoding 配置指南
• NVIDIA TensorRT-LLM 文件：推測解碼支援說明
• SGLang 專案文件

社群資源

• Hugging Face 部落格中關於 Speculative Decoding 的技術科普
• Lilian Weng 部落格中關於 LLM 推論最佳化的綜述（含推測解碼章節）

關鍵術語對照

英文	中文	說明
Speculative Decoding	推測解碼	整體架構名
Draft Model	草稿模型	快速猜測用的小模型
Target Model	目標模型	被加速的大型模型
Acceptance Rate	接受率	Draft token 被驗證通過的比例
Rejection Sampling	拒絕取樣	保證輸出分佈正確的統計機制
Speculative Sampling	推測取樣	支援 temperature sampling 的完整版本

---

免責宣告：本頁所有技術描述基於公開學術論文與業界共識。具體加速比、接受率等資料因模型、硬體、任務、實現而異，投資決策請以實際部署資料為準。標註 [粗略估算] 的數字僅為量級參考，不構成精確承諾。