什麼是 Speculative Decoding？LLM 如何加速生成文本

大型語言模型（LLM）在生成文本時，通常採用自回歸方式：先預測一個 Token，將其加入上下文，再預測下一個 Token。即使 GPU 擁有強大的並行運算能力，Token 之間的依賴關係仍然讓文本生成具有明顯的序列性。

Speculative Decoding（推測解碼）就是針對此一瓶頸而設計的 LLM 推論優化技術。該技術通常先使用計算成本較低的 Draft Model（草稿模型）快速提出多個候選 Token，再讓原本需要執行的 Target Model（目標模型）一次驗證這些候選。如果其中多個 Token 都被接受，Target Model 就能在一次驗證流程中推進多個生成位置，而不必每次只能前進一個 Token。

更重要的是，只要針對相對應的採樣與驗證演算法達到標準，Speculative Decoding 就可以在保持 Target Model 原始輸出分佈不變的情況下提升生成效率。因此，它不是單純地「用小模型取代大模型」，而是運用小模型來協助大模型減少序列生成步驟。

什麼是 Speculative Decoding（推測解碼）？

Speculative Decoding 是一種用於加速自回歸 LLM 推論的解碼方法。其核心理念是：先用低成本預測未來可能出現的多個 Token，再由目標模型集中驗證這些預測。

在一般自回歸解碼中，若模型需要生成四個 Token，通常須連續執行四次生成動作：

T1 → T2 → T3 → T4

T2 依賴 T1，T3 需依賴 T1 與 T2，因此沒辦法讓目標模型一次性獨立產生所有 Token。

Speculative Decoding 則改變了執行方式。一個運算速度更快或成本較低的 Draft Model，會先依據目前上下文預測出多個候選：

T1 → T2 → T3 → T4

隨後 Target Model 會將這段候選序列一次進行並行驗證。只要前幾個 Token 與 Target Model 的分布足夠接近，它們就能一次被接受，從而減少 Target Model 必須逐步執行的次數。

因此，Speculative Decoding 的重點並不是模型「知道什麼」，而是模型用什麼方式完成解碼。

為什麼 LLM 生成文本存在速度瓶頸？

LLM 文本生成的核心瓶頸之一在於 自回歸解碼（Autoregressive Decoding）。

假設輸入 Prompt 為：

AI models can

模型會先預測第四個 Token，如：

generate

只有取得這個 Token 後，模型才能將新的上下文：

AI models can generate

用以預測第五個 Token。接著可能生成「text」，再繼續預測後續字詞。

這表示，輸出 Token 之間天生就存在依賴關係。模型無法一開始就確定第 20 個 Token，因為它的機率要取決於前面已經產生哪些 Token。

現代 GPU 十分擅長大規模並行的矩陣運算，但逐 Token 解碼的序列性卻限制了 GPU 並行能力的發揮。尤其在單一請求或較小批次的生成場景下，解碼階段往往難以像 Prompt 預填一樣充分運用 GPU 運算資源。

Speculative Decoding 的目標，就是要減少 Target Model 必須歷經的序列解碼步驟（Decode Steps）。

Speculative Decoding 是怎麼運作的？

典型的 Speculative Decoding 系統包含兩個主要角色：

Draft Model 負責快速產生候選 Token，而Target Model 則是使用者原本期望運作的大模型，負責驗證並做出最終輸出決定。

假設目前上下文是：

Artificial intelligence is

Draft Model 可能會迅速提出四個候選 Token：

changing → the → way → people

接著 Target Model 不需要像傳統解碼流程一樣，一個個地產生這四個 Token，而是可以在一次前向推理中，評估整段候選序列於各位置的預測分布。

如果候選 Token 被接受，系統便直接將它們納入輸出。若前三個被接受，第4個不符合驗證條件，就只保留：

changing → the → way

然後在遇到拒絕的位置，由相對演算法重新採樣或生成 Token，再啟動下一輪推測。

整個流程可概括為：

目前上下文 → Draft Model 提案多個 Token → Target Model 驗證 → 接受有效前綴 → 在拒絕點修正 → 重複上述流程

