NVIDIA 集合通信库 (NCCL) 实现了针对 NVIDIA GPU 和网络优化的多 GPU 和多节点 (MGMN) 通信基元。NCCL 是用于多 GPU 深度学习训练的核心软件。 它可以处理任何类型的 GPU 间通信，无论是通过 PCI、NVLink 还是网络。它使用先进的拓扑检测、优化的通信图形和调优模型，在 NVIDIA GPU 平台上直接获得出色的性能。如需了解有关 NCCL 的更多信息，请访问 NVIDIA/nccl GitHub 仓库 。
在本文中，我们将讨论 NCCL 2.24 中发布的新功能和修复程序。
NCCL 2.24 的新功能
我们将特别解释以下新功能：
- 可靠性、可用性和可服务性 (RAS) 子系统
- 多节点集合的用户缓冲区（User Buffer，UB）注册
- 网卡融合
- 可选接收完成
- 支持 FP8
- 严格执行
NCCL_ALGO和NCCL_PROTO
RAS 子系统
NCCL 2.24 中添加了 RAS 子系统，可帮助用户诊断应用崩溃和挂起。在大规模上，识别应用程序缺乏进展的根本原因对于不太熟悉 NCCL 的用户可能具有挑战性。
RAS 是一种低开销基础架构，可在生产环境中用于在 NCCL 作业执行期间查询其运行状况。它提供了正在运行的应用程序状态的全局视图，可以帮助检测异常值，例如无响应的节点或单个应用程序进程落后于对等节点。
RAS 由一组线程 (每个 NCCL 进程一个) 组成，这些线程彼此建立 TCP/IP 连接，形成一个网络，然后线程使用该网络通过定期交换 keep-alive 消息来监控彼此的运行状况。如果 NCCL 进程崩溃或挂起，其与其他 NCCL 进程的 RAS 网络连接将关闭或变得无响应，从而将问题通知这些进程上的 RAS 线程。
RAS 是轻量级的。在空闲状态下，它使用的系统资源最少，不应干扰应用程序。默认情况下，此功能处于启用状态，但如果需要，可以通过提供 NCCL_RAS_ENABLE=0 环境变量将其禁用。
新提供的 ncclras 二进制客户端可在运行 NCCL 作业的任何节点上调用，它会生成有关作业的状态报告 (或者，可以通过连接到端口 28028 上的 localhost 来使用 telnet 或 netcat 等标准工具)。
正常进行中的作业的输出示例如下所示。
Job summary
===========
Nodes Processes GPUs Processes GPUs
(total) per node per process (total) (total)
4 8 1 32 32
Communicators... (0.00s)
=============
Group Comms Nodes Ranks Ranks Ranks Status Errors
# in group per comm per node per comm in group
0 8 4 1 4 32 RUNNING OK
RAS 试图通过避免重复来缩短其状态报告。在本示例中，所有 32 个 NCCL 进程以及所有 8 个 NCCL 通信器都列在一行中，因为它们共享相同的主要属性。
生成报告时，RAS 会收集每个通信者的每个等级的信息，并标记遇到的任何错误条件或差异。
Group Comms Nodes Ranks Ranks Ranks Status Errors
# in group per comm per node per comm in group
0 1 4 8 32 32 RUNNING MISMATCH
Warnings
========
#0-0 (27a079b828ff1a75) MISMATCH
Communicator ranks have different collective operation counts
26 ranks have launched up to operation 6650
6 ranks have launched up to operation 6649
Rank 0 -- GPU 0 managed by process 483072 on node 172.16.64.210
Rank 2 -- GPU 2 managed by process 483074 on node 172.16.64.210
Rank 3 -- GPU 3 managed by process 483075 on node 172.16.64.210
Rank 4 -- GPU 4 managed by process 483076 on node 172.16.64.210
Rank 5 -- GPU 5 managed by process 483077 on node 172.16.64.210
Rank 7 -- GPU 7 managed by process 483079 on node 172.16.64.210
确定潜在问题后，我们会在汇总表下方提供更多详细信息。在本例中，32 个秩中有 6 个在已发布的集合运算数量方面落后于其他秩。在激烈沟通期间，这不应成为引起关注的原因。
但是，如果计数器在重复调用 RAS 客户端时没有增加，则可能需要进行调查。借助 RAS 提供的信息，可以使用交互式调试等深入钻取技术来确定根本原因。
如果其中一个作业进程崩溃，预计会有以下输出：
Group Comms Nodes Ranks Ranks Ranks Status Errors
# in group per comm per node per comm in group
0 1 4 7-8 32 32 RUNNING INCOMPLETE
Errors
======
DEAD
1 job process is considered dead (unreachable via the RAS network)
Process 3487984 on node 172.16.64.213 managing GPU 5
#0-0 (cf264af53edbe986) INCOMPLETE
Missing communicator data from 1 rank
The missing rank: 21
NCCL 2.24 包含 RAS 的初始实现。我们计划在未来的 NCCL 版本中显著扩展功能。
多节点群集的 UB 注册
NCCL 不需要用户注册和维护任何持久性缓冲区才能正常运行。虽然此功能非常易于使用，但确实需要权衡性能。如果没有直接访问，则在 NCCL 传输数据时，必须出现更多的控制流和缓冲。与显式注册和映射缓冲区相比，这将消耗更多的 GPU 资源，导致在移动相同数量的数据时产生更高的开销。
建议 NCCL 开发者尽可能使用 ncclCommRegister 注册缓冲区，以使 NCCL 能够使用所有可用的优化。这包括 NvSwitch 或 IB Sharp 等特殊硬件的优化，以及更好的点对点传输优化。NCCL 团队一直致力于为已注册的用户缓冲区添加更多用例。NCCL 2.24 增加了对以下各项的 UB 注册支持：
- 每个节点的多个 rank 集合网络，尤其是 IB SHARP 网络。支持 AllReduce、AllGather 和 ReduceScatter。这意味着，使用每个 GPU 一个进程和 FSDP 通信后端运行的应用程序可以更好地利用 IB SHARP 技术。
- NCCL 现在使用标准对等网络 (例如默认的 IB 插件) 中的注册用户缓冲区来运行 Ring 算法。支持
ncclAllReduce、ncclAllGather和ncclBroadcast。
此外，对于基于纯网络的 AllGather 和 Broadcast Ring 操作，NCCL 将只使用单个 SM，从而节省用于计算的 GPU 资源。使用此功能无需更改应用程序，只要在用户缓冲区上调用了 ncclCommRegister，或者在 CUDA 图形中使用了 NCCL。
初步性能测试表明，每个节点一个 GPU 的 AllGather 和 Broadcast 操作具有强劲的性能提升，同时将 SM 使用量从四个减少到一个。对于每个节点 8 个 GPU 的 AllReduce 和 AllGather，使用用户缓冲区注册可将峰值带宽增加 5%。您有望看到改进的计算重叠为您的应用程序带来最大的性能优势。
网卡融合
随着 NCCL 支持的系统分类的扩展，NCCL 必须进行自我调整，以便在所有系统上开箱即用。也就是说，在使用多个 NIC (每个 GPU 多个 NIC) 系统时，出现了以下问题：
- NCCL 算法旨在为每个 GPU 使用一个 NIC，因此在两个 NIC 连接一个 GPU 或四合一的系统中，这些算法可能会崩溃。
- NCCL 核心调优代码还专为每个 GPU 一个 NIC 而设计。如果有许多 NIC，NCCL 可能会自行优化，占用过多的 SM 进行通信，或者选择完全不使用其中一些 NIC。
为解决此问题，NCCL 2.21 实现了一项名为 Port Fusion 的功能。在此初始解决方案中，默认 IB 插件会自动将双端口设备合并到单个逻辑设备中，然后返回 NCCL 核心。这适用于双端口 NIC 系统，但无法解决任何其他许多 NIC 用例。此后，NCCL 团队扩展了此功能，以解决以下部分场景：
- 未检测到为双端口的 NICs（原因可能是根本未检测到，或者 hypervisor 未将其显示为双端口）
- 四端口系统
- 任意合并设备
- 按拓扑距离自动合并
此外，Port Fusion 还需要克服一些限制：
- 它期望每个端口都作为同一 PCI 设备的单独 VF 呈现。
- 它会覆盖插件中每个 NIC 的物理属性，如果用户想将其转储到文件中，则会显示错误的拓扑。
- 在决定合并 NIC 时，它不考虑用户提供的拓扑结构。相反，它只使用操作系统提供的 PCI 地址。当 PCI 地址以不同方式呈现时，这是虚拟化场景中的一个问题。
NIC Fusion 旨在解决这些限制。这是一个灵活的系统，NCCL 核心可区分物理设备和虚拟设备，并根据用户指定的标准明确选择要融合的设备。此外，NIC Fusion 可确保 NCCL 丢弃的任何拓扑文件仅包含系统上的物理设备。在初始化的后期阶段创建虚拟设备。
NIC Fusion 是一个多步骤过程。首先，NCCL 枚举网络插件返回的所有网络设备，与之前相同。它将这些作为物理设备存储在其拓扑结构中。然后，它会检查插件是否与 NIC Fusion 兼容。如果是，则 NCCL 将启动合并过程。如果用户已 (使用 NCCL_NET_FORCE_MERGE 变量) 定义了一组要合并的显式 NIC，则 NCCL 会在转向自动合并之前先执行任意合并。
自动合并是一个相当复杂的过程，从搜索每对物理 NIC 之间的距离开始。NCCL 通过每个物理 NIC 循环，将每个 NIC 放置到一个新的虚拟设备中，其中最多包含三个在自动合并距离级别 (由 NCCL_NET_MERGE_LEVEL 指定) 内的其他设备。此过程会将所有物理设备置于虚拟环境中。
最后，如果发生 NIC 融合，NCCL 会将所有物理设备从其拓扑中分离出来，并将其替换为虚拟设备，然后再转向图形形成和搜索（与之前相同）。
网络插件可以在给定的融合 NIC 上选择任何方式来平衡工作负载。这已在默认 IB 插件中实现，对于给定的发送或接收操作，可在所有融合设备上对流量进行简单的均匀分割。
要详细说明在网络插件中使用 NIC Fusion 需要执行哪些操作，请先查看新 API：
#define NCCL_NET_MAX_DEVS_PER_NIC_V9 4
typedef struct {
int ndevs;
int devs[NCCL_NET_MAX_DEVS_PER_NIC_V9];
} ncclNetVDeviceProps_v9_t;
typedef ncclNetVDeviceProps_v9_t ncclNetVDeviceProps_t;
...
// Create a virtual NIC given the specified properties, which can be accessed at device index d
ncclResult_t (*makeVDevice)(int* d, ncclNetVDeviceProps_t* props);
NCCL 使用 makeVDevice 来指示插件将设备融合在一起，并且必须实施该插件才能实现 NIC 融合。NCCL 将编译设备列表并将其发送到插件。插件应分配一个新的设备索引，以引用此新虚拟设备并在返回成功前填充该值。NCCL 将使用此新值来引用新设备。
之后，用户控制合并的发生方式。用户可以指定 NCCL_NET_FORCE_MERGE 来强制 NCCL 合并任意一组设备。NCCL 期望它是一个以分号分隔的融合 NIC 数组，每个数组都由一个以逗号分隔的物理 NIC 名称列表组成。例如：
NCCL_NET_FORCE_MERGE=mlx5_0,mlx5_1;mlx5_2,mlx5_3;mlx5_4,mlx5_5,mlx5_6;mlx5_7
这将导致 NCCL 创建虚拟设备 mlx5_0+mlx5_1、mlx5_2+mlx5_3,mlx5_4+mlx5_5+mlx5_6 和 mlx5_7。请注意，任何未指定的设备仍将被使用，但除非它们符合自动合并标准，否则不会合并在一起。
所有剩余的 NIC 将通过 NCCL_NET_MERGE_LEVEL 进行合并。这控制了 NCCL 自动融合物理 NIC 的拓扑距离。默认值为 PORT。这使得 NIC Fusion 的默认行为与 NCCL 2.21 至 2.23 中的行为相同，其中双端口 NIC 合并在一起。
其他可能的选项包括 LOC (禁用任何融合) 、PIX (相同的 PCI 交换机) 、PXB (相同的 PCI 交换机树) 、PHB (相同的 CPU) 或 SYS (相同的系统) 。NIC Fusion 将自动使用所提供拓扑文件 (如果指定) 中的 PCI 路径，或仅使用系统返回的值 (realpath) 。
NIC Fusion 不应影响 NCCL 的默认行为。尽管在后台的工作方式完全不同，但默认情况下，它仍将仅合并双端口 NIC，就像 Port Fusion 一样。
NIC Fusion 注意事项：
- 在不需要 NIC Fusion 的系统上，NIC Fusion 不会提高性能。建议单独保留 NIC Fusion 设置，除非您在每个 GPU 有两个或两个以上的 NIC 的系统上运行，并且您发现性能或 SM 使用存在问题。
- 将距离不同的 NICs 融合到 GPU 可能会导致性能不佳或不可预测。
这是一项基础功能，可以帮助插件清晰地实现更高级的功能，例如 NIC 故障转移和动态负载均衡。
可选接收完成
该团队持续分析 NCCL 网络插件 API，以确定新 API 或现有 API 的扩展是否可以为 NVIDIA 客户带来更多价值和性能。其中一种可能的优化得益于 NCCL LL 和 LL128 协议的功能。两者都具有内置同步功能，可以放松网络插件的要求，NCCL 2.24 中增加了对这一功能的支持。
使用 LL 或 LL128 协议时，由于协议本身具有同步性，NCCL 可能不需要轮询网络接收完成项。LL 和 LL128 协议依靠嵌入在数据本身中的标志来向接收端 GPU 发送数据已到达的信号。GPU 将轮询 GPU 内存中的数据，一旦收到数据，它就会开始处理数据，而无需等待网络堆栈发出完成命令。跳过此接收完成功能可以让网络插件跳过额外的信令和同步，从而大规模降低开销并减少拥塞。
从 2.24 版本开始，在调用 irecv 时，NCCL 核心可以将请求指针对象设置为 NCCL_NET_OPTIONAL_RECV_COMPLETION (0x1) 。这是插件的提示，说明此操作不需要显式同步。请注意，NCCL 仍会针对此请求调用 test，并且仍应告知 NCCL 请求已完成并清理任何跟踪结构。
这是一项可选择加入的功能，可用于进行额外优化。现有网络插件的性能将一如既往。可以通过设置 NCCL_NET_OPTIONAL_RECV_COMPLETION=0 来禁用可选的接收完成。
支持 FP8
NCCL 现在支持 e4m3 和 e5m2 格式的原生 FP8 归约。这些数据类型仅在 NVIDIA Hopper 和更新的架构上启用。
严格执行 NCCL_ALGO 和 NCCL_PROTO
以前，当用户指定无效算法时，NCCL 会悄无声息地退回到支持的算法和协议。鉴于在基准测试或强制进行自定义调整时，这会导致大量混淆，NCCL 团队已决定结束这种做法，并在指定的 NCCL_ALGO 或 NCCL_PROTO 不受支持时返回错误，而不是悄无声息地返回。
除了严格检查之外，NCCL 2.24 还添加了更强大的语义，使用户能够灵活地使用这些变量进行调整。有关详细信息，请参阅 NCCL_ALGO 和 NCCL_PROTO 文档。
问题修复和次要功能
NCCL 2.24 提供以下额外更新：
- 调整 PAT 调优以改善 PAT 和 Ring 在大规模下的过渡
- 默认使用
cuMem*函数分配主机内存 - 当
NCCL_SOCKET_IFNAME设置为错误值而非ncclInternalError时，返回ncclInvalidUsage - 修复 UDS 中的 FD 泄漏
- 修复了混合缓冲区注册和图形缓冲区注册时崩溃的问题
- 使用 dmabuf 修复用户缓冲区注册问题（Fix user buffer registration with dmabuf）
- 修复了未初始化的字段导致 IB 代码崩溃的问题
- 修复了非阻塞的 ncclSend/ncclRecv 问题
- 各种编译器调整和修复
- 修复了
ncclTopoPrintGraph中的拼写错误
总结
NCCL 2.24 引入了一些重要的新功能和改进，包括大规模可靠性和可观察性、RAS 子系统、多节点群集的用户缓冲区注册支持以及 FP8 数据类型支持。主要增强功能包括 RAS 子系统、用于多节点群集的 UBR、NIC Fusion 和可选的接收完成。
如需详细了解之前的 NCCL 版本，请参阅以下帖子：
- 使用 NVIDIA Collective Communications Library 2.23 实现新的扩展算法和初始化
- 借助 NVIDIA Collective Communications Library 2.22 提高显存效率、加快初始化和成本估算
详细了解 NCCL 和 NVIDIA Magnum IO 。此外，还可以查看“ 大规模训练深度学习模型：NCCL 如何在 AI 数据中心网络上实现出色性能 ”的点播会议。
