版本號跳到 0.7.0，加速先別急著信：llama.cpp 推測解碼的驗收三步

2026 年 10 月 15 日，一篇討論 llama.cpp 0.7.0 升級評估的文章在技術圈流傳。焦點不是版本號本身，而是兩個新功能：LiliCorr 推測解碼，以及 GLM5-Next 的 MTP 支援。很多人看到「推測解碼」四個字，直覺反應是本地模型要變快了；但這篇文章把問題往回拉了一步，先問你手上的模型、草稿模型與推論後端，到底接不接得上這次的新路徑。這與我們先前觀察過的ComfyUI 升級前檢查清單被當成顯學的社羣心態很像：版號一跳，檢查表先於興奮。

Q1：0.7.0 到底新增了什麼？

官方發布說明列出兩個項目。一是 LiliCorr 推測解碼，說明文字寫的是「candidate selection with a small draft transformer on top of DFlash」，也就是在 DFlash 草稿基礎上，加上小型草稿 Transformer 做候選選擇。二是 GLM5-Next 的 MTP（Multi-Token Prediction）支援，發布頁還提到搭配最佳化的稀疏注意力路徑。

這些是具體的功能入口。發布說明並沒有給出一個適用所有模型的固定加速幅度，也沒有附上通用基準結果。

Q2：推測解碼為什麼可能變快？

推測解碼的運作方式是：先由較輕量的路徑提出一批候選 token，再讓目標模型驗證。若候選被接受，目標模型可以用批次方式處理多個 token，減少逐 token 生成的等待；若候選不合，後續仍由目標模型處理。

所以效益取決於兩件事：草稿路徑的成本，以及候選的接受狀況。額外的推論路徑也可能增加記憶體或運算負擔。MTP 則是由模型內部的預測頭提出後續 token 候選，不需要一個獨立的小型草稿模型，但這是針對特定架構的設計，不能推論成任何模型都有同樣的路徑。

Q3：「支援」列入版本，等於我的模型能用嗎？

不等於。版本更新中的「支援」通常指程式碼新增了相應的架構或推論邏輯；實際啟用還牽涉模型格式、必要權重、tokenizer、模型轉換工具、執行參數與後端算子。目標模型載入成功，也不代表草稿或 MTP 路徑已正常運作，需要看啟動日誌、生成過程與最終輸出。

發布頁另外列出幾項與測試配置直接相關的變更：draft sampling 與 rejection handling 的修正，以及 --spec-draft-n-ubatch 參數可個別設定草稿批次大小。若部署依賴 server API、啟動參數或批次請求，這些使用路徑也要一併納入驗收。

Q4：驗收流程怎麼排？

先把目前環境記錄下來：執行版本、模型家族與版本、量化格式、模型檔來源、tokenizer、是否使用微調權重。草稿模型若需單獨載入，還要記下它與目標模型的對應關係與檔案版本。模型名稱相似不代表架構和 tokenizer 相容。

接著用固定工作負載比較升級前後的延遲、輸出品質與資源佔用。任何一環不支援，速度比較就無法代表預期部署情境。版本號本身回答不了「我的環境能否啟用」與「啟用後是否改善我在意的指標」這兩題，只有固定條件下的實測可以。

Q5：這波討論反映了什麼社羣心態？

本地推論圈對推測解碼的期待一直很高，因為它直接對應「免換硬體、跑得更順」的願望。但 0.7.0 這波討論裡，比較有價值的部分反而是那些不性感的前置作業：查相容性、記錄環境、控制變數。發布說明給的是技術入口，部署決策要的是自己的數據，兩者之間的落差，就是驗收流程存在的原因。