vLLM 的部署核心，不是把服务“拉起来”，而是把它“稳定跑起来”。
1. 本地入门：先跑通最小链路
- Linux + GPU 是最稳妥路径；
- Windows 建议 WSL + CUDA；
- macOS 可用于轻量验证。
本地阶段要完成三件事：
- 模型可加载；
- API 可调用；
- 基础延迟可接受。
2. 模型与显存
部署前要同时考虑：
- 模型参数规模；
- 精度格式（FP16/BF16/INT8/INT4）；
- KV Cache 占用；
- 并发峰值。
图1：模型与显存关系表
量化通常是优先手段：它不仅压缩模型，也给 KV Cache 和并发留空间。
3. 快速上手验证
建议验证顺序：
/v1/models正常返回；- Web UI 可正常对话；
- 长输出下吞吐不抖动。
4. 生产调优关键点
4.1 容器化与 K8s
使用 Kubernetes 做资源编排、滚动发布和弹性扩缩。
4.2 可观测性
至少接入：
/health/metrics- Prometheus + Grafana
4.3 路由与负载均衡
路由策略决定尾延迟和资源利用率，不能只看平均响应。
图2：负载与路由策略图
4.4 自动扩容
HPA 是起点，GPU 场景建议叠加队列长度与延迟等指标。
4.5 容灾
要有平台自愈 + 业务兜底两层机制，避免单点故障放大。
5. 总结
vLLM 的生产化可以概括为三层：
- 跑通（模型 + API）；
- 稳定（显存 + 路由 + 监控）；
- 规模化（扩容 + 容灾 + 运营）。
vLLM 的真正难点不是部署命令，而是生产约束：高并发、长上下文、有限显存、可观测不足、以及突发流量下的尾延迟失控。下面按工程链路给一版“可执行”的部署方法。
1. 入门阶段：先建立可重复的最小闭环
建议把本地环境固定在 Linux + CUDA + Python 3.10+。如果必须走 Windows，优先 WSL2，避免宿主和容器驱动错配。
最小闭环要包含：
- 服务启动日志可追踪；
- 健康检查可脚本化；
- 单请求与并发请求都能稳定返回。
2. 显存预算：先算清楚再选模型
线上崩溃最常见的原因不是“模型太大”，而是“模型 + KV Cache + 并发”叠加后超预算。
预算建议分三层：
- 静态占用：模型权重、运行时缓冲；
- 动态占用：KV Cache、批处理队列；
- 峰值余量：故障重试、突发流量、滚动更新。
图1：模型与显存关系表
这张图适合做部署前估算。建议以它为起点，再结合真实上下文长度做校准。
3. 量化与服务能力的关系
量化的收益不只在“省显存”，还在于：
- 提高并发上限；
- 降低 OOM 概率；
- 降低单位请求成本。
但要警惕“只看平均指标”。低比特方案必须看 p95/p99 延迟和长上下文质量退化。
4. 生产调优五件套
4.1 K8s 编排
把 vLLM 当作有状态负载看待：发布策略、资源限制、亲和性和副本拓扑要提前规划。
4.2 可观测性
推荐最小指标集：
- QPS
- 队列长度
- TTFT
- tokens/s
- p95/p99 延迟
- 错误率与超时率
4.3 路由策略
单纯轮询在混合负载下效果通常很差。更推荐基于请求长度和实例负载的权重路由。
图2：路由策略图
图中体现的是吞吐、延迟、利用率之间的典型取舍关系。
4.4 自动扩容
HPA 可做基础扩缩，但 GPU 场景最好加自定义指标（队列长度、TTFT、利用率）做联合触发。
4.5 容灾策略
容灾建议分三层：
- 平台层：实例自愈、节点替换；
- 路由层：故障摘除、降级切流；
- 业务层：超时兜底、结果回退。
5. 压测模板（可直接复用）
建议固定以下压测矩阵：
- 并发：1/4/8/16/32
- 输入长度：512/2k/8k
- 输出长度：128/512/1024
- 采样：温度与 top-p 双档位
并记录：TTFT、tokens/s、显存峰值、错误率、p95/p99。
6. 结论
当你把显存预算、路由策略、可观测和容灾放进同一个系统视角，vLLM 才会从“可用 demo”变成“可运营推理基础设施”。