本機 AI 部署取捨：llama.cpp 為何適合進階 MoE 調校
本機語言模型用家若由 Ollama 轉用 llama.cpp，未必是為了追求更高 tokens per second。XDA Developers 作者 Abhinav Raj 的個人測試指出，在他使用的模型與硬件上，兩者預設表現相近；令他留下來的原因，是 llama.cpp 讓使用者直接控制模型各部分放在 GPU 還是系統記憶體，以及如何分配 context 和 server 資源。這對開始接觸 MoE 模型、但顯示卡記憶體不足以完整容納模型的用家尤其有參考價值。
不過，這組數字不能視為兩款工具的通用排名。測試只涉及一位作者、一張 RTX 4070 Ti Super、16GB GDDR6X 記憶體及指定模型；模型量化方式、儲存裝置、CPU、系統記憶體、prompt 長度和並行請求數量，都會改變結果。較可靠的結論是：當本機 AI 工作流由「下載後聊天」走到反覆測試不同 GGUF 模型時，部署工具提供多少可觀察、可重現的設定，會直接影響舊硬件或有限 VRAM 能否用得順手。
速度接近後，控制權成為分野
文章提到，Ollama 已透過 llama.cpp 執行作者常用的模型，因此兩者的推理速度差距已不像過往般明顯。在 32K context 下，作者以預設設定運行 Qwen3.6-35B-A3B，Ollama 錄得每秒 77.02 個 token，llama.cpp 則為每秒 74.75 個 token。單看這次結果，Ollama 還略快，亦說明只以 benchmark 一個數字選工具，未必能反映本機部署的實際體驗。
Ollama 的價值在於把下載、管理和對話流程包裝得較簡單，對首次嘗試本機模型、希望減少雲端訂閱依賴的用家頗有吸引力。相對地，llama.cpp 需要用家多理解模型檔、server 參數和硬件資源，但它把更多選項留給使用者。這個差異不一定令所有人受惠：若只固定運行少量模型，簡化流程往往更重要；若經常更換模型、調參或讓有限 VRAM 跑較大模型，額外控制就有實際用途。
MoE 改變「模型是否放得下」的判斷
這次比較的關鍵是 Qwen3.6-35B-A3B 屬於 mixture-of-experts（MoE）模型。作者表示，該模型檔約為 17.7GB，大於其顯示卡的 16GB VRAM；但在每一個 token 的運算中，350 億參數之中約只有 30 億會實際工作。換言之，模型的總大小仍會佔用儲存及記憶體資源，但每次生成文字時，並非所有專家層都同時參與計算。
作者的做法是把部分專家層卸載到系統 RAM，同時盡量把每個 token 都會用到的部分留在 GPU。llama.cpp 的 --n-cpu-moe 參數可指定有多少層的專家放在 CPU／系統記憶體；他亦把 server 的聊天 slot 由預設四個限為一個，將 context 預算集中給單一對話，從而騰出 VRAM 放入更多模型部分。這反映 MoE 的實際取捨：系統記憶體可補足 VRAM，但卸載多少、context 開多大及同時服務多少請求，彼此會爭用同一批資源。
| 測試設定 | context | 生成速度 |
|---|---|---|
| Ollama 預設 | 32K | 77.02 t/s |
| llama.cpp 預設 | 32K | 74.75 t/s |
llama.cpp，--n-cpu-moe 8 |
32K | 81.43 t/s |
在作者的單機條件下，把八層專家放入系統 RAM 後，llama.cpp 升至每秒 81.43 個 token。這不代表「多卸載必定更快」：分析上，若經常需要由系統記憶體取回資料，CPU、RAM 頻寬和其他程序負載都可能成為限制；若把聊天 slot 收窄至一個，亦意味不能以同一設定兼顧多個同時用戶。因此，這個案例較適合視為調校方向，而非可直接複製到所有 PC 的最佳數值。
context、快取與 benchmark 不應混為一談
文章另一個實用提醒，是首次載入模型造成的快取暖機效應。作者測試 Gemma 4 12B 時，第一次看到每秒 44.98 個 token，下一次以相同 prompt 重跑卻升至每秒 61.76 個 token，差幅達 37%。他的解釋是第一次仍在把權重載入 VRAM。若只抄錄首次結果，便可能錯判模型或硬件表現，尤其是檔案較大、載入時間較長的情況。
llama.cpp 的 llama-bench 會分開量度 prompt 處理和生成速度、每項重複五次並報告平均值。這種方法的意義不在於製造更漂亮的分數，而是把「模型讀取尚未完成」與「穩定生成時的吞吐量」分開。用家若要比較本機部署設定，至少應固定同一模型檔、context 長度、聊天 slot 數量及卸載策略，再記錄暖機後的多輪結果；否則即使數字有差距，也難以判斷是工具、硬件配置還是快取狀態所致。
context 亦不能只追求愈大愈好。本文案例把測試固定在 32K context，並透過減少 slot 釋放 VRAM，正好顯示較長對話記錄與模型常駐 GPU 之間的拉鋸。對單人長文整理或程式協作，用家可能寧可把資源留給較大 context；對短問答或追求反應速度的工作流，則可考慮較保守的 context。應先以實際 prompt 長度決定需求，再調整 GPU 卸載與 CPU MoE 層數，會比盲目追逐最高 t/s 更有意義。
模型檔管理同樣影響日常成本
除效能外，作者選擇 llama.cpp 亦因為它可直接指向硬碟任何位置的 GGUF 檔案，再由 llama-server 提供介面；不必先複製模型到指定位置。按照文章描述，Ollama 匯入本地模型時需要 Modelfile 和 ollama create 步驟，並會複製整個模型到自己的資料夾。作者在約三個模型的情況下，發現約有 41GB 重複檔案需要手動清理。
這項差異看似瑣碎，卻會影響經常下載和篩選模型的工作流。大型模型檔的副本不只佔儲存空間，亦令版本、量化檔和刪除流程較難追蹤；作者更提到曾因舊 Modelfile 意外拾取檔案，遇上「invalid model name」及「unexpected EOF」錯誤。另一方面，統一管理目錄亦可能令初學者少碰到路徑問題，故兩種設計各有取向，重點是用家是否經常自行處理模型檔。
對需要頻繁改動 top_k、top_p 等生成設定的人，作者認為 llama.cpp 的 WebUI 設定頁較方便；文章所述 Ollama 則要編輯 Modelfile、使用互動式 CLI 或提出 API 請求。這並非工具優劣的定論，而是介面設計如何配合使用頻率：每天多次調參的人會重視即時可見的控制項；主要使用固定 preset 的人，未必會從中獲得相同比例的好處。
接下來值得觀察的，是部署工具會否把 MoE 的記憶體配置、context 分配和可重現 benchmark 做成更易理解的選項。對擁有有限 VRAM、但可提供較多系統記憶體的本機 AI 用家而言，真正需要比較的已不只是某次生成速度，而是能否在自己的模型、對話長度和使用人數下，穩定地找出合適配置。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- XDA Developers — I moved my local models from Ollama to llama.cpp, and the reason I stayed has nothing to do with speed — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
