Networking Reliability and Observability at Scale with NCCL 2.24
Networking Reliability and Observability at Scale with NCCL 2.24
文章标题： 通过 NCCL 2.24 实现规模化的网络可靠性与可观测性
作者/机构： Ben Williams / NVIDIA
A1 主要贡献
NVIDIA集合通信库（NCCL）是专为NVIDIA GPU和网络优化的多GPU和多节点（MGMN）通信原语实现库，是多GPU深度学习训练的核心软件。它负责处理各种GPU间的通信，无论是通过PCI、NVLink还是网络。NCCL利用先进的拓扑检测、优化的通信图和调优模型，在NVIDIA GPU平台上实现开箱即用的最佳性能。
本文介绍了NCCL 2.24版本中发布的新功能和修复，其核心贡献在于提升大规模场景下的可靠性、性能和易用性。具体创新点如下：
* 可靠性、可用性与服务性（RAS）子系统：引入了一个低开销的基础设施，用于在生产环境中查询NCCL作业的健康状况，帮助用户诊断应用程序的崩溃和挂起问题，并检测无响应节点或落后进程等异常情况。
* 多节点集合操作的用户缓冲区（UB）注册：扩展了用户缓冲区注册功能，使其支持多节点集合通信，特别是针对IB SHARP和标准的点对点网络中的Ring算法，从而减少开销，提升性能和计算通信重叠效率。
* NIC Fusion（网卡融合）：实现了一个灵活的系统，用于将多个物理网卡融合成一个逻辑设备，以解决在每GPU拥有多个网卡的系统上，NCCL算法可能出现的崩溃或调优不当问题。
* 可选接收完成（Optional Receive Completions）：针对LL和LL128协议引入的一项优化，允许网络插件在特定情况下跳过轮询网络接收完成事件，从而降低开销并减少大规模下的拥塞。
* FP8支持：在NVIDIA Hopper及更新架构上，增加了对e4m3和e5m2两种格式的FP8数据类型的原生归约（reduction）支持。
* 严格强制执行NCCL_ALGO和NCCL_PROTO：改变了先前对无效算法和协议选择进行静默回退的行为，现在会直接报错，以减少用户在基准测试或自定义调优时的困惑。
A2 方法细节
RAS子系统
RAS子系统的设计目标 NCCL 2.24中新增了可靠性、可用性与服务性（RAS）子系统，旨在帮助用户诊断应用程序的崩溃和挂起问题。在大规模场景下，对于不熟悉NCCL内部机制的用户而言，定位应用程序无进展的根本原因可能非常具有挑战性。
RAS的基础设施与工作原理 RAS是一个低开销的基础设施，可用于在生产环境中查询运行中NCCL作业的健康状况。它能提供运行中应用程序状态的全局视图，并有助于检测异常值，例如无响应的节点或落后于其他对等进程的单个应用进程。
RAS的架构与健康监测机制 RAS由一组线程（每个NCCL进程一个）组成，这些线程通过建立TCP/IP连接形成一个网络。线程利用该网络定期交换“keep-alive”消息来相互监控健康状况。如果某个NCCL进程崩溃或挂起，其与其他NCCL进程的RAS网络连接会关闭或变得无响应，从而将问题通知给其他进程上的RAS线程。
RAS的资源开销与启用方式 RAS是轻量级的。在空闲状态下，它使用极少的系统资源，不应干扰应用程序。该功能默认启用，但如果需要，可以通过设置NCCL_RAS_ENABLE=0环境变量来禁用。
RAS客户端工具 新提供的ncclras二进制客户端可以在运行NCCL作业的任何节点上调用，它会生成一份关于该作业的状态报告。作为替代方案，也可以使用telnet或netcat等标准工具连接到本地主机的28028端口来获取信息。
正常作业的RAS报告示例 以下是一个正常运行作业的输出示例。RAS会通过避免重复信息来保持报告的简洁性。在此示例中，所有32个NCCL进程和8个NCCL通信器都因其主要属性相同而分别显示在单行中。
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会收集每个通信器中每个rank的信息，并标记任何遇到的错误条件或差异。
进程落后（Lagging）的RAS报告示例 当检测到潜在问题时，摘要表下方会提供额外细节。在此示例中，32个rank中有6个在已发起的集合操作数量上落后于其他rank。
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对进程落后问题的分析 在通信密集期间，出现上述计数差异通常无需担忧。然而，如果多次调用RAS客户端后计数器没有增加，则可能需要进行调查。利用RAS提供的信息，可以使用交互式调试等深入技术来确定根本原因。
进程崩溃的RAS报告示例 如果作业中某个进程崩溃，可以预期看到以下输出，报告会指出有一个作业进程被视为“死亡”（通过RAS网络无法访问），并列出具体的进程和节点信息，同时通信器状态会显示为INCOMPLETE。
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: 21RAS的未来发展 NCCL 2.24包含了RAS的初始实现。计划在未来的NCCL版本中显著扩展其功能。
多节点集合操作的用户缓冲区（UB）注册
用户缓冲区注册的性能权衡 NCCL本身不要求用户注册和维护任何持久性缓冲区即可运行。尽管这个特性极大地提升了易用性，但也带来了性能上的权衡。如果没有直接访问权限，NCCL在传输数据时必须进行更多的控制流和缓冲操作，这会消耗更多的GPU资源，导致与显式注册和映射的缓冲区相比，移动相同数量数据时的开销更高。
缓冲区注册的优势 只要有可能，建议NCCL开发者使用ncclCommRegister来注册他们的缓冲区，以使NCCL能够利用所有可用的优化。这包括来自NvSwitch或IB SHARP等特殊硬件的优化，以及对点对点传输的更好优化。NCCL团队一直在努力为注册用户缓冲区增加更多的使用场景。
NCCL 2.24中UB注册的新增支持 NCCL 2.24为UB注册增加了对以下场景的支持：
* 多rank/节点集合网络通信：最显著的是支持IB SHARP。AllReduce、AllGather和ReduceScatter操作均受支持。这意味着使用单进程/GPU模式和FSDP通信后端的应用程序可以更好地利用IB SHARP技术。
* 标准点对点网络中的Ring算法：NCCL现在可以在标准点对点网络（如默认的IB插件）中，对ncclAllReduce、ncclAllGather和ncclBroadcast的Ring算法使用已注册的用户缓冲区。
UB注册的资源优化 此外，对于纯基于网络的AllGather和Broadcast Ring操作，NCCL将仅使用单个SM（流式多处理器），从而为计算节省GPU资源。只要用户缓冲区已通过ncclCommRegister调用注册，或者NCCL在CUDA graph内部使用，应用程序无需任何更改即可使用此功能。
UB注册的性能收益 初步性能测试显示，对于单GPU/节点的AllGather和Broadcast操作，性能有显著提升，同时SM使用量从4个减少到1个。对于8 GPU/节点的AllReduce和AllGather，通过用户缓冲区注册可实现5%的峰值带宽增长。预计应用程序将从改善的计算通信重叠中获得最大的性能收益。
NIC Fusion（网卡融合）
多NIC系统带来的挑战 随着NCCL支持的系统类型不断扩展，NCCL必须能适应并在所有这些系统上实现开箱即用的良好表现。特别是在拥有多个NIC（每GPU多于一个NIC）的系统上，观察到了以下问题：
1. NCCL算法设计为每GPU一个NIC，因此在每GPU两个或四个NIC的系统上，这些算法可能会崩溃。
2. NCCL核心调优代码也针对每GPU一个NIC设计。如果NIC过多，NCCL可能会过度调优，为通信占用过多SM，或者根本不使用某些NIC。
历史方案：Port Fusion 为了解决这个问题，NCCL 2.21实现了一个名为Port Fusion的功能。在这个初始方案中，默认的IB插件在返回给NCCL核心之前，会自动将双端口设备合并为单个逻辑设备。这对于双端口NIC系统是有效的，但并未解决其他多NIC用例。
Port Fusion未覆盖的场景 自那时起，NCCL团队扩展了此功能，以解决以下一些场景：
* 未被检测为双端口的NIC（无论是它们本身就不是，还是虚拟机管理程序未将其显示为双端口）。
* 四端口系统。
* 任意设备合并。
* 按拓扑距离自动合并。
Port Fusion的局限性 此外，Port Fusion还有一些需要克服的局限性：
* 它期望每个端口都表现为同一PCI设备的独立VF。
* 它在插件中覆盖了每个NIC的物理属性，如果用户想将拓扑转储到文件，会呈现一个虚假的拓扑。
* 在决定是否合并NIC时，它不尊重用户提供的拓扑，而只使用操作系统提供的PCI地址。这在PCI地址可能呈现不同的虚拟化场景中是个问题。
NIC Fusion的引入与设计 为了解决这些限制，NIC Fusion被创建出来。它是一个灵活的系统，其中NCCL核心区分物理设备和虚拟设备，并根据用户指定的标准明确选择要融合的设备。此外，NIC Fusion确保NCCL转储的任何拓扑文件仅包含系统上的物理设备，虚拟设备是在初始化过程的后期创建的。
NIC Fusion的工作流程 NIC Fusion的工作过程分为多个步骤。首先，NCCL像以前一样枚举网络插件返回的所有网络设备，并将它们作为物理设备存储在其拓扑中。然后，它检查插件是否与NIC Fusion兼容。如果兼容，NCCL将启动一个合并过程。如果用户定义了一组要显式合并的NIC（使用NCCL_NET_FORCE_MERGE变量），NCCL会在进行自动合并之前，先执行一轮任意合并。
自动合并过程 自动合并是一个相当复杂的过程，始于搜索每对物理NIC之间的距离。NCCL遍历每个物理NIC，将每个NIC与最多三个在自动合并距离级别内（由NCCL_NET_MERGE_LEVEL指定）的其他NIC放入一个新的虚拟设备中。此过程最终会将所有物理设备都放入虚拟设备中。
拓扑更新 最后，如果发生了NIC Fusion，NCCL会从其拓扑中剥离所有物理设备，并用虚拟设备替换它们，然后再进入图的形成和搜索阶段（此阶段与之前相比没有变化）。
负载均衡机制 工作负载可以由网络插件选择的任何方式在给定的融合NIC上进行负载均衡。默认的IB插件中已实现此功能，采用简单的方式将给定发送或接收操作的流量平均分配到所有融合的设备上。
NIC Fusion的插件API 为了在网络插件中利用NIC Fusion，需要关注新的API。NCCL使用makeVDevice来指示插件将设备融合在一起，必须实现此函数才能进行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;
ncclResult_t (*makeVDevice)(int* d, ncclNetVDeviceProps_t* props);API工作方式 NCCL会编译一个设备列表并将其发送给插件。插件应分配一个新的设备索引来引用这个新的虚拟设备，并用该值填充d指针，然后返回成功。NCCL将使用这个新值来引用新设备。
强制合并配置 在此之后，用户可以控制合并的发生方式。用户可以指定NCCL_NET_FORCE_MERGE来强制NCCL合并任意一组设备。NCCL期望它是一个以分号分隔的融合NIC数组，每个融合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的默认行为。尽管其底层工作方式大不相同，但默认情况下它仍然只会像Port Fusion那样合并双端口NIC。
NIC Fusion使用说明
* 在不需要它的系统上，NIC Fusion不会提升性能。建议保持NIC Fusion设置为默认值，除非您在每GPU拥有两个或更多NIC的系统上运行，并且发现性能或SM使用存在问题。
* 将与GPU距离不同的NIC融合在一起可能会导致性能不佳或不可预测。
NIC Fusion的未来潜力 这是一项基础功能，可以帮助插件更清晰地实现更高级的功能，例如NIC故障转移和动态负载均衡。
可选接收完成（Optional Receive Completions）
优化动机 NCCL团队持续分析网络插件API，以确定新的API或现有API的扩展是否能为NVIDIA客户带来更多价值和性能。一项可能的优化得益于NCCL LL和LL128协议的特性，NCCL 2.24中增加了对此的支持。
技术原理 在使用LL或LL128协议时，由于协议固有的同步机制，NCCL可能不需要轮询网络接收完成事件。LL和LL128协议依赖嵌入在数据本身中的标志来向接收方GPU发出数据已到达的信号。GPU将轮询GPU内存中的数据，一旦接收到数据，它将开始处理，而无需等待网络堆栈发出完成信号。跳过这个接收完成步骤可以让网络插件省去额外的信令和同步，从而降低开销并减少大规模下的拥塞。
实现方式 从2.24版本开始，NCCL核心在调用irecv时可能会将请求指针对象设置为NCCL_NET_OPTIONAL_RECV_COMPLETION（值为0x1）。这是给插件的一个提示，表明此操作不需要显式同步。请注意，NCCL仍会对此请求调用test函数，该函数仍应告知NCCL请求已完成并清理任何跟踪结构。
功能启用 这是一个可选择加入的功能，可用于额外的优化。现有的网络插件将继续按原样执行。可以通过设置NCCL_NET_OPTIONAL_RECV_COMPLETION=0来禁用可选接收完成。
FP8支持
FP8数据类型 NCCL现在支持原生的FP8归约操作，支持e4m3和e5m2两种格式。这些数据类型仅在NVIDIA Hopper及更新的架构上启用。
严格强制执行NCCL_ALGO和NCCL_PROTO
行为变更 以前，当用户指定无效算法时，NCCL会静默回退到支持的算法和协议。鉴于这在基准测试或强制自定义调优时会引起大量困惑，NCCL团队决定终止这种做法。现在，当指定的NCCL_ALGO或NCCL_PROTO不受支持时，NCCL会返回一个错误，而不是静默回退。
功能增强 除了严格检查外，NCCL 2.24还增加了更强大的语义，使用户能够使用这些变量进行灵活的强制调优。有关详细信息，请参阅NCCL_ALGO和NCCL_PROTO的文档。
A4 实验环境与结果
实验环境
本文作为一篇功能发布介绍，并未提供详细的实验环境配置信息，例如所使用的具体硬件平台（GPU型号/数量、网卡、CPU）、软件栈（CUDA版本、操作系统）或用于性能测试的模型及数据集。
实验结果
文章中提到了关于用户缓冲区（UB）注册功能的一些初步性能测试结果：
* 单GPU/节点场景的性能: 针对AllGather和Broadcast操作，启用UB注册后观察到“强大的性能增益”，同时，GPU上用于通信的流式多处理器（SM）使用量从4个减少到1个。
* 八GPU/节点场景的性能: 对于AllReduce和AllGather操作，使用用户缓冲区注册可实现峰值带宽提升5%。
* 性能分析结论: 启用UB注册带来的最大性能好处来自于改善了计算与通信之间的重叠效率。
A7 补充细节
NCCL 2.24提供了以下额外的更新和错误修复：
* 调整PAT调优，以改善PAT和Ring算法在大规模场景下的转换。
* 默认使用cuMem*系列函数进行主机内存分配。
* 当NCCL_SOCKET_IFNAME设置为不正确的值时，返回ncclInvalidUsage错误，而不是之前的ncclInternalError。
* 修复了UDS（Unix Domain Sockets）中的文件描述符泄漏问题。
* 修复了混合使用缓冲区注册和图缓冲区注册时可能发生的崩溃。
* 修复了使用dmabuf进行用户缓冲区注册的问题。
* 修复了IB代码中因字段未初始化导致的崩溃。
* 修复了非阻塞ncclSend/ncclRecv的问题。
* 各种编译器相关的调整和修复。
* 修复了ncclTopoPrintGraph中的一个拼写错误。
A5 结论
NCCL 2.24引入了数项重要的新功能和改进，关键增强包括RAS子系统、对多节点集合操作的用户缓冲区注册支持、NIC Fusion以及可选接收完成功能，同时还增加了对FP8数据类型的支持。这些更新旨在提升NCCL在大规模AI数据中心网络中的可靠性、可观测性和性能。
对于未来的工作，文中提到：
* RAS子系统计划在未来的NCCL版本中进行功能上的显著扩展。
* NIC Fusion作为一项基础性功能，为将来实现NIC故障转移和动态负载均衡等更高级的插件功能奠定了基础。
💬 评论讨论
欢迎在这里分享您的想法和见解！