真正帶來加速關鍵在於：每次 Target Model 驗證有可能讓生成序列直接推進多個 Token。

Draft Model 和 Target Model 各自的職責是什麼？

瞭解這兩個模型的任務，是掌握 Speculative Decoding 的關鍵。

Target Model 是最終決定輸出分布的模型。例如，原本用戶要執行某個大型 LLM，那它就是 Target Model。Speculative Decoding 並不是用弱小模型取代它。

Draft Model 負責「提前預測」。這種模型運算成本通常較低，且必須有足夠能力預測 Target Model 在下一步可能接受哪些 Token。

比較	Draft Model	Target Model
主要任務	提供候選 Token	驗證候選、做出最終輸出判斷
計算成本	通常較低	通常較高
速度需求	極需快速	保持原模型能力
輸出功能	提供推測候選	決定最終接受結果
關鍵目標	提高候選命中率	維持目標輸出分布

所以，Draft Model 並非越小越好。如果速度雖快，卻總是被 Target Model 否決大多數 Token，就很難一次性推進多個 Token，實際加速效益會受損。

理想的 Draft Model，必須要在兩個目標之間取得平衡：夠快，同時又能夠充分預測 Target Model 的行為。

Target Model 要如何驗證多個 Token？

這是 Speculative Decoding 最容易被誤解的一環。

Target Model 並非只是簡單判斷 Draft Model 的句子「對不對」，而是會計算候選序列各位置的 Token 機率，再依據特定的接受規則判斷哪些 Token 可被保留。

假使 Draft Model 預測出：

A → B → C → D

Target Model 可以運用 Transformer 的並行運算特性，於單次前向預測裡同時評估這幾個 Token 的分布。接下來，系統會依序從第一個候選進行驗證。

如果 A、B、C 都被接受，而 D 被拒絕，系統通常僅保留前面連續通過驗證的 Token：

A → B → C

系統不會因為後方某個 Token 看起來合理就跳過前面出錯之處，因為一旦某個 Token 被修改，所有依賴於該上下文的後續 Token 也會受影響。

在經典的 Speculative Sampling 中，接受與否還需根據 Draft Model 與 Target Model 的機率分布進行校正，而不是簡單比對兩個模型 Top-1 Token 是否一致。正是這種設計，讓標準算法可在加速同時維持目標模型的採樣分布。

Speculative Decoding 為什麼能加速 LLM？

其主要優勢來自兩點：低成本推測 + 並行驗證。

在傳統解碼流程中，假設 Target Model 需要生成 100 個 Token，通常得進行大量序列解碼步驟。即使 KV Cache 能避免重複計算過去 Token 的 K/V，新的 Token 還是必須依序產生。

Speculative Decoding 可讓 Draft Model 先完成部分低成本推測。只要 Target Model 每次驗證能夠平均接受多個 Token，實際需進行的高成本序列 Target Model 步驟就會縮減。

舉例，一個簡化場景下：

傳統解碼：

Target → 1 TokenTarget → 1 TokenTarget → 1 TokenTarget → 1 Token

推測解碼：

Draft → 4 Candidate TokensTarget → Verify Candidates → Accept Multiple Tokens

這並不表示四個候選一定都能通過，也不代表速度固定提升四倍。實際成效需看候選接受率、Draft Model 成本、Target Model 大小、硬體運算效益與驗證開銷。

因此，Speculative Decoding 的效果本質上在於：節省下來的 Target Model 序列運算步驟是否大於額外產生的 Draft 與驗證成本。

Acceptance Rate 為什麼很重要？

Acceptance Rate（接受率）指的是 Draft Model 所提出的候選 Token 有多少比例能夠被 Target Model 接受，這是影響 Speculative Decoding 效率的關鍵指標。

若 Draft Model 能精準預測 Target Model 的生成方向，每次驗證可能可接受多個 Token，系統就能快速推進生成。

反之，若 Draft Model 與 Target Model 的行為差異偏大，例如頻繁預測出 Target Model 不會接受的 Token，那麼很快就會遇到拒絕點。此時 Draft Model 許多運算都無法帶來實際有效輸出，反而增加了額外開銷。

