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

Ollama 與 vLLM：一段話說明

Ollama 是附帶伺服器的模型管理工具：它會下載量化權重、載入權重，並在 127.0.0.1:11434 上回應；如果該主機只有 CPU，也會使用 CPU。vLLM 是吞吐量引擎：它會讓 GPU 同時處理大量請求，以維持 GPU 高使用率；在沒有 GPU 的機器上，vLLM 並不適用。決策原則就是如此。單一使用者與本機助理互動，是 Ollama 的使用情境。應用程式服務一個團隊，是 vLLM 的使用情境。

兩者都支援與 OpenAI 相容的 HTTP API，因此只要變更基底 URL，客戶端程式碼就能在兩者之間移轉。差異不在 API。差異在於第一個請求仍在產生 token 時，第二個請求到達後會發生什麼事。

Ollama 的實際功能

Ollama 是便利層。只要執行一個安裝命令，就能取得模型登錄庫（ollama pull llama3.1:8b）、本機權重儲存區、聊天提示、systemd 服務和 HTTP API。它提供的模型是 GGUF 檔案，通常採用 4-bit 量化，因此 7B 或 8B 模型在磁碟上約占 5 GB，而不是 16 GB。量化技術讓 CPU 推論成為可能。

其執行器建置於 llama.cpp 之上。llama.cpp 是 C++ 推論函式庫，讓 GGUF 量化能在一般硬體上實際運作。Ollama 後來為部分較新的模型系列加入了自己的引擎，但 llama.cpp 仍是其大部分服務背後的基礎。因此，將 Ollama 與 llama.cpp 比較時，實際上大多是在比較人體工學層與其包裝的底層元件。

這項設計以單一使用者為目標。截至 2026 年 7 月，OLLAMA_NUM_PARALLEL 的預設值為 1。這表示每個模型一次處理一個要求，其餘要求都會在佇列中等待；佇列預設可容納 512 個項目（OLLAMA_MAX_QUEUE）。您可以提高平行處理設定；下方章節會說明這樣做的成本。如果您尚未執行過 Ollama，請先參閱在 VPS 上代管 Ollama 並保持連接埠 11434 關閉，因為該 API 完全沒有任何驗證機制。

vLLM 實際上是什麼

vLLM 只是推論伺服器。它不管理模型庫，也沒有聊天提示詞功能，且不會在收到請求時替您下載模型。您在啟動時指定 Hugging Face 儲存庫，vLLM 會載入該模型，並持續提供服務，直到您停止程序。

這種專注設計帶來的是輸送量。兩項機制負責實現這一點。PagedAttention 會將 KV cache（key-value cache，即模型為每個作用中請求保留的逐 token 注意力狀態）儲存於固定大小的區塊中，方式類似作業系統分頁記憶體。請求不再需要按照最壞情況預留一大段連續記憶體，因此原本預留但未使用的記憶體，可供更多並行請求使用。Continuous batching 允許新請求在下一個解碼步驟加入執行中的批次，而不必等待目前批次完成。序列完成後會立即離開批次，其位置則由其他請求補上。

實際結果是：在單張 GPU 上，並行使用者從 1 增加到 30 時，總 tokens per second 會大幅提升，而每位使用者的速度下降幅度遠小於預期。使用 Ollama 的預設行為時，使用者從 1 增加到 30，只會讓另外 29 人等待。

連續批次處理就是全部差異

假設在相同硬體上，每部伺服器同時收到 5 個請求。

Ollama 使用預設設定時，會先將第 1 個請求處理完成，再處理第 2 個請求，依此類推。第 5 個呼叫端必須等待前 4 個請求完成完整生成。總吞吐量大致等於單一生成的速度，因為處理器一次只處理一個序列。

vLLM 會在同一次 forward pass 中解碼全部 5 個序列。為 5 個序列各生成 1 個 token，成本幾乎不比為 1 個序列生成 1 個 token 高，因為成本最高的部分是從記憶體讀取模型權重，而這次讀取可由整個批次共用。這與造成 CPU 推論速度緩慢的記憶體頻寬因素相同：需要付出的成本是搬移權重，而不是執行算術運算。

您可以設定 OLLAMA_NUM_PARALLEL=4，取得部分相同的效果。代價是記憶體。每個平行工作槽都需要自己的 KV cache，而 Ollama 會在各工作槽之間分配 context window。因此，對於設定為 8192 tokens 的模型，4 個平行請求會讓每個請求只有 2048 tokens 的 context。vLLM 的 paged cache 能避免這項取捨，因為它會在請求實際增長時，才為該請求配置區塊。

使用 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 數。請以此數值為準，不要採信任何已發布的數據。

若要提高並行處理量，請使用 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 執行速度緩慢報告的實際原因。

使用 vLLM 安裝並提供服務

vLLM 需要 Linux 和 Python 3.10 至 3.13。請將其安裝到專用的虛擬環境中，因為它會載入特定的 PyTorch 組建：

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

接著提供模型服務。模型名稱是 Hugging Face 儲存庫 ID，不是簡短標籤：

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

第一次啟動速度較慢，因為它會先下載權重，然後分析 GPU，以決定可容納多少 KV 快取區塊。它會監聽連接埠 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 是必要設定，不是裝飾性選項：PyTorch 會透過共用記憶體在程序之間傳遞張量，而 Docker 預設配置的共用記憶體太小，無法支援張量平行推論。

