压测前的环境与参数校准在真正跑起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_sourceAIpaper