大型語言模型支持廣泛應用，但要大規模部署則需精心優化。標準的自回歸解碼是大多數 LLM 服務系統的基線：模型每次生成一個詞元，將其附加到序列中，再用更新後的序列生成下一個詞元。此過程簡單可靠，但服務迴圈仍需嚴格按左到右順序逐詞元生成，限制了吞吐量。

推測解碼透過草稿與驗證機制改進此基線。輕量級草稿組件先提出多個候選未來詞元，目標模型再驗證這些候選詞元，只有通過驗證的詞元才會被提交。當多個草稿詞元被接受時，系統可在一次目標模型驗證中提交多個輸出詞元，同時保持目標模型的輸出行為不變。

本文介紹了 vLLM 中推測解碼的工作原理，並分享在 AMD Instinct MI300X 和 MI355X GPU 上使用 ROCm 平台的測試數據。首先回顧自回歸解碼基線與草稿驗證流程，接著分析五種推測草稿方法：原生 MTP、Gemma 4 MTP、EAGLE-3、DFlash 和 DSpark。這些方法在草稿組件如何接收目標模型資訊、候選詞元生成方式（序列式、自回歸、並行或混合）上有所不同。最後展示如何在 vLLM 中啟用這些方法，並討論調優與觀察性考量。

標準自回歸解碼每步生成並提交一個新詞元，例如生成四個詞元需四個連續步驟。每步生成的詞元會附加到序列中，成為下一步的輸入。此迴圈簡單，但每個輸出詞元都需一次模型解碼，長序列生成時延遲高且吞吐量受限。

推測解碼的核心問題是：能否在保持原模型輸出行為的同時，減少每次只前進一個詞元的頻率？

推測解碼透過分離提案與驗證來實現。草稿組件先提出多個未來詞元候選，目標模型作為驗證者評估這些候選，只有通過驗證的詞元才被提交。推測解碼不取代原模型，而是在其前端加上更快的提案階段。

每輪推測解碼中，草稿組件提出一個或多個未來詞元候選，這些詞元僅為候選，尚未提交。目標模型一次性驗證整個候選序列，從左到右逐詞元檢查。接受的詞元被提交，遇到第一個被拒詞元後，後續候選詞元不再接受。

若草稿詞元被拒，目標模型會提供下一個詞元，剩餘草稿詞元被捨棄，生成從更新序列繼續。

推測解碼允許多個候選位置同時評估，若多個候選被接受，則可在一次驗證中提交多個輸出詞元，減少目標模型解碼輪數。若提案被拒，目標模型結果決定生成如何繼續。

本文以圖示說明推測解碼流程，並以例子展示草稿詞元如何被驗證與接受或拒絕。

五種推測草稿方法雖遵循相同草稿與驗證流程，但草稿組件設計與與目標模型互動方式不同。可分為三大類：原生 MTP 模組、獨立 MTP 草稿器、專用目標條件草稿網絡。這些類別描述草稿組件架構，與目標模型家族無關。

草稿組件可能接收目標模型的隱藏狀態、KV 緩存等資訊，依方法不同而異。以下分別介紹各方法如何使用資訊並生成候選詞元。

多詞元預測（MTP）是模型原生機制，能預測多個未來詞元。vLLM 中若目標模型包含相容輔助預測組件，即支持原生 MTP。MTP 結構因模型家族而異，但均提供輔助路徑提出未來詞元。

第一步，MTP 組件結合目標模型隱藏表示與當前詞元資訊預測首個草稿詞元，後續步驟用新草稿詞元與前一步 MTP 隱藏狀態預測下一候選。提出設定數量詞元後，目標模型一次驗證。

多數原生 MTP 實現遵循類似模式：結合目標模型或前一 MTP 預測的隱藏表示與偏移輸入詞元或最新草稿詞元嵌入，兩者沿隱藏維度合併後進入輔助預測層。

物理 MTP 層數與設定推測長度為不同概念。當設定推測詞元數超過檢查點直接提供的預測深度，vLLM 可透過額外前向傳播重用 MTP 路徑，提出更多候選，但增加序列草稿工作。

原生 MTP 與目標模型架構緊密結合，部分路徑共享組件，記憶體開銷較小，但多詞元生成仍需序列草稿。

Gemma 4 使用獨立包裝的 MTP 草稿組件，與特定目標模型配對。草稿組件有獨立檢查點，但推理時與目標模型緊密連接，使用目標模型激活並共享 KV 緩存，重用上下文資訊。

草稿組件層數與推測長度分離，生成多候選詞元時依序生成。

