VPS 上該選 Ollama 還是 llama.cpp？

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

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

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

這些專案實際上是什麼

llama.cpp 是以 C 和 C++ 實作的 transformer 推論引擎，建置於 ggml 函式庫之上。它會讀取 GGUF 檔案。GGUF（GGML universal file format）是單一檔案容器，包含引擎執行模型所需的權重、tokeniser 和中繼資料。此專案會針對不同工作提供個別的二進位檔。llama-server 是 HTTP server，llama-cli 是互動式提示工具，llama-bench 則用於測量輸送量。此專案目前採用語意版本發布格式（MAJOR.MINOR.PATCH）；v0.7.0 於 15 October 2026 發布，且截至 27 October 2026 仍是最新版本。帶有 build 編號的 nightly tag 也會並行發布，每天可能有數個；截至 27 October 2026，最新版本是 b11913。

Ollama 是以 Go 撰寫的程式。背景 daemon 由 ollama serve 啟動，負責載入模型並處理 HTTP 請求；命令列 client 則與該 daemon 通訊。兩者背後都使用位於 ollama.com 的 registry，其中存放預先封裝的模型。Ollama 使用語意版本。v0.32.5 於 27 July 2026 發布，v0.40.12 則於 27 October 2026 00:07 UTC 發布。ollama pull 會取得 GGUF、prompt template 及一組預設參數，然後在 Linux 上將其儲存至 /usr/share/ollama/.ollama/models。這些檔案位於 root 磁碟上，每個檔案可能佔用數 GB；因此，在 root volume 為 25 GB 的 VPS 上，第三次下載可能將磁碟填滿。事先了解 pull 會留下哪些檔案，以及如何將模型目錄移到其他位置，會很有幫助。

這種封裝方式就是兩者的主要差異。Ollama 會替你決定 quantisation、template 和 context length，並提供一個需要記住的名稱。llama.cpp 則將這些選項公開為 flags；對於未設定的項目，會自動採用預設值。

軸 1：模型與量化控制

量化會以少於原始模型 16 或 32 位元的位元數儲存權重，而常見的 GGUF 建置版本平均每個權重約使用 4、5 或 8 位元。檔案中的精度並不一致。根據 llama.cpp 的量化器原始碼（讀取日期為 2026 年 10 月 27 日），Q4_K_M 建置版本會將大多數張量保持在 4 位元，但會將輸出層，以及約一半層中的注意力 value 和 feed-forward down 張量改用 6 位元的 Q6_K；norm 等小型張量則完全不量化。這就是 8 billion 參數模型能放入一般 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
  }
]

這些是 Hugging Face 上 bartowski/Meta-Llama-3.1-8B-Instruct-GGUF repository 公開的檔案大小，讀取日期為 2026 年 8 月 2 日，並已從 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 是以 tokens 表示的 context size，-t 是 thread count，而 -ngl 設定要移至 GPU 的 layer 數量（僅使用 CPU 的主機設為 0）。未設定的選項會使用預設值，而 --fit 預設啟用，會調整未設定的參數以符合裝置記憶體。

使用 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 的文件時，多出的 tokens 會在模型讀取前遭到捨棄，因此模型只讀到部分檔案，卻仍可能產生看似確定的錯誤回答。可在 daemon 上使用 OLLAMA_CONTEXT_LENGTH 提高此值，或在 Modelfile 中使用 PARAMETER num_ctx。如果只有一個工作需要較大的 context window，可以針對每個 request 設定 num_ctx，而不必套用到整個 server，如此可避免 daemon 執行其他工作時也保留額外的 cache。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

對 CPU VPS 而言，OLLAMA_KEEP_ALIVE 比其他環境更重要。模型預設會保留在記憶體中 5 分鐘，之後卸載。下一個請求必須重新載入整個檔案，才能開始回應。如果 kernel 仍將檔案保留在 page cache 中，載入會很快；但只有閒置 RAM 能讓檔案留在其中。一旦其他工作將其排出，檔案就會重新從磁碟讀取，因此在速度較慢的儲存裝置上，重新載入 4.58 GiB 會讓回應時間從 2 秒增加到 30 秒。設定較長的 keep-alive 可以降低延遲，但會長期占用 RAM。兩者都是真實成本。請選擇影響較小的方案。如果您決定讓模型持續常駐，設定 keep_alive，使模型在閒置期間及重新開機後仍保留只需幾行設定，也能避免每次伺服器重新啟動時手動預熱模型。

llama.cpp 不提供 daemon 或 service user，因此必須自行建立這兩者。從您建置 llama.cpp 的目錄開始，將 binary 及其 libraries 安裝至 /usr/local，建立 llama user，並給予該使用者一份模型副本：

sudo cmake --install build
sudo ldconfig
sudo useradd --system --no-create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
sudo install -o llama -g llama -m 644 ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf /srv/models/model-Q4_K_M.gguf

如果您使用的是 release archive，而不是自行建置，請將 ExecStart 指向其中的 llama-server，因為 archive 會將 libraries 放在 binary 旁邊。接著將 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 啟用服務。之後，該 process 會在整個生命週期中持續保留模型。預設不會因閒置而卸載；但加入 --sleep-idle-seconds 後，即可自動卸載及重新載入模型，而不必停止服務。如果您不熟悉撰寫 units，這與在 VPS 上使用 systemd 執行自有服務的模式相同。

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

