适用场景与目标

vLLM 适合谁？

• 日均 API 调用超过 10 万次的 AI 应用后端
• 需要自己托管大模型（70B 以内）且对成本敏感
• 对首次 token 延迟（TTFT）和吞吐率有明确 SLO 的场景
• 需要多模型共享 GPU 资源的团队

核心优势： vLLM 的 PagedAttention 算法将 GPU 内存管理虚拟化，消除传统推理框架 60-80% 的内存碎片，吞吐量比 HuggingFace Transformers 高 2-24 倍。一次迁移，GPU 成本直降 50-70% 并非夸张。

不适用的场景： 模型过大（>200B）且无多卡资源；极度定制化的算子优化（选 TensorRT-LLM）。

---

最小可行方案（MVP）步骤

Step 1：选型与硬件匹配

模型	推荐精度	最低硬件	推荐配置
Qwen2-7B	FP8 / AWQ	单卡 24GB	A100 40GB 或 H100 80GB
Qwen2-14B	FP8 / AWQ	单卡 40GB	A100 40GB ×1 或 H100 80GB
Qwen2-72B	FP16	2× H100 80GB	2× H100 FP16 或 H100 FP8 单卡
Llama3-8B	FP8	单卡 24GB	A100 40GB

💡 2026 年 H100 80GB 单卡可装下 72B FP8 模型（~70GB），优先考虑 FP8 节省成本。

Step 2：Docker 部署（单卡）

# 拉取官方镜像（v0.8+）
docker pull vllm/vllm-openai:latest

# 启动服务
docker run --gpus all \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  --env TF_ENABLE_ONEDNN_OPTS=0 \
  --shm-size 16g \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3-70B-Instruct \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.92 \
  --max-model-len 16384 \
  --trust-remote-code \
  --quantization fp8

关键参数解释：

• --gpu-memory-utilization 0.92：留给 KV cache 92% 显存，别设 1.0 会 OOM
• --max-model-len 16384：长上下文场景按需调高，注意显存消耗
• --quantization fp8：FP8 量化，70B 模型从 140GB 压到 ~70GB，单卡可跑

Step 3：验证服务

# 检查模型列表
curl http://localhost:8000/v1/models

# 测试推理
curl -X POST http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-3-70B-Instruct",
    "messages": [{"role": "user", "content": "用三句话解释PagedAttention"}],
    "max_tokens": 200,
    "temperature": 0.7
  }'

Step 4：多卡 Tensor Parallel（2卡+）

docker run --gpus all \
  -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3-70B-Instruct \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 16384 \
  --quantization fp16

--tensor-parallel-size N：将模型切分到 N 卡，延迟更低但吞吐量略降。N 卡须为 2^n（1, 2, 4, 8）。

---

关键实现细节

健康检查与指标监控

# 查看吞吐指标
curl http://localhost:8000/metrics | grep vllm

# 关键指标：
# vllm:num_requests_running —— 当前运行请求数
# vllm:num_requests_waiting —— 排队等待数，>0 说明容量不足
# vllm:gpu_cache_usage_utilization —— GPU 显存利用率

OpenAI 兼容 API 用法（Python client）

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY"  # 本地部署无需 key
)

response = client.chat.completions.create(
    model="meta-llama/Llama-3-70B-Instruct",
    messages=[
        {"role": "system", "content": "你是一个专业的技术助手"},
        {"role": "user", "content": "解释什么是连续批处理（Continuous Batching）"}
    ],
    max_tokens=512,
    temperature=0.3,
)

print(response.choices[0].message.content)

Kubernetes 部署（Helm chart）

# 安装官方 vLLM production stack
helm repo add vllm https://vllm.ai/helm-charts
helm repo update

helm install vllm vllm/vllm-production-stack \
  --set model.name=meta-llama/Llama-3-70B-Instruct \
  --set model.tensor_parallel=2 \
  --set service.type=LoadBalancer \
  --namespace vllm \
  --create-namespace

---

常见坑与规避清单

🔴 坑 1：显存溢出（OOM）

原因： --max-model-len 过大 + --gpu-memory-utilization 设太高。

