llama.cpp 是本地 LLM 生態的底層推論引擎、2023 年由 ggerganov 釋出、後來成為 Ollama、LM Studio 等高層工具的內部 backend。它的核心承諾是「用純 C++ 寫一個高效能的 GGUF 模型推論器、跨平台、CPU/GPU/Apple Metal 都能跑」。

對寫 code 場景的多數讀者來說、Ollama 已涵蓋 llama.cpp 的直接使用情境。Ollama 已經把它包好、使用者看到的是 model tag 跟 CLI；llama.cpp 自己的編譯、量化、參數設定都被抽象掉。本章的目的是澄清網路上「llama.cpp 才是真本地、Ollama 是壓榨版」這類迷思、並給少數需要直接用 llama.cpp 的場景一條路。

本章目標

讀完本章後，你應該能：

1. 理解 llama.cpp 在三層架構中的位置。
2. 知道 Ollama 與 llama.cpp 的關係（包含 / 上游）。
3. 判斷自己什麼情境下需要直接用 llama.cpp、什麼情境不用。
4. 看懂 GGUF 格式與量化標籤（Q4_K_M、Q5_K_S 等）。
5. 對「llama.cpp 整合 Gemma 4 MTP」這類消息建立判讀反射。

llama.cpp 在哪一層

llama.cpp 同時跨三層架構的兩層：

1. 推論引擎（library、可被其他程式呼叫的程式碼集合）：核心 C++ library、把 GGUF 權重載入、跑 forward pass（神經網路把輸入算到最後一層產出 token 的單次計算）。Ollama、LM Studio、許多其他工具的 backend 就是這個 library。
2. CLI 工具與 server（llama-cli、llama-server）：附帶的命令列工具與 HTTP server、可以直接拿來用、但需要自己編譯與配置。

當你看到「我用 Ollama 跑 Gemma 4」，實際發生的事是：

1你的指令
2  ↓
3Ollama CLI / server（包裝層、模型管理）
4  ↓
5llama.cpp library（推論核心）
6  ↓
7Metal API（Apple Silicon GPU）
8  ↓
9Apple Silicon 硬體

所以「Ollama vs llama.cpp」不是兩個競爭品，是「上層包裝」跟「底層引擎」的關係。

Ollama 跟 llama.cpp 的關係

Ollama 是 llama.cpp 的下游 wrapper、但 fork 跟 upstream 不是即時同步的關係。Ollama 在自己的 repo 裡放一份 vendored（複製進來、跟隨 Ollama 自家發版節奏管理）的 llama.cpp source、加上他們自己的 patches（補丁修改）；新功能進入 Ollama 的順序通常是：

1. llama.cpp 上游加新功能或修 bug
2. Ollama 把該 commit cherry-pick（從另一個 branch 單獨挑出一個 commit 套用）進來
3. Ollama 發新版

但反過來也成立：Ollama 有時搶先在 fork 裡加上游還沒接受的功能，例如 Gemma 4 MTP 在 2026/5/7 的 Ollama v0.23.1 一鍵支援，當時 llama.cpp 上游的 Gemma 4 MTP 整合還是 feature request。

這個關係的啟示：

1. 「llama.cpp vs Ollama 誰先進」視功能而定：具體功能要實際對照 release notes、「上游 / 下游」直覺只是初步參考、未必符合實際版本狀態。
2. 判讀支援度看 release notes：主版本號只是命名、實際功能列表要看具體版本的 changelog。
3. 直接用 llama.cpp 跟靠近上游是兩件事：Ollama 的 patches 有時是「上游還沒接受、但已經實用的功能」。

什麼情境真的需要直接用 llama.cpp

絕大多數寫 code 場景，Ollama 完全夠用。直接用 llama.cpp 的合理情境只有少數：

寫 code 場景的讀者通常不命中以上任何一條。

安裝（如果你真要試）

從原始碼編譯：

1git clone https://github.com/ggerganov/llama.cpp.git
2cd llama.cpp
3make

或用 Homebrew（社群維護，版本可能稍舊）：

1brew install llama.cpp

裝完後常用命令：

1# CLI 對話
2llama-cli -m /path/to/model.gguf -p "Hello"
3
4# HTTP server
5llama-server -m /path/to/model.gguf --port 8080 --host 127.0.0.1

llama-server 啟動後在 localhost:8080 提供 OpenAI 相容 API：

1curl http://localhost:8080/v1/chat/completions \
2  -H "Content-Type: application/json" \
3  -d '{
4    "model": "any-name",
5    "messages": [{"role": "user", "content": "Hi"}],
6    "stream": false
7  }'

model 欄位 llama-server 忽略，因為它一次只 serve 一個模型（不像 Ollama 可以動態切換）。

--host 127.0.0.1 是 loopback 預設、只接受本機連線。改 0.0.0.0 會把伺服器暴露到整個 LAN、跟 Ollama 改 OLLAMA_HOST 同類別的決定；完整的綁定模式跟誤開放後果見 6.1 推論伺服器的綁定與暴露範圍。

