最近要把一个 Qwen2-72B 的模型对外提供推理服务，本地那张 3090 直接劝退——72B 哪怕 4bit 量化也得 40G+ 显存，更别提并发了。折腾了一圈 vLLM，把部署流程和几个显存优化的坑记下来，给同样要上生产的人参考。

一、环境

推理要的是大显存 + 高带宽，我临时开了张云 GPU 顶上（用的 oriGPU 的 H100，80G 显存，origpu.com，ssh 上去驱动和 CUDA 都现成的，省得自己配）。

ssh user@gpu.origpu.com
nvidia-smi
# | GPU  Name        | Memory-Usage      |
# |   0  NVIDIA H100 | 0MiB / 81920MiB   |

二、装 vLLM

pip install vllm
# 验证
python -c "import vllm; print(vllm.__version__)"

建议用干净虚拟环境，别和训练那套依赖混一起，我第一次混装直接 import 冲突。

三、启动推理服务

72B 用单卡 H100（80G）+ 4bit 量化刚好：

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2-72B-Instruct \
  --quantization awq \
  --tensor-parallel-size 1 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --port 8000

启动后 OpenAI 兼容接口直接能用：

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2-72B-Instruct",
    "messages": [{"role":"user","content":"你好"}]
  }'

四、显存优化踩坑（重点）

1. --max-model-len 别拍脑袋设 32k。KV cache 随 context 长度平方级吃显存，我一开始设 32768，直接 OOM；降到 8192 才稳住。
2. --gpu-memory-utilization 别拉满。设 0.95 看着省卡，实际上传大 batch 就爆；0.90 留点余量更稳。
3. 量化先试 AWQ。72B 上 AWQ 比 GPTQ 在 H100 上吞吐高约 15%，精度损失肉眼难分。
4. 并发靠 --max-num-seqs。默认 256 太激进，我实际压到 128，P99 延迟反而更好。

压测结果（单卡 H100，4bit，max-len 8192）：

• 并发 64，吞吐约 1100 tokens/s
• 首 token 延迟 P99 ≈ 380ms

五、顺手记笔账

推理服务不是 7×24 都忙，我只在白天高峰拉起实例，晚上释放。用的这家长按分钟计费，跑完就关，一周算下来比常驻包月省了一截——对小流量服务挺划算，不用为闲置显存买单。

六、小结

vLLM 部署大模型不难，难的是把显存和延迟压到生产可用。关键就三件事：量化选对、context 别贪长、并发留余量。

你们部署时还踩过什么坑？评论区聊聊，互相排雷 👋