Ollama 與 llama.cpp：VPS 該選哪一個？

Ollama 與 llama.cpp：你想執行哪一層？

Ollama 與 llama.cpp 並不是問題所暗示的競爭關係。llama.cpp 是推論引擎，會載入模型檔案，並將提示轉換為 tokens。Ollama 則是建構在該引擎之上的模型管理器、背景 daemon 與 HTTP API。Ollama 的 README 目前仍將 llama.cpp 列為其推論後端（檢查日期為 2 August 2026）。因此，真正的問題是你想在 VPS 上操作哪一層，而不是哪一個速度較快。

如果你需要依名稱取得模型，並讓服務在無需人工介入的情況下持續運作，請使用 Ollama。如果 VPS 資源有限，而你需要指定確切的模型檔案、context size 與 thread count，請直接執行 llama.cpp。因為在小型 VPS 上，這些設定中的每一項都會耗用你無法提供的記憶體。

各專案實際上是什麼

llama.cpp 是以 ggml library 為基礎，用 C 和 C++ 實作 transformer 推論的專案。它會讀取 GGUF 檔案。GGUF（GGML universal file format）是單一檔案容器，內含引擎執行模型所需的權重、tokeniser 與中繼資料。此專案會針對不同工作提供個別的 binary。llama-server 是 HTTP server，llama-cli 是互動式 prompt，llama-bench 會測量 throughput。Release 會以 build number 標記，而不是採用 semantic version。目前的 tag 是 b10224，發布於 2 August 2026；幾乎每個工作日都會發布新的 tag。

Ollama 是以 Go 撰寫的程式。使用 ollama serve 啟動的 background daemon 會載入模型並處理 HTTP request，而 command line client 會與該 daemon 通訊。兩者背後都使用位於 ollama.com 的 registry，其中存放預先封裝的模型。Ollama 使用 semantic version，v0.32.5 於 27 July 2026 發布。ollama pull 會連同 prompt template 和一組預設參數擷取 GGUF，然後在 Linux 上將其儲存於 /usr/share/ollama/.ollama/models。

這種封裝方式就是兩者的全部差異。Ollama 會替你決定 quantisation、template 和 context length，並提供一個需要記住的名稱。llama.cpp 不會替你做任何決定，只提供 flags。

模型與量化控制

量化會將每個權重從 16 或 32 位元縮減至 4、5 或 8 位元。這使得 8 billion parameter model 能載入一般 VPS 的 RAM。了解命名規則後，GGUF 名稱很容易判讀：Q4_K_M 代表 4-bit K-quant，medium size。數字越高，保留的精度越多，所需記憶體也越大。

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

這些是 bartowski/Meta-Llama-3.1-8B-Instruct-GGUF repository 在 Hugging Face 上發布的檔案大小，資料讀取日期為 2 August 2026，並已從 bytes 轉換為 GiB。同一個 model 有 6 個 builds，最小檔案為 2.96 GiB，最大檔案則為 7.95 GiB。常見的預設選項 Q4_K_M 為 4.58 GiB。在 4 GiB VPS 上，這個選擇會直接決定 model 是否能載入。

使用 llama.cpp 時，必須指定檔案，因此要自行選取對應的列。

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c 是以 tokens 計算的 context size，-t 是 thread count，而 -ngl 用來設定要移至 GPU 的 layers；僅使用 CPU 的主機則設為 0。系統不會替你猜測這些設定。

使用 Ollama 時，quantisation 會隨著所拉取的 tag 一起套用，而 ollama ls 會顯示磁碟上實際存在的內容。如果 registry 沒有你需要的 build，請自行匯入 GGUF。建立一個 Modelfile：

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

接著建立並檢查結果：

ollama create llama31-q4 -f ./Modelfile
ollama ls

Context length 是最容易造成問題的設定。Ollama 會根據可用的 VRAM 選擇預設值，而沒有 GPU 的主機會落入最小區間：4096 tokens。若傳送一份 20,000 tokens 的文件，超出的 tokens 會在 model 讀取前遭到捨棄，因此 model 只讀到部分內容，卻可能對檔案產生看似確定但實際錯誤的回答。使用 OLLAMA_CONTEXT_LENGTH 在 daemon 上提高此值，或在 Modelfile 中使用 PARAMETER num_ctx 設定。llama.cpp 也沒有值得信任的預設值。請明確設定 -c，並確認實際設定內容。

你不會看到的記憶體計算方式

模型檔案不是全部成本。KV cache（key/value cache）會為每個 context token 在每個 layer 儲存一筆資料，並隨著對話內容增加而成長。

以 Llama 3.1 8B 為例。模型有 32 個 layer、8 個 key/value head，以及 128 的 head dimension。每個 token 會以 f16 儲存一個 key 和一個 value，每個值占 2 bytes，因此 2 x 8 x 128 x 2 = 4096 bytes per layer。32 個 layer 合計為每個 token 128 KiB。4096 token 的 context 需要 512 MiB，而 32,768 token 的 context 需要 4 GiB。

