📚 课程目录第4章集群网络物理与逻辑拓扑设计

4. 集群网络物理与逻辑拓扑设计

当集群规模从几十张 GPU 扩展到上千张时，网络拓扑就不再只是“把交换机连起来”的布线问题，而是直接决定 AllReduce、All-to-All 等集合通信能跑多快、RDMA 路径是否对称、故障域是否可控的核心设计变量。本节围绕叶脊架构、Rail-Optimized 拓扑、GPU 与网卡亲和性，以及 PCIe Switch 与 NVLink 域对 RDMA 路径的影响展开，目标是让读者能够根据 GPU 数量、网卡数量和交换机端口数，推导出一套可落地的物理与逻辑拓扑方案。

叶脊架构：无阻塞与等价多路径的基础

叶脊（Leaf-Spine）是当前 GPU 集群最主流的 CLOS 变体。叶交换机（Leaf）下联 GPU 服务器，上联所有脊交换机（Spine）；脊交换机之间不互连，只负责叶间转发。任意两台服务器之间的路径跳数固定为“服务器→Leaf→Spine→Leaf→服务器”，这种固定跳数带来两个关键收益：一是任意两点间带宽一致，避免传统三层树中“跨汇聚层拥塞”；二是天然支持 ECMP，同一目的地的多条等价路径可被哈希分散。

以常见的 64 端口 400G 交换机为例：若每台 Leaf 用 32 个下行端口接 32 台服务器（每台 8 张 GPU，即 256 GPU/Leaf），剩余 32 个上行端口接 32 台 Spine，则收敛比（oversubscription）为 1:1，即无阻塞。若 Spine 只有 16 台，则收敛比为 2:1，意味着跨 Leaf 的 All-to-All 流量峰值只能达到线速的一半。GPU 集群中 NCCL 的 Ring/Tree 算法对带宽对称性非常敏感，因此生产环境通常要求 Leaf 上行与下行端口数相等，或至少保证同一 Rail 内无收敛。

设计检查点：先确定“每 GPU 可用带宽”目标（如 400Gbps），再反推 Leaf 下行端口数、Spine 数量与收敛比。收敛比 = 下行总带宽 / 上行总带宽，GPU 集群建议 ≤ 1:1 或 2:1。

Rail-Optimized 拓扑：让同号 GPU 走同号网卡

Rail-Optimized 是 GPU 集群特有的逻辑拓扑优化。其核心思想是：把每台服务器内的第 i 张 GPU 与第 i 张网卡绑定，所有服务器的“第 i 号 GPU+网卡”组成一个 Rail，接入同一组 Leaf 交换机。这样，当 NCCL 执行 AllReduce 时，同一 Rail 内的 GPU 之间通信只经过本 Rail 的 Leaf，不跨 Spine，路径最短、延迟最低、拥塞域最小。

举例：8 台服务器，每台 8 GPU + 8 网卡（400G）。按 Rail 划分后，8 个 Rail 各对应一台 Leaf（或一组 Leaf），每台 Leaf 下联 8 台服务器的同号网卡。此时 AllReduce 的 Ring 可以优先在 Rail 内完成，跨 Rail 流量仅用于最终汇聚。相比随机布线，Rail-Optimized 能把跨 Spine 流量降低约 (N-1)/N，N 为 Rail 数。

GPU 与网卡亲和性：决定 RDMA 路径的起点

GPU 与网卡的亲和性（affinity）决定了数据从 GPU 显存出发后，经过哪条 PCIe 路径到达网卡。在 8 GPU 服务器中，GPU 通常分为两组，每组 4 张 GPU 挂在一个 PCIe Switch 下，网卡也按组分布。若 GPU0 与 NIC0 在同一 PCIe Switch 下，则 GPU0 的 RDMA 流量只需经过一次 PCIe Switch 跳转；若 GPU0 与 NIC4 跨组，则需经过 CPU 或跨 Socket 的 QPI/UPI 链路，延迟和带宽都会明显劣化。

实际配置中，可用 nvidia-smi topo -m 查看 GPU 与网卡的拓扑关系。输出中的 PIX 表示同一 PCIe Switch 下，PHB 表示同一 CPU 下的不同 PCIe Host Bridge，SYS 表示跨 Socket。NCCL 会优先选择 PIX 路径的网卡进行通信。因此，在部署时应在 NCCL 环境变量中显式设置 NCCL_IB_HCA 或使用 NCCL_TOPO_FILE 指定亲和关系，避免 NCCL 误选远端网卡。

# 查看 GPU 与网卡亲和性（示例输出片段）
$ nvidia-smi topo -m
        GPU0  GPU1  NIC0  NIC1
