vLLM Bench Serve 压测实战记录
vLLM Bench Serve 压测实战记录(Qwen2.5-7B-Instruct)
一、测试背景与目标
本次测试基于 ModelScope 免费 GPU 实例,使用 vLLM 部署 Qwen2.5-7B-Instruct 模型,利用 vllm bench serve 工具,通过控制请求速率(RPS)、最大并发数(Max Concurrency)以及Goodput SLO 标准,全方位评测模型的吞吐量、延迟以及有效产能。
二、环境与启动命令
1. 启动 vLLM 服务
# 激活虚拟环境
source vllm_learn/bin/activate
# 启动推理服务
python -m vllm.entrypoints.openai.api_server \
--model ./Qwen2.5-7B-Instruct \
--served-model-name qwen-7b \
--host 0.0.0.0 --port 8000
2. 基础压测命令(随机数据集)
vllm bench serve \
--model ./Qwen2.5-7B-Instruct \
--served-model-name qwen-7b \
--base-url http://localhost:8000 \
--dataset-name random \
--random-input-len 512 \
--random-output-len 256 \
--num-prompts 500
三、核心测试数据汇总与分析
3.1 请求速率(RPS)对系统的影响
| 测试场景 | RPS配置 | 峰值并发 | Mean TTFT | P99 TTFT | Output token吞吐 | 结果解读 |
|---|---|---|---|---|---|---|
| 极限压力 | 10 | 397 | 36,230 ms | 73,894 ms | 884 tok/s | 严重过载,排队失控,TTFT不可用 |
| 平稳压力 | 2 | 49 | 255 ms | 505 ms | 494 tok/s | 系统极其轻松,但算力未充分利用 |
🔍 关键结论:
- 系统处理能力约为 3.4 req/s。
- 当请求速率超过处理能力时,请求积压导致排队延迟飙升(从 0.25秒 -> 36秒)。
- 适用场景:模拟真实流量,寻找系统的最大安全流量阈值。
3.2 最大并发数(Max Concurrency)对系统的影响
| 测试场景 | 并发配置 | Request吞吐 | Output token吞吐 | Mean TTFT | P99 TTFT | TPOT | 结果解读 |
|---|---|---|---|---|---|---|---|
| 舒适区 | 32 | 2.57 req/s | 657 tok/s | 1,038 ms | 3,238 ms | 43.91 ms | 吞吐与延迟的完美平衡 |
| 满载区 | 64 | 3.73 req/s | 956 tok/s | 1,556 ms | 6,155 ms | 59.99 ms | 吞吐量提升,但延迟恶化 |
🔍 关键结论:
- 32 并发是“体验优先”,TTFT 和 TPOT 表现更优。
- 64 并发是“吞吐优先”,总吞吐量提升 45%,但用户等待时间变长。
- 适用场景:测试系统的极限吞吐量、寻找算力瓶颈。
3.3 Goodput(有效吞吐量)深度分析
设定业务 SLO 标准:TTFT < 3000ms 且 E2EL < 30000ms,对比 32 并发和 64 并发的 Goodput 表现。
| 测试场景 | Request吞吐 | Request Goodput | Goodput占比 | Mean TTFT | P99 TTFT | 结果解读 |
|---|---|---|---|---|---|---|
| 32并发 | 2.54 req/s | 2.51 req/s | 98.8% | 1,068 ms | 3,377 ms | 几乎100%满足SLO,质量极佳 |
| 64并发 | 3.67 req/s | 3.38 req/s | 92.1% | 1,615 ms | 6,558 ms | 吞吐提升,但约8%请求不合格 |
🔍 关键结论:
- Goodput = 在满足延迟标准下的有效请求速率。
- 32 并发下,Goodput 几乎等于 Throughput,系统健康。
- 64 并发下,虽然总吞吐更高,但约 7.9% 的请求因首字延迟超过 3 秒而“劣化”,导致 Goodput 占比下降。
- 核心权衡:32 并发适合延迟敏感型业务(如实时聊天);64 并发适合吞吐敏感型业务(如离线批量生成)。
四、核心工具参数速查表
| 参数 | 作用 | 适用场景 |
|---|---|---|
--request-rate N |
每秒发送 N 个请求(恒定速率) | 模拟真实流量、找安全流量阈值 |
--max-concurrency N |
最大同时处理的请求数(受控并发) | 测极限吞吐、找算力瓶颈、硬件对比 |
--goodput ttft:X e2el:Y |
设定 SLO 标准,计算有效吞吐量 | 衡量真实业务质量,权衡并发策略 |
五、总结与生产建议
- 最大安全流量:约 3.4 req/s(建议网关限流)。
- 最佳并发工作点:32 并发(体验与吞吐的最佳平衡点)。
- 吞吐优先点:64 并发(适合后台批量任务,可接受一定长尾延迟)。
- SLO 标准建议:在线聊天场景建议收紧至
TTFT<1s, E2EL<10s,离线场景可放宽至TTFT<5s, E2EL<60s。
测试环境:ModelScope 免费实例(24G 显存),vLLM 0.29.0,Qwen2.5-7B-Instruct。
浙公网安备 33010602011771号