Ollama vs llama.cpp：你選的不只是工具，是你願意承擔多少維護成本
HN 最近一篇文章把 Ollama 罵得很慘——504 points、142 則留言，熱鬧得很。理由包括：attribution 問題、後端分叉爭議、效能損耗、model naming 一塌糊塗。評論區當然也有人反撲，說一鍵啟動就是它的價值，不必每次都自己編譯。
這個討論本身沒什麼問題。問題是大部分人都在選邊站，而不是問正確的問題：你的 local LLM 堆疊六個月後還能跑嗎？
我帶 backend team 十幾年，最怕的不是選錯工具，是選了一個「進得去、出不來」的工具。local LLM 這塊現在正是這個狀態。
先說清楚這兩個東西在做什麼
Ollama 是個封裝層。它包了 llama.cpp，加上 REST API、model registry、自動量化處理，然後給你一個 ollama run llama3 就跑起來的體驗。對它的批評很多集中在它把 llama.cpp 的 fork 搞得很深、upstream sync 慢、效能有損耗。
llama.cpp 是底層。C++ 寫的，目標是在各種硬體上跑量化模型。你直接跑 binary 或自己包一層 server，控制權最大，但所有事情都要自己處理。
這不是技術好壞的問題。這是抽象層的選擇。你選哪個，決定的是你未來六個月要花多少時間在維護上，以及你踩坑的時候能不能找到根因。
我自己踩過的坑，不是理論
我們去年有個 side project，把本地模型接進內部工具做 code review 輔助。一開始選 Ollama，理由很實際：快速 prototype，讓其他人直接用，不要花太多時間在 infra 上。
第一個月很順。ollama serve 跑起來，REST API 接好，pipeline 完成。
第三個月開始出問題。
具體的問題有幾個：
1. Model naming 不透明
llama3:8b 在 Ollama registry 上是什麼量化？Q4_K_M？Q5_K_M？你要進去翻 Modelfile 才知道。我們有一次換了一個同名但實際上不同量化的版本，輸出品質掉了一截，追了快兩天才定位到是這個問題。
2. llama.cpp 的效能差距在壓力下放大
Ollama 對 llama.cpp 的封裝有 overhead。平常跑單一 request 感覺不明顯，一旦 concurrent request 上來，gap 會擴大。社群測得的區間從 30% 到接近 1.8x 都有，取決於你的硬體和 workload 類型。我們的場景是多人同時觸發，這個 overhead 非常有感。
3. 版本升級的不確定性
每次 Ollama 版本升，底下 llama.cpp 的版本也跟著動，但你不一定知道具體 diff 是什麼。有一次升完之後某個模型的 context window 行為變了，我們花了幾個小時才確認是 Ollama 升版帶進來的問題。
後來我們把核心 inference 改到 llama.cpp server（llama-server），Ollama 只留著給 team 裡非工程師用的測試場景。這個決策省了我們後續大量的排查時間。
「封裝便利 vs 技術透明」不是二元選擇，是個連續光譜
很多人把這個討論框成「要方便還是要控制」，這是錯的框架。正確的問法是：你需要在哪個層面有透明度？
有幾個維度可以分開看：
量化格式的透明度
llama.cpp 的 GGUF 格式你可以直接看 metadata：llama-quantize --info model.gguf 就知道是什麼量化、原始模型資訊。Ollama 把這個藏起來了，你要繞一圈才能看到。
如果你的應用對輸出品質敏感（法律文件摘要、財務分析），你必須知道你在跑什麼量化。Q4_K_M 和 Q5_K_M 在複雜推理上差距在某些 benchmark 場景社群測得可達 70% 以上（錯誤率的相對差，不是絕對值），這不是小事。
效能 profiling 的透明度
llama.cpp 的 log 很直白：tokens/s、每一層的時間、KV cache 使用率。Ollama 你能看到的東西少很多，debug latency 問題的時候非常不方便。
backend 參數的控制
llama.cpp server 你可以直接調 --n-gpu-layers、--ctx-size、--rope-scaling，這些參數會直接影響效能和記憶體用量。Ollama 透過 Modelfile 只暴露了部分參數，有些細節你就是動不了。
什麼情況下 Ollama 是對的選擇
我不想寫成「Ollama 很爛，大家都去用 llama.cpp」，那跟 HN 上的討論一樣流於情緒。
Ollama 適合：
- 你的 team 裡有非技術人員需要自己跑模型測試
- Prototype 階段，你不想花兩天設定環境
- 你的 workload 是低頻、單 user 的場景
- 你用的模型都在 Ollama registry 上，model naming 不是問題
llama.cpp 適合：
- 你需要確切知道跑的是什麼量化
- 你的 workload 有 concurrent request 壓力
- 你需要 profiling 和細粒度的 debug
- 你打算把這個跑在 CI/CD 裡或當成服務長期維護
- 你的模型不在標準 registry 上（自訓、微調過的）
第三個選項是兩個都跑。測試和 ad-hoc 場景用 Ollama，production pipeline 用 llama.cpp server。多一個服務要維護，但職責清楚。
真正的可維護性問題：六個月後你還記得為什麼這樣設定嗎？
我對「可維護性」的定義很明確：六個月後，新人進來，能不能在不問你的情況下搞清楚這個系統在跑什麼、為什麼這樣跑？
Ollama 的問題是它把太多細節藏進 registry 和 Modelfile，你要花額外工夫去把這些記錄下來，不然三個月後你自己也忘了你跑的是什麼。
llama.cpp 的問題是啟動指令一長，沒文件的話，一串 flags 看了也不知道在幹嘛。
兩個都需要你主動建立文件和 infrastructure-as-code 習慣。差別是 llama.cpp 的「秘密」都在表面，你想藏也藏不了；Ollama 的「秘密」在 abstraction 層底下，你不去挖就不會知道。
從這個角度看，Ollama 的便利性是有代價的——它讓你前三個月很舒服，但它同時在把技術債往後推。
一個我實際在用的評估框架
選 local LLM 堆疊之前，我會問自己四個問題：
- 這個服務需要跑多久？ 一週的 POC 和要跑兩年的 internal tool，答案完全不同。
- 誰來維護？ 只有我自己還是整個 team？他們的技術背景是什麼？
- 出了問題，我能找到根因嗎？ 如果 latency 突然變高，我有辦法從 log 定位到底是哪個層出的問題？
- 下次需要換模型的時候，換得動嗎？ 不要把自己鎖在某個 registry 的命名規則裡。
前兩個問題決定你要多少便利；後兩個問題決定你需要多少透明度。大部分人只想清楚了前兩個。
說白了，這個討論不是 Ollama 好不好的問題。是你有沒有想清楚你在用的是什麼，以及為什麼。HN 上吵得很熱，但吵架不會讓你的 production 跑得更穩。先把你的使用場景定義清楚，工具自然就選出來了。
作者：鍵盤工人