压测前的环境与参数校准
在真正跑起benchmark_serving.py之前，确保底层环境“干净”且参数对齐是成败的关键。很多团队直接上手跑分，结果发现数据波动极大，往往是因为显存预留不足或架构参数未锁定。基于 AMD Instinct MI300X 集群与 ROCm 7.x 的实践，启动 vLLM 服务时，我习惯将--gpu-memory-utilization固定在0.90。虽然理论上限能推到 0.95，但在高并发场景下，留出 10% 的显存给驱动缓冲和瞬时峰值能有效避免 OOM 崩溃。
另一个容易被忽视的细节是PYTORCH_ROCM_ARCH环境变量。编译 PyTorch 和 vLLM 时，必须明确指定为gfx942（对应 MI300 系列），否则生成的二进制文件在运行时可能因指令集不匹配而效率低下甚至报错。此外，针对长序列场景，适当调大--block-size至 32 或 64 可以减少页表管理开销，这在后续的高负载测试中对维持吞吐量稳定性有显著帮助。
构建流量模型与执行压测
为了模拟真实的业务洪峰，不能仅靠简单的单线程请求。我使用 vLLM 自带的benchmark_serving.py脚本，构造了一个混合长度的请求数据集，涵盖从短指令到长文档生成的多种场景。测试命令大致如下：
python benchmark_serving.py\--backendvllm\--dataset-name shared-gptj\--num-prompts2000\--request-rate inf\--hostlocalhost\--port8000这里的关键在于--request-rate inf，它会让客户端以最大能力发送请求，从而快速将服务端推至饱和状态，以此探测系统的极限吞吐。为了观察不同负载下的表现，我会通过外部控制脚本逐步增加并发连接数（Concurrency），从 16、32 一路加到 256 甚至更高，记录每一阶段的 RPS（每秒请求数）和 Token/s（每秒生成令牌数）。
性能曲线分析与拐点定位
当并发数较低时（例如 32 以下），AMD 集群的表现非常线性，RPS 随并发数增加而稳步上升，Token/s 也保持在高位。这是因为此时 GPU 的计算单元和显存带宽均有富余，请求无需排队。然而，随着并发数突破128，曲线开始出现微妙的变化。
在绘制性能曲线时，可以明显看到一个“拐点”：RPS 的增长斜率变缓，而平均延迟（Latency）开始指数级上升。这通常意味着显存带宽成为了瓶颈。MI300X 虽然拥有巨大的 HBM3 带宽，但在极端并发下，频繁的 KV Cache 读写依然会占满通道。此时若继续盲目增加并发，不仅无法提升吞吐，反而会导致上下文切换开销剧增，整体吞吐量甚至出现回落。
通过多次测试发现，在该配置下，系统的最佳工作点位于并发数 128 至 160 之间。超过这个范围，投入更多的并发连接只会带来边际效益递减，甚至损害稳定性。
max-num-seqs 对稳定性的调节作用
找到拐点后，如何在不扩容硬件的前提下尽可能拓宽这个“舒适区”？调整--max-num-seqs参数是一个立竿见影的手段。该参数限制了单个批次中同时处理的序列数量。
默认情况下，vLLM 会尝试塞入尽可能多的序列以最大化利用率。但在显存带宽饱和的临界点，过多的序列会导致每个序列分到的带宽资源不足，进而拉长首字延迟（TTFT）并引发超时。我在测试中将--max-num-seqs从默认的 256 下调至192。
这一调整带来了意想不到的效果：虽然理论上的最大并发处理能力略有下降，但系统在高压下的稳定性显著提升。P99 延迟的抖动幅度大幅收敛，不再出现因个别长尾请求阻塞整个批次的情况。这说明在带宽受限场景下，主动“限流”反而能保护整体吞吐的平滑性，避免因资源争抢导致的雪崩效应。
集群容量规划的实战建议
基于上述压测数据，对于需要规划集群容量的架构师，我有两点核心建议。首先，不要迷信标称的峰值 Token/s，那是在理想低负载下的数据。生产环境的容量规划应基于拐点后的稳定吞吐值，并预留 20% 的缓冲空间以应对突发流量。
其次，监控指标要从单纯的 GPU 利用率转向显存带宽利用率和KV Cache 命中率。在 AMD 平台上，利用rocm-smi结合 Prometheus exporter，可以清晰地看到带宽打满的时刻。当带宽持续维持在 90% 以上时，就是需要考虑横向扩展节点或优化模型量化策略（如切换至 FP8）的信号。通过这种精细化的压测与调优，我们能在有限的硬件资源下，挖掘出 vLLM 在 AMD 集群上的最大工程价值。
200小时GPU算力已就位，快来领取：https://marketing.csdn.net/questions/Q2604140858304426315?utm_source=AIpaper