同一台電腦、同一個模型、同一段提示詞，左側的回答已經生成完畢，右側還在逐字往外蹦。
Hugging Face最近用一場長達82分鐘的技術直播演示了這組對比。兩邊運行的是同一個目標模型，輸出質量也由同一個模型把關，區別只在於左側多了一個很小的「草稿模型」。
在部分測試中，這種組合把單請求生成速度提高到原來的近4倍；即使並發請求不斷增加，仍能獲得約2倍的吞吐提升。沒有更換顯示卡，也沒有把大模型繼續壓縮，變化發生在Token生成方式上。
這項技術叫做推測解碼，英文是Speculative Decoding。它正在被llama.cpp、Transformers和vLLM等主流推理框架吸收，也讓「草稿模型」逐漸成為本地運行大模型時一個繞不開的角色。
大模型為什麼總在「逐字加載自己」
一次大模型推理通常分為預填充和解碼兩個階段。
用戶輸入提示詞後，模型會在預填充階段集中處理整段內容，計算注意力並建立KV Cache。這個階段一次處理大量Token，主要受計算能力影響。開始回答以後，模型進入解碼階段，每次只能生成一個Token。
問題也出現在這裡。
為了生成下一個Token，顯示卡需要讀取模型權重和已有的KV Cache；生成完成後，再把新的鍵值數據寫入緩存。隨後，為了生成下一個Token，這個過程重新執行一遍。
一個模型有幾十GB甚至幾百GB權重，生成每個Token都要搬運大量數據。此時GPU擁有多少計算單元已經不再是唯一決定因素，顯示記憶體頻寬以及數據搬運速度會直接限制生成速度。
草稿模型的思路，是把一部分容易預測的工作交給一個更小、更快的模型。
例如，用戶輸入「The cat」，草稿模型可能連續預測「sat on my lap」。目標模型隨後用一次前向計算檢查這些候選Token。前兩個Token如果符合目標模型的概率分布，就會被直接接受；第三個Token被拒絕，後續候選也會隨之丟棄，再由目標模型生成修正Token。
過去目標模型需要運行三四輪才能完成的工作，現在有機會壓縮到一輪驗證中。草稿模型體積很小，生成候選Token的成本遠低於目標模型多次讀取完整權重的成本。Hugging Face官方文檔也將其概括為：助手模型先提出候選Token，主模型通過一次前向計算集中驗證。
推測解碼看起來像一頓「免費午餐」，真正決定加速效果的指標叫作平均接受長度，也就是目標模型每輪平均接受多少個草稿Token。
草稿模型一次預測4個Token，如果其中3個被目標模型接受，相當於用一次大模型計算推進了多個位置。草稿模型如果頻繁猜錯，目標模型只能不斷否決和修正，額外計算反而可能拖慢整個生成過程。
這也解釋了為什麼草稿模型不能隨便搭配。
用於法律文本的目標模型，配上一款主要訓練代碼的草稿模型，兩者的Token概率分布差異很大，接受率很可能快速下降。模型開發者提供的配套草稿模型通常更穩，因為它們針對目標模型的數據分布、隱藏狀態和詞表進行了專門訓練。
草稿長度同樣需要控制。一次預測8個Token，看起來比預測4個更有效率，但第三個Token一旦被拒絕，後面的5個全部作廢。影片中的建議是從較短長度開始測試，4個Token通常是相對安全的選擇，結構穩定的代碼和數學任務可以嘗試更長的草稿。
結構化任務也是草稿模型更容易發揮作用的場景。代碼必須遵守固定語法，數學推導中也存在大量可預測模式；故事和詩歌追求更多隨機性，草稿模型更難提前猜中目標模型的選擇。
傳統推測解碼使用一款獨立小模型，自回歸生成候選Token。EAGLE進一步讀取目標模型的隱藏狀態，讓草稿模型獲得更多上下文資訊，提高候選Token的接受率。
DFlash採用了另一種方法。它通過輕量擴散模型一次並行預測一整塊Token，減少草稿模型內部的串行生成。官方說明顯示，在同步請求中，DFlash可能獲得比EAGLE-3高2至3倍的加速，但實際表現仍取決於模型、任務和硬體配置。
MTP，即多Token預測，則把預測多個未來Token的能力放進模型或配套檢查點中。部分模型自帶MTP層，Gemma 4等模型採用獨立助手檢查點，並復用目標模型的輸入嵌入和KV Cache。Transformers和vLLM已經提供了相應的加載方式。
影片展示的Gemma 4 E2B草稿模型不到1億參數，目標模型約為20億參數。草稿模型復用目標模型的隱藏狀態，通過4層解碼器快速預測候選Token，再交回目標模型集中驗證。一次草擬3個Token時，目標模型如果接受前兩個，還能在同一輪計算中補上一個修正Token，相當於一次前向計算推進了3個位置。
接近4倍加速，也有明確的適用邊界
影片公布的一組Gemma測試顯示，使用DSpark草稿模型後，單請求場景獲得了接近4倍的速度提升；隨著並發請求增加，收益下降到約2倍。另一組Gemma 4測試中，MTP的提升範圍約為1.6倍至3.5倍。
並發越高，GPU一次可以批量處理的請求越多，原有推理方式對硬體的利用率也隨之提高，草稿模型帶來的額外收益便會縮小。DFlash一類並行草稿技術在低並發下優勢明顯，進入高並發場景後，MTP可能表現得更穩定。
任務分布也會改變結果。數學、代碼等低熵任務更容易預測；開放式創作或訓練數據之外的任務會降低接受率。影片中的DFlash測試在高熵任務上，有時只能追平MTP，甚至可能更慢。
「無損」也需要準確理解。推測解碼保證輸出仍來自目標模型的概率分布，草稿模型沒有最終決定權。採用貪婪解碼時，短輸出通常可以做到Token級一致；隨著序列變長，不同CUDA Kernel、浮點誤差和採樣實現仍可能讓輸出逐漸出現差異。
llama.cpp目前已經支持普通草稿模型、EAGLE-3、DFlash、DSpark、MTP和多種N-gram推測方式，並會輸出草稿生成數、接受Token數與接受率等統計資訊。
對本地大模型用戶來說，草稿模型帶來的價值很具體：當模型已經能夠裝進顯示記憶體或統一記憶體，下一道門檻往往就是生成速度。此時繼續量化可能損失能力，更換硬體又意味著新的成本，推測解碼則提供了一條軟體優化路徑。
但它真正加速的前提，始終是草稿足夠快，也足夠准。觀察Token/s之外，還應記錄平均接受長度、草稿接受率、首Token延遲、並發吞吐和額外記憶體占用。只有這些數字同時成立，草稿模型才算真正替目標模型省下了時間。
影片開頭那場速度對比，最終可以歸結為一次計算分工：幾十億、上百億參數的目標模型負責判斷方向，體積小得多的草稿模型負責處理容易預測的Token。大模型依然掌握最終決定權，卻不必親自完成每一步重複工作。
這也給本地大模型優化提供了一個新的觀察角度。模型已經裝進記憶體之後，速度提升未必只能依賴更高頻寬的顯示記憶體、更激進的量化或價格更高的顯示卡。草稿模型如果擁有足夠高的命中率，同樣能把現有硬體的性能繼續向前推一步。接下來真正值得比較的，將是不同草稿模型在代碼、數學、長文本和開放式創作中的接受率，以及它們能否在普通個人電腦上穩定兌現宣傳中的數倍加速。
