拒绝“拍脑袋”：用 benchmark_serving.py 跑准 vLLM 性能基线

在 DevCloud 上把 vLLM 服务跑起来只是第一步，很多开发者往往卡在这一步就急着上线，结果生产环境一遇流量就崩。真正的工程化落地，必须经过科学的压力测试。我们不需要复杂的商业压测工具，vLLM 源码中自带的 benchmark_serving.py 脚本就是最趁手的兵器。它能帮我们摸清 AMD Instinct GPU 在 ROCm 7.x 环境下的真实性能底数，避免资源浪费或容量预估失误。

核心指标：到底该看什么？

运行压测前，得先搞清楚几个关键指标的含义，否则看着一堆数字容易发懵。

• RPS (Requests Per Second)：每秒处理的请求数。这是衡量系统吞吐能力的直接指标，数值越高说明单位时间内能服务的用户越多。
• TPS (Tokens Per Second)：每秒生成的 Token 数。对于大模型而言，这比 RPS 更能反映实际的计算效率，尤其是生成长文本时。
• TTFT (Time To First Token)：首字延迟。用户发出请求到看到第一个字出来的时间。这个指标直接影响用户体验，TTFT 过高会让用户觉得系统“卡住了”。

在 ROCm 环境下，由于内存带宽和计算架构的特性，这些指标的表现可能与 NVIDIA 平台有所不同，因此实测数据尤为重要。

实验设计：模拟真实流量洪峰

不要只测单并发，那毫无意义。真实的业务场景往往是多用户同时访问。我们可以利用 benchmark_serving.py 模拟不同强度的负载。假设我们已经启动了 Llama 3 8B 模型的服务，监听在 8000 端口。

首先，准备一个包含真实 Prompt 的数据集（如 ShareGPT），然后设置不同的并发请求速率。以下是一个典型的测试命令：

python benchmarks/benchmark_serving.py \
    --backend vllm \
    --dataset-name sharegpt \
    --request-rate 4 \
    --num-prompts 200 \
    --model meta-llama/Meta-Llama-3-8B-Instruct

这里的 --request-rate 是关键变量。我们可以从低到高逐步调整，比如分别设置为 2、4、8、16、32，观察系统在不同负载下的表现。每次测试建议运行足够长的时间（如 200 个请求以上），以消除启动阶段的波动影响。

寻找性能拐点：显存带宽的博弈

在 AMD Instinct GPU 上，随着并发数的增加，性能曲线通常不会无限线性上升。你会发现一个有趣的现象：当 request-rate 较低时，RPS 和 TPS 随并发数增加而稳步提升；但当达到某个临界值后，吞吐量不再增长，甚至开始下降，同时 TTFT 急剧飙升。

这个临界点就是性能拐点。它的出现通常意味着显存带宽已经饱和，或者 GPU 的计算单元被过多的上下文切换占用。此时，GPU 大部分时间在等待数据搬运，而非进行有效计算。

为了找到这个拐点并优化它，我们需要关注 max-num-seqs 参数。这个参数控制了 vLLM 单个批次中最大能处理的序列数量。默认值可能过于激进或保守。

调优策略：

1. 观察现象：如果在高并发下 TPS 下降明显，尝试降低 --max-num-seqs。
2. 重新测试：在启动服务时加入该参数，例如 --max-num-seqs 128，然后重复上述压测流程。
3. 对比数据：记录不同 max-num-seqs 设置下的 RPS 和 TTFT 变化。

通常情况下，适当限制单批次的序列数，可以减少显存碎片化和调度开销，反而能在高负载下维持更高的整体吞吐量。这就好比高速公路，车太多全堵死不如限流让车流跑得更顺畅。

绘制容量曲线，为规划提供依据

测试完成后，不要只看终端输出的最后一行总结。建议将每次测试的 request-rate 作为横坐标，RPS 和 TTFT 作为纵坐标，绘制出性能曲线图。

• 线性增长区：说明资源充足，可以放心扩容。
• 平缓区：系统接近饱和，是最佳的工作区间。
• 下降区：系统过载，必须避免进入此区域。

通过这条曲线，你就能清楚地知道当前这台 DevCloud 实例（比如搭载 MI250 或 MI300）到底能扛多少并发。如果业务预期 QPS 是 50，而你的拐点在 40，那就需要考虑增加实例数量或开启张量并行（Tensor Parallelism）了。

这种基于数据的容量规划，远比凭经验“猜配置”要靠谱得多。在 ROCm 生态日益成熟的今天，掌握这套科学的压测方法，能让你的大模型服务在 AMD 硬件上跑得既稳又快。