EAGLE-3 使用專用草稿網絡，針對特定目標模型訓練。草稿組件有獨立執行路徑，但密切依賴目標模型資訊。

目標模型前向傳播時，EAGLE-3 記錄目標 Transformer 三個階段的隱藏狀態，將其串接並投影成融合特徵，與採樣詞元嵌入結合後輸入草稿解碼器。

EAGLE-3 自回歸生成草稿詞元，首個詞元用融合特徵與採樣詞元嵌入，後續詞元用前一草稿輸出嵌入。由於目標模型尚未處理後續推測位置，後續詞元依賴前一草稿輸出，需序列草稿。

DFlash 也是專用草稿網絡，與 MTP、EAGLE-3 不同，DFlash 並行預測整個未來區塊。

DFlash 每個草稿區塊以錨點詞元開始，錨點為目標模型已確認詞元，後續位置遮蔽並並行預測。融合多層目標模型隱藏狀態成融合表示，轉換為草稿網絡每層可用的 Key 和 Value 表示，遮蔽位置的查詢可同時關注目標模型上下文與草稿上下文。

草稿區塊生成後，目標模型一次驗證所有候選詞元，從左到右接受直到第一拒絕，拒絕詞元被目標模型詞元取代，後續候選捨棄。

DFlash 特點是所有遮蔽位置一次生成，無序列依賴，後續位置不依賴同輪前一位置輸出，效果依賴訓練檢查點與工作負載。

DSpark 基於 DFlash 並行骨幹，增加輕量序列頭。骨幹一次生成所有位置基礎 logits，序列頭從左到右選擇詞元，根據前一選擇詞元調整 logits，形成馬爾可夫依賴，避免獨立位置預測導致不一致組合。

DSpark 設計還包含信心頭，可選擇較短草稿前綴驗證，但實驗中未啟用此功能。

五種草稿方法在圖示中並列比較，展示草稿組件結構、使用的目標模型資訊及生成方式（序列或並行）。所有方法均由目標模型一次驗證候選序列，從左到右接受直到第一拒絕。

vLLM 透過 --speculative-config 配置推測解碼，主要差異在方法名稱、是否需獨立草稿檢查點及候選詞元數。支持 mtp、eagle3、dflash、dspark。

原生 MTP 草稿組件包含於目標模型中，無需獨立檢查點。Gemma 4 MTP、EAGLE-3、DFlash、DSpark 需獨立草稿檢查點，需預留足夠 GPU 記憶體，實際開銷依草稿組件大小、數值精度、張量並行配置與運行時緩衝而異。

多個組織在 Hugging Face 發布預訓練草稿模型，如 Google 提供 Gemma 4 MTP 助手，Z-Lab 維護 DFlash 檢查點，Red Hat AI 提供 EAGLE-3、DFlash、DSpark 草稿模型，DeepSeek DeepSpec 提供三者匹配檢查點，LightSeek 專注 EAGLE 基於 Kimi，Inferact 發布 MiniMax 與 Kimi 草稿模型。

啟用推測解碼後，關鍵是額外草稿工作是否提升整體服務效能。候選詞元不必每個位置都正確，因目標模型會驗證。效能取決於接受詞元數與節省的目標模型解碼工作是否超過草稿與驗證成本。

評估使用任務基準而非隨機詞元序列，因接受行為依模型輸出結構與可預測性，任務提示更具代表性。

主要效能指標為吞吐量（生成詞元每秒）與接受率。

實驗涵蓋五種草稿方法與多個目標模型家族，結果顯示吞吐量提升因模型、草稿方法、工作負載與提案長度而異。

例如 gemma-4-26B-A4B-it 在 GSM8K 與 MBPP 上 Gemma 4 MTP 吞吐量最高達 2.74× 與 2.62×，DFlash 在 MATH500 與 HumanEval 上達 2.87× 與 2.79×，EAGLE-3 範圍為 2.11× 至 2.27×。

gemma-4-31B-it、Qwen3-8B、Qwen3.5-27B、Qwen3.5-122B-A10B、Qwen3.6-27B、Qwen3.6-35B-A3B、MiniMax-M3-MXFP8、Kimi-K2.5 等模型也有不同程度提升，最高達 2.68×。

提案長度對吞吐量影響顯著，序列方法吞吐量隨 N 增加先升後穩定，DFlash 與 DSpark 多數情況 N=7 表現較佳，但更大值不一定提升。

推測解碼應視為運行時優化，非固定設定。最佳 num_speculative_tokens 依接受率與草稿成本平衡決定。

