AI Infra实战04：vLLM生产化,性能调优与压测
AI Infra实战04vLLM生产化,性能调优与压测本篇目标对vLLM推理服务进行性能压测和参数调优理解Continuous Batching的效果掌握生产环境的性能评估方法。学完本篇你将掌握推理服务的性能指标延迟、吞吐量、并发串行vs并发的性能差异vLLM关键调优参数Continuous Batching的实际效果简单压测脚本编写实操环境与第3篇相同AutoDL Tesla T416GBvLLM 0.10.1.1Qwen2-1.5B-Instruct。推理服务的核心性能指标指标含义怎么衡量Latency延迟一个请求从发出到收到响应的时间msThroughput吞吐量每秒能处理多少个请求req/sConcurrency并发同时在处理的请求数个Time to First TokenTTFT流式输出时第一个token返回的时间msTokens per SecondTPS每秒生成多少tokentokens/s它们之间的关系吞吐量 并发数 / 平均延迟GPU显存分布分析模型启动后执行nvidia-smi| Tesla T4 | 11925MiB / 15360MiB | 0% |用途占用说明模型权重~3GBQwen2-1.5Bfloat16KV Cache~9GB处理并发请求的缓存空间运行时开销~0.5GBvLLM框架本身总计~12GB占用78%显存KV Cache越大 → 能同时处理的请求越多 → 并发能力越强。压测实战测试1串行请求基准线#!/bin/bashecho开始压测10个串行请求total_time0foriin$(seq110);dostart$(date%s%N)curl-shttp://localhost:8000/v1/chat/completions\-HContent-Type: application/json\-d{ model: /root/models/Qwen2-1.5B-Instruct, messages: [{role: user, content: 什么是Docker一句话回答}], max_tokens: 50 }/dev/nullend$(date%s%N)elapsed$(((end-start)/1000000))echo请求$i:${elapsed}mstotal_time$((total_timeelapsed))doneavg$((total_time/10))echoecho总耗时:${total_time}msecho平均响应:${avg}ms结果请求 1: 591ms 请求 2: 611ms 请求 3: 352ms 请求 4: 750ms 请求 5: 734ms 请求 6: 670ms 请求 7: 526ms 请求 8: 495ms 请求 9: 493ms 请求 10: 687ms 总耗时: 5909ms 平均响应: 590ms基准线单个请求平均590ms。测试25并发#!/bin/bashecho开始并发压测5个请求同时发start$(date%s%N)foriin$(seq15);docurl-shttp://localhost:8000/v1/chat/completions\-HContent-Type: application/json\-d{ model: /root/models/Qwen2-1.5B-Instruct, messages: [{role: user, content: 什么是K8s一句话回答}], max_tokens: 50 }/dev/nulldonewaitend$(date%s%N)elapsed$(((end-start)/1000000))echoecho5个并发请求总耗时:${elapsed}msecho平均每个:$((elapsed/5))ms结果5个并发请求总耗时: 599ms 平均每个: 119ms测试320并发重度压测#!/bin/bashecho重度并发压测20个请求同时发start$(date%s%N)foriin$(seq120);docurl-shttp://localhost:8000/v1/chat/completions\-HContent-Type: application/json\-d{ model: /root/models/Qwen2-1.5B-Instruct, messages: [{role: user, content: 用一句话解释什么是微服务}], max_tokens: 50 }/dev/nulldonewaitend$(date%s%N)elapsed$(((end-start)/1000000))echoecho20个并发请求总耗时:${elapsed}msecho平均每个:$((elapsed/20))msecho吞吐量: 约$((20000/elapsed))req/s结果20个并发请求总耗时: 1129ms 平均每个: 56ms 吞吐量: 约 17 req/s压测结果对比并发数总耗时平均每个请求吞吐量GPU利用率1串行590ms590ms~1.7 req/s低5并发605ms121ms~8.3 req/s中20并发1129ms56ms~17 req/s高关键发现5并发 vs 串行总耗时几乎相同605ms vs 590ms但处理了5倍的请求。说明GPU有大量闲置能力被浪费在串行模式中。20并发总耗时只增加到1.1秒不是20×590ms11.8秒吞吐量达到17 req/s。这就是Continuous Batching的效果。vLLM的批处理原理串行请求1处理完 → 请求2处理完 → 请求3...GPU大量时间在等待 批处理请求12345同时放到GPU上计算GPU满载运行参数调优关键参数说明vllm serve /root/models/Qwen2-1.5B-Instruct\--host0.0.0.0\--port8000\--max-model-len4096\--gpu-memory-utilization0.9参数默认值调优建议说明--max-model-len模型最大值32768按需缩小限制单请求最大KV Cache占用提高可容纳的并发上限--gpu-memory-utilization0.90.85-0.95分配给vLLM的GPU显存比例--max-num-seqs256按需调整最大同时处理的序列数--tensor-parallel-size1多卡时设置张量并行多GPU--dtypeautofloat16/bfloat16模型精度T4只支持float16调优思路场景1请求都是短对话1000 token → 减小 max-model-len 到 2048-4096 → 限制单个请求最多占用的KV Cache块数 → 同一个KV Cache池可以容纳更多短请求 场景2需要长文本处理 → 保持 max-model-len 大 → 但并发能力会下降 场景3多GPU → tensor-parallel-size2两卡并行 → 大模型必须多卡才能加载调优前后对比配置max-model-len5并发耗时说明默认32768599ms大量显存预留给长上下文调优后4096605ms短对话场景足够对于短对话场景max_tokens100两者的单请求延迟差异不大。但在固定KV Cache容量下合理降低max-model-len可以限制单请求的最大缓存占用避免为业务永远用不到的超长上下文保留能力从而提高可支持的并发上限。需要注意真正的KV Cache总容量主要由模型权重、可用显存和gpu-memory-utilization共同决定并不是缩小max-model-len后凭空多出一块显存。生产环境部署建议维度建议max-model-len按业务实际需求设置不要用默认最大值健康检查定期请求/health或/v1/models超时设置客户端设30-60s超时防止长请求阻塞多实例流量大时部署多个vLLM实例前面加负载均衡监控关注GPU利用率、显存、推理延迟P99重启策略OOM时自动重启K8s的restartPolicy费用说明项目费用AutoDL T4实例0.78元/小时本篇实操时长约20分钟总费用约0.3元第34篇合计不到1元。小结本篇核心收获Continuous Batching威力巨大20并发总耗时只有串行的2倍吞吐量提升10倍GPU利用率是关键串行时GPU大量空闲高并发时才能充分利用max-model-len是核心调优参数按需设置限制单请求最大KV Cache占用提高并发上限压测方法串行→5并发→20并发递增观察拐点下一篇预告AI Infra实战05在K8s中部署vLLMHelm方式下一篇我们将学习编写vLLM的Helm ChartK8s中管理GPU推理服务健康检查和滚动更新配置模型存储方案参考链接vLLM性能调优文档vLLM Continuous Batching原理PagedAttention论文LLM推理优化综述