因此，Q4_K_M 8B 模型在 4k context 下，需要約 4.58 GiB 的 weights，另加約 0.5 GiB 的 cache，以及 runtime 本身所需的記憶體。它無法裝入 4 GiB RAM。在 8 GiB RAM 中可以執行，並保留工作所需的空間。若在同一台 8 GiB 的主機上將 context 提高到 32k，光是 cache 就會耗盡可用餘裕。模型載入時，使用 free -h 即時監看記憶體用量，不要相信未經實測的估算。

Ollama 會進一步放大這項需求。OLLAMA_NUM_PARALLEL 的預設值為 1，模型所需的記憶體會隨該數值乘上 context length 成比例增加。若同時提高這兩項設定，daemon 會在沒有明顯提示的情況下要求數倍於預期的 RAM。

軸線 2：你必須操作的 daemon

Ollama 安裝指令碼會寫入 systemd unit、建立 ollama system user，並啟用服務。無須自行撰寫這些設定，即可管理服務生命週期。設定透過 systemd 進行：

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE在 CPU VPS 上的重要性高於其他環境。模型預設會保留在記憶體中 5 分鐘，之後卸載。下一個請求必須先從磁碟重新讀取整個檔案，才能產生回應。因此，在慢速儲存裝置上，重新載入 4.58 GiB 檔案，會讓原本 2 秒的回應變成 30 秒。設定較長的 keep-alive 可以降低延遲，但會持續占用 RAM。兩者都是真實成本。請選擇影響較小的方案。

llama.cpp 不提供 daemon，因此必須自行撰寫 unit，內容如下 /etc/systemd/system/llama-server.service：

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

使用 sudo systemctl enable --now llama-server 啟用。程序在整個生命週期中都會保留模型。閒置時不會卸載，因此不會突然重新載入，但除非停止服務，否則也無法回收記憶體。若你不熟悉撰寫 unit，這與在 VPS 上使用 systemd 執行自有服務是相同模式。

軸 3：應用程式要使用的 API

這個軸面的差異已大幅縮小。目前兩個專案都支援 OpenAI chat 格式，因此大多數用戶端程式庫只要修改 base URL，就能連接其中任一個專案。

Ollama 監聽 127.0.0.1:11434。它的 OpenAI 相容路徑是 http://localhost:11434/v1/chat/completions，同時也在 /api/chat 提供原生 API。此外，Ollama 也有文件說明 Anthropic 相容路徑。

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server 監聽 127.0.0.1:8080，並提供 /v1/chat/completions、/v1/completions 和 /v1/embeddings，以及專用的 /completion endpoint 和內建 web UI。它也提供 Ollama 沒有的運作狀態路徑：/health 用於 readiness probe、/props 用於查看已載入模型的設定、/slots 用於查看每個請求 slot 的處理狀態，以及以 Prometheus 格式提供的 /metrics。如果你計畫監控這項服務，這項差異很可能會成為決定因素。

兩個伺服器都不會自動替你啟用驗證。基於安全考量，兩者預設都只繫結 loopback。請透過 SSH tunnel，或從 reverse proxy 後方存取它們，絕不要將 11434 或 8080 開放到網際網路。

CPU-only VPS 實際能做到的事

CPU-only VPS 只能緩慢執行小型模型。這是最簡短且實際的結論，重點在於了解可用範圍。先完成測量，再據此設計：

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

pp 欄是提示處理速度，tg 欄是 token 生成速度，單位都是每秒 token。在共用 vCPU 方案上，8B 模型搭配 Q4_K_M 通常只能達到個位數的 tg。提示處理是主要瓶頸：系統必須先處理完整提示，才會產生第一個輸出 token，因此較長的 system prompt 會讓每次請求都增加等待時間。

CPU 適合的用途：使用 1B 至 4B 模型進行分類、資料擷取、短摘要或路由。回應會在幾秒內出現，記憶體需求也符合一般方案。CPU 不適合的用途：以閱讀速度進行互動式聊天、程式碼助理、長文件處理，或任何由 agent loop 依序發出多次請求的工作。若迴圈以每次 4 秒的速度發出 12 次請求，產生任何結果前就需要 1 分鐘。

當效能數據不符需求時，有兩種解決方向。如果問題是並行處理，也就是許多使用者同時使用同一個模型，應改變推論引擎；Ollama 與 vLLM 的並行服務比較涵蓋這個主題。如果問題是原始速度，答案是配備 GPU 的 VPS，此時 -ngl 才具有實際意義。在採用上述任一方案前，先取得硬體本身的基準數據，因為磁碟與記憶體頻寬和 CPU 一樣，都會影響載入時間。可重複執行的 VPS 基準測試值得花 1 小時完成。

安裝 llama.cpp，固定至特定建置版本

這兩個專案每週都會更新，因此請記錄已部署的版本。上游提供的一行指令會安裝目前的建置版本：

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

若要固定特定建置版本，請改用 releases 頁面的預先建置 tarball。b10224 是截至 2 August 2026 的目前標籤：

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

或者，直接從原始碼建置相同的標籤：

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev 是 HTTPS 功能的文件指定相依套件。編譯需要幾分鐘，且所需 RAM 超過最小方案的容量。因此，請在較大型的主機上建置；如果小型主機容量不足，再將二進位檔複製過去。

