Ollama 與 vLLM 怎麼選：自架 LLM 推論服務的兩條路線實測比較

把 LLM 從 API 服務搬回自己機器上跑，這兩年已經從「邊緣需求」變成中小團隊認真評估的選項。資料不出境、API 呼叫無上限、模型版本完全鎖定，這些理由都很實際。但問題接著就出現：自架 LLM 推論服務，到底要用 Ollama 還是 vLLM？

網路上多數比較文寫得太曖昧，結尾總是寫一句「依需求選擇」。這篇文章想直接給出結論：單人用、原型開發、或是內部少量請求的情境，Ollama 是對的選擇；只要你要服務多個併發使用者、或想榨乾 GPU 算力，vLLM 是唯一合理的答案。中間沒有灰色地帶，差距大到不需要猶豫。

兩者解決的根本問題不同

Ollama 把 LLM 推論變成 docker pull 等級的體驗。一行指令拉模型、一行指令跑起來，背後是 llama.cpp 引擎，CPU、GPU 都能跑，量化過的 GGUF 格式讓 7B 模型在 8GB 記憶體環境也能動。它的設計目標就是降低門檻，讓開發者在自己的筆電、Mac mini、或是一台 CPU-only 的 VPS 上都能跑模型。

vLLM 走的是完全相反的路線。它的核心技術是 PagedAttention，把 KV cache 切成固定大小的頁面（預設 16 個 token 一頁），讓多個請求可以共用相同 prefix 的記憶體頁面，長 context 場景下能省下超過一半的 VRAM。再加上 continuous batching，新進來的請求可以直接插入正在跑的 batch，不用等前一批完成。整套架構是為了在單張 GPU 上同時服務數十到上百個請求而設計。

簡單講：Ollama 優化的是「上手速度」，vLLM 優化的是「每秒服務人次」。

實測數據才是真相

業界這一年累積了不少實測，數字差距驚人。在 NVIDIA A100 上跑 Llama 3 8B，單一請求的情境 Ollama 反而略快（約 45 tok/s vs vLLM 38 tok/s，約 18% 優勢），這是因為 Ollama 的 overhead 低、量化壓縮也帶來增益。

但只要併發上去，局勢瞬間翻轉。50 個併發請求下，Ollama 的首字延遲（TTFR）攀升到約 3200 ms，請求在 queue 裡排隊等前一個跑完。vLLM 同樣 50 併發，TTFR 維持在 145 ms 左右，continuous batching 把新請求直接吸收進當前 batch。峰值吞吐量差距更誇張：vLLM 約 793 tok/s，Ollama 約 41 tok/s，差距接近 20 倍。

Ollama 從 0.4 版（2026 年 1 月）開始引入 continuous batching，是透過 llama.cpp 的 parallel-slot 機制實作。實測顯示這項改進有用，但天花板依然遠低於 vLLM。原因是 llama.cpp 的記憶體管理沒辦法做到 PagedAttention 那種細粒度的頁面分配，slot 之間的記憶體無法共享 prefix，多 slot 平行跑時 VRAM 很快就吃滿。

結論很清楚：低併發 Ollama 體驗夠用，高併發場景 vLLM 沒有對手。

硬體門檻與部署複雜度

這是 Ollama 真正的優勢領域。

Ollama 對硬體幾乎沒有要求。一台 16 vCPU 的 AMD EPYC VPS，跑 7B 模型 Q4 量化，能拿到 5–10 tok/s 的穩定輸出。對於摘要、抽取、分類、改寫這類任務，這個速度已經堪用。Mac mini M2 跑 7B 模型可以到 30 tok/s 以上。連 GPU 都不需要，這對許多臺灣中小企業來說是關鍵——買得起、養得起、跑得動。

vLLM 則是另一個世界。它需要 CUDA 11.8 以上、需要 GPU、而且最好是 Ampere（A100、A40）或 Hopper（H100）架構才能完整支援 FlashAttention-3。在 Turing 或 Pascal 老卡上能跑但效能打折，效益不大。Llama 3.3 70B 這種規模的模型，得用 H100 跑 FP8、或是兩張 H100 做 tensor parallel——後者 Ollama 完全不支援。

部署複雜度也對應拉開。Ollama 在 Linux VPS 上的安裝是：

curl -fsSL https://ollama.com/install.sh | sh
ollama serve
ollama pull llama3.1:8b
curl http://localhost:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "解釋 BGP anycast 的運作原理"
}'

正式環境建議先把安裝腳本下載後自行檢視內容並確認來源，再執行安裝，不要直接在敏感主機照貼 curl | sh。

vLLM 至少要先處理 CUDA driver、再 pip install、再用 OpenAI 相容 API 啟動：