這個軸向的差異已大幅縮小。目前兩個專案都支援 OpenAI chat 格式，因此大多數用戶端函式庫只需變更 base URL，即可對應其中任一個專案。

Ollama 監聽 127.0.0.1:11434。其 OpenAI 相容路徑為 http://localhost:11434/v1/chat/completions，並在旁提供原生 API /api/chat。文件也說明了 Anthropic 相容路徑。這些路徑都不會讓模型自行查詢資料。因此，若應用程式需要取得新於模型訓練資料的答案，請規劃透過 Ollama 的 API、Open WebUI 或簡短的工具迴圈，串接網路搜尋。

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"}]}'

使用上述 flags 啟動後，llama-server 會監聽 127.0.0.1:8080。如果不另外指定，它目前預設使用 9931 埠（截至 27 October 2026 已確認）。因此，如果應用程式預期使用 8080，請在命令列保留 --port。它提供 /v1/chat/completions、/v1/completions 和 /v1/embeddings，也提供自有的 /completion endpoint 及內建 web UI。此外，它還提供 Ollama 沒有的運作狀態路由：/health 可用於 readiness probe；/props 可查看已載入模型的設定；/slots 可查看每個 request slot 目前的工作；加入 --metrics 後，/metrics 會以 Prometheus 格式提供指標，因為該 endpoint 預設為停用。如果你計畫監控這項服務，這項差異可能就是決定因素。

兩個伺服器都不會替你啟用驗證。基於合理的安全考量，兩者預設都只繫結 loopback。請透過 SSH tunnel 或反向代理存取它們，絕對不要將 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。最耗時的是提示處理：模型必須先處理完整提示，才會產生第一個輸出 token，因此冗長的 system prompt 會讓每個請求都多等一段時間。回覆長度是你實際能控制的成本部分，因為模型每秒只能生成 3 個 token 時，若一次冗長回覆產生 600 個 token，就會占用伺服器 200 秒，光生成就超過 3 分鐘。因此，使用 num_predict 限制輸出是避免單一冗長回覆變成逾時問題的最低成本方式。

CPU 適合的用途：使用 1B 到 4B 模型進行分類、資訊擷取、短摘要或路由。回覆可在數秒內產生，記憶體需求也符合一般方案。若要查看該尺寸的實際範例，而不是尺寸範圍，在 VPS 上下載並測量 Nemotron 3.5 Lightning會提供確切的 tag、實際所需的 RAM，以及不使用 GPU 時能維持的速度。CPU 不適合的用途：需要接近閱讀速度的互動式聊天、程式撰寫助理、長文件處理，或包含連續多次呼叫的 agent 迴圈。若迴圈每次呼叫需要 4 秒，連續呼叫 12 次，就要等 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 年 10 月 27 日的最新版本為 v0.7.0，其 release page 指向 nightly b11669 的二進位檔。v0.8.0 於 2026 年 10 月 28 日發布，其 release page 指向 nightly b11960 的二進位檔。以下指令使用 2026 年 8 月 2 日目前的標籤 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 會在載入前檢查大小，ollama run 會回傳以下格式的訊息：

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

目前的 Ollama 原始碼已不再包含這段訊息（於 27 October 2026 檢查）。Ollama 現在會將載入工作交給 llama-server，因此不適用的模型會改以 runner 失敗顯示，錯誤訊息通常會以以下內容開頭：

llama-server reported out-of-memory during startup
llama-server process has terminated

無論哪種情況，修正方式都相同。往下選擇一列量化格式、降低 context length，或改用較小的模型。

llama.cpp 沒有失敗，而是執行速度極慢。 llama.cpp 預設會使用 memory mapping 對 GGUF 建立記憶體映射，因此大於 RAM 的檔案仍可啟動。接著 kernel 會在每個 token 生成期間反覆從磁碟換入和換出權重，導致每個 token 的生成時間降至數秒，且磁碟使用率固定為 100 percent。傳入 --load-mode none 可停用 memory mapping。該選項取代了 --no-mmap；在固定使用的 b10224 build 中，該選項已標示為 deprecated，且目前的 build 已不再提供（於 29 October 2026 檢查）。當 kernel 介入時，dmesg 會顯示原因：

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

模型檔案完全無法載入。 如果 GGUF 是針對比引擎更新的模型系列所建立，引擎會因不認得該架構而回報錯誤；其中 <arch> 是檔案中 metadata 儲存的架構名稱：

llama_model_load: error loading model: unknown model architecture: '<arch>'

修正方式是升級引擎，而不是更換檔案。這就是固定版本的代價，也是您必須記錄 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 已經發生，模型正在重新載入；如果 page cache 未保留模型，則會從磁碟載入。在請求前立即執行 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 列為其推論後端（截至 27 October 2026）。Ollama 在其上加入模型登錄檔、將聊天訊息轉換為提示的 prompt template、一組預設取樣參數、具備閒置卸載功能的 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 擴大。