多卡并行怎么配，AMD GPU 张量并行实战笔记

环境准备与驱动验证

在多卡环境下部署大模型推理，最忌讳的就是“想当然”。很多团队在拿到 AMD Instinct GPU 后，直接跳进代码编译环节，结果往往卡在通信库初始化失败或者显存分配异常上。基于 ROCm 7.x 的实战经验告诉我们，先把地基打牢比什么都重要。

首先，操作系统层面必须干净。推荐使用 Ubuntu 22.04 LTS，内核版本最好保持在 5.15 以上，以确保对最新硬件调度的支持。安装完官方 ROCm 7.x 驱动后，不要急着跑 PyTorch，先用rocm-smi扫一眼。如果能看到所有卡的温度、功耗和显存状态，说明内核态驱动没问题。紧接着是关键的架构确认，运行rocminfo，记下你的 GPU 架构代码（比如 MI300X 对应的是gfx942）。这个代码后续编译 PyTorch 和 vLLM 时要用到，填错了会导致生成的二进制文件在运行时抛出 "illegal instruction" 错误，到时候排查起来非常耗时。

另外，用户权限也是个隐蔽的坑。确保当前用户已加入video和render组：

sudo usermod -aG video,render $USER

执行完后务必重启，否则后续调用 GPU 设备文件时可能会遇到权限拒绝的问题。

源码编译与依赖对齐

虽然 PyTorch 提供了预编译的 ROCm 版本，但在多卡并行场景下，为了获得最佳的算子性能和 RCCL 通信库支持，强烈建议从源码编译。这步虽然繁琐，但能避免很多“玄学”问题。

创建好 Conda 虚拟环境后，先安装基础构建工具：ninja、wheel以及对应版本的hipblaslt。编译 PyTorch 前，必须导出架构环境变量：

export PYTORCH_ROCM_ARCH=gfx942 export MAX_JOBS=32

这里的gfx942需替换为你实际机器的架构代码。接着使用pip install .进行编译。PyTorch 搞定后，轮到 vLLM。vLLM 强依赖 Triton 编译器，务必确保安装的 Triton 版本与当前 PyTorch 版本兼容。在安装 vLLM 时，同样需要指定 HIP 路径，确保其内部的 Kernel 能针对 AMD 架构正确生成。

深入理解 RCCL 与张量并行配置

多卡并行的核心在于通信。在 NVIDIA 生态里大家熟悉的是 NCCL，而在 AMD 平台上，对应的则是RCCL(ROCm Communication Collectives Library)。vLLM 的张量并行（Tensor Parallelism, TP）功能正是依赖 RCCL 来实现卡间的高速数据同步。

RCCL 的工作原理是根据 GPU 的拓扑结构自动选择最优通信路径。在理想情况下，如果所有卡都位于同一个 PCIe 根复合体下，或者通过 Infinity Fabric 互联，RCCL 会优先使用 P2P（Peer-to-Peer）直连通信，带宽极高且延迟极低。但如果拓扑识别错误，通信流量可能会被强制路由到 CPU 内存甚至低速以太网，导致吞吐量断崖式下跌。

启动 vLLM 服务时，通过--tensor-parallel-size参数指定卡数。例如在八卡机器上：

vllm serve meta-llama/Llama-3-70B-Instruct \ --tensor-parallel-size 8 \ --gpu-memory-utilization 0.92 \ --block-size 16

这里gpu-memory-utilization设为 0.92 是为了给系统预留一点缓冲，防止因显存碎片导致 OOM。如果发现启动极慢或者推理过程中频繁卡顿，大概率是 RCCL 没有走对通道。可以用RCCL_DEBUG_INFO=1环境变量启动，观察日志中是否显示使用了 "P2P" 或 "Direct" 模式。

CPU 绑核与拓扑优化技巧

很多时候，GPU 没吃饱，瓶颈反而在 CPU 资源争抢上。多卡并行时，每个 GPU 进程都会占用 CPU 资源进行数据预处理和调度。如果多个进程被操作系统随机调度到同一个 CPU 核心上，上下文切换开销会瞬间拉高延迟。

解决这个问题的标准动作是使用numactl进行绑核。假设我们有 8 张卡，CPU 有 64 个核心，可以将每 8 个核心绑定给一张卡。以下是一个简化的启动脚本示例：

# 卡 0 绑定到 NUMA 节点 0 的前 8 个核心 numactl --cpunodebind=0 --membind=0 vllm serve ... --device 0 & # 卡 1 绑定到 NUMA 节点 0 的后 8 个核心 numactl --cpunodebind=0 --membind=0 vllm serve ... --device 1 &

更精细的做法是结合taskset直接指定核心掩码。此外，还要检查 PCIe 拓扑结构，使用lspci -t确认所有参与并行的 GPU 是否挂在同一个 Switch 下。如果跨了 PCIe 根桥，通信延迟会增加，此时需要在 BIOS 中开启 Above 4G Decoding 和 Re-Size BAR 支持，确保显存寻址无障碍。

实测表现与网络避坑

在完成上述配置后，我们进行了八卡互联的压力测试。结果显示，在 FP8 精度下，Llama-3-70B 模型的推理吞吐量随着卡数增加呈现出近乎线性的增长。当 TP=8 时，整体 Token 生成速度接近单卡的 7.8 倍，通信损耗控制在 5% 以内，这得益于 ROCm 7.x 对 RCCL 的深度优化以及 Instinct GPU 之间的高速互联。

不过，网络配置中有个常见陷阱容易被忽视：在多节点或多网卡环境中，RCCL 有时会错误地选择管理网口（如 eth0）而不是高速 RDMA 网卡（如 ib0）进行通信。务必通过NCCL_SOCKET_IFNAME或RCCL_NET_PLUGIN环境变量显式指定正确的网络接口名称，否则一旦走错路，性能会跌落到原来的十分之一。

折腾完这套流程，你会发现 AMD 平台的多卡并行其实并不神秘，关键在于对底层通信机制的理解和细致的参数调优。一旦链路打通，其性价比优势在大规模推理场景中非常明显。

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