安裝 Ollama 並固定版本

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

此腳本會讀取 OLLAMA_VERSION，因此您可以固定使用已知穩定的版本，而不是直接採用今天早上發布的版本。v0.32.5 於 27 July 2026 發布。如果不希望將腳本透過管線傳給 shell，也可以採用手動方式：

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

手動方式不會建立 systemd unit 或服務使用者，因此必須自行新增。完整的 VPS 上 Ollama 操作指南會逐步說明服務設定流程。

失敗模式與您會看到的字串

Ollama 拒絕載入模型。 ollama run 會回傳如下格式的一行：

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama 會在載入前檢查大小，因此會快速失敗並說明原因。往下選一列 quantisation、降低 context length，或改用較小的模型。

llama.cpp 沒有失敗，而是執行速度極慢。 llama.cpp 預設會使用 memory-map 載入 GGUF，因此即使檔案大於 RAM，仍會開始執行。接著，kernel 會在每個 token 產生時，持續從磁碟分頁載入及移出 weights，導致每個 token 需要數秒，且磁碟使用率固定在 100%。傳入 --no-mmap 強制進行實際配置，讓它立即失敗，而不是效能逐步下降。當 kernel 介入時，dmesg 會顯示原因：

Out of memory: Killed process 1234 (llama-server)

模型檔案完全無法載入。 如果 GGUF 是為比您的 engine 更新的 model family 建置，錯誤訊息會列出它不認識的 architecture：

error loading model architecture: unknown model architecture: 'qwen3next'

解決方式是升級 engine，而不是更換檔案。這是 pinning 的代價，也是您必須記錄 build number 的原因。您需要知道目前是從哪個版本升級。

API 在本機回應，但您的應用程式無法連線。 Ollama 綁定在 127.0.0.1:11434，因此其他主機會收到 connection refused。只有在該埠位於防火牆或私有網路後方時，才應透過 systemctl edit ollama 設定 OLLAMA_HOST=0.0.0.0:11434，因為 API 前方沒有 authentication。

暫停後收到的第一個回覆非常慢。 5 minute idle unload 已經發生，模型必須再次從磁碟讀取。在請求前立即執行 ollama ps，若顯示沒有已載入的內容，即可確認此情況。提高 OLLAMA_KEEP_ALIVE。

因此，您應該執行哪一個？

如果您希望由系統代為管理模型，並在不需額外設定的情況下提供符合 OpenAI 介面的端點，請執行 Ollama。這是首次部署時的預設選擇，也適合模型選擇會持續變動的情境。

如果記憶體限制嚴格到必須自行選擇量化列，或需要使用 /health、/slots 和 /metrics 進行監控，或者需要使用 Ollama 未提供的旗標，請直接執行 llama.cpp。對於模型勉強才能容納的 VPS，這是較實際的選擇，因為讓模型能夠運作的設定，正是 Ollama 會代您選擇的設定。

同時執行兩者很正常。Ollama 用於實驗，llama.cpp 則用於正式環境中那個部署後不希望再變動的模型。

FAQ

Ollama 只是 llama.cpp 的包裝程式嗎？

接近，但這個包裝層實際上負責許多工作。Ollama 的 README 將 llama.cpp 列為其推論後端（截至 2026 年 8 月 2 日）。Ollama 在此之上加入模型登錄庫、將聊天訊息轉換為提示的提示範本、一組預設取樣參數、具備閒置卸載功能的 daemon，以及 HTTP API。在相同設定下比較每秒 token 數時，實際上是在比較同一個引擎本身。真正需要選擇的是管理層。

僅使用 CPU 的 VPS 上，哪一個比較快？

兩者共用同一個引擎，因此在模型檔案、量化方式、context 大小與執行緒數相同的情況下，效能通常相近。人們回報的差異通常來自不同的預設值，最常見的是 context 長度與執行緒數，而不是引擎本身。在相信任何已發布的數據前，先使用 llama-bench -m <file> -p 512 -n 128 測量，並在自己的主機上比較 tg 欄位。

我可以在 Ollama 中使用自己的 GGUF 檔案嗎？

可以。將檔案放在伺服器上，建立一個 Modelfile，其第一行為 FROM ./your-model.gguf，再加入所需的 PARAMETER 行，例如 num_ctx，然後執行 ollama create your-name -f ./Modelfile。ollama ls 會將它與從登錄庫提取的其他模型一併列出。若登錄庫沒有提供所需的量化版本，可以透過這種方式使用。

8B 模型需要多少 RAM？

請將檔案大小、KV cache 與執行環境所需記憶體一併納入估算。Llama 3.1 8B 的 Q4_K_M 建置版本在磁碟上約為 4.58 GiB，而 4096 token 的 context 約需額外 512 MiB 的 cache，因此 8 GiB RAM 足夠，4 GiB 則不足。cache 會隨 context 增加：相同模型在 32,768 token 的 context 下，單是 cache 就約需 4 GiB。使用 Ollama 時，請記住需求也會隨 OLLAMA_NUM_PARALLEL 增加。