觀察性重要，建議以代表性工作負載與端到端測量調整配置，監控吞吐量、平均接受長度、整體與逐位置接受率。

原生 MTP 建議從 N=1 保守開始，逐步增加至 7，根據模型與工作負載調整最佳值。

Gemma 4 MTP 與 EAGLE-3 亦建議短範圍掃描 N 值。

DFlash 建議依檢查點推薦提案長度開始，常見最大長度為 16（含錨點），實驗中 N=7 與 N=11 表現較佳。

DSpark 透過 num_speculative_tokens 設定每輪生成候選數，實驗中以端到端吞吐量比較不同 N 值。

不同工作負載接受模式不同，GSM8K 與 MATH500 偏好中長提案長度，HumanEval 與 MBPP 則偏好中等長度。

建議從檢查點推薦配置開始，使用代表性提示與生成設定進行基準測試，記錄吞吐量與接受率，掃描多個提案長度，根據工作負載選擇最佳配置。

選擇不一定是最大提案長度或最高接受率，而是草稿成本、驗證成本與接受詞元數的最佳平衡。

本文未深入探討推測器訓練，簡述實務流程：

以預期工作負載提示開始，保留獨立評估集。訓練回應需由目標模型生成，使用相同分詞器、聊天模板與生成配置。vLLM 強調僅套用目標模型分詞器或模板不足以使資料目標專屬，回應本身必須來自目標模型。

訓練時推測器接收目標模型內部隱藏狀態，vLLM 支援三種提供方式，選擇影響隱藏狀態來源，訓練流程大致相同。

vLLM 伺服器可運行目標模型並暴露所需層隱藏狀態，訓練配置須與目標模型隱藏大小、詞彙表、分詞器及選定層匹配，並設定草稿網絡深度、區塊大小、序列長度與學習率。

訓練後檢視檢查點，與目標模型一起部署。訓練損失不足以判斷結果，重要指標為接受長度、接受率、草稿延遲、GPU 記憶體使用與端到端吞吐量。

接受率不佳時可調整提示混合或訓練配置，重複流程，原則是使用相同目標模型、生成模式與代表性工作負載。

總結，本文探討 vLLM 中推測解碼作為草稿與驗證方法，草稿組件提出未來詞元候選，目標模型驗證後提交。

分析五種草稿方法，差異在於如何利用目標模型資訊及候選詞元生成方式（序列、並行或混合）。

實驗涵蓋 Gemma、Qwen、MiniMax 與 Kimi 模型，使用 AMD Instinct MI300X 與 MI355X GPU 及 ROCm 平台。吞吐量因模型、草稿檢查點、工作負載、提案長度與配置不同而異。

部分配置吞吐量低於基線，部分組合最高達 2 倍以上提升，如 DFlash 在 gemma-4-26B-A4B-it 達 2.87 倍，Gemma 4 MTP 同目標模型達 2.83 倍，DFlash 在 Kimi-K2.5 達 2.68 倍。

提案長度為重要變數，增加 num_speculative_tokens 有時提升吞吐量，過大則可能持平或下降。檢查點建議為起點，選擇配置需依代表性工作負載與接受率指標。

未來工作可涵蓋非學習方法如 n-gram 推測與後綴解碼，特別適用於重複詞元模式工作負載。

亦可擴展評估不同並發度、提示與輸出長度、批次大小與採樣設定下推測解碼表現。

研究推測器訓練資料對不同任務（程式碼、數學、聊天、多語言、工具使用、結構化輸出）接受率的影響，有助於選擇或訓練適合工作負載的草稿檢查點。

深入分析草稿生成、目標驗證、KV 緩存行為、圖形執行與排程，有助解釋不同模型與工作負載間性能差異。

附錄聚焦草稿位置接受行為，提供目標模型、草稿方法與實驗的逐位置接受熱圖，深色表示接受率高，並附速度提升與輸出吞吐量數據。

感謝 AMD 的 Hongxia Yang 與 Peng Sun，以及 Embedded LLM 的 Pin Siang Tan、Jun Kang Chow 與 Ye Hur Cheong 的貢獻。

測試環境為 AMD Instinct MI300X 與 MI355X，軟體版本包括 Ubuntu 22.04.5 LTS、ROCm/HIP 7.2.53211、vLLM 0.23.1rc1.dev1120+g0f0f28b53、PyTorch 2.11.0+gitd0c8b1f、Transformers 5.13.1、Python 3.12.13。伺服器製造商配置不同可能導致結果差異，性能受配置、軟體、vLLM 版本及驅動優化影響。