环境基石：驱动验证与拓扑检查

在多卡并行推理的实战中，很多团队往往急于启动服务，却忽略了底层硬件拓扑的确认。对于 AMD Instinct GPU 用户而言，确保所有参与计算的卡片处于同一 PCIe 根复合体（Root Complex）或通过 Infinity Fabric 高速互联，是实现线性加速比的前提。如果卡片分散在不同的 PCIe 交换机下，卡间通信延迟会显著增加，导致张量并行（Tensor Parallelism, TP）效率大打折扣。

在动手配置 vLLM 之前，务必先通过 rocm-smi 和 rocminfo 完成“体检”。运行 rocm-smi --showtopo 可以直观地查看 GPU 之间的连接类型。理想状态下，多卡之间应显示为 XGMI（即 Infinity Fabric），这意味着它们拥有极高的带宽和低延迟；若显示为 PIX 或 PXB，说明通信需经过 PCIe 交换机，虽可工作但性能会有损耗；若是 NODE，则意味着通信需经过 CPU 甚至 NUMA 节点，这在 TP 场景下通常是不可接受的。

此外，使用 rocminfo 确认架构代码（如 gfx942 对应 MI300 系列）至关重要。后续编译 PyTorch 和 vLLM 时，必须将 PYTORCH_ROCM_ARCH 环境变量严格匹配此代码，否则生成的二进制文件在运行时会直接抛出 “illegal instruction” 错误，且没有任何友好的提示，排查起来非常耗时。

核心配置：RCCL 通信与进程绑核

当硬件拓扑确认无误后，软件层面的通信库配置成为关键。vLLM 在 ROCm 环境下依赖 RCCL（ROCm Communication Collectives Library）进行卡间数据同步。虽然 RCCL 通常能自动识别设备，但在复杂的多卡服务器中，显式指定通信后端和绑定策略能显著提升稳定性。

最容易被忽视的性能杀手是 CPU 资源争抢。在八卡并行场景下，如果多个推理进程被操作系统调度到同一个 CPU 核心上，或者跨 NUMA 节点访问内存，会导致严重的上下文切换开销和内存访问延迟。解决这一问题的标准动作是使用 numactl 进行进程绑核。

假设我们有一台八卡服务器，CPU 拓扑为两个 NUMA 节点，每个节点管理四张卡。启动服务时，不应直接运行 vllm serve，而应结合 numactl 将进程绑定到对应的 CPU 核心和内存节点。例如，对于前四张卡，可以使用：

numactl --cpunodebind=0 --membind=0 vllm serve <model_path> \
    --tensor-parallel-size 8 \
    --gpu-memory-utilization 0.90 \
    --block-size 16

这里的 --tensor-parallel-size 8 告诉 vLLM 将模型权重切分到 8 张卡上。--gpu-memory-utilization 建议设置为 0.90 而非激进的 0.95，预留的 10% 显存用于应对 KV Cache 的动态波动和驱动开销，防止因瞬时峰值导致 OOM（内存溢出）。--block-size 设为 16 是在显存利用率和碎片化管理之间的一个平衡点，适合大多数变长序列场景。

若遇到 RCCL 初始化超时或通信错误，可尝试导出环境变量强制指定后端：

export NCCL_ALGO=Ring
export RCCL_NET_PLUGIN=none

这能迫使 RCCL 使用更稳健的环形算法，避免在某些特定网络拓扑下选择次优路径。

实战演练：八卡集群启动与性能观测

完成上述配置后，我们可以正式拉起高并发推理服务。以下是一个针对 Llama 3 70B 模型在八卡 MI300X 环境下的完整启动模板。该命令集成了显存优化、多卡并行及日志监控参数：

vllm serve meta-llama/Meta-Llama-3-70B-Instruct \
    --host 0.0.0.0 \
    --port 8000 \
    --tensor-parallel-size 8 \
    --gpu-memory-utilization 0.90 \
    --max-num-seqs 256 \
    --max-model-len 8192 \
    --block-size 16 \
    --disable-log-requests

启动过程中，密切观察日志输出。正常的加载流程会显示每张卡的显存分配情况以及 RCCL 组的建立信息。一旦看到 “Uvicorn running on…”，即可进行压力测试。

为了验证多卡并行的实际效果，不要仅凭单次请求的响应时间做判断。推荐使用 vLLM 自带的 benchmark_serving.py 脚本模拟真实流量。设置并发数为 32 至 64，观察每秒请求数（RPS）和每秒生成 Token 数（Token/s）。在理想的八卡互联环境下，随着并发度提升，吞吐量应呈现近似线性的增长。如果发现并发升高后吞吐量反而下降，或者 TTFT（首字延迟）异常波动，大概率是 CPU 绑核未生效导致资源争抢，或是 PCIe 拓扑非最优导致的通信瓶颈。

此时，可配合 Prometheus + DCGM Exporter 监控显卡状态。重点关注 SM 利用率和显存带宽占用率。若 SM 利用率长期低于 80% 而带宽已跑满，说明模型是显存带宽受限，此时进一步增加并发意义不大，应考虑调整 --max-num-seqs 或开启量化（如 FP8）来降低带宽压力。通过这种“配置 - 测试 - 监控”的闭环迭代，才能真正榨干多卡集群的性能潜力。

200小时GPU算力已就位，快来领取：https://marketing.csdn.net/questions/Q2604140858304426315?utm_source=AIpaper