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 推論成為可能。

其執行器建置於 llama.cpp 之上。llama.cpp 是讓 GGUF 量化能在一般硬體上實用的 C++ 推論函式庫。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。8192 本身也是設定值，不是固定前提，因此 提高 num_ctx 並規劃所需的 RAM 是決定 4 個插槽是否實用的步驟。vLLM 的 paged cache 可避免這項取捨，因為它會隨著請求實際增長，將區塊分配給該請求。無論採用哪種方式，單台伺服器能同時服務多少人的上限，都取決於 KV cache 大小、prefill 成本與佇列深度。這就是 一台單人使用時運作順暢的伺服器，面對 5 個人卻變得緩慢的原因。

安裝並使用 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 設定，在負載低的主機上同樣重要，因為預設值會在 5 分鐘沒有請求後卸載模型，而讓模型在請求之間保持常駐，才能避免閒置 1 小時後的第一個提示再次支付完整的載入時間。

使用 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

第一次啟動速度較慢，因為 vLLM 會先下載權重，再分析 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 是必要設定，不是裝飾用途：PyTorch 會透過共享記憶體，在程序之間傳遞張量；而 Docker 預設配置的共享記憶體太小，無法用於張量平行推論。

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

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

只要提供 bearer token，vLLM 就會強制要求驗證：

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（傳輸層安全性）的驗證型反向代理。

硬體：各自需要什麼

Ollama 可在 CPU 上執行。4-bit 量化模型每 10 億個參數大約需要半 GB RAM，另加約 1 GB 的執行階段額外負載；內容上下文還會增加需求。因此，3B 模型需要約 4 GB 可用記憶體，8B 模型則約需 8 GB。在共用 vCPU 上，速度約為每秒個位數到低兩位數的 tokens。這是記憶體頻寬造成的限制，不是設定錯誤，也沒有任何 flag 能修正。若要查看特定版本的實際情況，而不是依循經驗法則，在 VPS 上執行 Nemotron 3.5 Lightning可明確確認要拉取的 tag、模型載入後占用的 RAM，以及僅使用 CPU 的速度是否足以接受。

vLLM 的設計前提是使用 GPU。預設路徑會以 16-bit 精度提供未量化的權重，每 10 億個參數大約需要 2 GB，因此 8B 模型光是權重就約需 16 GB VRAM，還未計入支援 vLLM 並行處理所需的 KV cache。使用 24 GB 顯示卡時，剩餘空間足以配置可用的 cache。使用 16 GB 顯示卡時則不足，因此必須改用較小的模型，或搭配量化 checkpoint 傳入 --quantization。雖然存在 CPU backend，但標準 wheels 並非為此建置，而且這會失去執行 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.

模型宣告的 context window 大於載入權重後剩餘的記憶體。使用 --max-model-len 8192 降低 context window；如果沒有其他程序使用該 GPU，則提高 --gpu-memory-utilization。將使用率推高到約 0.95 以上，通常會把這個啟動錯誤換成之後負載增加時的 CUDA out-of-memory 當機，後者更難處理。

Ollama 在生成過程中顯示 Killed。 Linux 的 out-of-memory killer 停止了該程序，因為模型需要的 RAM 超過伺服器可用容量。使用 sudo dmesg | grep -i oom 確認。解決方式是改用較小或量化程度更高的模型，而不是修改設定。

Ollama 單獨執行時回應正常，但負載增加後停滯。 任何地方都不會顯示錯誤。呼叫端越多，請求處理時間就越長，因為 OLLAMA_NUM_PARALLEL=1 會將請求序列化。較長的回答會讓佇列更加嚴重，因為單一呼叫端會占用唯一的執行位置，直到模型決定停止，期間後續請求都會被阻塞。因此，使用 num_predict 限制回答長度可限制單次對話占用伺服器的時間上限。提高平行處理設定，並接受每個請求可用的 context 較小；或者將工作負載移至 vLLM。

vLLM 每次呼叫都回傳 401。 啟動時使用了 --api-key，但用戶端沒有傳送 Authorization 標頭。大多數 OpenAI 用戶端函式庫會將你傳入的值作為 key 傳送，因此應在該處設定 key，而不要移除這個 flag。

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 明顯更快，因為 continuous batching 會在一次 forward pass 中解碼所有作用中的序列，而 Ollama 預設會依序處理。在僅使用 CPU 的機器上，這個問題不適用：Ollama 可以在該環境執行，而 vLLM 實際上無法執行。

vLLM 可以不使用 GPU 執行嗎？

實際上不可行。標準 wheel 以 NVIDIA 或 AMD GPU 為目標，而 vLLM 的用途是在 CPU 上以批次請求讓加速器維持高使用率；在僅使用 CPU 的環境中，這項優勢並不存在。vLLM 提供 CPU backend，但主要用於開發。若要進行實際的 CPU 推論，請直接使用 Ollama 或 llama.cpp。

Ollama 與 llama.cpp 有什麼差異？

llama.cpp 是推論函式庫，GGUF 是其量化權重格式。Ollama 的 runner 建立在 llama.cpp 之上，並補足 llama.cpp 留給使用者處理的部分：model registry、自動下載、常駐伺服器、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 設定的顯示卡記憶體比例；截至 July 2026，預設值為 0.92。

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

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