拒绝“跑分焦虑”：用 benchmark_serving.py 摸清 AMD GPU 的真实性能
很多开发者在把大模型从 NVIDIA 迁移到 AMD Instinct GPU 时，心里总有点打鼓：ROCm 生态到底稳不稳？推理速度会不会崩？其实，光看官方文档里的理论峰值没意义，真正的性能得在真实的高并发场景下“跑”出来。最近我在 DevCloud 上基于 ROCm 7.x 部署好 vLLM 服务后，没有急着上线业务，而是先用benchmark_serving.py脚本做了一轮全方位的“压力测试”。这一测才发现，AMD 平台在大模型推理上的潜力，往往藏在那些容易被忽略的参数调优里。
测试环境与基准设定
这次测试的底座是 DevCloud 上的 AMD Instinct MI250 实例，操作系统为 Ubuntu 22.04，驱动版本锁定在 ROCm 7.0。模型选用的是社区支持度极高的Llama-3-8B-Instruct，通过 vLLM 以张量并行（TP=2）的方式启动。为了模拟真实业务流量，我直接使用了 vLLM 自带的benchmarks/benchmark_serving.py工具，数据集选取了sharegpt，它能很好地反映真实对话中的序列长度分布。
测试的核心变量设定为并发请求数（Concurrency）和序列长度。我们分别设置了 1、4、8、16、32 五个并发梯度，观察系统在不同负载下的表现。关注的指标非常明确：首字延迟（TTFT），这决定了用户感觉快不快；每秒生成 Token 数（TPS），这代表了模型的吞吐能力；以及每秒请求数（RPS），这是衡量系统整体处理效率的关键。
高负载下的性能曲线分析
当并发数从 1 逐步提升到 8 时，RPS 几乎呈线性增长，TPS 也保持在高位，这说明 vLLM 的 Continuous Batching（连续批处理）机制在 AMD 后端工作得非常出色，GPU 算力被充分榨取。然而，当并发数突破 16 甚至达到 32 时，性能曲线出现了明显的“拐点”：RPS 的增长开始放缓，甚至略有下降，同时 TTFT 显著拉长。
通过分析rocprof的性能剖析数据，我们发现瓶颈主要出在显存带宽饱和与上下文切换开销上。在高并发下，大量的 KV Cache 读写操作占满了 HBM 带宽，导致计算单元不得不等待数据。此外，过多的活跃序列也增加了 CPU 调度 GPU 任务的上下文切换成本。这时候，盲目增加并发数不仅不能提升 throughput，反而会拖慢整体响应。
针对这个问题，调整--max-num-seqs参数成了关键。限制单批次内处理的序列数量，虽然牺牲了一点极限并发能力，但换来了更平滑的延迟曲线和更稳定的 TPS。在实际生产中，找到这个“性能拐点”并据此设置限流策略，比单纯追求高并发更有价值。
FP8 量化带来的惊喜跃升
除了并发调优，这次测试还有一个重头戏：对比开启FP8 量化前后的性能差异。AMD Instinct 系列 GPU 对低精度计算有着原生硬件加速支持，理论上能带来显著提升。
在相同的并发配置（Concurrency=8）下，我分别运行了 BF16 精度和 FP8 精度的模型。结果令人印象深刻：
- 显存占用：FP8 模式下，模型权重加 KV Cache 的显存占用减少了近 45%，这意味着我们可以容纳更长的上下文或更大的 Batch Size。
- 推理速度：TPS 从 BF16 的约 140 tokens/s 提升到了 FP8 的 210 tokens/s 左右，增幅接近 50%。
- 延迟表现：TTFT 也有明显优化，尤其是在长序列生成场景下，首字返回更快。
启动命令只需简单增加--quantization fp8参数（需确保模型权重已转换为对应的 FP8 格式，或使用支持动态量化的版本）：
vllm serve meta-llama/Meta-Llama-3-8B-Instruct\--tensor-parallel-size2\--gpu-memory-utilization0.92\--quantizationfp8\--host0.0.0.0\--port8000数据不会骗人，FP8 量化在 AMD 平台上不仅仅是省显存，更是实打实的提速利器。对于对精度损失不敏感的生成类任务，这几乎是必选项。
结果可视化与结论
测试结束后，原始日志里的数字还不够直观。建议将benchmark_serving.py输出的 JSON 结果导入 Python，利用matplotlib或seaborn绘制并发数 -TPS/RPS 关系图以及TTFT 分布箱线图。通过可视化，你可以清晰地看到性能拐点在何处，以及不同量化策略下的延迟抖动范围。
这次实测证明，只要配置得当，AMD Instinct GPU 配合 ROCm 7.x 和 vLLM，完全能在生产级大模型推理中交出漂亮的成绩单。关键在于不要迷信默认参数，而是要通过科学的基准测试，结合具体的业务负载特征，去挖掘硬件的真实潜力。毕竟，适合自己的性能曲线，才是最好的优化方案。
200小时GPU算力已就位，快来领取：https://marketing.csdn.net/questions/Q2604140858304426315?utm_source=AIpaper
