Ollama 與 vLLM 怎麼選？LLM 伺服器比較

Ollama 與 vLLM：一段話說明

Ollama 是附帶伺服器的模型管理工具：它會下載量化權重、載入模型，並在 127.0.0.1:11434 提供回應；如果主機只有 CPU，也能使用 CPU。vLLM 是以處理量為導向的推論引擎：它讓 GPU 同時處理多個請求，以維持高使用率；沒有 GPU 的機器不適合使用它。判斷方式就是這麼簡單。單一使用者與本機助理互動，適合使用 Ollama。為團隊提供服務的應用程式，適合使用 vLLM。

兩者都支援與 OpenAI 相容的 HTTP API，因此只要變更 base URL，客戶端程式碼即可在兩者之間切換。API 並不是差異所在。真正的差異在於第一個請求仍在產生 token 時，第二個請求抵達後會發生什麼事。

Ollama 的本質

Ollama 是一個便利層。透過單一安裝指令，它提供了模型登錄庫 (ollama pull llama3.1:8b)、權重本地儲存、聊天提示介面、systemd 服務以及 HTTP API。它所服務的模型大多為 GGUF 格式，通常經過 4-bit 量化，這就是為什麼 7B 或 8B 模型在磁碟上僅佔約 5 GB，而非 16 GB 的原因。量化減少了 CPU 推論所需的記憶體。在 Apple Silicon Mac 上，它也能透過 MLX 引擎執行基於 safetensors 的模型；自 v0.40.0（2026 年 9 月）起，支援的架構會自動在 MLX 上執行。

其 GGUF 執行器建立在 llama.cpp 之上，這是一個讓 GGUF 量化在一般硬體上變得實用的 C++ 推論函式庫。截至 2026 年 10 月，Ollama 支援 llama.cpp 與 MLX 兩種引擎，Linux 版本也支援搭配 CUDA 進行 MLX 推論。開發指南透過 cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13 啟用該後端，並要求 CUDA 13+ 與 cuDNN 9+ 作為先決條件。因此，當人們將 Ollama 與 llama.cpp 進行比較時，本質上是在比較一個易用性層與它所封裝的核心工具。

其設計目標為單一使用者。截至 2026 年 10 月，OLLAMA_NUM_PARALLEL 的預設值為 1，這意味著一個模型一次僅處理一個請求，其餘請求則進入預設容量為 512 筆的佇列中等待 (OLLAMA_MAX_QUEUE)。您可以調高並行設定，下節將說明其代價。若您先前未曾執行過 Ollama，請從 在 VPS 上託管 Ollama 並保持 11434 埠關閉 開始，因為本地 API 不需要任何驗證。

vLLM 的本質

vLLM 僅是一個推論伺服器。它不管理模型庫，僅提供用於執行中伺服器的 vllm chat 客戶端，且不會在請求時自動下載模型。您在啟動時指定一個 Hugging Face 儲存庫，它便會載入該模型並持續提供服務，直到您停止該程序為止。

這種專一性帶來的優勢是吞吐量。其運作依賴兩項機制：PagedAttention 以固定大小的區塊儲存 KV cache（key-value cache，即模型為每個活躍請求保留的每個 token 的注意力狀態），運作方式如同作業系統的記憶體分頁。請求不再需要預留一個針對最壞情況的大型連續空間，因此原本被預留卻閒置的記憶體，現在可用於處理更多並發請求。Continuous batching 允許新請求在下一個解碼步驟加入執行中的批次，而不必等待當前批次結束。已完成的序列會立即離開批次，其空位隨即被填補。

實際結果是：在單一 GPU 上，從單一並發使用者增加到三十個時，每秒總 token 數會顯著提升，而單一使用者的速度下降幅度遠低於預期。在 Ollama 的預設設定下，從一人增加到三十人，只會導致二十九個人排隊等待。

連續批次處理（Continuous batching）是關鍵差異

想像五個請求同時抵達硬體規格相同的伺服器。

預設設定下的 Ollama 會先完成第一個請求，接著處理第二個，依此類推。第五位使用者必須等待四次完整的生成過程。總吞吐量大致等於單次生成的速度，因為處理器同一時間僅處理一個序列。

vLLM 則是在同一次前向傳遞（forward pass）中解碼所有五個請求。為五個序列各生成一個 token 的成本，幾乎與生成一個序列的成本相同，因為最耗資源的部分是從記憶體讀取模型權重，而該讀取動作在整個批次中是共享的。這與導致 CPU 推論緩慢的記憶體頻寬限制是相同原理：成本在於移動權重，而非算術運算。

