推論系統
llama.cpp 主線納入 Maple 20B‑A1B 三值 MoE，首階段以 CPU 支援為基準
9 月 14 日合併的架構支援，讓 Maple‑Preview 不再依賴 DeepGrove 的 llama.cpp 分支即可載入與轉換。模型每個 token 只啟用約 10 億參數，但 GPU 後端、品質評測與官方速度宣稱仍需分開驗證。
llama.cpp 於 9 月 14 日合併 Maple‑Preview 支援，新增 GGUF 常數、Hugging Face 轉換器、模型架構註冊與測試項目。Maple 是一個 20B‑A1B 推理模型：共有 24 層、256 個專家，每層選用 8 個，並以三層 512-token 滑動視窗注意力搭配一層全域注意力。主要權重原生採 `{-1, 0, +1}` 三值表示，再由 TQ1_0 或 TQ2_0 以不同封裝方式儲存，而不是把一般 BF16 模型事後壓成極低位元。
這次合併的實際價值是部署相容性。官方約 5.31 GB 的 checkpoint 現可沿用 llama.cpp 的轉換、伺服器及周邊工具鏈，不必固定在廠商 fork；PR 的架構測試得到 `NMSE 8.75e-08`，作者也在 Apple M4 CPU 上量到約 216 token/s prefill、88 token/s generation。這與模型卡宣稱的 218 token/s 不可直接比較，後者使用另一套 Apple Silicon runtime，測試條件與生成階段也未完全對齊。
審查過程還揭露值得追蹤的數值問題。TQ1_0 與 TQ2_0 在相同輸出頭下理應保存同一組三值權重，但不同量化運算與 CPU／CUDA 後端曾產生顯著 perplexity 差距；將輸出頭改成 Q4_K 也帶來小幅品質損失。合併內容以 CPU 架構路徑為基準，不能據此推定 CUDA、Metal 或 Vulkan 已具有同等速度與正確性。PR 亦揭露部分程式由代理生成、再經人工審查與測試。工程團隊下一步應等待正式建置，並在自己的上下文長度、後端與任務資料上同時驗證速度、記憶體和品質。