候選長度同樣需要斟酌。一次讓 Draft Model 預測更多 Token，理論上也許能讓 Target Model 一次推進更遠，但預測越長，後面候選被拒機率也會升高。

因此，實作時需在 Draft Speed、Acceptance Rate 以及推測長度之間尋找平衡，而非僅追求 Draft Model 多預測 Token 數量。

Speculative Decoding 會降低模型輸出品質嗎？

對於有嚴格驗證和機率校正機制的標準 Speculative Decoding / Speculative Sampling 演算法，其設計目標就是維持 Target Model 的原始輸出分布不變。

這一點至關重要。

如果只是單純讓小模型生出內容，大模型只進行簡單檢查（如核對 Top-1），那這種近似方案有可能改變最終輸出。不過經典 Speculative Decoding 會依據 Target Model 的機率分布採樣、拒決與必要的重採策略，使最終抽樣依理論和實務都與直接以 Target Model 解碼一致。

因此，標準 Speculative Decoding 的價值在於：改變生成過程的運算型態，而非用 Draft Model 的品質取代 Target Model。

但「Speculative Decoding」在實際工程上也可能泛指多種推測式生成作法，並不是所有變體都能保證完全一致的輸出分布。有些系統會主動採用較粗略的策略，以進一步優化速度。

所以，判斷某項實作是否影響輸出品質，必須檢視其具體的驗證與採樣算法，而非僅看名稱標示「Speculative」。

Speculative Decoding 與 KV Cache 有何不同？

Speculative Decoding 與 KV Cache 都是優化 LLM 推論時常用的技術，但它們處理的問題截然不同。

KV Cache 目的是避免重複計算歷史 Token。它會保留注意力機制（Attention）內已運算完成的 Key 與 Value，使新 Token 可直接重用先前的狀態。

Speculative Decoding 則針對自回歸生成的序列性瓶頸。它試圖讓 Draft Model 一次預測多個未來 Token，再透過 Target Model 集中驗證，以減少高成本模型所需的序列化運算步驟。

比較	KV Cache	Speculative Decoding
主要目標	避免 K/V 重覆計算	解決逐個產生 Token 的瓶頸
核心手段	緩存歷史 Attention 狀態	提前推測多個候選 Token
是否有 Draft Model	不需要	經典做法需要
主要影響	提升解碼運算效能	加快 Token 產生速度
主要代價	KV Cache 顯存空間	Draft 與驗證計算負擔

兩者並非競爭關係。在實務推論系統裡，Speculative Decoding 通常與 KV Cache 協同運用。

Speculative Decoding 與傳統 Decoding 差別在哪？

一般自回歸解碼流程完全依賴 Target Model 按步產生，每次僅決定下個位置的 Token。無論採用 Greedy、Top-k、Top-p 或 Temperature Sampling，基本流程始終具序列特性。

Speculative Decoding 則於 Target Model 前加上一道「推測階段」。Draft Model 會先預測未來多個位置的候選，再由 Target Model 一次驗證。

最大區別不在於最終任務，而是生成過程本身：

比較	傳統 Decoding	Speculative Decoding
Token 產生方式	Target Model 逐步生成	Draft 先產生多個候選
Target Model	每步執行	一次能驗證多個位置
並行應用	解碼序列性高	讓驗證階段更並行
額外模型	不需要	經典作法要 Draft Model
系統複雜度	較低	較高
潛在效益	基準	條件適當下可更快

這也是為什麼 Speculative Decoding 更應被理解為推論優化（Inference Optimization），而非新的模型訓練方法。

Speculative Decoding 一定能讓 LLM 更快嗎？

不一定。

如果 Target Model 很龐大、Draft Model 足夠輕量，且兩者預測結果一致性高，通常 Speculative Decoding 較容易帶來明顯效益。

但若 Draft Model 自身就具備高運算成本，或者 Acceptance Rate 過低，Draft 和驗證產生的額外負擔就可能抵銷原本節省的時間。

硬體環境同樣至關重要。在高批次（Batch）、強吞吐的推論服務下，GPU 也許已被充分利用，Speculative Decoding 的利得和單請求低延遲場景不盡相同。模型大小、記憶體頻寬、上下文長度或推測 Token 數量，都會影響最終結果。

