llama.cpp 專案合併了由 am17an 提交的 Pull Request #29887，該功能為存放在主機記憶體（Host Memory）中的 Mixture-of-Experts (MoE) 專家引入了 GPU 快取機制。原始來源指出，此功能可能為那些無法完全放入 VRAM 的 MoE 模型帶來顯著的加速效果。該 PR 已透過後續的 PR #30112 正式合併。
社群用戶提供了具體的測試數據以展示效能變化。用戶 Amazing_Athlete_2265 在 RTX 3080 10GB 顯卡上測試 Qwen3.6-35B-A3B 模型，初始測試顯示生成速度從約 35t/s 提升至 40t/s；隨後該用戶補充說明，在使用 `-cmoe` 和 `--moe-cache-mib` 參數後，生成速度達到 47t/s，預填充（prefill）速度從 350t/s 提升至 500t/s。
然而，用戶 CUvinny 在 RX 9070 XT 顯卡上使用 Vulkan 後端測試 Gemma4 26BA4 QAT 模型時，報告了不同的結果與權衡關係。數據顯示，隨著 `moe-cache-mib` 參數值的增加，解碼（decode）速度在某些設定下有所提升（例如從無快取的 59.3tps 提升至 8000 設定下的 76.9tps），但預填充（prompt processing）速度則顯著下降（從 869.7tps 降至 409.3tps）。該用戶指出，在其測試環境中，雖然足夠大的快取能提升生成速度，但預填充速度的下降幅度超過了生成速度的提升幅度。
事件背景
Mixture-of-Experts (MoE) 模型結構通常包含多個專家網路，為了在硬體資源受限的環境下運行，llama.cpp 等推理引擎可能會將部分專家權重存放在主機記憶體而非 GPU 顯存（VRAM）中。此 PR 引入的 GPU 快取機制旨在優化這種配置下的存取效率。原始來源僅簡述此功能針對「無法完全放入 VRAM 的 MoE 模型」提供潛在加速，並未詳細說明底層技術實作細節或 MoE 模型的具體運作原理。
社群觀察
社群討論呈現兩極化。一方面，許多用戶慶祝此功能對「顯卡貧困」（GPU Poor）用戶的幫助，用戶 pmttyji 稱之為「夢想成真」，用戶 msalsas 則表示其 16GB 顯卡因此受益。另一方面，用戶 karmaisnonsense 對合併過程提出批評，指出社群曾花費數月時間討論並嘗試將類似功能上游化，但開發團隊忽略了這些努力，反而在 5 天內合併了來自供應商分支（vendor fork）的實作，且 am17an 表示未尋求協助並認為其版本可合併。
此外，用戶 CUvinny 的測試數據揭示了該功能在不同硬體與模型組合下的複雜表現，特別是在預填充與解碼速度之間存在明顯的權衡，這與部分用戶報告的單純加速效果形成對比，顯示該功能的效能增益高度依賴具體的硬體配置與參數設定。
