vLLM（高性能大模型推理框架）部署实战：企业级高吞吐量推理服务搭建

自己跑开源模型，单机能出结果和能扛住线上流量是两回事：并发一提就排队、显存一满就 OOM、首字延迟忽高忽低，最后发现瓶颈根本不在模型上。这篇面向生产环境，把 vLLM 部署拆成准备、参数、压测、监控、上线几步，每步给出判断标准和排查顺序；想在本机快速试模型，那属于另一条路子，本篇不覆盖。

自己部署开源模型，能跑出结果和能扛住线上流量完全是两件事。并发一提就排队、显存一满就报错、首字延迟忽高忽低，排查半天发现瓶颈压根不在模型身上。这篇面向生产环境，把 vLLM 部署拆成准备、测算、参数、压测、监控、上线几步，每一步都给出判断标准和排查顺序。

先划清边界：这篇讲的是要对外提供稳定推理服务的场景。如果你只是想在本机试试某个模型能不能用，几分钟跑起来那种，属于另一条路子，本篇不覆盖。生产看的是峰值下会不会雪崩、挂了谁来看、扩容谁来做，评估口径和试模型完全不同，不要混着用。

先判断该不该用 vLLM，而不是先学怎么装

很多人上来就找安装命令，结果装完发现自己的场景根本不需要这套东西。判断顺序应该是先看业务形态，再看团队能力，最后才看技术选型。下面这张对照表可以帮你快速定位自己属于哪一类。

动手之前先把三件事定下来：模型权重从哪来、许可证能不能商用、算力是租的还是自购。许可证和模型资料到 /models 与 /stacks 核对，算力口径到 /compute/platforms 对一遍。这三件事没定就搭服务，后面返工的概率很高。

• 一个 5 人小团队最常见的误判：拿开发机上跑通过的配置直接上线，从没算过峰值并发对应多少显存和几张卡
• 另一种误判：把「模型能加载」当成「服务能扛」，加载成功只说明装得下权重，和吞吐没半点关系
• 还有一种：团队里没人能接运维，服务上线后全靠祈祷，这种情况先补人或先用托管方案更稳

装之前先算账：显存、并发、卡数

装之前先算清楚三个数：权重占用多少显存、KV 缓存占用多少、每张卡能同时承载多少请求。这三个数是互相挤压的，权重占比大，留给缓存的空间就小；缓存开得大，能跑的并发上限就低。先把这三个数的关系想明白，再谈具体配置。

1. 估权重占用根据模型规格和量化档位估算权重占用显存。量化档位越低，能塞进的并发越多，但质量损失要看你的任务类型。选档思路见 /vram-optimization-guide，具体规格到 /models/deploy 用测算页对一遍当时的数字。
2. 估缓存占用KV 缓存与并发数、输入输出长度直接相关。先统计你线上真实请求的长度分布，用分位数而不是平均值来估，不然会严重低估峰值占用。
3. 算单卡并发用剩余显存除以单请求缓存的占用，得出理论上限，再打一个安全折扣。别按理论值配，留余量给突发和碎片。
4. 定卡数与并行方式张量并行不是越多越好，卡间通信会吃掉一部分收益，超过某个卡数后吞吐增长明显变缓。这个拐点必须自己实测，不能照抄别人的配置。容量估算的结果去 /compute/sizing 与 /compute/gpus 核对当时的卡型参数，别用记忆里的数据。

装环境与第一次跑通：把变量收进配置

安装路径大致分三类：容器镜像、官方包、源码编译。生产环境优先用镜像，理由是可复现、便于回滚，不是因为性能更好。源码编译通常只在需要改代码或尝鲜特性时才用，生产上少碰。

• 第一次启动只求跑通：固定模型权重路径、固定端口、关掉任何自动更新，先把日志打到标准输出能直接看见
• 所有可调参数写进配置文件或环境变量，不要留在启动命令里，后续排查和回滚都靠它
• 跑通之后立刻做一次单请求基线，记下首字延迟和整段耗时，作为后面压测的对照起点
• 服务进程用守护方式拉起，别用前台终端跑，终端一关服务就没了这种事见得太多了

基线测速的方法和工具可以到 /tools/speed-test 看当时的用法。注意单请求基线和并发压测是两回事，前者只用来确认服务正常工作，不能拿来推算峰值能力。