您可以設定 OLLAMA_NUM_PARALLEL=4 來獲得部分效果，但代價是記憶體。每個平行處理槽位（slot）都需要各自的 KV cache，而 Ollama 是將上下文配置量相乘而非分割：其 FAQ 指出所需 RAM 會隨 OLLAMA_NUM_PARALLEL 乘以 OLLAMA_CONTEXT_LENGTH 的比例擴展。因此，針對設定為 8192 個 token 的模型進行四個平行請求時，每個請求各佔用 8192 個 token，伺服器總共必須容納 32768 個 token 的快取。8192 本身是一個選項而非固定值，因此 調高 num_ctx 並評估其 RAM 成本 是決定是否能容納四個槽位的關鍵步驟。vLLM 的分頁快取（paged cache）機制避免了預先為每個槽位保留完整視窗，因為區塊是隨著請求實際增長而動態分配的。無論如何，單台伺服器能同時服務的人數上限，取決於 KV cache 大小、預填充（prefill）成本以及佇列深度，這也是 為何單人使用時運作流暢的伺服器，在五人同時使用時會變慢的原因。

安裝並使用 Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

安裝腳本會建立一個 ollama 系統使用者，安裝二進位檔案，並註冊綁定至 127.0.0.1:11434 的 ollama.service。由 --verbose 輸出的 eval rate 行，代表該機器上真實的每秒 Token 處理速度。請以此數據為準，而非參考任何公開的效能指標。單次提示詞的讀取僅為參考基準，而非容量上限，因此 跨併發掃描的每秒 Token 處理時間 才能告訴您該機器是否能負荷預期的負載，以及租用 GPU 是否比按 Token 付費更划算。

若要提高併發量，請使用 systemd drop-in 設定，以避免升級時覆蓋變更：

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps 會顯示目前載入的內容，其 PROCESSOR 欄位顯示真實狀態。100% CPU 代表未啟用 GPU，這也是大多數 Ollama 執行緩慢報告的真實原因。該 drop-in 中的 OLLAMA_KEEP_ALIVE=30m 行在閒置機器上同樣重要，因為預設值會在五分鐘無請求後卸載模型，而 在請求之間保持模型常駐 可避免在長達半小時的間歇後，再次觸發完整的模型載入時間。若您的閒置時間更長，請設定更大的數值。

安裝 vLLM 並提供服務

vLLM 的 GPU 版本需要 Linux 環境（macOS on Apple Silicon 僅支援 CPU，0.32.0 版本提供預先編譯的 wheel，而該平台的 GPU 加速需依賴社群維護的 vLLM-Metal 外掛，該外掛基於 MLX）。目前的 Python 版本（0.32.0，2026 年 10 月）支援 3.11 至 3.14，安裝指南亦列出相同範圍。由於 Python 3.10 已於 0.32.0 移除，下方選用 3.12 作為安全選擇。請將其安裝於獨立的虛擬環境中，因為它會拉取特定的 PyTorch 建置版本：

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm download-kernels

最後一行指令摘自 2026 年 10 月的 vLLM NVIDIA 安裝指南。它會安裝 FlashInfer 的預編譯核心。若未安裝，vLLM 會在啟動時下載並編譯核心，根據指南說明，這在 Hopper 及更新的 GPU 上可能增加數分鐘的啟動時間。每次升級 vLLM 後請務必重新執行此指令，因為當核心版本不符時，FlashInfer 將無法匯入。

接著啟動模型服務。名稱應使用 Hugging Face 的儲存庫 ID，而非簡短標籤：

vllm serve Qwen/Qwen2.5-1.5B-Instruct

首次啟動速度較慢，因為系統需下載權重並分析 GPU 以決定可容納的 KV cache 區塊數量。服務預設監聽 8000 埠。在撰寫任何客戶端程式碼前，請先進行測試：

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

若伺服器已安裝 Docker，使用官方映像檔可避免處理 CUDA 相依性問題：

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host 參數讓容器能存取主機的共享記憶體；增加 --shm-size 是另一種替代方案。PyTorch 會透過共享記憶體在處理程序間傳遞張量，這對於張量並行（tensor-parallel）推論尤為重要。

在生產環境中最重要的旗標包括 --max-model-len（您願意負擔的上下文視窗大小）、--gpu-memory-utilization（vLLM 可佔用的顯示卡比例，截至 2026 年 10 月預設值為 0.92）、--tensor-parallel-size（用於將單一模型拆分至多張 GPU），以及 --api-key。

vLLM 具備驗證旗標，而 Ollama 的本機 API 則無此功能

若您提供 bearer token，vLLM 將會強制執行驗證：

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