规避：

# 固定留 8% 显存给 KV cache
--gpu-memory-utilization 0.90
# 长上下文按需开启，不要开局就 32k
--max-model-len 8192

首次上线先用小窗口压测，观察 vllm:num_requests_running 和实际显存占用再逐步调高。

🔴 坑 2：FP8 量化精度损失

原因： 并非所有模型 FP8 效果一致，部分量化敏感模型（如数学/代码类）可能质量下降。

规避： 先在 evals 上对标 BF16 基准线，下降 >2% 则切回 BF16 用 tensor parallel。

# 量化方案选择
quantization=fp8   # 70B 单卡可行，质量损失可接受
quantization=awq   # 更高精度，推理稍慢，适合对质量敏感场景
quantization=gptq   # 兼容性最广，速度最慢

🔴 坑 3：冷启动延迟过高

原因： 首次请求需要加载模型到 GPU，大模型可能需要 30-60 秒。

规避： 使用 --enforce-eager + 预热请求，或使用 vLLM 的模型预加载功能。

# 启动后立即发送 3-5 条预热请求
for i in {1..5}; do
  curl -s -X POST http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model":"meta-llama/Llama-3-70B-Instruct","messages":[{"role":"user","content":"hi"}],"max_tokens":5}'
done

🟡 坑 4：Tensor Parallel 通信瓶颈

原因： 多卡间 NVLink 带宽不足时，tensor parallel 反而更慢。

规避： 2 卡以上确保 NVLink 连接；无 NVLink 时用 pipeline parallel 替代。

# 检查 NVLink
nvidia-smi topo -m

🟡 坑 5：多实例负载不均

原因： vLLM 默认 continuous batching，各实例队列深度不同。

规避： 在 vLLM 前加 Nginx 或 Traefik 做反向代理，结合 health check。

# nginx.conf 片段
upstream vllm_backend {
    least_conn;
    server 192.168.1.101:8000;
    server 192.168.1.102:8000;
}

---

成本/性能/维护权衡

成本横向对比（以 72B 模型、月均 3000 万 token 为例）

方案	月成本（估算）	QPS 上限	维护难度
OpenAI GPT-4o API	~$3000	受限	低
HuggingFace TGI（A100×2）	~$2500	中	中
vLLM FP8 单卡 H100	~$800	高	中
vLLM FP16 双卡 H100	~$1600	很高	中高

vLLM 在 72B 规模下成本优势最显著，约为 API 方案的 1/4。

性能调优优先级

1. 先开 FP8/AWQ 量化（立竿见影，显存减半）
2. 再调 gpu-memory-utilization（从 0.85 开始逐步压测）
3. 最后考虑 tensor parallel（增加 GPU 成本，换延迟改善）
4. 关闭对称注意力（--disable-custom-all-reduce）在多卡场景有时反而更快

维护建议

• 模型更新时使用蓝绿部署：新实例启动完毕 → 流量切换 → 销毁旧实例
• 监控 num_requests_waiting > 0 超过 5 分钟立即扩容
• 建议用 vLLM 官方 /metrics 接口接 Prometheus，不依赖闭源监控

---

一周内可执行行动清单

Day 1-2：本地压测

• 在单卡 A100/H100 上跑通 Docker 部署
• 用 curl /metrics 观察显存和队列指标
• 记录 QPS 和 P99 延迟基准线

Day 3-4：量化选型

• 对比 BF16 vs FP8 vs AWQ 的精度差异（用 100-200 条测试集）
• 选定量化方案，调整 --gpu-memory-utilization 到最优值

Day 5-6：生产就绪

• 接入 Prometheus + Grafana 监控
• 配置健康检查（/health 端点）
• Kubernetes 部署（若有多卡资源）
• 压力测试：pytest 或 locust 模拟真实流量

Day 7：灰度切换

• 旧服务 10% 流量切到 vLLM，观察 error rate
• 确认稳定后逐步提升到 100%

---

参考来源：vLLM Production Stack Docs，SitePoint vLLM 2026 Guide，Spheron Multi-GPU Setup