vLLM的并发数调整核心在于平衡GPU显存利用率与请求延迟，通常通过调整max_num_seqs、max_batch_size及gpu_memory_utilization参数，结合业务对吞吐量和延迟的具体需求进行动态调优。
在大规模部署大语言模型时,很多工程师容易陷入一个误区，认为并发数越高越好，或者盲目追求极致的吞吐量，并发配置是一个典型的“不可能三角”博弈：高并发带来高吞吐，但往往伴随高延迟和显存溢出风险；低并发保证低延迟，却浪费了昂贵的GPU算力，业内专家指出，合理的并发策略必须基于具体的硬件资源和业务场景进行精细化匹配，而非套用通用模板。
![[Agentic RL] [Inference] 05 vllm 参数配置、显存分析与性能调优 max_num_batched_tokens](https://i2.hdslb.com/bfs/archive/09f3cb90ad869fd37f8a0a6baa289827dbe84e10.jpg)
理解vLLM并发控制的核心参数
要掌握vLLM的并发能力,首先得读懂它背后的三个关键开关，这些参数直接决定了vLLM如何在显存、计算资源和请求队列之间分配资源。
显存利用率与批处理上限
gpu_memory_utilization是vLLM的基石，它定义了vLLM启动时预留多少比例的GPU显存用于KV Cache（键值缓存）和模型权重。
- 默认值：通常为0.9，即预留90%的显存。
- 调整逻辑：如果设置为1.0，vLLM会尝试占用所有显存，这可能导致系统级OOM（内存溢出）或与其他进程冲突，建议设置为0.85-0.95之间，留出5-15%给操作系统和其他必要服务。
max_num_seqs和max_batch_size则是控制实际并发量的直接杠杆。
max_batch_size：限制每个调度周期内处理的最大请求数。max_num_seqs：限制调度器中允许存在的最大序列数（包括正在生成的Token）。- 关系：
max_num_seqs通常大于等于max_batch_size，因为它包含了正在生成中但尚未完成的请求。
连续批处理机制的影响
vLLM的核心优势在于Continuous Batching（连续批处理），这意味着请求不需要等待整个批次完成才能被处理，而是只要显存有空闲，新的请求就可以插入，这种机制使得并发数的调整不再是简单的“开或关”，而是一个动态的资源分配过程。
不同场景下的并发数调优策略
不同的业务场景对并发的需求截然不同,有的场景追求极致的响应速度，有的场景则追求最大的吞吐量。
低延迟交互场景：客服与实时对话
在智能客服或实时对话场景中,用户无法忍受超过200ms的等待，高并发会导致排队现象，增加首字延迟（TTFT）。
- 策略：降低
max_batch_size，提高gpu_memory_utilization的灵活性。 - 具体操作：
- 将
max_batch_size设置为较小值（如16或32）。 - 启用
enable_chunked_prefill，允许预填充阶段分块处理，减少显存碎片。 - 监控TTFT指标,确保P99延迟在可接受范围内。
- 将
- 效果：牺牲部分吞吐量，换取更稳定的低延迟体验。
高吞吐量批量场景：内容生成与数据分析
在批量生成报告、代码补全或数据分析场景中，用户更关心单位时间内处理多少请求，而非单个请求的响应速度。
- 策略：最大化
max_batch_size和max_num_seqs。 - 具体操作：
- 将
max_batch_size设置为GPU显存允许的最大值（如256或512，取决于模型大小）。 - 适当降低
gpu_memory_utilization至0.85，避免显存抖动。 - 禁用
enable_chunked_prefill，因为批量处理对预填充的连续性要求不高。
- 将
- 效果：吞吐量提升显著，但单个请求的延迟可能增加。
混合负载场景：通用API服务
大多数生产环境面临的是混合负载,既有实时对话，也有批量任务。
- 策略：采用动态批处理与优先级队列。
- 具体操作：
- 设置中等大小的
max_batch_size（如64或128）。 - 启用
priority_queue，为实时请求分配更高优先级。 - 监控GPU利用率,若利用率持续低于70%，可适当提高并发参数；若超过95%，则降低并发参数以避免OOM。
- 设置中等大小的
实操调优步骤与验证方法
理论再好,不如动手实践，以下是具体的调优路径，帮助你找到最适合你业务的并发配置。
第一步：基准测试与资源摸底
在调整任何参数之前,先了解你的硬件底线。
- 使用
nvidia-smi查看GPU显存总量和当前使用情况。 - 运行一个简单的基准测试脚本,测量不同
max_batch_size下的吞吐量和延迟。 - 记录每个参数组合下的GPU显存占用曲线,识别显存瓶颈。
第二步：逐步调整与监控
不要一次性大幅修改参数,应采用增量调整法。
- 初始配置：使用vLLM默认参数启动服务。
- 监控工具：使用Prometheus + Grafana监控vLLM指标，重点关注
vllm:num_requests_running、vllm:gpu_cache_usage_perc和vllm:time_to_first_token_seconds。 - 调整循环：
- 增加
max_batch_size，观察GPU利用率是否上升，延迟是否可控。 - 若延迟飙升,适当降低
max_batch_size或增加gpu_memory_utilization的预留空间。 - 若GPU利用率不足,继续增加
max_batch_size。
- 增加
第三步：压力测试与稳定性验证
在找到初步最优解后,进行长时间的压力测试。
- 使用
locust或wrk模拟高并发请求，持续时间不少于1小时。 - 观察服务是否出现OOM、重启或性能衰减。
- 检查日志中的错误信息,特别是与显存分配相关的警告。
常见问题与故障排查
如何避免显存溢出导致的OOM？
OOM是vLLM最常见的故障,主要原因包括KV Cache增长过快或批处理大小设置过大。
- 解决方案：
- 降低
gpu_memory_utilization至0.85以下。 - 启用
enable_chunked_prefill，限制预填充阶段的显存占用。 - 监控
vllm:gpu_cache_usage_perc，若接近100%，立即降低并发参数。
- 降低
并发数增加但吞吐量未提升怎么办？
有时增加并发数并未带来预期的吞吐量提升,反而增加了延迟。
- 原因分析：可能是CPU瓶颈或网络IO瓶颈，而非GPU瓶颈。
- 解决方案：
- 检查CPU利用率,若CPU满载，考虑增加Worker数量或优化数据预处理。
- 检查网络带宽,确保客户端与服务端之间的通信无瓶颈。
- 使用
perf工具分析热点函数，定位性能瓶颈。
vLLM并发数怎么调：Q&A模块
vLLM并发数怎么调才能兼顾低延迟和高吞吐？
无法同时达到极致的低延迟和高吞吐,需根据业务优先级取舍，对于实时性要求高的场景，优先保证低延迟，设置较小的max_batch_size并启用优先级队列；对于批量处理场景，优先保证高吞吐，设置较大的max_batch_size并最大化GPU利用率，通过监控TTFT和TPS指标，动态调整参数，找到平衡点。
vLLM并发数设置过高会导致什么后果？
设置过高会导致显存溢出（OOM）、请求排队时间增加、首字延迟（TTFT）飙升，甚至服务崩溃，过高的并发可能导致GPU利用率波动剧烈，影响服务稳定性，建议通过逐步增加并发数并监控资源使用情况，找到稳定运行的最大并发阈值。
vLLM并发数怎么调适合小规模GPU集群？
小规模集群资源有限,建议采用保守策略，设置gpu_memory_utilization为0.8，max_batch_size为32-64，并启用enable_chunked_prefill以优化显存使用，通过压测确定最佳配置，避免资源浪费和服务不稳定。
首发原创文章，作者：世雄 - 原生数据库架构专家，如若转载，请注明出处：https://idctop.com/article/400937.html
