3. 硬件拓扑与网络：服务器网络拓扑与通信算法

聊到 NCCL 的性能，很多人第一反应是调参数、改代码。

但我得说句实话——你连硬件怎么连的都没搞清楚，调参就是瞎调。

我自己踩过这个坑。有一次压测死活上不去带宽，折腾了两天，最后发现是 PCIe 链路降速了。嗯，从那以后，我每次做性能分析，第一件事就是看拓扑。

3.1 服务器内部的三张网

一台 8 卡 GPU 服务器，内部其实有三套通信路径：

• PCIe：CPU 和 GPU 之间、GPU 和网卡之间，走 PCIe 总线
• NVLink：GPU 与 GPU 之间，NVIDIA 自家的高速互联
• InfiniBand：跨服务器通信，走网卡和交换机

这三者速度差多少？我给你列个表：

互联方式	单链路带宽	典型延迟	适用场景
PCIe 4.0 x16	32 GB/s	~1 µs	CPU↔GPU、GPU↔网卡
NVLink 3.0	600 GB/s（单卡 12 条）	~0.2 µs	GPU↔GPU（同节点）
InfiniBand HDR	200 Gb/s（约 25 GB/s）	~1.5 µs	跨节点通信

你看，NVLink 比 PCIe 快了将近 20 倍。所以为什么多卡训练要优先用 NVLink？就是这个道理。

3.2 常见的 GPU 拓扑结构

我见过最多的两种拓扑：

3.2.1 全 NVLink 互联（DGX 风格）

8 张 GPU 通过 NVSwitch 全互联。每张卡到其他 7 张卡都是直连，延迟极低。

这种拓扑下，NCCL 的 AllReduce 基本能跑到理论峰值的 90% 以上。我个人习惯在这种环境里直接上 Ring 算法，简单高效。

3.2.2 混合拓扑（常见于自建集群）

GPU 通过 PCIe Switch 连接到 CPU，再通过网卡走 IB。GPU 之间可能只有部分 NVLink 连接。

举个例子：4 张卡一组通过 NVLink 互联，组间走 PCIe。这种拓扑下，Ring 算法就会在跨组通信时遇到瓶颈。

3.3 通信算法：Ring 与 Tree

算法这东西，说白了就是「怎么把数据从 A 传到 B，再汇总回来」。NCCL 里最核心的两个算法：

3.3.1 Ring AllReduce

把 GPU 排成一个环。每个 GPU 只跟邻居通信。

• 优点：带宽利用率高，适合同构环境
• 缺点：延迟随 GPU 数量线性增长

你想想看，8 张卡做 Ring，数据要绕一圈才能回来。延迟就是 8 跳。如果 64 张卡呢？64 跳。所以 Ring 不适合大规模集群。

3.3.2 Tree AllReduce

构建一棵二叉树。数据从叶子往根汇聚，再从根广播下来。

• 优点：延迟随 GPU 数量对数增长，适合大规模
• 缺点：根节点容易成为瓶颈

我个人的经验是：单机 8 卡以内用 Ring，跨机超过 16 卡用 Tree。NCCL 其实会自动选择，但你也可以手动指定 NCCL_ALGO 来强制切换。

3.4 一张图看懂核心逻辑

下面这张 SVG 图，把服务器网络拓扑和算法选择的关系画清楚了：

3.5 实战建议

最后，给你几个我实际用过的建议：

1. 先跑 nccl-tests：用 allreduce_perf 看实际带宽，跟理论值对比。如果差太多，查拓扑。
2. 关注跨 NUMA 通信：用 nvidia-smi topo -m 看 GPU 归属。跨 NUMA 的通信尽量走 NVLink，别走 PCIe。
3. Ring 不是万能的：跨机场景，Tree 往往更优。我习惯在 16 卡以上集群里强制用 Tree。
4. 别忽略网卡位置：网卡插在哪个 PCIe Slot 上，直接影响 GPU 到网卡的带宽。最好让网卡跟 GPU 在同一 PCIe Switch 下。