生产环境部署架构：单机多卡、多机分布式、负载均衡与高可用
聊到生产环境的vLLM部署，我见过不少团队上来就怼一台8卡A100，觉得“显存够大，模型能塞进去就行”。结果呢？线上流量一上来，单机扛不住，推理延迟飙升，甚至直接OOM。说白了，部署架构这件事，不是把模型跑起来就完事了，你得考虑怎么让它跑得稳、跑得快、还能扛得住突发流量。
我个人习惯把生产部署拆成四个层次来看：单机多卡是基础，多机分布式是扩展，负载均衡是调度，高可用是兜底。咱们一个一个聊。
一、单机多卡部署：把一张卡的活分给多张卡
单机多卡，说白了就是一台机器上插了多张GPU，比如4卡、8卡。vLLM天然支持张量并行（Tensor Parallelism）和流水线并行（Pipeline Parallelism）。
- 张量并行：把一层网络的计算切分到多张卡上，适合大模型单层计算量大的场景。我建议小模型（比如7B以下）用TP=1或2，大模型（比如70B）用TP=4或8。
- 流水线并行：把不同层分配到不同卡上，适合模型层数特别多的情况。但要注意，流水线并行会有气泡（bubble），利用率不如张量并行高。
我的经验：在单机8卡A100上部署LLaMA-70B，我试过TP=8，显存占用约140GB，推理延迟在200ms左右。但如果用TP=4+PP=2，延迟会高一些，因为卡间通信多了。所以，能全用张量并行就别混用。
避坑指南：我曾经遇到过单机多卡时，NVLink带宽不够导致通信成为瓶颈。后来我改用H800（NVLink带宽更高），延迟直接降了30%。如果你的卡之间没有NVLink，建议TP值不要超过4。
二、多机分布式部署：一台不够，那就上多台
当单机显存不够，或者单机吞吐量满足不了业务需求时，就得考虑多机分布式了。vLLM支持两种分布式模式：数据并行和模型并行。
- 数据并行：每台机器上都部署一份完整的模型副本，各自处理不同的请求。适合模型能塞进单机显存，但并发量大的场景。
- 模型并行：把模型切分到多台机器上，每台机器只负责一部分。适合超大模型（比如175B以上），单机放不下。
我个人更推荐数据并行，因为实现简单，而且扩展性好。你想想看，加一台机器，吞吐量就翻一倍，多爽。但要注意，数据并行需要配合负载均衡，不然流量全打到一台机器上，其他机器闲着。
多机部署的通信问题：多机之间通常用RDMA（比如InfiniBand）或者RoCE v2。我建议至少用100Gbps的网络，否则通信延迟会拖垮推理速度。我在项目中遇到过用25Gbps网卡跑多机，结果通信占了总时间的40%，后来换成100Gbps才降到10%。
三、负载均衡策略：别让一台机器累死
负载均衡，说白了就是“把请求均匀地分给后端的每一台vLLM实例”。常见的方案有：
- 轮询（Round Robin）：简单粗暴，但容易出问题。比如某台机器正在处理长文本，轮询还是给它发请求，结果它处理不过来。
- 最少连接数（Least Connections）：根据当前正在处理的请求数来分配。我个人比较推荐这个，因为它能动态感知后端负载。
- 基于队列深度的调度：vLLM内部有请求队列，负载均衡器可以读取队列深度，把请求发给队列最短的实例。这个最精准，但实现起来稍微复杂一点。
我的习惯：我一般用Nginx或者HAProxy做七层负载均衡，配合健康检查。如果后端实例挂了，自动摘掉。另外，我会在vLLM实例前面加一层Redis或者etcd来做服务发现，这样扩缩容时不用手动改配置。
四、高可用架构设计：别让单点故障搞崩你
高可用，说白了就是“就算某个组件挂了，系统还能继续服务”。我见过最惨的情况是：负载均衡器挂了，整个推理服务全崩。所以，高可用要从多个层面来设计。
| 层面 | 常见故障 | 解决方案 |
|---|---|---|
| GPU节点 | 显卡故障、显存ECC错误 | 多副本部署，故障自动摘除 |
| 网络 | 网卡故障、交换机宕机 | 双网卡绑定、多路径冗余 |
| 负载均衡器 | 进程崩溃、机器宕机 | 主备模式（Keepalived + VIP） |
| 模型服务 | OOM、推理超时 | 自动重启、熔断降级 |
警告：我曾经遇到过vLLM实例因为显存泄漏导致OOM，结果整个节点挂了。后来我加了--max-model-len限制最大输入长度，并且用watchdog定时检查显存使用率，超过90%就自动重启。嗯，这招挺管用的。
五、整体架构图：一张图看懂所有
下面这张SVG图，是我自己画的生产环境vLLM部署架构。你可以看到从客户端到负载均衡，再到多机多卡实例，最后到存储和监控的完整链路。
六、避坑与最佳实践
最后，我总结几个我在生产环境中踩过的坑，以及对应的最佳实践：
- 显存碎片化：vLLM虽然用了PagedAttention，但长时间运行后显存还是会碎。我建议每天凌晨低峰期重启一次实例，或者用
--gpu-memory-utilization 0.9留点余量。 - 请求超时：长文本生成可能耗时几十秒，负载均衡器容易超时。我一般把超时时间设成60秒，并且用异步回调的方式返回结果。
- 模型热更新：生产环境不能停服更新模型。我习惯用蓝绿部署，先启动新版本实例，等流量切换完再停旧版本。
- 监控告警：别等用户投诉了才发现服务挂了。我建议监控GPU利用率、显存使用率、请求延迟P99、错误率这四个指标，超过阈值就告警。
一个小技巧：我曾经在负载均衡层加了rate limiting，防止突发流量把后端打爆。比如每个客户端IP每秒最多100个请求，超出的直接返回429。这样后端实例不会因为流量洪峰而雪崩。
好了，关于生产环境部署架构，我就聊这么多。记住，没有银弹，每个方案都要根据你的业务场景来权衡。单机多卡够用就别上多机，负载均衡简单够用就别搞太复杂。嗯，就这样。