部署超大参数模型时，单卡显存往往捉襟见肘，多卡张量并行（Tensor Parallelism, TP）成了必选项。但在 AMD Instinct GPU 平台上，很多管理员直接套用 NVIDIA 的经验，结果发现吞吐量并未线性增长，甚至出现延迟抖动。这通常是因为忽略了底层的硬件拓扑结构。

在配置 vLLM 之前，必须先摸清显卡之间的“路况”。Instinct 系列（如 MI300X）依赖高速互联技术，理想状态下应通过 Infinity Fabric 直连，而非经过 PCIe 交换机中转。你可以使用 rocm-smi --showtopo 命令查看拓扑图。如果看到 GPU 之间标记为 NV# 或类似的直连标识（AMD 环境下通常显示为 XGMI 或特定带宽数值），说明通信路径最优；若所有卡都挂在同一个 PCIe Root Complex 下且无直连链路，跨卡通信延迟将显著增加，直接拖累 TP 效率。

对于八路服务器，务必确认所有参与并行的 GPU 位于同一 NUMA 节点或同一 PCIe 根复合体下。如果拓扑显示跨 Socket 通信，建议在 BIOS 中开启 Above 4G Decoding 并检查 SR-IOV 设置，确保硬件层面没有人为制造瓶颈。只有物理链路通畅，上层的集合通信库才能跑满带宽。

核心配置实战：TP 切分与进程绑核

确认硬件拓扑无误后，我们进入 vLLM 的启动配置环节。张量并行的核心参数是 --tensor-parallel-size，它决定了模型权重被切分到多少张卡上。例如，运行一个 70B 参数的模型，若单卡显存不足，可设置为 8 卡并行：

vllm serve meta-llama/Llama-3-70b-Instruct \
    --tensor-parallel-size 8 \
    --gpu-memory-utilization 0.95 \
    --port 8000

这里有个容易被忽视的细节：进程绑核（CPU Affinity）。默认情况下，vLLM 启动的多个 worker 进程可能会随机调度到不同的 CPU 核心上，甚至跨越 NUMA 节点去访问内存，这会引发严重的资源争抢和延迟。

在 ROCm 环境下，强烈建议配合 numactl 工具手动绑定核心。假设我们有 8 张卡，对应 CPU 核心 0-63，可以将每个 vLLM worker 绑定到特定的核心范围。虽然 vLLM 自身在逐步优化调度，但在生产环境中，显式控制更稳妥。你可以编写一个简单的启动脚本，利用 taskset 或 numactl 包裹启动命令：

# 示例：将进程绑定到本地 NUMA 节点的核心
numactl --cpunodebind=0 --membind=0 vllm serve ... 

更精细的做法是根据 rocm-smi 显示的 Device ID 顺序，为每个 rank 分配独立的 CPU 核心组，避免上下文切换开销。特别是在高并发场景下，CPU 的调度抖动会直接传导至 GPU 的 Kernel 执行，导致 TTFT（首字延迟）忽高忽低。

通信后端排查：确保 RCCL 全链路畅通

多卡并行的灵魂在于集合通信。在 NVIDIA 生态中是 NCCL，而在 AMD 平台上则是 RCCL (ROCm Communication Collectives Library)。很多“配置了 TP 但速度没提升”的案例，根源都在于 RCCL 未能正确识别所有设备，退化为低效的通信模式。

启动服务后，第一时间观察日志输出。正常的 RCCL 初始化会打印出类似 Using network: GDRDMA 或 Init complete 的信息，并列出所有参与的 Rank ID。如果日志中出现 Fallback to TCP 或警告信息，说明高速直连通道建立失败，数据正通过缓慢的 TCP/IP 栈传输，这将使推理性能断崖式下跌。

排查步骤如下：

1. 检查环境变量：确保 RCCL_NET_PLUGIN 指向正确的插件路径（通常安装 ROCm 时已自动配置），并尝试设置 NCCL_DEBUG=INFO（RCCL 兼容该变量）来获取详细日志。
2. 验证设备可见性：在容器或虚拟环境中，确认 /dev/kfd 和 /dev/dri/renderD* 设备文件已正确挂载给所有用户组。
3. 防火墙与端口：RCCL 需要特定的端口范围进行点对点通信。如果集群节点间有防火墙，需放行相关端口，或直接设置 NCCL_SOCKET_IFNAME 指定内网网卡（如 eth0 或 ib0）。

若遇到 unhandled cuda error（ROCm 中常复用此类报错名）或进程挂起，大概率是某个 Rank 初始化超时。此时可调整 NCCL_TIMEOUT 环境变量，给慢速节点更多握手时间，但这只是权宜之计，根本解决还需回归到网络和驱动层面的连通性测试。

性能监控与容量曲线绘制

配置完成并不代表工作结束。多卡系统的稳定性需要通过压力测试来验证。不要仅凭单次请求的快慢做判断，而应关注系统在持续高负载下的表现。

利用 benchmark_serving.py 脚本模拟真实流量，逐步增加并发数（Concurrency），记录每秒请求数（RPS）和平均延迟。在 AMD 平台上，你可能会发现一个有趣的现象：当并发数超过某个阈值后，吞吐量不再上升，甚至下降。这通常意味着显存带宽饱和或 RCCL 通信成为瓶颈。

建议绘制一张系统容量曲线：横轴为并发请求数，纵轴为吞吐量（Token/s）和 P99 延迟。

• 线性增长区：说明多卡并行效率良好，通信开销可控。
• 拐点：此处即为系统的最佳工作点。
• 衰退区：资源争抢严重，需在此处设置限流策略。

同时，部署 Prometheus + Grafana 监控栈，通过 DCGM Exporter 采集每张卡的显存利用率、SM 活跃度及片间通信流量。如果发现某张卡的通信流量显著低于其他卡，可能存在负载均衡不均或拓扑识别错误。

多卡并行不是简单的参数叠加，而是对硬件拓扑、通信库调优及资源调度的综合考验。在 AMD Instinct 平台上，只要理清 Infinity Fabric 的物理连接，配好 RCCL 通信链路，并做好精细化的进程管理，完全能构建出高性价比的大模型推理集群。

🎁 开发者“神装”补给站｜CSDN 6 月宠粉专属福利
工欲善其事，必先利其器。为了帮大家扫清 AI 实践的障碍，CSDN AI 开发者计划，在文末为大家准备了一份「AI 开发者能量包」！