当前位置：首页 > news >正文

高并发压力测试，vLLM 在 AMD Instinct GPU 上的极限吞吐量揭秘

news 2026/6/26 5:38:29

压测实战：用 benchmark_serving.py 摸清 AMD GPU 的吞吐底牌

作为架构师，我们在规划大模型推理集群时，最头疼的往往不是“能不能跑起来”，而是“到底能扛多少并发”。特别是在 AMD Instinct GPU 这种新硬件平台上，官方文档给出的理论峰值往往过于理想化。真正的生产容量，必须通过高强度的压力测试才能摸清楚。最近我在 DevCloud 上基于 ROCm 7.x 部署了 vLLM 服务，并利用benchmark_serving.py脚本进行了一场从低负载到极限并发的全链路压测，结果发现了一些值得注意的性能拐点。

构建高并发测试场景

压测的第一步是还原真实流量。我并没有使用简单的单线程请求，而是直接调用 vLLM 自带的benchmark_serving.py工具。这个脚本的强大之处在于它能模拟真实的请求分布，支持设置并发数（concurrency）、请求速率以及输入输出长度分布。

为了贴近生产环境，我选取了 Llama 3.1 8B 和 70B 两个典型模型，分别对应轻量级对话和复杂逻辑推理场景。测试数据集采用了 ShareGPT 的真实对话片段，确保输入长度（Prompt Length）和输出长度（Completion Length）具有随机性和长尾特征。在 AMD MI300X 环境下，我重点观察了三个核心指标的变化曲线：RPS（每秒请求数）、Token/s（系统总吞吐量）以及TTFT（首字延迟）。

测试命令示例如下，这里我们模拟了从 1 到 128 的并发梯度：

python benchmark_serving.py \ --backend vllm \ --dataset-name sharegpt \ --request-rate inf \ --num-prompts 2000 \ --concurrency 64 \ --model meta-llama/Meta-Llama-3.1-8B-Instruct

性能曲线分析与瓶颈定位

随着并发数从 1 逐步攀升，系统的表现呈现出明显的阶段性特征。

在低并发阶段（1-16），TTFT 保持在极低水平（约 50ms-80ms），此时系统资源充裕，GPU 计算单元并未满载，响应速度主要受限于网络往返和内核启动开销。当并发数进入中等区间（32-64）时，RPS 线性增长，Token/s 迅速爬升至峰值。对于 MI300X 而言，其高达 5.2TB/s 的 HBM3 带宽优势在此刻展露无遗，显存读取不再是瓶颈，计算单元利用率接近饱和。

然而，真正的考验出现在高并发区间（>64）。我发现当并发数超过某个阈值后，RPS 不再增长甚至出现回落，而 TTFT 开始指数级飙升。通过rocm-smi和性能分析工具追踪，确认此时的瓶颈并非算力不足，而是显存带宽饱和与上下文切换开销过大。大量的 KV Cache 读写操作占用了带宽，导致新的请求需要排队等待显存资源。这一现象在 70B 大模型上尤为明显，因为单个请求占用的显存块更多，加剧了碎片化和竞争。

关键参数调优：max-num-seqs 的平衡艺术

面对高并发下的性能衰退，盲目增加显卡数量并非最优解，调整 vLLM 的批处理策略往往能立竿见影。其中，--max-num-seqs参数是控制单次迭代中最大序列数的关键阀门。

默认配置下，vLLM 可能会尝试接纳过多并发请求进入批处理队列，导致单个步长的计算时间拉长，进而推高 TTFT。在我的测试中，将max-num-seqs从默认的较大值限制在256左右时，系统在 64 并发下的表现最为稳健。虽然这略微牺牲了极端的峰值吞吐量，但显著平滑了延迟曲线，避免了长尾请求拖垮整体体验。

此外，针对 AMD 平台的特性，我还调整了--block-size参数。在显存碎片化严重的场景下，适当增大 block size（如从 16 调整为 32）可以减少页表管理开销，提升显存连续读取效率。配合--gpu-memory-utilization 0.90的设置，预留 10% 的显存给驱动和系统缓冲，有效防止了因瞬时峰值导致的 OOM 崩溃。