并发压力测试，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）却急剧飙升。

这种现象背后的原因主要有两点：

1. 显存带宽饱和：AMD MI300X 等卡虽然拥有巨大的 HBM3 带宽，但在高并发下，频繁的 KV Cache 读写操作会迅速占满带宽通道。一旦带宽成为瓶颈，GPU 的计算单元（SM）就必须等待数据，导致算力闲置。
2. 上下文切换开销：当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_source=AIpaper