用 vLLM 自架高吞吐推論伺服器

大部分說「我們應該自架」的團隊沒算過數學。Anthropic API 的 $3/M input + $15/M output 算便宜 —— 直到你撞上穩定高吞吐流量,而且就算撞上了,把 ops 時間跟 tail latency 算進來,自架不一定贏。

但當自架真的贏時 —— 微調模型、受監管產業、超高 QPS —— vLLM 是 2026 年的 production 級選擇。這篇是完整 setup、調校 playbook、跟對應真實工作負載的 benchmark。

自架什麼時候贏 API

先做餐巾紙數學:

前沿模型(Claude 4.7 Opus、GPT-5): 在你每月花費破 $30k 又有重 reasoning 負載之前,API 基本上永遠贏。前沿模型在實務上自架不了。
中階(Claude Haiku、GPT-5 mini): 穩定吞吐 $10k/月以下,API 贏。
開源權重(Llama 70B、Mixtral 8x22B、Qwen 2.5 72B): 租 H100 自架約 $2/hr。GPU 使用率能維持 50% 以上,自架贏對應 API 服務。
小開源權重(Llama 8B、Phi-4、Qwen 7B): 每天 1000+ 請求自架永遠贏成本。單張 24GB GPU 跑量化模型。
自己微調的模型: 自架是唯一選項(沒有 API 會服務你的 adapter)。

不管成本如何,自架贏的其他理由:

隱私 / 合規。 醫療、金融、政府 —— 有時候資料根本不能離開你的網路。
客製 kernel 工作。 你想要 speculative decoding、跨請求共享 KV cache、客製 attention 機制。
延遲下限。 API 含網路有 200-400ms 基線。跟你 app 同 datacenter 自架:50ms。

為什麼是 vLLM

2026 年推論伺服器版圖:

vLLM。 社群標準。GPU per token 吞吐最佳、模型支援最廣、動態批次最好。柏克萊大學專案,非常活躍。
SGLang。 後起之秀。在結構化輸出跟 agent workflow 上很強,某些工作負載比 vLLM 略快。
TensorRT-LLM(NVIDIA)。 單流延遲最低。設定很痛。
TGI(HuggingFace)。 Production 穩定,raw 吞吐略落後 vLLM。Docker 故事好。
Ollama / llama.cpp。 筆電跟小型開發流程很棒,不是 production 用。

2026 年大部分團隊:vLLM。性能差距小,文件跟社群讓它是阻力最小的路。

Setup:從零到服務

最小可用 production 設定,單張 H100 80GB 服務 Llama 3.3 70B Instruct:

# 1. Linux(Ubuntu 22.04+)安裝
pip install vllm

# 2. 啟動伺服器
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 1 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.92 \
  --enable-prefix-caching \
  --port 8000

就這樣。你現在有一個 OpenAI 相容 API 在 http://localhost:8000/v1。任何 OpenAI SDK 設 base_url 指過去就能用。

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="local")
response = client.chat.completions.create(
    model="meta-llama/Llama-3.3-70B-Instruct",
    messages=[{"role": "user", "content": "Hello"}],
)

重要的 flag

預設值對 production 不是最佳。關鍵幾個:

--gpu-memory-utilization。 預設 0.9。production 拉到 0.92-0.95 拿更多 KV cache,共享 GPU 拉低。越高 = 同時更多請求 = OOM 風險越高。
--max-model-len。 你允許的 context window。越低 = 每請求 KV cache 越多 = 吞吐越高。如果真實 prompt 是 2k token,設 4096 不要設 128000。
--max-num-seqs。 多少請求可以一起 batch。預設 256 寬鬆,看記憶體調。
--enable-prefix-caching。 永遠開。如果你有重複的長 system prompt,這會 cache 它。重複工作負載 2-5× 吞吐提升。
--tensor-parallel-size。 模型切到幾張 GPU。70B 塞 80GB 用 1,70B fp16 塞 2× A100 40GB 用 2。
--quantization fp8 或 --quantization awq。 量化模型換 2× 吞吐,品質代價小。H100 用 fp8,Ada GPU 用 awq。
--enable-chunked-prefill。 把長 prompt 切塊。混合長短請求時延遲更平順。

吞吐 benchmark(真實數字)

單張 H100 80GB 服務 Llama 3.3 70B Instruct,fp16 + prefix caching,我量到的:

循序(每次 1 個請求): ~85 tokens/sec 生成。低延遲單流好用。
並發(32 個飛行中): ~6,400 tokens/sec 總生成。動態批次發揮作用。
fp8 量化,32 並發: ~10,000 tokens/sec。約 +50% 吞吐,大部分任務品質掉很少。
跟 API 等價成本: 6,400 tok/s × $2.50/hr H100 = $0.11/M token。對比 GPT-5 mini $0.40/M output。GPU 能持續忙,自架在 $/token 上贏約 3.5×。

如果平均 GPU 使用率 30%,成本優勢縮到差不多打平 API。

Production 部署 pattern

2026 年真實部署:

vLLM 在 Docker container 裡。 用官方 vllm/vllm-openai image,版本鎖死。
後面接 load balancer。 需要 >1 GPU 吞吐就多開 vLLM 實例。round-robin 就好,只有用跨請求 KV cache 共享才需要 sticky session。
健康檢查。 vLLM 有 /health 跟 /metrics endpoint,接到監控。
自動擴展。 vLLM cold start 60-120 秒(load model)。基於請求佇列深度擴展,不是基於 CPU。
API fallback。 GPU 飽和或當機時永遠要有 API 備援。別讓單一當機就 production failure。

不想跑硬體的託管選項:Modal、RunPod、Fireworks、Baseten。對 raw GPU 加價,但幫你處理 ops。

production 出包的事

吃過我週末的東西,不要讓它吃你的:

長 prompt 時 OOM。 30k context + 4k output 的請求生成中可能 OOM。--max-model-len 設成你 VRAM 能 handle 的值,即使模型支援更多。
Tokenizer 不匹配。 別 pip install 跟 vLLM 預期不同的 transformers 版本,精確版本鎖死。
prefill 期間延遲爆衝。 長 prompt 卡住整個 batch。--enable-chunked-prefill 有幫助;--num-scheduler-steps 8 在重混合流量上更好。
跑得好好的突然 CUDA OOM。 記憶體碎片。發生時重啟伺服器;頻繁的話查 --enforce-eager。
Adapter 載入。 vLLM 2026 透過 --enable-lora 支援每請求 LoRA adapter 切換。每個 adapter 約佔 200MB GPU 記憶體。

什麼時候不要自架

每天 <1000 請求。 API 更便宜、簡單、可靠。
你要前沿品質。 2026 沒有開源權重模型在硬 reasoning 任務上對得上 Claude 4.7 Opus 或 GPT-5。
不能容忍當機。 自架單 GPU 一定會當,多 GPU + 冗餘 = 真 ops 投資。
團隊沒 GPU 專家。 vLLM 直接,但失敗模式(CUDA 不匹配、NCCL 錯、kernel crash)需要 Linux 跟 CUDA 都熟的人。

下一步

vLLM 官方文件跟調校指南。
Efficient Memory Management for Large Language Model Serving with PagedAttention —— 原始 vLLM 論文。
SGLang 文件(值得認識的主要替代品)。
查這些詞:prefix caching、speculative decoding、paged attention、continuous batching。