GGUF 格式與量化標籤

量化標籤是看 GGUF 檔名選模型的唯一線索、影響「記憶體 / 品質 / 速度」三軸的取捨。GGUF（GGML Unified Format）是 llama.cpp 定義的模型權重格式、把模型權重、tokenizer、metadata 打包成單一檔案。Ollama 內部存的就是 GGUF。

常見量化標籤：

_K_M、_K_S 的 K 指 K-quants（更先進的量化方法）、M / S 指 mixed-medium / mixed-small（不同層用不同量化）。實務上選 Q4_K_M 或 Q5_K_M 是寫 code 場景的甜蜜點；極端記憶體緊張才往 Q3 走、但通常會發現換較小模型的 Q5 比強塞大模型的 Q3 好。

為何 coding 任務對 Q3 以下特別敏感：寫 code 的回應要在 token 層保持高精度（變數名拼字、API 呼叫格式、括號配對都不容錯）、低 bit 量化會放大 token 分布失真、體感是 hallucination 上升、編造的 API 變多、長 context 累積誤差更明顯。一般對話容忍幾個錯字、code 一個錯字就跑不過。所以同 24GB Mac 上 Q5 14B 通常比 Q3 31B 適合寫 code、雖然參數量名義上少了一半。

Gemma 4 MTP 在 llama.cpp 的狀態（2026/5）

2026 年 5 月時：

• speculative decoding 框架：llama.cpp 已有 --draft-model 參數，整體 speculative decoding 功能 beta 階段。
• Gemma 4 官方 drafter 整合：feature request 開著（GitHub issue 上有討論），但尚未合進主分支。
• Ollama 對應狀態：v0.23.1 已一鍵支援 gemma4:31b-coding-mtp-bf16。

這是少見的「Ollama 領先 llama.cpp 上游」情境，原因是 Ollama 團隊接到 Google 的合作後直接做 patch、不等上游 review 流程。

實務啟示：

1. 想用 Gemma 4 MTP，直接用 Ollama 是最快路徑。
2. 想在 llama.cpp 直接跑 Gemma 4 MTP，要自己編譯帶上 Ollama 的 patches，或等上游合進來。
3. 看到「llama.cpp 已整合 Gemma 4 MTP」的網路文章，先去 llama.cpp 的 PR 列表 確認時間點。

llama.cpp 對 Apple Silicon 的優化

llama.cpp 對 Apple Silicon 有針對性優化：

1. Metal backend：在 macOS 上自動啟用 Metal（Apple 的 GPU 加速 API）、把 GPU 算力吃滿。
2. NEON / AMX：CPU 上用 ARM 向量指令集（NEON 是基本 SIMD、AMX 是 Apple 的矩陣加速器）加速 dequantization（把量化權重還原為計算精度的過程）。
3. Unified Memory aware：不像 NVIDIA GPU 要透過 PCIe（連接 GPU 與系統其他元件的高速匯流排）把資料搬進 VRAM、Apple Silicon 直接共用記憶體、省下這趟搬移。

這些優化都「免費」，不用使用者特別設定。但跟 MLX 比，llama.cpp 用的是 Metal 而不是 MLX framework；兩者效能各有勝負，差距通常 10 ~ 30%，不是「天差地遠」。

陷阱是看到「MLX 比 llama.cpp 快 N 倍」這類說法時，要追問：

1. 哪個模型？
2. 哪個量化？
3. 哪台 Mac？
4. llama.cpp 哪個版本？
5. 量測腳本是什麼？

多數網路 benchmark 沒有完整變數控制，差距常被誇大。對寫 code 場景的使用者，這個差距不值得糾結。

直接用 llama.cpp 跟 Ollama 並存

如果你真的想試 llama.cpp，可以跟 Ollama 並存（port 不同）：

Continue.dev 可以同時連兩個：

 1{
 2  "models": [
 3    {
 4      "title": "Ollama default",
 5      "provider": "ollama",
 6      "model": "gemma4:31b-coding-mtp-bf16",
 7      "apiBase": "http://localhost:11434"
 8    },
 9    {
10      "title": "llama.cpp experimental",
11      "provider": "openai",
12      "model": "any",
13      "apiBase": "http://localhost:8080/v1",
14      "apiKey": "not-needed"
15    }
16  ]
17}

給多數讀者的建議

直接用 llama.cpp 的學習成本比 Ollama 高、換來的好處對寫 code 場景的使用者通常不命中需求。在「自己量化模型 / 跑特殊冷門模型 / 需要 llama.cpp 最新 commit」三個條件都不命中時、Ollama 是低成本的預設選擇。

把 llama.cpp 當成「Ollama 背後的引擎、值得知道存在、但不必直接面對」。這個定位足夠應付網路上 95% 的相關討論。

何時不適用本章 / 該往哪去

本章的「以 Ollama 為主、llama.cpp 作為底層理解」這個敘事在以下情境會失準、需要另外的路徑：

下一章

下一章：1.3 VS Code + Continue.dev 整合，把伺服器接到日常編輯器，這才是寫 code 的真正起點。