因此，「用了 Speculative Decoding」並不代表加速倍數是固定的，最終效率還須端視實際模型、硬體和工作負載測試。

Speculative Decoding 還有哪些其他實現方式？

經典方式會採用較小、獨立的 Draft Model，但「先推測、再驗證」這個觀念已延伸出多元實現型態。

一種做法為 Self-Speculative Decoding。系統不一定要另外執行獨立小模型，也可運用 Target Model 自身的部分層數、提前退出條件或其他輕量化分支來生成候選。

另一類則為 Multi-Token Prediction 或設計額外輸出頭，讓模型可一次產生未來多個 Token 候選，然後以主模型驗證。

還有些方法會使用類似樹狀候選結構，不只推測單一路徑，而是同時展開多條未來分支，讓 Target Model 一次驗證就能挑選出最適路徑。

這些方式的算法細節大不相同，但最終皆以降低昂貴 Target Model 序列性、促使運算並行化為目標。

Speculative Decoding 與 LLM 推論優化的關聯為何？

Speculative Decoding 只是現代 LLM Inference Optimization（推論優化）體系的一環。

LLM 推論效能受限於運算、顯存、記憶體頻寬、請求調度與自回歸生成瓶頸，多數系統都需結合多種技術。

KV Cache 減少 Token 重複 K/V 計算；Paged Attention 改善 KV Cache 的記憶體管理；Continuous Batching 提高多請求共享 GPU 效率；Quantization 降低權重或快取的儲存與運算成本；Speculative Decoding 則重點解決自回歸解碼的序列性瓶頸。

這些問題彼此並不完全重疊。

由此可見，現代 LLM 實際的響應速度，其實並不僅受模型參數量所限。模型架構、Attention 設計、KV Cache、解碼算法、GPU、推論引擎和請求排程策略，才共同決定了整體推論效能。

總結

Speculative Decoding（推測解碼）是一項針對 LLM 自回歸生成瓶頸所設計的推論優化技術。經典做法是先用運算成本較低的 Draft Model 產生多個候選 Token，再由 Target Model 集中驗證，從而嘗試讓目標模型一次前進多個 Token。

它之所以能提升速度，關鍵在於 Draft Model 候選夠準確。若 Acceptance Rate 較高，Target Model 就能一次接受多個 Token，有效減少昂貴的序列解碼步驟；但若大量候選遭拒，額外推測的成本可能反而影響加速成效。

與 KV Cache 不同，Speculative Decoding 並非解決歷史運算重複問題，而是專注於減少逐 Token 生成造成的序列性瓶頸。兩者可搭配運用，也常與 Continuous Batching、Paged Attention、Quantization 等技術共同優化現代 LLM 推論效能。

理解 Speculative Decoding 也有助於認識一個更關鍵議題：提升 LLM 速度不必然仰賴縮小模型或降低輸出品質，改變推論與解碼流程本身，就有機會讓既有模型更高效地生成文本。

FAQ

Speculative Decoding 一定要用兩個模型嗎？

經典 Speculative Decoding 通常使用 Draft Model 與 Target Model，但 Self-Speculative Decoding、額外預測頭等變體則可能採用不同的候選生成機制。

Draft Model 越小越好嗎？

不一定。Draft Model 需極速運算且具備與 Target Model 較高的一致性，如果模型過弱導致 Acceptance Rate 低，整體加速效果反而可能變差。

Speculative Decoding 會改動 Target Model 嗎？

不會變更 Target Model 的訓練參數。它屬於推論與解碼階段的優化手段，並非模型訓練或微調方法。

Speculative Decoding 和 KV Cache 可否一併使用？

當然可以。KV Cache 減少歷史 Token 的 Attention 重複計算，Speculative Decoding 則能減少高成本模型的序列解碼步驟，兩者解決的是不同瓶頸，能夠相輔相成。

Speculative Decoding 為什麼無法保證一定加速倍數？

實際速度取決於 Draft Model 成本、候選接受率、推測長度、Target Model 大小、GPU 硬體、Batch 大小以及工作負載等多項因素，因此在不同部署場景下的效益可能差異極大。