吞吐调优：按现象改参数，别一次改一堆

调优最忌讳的就是一次改好几个参数，然后看整体好像快了，但你根本不知道是哪个参数起了作用，下次换个场景又白调。正确做法是按现象定位，一次只动一个参数，改完复测同一组请求。

长输入和长输出要分开测，两者瓶颈完全不同，混在一起测出来的平均值没有指导意义。每次调参都把配置和结果记下来，攒成自己团队的一张表，这张表比任何通用推荐值都有用，因为它是针对你这套卡、这个模型、这种请求分布测出来的。

压测与验收：拿数字决定能不能上线

压测必须分档，至少跑低并发、目标并发、超目标并发三档。重点看超载时的表现：是排队变慢但还能用，还是直接报错拒绝。这两种行为对业务的影响完全不同，要提前知道会是哪种。

• 四个必看指标：首字延迟、单请求总耗时、每秒完成请求数、错误率，缺一项就可能被平均值骗
• 看分位数而不是看平均，平均值会把最差的那部分请求藏起来，而那部分往往是用户在吐槽的
• 压测脚本要模拟真实请求长度分布，全用短请求测出来的吞吐数字没有参考价值
• 验收线提前定好并写下来：延迟和错误率到什么程度算通过，上线后临场放宽等于没验收

验收线定下来之后，让不同的人拿同一套脚本跑一遍，确认结果可复现。如果两次跑出来差很多，先查环境是否一致，别急着下结论说服务不稳定。

上线形态：网关、鉴权、限流与灰度

推理服务前面要有一层网关，做鉴权、限流、请求排队。业务方拿到的地址不应该直连推理进程，否则一个写错的脚本就能把整个服务打满。网关层的鉴权和灰度思路可以参考 /api-gateway-auth-rollout，那里讲的是部署节奏和权限划分。

1. 接入鉴权给每个调用方单独的凭证，不要共用一把钥匙。出问题时能定位到具体是谁，也能单独吊销不影响别人。
2. 设定限流阈值阈值要低于压测通过线，留出余量。超过阈值的行为要明确：是排队、降级还是直接拒绝，别让它自己随机发生。
3. 灰度放量先切一小部分流量，观察一个完整业务周期再逐步放大。一个完整周期才能覆盖高峰期和低谷期的真实表现。
4. 演练回退上线前把回退方案实际走一遍，确认能回到上一个正常版本。没演练过的回退方案等于没有。

监控与排障：出问题时先看哪一层

监控项缺失的后果是出事时只能瞎猜。必备的至少包括：GPU 利用率与显存、队列长度、首字延迟分位数、错误码分布。这四项覆盖了大部分常见故障的入口，缺哪项，出事时就得现场加。

流量层

先看是不是流量突增，对比历史同时段和当前请求量

资源层

再看显存和队列，判断是资源打满还是排队积压

实例层

接着看单实例是否健康，有没有实例已经无响应但还挂在负载上

模型层

最后才怀疑模型本身，前面几层都排除了再看模型是不是被换了或损坏了

OOM 和延迟暴涨的处理方向不同：前者先降并发上限，后者先看队列长度和输入长度分布。别用同一个动作应付两种现象，那大概率会把问题从一种变成另一种。另外，改参数前务必复制一份「上次好好的配置」快照，这是最快的回滚手段。

上线前检查清单

把下面这张清单当成上线前的最后一道门。每一项都要有明确的负责人和确认记录，口头说过不算。

几个容易踩的误判

• 把单卡跑得动当成能扛住并发，跑得动只说明装得下权重，和吞吐没有任何关系
• 拿别家的参数当自己的默认值，卡型、模型、请求长度分布任意一项不同，最优参数就不同
• 只在白天测，夜间或业务高峰的流量形态不一样，至少覆盖一个完整周期再下结论
• 认为加卡就能解决延迟，如果瓶颈在调度或输入长度分布，加卡只是把排队往后推
• 验收线定得太松，上线后发现问题又临时放宽，等于一开始就没有验收标准

这些误判的共同点是：把某一个观察到的现象直接当成结论，跳过了验证环节。生产环境的判断要尽量基于自己测出来的数字，而不是别人的经验值。