CPU VPS 該用 Ollama 還是 llama.cpp？

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

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

如果你需要依名稱取得模型，並讓服務在無人介入時持續運作，請執行 Ollama。如果 VPS 資源有限，而你需要選擇確切的模型檔案、確切的 context size 與確切的 thread count，請直接執行 llama.cpp，因為在小型 VPS 上，這些設定都會消耗你所沒有的記憶體。

實際上各個專案是什麼

llama.cpp 是以 C 和 C++ 實作的 Transformer 推論引擎，建置於 ggml 程式庫之上。它會讀取 GGUF 檔案。GGUF（GGML universal file format）是單一檔案容器，內含引擎執行模型所需的權重、tokenizer 與中繼資料。此專案針對不同工作提供個別的二進位檔。llama-server 是 HTTP 伺服器，llama-cli 是互動式提示介面，而 llama-bench 用於測量輸送量。版本發布會以建置編號標記，而不是使用語意化版本。當前標記為 b10224，發布於 2 August 2026，且大多數工作日都會發布新的標記。

Ollama 是以 Go 撰寫的程式。由 ollama serve 啟動的背景 daemon 會載入模型並回應 HTTP 請求，命令列用戶端則與該 daemon 通訊。兩者背後都有位於 ollama.com 的 registry，其中存放預先封裝的模型。Ollama 使用語意化版本，v0.32.5 於 27 July 2026 發布。ollama pull 會連同 prompt template 和一組預設參數擷取 GGUF，然後在 Linux 上將其儲存於 /usr/share/ollama/.ollama/models。這些檔案位於 root 磁碟，且每個檔案可能佔用數 GB。因此，在 root volume 為 25 GB 的 VPS 上，第三次下載前先了解 pull 會留下哪些檔案，以及如何將模型目錄移到其他位置，以免磁碟空間耗盡。

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

軸 1：模型與量化控制

量化會將每個權重從 16 或 32 位元縮減為 4、5 或 8 位元。這讓 80 億參數的模型能裝入一般 VPS 的 RAM。了解命名規則後，GGUF 的名稱就很容易讀懂：Q4_K_M 表示 4 位元 K-quant，大小為 medium。數字越高，保留的精度越多，所需的記憶體也越多。

