⚡ 站長快讀:核心重點
- 文章屬性:科技冷知識 / 規格解析
- 核心結論:Speculative Decoding(推測解碼)讓一個小模型先猜好幾個字,再由大模型一次驗證,把「一次一個字」的序列瓶頸換成「一次驗一批」的平行計算,在 NVIDIA H200 這類資料中心 GPU 上,官方實測倍率落在 2.2–3.6 倍;消費級顯示卡則要看主模型多大、任務多好猜,LM Studio 官方實測介於 1.05–2.07 倍。無論哪一種,輸出品質都不打折。
- 適用對象:所有對科技好奇的人,尤其是在自己電腦上跑本地 LLM、覺得吐字太慢的人
📌 快速答案
一句話答案:Speculative Decoding 是讓小型草稿模型先預測接下來幾個 token、再由大模型一次平行驗證的推論加速技術,接受的就留、猜錯的就丟,輸出分佈與原模型相同。
🔍 故事的起點
有一個現象,只要你在自己電腦上跑過本地 LLM 就一定遇過:模型吐字的速度,跟顯示卡的算力好像沒什麼關係。明明 GPU 的浮點運算能力是天文數字,畫面上的字卻一個一個慢慢冒出來,風扇也沒怎麼轉。這不是錯覺——NVIDIA 在 2025 年 9 月的技術部落格裡直接點名了這個矛盾:GPU 提供了龐大的算力,但其中大部分處於閒置狀態,因為自迴歸生成本質上是循序的,每一個 token 都需要一次完整的前向傳播、重新載入權重、並在每一步同步記憶體(來源:NVIDIA Technical Blog,第一級官方)。
換句話說,生成 100 個 token 就是把整個模型的權重從記憶體搬 100 次。真正的瓶頸在記憶體頻寬,不在算力——這件事站長先前在〈為什麼本地 LLM 跑不快?真瓶頸是記憶體頻寬,不是顯卡算力〉裡拆解過。
於是有人問了一個很反直覺的問題:既然大模型每一步都在等記憶體、算力都空著,那能不能先讓一個小模型隨便猜幾個字,再讓大模型一次把這幾個字全部檢查完?猜對就賺到,猜錯就當作沒發生。這就是 Speculative Decoding 的起點。它由 Google Research 的 Leviathan 等人在 2022 年 11 月提出(論文〈Fast Inference from Transformers via Speculative Decoding〉,arXiv 2211.17192,2023 年 5 月修訂為 v2,收錄於 ICML 2023 Oral),幾乎同時 DeepMind 的 Chen 等人也提出了名稱不同、原理相通的 speculative sampling(arXiv 2302.01318,2023 年 2 月,預印本)。
🧪 原理拆解
先給結論:Speculative Decoding 的核心不是「讓模型變聰明」,而是把序列的等待換成平行的驗證。它由「草稿」與「驗證」兩個階段組成,兩者缺一不可。
第一階段:草稿模型先猜下一批字
大模型旁邊會多掛一個小很多的模型,論文與業界慣稱 draft model(草稿模型),LM Studio 的介面上叫它 speculator。它的工作只有一件事:接著目前的文字,一口氣往下猜幾個 token。NVIDIA 的說明給出的常見範圍是一次草擬 3 到 12 個 token(來源:NVIDIA Technical Blog,第一級官方);llama.cpp 的官方文件則把這個數字放在 --spec-draft-n-max,預設值為 3(來源:llama.cpp 官方 repo docs/speculative.md,第一級官方)。
草稿模型為什麼快?因為它小。小模型每一步要搬的權重少得多,同樣的記憶體頻寬下就能跑出高得多的 token 速度。NVIDIA 在說明中用了一個很好懂的比喻:這就像實驗室裡的首席科學家找一位經驗較淺但手腳很快的助理去跑例行實驗,助理快速把清單做完,科學家專心驗證。
第二階段:大模型一次驗證全部
關鍵在這一步。大模型(target model,目標模型)拿到草稿的那一串候選 token 之後,不是一個一個檢查,而是把整段輸入連同所有草稿 token 一起丟進去,用一次前向傳播算出每個位置的機率分佈(來源:NVIDIA Technical Blog)。這正是 llama.cpp 文件開頭那句話的意思:一次批次計算 n 個 token(像處理 prompt 那樣),比循序計算 n 個(像逐字生成那樣)有效率得多。
而且因為 KV Cache 裡已經存好了前面那段前綴的計算結果,這一次驗證真正需要付出計算成本的,只有新增的那幾個推測 token。
第三階段:接受、拒絕,以及「為什麼答案不會變」
這是最多人誤會的地方,先把結論講清楚:Speculative Decoding 不會讓答案變差,也不是一種近似或取巧。
驗證採用的是論文所稱的修正版拒絕取樣(modified rejection sampling)。直觀來說,對每一個草稿 token,比較目標模型給它的機率與草稿模型給它的機率:目標模型認為這個字至少同樣合理,就直接接受;目標模型覺得這個字沒那麼合理,則按兩者機率的比值決定接受或丟棄。一旦某個 token 被拒絕,它以及它後面的所有草稿 token 全部作廢(因為後面的字是建立在前面那個字上的),流程退回最後一個被接受的位置,由目標模型自己產生一個修正過的 token。
這套機制的數學保證,是兩篇原始論文都明確寫下的:Leviathan 等人的說法是「在不改變輸出的前提下」加速,並在 T5-XXL 上示範相較標準 T5X 實作有 2 至 3 倍加速、輸出完全相同;Chen 等人的說法是該取樣方案「在硬體數值精度內保留了目標模型的分佈」,並在 700 億參數的 Chinchilla 上測得分散式環境下 2 至 2.5 倍的解碼加速,且不犧牲取樣品質、不修改模型本身(來源:arXiv 2211.17192 / arXiv 2302.01318,兩者皆為預印本,前者另收錄於 ICML 2023)。
順帶一提,NVIDIA 部落格圖示中把接受條件簡化成「目標機率大於等於草稿機率就接受」,那是為了教學好懂的簡化畫法;論文的完整規則是上述的機率比值版本,兩者不衝突,但要引用精確定義時請以論文為準。
還有一個容易被忽略的性質:最壞情況不會比原本更慢很多。NVIDIA 明講,如果所有草稿 token 都被拒絕,那這一輪就只產生目標模型自己的那一個 token——也就是退化成原本的逐字生成,只是白花了草稿模型的那點時間。
那到底省下了什麼?一個 250 毫秒的例子
NVIDIA 用了一組很清楚的假設數字說明:如果一次前向傳播要 200 毫秒,標準逐字生成產出 3 個 token 就是 3 × 200 = 600 毫秒。改用推測解碼後,草稿加驗證的那一次前向傳播稍微久一點、假設 250 毫秒,但這一次就吐出 3 個 token(2 個推測 + 1 個目標模型自產),於是 600 毫秒變成 250 毫秒。
使用者感受到的不是「字一個一個出現」,而是「一小段一小段跳出來」。在聊天機器人這類互動場景裡,這個差別非常明顯。
官方實測數字:草稿模型不是越大越好
NVIDIA 在 TensorRT-LLM 的官方數據(2024 年 11 月 18 日量測,DGX H200)顯示,推測解碼的加速幅度確實可觀,但草稿模型的大小存在一個甜蜜點:
| 目標模型 | 草稿模型 | 輸出 tokens/秒 | 倍率 |
|---|---|---|---|
| Llama 3.1 405B(4 張 H200) | 無 | 33.46 | — |
| Llama 3.1 405B | Llama 3.2 3B | 120.75 | 3.61× |
| Llama 3.1 70B(1 張 H200) | 無 | 51.14 | — |
| Llama 3.1 70B | Llama 3.2 1B | 146.05 | 2.86× |
重點摘要:
- 405B 目標模型搭 1B / 3B / 8B 草稿模型的倍率分別是 3.33× / 3.61× / 3.04×——3B 最快,8B 反而掉下來。
- 70B 目標模型搭同樣三種草稿的倍率是 2.86× / 2.75× / 2.23×,這次是最小的 1B 最快。
- 草稿模型越大,猜得越準(接受率高),但它自己也越慢;兩者相乘才是實際收益,所以「越大越好」是錯的。
- 以上為 NVIDIA 內部量測,TensorRT Model Optimizer 0.21 預發行版、TensorRT-LLM 0.15.0.dev,並非站長實測。
代價一:你要多載一個模型
草稿模型必須跟目標模型同時待命。對資料中心來說這點記憶體不算什麼,但在自己電腦上就很有感——本來 VRAM 就吃緊,現在還要再塞一個模型進去。LM Studio 官方說明提到,自 0.3.10 起系統會嘗試把草稿模型整個卸載到 GPU 上(若有 GPU)。好消息是草稿模型通常小到 0.5B–1B 這個級距,量化後往往只有幾百 MB。關於量化與 VRAM 的取捨,可參考〈本地 LLM 模型怎麼選?7B/70B、Q4/Q8 量化與 VRAM 一次搞懂〉。
代價二:兩個模型必須「講同一種語言」
草稿模型不能隨便挑。LM Studio 官方文件講得很白:兩個模型必須共用足夠相似的詞彙表(vocabulary)與 tokenizer 特性,草稿模型才有可能產生大模型也會產生的 token;LM Studio 會自動檢查配對相容性。NVIDIA 這邊的要求同樣是草稿模型須與目標模型共用同一個 tokenizer。
實務上最省事的做法就是同家族取一大一小。LM Studio 官方給的配對範例是:Llama 3.1 8B Instruct 配 Llama 3.2 1B Instruct、Qwen 2.5 14B Instruct 配 Qwen 2.5 0.5B Instruct、DeepSeek R1 Distill Qwen 32B 配 DeepSeek R1 Distill Qwen 1.5B。
代價三:主模型不夠大時,幾乎沒賺頭
這是站長認為最該講、卻最少人講的一點。LM Studio 官方公布的實測數據裡有一組非常誠實的對照(RTX 3090 Ti 24GB、Intel Core Ultra 7 265K、32GB RAM):
| 主模型 | 草稿模型 | 測試提示詞 | 未啟用 → 啟用後 | 倍率 |
|---|---|---|---|---|
| Qwen2.5-32B Q4_K_M | Qwen2.5-0.5B Q4_K_M | 寫 quicksort | 21.84 → 45.15 tok/秒 | 2.07× |
| Llama 3.1 8B Q8_0 | Llama 3.2 1B Q4_0 | 解釋畢氏定理 | 50.11 → 68.40 tok/秒 | 1.36× |
| Llama 3.1 8B Q8_0 | Llama 3.2 1B Q4_0 | 規劃一日行程 | 46.90 → 49.09 tok/秒 | 1.05× |
重點摘要:
- 同一台機器上,32B 主模型拿到 2 倍多;8B 主模型則是 1.36× 與 1.05× 兩種結果。
- 同一組模型配對,倍率會因為任務不同而差很多——8B 那組換個提示詞就從 1.36× 掉到 1.05×,幾乎等於沒開。
- 主模型越大,推測解碼越划算;主模型本來就快,收益就不穩定。
道理不難懂:推測解碼賺的是「大模型每一步的固定成本很高」這件事。主模型本來就跑得飛快時,草稿模型的開銷佔比就變得無法忽略。LM Studio 官方也明白寫出反效果的兩個主因:草稿模型相對於可用資源太大,以及接受率太低;後者跟模型與提示詞內容有關,並直言在拒絕多於接受的情況下,總生成速度會下降。
現在有哪些工具支援?
- llama.cpp:官方文件以
llama-server為說明對象。草稿模型參數為--spec-draft-model(短旗標-md,舊名--model-draft),草擬長度為--spec-draft-n-max(預設 3)。另有--spec-type可選擇實作方式。 - LM Studio:自 0.3.10(2025 年 2 月 18 日發布) 起於
llama.cpp與MLX兩個引擎支援,GUI 側邊欄可直接選草稿模型,也可在 API 請求中帶draft_model欄位;它還提供「視覺化已接受的草稿 token」功能,把來自草稿模型的字上色,綠色越多代表效果越好。想先把 LM Studio 跑起來的人可以看〈LM Studio 完整教學:不打指令,在 Windows 本地跑 LLM〉。 - NVIDIA TensorRT-LLM:支援單 GPU 與單節點多 GPU,並可搭配 NVIDIA Triton Inference Server 部署;NVIDIA 另指出 SGLang 與 vLLM 亦為可搭配的框架。
進階:連草稿模型都不用了
近兩年的發展方向,是把「第二個模型」這個包袱也拿掉:
- n-gram 類方法:llama.cpp 提供
ngram-simple、ngram-map-k、ngram-mod等實作,直接從已生成的文字裡找重複出現的片語當草稿,不需要任何額外模型。官方文件指出ngram-mod記憶體佔用約 16 MB,特別適合改寫程式碼、摘要,以及推理模型在最終答案中重述思考過程這類高度重複的場景。 - EAGLE / EAGLE-3:在目標模型內部層掛一個輕量的自迴歸預測頭(EAGLE head),用模型自己的隱藏狀態特徵去外推候選 token,免去訓練與執行第二個模型的開銷;EAGLE-3 進一步採用動態草稿樹與平行樹狀注意力,提升接受率與吞吐量。
- MTP(Multi-Token Prediction):DeepSeek 多代模型採用的做法,用多個預測頭各自負責猜第 1、2、3 個未來 token,主模型再依序驗證並保留最長相符前綴,同樣不需要獨立的草稿模型。llama.cpp 的
--spec-type也已列入draft-mtp這個選項。
💡 總結:冷知識延伸
站長我覺得 Speculative Decoding 最有意思的地方,是它根本不是 AI 領域原創的想法。LM Studio 官方在介紹文裡就講明了:這可以看成現代 CPU 裡那種推測執行(speculative execution)優化,只是套到了 LLM 推論上。CPU 在等待分支條件算完之前,會先賭一個方向把後面的指令跑下去,賭對了就直接沿用、賭錯了就把結果丟掉重來——半導體業界玩了幾十年的老招式,換個場景又救了一次 AI。
實務上有一件事值得記住:推測解碼的收益不是固定值,而是隨你在做什麼事而變。 寫程式、填表格、照格式產出 JSON 這類「下一個字很好猜」的任務,接受率通常很高,加速最明顯;而創意寫作、需要模型認真斟酌用詞的內容,接受率就低,收益自然縮水。這也是為什麼 LM Studio 官方會建議直接拿你真正在乎的任務去實測一輪,而不是看別人的數字。
想確認自己開了之後有沒有賺到,llama.cpp 會直接印出草稿接受率統計(draft acceptance rate,以及各實作的已生成 / 已接受 token 數),LM Studio 的 REST API 回應則會多出 total_draft_tokens_count、accepted_draft_tokens_count、rejected_draft_tokens_count 等欄位。數字擺在眼前,不用猜。
❓ 常見問題
Q:開了 Speculative Decoding,模型的回答會不會變差?
不會。這是這項技術最核心的設計保證:驗證階段只會接受「目標模型自己也會產生」的 token,兩篇原始論文分別以「不改變分佈」與「在硬體數值精度內保留目標模型分佈」表述。Leviathan 等人在 T5-XXL 上的示範更是輸出完全相同。要注意的是,這個保證講的是輸出分佈;在有隨機取樣(temperature 大於 0)的情況下,同一個問題本來每次答案就會不一樣,那與有沒有開推測解碼無關。
Q:草稿模型該挑多大?
從最小的開始試。NVIDIA 的官方數據顯示,Llama 3.1 70B 目標模型搭 1B 草稿的倍率(2.86×)高於搭 8B(2.23×);405B 目標模型則是 3B 最佳。原則是:草稿模型要遠小於主模型,LM Studio 官方也是同樣建議。
Q:為什麼我開了之後反而變慢?
兩個常見原因。第一,主模型不夠大——LM Studio 官方實測中,Llama 3.1 8B 搭 1B 草稿只拿到 1.36× 與 1.05×(同一組配對、不同提示詞),後者幾乎等於沒開。第二,接受率太低,可能是草稿模型與主模型不同家族、或你正在做的任務本來就難猜。llama.cpp 印出的 draft acceptance rate 是最直接的判斷依據。
Q:一定要另外準備一個模型嗎?
不用了。llama.cpp 的 n-gram 系列實作(如 ngram-mod,記憶體約 16 MB)完全不需要額外模型,直接從已生成文字裡找重複片語當草稿;EAGLE 與 DeepSeek 的 MTP 則是把草稿能力做進目標模型自己的預測頭裡。
Q:這跟量化(quantization)是同一回事嗎?
不是,而且方向相反。量化是把模型權重的精度降低來換取速度與記憶體,屬於有損的取捨;Speculative Decoding 不動模型權重,靠驗證機制保住輸出分佈,屬於無損加速。兩者可以同時使用——LM Studio 的實測就是在 4-bit 量化模型上再開推測解碼。
🔗 延伸閱讀
- 本地 LLM 顯卡軟體生態:NVIDIA CUDA vs AMD ROCm vs Vulkan 怎麼選
- Mac 跑本地 LLM 記憶體怎麼挑?Apple Silicon 統一記憶體與 M4/M5 選購全解析
- AMD Strix Halo 值不值得買?128GB 統一記憶體跑本地 LLM 的真相
- [\[深度解析\] 2026 本地端 AI (Local LLM) 硬體指南:NPU 是智商稅嗎?](https://adersaytech.com/tech-event/2026-local-llm-hardware-guide-npu-vs-gpu-vram.html)
📎 參考資料來源
📖 第一級|廠商官方與原始論文:
- Fast Inference from Transformers via Speculative Decoding(Leviathan、Kalman、Matias,arXiv 2211.17192,預印本 v2;ICML 2023 Oral) — 2026-08-11 查證
- Accelerating Large Language Model Decoding with Speculative Sampling(Chen 等人,arXiv 2302.01318,預印本) — 2026-08-11 查證
- An Introduction to Speculative Decoding for Reducing Latency in AI Inference|NVIDIA Technical Blog — 2026-08-11 查證
- TensorRT-LLM Speculative Decoding Boosts Inference Throughput by up to 3.6x|NVIDIA Technical Blog — 2026-08-11 查證
- llama.cpp 官方文件:Speculative Decoding(ggml-org/llama.cpp,docs/speculative.md) — 2026-08-11 查證
- LM Studio 0.3.10: Speculative Decoding|LM Studio 官方部落格 — 2026-08-11 查證