第 9 章 — 推測解碼

發佈於: 2026-05-01 最後更新於: 2026-07-08 版本: 1
第 9 章 — 推測解碼

第 9 章 — 推測解碼

LLM Primer VI:擴展 AI 系統》章節走讀的第九篇。這一章顯示自回歸的循序瓶頸其實有一個數學上的漏洞 — 並展示它何時值得付出代價的算術。


這一章為什麼存在

第 7、8 章攻擊了並行度,讓 GPU 在許多序列之間保持忙碌。這兩者都沒改變一件事:每個序列還是每次迭代收到一個輸出 token。這個地板看起來無法閃避,因為 transformer 的前向傳遞確實依賴前一個被挑出來的 token。推測解碼的洞察是,這個依賴是對生成的、不是對驗證的:給定一個 t+1 的候選,目標模型可以跑一次前向傳遞,同時問「我當初會挑這個嗎?」並在假設候選正確的前提下運算 t+2 的分布。第 9 章走過機制、草擬演算法(EAGLE、Medusa、Lookahead、MTP、n-gram、suffix),以及推測何時值得的算術。

一句話總結:推測解碼付出一次便宜的猜測與一次稍微加寬的驗證傳遞,如果猜測夠常正確,目標模型就能在一次前向傳遞的牆上時間內產出好幾個 token。

9.1 驗證洞察精確保留了正確性

一個便宜的草擬機制提議 N 個候選 token。目標 — 我們真正想要的貴模型 — 對「前綴接上這 N 個候選」跑一次前向傳遞。因為 transformer 的前向傳遞在位置之間是平行的,目標會在同一次傳遞裡為 N+1 個位置各自產出自己的下一個 token 分布。候選與目標一致的最長前綴被接受;第一個分歧的位置就是引擎採用目標自己的選擇、並把其餘丟掉的地方。接受規則 — 以機率 min(1, p(x)/q(x)) 接受從草擬 q 抽出的 x,否則從歸一化後的殘差 (p−q)₊ 抽樣 — 讓輸出分布跟純粹的目標取樣完全一樣。推測是「精確保留正確性」的;草擬只影響速度。在現代 GPU 上,N=4 的驗證傳遞成本大約是一次正常 decode 步驟的 1.2 到 1.5 倍,因為注意力現在跨越 N+1 個查詢位置,但仍然穩穩地落在受記憶體所困的區間裡。

9.2 EAGLE 把草擬綁在目標的隱藏狀態上

早期實作用另一顆小模型當草擬 — Llama-7B 替 Llama-70B 草擬 — 這行得通,但要付另一份 HBM 串流給草擬的權重,而且接受率被限制住,因為兩個模型的表示不共享。EAGLE 在 2024 到 2025 年之間經 EAGLE-2、EAGLE-3 演進,把草擬綁在目標上:一層被訓練來預測目標下一層隱藏狀態的 transformer 層,再投影過目標自己的輸出 embedding。沒有另外一份 7B 權重要串流;草擬頭只有幾百 MB。EAGLE-2 加上動態草擬樹擴張 — 一棵候選樹在一次注意力傳遞裡用自訂的 mask 一起驗證 — 所以目標會從幾條路徑挑最好的,而不是只吃草擬的單一猜測。EAGLE-3 加上多層特徵混合,消化的是中間的目標層,而不只是倒數第二層。接受率在聊天與程式碼上落在 75 到 85%,搭配 N=5 到 8,對純 decoding 轉換成 3 到 4 倍的端到端加速。Medusa 走另一條路 — 平行的草擬頭在一次傳遞裡預測好幾個未來 token,而不是自回歸地預測 — 訓練故事更簡單、接受率略低。N-gram 與 suffix 解碼則是給重複性工作量(程式碼編輯、模板輸出)的免費午餐,草擬就是最近上下文的一次查表。

9.3 驗證傳遞本身變成上限

加速公式精確到可以寫下來:E[accepted_tokens] / (T_draft/T_decode + 1 + α·N),其中 α 是每個位置的驗證開銷,通常 0.05 到 0.15。有兩個上限會浮現。第一,α·N 隨 N 成長,所以無限增大 N 幫不上忙;p=0.8 時的峰值大約在 N=6 到 8,p=0.9 時大約在 N=10 到 12。硬編碼 N 的引擎,在工作量變動時會錯過最佳點。第二,而且更微妙,當 p 趨近 1 時的漸近加速是 1/α — α=0.10 時大約 10 倍、α=0.05 時大約 20 倍 — 因為驗證傳遞本身就是那道牆。生產引擎在高度重複性工作量上量到的峰值加速都落在這個區間裡,沒超過。推測還跟批次互動:在高批次下目標的前向傳遞已經接近受制於運算,額外的驗證 token 會把它再往前推,所以加速會隨批次成長而縮小。推測的甜點是低到中批次、延遲關鍵的工作量 — 剛好就是第 1 章那些「未被使用的運算」所住的區間。

值得記住:推測是花閒置的運算去買回循序瓶頸的延遲。它跟批次是互補的,不是替代品 — 在非常高的批次下目標已經在用掉自己的運算,驗證傳遞會啃食吞吐量而不是替吞吐量加分。

第 9 章鋪陳出來的東西

第 5 到 9 章已經把「模型與執行期」的工具箱走完了 — 量化、剪枝、蒸餾、批次處理、分頁式 KV、推測解碼。它們沒有任何一個是你 pip install 就能忘掉的函式庫。有人得把它們拼起來,做成一個擁有 GPU 上某顆模型、跑連續批次、對外暴露推論 API 的執行期。那個執行期就是引擎。第 10 章走過 2026 年堆疊主流的五個引擎 — vLLM、TensorRT-LLM、SGLang、TGI、Ollama — 以及決定某次部署該挑哪一個的機械式取捨。


下一篇 — 第 10 章:LLM 引擎層vLLM、TensorRT-LLM、SGLang、TGI、Ollama — 把引擎當成單節點執行期,以機制而非跑分來挑。

想看完整的全貌?書中章節包含可執行的推測解碼內迴圈、Medusa 平行頭架構、Lookahead 與 MTP 的訓練期變體、n-gram/suffix 的工作量情境,以及會隨負載縮小或放大的批次互動分析。在 Amazon 查看 LLM Primer VI →

下田 昌平
下田 昌平
RECEIPTROLLER 的 CTO 與創辦人。專注於數據、驅動創新、始終保持好奇心。