NVIDIA 集合通信庫 (NCCL) 可實現針對 NVIDIA GPU 和網絡優化的多 GPU 和多節點通信基元。NCCL 是用于多 GPU 深度學習訓練的核心軟件。它可以處理任何類型的 GPU 間通信，無論是通過 PCI、NVIDIA NVLink 還是網絡。它使用先進的拓撲檢測、優化的通信圖形和調優模型，在 NVIDIA GPU 平臺上直接獲得出色性能。
在本文中，我們將討論 NCCL 2.26 中發布的新功能和修復。有關更多詳情，請訪問 NVIDIA/nccl GitHub 資源庫。請注意，NCCL 2.25 版本僅側重于 NVIDIA Blackwell 平臺支持，沒有庫功能更改。因此，尚未發布該版本的發布文章。
版本亮點
NVIDIA Magnum IO NCCL 是一個旨在優化 GPU 間和多節點通信的庫，對于 AI 和 HPC 應用中的高效并行計算至關重要。最新版本的 NCCL 顯著提升了性能、監控、可靠性和服務質量。以下功能支持這些改進：
- PAT 優化：CUDA 線程束級優化可改善 PAT 算法并行性。
- 隱式啟動順序：在多個通信器同時使用設備時防止死鎖，并檢測主機線程競速啟動。
- GPU 內核和網絡分析器支持：新事件允許在內核和網絡插件級別更全面地描述 NCCL 性能。
- 網絡插件 QoS 支持：Communicator 級質量服務 (QoS) 控制，允許用戶在通信器之間劃分可用網絡資源。
- RAS 改進：豐富了有關集合操作的信息，改進了診斷輸出，并增強了穩定性。
NCCL 2.26 特性
本節深入探討以下每個新功能的詳細信息：
- PAT 優化
- 隱式啟動順序
- 支持 GPU 內核分析器
- 網絡插件 profiler 支持
- 網絡插件 QoS 支持
- RAS 改進
PAT 優化
此更改通過分離不同線程束上 PAT 步驟的計算和執行來優化 NCCL 2.23 中引入的 PAT 算法。
與初始實施不同，每個線程將計算 PAT 步驟并一次執行一個步驟，現在一個線程專用于計算 PAT 步驟，并且多達 16 個 warp 可以并行執行來自 16 個不同并行樹的 16 個步驟。
在具有許多并行樹的情況下，此優化將有所幫助。也就是說，具有至少 32 個秩和小運算的情況，并且算法的線性部分開始限制其性能；通常是大規模的。
隱式啟動順序
當每個設備使用多個 NCCL 通信器時，NCCL 要求用戶將所有通信操作（通過 CUDA 流依賴項或同步）的順序序列化為一致的全局總順序。否則，如果設備端通信內核在不同秩上的順序不同，則可能會導致死鎖。
NCCL 2.26 可以選擇通過添加對由 NCCL_LAUNCH_ORDER_IMPLICIT 控制的隱式啟動順序的支持來放松此要求。如果啟用，NCCL 會在已啟動的通信內核之間添加依賴項，以確保設備端順序與主機上的啟動順序相匹配。這使得 NCCL 更易于正確使用，但由于這會增加延遲，因此在默認情況下處于關閉狀態。我們鼓勵難以調試掛起的用戶嘗試一下。
即使已啟用，用戶仍必須確保主機端啟動的順序與所有設備相匹配。通過從每個設備的單個主機線程按確定的順序啟動，即可輕松實現這一點。由默認開啟的 NCCL_LAUNCH_RACE_FATAL 控制的互補機制會嘗試檢測啟動到同一設備的多個主機線程之間的競爭。如果觸發，操作將中止，并返回錯誤。
支持 GPU 內核和網絡分析器
2.23 中引入的 NCCL 分析器插件接口現在支持 GPU 內核和網絡定義事件。
GPU 內核事件
在 2.26 版本之前，NCCL 分析器插件接口僅限于網絡代理事件。但是，這些事件僅捕獲部分 NCCL 行為，而忽略 GPU。為了解決這一限制，并向分析器用戶提供更準確的信息，在 2.26 中，NCCL 核心擴展了新的 kernel 分析器基礎設施，允許主機代碼監控獨立和融合內核 (即分組操作) 中單個集合和點對點操作的進度。
融合核函數會為每個通道的每個運算生成一個事件，允許分析器將其直接關聯到原始 NCCL 運算。
每當 NCCL 內核開始或結束執行新操作時，它會將其傳達給主機。相應地，NCCL 中的主機代碼會調用分析器 startEvent 或 stopEvent 回調函數。
分析器插件接口已通過新的 ncclProfileKernelCh 事件進行擴展，該事件可捕獲 NCCL 主機代碼觀察到的內核活動。其父節點為 ncclProfileColl 或 ncclProfileP2p 事件。
需要注意的是，NCCL 報告的 kernel 事件的準確性受到當前設計的限制，因為當前設計利用 proxy 線程 (也用于推進網絡操作) 來監控 GPU 內核活動。這一限制將在未來的 NCCL 版本中得到解決。
網絡定義事件
2.23 版本中引入的 NCCL 分析器插件接口僅限于 NCCL 核心事件。但是，用戶往往對網絡產生的事件感興趣。為解決 2.26 中的此限制，分析器插件接口已擴展，支持網絡定義事件。網絡插件開發者現在可以定義特定于插件的事件，并將其傳播到分析器插件。
這是通過 NCCL 中的以下擴展程序實現的：
- 新的
ncclProfileNetPlugin事件：NCCL 在代表網絡插件調用分析器時使用的 Wrapper 事件。 - V10 網絡插件接口擴展：將這些新事件應用于所有相關的初始化和數據操作功能。
ncclResult_t (*init)(ncclDebugLogger_t logFunction, ncclProfilerCallback_t profFunction) ncclResult_t (*isend)(void* sendComm, void* data, size_t size, int tag, void* mhandle, void* phandle, void** request) ncclResult_t (*irecv)(void* recvComm, int n, void** data, size_t* sizes, int* tags, void** mhandles, void** phandles, void** request) |
- NCCL 核心分析器回調：由網絡插件通過 NCCL 調用分析器。 eHandle：Profiler 插件事件句柄 (事件開始時返回值，事件停止時輸入值) 類型：啟動 (0) 或停止 (1) 網絡定義事件 pHandle：NCCL 核心內部對象的指針，由 NCCL 本身在 isend/irecv 調用期間提供，并由 NCCL 在回調期間將
ncclProfileNetPlugin事件鏈接到其父對象 pluginId：網絡和分析器插件用于同步網絡類型和事件版本的唯一標識符 (如果分析器插件無法識別所提供的 pluginId，則應忽略事件) extData：網絡定義事件，提供給分析器回調，并由 NCCL 作為ncclProfileNetPlugin事件的一部分傳播給分析器插件
ncclResult_t (*ncclProfilerCallback_t)(void** eHandle, int type, void* pHandle, int64_t pluginId, void* extData) |
用于kernel和network事件的經過更新的分析器事件層次結構如下所示：
ncclProfileGroup | +- ncclProfileColl/ncclProfileP2p | | | +- ncclProfileProxyOp | | | | | +- ncclProfileProxyStep | | | | | +- ncclProfileNetPlugin | | | +- ncclProfileKernelCh ncclProfileProxyCtrl |
網絡插件 QoS 支持
網絡通信中的 QoS 對于確保 HPC 工作負載的良好性能至關重要。例如，在 LLM 訓練期間，幾種類型的網絡通信會重疊，例如 pipeline parallelism (PP) 和 data parallelism (DP) 通信。PP 通信通常駐留在關鍵路徑上，而 DP 通信則不駐留。當這些通信重疊時，兩者都會在爭奪共享網絡資源時遇到減速。通過優先處理關鍵路徑上的通信，應用程序的端到端性能得到顯著提高。
為啟用 QoS，NCCL 使用 ncclCommInitRankConfig API 提供每個通信器配置選項。NCCL 現在支持現有 ncclConfig_t 結構中的新 trafficClass 字段。trafficClass 是一個整數，用于抽象表示通信網絡流量的 QoS 級別。應用程序可以使用默認值或用戶定義的設置來設置此字段。trafficClass 的具體含義由網絡系統管理員和網絡棧實現者決定。
struct { ... int splitShare; int trafficClass; // add trafficClass to communicator } ncclConfig_t |
NCCL 將 trafficClass 傳遞給網絡插件，而無需對其進行修改
網絡插件接口還通過新的 ncclNetCommConfig_t 結構進行擴展，該結構包含 trafficClass，并傳遞給網絡插件中的每個連接。例如，connect 函數會添加輸入參數 ncclNetCommConfig_t* config。
struct { int trafficClass; // Plugin-specifig trafficClass value } ncclNetCommConfig_t ncclResult_t (*connect)(int dev, ncclNetCommConfig_t* config, void* handle, void** sendComm, ncclNetDeviceHandle_v10_t** sendDevComm); |
網絡插件實現者可以使用 trafficClass 值在其網絡數據包中設置特定字段，以啟用 QoS。擴展插件接口旨在支持內部和外部網絡插件。例如，該值可以傳遞給 NCCL 內部的 net_ib 插件，如果定義了 trafficClass，則可用于配置 qpAttr.ah_attr.grh.traffic_class 字段。
RAS 改進
在此版本中，RAS 子系統的大部分更改都是內部增強功能，旨在大規模提高其穩定性和內存占用。用戶可見性改進包括：
- 針對每種操作類型，單獨報告集合操作計數中的不匹配。這可能有助于識別不確定的啟動順序場景。
- 提供有關未能報告的communicator等級的詳細信息。在 2.26 之前，在這種情況下只提供等級號，而 RAS 無法可靠地確定缺乏等級信息是由于該等級無法訪問，還是僅僅因為該等級不再是給定的communicator的成員。現在可以區分這兩種情況，前者報告為
INCOMPLETE錯誤，后者報告為MISMATCH警告，并具有新的NOCOMM等級狀態 (替換之前使用的UNKNOWN) 。
特定于 RAS 的修復包括：
- 避免計算圖形捕獲的collective。根據所使用的collective算法，一些截取圖形的collective操作可能會導致collective操作計數在秩之間不同步，從而導致RAS發出假陽性警告。圖形捕獲collective的計數功能現已禁用。
- 在終止之前清理 RAS 資源。這不僅可以避免來自各種第三方泄漏檢測工具的額外噪音，而且如果在不終止進程的情況下動態卸載 libnccl.so 庫，還可以避免在仍在運行的 RAS 線程嘗試執行未映射的代碼時崩潰。
問題修復和次要功能
NCCL 2.26 提供以下額外更新：
- 添加 Direct NIC 支持 (如果 GPU 通過 C2C 連接到 CPU，則適用于連接到 CPU 的 NIC 的 GPUDirect RDMA，通過
NCCL_NET_GDR_C2C進行控制) - 為 NCCL 診斷消息添加時間戳 (默認情況下，為 WARN 消息啟用；可通過
NCCL_DEBUG_TIMESTAMP_LEVELS和NCCL_DEBUG_TIMESTAMP_FORMAT進行配置) - 使用 NVLink SHARP 減少內存占用
- 將 Intel Emerald Rapids 和 Sapphire Rapids CPU 的性能數據整合到 NCCL 性能模型中
- 在 nccl.conf 文件中添加對注釋行 (以# 開頭) 的支持
- 修復了建立連接時split-shared通信器出現的競爭條件
- 修復了
NCCL_CROSS_NIC=1仍會交替環的性能回歸問題，這會破壞 GPU-NIC 關聯的環 - 改進了容器環境中的 IB/RoCE GID 檢測
- 修復了無阻塞通信的競爭條件，其中對不同communicator的連續集合操作可能導致崩潰
- 修復了 B203 上 NCCL 請求的共享內存超過設備支持的內存的問題
- 修復了當用戶中止communicator時，進程線程會旋轉網絡進度而導致的掛起問題
- 修復了 network plugin 的測試調用返回錯誤時的掛起問題
- 修復了混合不同架構時 rank 最終可能具有不同通信模式的掛起問題
- 修復了
ncclCommInitRank和ncclCommFinalize失敗時的雙重釋放崩潰問題 - 修復了在極少數情況下，config file中指定的一些變量可能會被忽略的問題
總結
NCCL 2.26 引入了一些重要的新功能和改進，包括 PAT 優化、隱式啟動排序、GPU 內核分析器支持、網絡插件分析器支持、網絡插件 QoS 支持和 RAS 改進。
如需詳細了解之前的 NCCL 版本，請參閱以下帖子：
- 2.24：使用 NCCL 2.24 實現大規模 Networking 可靠性和 Observability
- 2.23：使用 NVIDIA Collective Communications Library 的新擴展算法和初始化 2.23
- 2.22：NVIDIA Collective Communications Library的顯存效率、更快的初始化和成本估算 2.22
詳細了解 NCCL 和 NVIDIA Magnum IO。查看點播會議 NCCL：支持多 GPU AI 的 Inter-GPU 通信庫 | GTC 25 2025 | NVIDIA On-Demand
?
