3. 多卡通信模式

在单机多卡或跨节点训练场景中，单个 GPU 无法容纳大模型参数与中间激活值，数据并行、模型并行、流水线并行等策略都依赖 GPU 之间频繁交换张量数据。这些交换并非简单的点对点消息传递，而是以集合通信（Collective Communication）为基本原语。理解集合通信的语义与性能边界，是分析多卡拓扑瓶颈、设计通信调度策略的前提。

3.1 集合通信的语义模型

集合通信定义了一组参与进程（或 GPU）之间的全局数据搬运与规约操作。与点对点通信（如 send/recv）不同，集合通信要求所有参与者同时进入调用，并共同完成一次全局操作。常用原语包括：

  • Broadcast：将根节点的数据分发给所有参与者。
  • All-Reduce：所有节点提供一份数据，经过逐元素规约（求和、求最大值等）后，每个节点都得到完整的规约结果。
  • All-Gather：每个节点提供一份数据，所有节点收集全部数据并按 rank 顺序拼接成完整张量。
  • Reduce-Scatter：先按 rank 维度切分数据，各节点对切分块做规约，最终每个节点只保留属于自己的规约结果块。
  • All-to-All：每个节点向其他每个节点发送不同数据，同时从其他节点接收数据，常用于 MoE 模型或序列并行。

从数据流角度看，All-Reduce 等价于 Reduce-Scatter 后接 All-Gather；All-Gather 则是全量数据的汇聚与复制。理解这一等价关系有助于后续分析通信量下限。

3.2 通信量与拓扑感知的 Ring All-Reduce

设参与节点数为 N，每个节点持有数据量为 K（单位：字节）。朴素实现中，若采用中心化参数服务器模式，每个节点先发送 K 给服务器，服务器规约后再广播 K 给所有节点，总通信量为 2NK。当 N 增大时，服务器成为瓶颈，且通信量随节点数线性增长。

Ring All-Reduce 将节点组织成逻辑环，分两步完成：

  1. Reduce-Scatter 阶段：将数据切分为 N 块，每个节点从上游接收一块，与本地对应块做规约，再传给下游。经过 N-1 步后，每个节点持有最终规约结果的一个分块。
  2. All-Gather 阶段：每个节点将持有的分块沿环广播，经过 N-1 步后，所有节点获得完整结果。

Ring 算法总通信量为 2K(N-1)/N，当 N 较大时趋近于 2K，与节点数基本解耦。但代价是延迟随 N 线性增加（共 2(N-1) 步），且每一步的传输时间取决于环中相邻节点的链路带宽。若环中某条链路是跨 NUMA 或跨 PCIe Switch 的低带宽路径，整环性能会被该链路拖累。

性能特征总结：

算法通信量延迟步数适用场景
中心化（PS）2NK2小规模、容忍单点瓶颈
Ring All-Reduce2K(N-1)/N2(N-1)大规模、同构高速互联
Tree All-Reduce2K·log(N)2·log(N)跨机柜、层次化拓扑
Hierarchical（分层）机内 + 机间分离机内步数 + 机间步数混合拓扑（NVLink + RDMA）

3.3 拓扑对集合通信性能的影响

实际 GPU 集群的物理拓扑并非均匀全互联。以一台 8 卡 DGX 服务器为例，GPU 之间通过 NVLink 构成混合立方体网格，而跨节点通信必须经过 PCIe Switch、网卡（HCA）和交换机。集合通信的性能取决于两个维度：

  • 链路带宽差异：NVLink 单条带宽通常为 50~100 GB/s，而 PCIe Gen5 x16 约 64 GB/s，跨节点 RDMA 通常为 25~50 GB/s（受网卡与交换机限制）。Ring 算法若将低速链路纳入环中，会直接拉长单步传输时间。
  • 拓扑感知的通信调度：NCCL 等库会探测 GPU 之间的实际连接路径，构建 拓扑感知的通信图。例如，在 8 卡机内，NCCL 优先使用 NVLink 形成两个 4-GPU 环，再通过 PCIe Switch 连接两个环；跨节点时，每个节点选一个 GPU 作为桥接节点，通过网卡完成机间通信。

下图展示了一个典型的 8 卡双 NVLink Switch 拓扑下的 All-Reduce 数据流示意：

GPU 0-3 GPU0 GPU1 GPU2 GPU3 NVLink PCIe Switch GPU 4-7 GPU4 GPU5 GPU6 GPU7 HCA RDMA 25GB/s Reduce-Scatter 数据流方向

在跨节点场景中，若直接使用全局 Ring，则环中必然包含低速 RDMA 链路，导致整环性能下降。更优做法是分层 All-Reduce：先在机内通过 NVLink 完成局部规约，再将机内结果通过 RDMA 在节点间做第二次规约，最后将结果广播回机内各 GPU。这种策略将高速链路与低速链路分离，避免低速链路成为全局瓶颈。

3.4 实际案例：8 卡机内 vs 跨节点 All-Reduce 性能对比

以 8 卡 A100（NVLink 三代，带宽 600 GB/s）为例，测试 256 MB 张量的 All-Reduce 延迟：

# 机内 8 卡，NCCL 默认拓扑感知
$ nccl-tests/build/all_reduce_perf -b 256M -e 256M -f 2 -g 8
# 结果：平均延迟约 45 us，总线带宽约 5.6 TB/s（利用 NVLink 全互联）

# 跨 2 节点（每节点 8 卡），通过 IB EDR（100 Gb/s）互联
$ mpirun -np 16 -hostfile hosts ./all_reduce_perf -b 256M -e 256M -f 2 -g 8
# 结果：平均延迟约 320 us，总线带宽约 1.6 TB/s（受限于机间链路）

从数据可以看出，跨节点延迟是机内的 7 倍以上。若训练脚本中每步迭代都执行一次全局 All-Reduce，则通信时间占比会显著上升。优化手段包括：

  • 梯度压缩：将 32 位浮点梯度量化为 8 位或使用 TopK 稀疏化，减少通信量。
  • 通信与计算重叠：将梯度切分为多个分块，在反向传播过程中边计算边通信，隐藏通信延迟。
  • 使用 NCCL 的 NCCL_P2P_LEVEL 与 NCCL_NET_GDR_LEVEL 环境变量，控制 P2P 与 GPUDirect RDMA 的启用层级，避免不必要的内存拷贝。

3.5 常见误区与复盘

误区一：认为 Ring All-Reduce 一定优于 Tree 算法。 Ring 在节点数多且链路同构时通信量最优，但在跨机柜场景中，Tree 算法可以利用层次化带宽（如机柜内高速、机柜间低速）减少跨柜数据量。实际应通过基准测试选择算法，而非盲目套用。

误区二：忽略 All-Gather 与 All-Reduce 的差异。 All-Gather 没有规约操作，通信量下限为 K(N-1)，比 All-Reduce 高约 N/2 倍。在张量并行（如 Megatron-LM 的列并行）中，每个 Transformer 层会执行两次 All-Reduce；若误用 All-Gather 实现，通信开销将成倍增加。

复盘建议：在引入新的并行策略或调整拓扑前，先用 nccl-tests 对目标通信原语做带宽与延迟基准测试，并记录不同消息大小下的性能曲线。重点关注消息较小时延迟受步数影响、消息较大时带宽受链路瓶颈影响这两个区间。

← 上一章 📖 返回目录 下一章 →