一、vLLM性能压测概述
大家好，我是你们的老朋友。今天咱们聊聊vLLM性能压测这件事。
说实话，我见过太多团队把模型部署上去就完事了。结果呢？线上用户一多，响应慢得像蜗牛，显存直接爆掉。嗯，这就是没做压测的后果。
我个人习惯，在模型上线前，至少做三轮压测。为什么？因为压测能帮你回答三个灵魂拷问：
- 这模型到底能扛多少并发？
- 用户等多久才能看到第一个字？
- 显存会不会在半夜偷偷爆掉？
说白了，压测就是给你的服务做一次「压力体检」。你想想看，人每年都要体检，服务凭什么不检？
1.1 为什么要做压测？
我在项目中遇到过一件事，印象特别深。有一次给客户部署一个70B的模型，对方说「我们日活也就几万人」。结果上线第一天，并发请求一上来，服务直接OOM。后来一查，原来他们说的「几万人」是同时在线——这压测没做，差点背锅。
压测的核心价值，我总结为三点：
- 验证容量规划——你买的A100够不够用？别等用户骂了才加机器
- 发现瓶颈点——是显存不够？还是CPU计算卡脖子？还是网络带宽拖后腿？
- 建立基准线——优化前和优化后，到底快了多少？没有数据，你拿什么说服老板？
重要提醒：压测不是一次性工作。每次模型更新、框架升级、硬件变更，都应该重新跑一遍。我曾经吃过这个亏——升级了vLLM版本，以为兼容性没问题，结果吞吐量掉了30%。
1.2 压测的核心目标
压测到底看什么？三个指标，一个都不能少。
| 指标 | 含义 | 我关注的点 |
|---|---|---|
| 吞吐量 | 每秒处理的请求数或token数 | QPS和TPS都要看，别只看一个 |
| 延迟 | 从请求发出到收到响应的耗时 | 重点关注P50、P95、P99，平均值会骗人 |
| 显存 | GPU显存的占用和峰值 | 看峰值，更要看有没有内存泄漏 |
为什么会这样？我解释一下。
吞吐量决定了你的服务能服务多少人。但注意，吞吐量高不代表体验好。我见过一个方案，吞吐量刷到很高，但每个请求要等30秒才出第一个字——这谁受得了？
延迟分两种：TTFT（首token延迟）和TPOT（每个后续token的延迟）。前者影响用户的第一印象，后者影响整体的流畅度。我个人习惯，TTFT控制在2秒以内，TPOT控制在50ms以内。
显存是vLLM的生命线。vLLM虽然用了PagedAttention来优化显存，但如果你压测时发现显存持续增长不回落——嗯，那大概率有泄漏。我曾经排查过一个案例，跑了12小时后显存从40G涨到78G，最后发现是某个版本的缓存没清理。
小技巧：压测时用 nvidia-smi -l 1 实时监控显存。我习惯同时开一个窗口跑压测，另一个窗口盯着显存曲线。看到异常波动，立刻停掉排查。
1.3 压测在整个部署流程中的位置
很多新手把压测当成「上线前的最后一步」。其实不对。压测应该贯穿整个部署流程。
我画了一张图，帮你理清位置关系：
从图上你能看到，压测在部署流程中的位置很关键：
- 模型训练/微调后——先别急着部署，跑一轮压测看看基础性能
- 模型转换/量化后——精度变了，性能也会变，必须重新压
- vLLM配置调整后——改了max_num_seqs、gpu_memory_utilization这些参数，压测验证效果
- 压测发现问题——返回去调整配置或模型，形成闭环
我记得有一次，一个团队在模型微调后直接上线，结果TTFT从1.5秒飙到了4秒。后来一查，是微调时增加了attention层的计算量，但vLLM的配置没跟着调。如果当时做了压测，这个问题在测试环境就能发现。
避坑指南：我曾经犯过一个错误——在压测时只测了单并发。结果上线后并发一上来，显存直接炸了。后来我学乖了：压测一定要覆盖低并发、中并发、高并发三种场景。低并发看延迟，高并发看吞吐和显存。
总结一下这一节的核心：
- 压测不是可选项，是必选项
- 三个核心指标：吞吐量、延迟、显存，缺一不可
- 压测要贯穿整个部署流程，不是一次性工作
- 发现问题后要形成「压测→调优→再压测」的闭环
好了，这一章就到这里。记住一句话：没有压测的上线，就是裸奔。咱们下一章见。