llama.cpp v0.7.0 於二零二六年十月十五日發布。這個以 C/C++ 撰寫的推論引擎在 GitHub 累積 132,503 顆星標與 24,856 個分支，採 MIT 授權。本版最受關注的改動是混合專家快取：把留在主機記憶體的專家權重透過顯示卡上的最近使用快取調用，官方數據顯示卸載情境下解碼速度最多提升 2.2 倍，且快取可跨多張顯示卡共用。
同版另加入 LiliCorr 投機解碼與 GLM5-Next 的多詞元預測支援，並把伺服器預設連接埠由 8080 改為 9931。十多款新模型架構同時納入，涵蓋多模態嵌入與決策模型兩類用途。
llama.cpp v0.7.0 是什麼？
llama.cpp v0.7.0 於十月十五日發布，主打 MoE 專家主機記憶體快取與 LiliCorr 投機解碼，並把伺服器預設連接埠改為 9931。
這個專案自二零二三年三月建立以來，定位一直是把大型語言模型推論下放到一般硬體。它以零外部依賴的實作搭配 GGUF 量化格式，讓 CPU、Apple Silicon 與多家顯示卡後端都能執行同一份模型檔案。
v0.7.0 的發行說明篇幅罕見地長。條目涵蓋核心圖執行、取樣、分詞器、伺服器層與模型轉換工具，顯示這一版並非單點修補，而是一次跨層的整理與擴充。對日常使用者而言，最直接的感受會落在推論速度與可用模型清單；對部署團隊而言，連接埠與 API 的變動影響更大。
專案活躍度維持高檔。儲存庫在查詢當日仍有提交紀錄，累計分支接近兩萬五千，議題數量維持在數百項的區間，社群貢獻者規模逾兩千人。這種節奏意味著 nightly 建置幾乎每日更新，穩定版本則以較長週期收斂。
MoE 專家快取如何帶來 2.2 倍解碼加速？
混合專家的權重原本留在主機記憶體，每次運算都要搬運。新的 –moe-cache-mib 把常用專家放進顯示卡快取，官方量測解碼速度最多提升 2.2 倍。
混合專家架構的記憶體難題在於總量與頻寬。模型總參數可能達數百億，但單次前向運算只啟用少數專家，把全部權重塞進顯示記憶體並不划算，於是把專家留在主機記憶體、按需搬運成為常見折衷。代價是每次搬運都要付出匯流排延遲。
快取機制改變了這個折衷的成本結構。實作方式是在裝置上保留一塊由最近使用順序管理的專家池，常用專家直接從顯示卡讀取，只有未命中時才回到主機記憶體搬運。參數以百萬位元組為單位設定上限，團隊可依顯示記憶體餘裕調整。
跨顯示卡共用是這一版另一個進展。多卡環境下各張卡不再各自維護重複的專家副本，而是共用同一組快取，等於把有限的顯示記憶體留給 KV 快取與批次處理。對執行大型混合專家模型的工作站而言，這項改動可能直接決定能否把模型留在單機。
為何伺服器預設連接埠從 8080 改成 9931？
官方把伺服器預設監聽埠由 8080 改為 9931，避免與其他服務衝突。容器映像內部仍維持 8080，Docker 部署不受影響。
8080 是網路服務最常見的備用埠，開發機上一次啟動多個服務就很容易撞埠。改用 9931 之後，衝突機率下降，除錯時也較容易辨識流量來源。
影響範圍取決於部署方式。Docker 映像在容器內仍監聽 8080，由外部對映決定實際埠號，因此既有容器設定可以照舊運作。直接下載執行檔或自行編譯的環境，啟動後會發現服務不在原本位址，反向代理與健康檢查腳本需要一併更新。
這類預設值變更通常不會出現在效能討論中，卻是升級時最容易出錯的環節。若服務前面有負載平衡或程序管理工具，位址寫死在設定檔的情況相當普遍，升級前先搜尋設定中的連接埠字串，可以省下排查時間。
這次更新支援哪些新模型架構？
本次納入 K2 Horizon 的稠密與 MoVA 變體、三元模型 Prism Bonsai 2 27B、多模態 EmbeddingGemma-2，以及多款決策模型。
新模型清單反映社群的關注方向。多模態嵌入模型開始把文字、影像與音訊放進同一個向量空間，這對檢索增強流程的設計有直接影響；三元權重模型則把量化推到極端，以精度換取體積與速度。
決策模型的出現值得留意。這類小模型輸出的不是長篇文字，而是動作選擇或分類結果，常被用作代理流程中的路由層。同時納入多個來源的決策模型，顯示推論引擎正被期待承擔代理系統的基礎設施角色。
部分架構的支援範圍超出單純載入。K2 Horizon 的 MoVA 變體同時處理轉換、分詞器、對話模板與張量分割；PLaMo-3 的分詞器實作了參考實作的前置切分，以達成逐位元組一致的切詞結果。這些細節決定模型輸出能否與原廠一致，也是實務上最常被忽略的相容性問題。
投機解碼在 v0.7.0 有什麼變化？
本版加入 LiliCorr 投機解碼，以小型草稿轉換器挑選候選詞，並為 GLM5-Next 提供 MTP 支援與稀疏注意力路徑。
投機解碼的原理是用較小的模型先猜幾個詞，再由主模型一次驗證。猜中越多，單位時間輸出的詞量越高；猜錯則浪費運算。這種做法的效益高度取決於草稿品質與驗證成本。
LiliCorr 的著力點在候選挑選。它以一個小型草稿轉換器搭配 DFlash 產生候選，讓候選分佈更接近主模型，減少被拒絕的比例。對長文本生成任務而言，這類改良通常表現為穩定的吞吐提升，而非單次延遲下降。
記憶體佔用也有對應調整。新增的參數可獨立設定草稿情境的批次大小，避免草稿階段佔用與主模型相同的顯示記憶體。搭配既有的部分 KV 檢查點旗標，草稿階段不再攜帶完整快取，長對話累積下來的節省相當可觀。
伺服器 API 有哪些破壞性變更？
對話層改以 common_chat_session 重寫，格式化輸出由單一字串改為分段陣列，客戶端需同步調整解析邏輯。
新版把聊天工作階段抽成獨立物件，對外提供送入與結束兩個方法。這種設計讓多輪對話的狀態管理集中在伺服器端，客戶端不必自行拼裝歷史訊息。對自建應用的團隊而言，介面變得更清楚；對既有整合而言，則是必須改寫的部分。
輸出格式的變化影響更直接。原本回傳的格式化字串被替換為由多個片段組成的陣列，每個片段帶有型別資訊。這樣的結構更適合處理工具呼叫、推理段落與純文字的混合輸出，但客戶端必須逐段處理，不能整段當作純文字顯示。
C 函式庫層同樣有增補。新增的專家快取大小參數、新的詞表型別與圖重新配置的效能計數，都屬於相容性擴充；行為變更則集中在嵌入計算與批次狀態回報。自行以函式庫整合的專案，建議先讀過變更清單再決定升級時機。
升級前需要注意什麼？
先確認連接埠設定與客戶端解析邏輯，再以 nightly 建置驗證模型載入。生產環境宜停留於穩定版本並保留舊版以便回退。
升級順序建議由小到大。先在一台開發機上以既有模型跑一次基準，記錄提示處理與解碼速度，作為後續比較的依據；再逐步把服務切換到新版，觀察延遲分佈與記憶體佔用是否出現異常。
混合專家模型的使用者可以優先試用快取參數。設定值太小不會帶來明顯收益，太大則可能擠壓 KV 快取的空間，建議從顯示記憶體餘裕的一半開始調整，並以實際請求模式觀察命中率。
版本管理需要明確紀律。專案同時發布語意化版本與每日建置，後者包含未經長期驗證的改動。把 nightly 用於嘗鮮、穩定版用於服務，是這個生態系常見的分工方式；若團隊人力有限，至少應固定一份可重現的建置紀錄。
出處連結有哪些？
本文資訊整理自 ggml-org/llama.cpp 的 GitHub 儲存庫、v0.7.0 版本發布說明與伺服器文件，涵蓋版本亮點、API 變更、新模型支援與授權條件。
- GitHub 儲存庫：https://github.com/ggml-org/llama.cpp
- v0.7.0 發布說明：https://github.com/ggml-org/llama.cpp/releases/tag/v0.7.0
- 伺服器文件：https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md
- 建置指南：https://github.com/ggml-org/llama.cpp/blob/master/docs/build.md
- nightly 建置：https://github.com/ggml-org/llama.cpp/releases
- MIT 授權條款：https://github.com/ggml-org/llama.cpp/blob/master/LICENSE
總結：llama.cpp 適合什麼團隊？
llama.cpp 適合需要在多種硬體上執行本地模型的團隊；v0.7.0 的專家快取降低記憶體門檻，連接埠變更需先檢查部署設定。
這一版的核心價值在於把記憶體限制轉化為可調參數。過去執行大型混合專家模型往往需要把整套權重塞進顯示記憶體，現在可以讓專家留在主機端、只快取常用部分，等於用一個啟動參數換取硬體門檻的下降。
生態層面的意義同樣明顯。十多款新架構在同一個版本內完成轉換、分詞與對話模板支援，代表這個引擎仍是模型發布者優先適配的目標之一。對想即時試用新模型的研究者與開發者而言，這種支援速度本身就是採用理由。
現實條件仍須衡量。硬體後端眾多意味著效能高度依賴平台與編譯選項，團隊需要具備相應的調校能力；nightly 與穩定版並行的節奏，也要求專案建立版本控管與迴歸測試流程。MIT 授權讓整合路徑相對單純，但商業部署前仍應確認預編譯執行檔的授權組合。是否採用，最終取決於團隊在硬體廣度、部署成本與維運投入之間的取捨。