相同的值亦可透過 VLLM_API_KEY 環境變數設定。若請求 /v1 路由時未提供該權杖，將會收到 HTTP 401 錯誤。然而，此金鑰並未涵蓋整個伺服器。根據 vLLM 的安全指南以及 0.32.0 版原始碼中的驗證程式碼，該機制僅適用於 /v1、/v2、/inference 與 /cohere 路徑前綴下的端點。vllm serve 頁面上的 --api-key 說明文字僅列出前三項，但程式碼實際會檢查全部四項。安全指南與說明文字皆指出，其他端點（最顯著的是 /invocations，其公開了與 /v1 相同的推論功能）並未受到驗證保護。這足以成為不應將 8000 埠暴露於公開介面的理由。vLLM 的安全指南亦建議將速率限制交由前端的反向代理處理；此外，透過純 HTTP 傳送的權杖在傳輸過程中可被讀取，但此旗標確實代表伺服器具備呼叫者的概念。

Ollama 的本機 API 不需要驗證。雲端模型、模型發布與私有模型下載需要登入；直接存取 ollama.com 的 API 則需要 API 金鑰。任何能連線至 11434 埠的處理程序皆可執行、拉取或刪除模型。請將其維持在 loopback 介面上，並透過 您自行架設的 WireGuard VPN 或具備 TLS (傳輸層安全性) 終止功能的驗證型反向代理進行存取。

硬體需求：各項配置所需

Ollama 運行於 CPU。4-bit 量化模型每 10 億參數約需 0.5 GB RAM，加上約 1 GB 的執行時期開銷，以及額外的上下文空間；因此 3B 模型約需 4 GB 可用記憶體，8B 模型則需約 8 GB。在共享 vCPU 上，速度約為每秒個位數至十位數的 token。這是記憶體頻寬限制，並非設定錯誤，且無任何 flag 可修正此問題。若想觀察特定版本在實際運算下的表現而非僅憑經驗法則，請參考 在 VPS 上運行 Nemotron 3.5 Lightning，其中詳述了需拉取的確切 tag、載入後的 RAM 佔用量，以及純 CPU 運行是否足以滿足需求。

vLLM 預設需要 GPU。其預設路徑以 16-bit 精度提供未量化的權重，每 10 億參數約需 2 GB：8B 模型僅權重部分就需要約 16 GB 視訊記憶體，這還不包含為了實現並發處理而安裝 vLLM 所需的 KV cache。在 24 GB 的顯示卡上，這能留下可用的快取空間；但在 16 GB 的卡上則不足，因此您必須選擇較小的模型、傳入 --quantization（搭配量化檢查點，或在載入時量化全精度權重），或是使用 --cpu-offload-gb 將部分權重推入系統 RAM。後者雖能保持精度但速度較慢，因為這些權重在每次前向傳遞時都必須傳輸至 GPU。雖然存在專用的 CPU 後端，但這會失去使用 vLLM 的核心意義。

因此，硬體選擇通常決定了軟體選擇。沒有 GPU 就選 Ollama；若租用的 GPU 因請求序列化而長期處於 5% 使用率，則應選 vLLM。

適合您工作負載的選擇

• 單人使用、搭配 CPU VPS 進行草擬與摘要：Ollama。速度可以接受，而且沒有更簡單的選擇。
• 僅供您使用的程式碼助理，或是將工具連接至本機模型的 MCP 伺服器：Ollama。實際工作負載就是單一並行請求。
• 本週要比較 5 個模型：Ollama。拉取與刪除具標籤的模型正是它擅長的工作，而 vLLM 每次切換模型都需要重新啟動程序。
• 內部應用程式、聊天產品，或有實際使用者的檢索管線：vLLM。這正是批次處理足以支撐 GPU 成本的情境。
• 在夜間批次評分 100000 份文件的工作：vLLM，並設定較高的 --max-num-seqs。唯一重要的指標是處理量，單份文件的延遲則不重要。
• 多個自架 AI 代理程式會同時存取模型的代理程式平台：vLLM，因為代理程式流量具有突發性，而且天生適合平行處理。

故障模式與常見錯誤訊息

vLLM 因 KV cache 錯誤無法啟動。 錯誤訊息會顯示兩個數值：

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

模型宣告的上下文視窗大於載入權重後剩餘的記憶體空間。請使用 --max-model-len 8192 調低該數值，若無其他程式佔用顯卡，則可調高 --gpu-memory-utilization。

