很多人第一個會先想到，推測解碼是不是能讓本地模型變快；但這裡要先問一個更前面的問題：目前使用的模型、草稿模型與推論後端，是否都能接上這次新增支援？llama.cpp 0.7.0 的發布說明列出 LiliCorr 推測解碼，以及 GLM5-Next 的 MTP 支援。這代表使用者多了測試入口，實際速度仍須回到自己的模型與工作負載驗收。
升級評估可拆成三件事：新增功能支援什麼路徑、現有環境能否啟用、啟用後是否改善最在意的指標。版本號本身不能回答後兩題。先記下目前執行版本、模型檔與後端，再以固定條件比較，才能把新功能的可能性轉成可供部署決策使用的證據。
llama.cpp 0.7.0 新增了哪些推測解碼支援？
官方發布說明列出 LiliCorr 候選選擇搭配小型草稿 Transformer，以及 GLM5-Next 的 MTP 推測解碼路徑；這些是具體功能項目，不能直接解讀為所有模型或後端都會加速。
LiliCorr 與 MTP 的角色
推測解碼（speculative decoding）會先由較輕量的路徑提出一批候選 token，再讓目標模型驗證候選。若候選能被接受，目標模型可用批次方式處理多個 token，減少逐 token 生成的等待；如果候選不合，仍要由目標模型處理後續。它的效益取決於草稿成本與候選接受狀況，額外的推論路徑也可能增加記憶體或運算負擔。
MTP（Multi-Token Prediction，多 token 預測）是由模型內部的預測頭或相關結構提出後續 token 候選，不一定依賴一個獨立的小型草稿模型。llama.cpp 的 0.7.0 發布頁將 GLM5-Next 的 MTP 支援列為推測解碼項目，並提到搭配最佳化的稀疏注意力路徑。這是針對特定架構的功能資訊，不能推論成任何模型都具備同樣的 MTP 路徑。
LiliCorr 則在發布說明中描述為「candidate selection with a small draft transformer on top of DFlash」，也就是在 DFlash 草稿基礎上加入小型草稿 Transformer 的候選選擇方式。這能說明 0.7.0 增加了什麼技術入口，卻沒有提供一個適用所有模型、顯示固定加速幅度的基準結果。導入時應先問目標模型是否有相應草稿資料與轉換流程，再看該路徑能否在目前編譯與硬體環境執行。
「LiliCorr speculative decoding: candidate selection with a small draft transformer on top of DFlash」是 llama.cpp v0.7.0 發布說明對該項目的描述。這句話說明技術組成，沒有宣告所有工作負載的速度提升幅度。來源：ggml-org/llama.cpp v0.7.0 release notes。
功能列入版本，不代表手上的模型可用
版本更新的「支援」通常表示程式碼新增相應架構或推論邏輯，啟用條件仍可能包括模型格式、必要權重、tokenizer、模型轉換工具、執行參數和後端算子。目標模型載入成功，也不等於草稿或 MTP 路徑已正常運作；需要看啟動日誌、生成過程與最終輸出。
官方發布頁也列出其他核心變更，例如 draft sampling 與 rejection handling 的修正，以及 --spec-draft-n-ubatch 參數可個別設定草稿批次大小。這些細節可能影響測試配置或資源分配，但不能在缺少工作負載實測時推導出效能結論。若部署依賴 server API、啟動參數或批次請求，也要把這些使用路徑一起納入驗收。
為什麼驗收要先確認模型與執行環境？
先確認目標模型、草稿或 MTP 路徑、模型檔與編譯後端是否彼此相容，再開始量測；任何一環不支援，速度比較就無法代表預期部署情境。
對齊目標模型、草稿路徑與模型檔
第一步是列出目標模型的完整識別資訊：模型家族與版本、量化格式、模型檔來源、tokenizer、轉換日期，以及是否使用經過微調的權重。草稿模型若需要單獨載入，還應記錄它與目標模型的對應關係、檔案版本與量化方式。模型名稱相似不代表架構和 tokenizer 相容；格式可讀也不代表候選 token 能被目標模型正確驗證。
MTP 路徑則要確認目標模型本身是否具有所需預測結構，並使用支援這條路徑的模型檔與程式版本。GLM5-Next 的發布項目只能證明發布方將該架構列入支援範圍，其他模型能否使用應查對各自的模型文件與版本說明。若模型由第三方轉檔，保存轉換器版本、轉換參數與來源權重，方便失敗時定位問題。
模型檔可以載入，但推測解碼路徑仍可能因候選輸出格式或執行參數而未啟用。驗收記錄應包含實際啟用的推測類型、草稿 token 數、批次設定與日誌中顯示的路徑。不要只看命令列沒有報錯，就判定新功能已進入生成流程。
編譯版本、推論後端與硬體條件
本地推論環境可能使用 CPU、CUDA、Metal、Vulkan 或其他後端；相同的模型與推測策略，在不同後端上會走不同的算子與記憶體配置。除了 llama.cpp 的版本標籤，還要記下實際 commit 或發行包、編譯選項、驅動程式、作業系統、處理器與 GPU、可用記憶體，以及模型層如何分配到裝置。
推測解碼增加草稿計算和候選驗證。若草稿模型占用大量 VRAM，可能擠壓目標模型或 KV cache（鍵值快取）的空間；若草稿工作落在不同裝置，資料傳輸也會進入延遲。批次大小、上下文長度與同時請求數同樣會改變資源壓力。這些是需要觀察的變因，不代表每種配置都會遇到相同瓶頸。
因此，測試要先設定符合部署需求的資源上限。若正式服務會同時處理多個請求，單一請求下的速度增加未必能代表整體吞吐量或尾端延遲。若使用者最在意互動等待，首 token 延遲與整段生成時間可能比高併發吞吐量更有參考價值；指標需由實際使用情境決定。
升級前後如何設計可比較的測試？
保留同一批提示詞、模型、取樣設定、輸出長度、硬體與請求方式，只替換 llama.cpp 版本或推測解碼選項；分開記錄速度、品質和資源指標，才看得出差異來自哪個改動。
固定提示詞、取樣設定與輸出長度
先從常用任務挑一組可重複的提示詞，涵蓋短回答、長回答、程式碼或結構化輸出等真實工作負載。每個案例都保存完整輸入、系統提示、上下文長度、取樣方式、溫度、top-p、停止條件與最大輸出 token 數。若模型以隨機取樣生成，需固定 seed 或進行多輪重複，並在解讀結果時保留輸出的隨機性。
基準版本與 0.7.0 使用相同模型檔、量化、提示詞和硬體。先在不啟用推測解碼的情況比較版本本身，再在 0.7.0 下比較關閉與開啟 LiliCorr 或 MTP 的結果。如此可分辨差距是來自版本更新、推測路徑，還是硬體與設定變動。一次只改一類條件，避免把多個改動的影響混成一個數字。
測試前先讓模型完成暖機，記錄每次運行的順序與背景負載。至少多跑幾輪，觀察中位數與波動範圍，不要挑一次最快結果當結論。若部署流量會有不同長度或併發，另外保留相應測試組，避免以單一短提示替代全部實際工作。
分開看延遲、速度、品質與資源
效能不能只看每秒 token 數。建議至少分開記錄首 token 延遲、生成階段 token/s、完整回覆時間、請求成功率、GPU/CPU 使用率、峰值 VRAM 或記憶體，以及併發時的排隊狀況。對聊天場景，首 token 的等待感受和長回答的生成速度是兩個不同問題，平均值也可能掩蓋偶發的慢請求。
品質則要用符合任務的檢查方式比較。結構化輸出可檢查格式有效率與欄位完整度；程式碼可跑既有測例；問答任務可由固定評分規則或人工盲測比較事實、指令遵循和完整性。不要預設推測路徑一定維持完全相同的輸出，也不要只因回答文字不同就立刻判定品質下降，評估規則需先訂清楚。
llama.cpp 官方文件將推測解碼說明為：草稿路徑先提出候選，再由目標模型批次驗證；候選常被接受時，才可能得到加速。這是理解機制的條件說明，不是對特定裝置的測速結果。驗收時可同步查看候選接受情況或相關日誌，並把它與延遲及資源變化放在一起分析。
「By generating draft tokens quickly and then verifying them with the target model in a single batch」是 llama.cpp 推測解碼文件對流程的概述。文件接著指出，草稿預測經常正確時，這種方式才可能取得速度效益。來源：ggml-org/llama.cpp docs/speculative.md。
哪些工作流值得先試，何時保留舊版？
優先選擇高頻、可重現、輸出可檢查且有明確延遲門檻的任務；只有相容性、品質與資源都符合部署條件，才擴大升級範圍。
從高頻且可重現的任務開始
適合先試的工作流通常有固定模型與輸入範本，例如內部文件摘要、程式碼補全、固定格式資料抽取，或測試環境中的常見問答。它們容易保存測試案例，也能從既有使用紀錄定義「夠快」的門檻。先選一個任務可降低排查成本，通過後再加入長上下文、多輪對話或較高併發的場景。
若提示詞變化很大、輸出無法客觀檢查，或工作負載本來就受磁碟讀取、網路等待、資料庫查詢等因素限制，推測解碼帶來的差異可能不容易辨識。此時可先拆開整體流程，確定模型生成是主要等待來源，再投入 A/B 測試。這樣能避免只因版本新就變更服務，卻沒有改善使用者真正等待的環節。
用部署門檻決定升級範圍
開始測試前，先定義最低條件：目標模型與後端能正常啟動、輸出通過品質檢查、延遲達到需求、資源峰值留有餘裕，並且回退方式已準備好。若只有部分模型或裝置通過，就按通過範圍逐步部署，不必把整個模型庫一次切換。記下實際通過的版本、模型與硬體組合，避免把單一環境結果擴張成普遍承諾。
若新版本無法啟用預期路徑、候選接受狀況不理想、輸出品質退步，或資源使用超過上限，先保留目前穩定版本。接著檢查模型檔、啟動參數、編譯後端與日誌，逐項縮小問題範圍。測試不通過也是有效結果，它可以指出這個工作流目前不適合升級，或需要先調整草稿模型及資源配置。
- 保存現行版本、模型檔、提示詞、取樣設定、硬體與資源基準。
- 在同一環境分別測試原版本、0.7.0 基準模式，以及可用的 LiliCorr 或 MTP 路徑。
- 比對多輪延遲、生成速度、輸出品質和資源峰值，對照事先設定的門檻。
- 僅將通過測試的模型與工作流納入升級，保留可回復的舊版設定。
常見問題：MTP、推測解碼與版本升級
先把 MTP 或 LiliCorr 視為需驗證的推論路徑，再用相同工作負載測試；版本發布資訊能確認功能清單，不能代替本地相容性和效能驗收。
升級後是否一定會變快？
不一定。候選生成與驗證的成本、候選接受情形、模型大小、上下文、後端和硬體都會影響結果。若草稿階段花費的時間高於驗證所省下的時間，總延遲可能沒有改善。應以自己的請求組合實測，並明確標示測試環境。
如何判斷差異來自版本還是環境？
先固定模型檔、提示詞、取樣設定和硬體，再分別測版本差異與推測路徑差異。記錄編譯選項、驅動程式、資源負載和測試順序，多跑幾輪比較分布。若中途更新模型檔或改變 GPU 層配置，就另立測試組，不與原組直接合併。
未通過驗收時要記錄什麼？
保存完整啟動命令、版本或 commit、模型與草稿檔案識別、後端和裝置、日誌、錯誤訊息、提示詞、輸出結果、延遲與記憶體資料。這些資訊有助於區分載入失敗、推測路徑未啟用、候選效果不佳和資源不足。修正一項條件後重跑同一組案例，才能確認原因是否排除。
- v0.7.0 列出 LiliCorr 與 GLM5-Next MTP 支援，功能清單不等同通用效能承諾。
- 升級前核對目標模型、草稿或 MTP 路徑、編譯版本、推論後端與硬體。
- 以相同提示詞與設定比較延遲、生成速度、輸出品質及資源使用，再按通過的工作流逐步升級。
先挑一個常用且可重現的本地推論工作流，記錄現行版本與測試條件，再以相同設定比較 0.7.0。確認相容性、輸出品質與延遲都符合部署門檻後，再擴大升級範圍。
