并发压力测试，vLLM 在高负载下的吞吐量评估

压测前的环境与参数校准在 AMD Instinct GPU 上跑通 vLLM 只是第一步真正考验工程能力的环节在于高并发下的吞吐量评估。很多开发者在本地单请求测试时觉得延迟尚可一旦接入真实流量系统表现却大相径庭。这通常是因为忽略了显存带宽饱和与上下文切换带来的非线性损耗。基于 ROCm 7.x 环境我们需要利用benchmark_serving.py脚本模拟真实的高压场景通过量化数据来寻找系统的性能拐点。在启动压测前必须确保服务端的参数配置已经针对多并发场景做过初步调优。特别是--max-num-seqs参数它直接决定了单个批次Batch中允许同时存在的序列数量。如果该值设置过大虽然理论上能提升并行度但在显存带宽有限的情况下会导致每个序列分到的计算资源被稀释反而增加排队等待时间若设置过小则无法吃满 GPU 的算力。建议初始值设为显卡数量的 4 到 8 倍后续根据压测结果动态调整。同时务必确认gpu-memory-utilization设置在 0.90 至 0.92 之间为 KV Cache 的动态增长留出缓冲避免在高负载下因瞬间显存峰值触发 OOM 导致服务崩溃。构建高压流量模拟场景vLLM 官方提供的benchmark_serving.py是进行压力测试的核心工具。它不仅能发送请求还能精确控制并发度和请求速率模拟出接近生产环境的流量特征。以下是一个典型的压测命令示例旨在评估系统在 32 并发下的表现python benchmark_serving.py\--backendvllm\--dataset-name sharegpt\--request-rate16\--num-prompts1000\--concurrency32\--model/path/to/your/model\--tokenizer/path/to/your/tokenizer\--host0.0.0.0\--port8000在这个命令中--concurrency是关键变量它模拟了同时发起请求的用户数。而--request-rate则控制了请求到达的频率每秒多少个。在实际操作中不要一次性将并发拉满应采用阶梯式递增的策略。例如从并发数 4 开始逐步增加到 8、16、32、64甚至更高。每次测试保持运行足够长的时间如 3-5 分钟以确保统计数据具有代表性消除冷启动或瞬时波动的影响。对于数据集的选择sharegpt包含了真实的对话长度分布比随机生成的数据更能反映实际业务中的显存占用情况。如果你的业务场景主要是长文本生成还可以自定义数据集增加输入输出的 token 长度以此观察长上下文对显存带宽的压力。解读核心指标与非线性波动压测结束后脚本会输出一份详细的统计报告。我们最需要关注的两个核心指标是RPS (Requests Per Second)和Token/s (每秒生成 Token 数)。在低并发阶段如并发数 8你通常会看到 RPS 和 Token/s 随着并发数的增加呈线性上升。这是因为此时 GPU 算力尚未饱和增加并发能有效利用空闲的计算单元。然而当并发数超过某个阈值后曲线往往会发生“弯折”出现明显的非线性波动RPS 增长停滞甚至下降而平均延迟Latency却急剧飙升。这种现象背后的原因主要有两点显存带宽饱和AMD MI300X 等卡虽然拥有巨大的 HBM3 带宽但在高并发下频繁的 KV Cache 读写操作会迅速占满带宽通道。一旦带宽成为瓶颈GPU 的计算单元SM就必须等待数据导致算力闲置。上下文切换开销当max-num-seqs设置过大调度器需要在过多的序列间进行切换。这种切换不仅消耗 CPU 资源还会导致 GPU 上的指令流水线频繁刷新降低了整体执行效率。此外还需留意TTFT (Time To First Token)的变化。如果在高并发下 TTFT 显著增加说明请求在队列中的等待时间过长这通常是服务端处理能力达到上限的信号。寻找性能拐点与容量规划面对吞吐量的非线性波动盲目增加并发数毫无意义关键在于找到系统的“甜蜜点”Sweet Spot。这个点通常位于线性增长的末端即吞吐量接近最大值但延迟尚未失控的区间。调整--max-num-seqs是寻找这一拐点的有效手段。你可以尝试在 vLLM 启动时修改该参数重新运行上述压测流程。若发现高并发下延迟极高但 GPU 利用率不高尝试减小max-num-seqs减少批次内的序列竞争降低调度开销。若 GPU 算力未跑满且 RPS 较低可适当增大该值以挖掘潜在的并行能力。通过多轮测试将不同并发数下的 RPS 和平均延迟绘制成坐标图横轴为并发数纵轴分别为吞吐量和延迟。你会得到一条典型的“容量曲线”。曲线的最高点对应的并发数就是当前硬件配置下的最佳工作负载。基于这条曲线我们可以制定更科学的限流策略。例如如果测试表明并发数超过 48 后延迟不可接受那么在生产环境的网关层就可以将最大并发限制在 40 左右预留 20% 的安全缓冲以应对流量突发。这种基于实测数据的决策远比凭经验估算要可靠得多也能最大程度地发挥 AMD GPU 在 ROCm 7.x 生态下的推理性能。200小时GPU算力已就位快来领取https://marketing.csdn.net/questions/Q2604140858304426315?utm_sourceAIpaper