高并发下的表现,Instinct GPU 上 vLLM 压力测试数据分析
压力测试实战:用 benchmark_serving.py 摸清 Instinct GPU 底牌
部署好 vLLM 服务只是第一步,真正决定生产环境稳定性的,是搞清楚它在高并发下的“脾气”。很多开发者在本地跑通 Demo 后就直接上线,结果流量一来,延迟飙升甚至服务崩溃。在 AMD Instinct GPU 上,由于内存架构和互联拓扑的特殊性,这种性能拐点往往来得比 NVIDIA 平台更突然。今天我们就基于 benchmark_serving.py 工具,完整复盘一次高并发压力测试,看看如何科学地评估系统极限。
关键指标定义与业务映射
在开始跑分之前,必须统一“度量衡”。vLLM 的压力测试主要关注三个核心指标,它们分别对应着用户体验的不同维度:
- TTFT (Time To First Token):首字延迟。指从发送请求到接收到第一个生成 token 的时间。对于聊天机器人或实时交互场景,这是用户感知最明显的指标。如果 TTFT 超过 500ms,用户就会觉得“卡”。
- TPS (Tokens Per Second):每秒生成 token 数。反映了模型的生成速度,决定了长文本输出的流畅度。
- RPS (Requests Per Second):每秒请求数。代表系统的吞吐量,直接关联到服务器能支撑多少并发用户。
在 Instinct GPU 上,我们不仅要看绝对数值,更要观察这些指标随负载变化的趋势。通常使用 vLLM 自带的 benchmarks/benchmark_serving.py 脚本进行测试,它支持模拟 ShareGPT 等真实数据集的流量模式。
并发压力测试全过程
假设我们已经启动了 Llama 3 8B 模型,配置了双卡张量并行(--tensor-parallel-size 2)。接下来使用以下命令发起不同梯度的并发测试:
python benchmarks/benchmark_serving.py \
--backend vllm \
--dataset-name sharegpt \
--request-rate 4 \
--num-prompts 200 \
--output-file result_rate_4.json
我们将 --request-rate 分别从 2、4、8、16 逐步调高,模拟从空闲到拥塞的过程。测试发现,当请求速率较低时,RPS 随并发数线性增长,TTFT 保持在 200ms 左右,表现非常平稳。然而,当并发数突破某个临界点(例如 QPS=12)后,曲线开始出现明显的“膝点”:RPS 增长停滞甚至回落,而 TTFT 则呈指数级上升,瞬间突破 2s。
这种现象在 Instinct MI250/MI300 系列上尤为典型。究其原因,主要是显存带宽饱和与上下文切换开销的双重制约。vLLM 的 PagedAttention 机制虽然高效,但在极高并发下,频繁的 KV Cache 换入换出会占满 HBM 带宽,导致计算单元等待数据。同时,过多的活跃序列迫使调度器花费更多时间在 CPU 上进行上下文管理,而非 GPU 计算。
优化策略:调整 max-num-seqs
面对吞吐量下降,最直接的手段是限制单批次处理的序列数量。通过添加 --max-num-seqs 参数,我们可以强制 vLLM 拒绝部分排队请求,从而保护正在处理的请求不受干扰。
python -m vllm.entrypoints.api_server \
--model meta-llama/Meta-Llama-3-8B-Instruct \
--tensor-parallel-size 2 \
--max-num-seqs 128 \
--gpu-memory-utilization 0.9
经过多轮测试,我们发现将 --max-num-seqs 设置为 128 时,系统在高压下的 TTFT 波动最小,整体吞吐量反而比默认配置(通常更大)高出 15% 左右。这说明在 ROCm 环境下,适当“做减法”限制并发深度,能有效避免资源争抢带来的性能崩塌。
测试报告模板与自定义脚本思路
为了便于团队复盘,建议建立标准化的测试报告。一份合格的报告应包含以下要素:
| 配置项 | 详情 |
|---|---|
| 硬件环境 | 2x AMD Instinct MI250X, ROCm 7.x, Ubuntu 22.04 |
| 模型参数 | Llama-3-8B-Instruct, FP16, TP=2 |
| 测试工具 | benchmark_serving.py (ShareGPT 数据集) |
| 并发策略 | Request Rate: 2 ~ 16, Max Num Seqs: 128 |
测试结果摘要:
| 请求速率 (QPS) | 平均 TTFT (ms) | 平均 TPS | 成功 RPS | 错误率 |
|---|---|---|---|---|
| 4 | 210 | 45.2 | 3.9 | 0% |
| 8 | 245 | 44.8 | 7.8 | 0% |
| 12 | 380 | 43.5 | 11.2 | 0.5% |
| 16 | 1200+ | 38.1 | 10.5 | 4.2% |
除了使用官方脚本,你还可以编写自定义脚本来模拟更复杂的业务场景。例如,利用 Python 的 asyncio 和 aiohttp 库,构造具有“突发流量”特征的请求流,或者模拟不同长度的输入输出分布。核心思路是维护一个动态的请求队列,按照泊松分布发送请求,并实时记录每个请求的生命周期日志。这样不仅能测出系统的理论上限,还能发现长尾延迟的具体成因,为后续的自动扩缩容策略提供坚实的数据支撑。
200小时GPU算力已就位,快来领取:https://marketing.csdn.net/questions/Q2604140858304426315?utm_source=AIpaper

DAMO开发者矩阵,由阿里巴巴达摩院和中国互联网协会联合发起,致力于探讨最前沿的技术趋势与应用成果,搭建高质量的交流与分享平台,推动技术创新与产业应用链接,围绕“人工智能与新型计算”构建开放共享的开发者生态。
更多推荐

所有评论(0)