DeepSeek-R1 vLLM性能基准测试:wrk压力测试详细报告
配置
- DeepSeek-R1-Distill-Qwen-14B
- NVIDIA A40
- vLLM vllm/vllm-openai:v0.8.5
- NVIDIA-SMI 560.35.03
- Driver Version: 560.35.03
- CUDA Version: 12.6
- wrk
测试方法
创建一个请求文件
cat > post.lua << 'EOF'
wrk.method = "POST"
wrk.body = '{"model":"deepseek-14b","messages":[{"role":"user","content":"写一个50字的短文"}],"max_tokens":50}'
wrk.headers["Content-Type"] = "application/json"
wrk.headers["Authorization"] = "Bearer your-api-key"
EOF
10 线程 20 并发持续测试一分钟
[root@myserver wrk-4.2.0]# ./wrk --timeout 30s -t10 -c20 -d60s -s post.lua http://10.1.2.100:8080/v1/chat/completions
Running 1m test @ http://10.1.2.100:8080/v1/chat/completions
10 threads and 20 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 3.07s 38.32ms 3.20s 66.93%
Req/Sec 1.45 3.05 10.00 87.92%
381 requests in 1.00m, 285.10KB read
Requests/sec: 6.34
Transfer/sec: 4.74KB
10 线程 100 并发持续测试一分钟
[root@myserver wrk-4.2.0]# ./wrk --timeout 30s -t10 -c100 -d60s -s post.lua http://10.1.2.100:8080/v1/chat/completions
Running 1m test @ http://10.1.2.100:8080/v1/chat/completions
10 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 3.62s 108.42ms 4.34s 95.19%
Req/Sec 20.14 22.29 89.00 88.81%
1601 requests in 1.00m, 1.17MB read
Requests/sec: 26.64
Transfer/sec: 19.97KB
100 线程 100 并发持续测试一分钟
[root@myserver wrk-4.2.0]# ./wrk --timeout 30s -t100 -c100 -d60s -s post.lua http://10.1.2.100:8080/v1/chat/completions
Running 1m test @ http://10.1.2.100:8080/v1/chat/completions
100 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 3.62s 103.22ms 4.24s 87.65%
Req/Sec 0.00 0.00 0.00 100.00%
1603 requests in 1.00m, 1.17MB read
Requests/sec: 26.67
Transfer/sec: 19.99KB
100 线程 200 并发持续测试一分钟
[root@myserver wrk-4.2.0]# ./wrk --timeout 30s -t100 -c200 -d60s -s post.lua http://10.1.2.100:8080/v1/chat/completions
Running 1m test @ http://10.1.2.100:8080/v1/chat/completions
100 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 5.27s 265.22ms 6.80s 92.77%
Req/Sec 1.33 3.25 10.00 86.58%
2200 requests in 1.00m, 1.61MB read
Requests/sec: 36.60
Transfer/sec: 27.43KB
报告解读
测试配置对比
测试 | 线程数 | 连接数 | 平均延迟 | RPS | 传输速率 |
---|---|---|---|---|---|
1 | 10 | 20 | 3.07s | 6.34 | 4.74KB/s |
2 | 10 | 100 | 3.62s | 26.64 | 19.97KB/s |
3 | 100 | 100 | 3.62s | 26.67 | 19.99KB/s |
4 | 100 | 200 | 5.27s | 36.60 | 27.43KB/s |
关键发现
性能瓶颈分析:
- 服务器在低并发(20连接)时表现最差,RPS仅6.34
- 并发数从20增加到100时,性能显著提升(RPS从6.34提升到26.64)
- 线程数从10增加到100对性能影响很小(测试2和3几乎相同)
- 连接数增加到200时,延迟明显上升(从3.62s增加到5.27s)
延迟特征:
- 所有测试的平均延迟都超过3秒,表明这是一个高延迟的服务(可能是AI推理服务)
- 延迟标准差相对较小,说明响应时间比较稳定
- 最高延迟在6.8秒以内,99%的请求延迟分布较为集中
吞吐量分析:
- 最佳吞吐量出现在200连接配置下(36.60 RPS)
- 100连接配置达到了较好的延迟/吞吐量平衡点
- 传输数据量较小,每个响应平均约750字节
建议
- 最优配置:推荐使用100连接的配置,能够在保持合理延迟的同时获得良好的吞吐量
- 容量规划:当前服务器在理想条件下最大支持约40 RPS
- 监控重点:重点关注3-6秒的响应时间是否符合业务需求
- 扩展方案:如需更高吞吐量,考虑水平扩展或优化后端处理逻辑
这个性能表现符合典型的AI推理服务特征,高延迟但相对稳定的响应时间。
服务器容量估算
基于以上性能测试报告,估算1000注册用户的服务器配置需求。
用户行为分析与容量估算
- 用户活跃度假设 对于1000注册用户,需要考虑不同的活跃度场景:
保守估算(10%同时在线):
- 同时在线用户:100人
- 峰值并发请求:假设20-30%用户同时发起请求
- 预期并发数:20-30个请求
中等估算(20%同时在线):
- 同时在线用户:200人
- 峰值并发请求:40-60个请求
高峰估算(30%同时在线):
- 同时在线用户:300人
- 峰值并发请求:60-90个请求
- 基于测试数据的性能分析
从报告数据看:
- 单台A40服务器最大RPS: 36.60(200连接时)
- 推荐配置RPS: 26.64(100连接,延迟3.62s)
- 每个请求平均响应时间: 3-5秒
服务器配置建议
方案A:保守配置(适合轻度使用)
硬件配置:
- 2台 NVIDIA A40 服务器
- 负载均衡器
- 理论峰值:70+ RPS
- 支持并发:50-60个请求
方案B:标准配置(推荐)
硬件配置:
- 3-4台 NVIDIA A40 服务器
- 负载均衡器 + 自动扩缩容
- 理论峰值:100-140 RPS
- 支持并发:80-100个请求
方案C:高性能配置(高频使用)
硬件配置:
- 5-6台 NVIDIA A40 服务器
- 高可用负载均衡
- 理论峰值:180+ RPS
- 支持并发:120-150个请求
成本与性能权衡
推荐方案B的理由:
- 考虑到AI推理的3-5秒延迟,用户不会频繁发起请求
- 预留50%性能余量应对突发流量
- 支持业务增长空间
- 成本相对合理
监控与优化建议
关键监控指标:
- 实时并发数
- 平均响应时间
- GPU利用率
- 队列长度
优化策略:
- 实现请求队列管理
- 设置用户频率限制(如每分钟最多3次请求)
- 考虑缓存常见请求结果
- 实现服务降级机制
实际部署建议
初期部署:
- 先部署2台A40服务器测试真实用户行为
- 收集1-2周的实际使用数据
- 根据真实并发模式调整配置
扩容计划:
- 当平均GPU利用率超过70%时考虑扩容
- 当95%响应时间超过8秒时必须扩容
这样的配置应该能够很好地支持1000用户的AI服务需求,同时保持良好的用户体验和合理的成本控制。