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 32Communicators... (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 MISMATCHWarnings========#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 INCOMPLETEErrors======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 4typedef 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 數據中心網絡上實現出色性能 ”的點播會議。
?
?