GPU0     X    NV1   PIX   SYS
GPU1    NV1    X    SYS   PIX
NIC0   PIX   SYS    X    SYS
NIC1   SYS   PIX   SYS    X

# 结论：GPU0 应绑定 NIC0，GPU1 应绑定 NIC1
# 在 NCCL 中限制使用与 GPU 同组的 HCA
$ export NCCL_IB_HCA=mlx5_0:1,mlx5_1:1

PCIe Switch 与 NVLink 域对 RDMA 路径的影响

NVLink 域是服务器内部 GPU 之间的高带宽互连，带宽可达 600GB/s 以上，远高于 PCIe Gen4 x16 的 32GB/s。当 NCCL 执行 AllReduce 时，若通信双方在同一 NVLink 域内，数据直接走 NVLink，不经过网卡；只有跨服务器通信才需要经过网卡和 RDMA 网络。因此，拓扑设计应尽量让同一 NVLink 域内的 GPU 承担同一 Rail 的通信任务，减少跨域流量。

PCIe Switch 则决定了 GPU 到网卡的路径。若 GPU 与网卡在同一 PCIe Switch 下，RDMA 路径为“GPU→PCIe Switch→NIC”，延迟约 1~2μs；若跨 PCIe Switch 或跨 Socket，路径变为“GPU→PCIe Switch→CPU→PCIe Switch→NIC”，延迟可能增加到 5~10μs，且带宽受 UPI 限制。对于 400G RDMA，单条 PCIe Gen4 x16 已接近饱和，跨 Socket 路径会成为瓶颈。

实践建议：在 8 GPU 服务器中，优先将 GPU0~3 与 NIC0~3 放在同一 PCIe Switch 下，GPU4~7 与 NIC4~7 放在另一 PCIe Switch 下。这样每个 Rail 内的 GPU 与网卡都处于同一 PCIe 域，RDMA 路径最短。

从物理到逻辑：一套可落地的拓扑推导流程

假设集群规模为 512 GPU，每台服务器 8 GPU + 8 张 400G 网卡，交换机为 64 端口 400G。推导步骤如下：

确定 Rail 数：每台服务器 8 GPU，对应 8 个 Rail。
确定每 Rail 服务器数：512 GPU / 8 GPU每台 = 64 台服务器，每 Rail 有 64 张同号网卡。
确定 Leaf 数量：每台 Leaf 下联 64 个端口，正好覆盖一个 Rail 的 64 张网卡，因此需要 8 台 Leaf（每 Rail 一台）。
确定 Spine 数量：若要求无阻塞，每台 Leaf 需要 64 个上行端口，但 Leaf 总端口只有 64，下行已占满，因此需采用“Leaf 下行 32 + 上行 32”的配置，即每台 Leaf 只接 32 台服务器，8 个 Rail 共需 16 台 Leaf。Spine 数量 = 16 台 Leaf × 32 上行 / 64 端口 = 8 台 Spine。
收敛比校验：下行总带宽 = 16 Leaf × 32 端口 × 400G = 204.8T；上行总带宽 = 16 Leaf × 32 端口 × 400G = 204.8T，收敛比 1:1，无阻塞。

逻辑上，每个 Rail 对应一组 Leaf，NCCL 的 Ring 优先在 Rail 内闭合，跨 Rail 流量仅用于最终 AllReduce 汇聚。此时，GPU 与网卡的亲和性配置应保证：服务器内第 i 张 GPU 使用第 i 张网卡，且该网卡接入第 i 个 Rail 的 Leaf。这样，从 GPU 显存到 RDMA 出口的整条路径——NVLink 域内、PCIe Switch 同组、Leaf 同 Rail——都处于最短路径上。

设计维度	推荐取值	影响
Leaf 下行端口数	32（400G）	决定每 Leaf 服务器数，影响 Rail 规模
Spine 数量	8（64 端口）	决定跨 Rail 带宽与收敛比
收敛比	1:1	All-to-All 峰值带宽，NCCL 效率
GPU-NIC 亲和	同 PCIe Switch	RDMA 路径延迟与带宽
NVLink 域划分	同 Rail 同域	减少跨域 RDMA 流量

最后需要强调的是，拓扑设计不是一次性的静态任务。当集群扩容、更换网卡或调整 NCCL 版本时，GPU 与网卡的亲和关系、Rail 划分和收敛比都可能变化。建议在每次变更后，用 nvidia-smi topo -m 复核亲和性，用 ibstat 确认网卡状态，并用 NCCL 的 NCCL_DEBUG=INFO 日志观察实际使用的 Ring 路径是否与设计一致。只有物理拓扑、逻辑拓扑和软件配置三者对齐，RDMA 路径才能真正跑在最短、最宽的那条线上。