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