随着 AI 训练规模的扩大，单个数据中心 (DC) 不足以提供所需的计算能力。应对这一挑战的最新方法依赖于多个数据中心位于同一地点或分布在不同地理位置。在最近的一项开源功能中，NVIDIA 集合通信库 (NCCL) 现在能够跨多个数据中心无缝通信，同时考虑网络拓扑结构，以确保提供最佳性能。
下面我们将介绍所提议方法的内部运作方式，以及实现预期功能所需的关键关注点。
NCCL 已经支持多个通信器，每个通信器都依赖于不同的网络。例如，用户可以使用内部 DC 网络将全局归约集合组成内部 DC 归约散射，然后在内部 DC 网络上执行全局归约，并在内部 DC 网络上执行最终的全局收集。此方法已在 NVIDIA Nemo 框架中使用。
NCCL 中提议的交叉 DC 功能有两个目标。首先，我们保证在多直流连接的情况下提供最佳性能。其次，我们支持多直流通信，对 AI 训练工作负载的修改最少。
具体来说，对于此功能，我们针对两种连接场景 (请参见下图 1) ：
- 通过同构网络连接的不同数据中心 (对于 DC 内和 DC 间网络，通常为 IB 或 RoCE) 。
- 数据中心通过异构网络连接。通常，InfiniBand (IB) 或 RDMA over Converged Ethernet (RoCE) 用于 DC 内连接，TCP 用于 DC 间网络。
在这两个场景中，我们在下面详细介绍了如何在 NCCL 中使用跨 DC 功能，以及在评估性能时需要牢记的一些关键性能注意事项。
NCCL 中的网络拓扑感知
网络通过 ncclNet API 暴露给 NCCL。每个 ncclNet 都对应一组连接到同一网络的虚拟设备 (以及用于与该组设备交互的关联 API) 。从 NCCL 的角度来看，暴露在两个不同网络上的两台设备将被视为两个断开连接的网络的一部分。我们还注意到，合作伙伴和网络提供商可以自由地公开与单个或多个 ncclNet 结构相同的物理网络。
这种抽象是关键，因为它提供了支持跨 DC 通信的构建块。在本文档的其余部分中，“网络”旨在表示为 ncclNet。
第 1 步：启用多个网络
要允许 NCCL 使用多个网络 (多个 ncclNet) ，必须设置 NCCL_ALLNET_ENABLE=1。当 NCCL_ALLNET_ENABLE 设置为 1 时，NCCL 将尝试为每个通信器加载所有 ncclNet 插件。副作用是，它会禁用 collNet。将值设置为 0 (默认) 将恢复已知行为：NCCL 将仅使用第一个成功加载的插件。
如前所述，NCCL 假设来自不同网络的设备断开连接。虽然在异构网络场景中，此假设可能足以推理网络拓扑，但在单个同构网络的情况下，此假设是不够的 (请参见图 1) 。为了更深入地了解网络拓扑，我们引入了网络 ID 的概念。
第 2 步：NCCL 通过网络 ID 发现网络拓扑
拓扑感知依赖于 fabricId，它捕获拓扑信息和设备之间的连接。使用 fabricId，NCCL 查询属于同一 tg_ 13 的两台网络设备之间的网络拓扑和其他路径信息。NCCL 分两步探索网络拓扑：
- 在初始化过程中，系统会交换通信器中每个秩可用的
fabricId列表。对于 NCCL，fabricId是不透明的 64 位句柄。fabricId由网络插件提供，其确切含义取决于插件的实现。 - 建立连接时，NCCL 将使用新添加到
ncclNet：tg_ 18 的 API 来查询网络连接。在此功能的特定环境中，path信息仅包含两个以参数形式给出的fabricId之间的连接情况：NET_LOC_DCL0 用于内部 DC 连接，NET_ LOC_ DCL1 用于跨 DC 连接，NET_ LOC_ DISC 用于断开连接的 tg_ 21。
解释 fabricId 之间的连接是网络插件的责任。实现此目的的方法有很多，例如使用 64 位哈希主机名和利用 SLURM 拓扑文件。
在 NCCL IB 插件实现中，我们选择了一种更简单的方法。通过环境变量 NCCL_IB_HCA 以 tg_ 25 格式设置 tg_ 23。fabricId 的值应为 tg_ 27 之前的正整数，并解释为 tg_ 28，其中 tg_ 29 可以使用 NCCL_IB_FABRICID_MAXRAIL 设置。如果未设置，每个 fabricId 值将被解释为 tg_ 32 (即 tg_ 33 和 tg_ 34) 。具有不同 RAIL_ID 的设备将被解释为断开连接，而不管它们的 tg_ 36 如何。具有相同 RAIL_ID 和相同 tg_ 38 的设备将被解释为 tg_ 39，具有相同 RAIL_ID 和 differenttg_ 41 的设备将被设置为 tg_ 42。
第 3 步：网络拓扑引导算法
NCCL 包含三种算法系列：Ring、tg_ 44 (以及 tg_ 45 等变体) 和 tg_ 46。这些算法支持不同类型的群集和通信模式。在跨 DC 通信方面，我们重点研究了 Ring 和 tg_ 48 算法的更稀疏通信模式。下文详细介绍的所有更改均旨在实现两个目标： (1) 尽可能避免跨越 (通常较慢的) DC 间链路。(2) 利用尽可能多的网络设备进行 DC 间连接。后者在异构网络的用例中尤为重要，其中 DC 间连接的带宽和一般性能明显低于 DC 内连接。
环形算法
为避免多个 DC 间连接，我们在每个 DC 内优先重新排序。然后，打开每个环，并使用两个松散的一端将 DC 连接在一起。通过这种方法，我们可以保证跨 DC 连接的数量为 2*(nDc-1)，其中 nDc 是 DC 的数量。
对于异构网络，即使采用后一种方法，单个 DC 间设备也将成为整个集合性能的瓶颈 (请参见图 2) 。NCCL 会创建多个环 (图中有四个环) ，其中所有环都会在同一组节点之间通过直流连接。为了减轻这种影响，我们引入了散射 (通过 NCCL_SCATTER_XDC=1 启用) ，其中每个环将使用两个不同的节点通过直流连接。
性能提升是巨大的。例如，如果通信器每个节点包含四个 GPU (每个 GPU 具有 400 Gbps HCA) ，则单个跨直流连接必须提供 1.6 Tbps。启用散射后，对跨直流连接的要求降低到 400 Gbps；在实践中，通过增加每个 HCA 的通道数，以及使用的跨直流连接数，可以进一步降低这一要求。这种解释故意忽略了许多细节，例如选择通道数量和相关协议。尽管它不准确，但在启用散射时，它可以对信道行为提供强烈的直觉。
树算法
与环算法方法非常相似，这里的目标是避免跨 DC 连接的次数超过实际需要的次数，并允许散射将树分散到多个设备上，以避免出现单个设备瓶颈。我们首先在每个 DC 内构建树。由于 NCCL 构建树的方式，我们确定每个根都有一个空的子插槽和一个空的父插槽。这允许我们将每个 DC 的每棵树的根链接在一起，以便构建覆盖所有 DC 的全局树。新树的深度在 DC 数量上是线性的，在每个 DC 的节点数上是对数的。假设每个 DC 的节点数量恒定，我们获得的深度为 (nDC - 1) + log2(nNodes)。
通道散射的实现方式与环算法类似。树根是跨 DC 的实际通信对象，因此我们将它们分散在可用节点之间。这使得 NCCL 能够利用更多跨 DC 的连接，并消除潜在的瓶颈。
性能注意事项
DC 之间的连接质量可能会提升应用的整体性能。量化成对连接的性能非常重要，这样才能推断出 NCCL_SCATTER_XDC 和 tg_ 55 的正确值。第一种方法将实现通道在多个设备之间的散射，而第二种方法则用于控制 NCCL 将使用的通道数量。
以下是可能对跨直流连接达到峰值性能至关重要的各种参数的非详尽列表：
NCCL_IB_QPS_PER_CONNECTION用于更高延迟的 IB/ RoCE 连接。NCCL_NSOCKS_PERTHREAD和 tg_ 58 用于更高延迟的 TCP 连接。NCCL_SOCKET_INLINE和NCCL_SOCKET_MIN_TASKSIZE用于控制 TCP 消息大小和内联数据大小。NCCL_BUFFSIZE允许 NCCL 发送更大的消息。
总结
在最近的一项研究中，NCCL 支持在两个关键连接场景中跨多个 DC 的无缝集合通信。第一种是同构情况，即单个网络为 DC 间和 DC 内提供连接。其次是异构情况，其中使用不同的网络 (以及相应的技术) 来连接节点内部 DC 和内部 DC。
但是，我们发现对多个网络的支持不足以为 NCCL 提供足够的拓扑感知能力，因此无法提供最佳性能。为了填补这一空白，我们引入了 fabricID 以及新的 ncclNet API。这使得 NCCL 能够查询详细的网络拓扑，并做出相应的算法选择。为了演示我们的方法，我们使用网络拓扑信息来优化 NCCL 创建的环和树，以尽可能减少交叉 DC 连接的数量并提高性能。
在我们开发 AI 通信的未来时，我们迫切希望收集反馈，了解您如何使用 NCCL 进行跨 DC 通信、其性能以及我们方法中的任何缺点。请在开发者论坛上与我们联系，或在 Github 上分享您的反馈。
