投機解碼為何更快：算得更少是誤解，它把記憶體瓶頸換成算力
投機解碼提速並不是因為計算量更少，恰恰相反，同一序列的浮點運算總量反而上升。它快在改變了 GPU 的工作型別：逐個 token 解碼時 GPU 處於記憶體瓶頸、算力閒置，而用小草稿模型一次並行驗證多個 token，等於用閒置算力換取單條序列的深度推進。被拒絕的草稿 token 都是白做的功，高吞吐場景下反而浪費算力，因此 vLLM 提供 --speculative-disable-by-batch-size 引數按批大小整體關閉該功能；
澄清了投機解碼實際執行更多 FLOPs 這一反直覺事實，並給出 vLLM 的關閉引數與動態投機深度思路，對做本地推理和推理服務吞吐調優的人有直接參考價值。
原標題：Why Is Speculative Decoding Fast?
閱讀原文
| 評分 | 70 / 70（平均 70，門檻 76） |
|---|---|
| 狀態 | 未入選 |
相關報導
llama.cpp 為草稿模型與 MTP 加入機率取樣
llama.cpp 合併 PR #27694，為 simple draft 與 MTP 推測解碼引入機率取樣：草稿端按機率取樣，目標模型用拒絕取樣驗證，並修復草稿取樣器與目標模型共用 RNG 流等問題。新增開關控制機率草稿取樣，預設仍為貪心；語法約束請求回退到 argmax，同時支援在拒絕取樣中處理語法約束。改動由 NVIDIA 工程師參與提交，隨各平台建置一同發布。
九章雲極發布 GLM-5.3 推測解碼方案，單併發解碼提速 3.41 倍
九章雲極為 GLM-5.3 推出推測解碼加速方案 Alaya-DFlash2，在 8×H200、TP=8 單併發下解碼速度達 288.2 tokens/s，為原生自迴歸 84.5 tokens/s 的 3.41 倍，總輸出吞吐從 78.95 提升至 236.47 tokens/s。64 併發時吞吐 608.71 tokens/s，較原生提升 44.9%；32k 上下文下草稿接受長度 5.39，高於參評的 IncoAI-DFlash2 與 RedHat-DSpark。
llama.cpp SYCL 後端為 IQ3 加持久權重重排，解碼提速最高 82%
llama.cpp 的 SYCL 後端為 IQ3_S/IQ3_XXS 加入持久化權重重排，在 Intel Arc Pro B70 上解碼速度最高提升 82%。權重在載入時只重排一次，MMVQ 點積改用 dp4a 與 SWAR 符號擴充套件遍歷稠密超級塊，重排感知的反量化也接入批次 prefill 的 GEMM。
llama.cpp v0.7.0 發布：MoE 專家快取最高帶來 2.2 倍解碼提速
llama.cpp 發布 v0.7.0，最核心的變化是新增主機記憶體 MoE 專家的 GPU 快取（--moe-cache-mib），專家改由裝置端 LRU 快取執行，專家解除安裝時解碼最高提速約 2.2 倍，且該快取可跨多張 GPU 共享。版本同時加入 LiliCorr 投機解碼與 GLM5-Next 的 MTP 投機解碼，並支援 K2 Horizon、Prism Bonsai 2 27B、EmbeddingGemma-2、MiniCPM-V 4.7 等一批新模型。
llama.cpp 修復 k-pool 模型圖重分配導致的解碼中止
llama.cpp 發布 b11412，修復 k-pool 模型（qwen4exp、glm5-next）解碼時意外重新預留計算圖並中止的問題。原因是兩模型按 cache_safe、n_tokens 等 reserve 無法預知的狀態分支，解碼圖與預留圖節點數不一致（如 7564 對 7762），解碼時被迫按當前狀態重預留、丟掉最壞情況尺寸，在 GGML_SCHED_DEBUG_REALLOC=1 下直接 abort。