Ollama 在生成過程中輸出 Killed。 這是因為 Linux 的 OOM killer 終止了處理程序，原因是模型所需的 RAM 超過系統總量。請使用 sudo dmesg | grep -i oom 確認此狀況。解決方法是改用更小或量化程度更高的模型，調整設定無法解決此問題。

Ollama 單獨運作正常，但在負載下停滯。 系統不會顯示任何錯誤。隨著呼叫者增加，請求處理時間會變長，這是因為 OLLAMA_NUM_PARALLEL=1 會將請求序列化。長篇回答會加劇排隊狀況，因為單一呼叫者會佔用唯一的處理槽位直到模型停止輸出，進而阻塞後續請求。透過 以 num_predict 限制回覆長度 可設定單次請求佔用伺服器的時間上限。若要改善，請調高平行處理設定並承擔每個槽位上下文所需的額外 RAM，或將工作負載遷移至 vLLM。

vLLM 對所有 /v1 呼叫回傳 401 錯誤。 這是因為啟動時使用了 --api-key，但客戶端未發送 Authorization 標頭。大多數 OpenAI 客戶端程式庫會發送您設定的金鑰，請直接在程式庫中設定，而非移除該旗標。

vLLM 顯示找不到模型。 Ollama 會按需下載模型，但 vLLM 不會。請求主體中的 model 欄位必須與您啟動時指定的儲存庫 ID 相符，若有設定 --served-model-name，則需與該值相符。請使用 curl http://localhost:8000/v1/models 確認確切的字串。

同時執行是合理的做法

兩者並不互斥。常見架構是在 GPU instance 上執行 vLLM，為應用程式提供服務；同時在旁邊的一般 VPS 上執行 Ollama，供本機指令碼、cron 工作與測試新版模型使用。兩者的端點都相容於 OpenAI，因此只需使用同一個用戶端程式庫，再切換 base URL 即可。這裡的成本控管比選擇哪個引擎更重要，因為閒置的 GPU 與忙碌的 GPU 收費相同，而讓代理程式與推論成本維持可預測，與選擇伺服器是不同的工作。

FAQ

vLLM 比 Ollama 快嗎？

在同一張 GPU 上處理單一請求時，兩者的效能差異不大，因為底層運算邏輯相同。但在處理大量併發請求時，vLLM 表現遠優於 Ollama，因為 vLLM 採用連續批次處理（continuous batching），能在單次前向傳遞中解碼所有活躍序列，而 Ollama 預設則採取循序處理。在僅有 CPU 的機器上，兩者皆支援推論路徑，vLLM 需使用專用的 CPU wheels。

vLLM 可以在沒有 GPU 的情況下執行嗎？

可以，透過其 CPU 後端即可執行。標準的 wheels 針對 NVIDIA 或 AMD GPU 設計，而 vLLM 的核心價值在於透過批次請求讓加速器維持滿載，此優勢在 CPU 上並不適用。vLLM 確實提供 CPU 後端，並針對 x86 與 Arm 架構提供獨立的 wheels。若需進行實際的 CPU 推論，建議直接使用 Ollama 或 llama.cpp。

Ollama 與 llama.cpp 有什麼區別？

llama.cpp 是推論函式庫，而 GGUF 是其量化權重格式。Ollama 使用 llama.cpp 進行 GGUF 推論，並額外提供模型註冊表、標籤下載、模型管理功能以及 systemd 服務單元。Ollama 亦內建 MLX 引擎，可在 Apple Silicon 上執行基於 safetensors 的模型，並支援 Linux 上的 CUDA 建置，因此兩者在底層實作上並不完全相同。

執行 8B 模型時，vLLM 需要多少 GPU 記憶體？

在 16-bit 精度下，僅權重部分就約需 16 GB（每十億參數約 2 GB），此外還需預留 KV cache 的空間。24 GB 的顯示卡可舒適運行。16 GB 的顯示卡則需使用量化模型、更小的模型，或透過 --cpu-offload-gb 將部分權重移至系統記憶體，但會犧牲推論速度。vLLM 會佔用由 --gpu-memory-utilization 設定的顯示卡記憶體比例，截至 2026 年 10 月，預設值為 0.92。

在兩者之間切換時，需要修改應用程式碼嗎？

通常僅需修改基礎 URL、API key 與模型名稱。Ollama 在 http://127.0.0.1:11434/v1 提供相容於 OpenAI 的介面且會忽略 key；vLLM 則在 http://localhost:8000/v1 提供服務，若有設定 key，則會在 /v1 路由上強制驗證。模型名稱格式亦不同：Ollama 使用 llama3.1:8b，vLLM 則使用完整的儲存庫 ID，例如 Qwen/Qwen2.5-1.5B-Instruct。