[
  {
    "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 Hugging Face repository 中發布的檔案大小，資料讀取於 2 August 2026，並從 bytes 轉換為 GiB。同一個模型共有 6 個版本，最小檔案為 2.96 GiB，最大檔案則為 7.95 GiB。常見的預設版本 Q4_K_M 為 4.58 GiB。在 4 GiB VPS 上，這個選擇會直接決定模型能否載入。檔案大小只是決策的一半，因為負擔得起的版本不一定值得使用，而 Q4、Q8 與 fp16 實際會如何影響回答品質 才能告訴你，多出的 GB 是否能換來可察覺的改善。

使用 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 是以 token 計算的 context size，-t 是執行緒數量，-ngl 則設定要移至 GPU 的 layer 數量（僅使用 CPU 的主機設為 0）。系統不會替你猜測任何設定。

使用 Ollama 時，量化版本會隨著你拉取的 tag 一起指定，而 ollama ls 可顯示磁碟上實際擁有的內容。當 registry 沒有你需要的版本時，可以自行匯入 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 token 的文件，多出的 token 會在模型看到文件前就被捨棄，因此模型只讀到一半，卻會對檔案產生看似確定但錯誤的回答。你可以在 daemon 上使用 OLLAMA_CONTEXT_LENGTH 提高此值，或在 Modelfile 中使用 PARAMETER num_ctx。如果只有一個工作需要較大的 context window，也可以 將 num_ctx 設定在單一請求上，而不是套用至整個伺服器，讓多出的 cache 不會影響 daemon 執行的其他工作。llama.cpp 也沒有值得信任的預設值。明確設定 -c，並確認實際設定的值。

記憶體計算：沒有人告訴你的部分

模型檔案不是全部成本。KV cache（key/value cache）會為每一層及內容中的每個 token 保存一筆資料，並隨著對話增長。

以 Llama 3.1 8B 為例。模型有 32 層、8 個 key/value head，以及 128 的 head dimension。f16 中每個 token 的 key 和 value 各占 2 bytes，因此每層的計算為 2 x 8 x 128 x 2 = 4096 bytes。32 層合計為每個 token 128 KiB。因此，4096 token 的 context 需要 512 MiB，32,768 token 的 context 則需要 4 GiB。

因此，Q4_K_M 8B 模型在 4k context 下，需要約 4.58 GiB 的權重空間，另加約 0.5 GiB 的 cache，以及 runtime 本身的記憶體。它無法放入 4 GiB RAM。使用 8 GiB 時則有足夠的工作空間。若在同一台 8 GiB 主機上將 context 提高到 32k，光是 cache 就會耗盡可用餘裕。模型載入期間，使用 free -h 即時監看記憶體用量，不要相信未經測量的估算。如果要為遠超過 8B 的模型配置資源，僅使用 CPU 的 VPS 上執行 27B 模型中的相同計算，可說明 8 到 64 GB 各個層級實際能容納的內容。

Ollama 會進一步放大這個需求。OLLAMA_NUM_PARALLEL 的預設值為 1，模型所需的記憶體會隨該數值乘以 context length 的結果而增加。若同時提高這兩項設定，daemon 會悄悄要求數倍於預期的 RAM。同樣的計算也決定同時使用者數的上限，因為每個並行請求都需要自己的 KV cache 配額；這就是伺服器對一個人使用時運作正常，五個人同時使用卻停滯的原因。

軸 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。兩者都會產生成本。請選擇影響較小的方式。如果決定讓模型持續駐留，設定 keep_alive，讓模型在閒置期間及重新開機後持續保留只需幾行設定，也不必每次主機重新啟動時手動預熱模型。

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。文件也說明了 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 可查看每個 request slot 正在處理的工作，/metrics 則使用 Prometheus 格式。如果你計畫監控這項服務，這項差異可能就是決定因素。

兩台伺服器都不會替你啟用驗證。基於合理的安全考量，兩者預設都只繫結 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 會讓每個請求都增加等待時間。回覆長度是你實際能控制的成本因素；在每秒 3 個 token 的速度下，一個冗長產生 600 個 token 的模型會占用伺服器 3 分鐘，因此以 num_predict 限制輸出長度 是避免單次冗長回覆變成逾時的最低成本方法。

CPU 適用的用途：使用 1B 到 4B 模型進行分類、擷取、短摘要或路由。回覆會在數秒內出現，記憶體需求也符合一般方案。若要查看該尺寸的實際範例，而不是尺寸範圍，在 VPS 上下載並測量 Nemotron 3.5 Lightning 會提供確切的 tag、實際所需的 RAM，以及無 GPU 時能維持的速度。CPU 不適用的用途：需要接近閱讀速度的互動式聊天、程式碼助理、長文件處理，或包含多次連續呼叫的 agent 迴圈。若迴圈需要呼叫 12 次、每次 4 秒，產生任何內容前就要等 1 分鐘。如果原本的規劃是使用程式碼助理，讓 agent 使用自行託管的模型會說明小型本地模型真正適合哪些工作，以及哪些工作必須交由託管 API 處理。

當測試數據不符需求時，有兩種解決方向。如果問題是並行處理，也就是許多使用者同時使用同一個模型，應改變引擎選擇；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。2026 年 8 月 2 日當時，目前的標籤是 build b10224：

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 會在載入前檢查大小，因此能立即失敗並說明原因。往下選一列量化格式、降低 context length，或改用較小的模型。

llama.cpp 不會失敗，而是變得極慢。 llama.cpp 預設會使用 memory-map 載入 GGUF，因此即使檔案大於 RAM，仍會開始執行。接著，kernel 會在每個 token 產生期間持續從磁碟換入和換出權重，導致每個 token 需要數秒，且磁碟使用率固定在 100 percent。傳入 --no-mmap，強制進行實際配置，讓它立即失敗，而不是效能逐漸惡化。當 kernel 介入時，dmesg 會顯示原因：

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

模型檔案完全無法載入。 如果 GGUF 是為比你的 engine 更新的模型家族所建立，錯誤訊息會指出它不認識的 architecture：

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

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

API 可在本機回應，但你的應用程式無法連線。 Ollama 綁定 127.0.0.1:11434，因此其他主機會收到 connection refused。只有在該埠位於 firewall 或 private network 後方時，才透過 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 列為其推論後端（截至 2 August 2026）。Ollama 在其上加入模型登錄中心、將聊天訊息轉換為提示的提示範本、一組預設取樣參數、具備閒置卸載功能的 daemon，以及 HTTP API。在設定完全相同時比較每秒 token 數，實際上是在比較同一個引擎本身。真正需要選擇的是管理層。

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

兩者共用同一個引擎，因此使用相同的模型檔案、量化方式、內容大小與執行緒數時，效能會非常接近。人們回報的差異通常來自不同的預設值，最常見的是內容長度與執行緒數，而不是引擎本身。請使用 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 的內容會額外增加約 512 MiB 的 cache，因此 8 GiB 的 RAM 足夠，4 GiB 則不足。cache 會隨內容大小增加：相同模型使用 32,768 token 的內容時，單是 cache 就約需 4 GiB。使用 Ollama 時，請記住需求也會隨 OLLAMA_NUM_PARALLEL 增加。