pip install vllm
vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --dtype bfloat16 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --tensor-parallel-size 1

--max-model-len 與 --gpu-memory-utilization 是 vLLM 部署的兩個關鍵旋鈕。前者決定每個請求的 context 上限（設太大會吃掉 KV cache 空間，設太小會切到使用者的長對話），後者控制 vLLM 能用多少 VRAM（設 0.95 以上很容易 OOM，0.85–0.90 是安全範圍）。

用 systemd 把 Ollama 變成正式服務

Ollama 預設裝完就會註冊成 systemd service，但有幾個設定預設沒打開，正式環境需要調整：

1	sudo systemctl edit ollama

加入以下 override：

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_KEEP_ALIVE=24h"
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_MAX_LOADED_MODELS=2"

OLLAMA_KEEP_ALIVE 控制模型載入後待在記憶體裡多久，預設只有 5 分鐘，正式環境每次冷啟動載入 7B 模型要好幾秒，使用者體驗很差。設成 24h 讓模型常駐。

OLLAMA_NUM_PARALLEL 是 0.4 版之後可調的並行 slot 數，等同於同時能服務的請求數。設太大會讓 VRAM 不夠用，預設 4 是合理起點。

OLLAMA_HOST 預設只 listen 127.0.0.1，要對外服務必須改成 0.0.0.0，並在前面用 Caddy 或 Nginx 加上認證——Ollama 本身沒有 API key 機制，任何能連到 11434 port 的人都能呼叫。

vLLM 在 Docker 裡的正式部署

vLLM 官方 Docker image 是最穩定的部署方式：

services:
  vllm:
    image: vllm/vllm-openai:v0.7.2
    runtime: nvidia
    ports:
      - "8000:8000"
    volumes:
      - ./models:/root/.cache/huggingface
    environment:
      - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}
    command:
      - --model=meta-llama/Llama-3.1-8B-Instruct
      - --dtype=bfloat16
      - --max-model-len=8192
      - --gpu-memory-utilization=0.90
      - --api-key=${VLLM_API_KEY}
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]
    restart: unless-stopped

幾個重點：

runtime: nvidia 需要先在主機裝 nvidia-container-toolkit
--api-key 是內建的 bearer token 驗證，比 Ollama 完善
HuggingFace token 透過環境變數注入，避免寫死在 image 裡
volume mount 把模型快取拉到主機，重啟容器不需要重新下載 15GB 模型

vLLM 暴露的是 OpenAI 相容 API，這代表所有支援 OpenAI SDK 的程式碼，把 base_url 換掉就能直接用：

from openai import OpenAI
client = OpenAI(
    base_url="https://llm.example.com/v1",
    api_key="sk-your-vllm-key"
)
response = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=[{"role": "user", "content": "你好"}]
)

這個 API 相容性是 vLLM 在生產環境的另一個關鍵優勢——前端應用幾乎不用改。Ollama 也有 OpenAI 相容 endpoint（/v1/chat/completions），但部分參數行為與 OpenAI 不完全一致，遇到複雜的 function calling 場景容易踩坑。

該怎麼決定

把選擇條件攤開：

Ollama 適合：個人開發、Demo、內部工具、單一使用者的 RAG 系統、低頻率的批次處理、預算只有 CPU VPS 的情境、想要 5 分鐘內看到結果的場景。

vLLM 適合：對外提供 LLM API 服務、SaaS 後端、需要服務多個併發使用者的 AI Agent 平臺、有 GPU 預算且想最大化算力 ROI 的團隊、需要 OpenAI 相容 API 給其他服務介接的場景。

中間還有一個選項：llama.cpp 本身。如果你不需要 Ollama 的模型管理便利，又不想被 vLLM 的 GPU 門檻綁住，直接跑 llama.cpp server 在 CPU 環境效能會比 Ollama 略好一點點（兩者底層相同，但 Ollama 多了一層抽象），代價是設定要自己處理。

實務上，許多團隊會兩個都跑：Ollama 給開發環境、跑各種模型實驗用；vLLM 給正式環境、固定模型版本、加上 monitoring。模型切換、A/B 測試、舊版本 fallback 這些需求，OpenAI 相容 API 都比 Ollama 的私有 API 好做。

不管選擇哪一種推論引擎，自架 LLM 服務都需要穩定的計算資源做支撐。NCSE Network 提供搭載 Intel Gold CPU 與 NVMe SSD 的臺灣 VPS 主機，適合跑 Ollama 這類 CPU 推論工作負載；同時也提供機房代管服務，讓需要 GPU 算力的團隊把自有設備放進是方電訊機房，享有低延遲的網路與穩定電力。實際方案規劃歡迎到 ncse.tw 了解。