在正式環境中最重要的旗標是 --max-model-len（願意支付成本的內容視窗大小）、--gpu-memory-utilization（vLLM 可使用的 GPU 記憶體比例；截至 2026 年 7 月，預設值為 0.92）、--tensor-parallel-size（將單一模型分散到多個 GPU），以及 --api-key。

vLLM 的驗證只需設定一個旗標，Ollama 則沒有驗證功能

如果提供 bearer token，vLLM 會強制要求該 token：

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

相同的值也可以來自 VLLM_API_KEY 環境變數。未提供該值的要求會收到 HTTP 401。這仍不足以成為在公共介面公開連接埠 8000 的理由，因為 vLLM 沒有速率限制功能，而且純 HTTP token 可在傳輸過程中被讀取；但這表示伺服器能識別呼叫端。

Ollama 完全沒有驗證功能。它沒有金鑰、登入機制或允許清單。任何能連線至 11434 的程序都可以執行、下載或刪除模型。請讓它只監聽 loopback，並透過 自行架設的 WireGuard VPN 存取；或者使用會終止 TLS（傳輸層安全性）的驗證反向 Proxy。

硬體：各自需要什麼

Ollama 在 CPU 上執行。4-bit 量化模型每 10 億個參數約需 0.5 GB RAM，另需約 1 GB 執行階段額外負載，以及更多內容所需的記憶體。因此，3B 模型需要約 4 GB 可用記憶體，8B 模型需要約 8 GB。在共用 vCPU 上，速度約為每秒個位數至低兩位數的 token。這是記憶體頻寬造成的限制，不是設定錯誤，也沒有任何旗標可以修正。

vLLM 預設使用 GPU。其預設路徑會以 16-bit 精度提供未量化權重，每 10 億個參數約需 2 GB，因此 8B 模型僅權重就約需 16 GB 顯示記憶體，還未計入你為 vLLM 的並行處理能力所配置的 KV cache。使用 24 GB 顯示卡時，仍可提供足夠的 cache。使用 16 GB 顯示卡時則不足，因此你必須選擇較小的模型，或搭配量化 checkpoint 傳入 --quantization。雖然存在 CPU 後端，但標準 wheel 並非針對該後端建置，而且這會失去執行 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: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

模型宣告的內容視窗大於載入權重後剩餘的記憶體。使用 --max-model-len 8192 將其調低；如果沒有其他程式使用該顯示卡，則提高 --gpu-memory-utilization。將使用率推高到約 0.95 以上，通常會把這項啟動錯誤改成稍後在負載下發生的 CUDA 記憶體不足崩潰，而後者更為嚴重。

Ollama 在生成過程中輸出 Killed。 Linux 記憶體不足終止程序，因為模型所需的 RAM 超過主機可用容量。使用 sudo dmesg | grep -i oom 確認。解決方法是改用較小或量化程度更高的模型，而不是調整設定。

Ollama 單獨執行時回應正常，但在負載下停滯。 任何地方都不會顯示錯誤。隨著呼叫端增加，要求只會花費更長時間，因為 OLLAMA_NUM_PARALLEL=1 會將它們序列化。提高該值並接受每個要求較小的內容視窗，或將工作負載移至 vLLM。

vLLM 對每次呼叫都回傳 401。 您以 --api-key 啟動它，但用戶端未傳送 Authorization 標頭。大多數 OpenAI 用戶端程式庫會將您傳入的值作為 key 傳送，因此應在該處設定，而不要移除旗標。

vLLM 表示找不到模型。 Ollama 會依需求拉取模型，但 vLLM 不會。要求本文中的 model 欄位必須符合您啟動時使用的 repository 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 的預設行為會依序處理。僅使用 CPU 的機器不適用於此問題：Ollama 可在該環境執行，而 vLLM 實際上無法執行。

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

實用性不高。標準 wheels 以 NVIDIA 或 AMD GPU 為目標，而 vLLM 的用途是透過批次要求讓加速器持續滿載；在 CPU 上這項優勢便不存在。vLLM 提供 CPU backend，適合開發工作。若要實際進行 CPU 推論，請直接使用 Ollama 或 llama.cpp。

Ollama 和 llama.cpp 有何不同？

llama.cpp 是推論函式庫，GGUF 是其量化權重格式。Ollama 的 runner 建立在 llama.cpp 之上，並加入 llama.cpp 留給使用者處理的功能：model registry、自動下載、常駐 server、systemd unit，以及與 OpenAI 相容的 endpoint。Ollama 已為部分較新的模型系列加入自己的 engine，因此兩者底層已不再完全相同。

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

在 16-bit 精度下，僅權重就約需 16 GB，約為每 1 billion 個參數 2 GB，此外還需為 KV cache 預留空間。24 GB 顯示卡可提供充裕空間。16 GB 顯示卡需要使用量化 checkpoint 或較小的模型。vLLM 使用由 --gpu-memory-utilization 設定的顯示卡記憶體比例；截至 2026 年 7 月，預設值為 0.92。

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

通常只需修改 base URL、API key 和 model name。Ollama 在 http://127.0.0.1:11434/v1 提供與 OpenAI 相容的介面，且會忽略 key；vLLM 則在 http://localhost:8000/v1 提供介面，若設定 key，便會強制驗證。模型名稱的格式不同：Ollama 使用 llama3.1:8b，vLLM 使用完整的 repository id，例如 Qwen/Qwen2.5-1.5B-Instruct。