一、背景

模型越來越大，需要的 GPU 越來越多；與此同時 GPU 性能也在不斷增強，配套的網(wǎng)絡(luò)帶寬也不斷增加到 400G（Blackwell GPU 甚至需要到 800 Gbps）。Ranking 模型還在遷移到 GPU 的早期階段，但使用 GPU 的規(guī)模也在不斷增加；而 LLM 通常需要使用更大規(guī)模 GPU。在構(gòu)建這種規(guī)模的網(wǎng)絡(luò)的同時保持高性能 GPU 間通信很有挑戰(zhàn)。

Meta 在其 LLaMA 3 技術(shù)報告中簡單提到用于訓練 LLaMA 3 的大規(guī)模 GPU 集群，不過在報告中并沒有詳細介紹其集群的構(gòu)成以及相應(yīng)的網(wǎng)絡(luò)解決方案。Meta 最近發(fā)布了相應(yīng)的 Paper，我們這里進行簡單介紹。

對應(yīng)的論文為：Proceedings of the ACM SIGCOMM 2024 Conference: RDMA over Ethernet for Distributed Training at Meta Scale

對應(yīng)的 Meta Blog：RoCE networks for distributed AI training at scale - Engineering at Meta

二、摘要

近年來，AI 模型的計算密度和規(guī)模都快速增長，推動了高效、可靠的專用網(wǎng)絡(luò)基礎(chǔ)設(shè)施的建設(shè)。本文中，Meta 作者介紹了其用于分布式 AI 訓練的 RoCE 網(wǎng)絡(luò)設(shè)計、實現(xiàn)和運維。

其設(shè)計原則涉及對工作負載的深刻理解，作者將這些間接轉(zhuǎn)化為各種網(wǎng)絡(luò)組件的設(shè)計：

• 網(wǎng)絡(luò)拓撲：為了支持幾代 AI 硬件平臺的快速演進，將基于 GPU 的訓練分離到自己的后向網(wǎng)絡(luò)中。
• 路由：訓練工作負載本身就會導(dǎo)致負載不均衡和流量突發(fā)，因此作者部署了多次迭代的路由方案，以實現(xiàn)接近最優(yōu)的流量分布。
• 傳輸：解釋了最初如何嘗試使用 DCQCN 運行擁塞管理，不過后來放棄了 DCQCN，轉(zhuǎn)而利用集合通信庫來管理擁塞。
• 運維：作者分享了大規(guī)模 AI 網(wǎng)絡(luò)運維的經(jīng)驗，包括開發(fā)的工具和故障排查示例。

三、引言

3.1 IB & RoCEv2

RDMA 是一種硬件輔助通信加速的行業(yè)標準，RDMA 實現(xiàn)了 “verbs” API，比如讀和寫（可以參考：RDMA Verbs API - NVIDIA Docs）。與基于 TCP/IP 的通信不同，基于 TCP/IP 的通信中，數(shù)據(jù)包需要先發(fā)送到內(nèi)核，然后再復(fù)制到 CPU 內(nèi)存中，而 RDMA 繞過了發(fā)送方和接收方的內(nèi)核，直接從應(yīng)用進程內(nèi)存中傳遞數(shù)據(jù)。如下圖所示：

如下圖所示為幾種常見的 RDMA 方案，現(xiàn)在比較常見的是 IB 和 RoCEv2：

• IB 是 NVIDIA 提供的一種專用的高性能計算網(wǎng)絡(luò)技術(shù)，具有專用的網(wǎng)絡(luò)架構(gòu)和硬件設(shè)備，IB 使用專用的 InfiniBand 協(xié)議棧，包括物理層、鏈路層、網(wǎng)絡(luò)層和傳輸層，專門設(shè)計以優(yōu)化高性能計算和低延遲通信。
• RoCEv2 是一種在標準以太網(wǎng)基礎(chǔ)上實現(xiàn) RDMA 的協(xié)議，RoCEv2 使用常見的以太網(wǎng)交換機和網(wǎng)卡，因此更容易與現(xiàn)有的以太網(wǎng)基礎(chǔ)設(shè)施集成。?

RDMA verbs 消息封裝在以太網(wǎng)/IPv6/UDP 數(shù)據(jù)包中，并通過常規(guī)以太網(wǎng)絡(luò)進行傳輸，打包/解包封裝在 RDMA NIC 硬件中處理。如下圖所示為對應(yīng)的 RoCEv2 Packet Format：

3.2 集合通信（Collective Communicatin）

集合通信庫（如 NCCL）充當訓練工作負載和 NIC 之間的軟件抽象，通過 verbs API 層提供接口。它將集合通信原語（如 AllReduce）轉(zhuǎn)換為邏輯拓撲實現(xiàn)（如 Ring 或 Tree），并進一步將這些分解為 GPU 之間基于 verbs 的 P2P 數(shù)據(jù)傳輸。這些傳輸需要 GPU-to-RDMA NIC 支持。集合通信庫在源和目標 NIC 之間創(chuàng)建的隊列對（Queue Pairs, QP）協(xié)調(diào) verbs 調(diào)用。例如，NCCL 使用 RDMA 寫入操作實現(xiàn)所有集合算法和 P2P 語義（具體可以參考 NCCL 的 ISSUE why uses rdma write for default ib traffic · Issue #609 · NVIDIA/nccl · GitHub）。

如下圖 Table 1 列出了主要集合通信原語的特點以及每種集合通信的要求：

• 首先：集合通信原語由并行策略決定。比如，分布式數(shù)據(jù)平行（DDP）使用 AllReduce；FSDP 使用 AllGather 和 ReduceScatter；Ranking 模型（例如 DLRM）使用 AlltoAllv（矢量化的 AlltoAll）來為模型并行分發(fā) Embedding。
• 其次：集合通信原語可以生成多種網(wǎng)絡(luò)流量模式。比如 AlltoAll 在所有 endpoint 之間形成 Full Mesh 流量模式，可能導(dǎo)致高度暫時性的網(wǎng)絡(luò)擁塞。然而，它的高活躍流量簡化了路由，可以使用哈希方案降低持續(xù)擁塞風險。
• 最后：集合通信原語選擇的邏輯拓撲會影響 GPU 之間的網(wǎng)絡(luò)擁塞和數(shù)據(jù)交換。與 Tree 方案相比，基于 Ring 實現(xiàn)的 AllReduce 具有獨特的擁塞和哈希沖突含義。NCCL 會根據(jù) GPU 數(shù)量和 Message 大小等因素優(yōu)化相應(yīng)選項。然而，這種方法也有局限性，比如，由于硬編碼配置文件導(dǎo)致的潛在不確定性、某些消息大小或大型作業(yè)的性能不佳，以及一些實現(xiàn)中集合通信算法的不相關(guān)性。?

3.3 訓練工作負載

為了了解生成環(huán)境中實際的工作負載，作者利用 Chakra（[2305.14516] Chakra: Advancing Performance Benchmarking and Co-design using Standardized Execution Traces） 收集了 2023 Q4 期間大約 30K 個隨機選擇的訓練任務(wù)的集合通信數(shù)據(jù)。如下圖 Figure 1:

• （a）Job 大小趨勢：這里主要是分析 GPU <= 128 的情況，也就是不包含大規(guī)模的 LLM Job?？梢钥闯觯琂ob 的 GPU 數(shù)通常是 8 的整數(shù)倍，這是因為單機 8 個 GPU，此外，作者也不推薦使用小于 8 卡運行（PS：小于 8 卡確實容易導(dǎo)致碎片化問題，但是有些小型任務(wù)也確實沒必要使用 8 卡 H100，不過也許 Meta 有 A100 集群，可以讓小型任務(wù)跑在 A100 上）。
• （b）通信類型分布：基于 DDP 的任務(wù)中，AllReduce 和 AlltoAll(v) 占絕大部分；基于 FSDP 的任務(wù)中，會額外多了一些 AllGather 和 ReduceScatter。?

如下圖 Figure 2 所示為不同模型中各類通信原語實際通信 Message 大?。ㄍㄐ诺脑財?shù)量）的分布，可以看出，不同模型的 Message 大小變化很大：

每個集合通信操作中 GPU 數(shù)量的趨勢：無論是 Ranking Job，還是 LLM Job，每個集合通信操作中 GPU 的數(shù)量并沒有與 Job 大小以相同的速度增長。這是因為在大規(guī)模訓練中會使用多維并行策略，這有助于限制最大集合通信操作中 GPU 的數(shù)量，即使運行的 Job 中有成千上萬個 GPU。因此，本文中的其他部分主要關(guān)注涉及 16-128 個 GPU 的集合通信操作。

3.4 Shallow Buffer Switch & Deep Buffer Switch

在網(wǎng)絡(luò)交換機設(shè)計中，緩沖區(qū)（Buffer）是用來臨時存儲數(shù)據(jù)包的內(nèi)存區(qū)域，通常用于應(yīng)對網(wǎng)絡(luò)流量高峰或者臨時的擁塞情況。根據(jù)緩沖區(qū)大小的不同，交換機可以分為淺緩沖交換機（Shallow Buffer Switch）和深緩沖交換機（Deep Buffer Switch）。

• Shallow Buffer Switch

• 小緩沖區(qū)：每個端口通常配置有相對較小的內(nèi)存緩沖區(qū)（例如幾百 KB 到幾 MB）。
• 低延遲：由于緩沖區(qū)較小，淺緩沖交換機通常具有較低的轉(zhuǎn)發(fā)延遲，適合延遲敏感的應(yīng)用場景。
• 適用場景：淺緩沖交換機通常用于低延遲、高性能的環(huán)境中，當網(wǎng)絡(luò)流量相對穩(wěn)定且網(wǎng)絡(luò)拓撲設(shè)計良好時，淺緩沖交換機的性能表現(xiàn)良好。

• Deep Buffer Switch
• 大緩沖區(qū)：每個端口配置了較大的內(nèi)存緩沖區(qū)（可以達到幾十 MB 甚至更多），能夠存儲大量的數(shù)據(jù)包。
• 高緩沖能力：深緩沖交換機在面對突發(fā)流量或持續(xù)擁塞時，可以有效防止數(shù)據(jù)包丟失，因為其緩沖區(qū)能夠在網(wǎng)絡(luò)擁塞期間存儲更多的數(shù)據(jù)包。
• 適用場景：深緩沖交換機適合那些存在大量突發(fā)流量或復(fù)雜流量模式的環(huán)境，如數(shù)據(jù)中心的邊緣路由、以及需要應(yīng)對突發(fā)流量的大規(guī)模分布式系統(tǒng)。

比如 NVIDIA 的 SN4000 系列以太網(wǎng)交換機都是 64MB 的 fully shared buffer（https://nvdam.widen.net/s/6269c25wv8/nv-spectrum-sn4000-product-brief）如下圖所示；而最新的 SN5000 系列也只有 160MB 的 fully shared buffer。

而 ARISTA 的 7800R3 系列交換機都采用 Deep packet buffer，最多可以達到 24GB/line（7800R3 Series Data Center Switch Router）

3.5 DSCP-based PFC

在傳統(tǒng)的以太網(wǎng)中，流量擁塞時會導(dǎo)致數(shù)據(jù)包丟失，從而影響網(wǎng)絡(luò)性能。為了解決這個問題，出現(xiàn)了優(yōu)先級流控（PFC, Priority Flow Control），它通過暫停某些優(yōu)先級的流量來防止擁塞，但PFC 是基于端口優(yōu)先級（CoS, Class of Service）進行控制的。

DSCP 是一種在 IP 頭中用于標識 IP 包優(yōu)先級的字段。通過在 PFC 中引入 DSCP 字段，網(wǎng)絡(luò)設(shè)備可以根據(jù) IP 數(shù)據(jù)包中的 DSCP 值來識別不同的流量類別，并根據(jù)這些類別實施更加細粒度的流量控制策略。

相比傳統(tǒng)的基于 CoS 的 PFC，DSCP-based PFC可以實現(xiàn)更精確的流量分類與管理，因為DSCP 字段的范圍更廣，可以定義更多的優(yōu)先級和流量類別。因此，DSCP-based PFC 允許網(wǎng)絡(luò)管理者在處理流量擁塞時，針對不同的流量類型采取不同的流控策略，避免對關(guān)鍵應(yīng)用的影響，同時確保其他低優(yōu)先級的流量不會完全丟失。

四、硬件

4.1 訓練節(jié)點

4.1.1 概覽

訓練節(jié)點配置上與常見的 8*H100 Server 相當，同樣是每個 GPU 對應(yīng) 1 個 400G NIC，并且 8 個 GPU 通過 NVSwitch 實現(xiàn)全互聯(lián)。不過其結(jié)構(gòu)有所不同，采用 Grand Teton 平臺，如下圖所示為 Grand Teton 系統(tǒng)的概覽，其分為 3 個 Tray：

• Intel CPU Tray：

• 兩個 CPU，通過 UPI 連接。
• 每個 CPU 還會連接一個前向網(wǎng)絡(luò)對應(yīng)的 400G NIC。
• 每個 CPU 有 4 個 PCIe Gen5x16 與 Switch Tray 連接，連接其中的 2 個 PCIe Gen5 Switch。

• Switch Tray：
• 主要是 4 組 PCIe Gen5 Switch。
• 每組 PCIe Gen5 Switch 有 2 個 400G NIC，4 個 NvMe（或 2 個）。
• 每組 PCIe Gen5 Switch 還會通過 2 個 PCIe Retimer 分別連接一個 GPU。
• GPU Tray（Accelerator Tray）
• 8 個 GPU，通過 NVLink Switch 實現(xiàn)全互聯(lián)。?

PS：PCIe Retimer 是一種用于延長 PCIe 信號傳輸距離并增強信號完整性的硬件設(shè)備。隨著 PCIe 鏈路速率的增加（如PCIe 4.0、5.0 甚至 6.0），信號衰減和噪聲問題變得更加嚴重，特別是在長距離傳輸或使用質(zhì)量較低的電纜和連接器時。PCIe Retimer 通過 Retiming, Re-amplifying 和 Re-shaping 來減少這些問題。

4.1.2 Intel CPU Tray

如下圖所示為其 CPU Tray 的結(jié)構(gòu)：

• 最上面每個 CPU Socket 的 4 個 PCIe Gen5 會與 Switch Tray 連接。
• 兩個 CPU 之間有 3 個 UPI line。
• 每個 CPU 又通過 PCIe Gen 5x16 連接一個 OCP NIC。
• CPU 0 通過 DMI 連接 PCH。?

4.2 網(wǎng)絡(luò)拓撲

4.2.1 網(wǎng)絡(luò)概覽

如下圖 Figure 5 所示為其前向（Frontend）和后向（Backend）網(wǎng)絡(luò)拓撲：

• 前向網(wǎng)絡(luò)：前向網(wǎng)絡(luò)通過Fabric 交換機（FSW）和Rack 交換機（RSW）連接。前向網(wǎng)絡(luò)會連接存儲，用于為訓練提供數(shù)據(jù)供給。會保證前向網(wǎng)絡(luò)具有足夠的入口帶寬，以避免阻塞 GPU 的工作負載。
• 后向網(wǎng)絡(luò)：后向網(wǎng)絡(luò)是專用網(wǎng)絡(luò)，可在非阻塞架構(gòu)中連接所有RDMA NIC，從而在集群中的任意兩個 GPU 之間提供高帶寬、低延遲和無損傳輸。后向網(wǎng)絡(luò)利用RoCEv2 協(xié)議，該協(xié)議將 RDMA 服務(wù)封裝在 UDP 數(shù)據(jù)包中，以便通過網(wǎng)絡(luò)進行傳輸。?

4.2.2 后向網(wǎng)絡(luò)

如下圖 Figure 6 所示為其后向網(wǎng)絡(luò)拓撲，是典型的 3 層 Clos 網(wǎng)絡(luò)，最下兩層由多個獨立的 AI Zone（PS：類似其他方案中的 Pod），然后多個 AI Zone 通過 Aggregator Training Switch（ATSW）連接。

• AI Zone：兩層 Clos 拓撲，無阻塞

• Leaf Switch 對應(yīng) Rack Training Switch（RTSW），使用銅制 DAC 電纜連接 Rack 內(nèi)的 GPU NIC。
• Spine Switch 對應(yīng) Cluster Training Switch（CTSW），通過單模光纖和 400G 可插拔光模塊連接 RTSW。
• 同一個 Zone 內(nèi)的 Rack 通過 CTSW 實現(xiàn) Full Mesh 互聯(lián)，構(gòu)成無收斂網(wǎng)絡(luò)。

• DC-Scale 和拓撲感知調(diào)度：
• LLaMA 3 技術(shù)報告中提到單個 AI Zone 有 3072 GPU，而這往往無法滿足大規(guī)模 LLM 預(yù)訓練的需求。為了解決這一問題，作者設(shè)計了 Aggregator Training Switch（ATSW），以實現(xiàn)在數(shù)據(jù)中心內(nèi)部連接多個 AI Zone，將 RoCE 域擴展到 AI Zone 之外。
• 其在 CTSW 的上下行采用了 1:7 的收斂比，因此在調(diào)度時應(yīng)盡量減少跨 AI Zone 的流量。
• 為了緩解跨 AI Zone 流量的瓶頸，作者增強了訓練 Job 調(diào)度器（會感知 GPU 服務(wù)器之間的拓撲位置，推薦排序后的分配方案），以便將 Job 放在最合適的位置，減少跨 AI Zone 的流量，從而減少 Job 執(zhí)行時間。?

如下圖所示為我們根據(jù) LLaMA 3 技術(shù)報告數(shù)據(jù)繪制的集群網(wǎng)絡(luò)拓撲（PS：不一定嚴格對齊），其總共包含 24K GPU，采用 3 層 Clos 網(wǎng)絡(luò)：

• RACK：每個 Rack 包含 2 個 Server，每個 Server 包含 8 個 H100 80GB HBM3 GPU，8 個 400G NIC。每個 Rack 中都有一個 TOR（top-of-the-fack） Switch。
• ToR Switch：采用  Minipack2 ToR Switch（PS：實際上最多可以支持 64 個 400G Port），這里只使用了 32 個。其中 16 個下行 Port 連接 16 個 NIC，16 個上行 Port 連接到中間層 Cluster Switch。
• Cluster Switch：采用 Arista 7800 系列 Switch（PS：參考Arista 7800R3 Series，有多個版本，分別可以提供 576/432/288/144 個 400G Port，圖中以 288 Port 版本為例）。

• 一個 Pod 里有 192 個 Rack，也就是有 192 個 ToR Switch，Pod 里的每個 Cluster Switch 都會與所有 ToR Switch 連接，實現(xiàn) Full Mesh，1:1 收斂比。所以每個 Pod 需要有 16 個 Cluster Switch。一個 Pod 內(nèi)就可以包含 192*16=3072 個 H100 GPU，并且這些 GPU 通信最多都只用通過 3 跳，并且 1:1 無收斂。
• Cluster 的上下行 Port 沒有采用 1:1 對稱，而是采用了 1:7 有收斂的方案。也就是說，如果下行 Port 是 192 個，則上行大約是 28 個 400G Port，此時 Cluster Switch 也只使用了 220 個 Port。

• Aggregation Switch：每個 Cluster Switch 只有 28 個上行 Port，而總共有 16*8=128 個 Cluster Switch，因此可以使用 28 個 Aggregation Switch 將所有 Cluster Switch 連接起來，每一個都連接所有 Cluster Switch，對應(yīng)每個 Aggregation Switch 使用 128 個 400G Port。
• Data Center：總共有 8 個 Pod，也就是 24K H100 GPU。?

五、路由

5.1 挑戰(zhàn)

在 AI 訓練工作負載中有如下幾個有挑戰(zhàn)性的特點：

• 流量模式的低熵（Low Entropy）：分布式訓練中的流量模式在 UDP 5 元組中表現(xiàn)出低熵現(xiàn)象（“熵”是一種衡量既定網(wǎng)絡(luò)流量的豐富性和多樣性的方法，流量特征值的微小變化產(chǎn)生低熵值，而流量特征值的顯著變化則導(dǎo)致較高的熵值）。一個 GPU 通常被一個訓練作業(yè)占用，其邏輯拓撲通常是稀疏的，這給路由中均勻分配流量以實現(xiàn)最佳性能帶來了挑戰(zhàn)。使用靜態(tài) ECMP 的傳統(tǒng)技術(shù)中，需要“高熵”來將流量均勻路由到多個鏈路上，而不出現(xiàn)擁塞。
• 突發(fā)性：在時間維度上，由于計算負載往往大得多，而且節(jié)點內(nèi)可以通過 NVSwitch 通信，導(dǎo)致 RoCE 網(wǎng)絡(luò)中的流量通常具有突發(fā)性，通信時間可能只有幾毫秒。
• 大象流：針對低熵場景，多個流可能出現(xiàn)在同一條鏈路上，從而出現(xiàn)流量熱點，導(dǎo)致?lián)砣?、延遲增加等。

5.2 ECMP 和路徑固定

5.2.1 ECMP

作者最初考慮使用廣泛采用的 ECMP，它根據(jù)五元組的哈希值隨機放置數(shù)據(jù)流：源 IP、目標 IP、源 UDP 端口、目標 UDP 端口以及協(xié)議。然而，由于低熵問題，ECMP 在訓練工作負載中表現(xiàn)不佳。作者使用最大均值比（MMR，也就是負載最大鏈路的流數(shù)量和每個鏈路平均的流數(shù)量之比）來衡量 ECMP 均衡性，這是因為集合通信中的大多數(shù)數(shù)據(jù)流大小相同。作者觀察到 16 個鏈路模擬中 1000 個流的平均 MMR 超過 1.2。如下圖 Table 2 所示，實際上這種情況要糟糕的多。這種負載不均衡會導(dǎo)致大象流發(fā)生碰撞的概率大得多，從而造成嚴重擁塞并降低網(wǎng)絡(luò)吞吐量和 Job 性能。

5.2.2 路徑固定

作者早期部署了固定路徑的方案，該方案根據(jù)目標“切片”（RTSW 下行鏈路索引）將數(shù)據(jù)包路由到特定路徑。如果每個 Rack 都完全分配給同一個作業(yè)，并且網(wǎng)絡(luò)中沒有故障，則這種方案非常有效。然而，事實往往并非如此，分散的 Job 導(dǎo)致流量分布不均，特定 RTSW 的上行鏈路擁塞，使訓練性能下降達 30% 以上；此外，部分網(wǎng)絡(luò)故障也會加劇重新分配的流與現(xiàn)有流發(fā)生沖突，并減慢 Job 訓練速度。

5.2.3 短期和長期方案

通過將 RTSW 上行鏈路帶寬升級 2 倍，可以減輕這些流量沖突的影響，但是這種方式非常昂貴，因此作者認為這是一種短期的緩解措施，并著手進一步將路由演進到新的階段。

5.3 增強的 ECMP

接下來，作者重新審視 ECMP，旨在通過集合通信庫中的隊列對（QP）擴展其軟件功能來增加分層集合通信的流數(shù)。

5.3.1 QP 擴展

通過在多個 QP 上發(fā)送消息，以便將每個 NIC 到 NIC 流的消息發(fā)送為多個流。作者發(fā)現(xiàn)，啟用該功能低熵仍然存在，并且活動 QP 的數(shù)量更多。通過調(diào)試發(fā)現(xiàn)，目標 UDP 端口對于不同的 QP 數(shù)據(jù)包保持相同，但某些極端情況下，源 UDP 的端口也是如此，因此熵并沒有像預(yù)期那樣增加。

5.3.2 自定義哈希

作者將交換機配置為執(zhí)行增強型 ECMP（E-ECMP），以使用交換機 ASIC 的 UDF 功能對 RoCE 數(shù)據(jù)包的目標 QP 字段進行額外哈希。這增加了熵，如下圖 Figure 7 所示，與沒有 QP 擴展的 ECMP 基線相比，E-ECMP 和 QP 擴展使得 AllReduce 集合通信性能提高 40%：

5.3.3 QP 權(quán)衡

QP 緩沖區(qū)是 RDMA NIC 中的稀缺資源，QP 資源在 Ranking 和 LLM 工作負載之間的使用方式不同。對于 Ranking 工作負載，因為其通常涉及 Full Mesh 通信（例如 AlltoAll），本身已經(jīng)具有相對比較高的熵，因此使用 QP=4。而對于 LLM 工作負載，往往涉及分層集合通信（比如 AllReduce），熵比較低，因此使用 QP=16。其結(jié)果如下圖 Figure 8 所示：

5.3.4 不同 QP 擴展方案

作者評估了兩種 QP 擴展策略：

• 第一種：將本應(yīng)在單個 QP 上發(fā)送的每個消息拆分到多個 QP 上，從而變成多個流。但它也導(dǎo)致產(chǎn)生了更多的比較小的消息，以及更多的 ACK。
• 第二種：以輪詢方式將每條消息發(fā)送到不同的隊列。

對于生產(chǎn)環(huán)境中的 NCCL 消息大小，作者觀察到第二種方案表現(xiàn)良好，這項功能對于 ECMP 的可擴展性非常重要，因為它增加了分層集合通信（如 AllReduce）的網(wǎng)絡(luò)流。

PS：如果使用 NCCL 的話，可以使用 “NCCL_IB_QPS_PER_CONNECTION” 和 “NCCL_IB_SPLIT_DATA_ON_QPS” 兩個環(huán)境變量來調(diào)整：

• NCCL_IB_QPS_PER_CONNECTION：用于控制每個連接使用的 Queue Pair (QP) 的數(shù)量。
• NCCL_IB_SPLIT_DATA_ON_QPS：決定是否基于 QP 數(shù)量來分割數(shù)據(jù)，啟用這個選項后，NCCL 會根據(jù)可用的 QP 數(shù)量將數(shù)據(jù)進行分割，以實現(xiàn)更高效的數(shù)據(jù)傳輸。

5.3.5 超越 E-ECMP 的動機

雖然通過 QP 擴展改善了 ECMP 性能，但哈希的隨機性依舊是此路由方案的缺點。此外，根據(jù)工作負載類型定制 QP 擴展因子和方案，雖然在短期內(nèi)可行，但長期來看其增加了運維的復(fù)雜性。

5.4 中心化流量工程

從硬件角度來看，ECMP 和路徑固定方案都有局限性。因此，作者借鑒 EBB: Reliable and Evolvable Express Backbone Network in Meta 和 Engineering Egress with Edge Fabric: Steering Oceans of Content to the World，通過開發(fā)中心化流量工程（Tfaffic Engineering，TE）控制器來解決這些問題。TE 控制器根據(jù)實時工作負載和拓撲動態(tài)優(yōu)化路由。如下圖 Figure 9 所示為 TE 的架構(gòu)，展示了如何優(yōu)化動態(tài)路由分配：

5.4.1 控制平面

控制平面包含 3 個組件：

• Collector創(chuàng)建端到端訓練集群的實時拓撲。它通過 Topology Generator 服務(wù)從內(nèi)部數(shù)據(jù)倉庫 bootstrap 一個靜態(tài)拓撲。此外，它根據(jù) Open/R（內(nèi)部鏈路狀態(tài)路由協(xié)議）提供的鏈路狀態(tài)構(gòu)建動態(tài)拓撲。
• TE Engine將來自 Traffic Matrix Collector 服務(wù)提供的流量矩陣（例如，流 bps）和 Training Job Scheduler 的作業(yè)排布相結(jié)合，以得出流量矩陣（即 TE 分配的流量的字節(jié)數(shù)量）。TE Engine 運行有約束最短路徑優(yōu)先（CSPF）算法來處理實時拓撲和流量矩陣，定期（例如每 30s）生成優(yōu)化的流量排布。
• Switch Programmer獲取流量排布并將其轉(zhuǎn)換為設(shè)備特定的數(shù)據(jù)平面原語以執(zhí)行路由決策。

5.4.2 數(shù)據(jù)平面

數(shù)據(jù)平面基于覆寫默認路由策略的理念運行。默認路由由 BGP（Border Gateway Protocol） 提供，確保集群中所有前綴的連通性。TE 根據(jù)優(yōu)化的流量排布在 TRSW 上覆寫這些默認路由決策，從而為 RDMA 流量提供主路由。TE 包含能夠?qū)?<源端口、目標前綴> 元組與轉(zhuǎn)發(fā)到下一跳的操作關(guān)聯(lián)的技術(shù)。使用源+目標元組提供更精細的流量管理，而使用目標前綴則有助于在硬件中保持這些條目的規(guī)?？晒芾?。具體來說，利用硬件提供的精確匹配（EM）表來覆蓋默認路由。當主條目因故障而缺失時，BGP 確定的路由決策作為 RDMA 流量的備份。

5.5 對比 TE 和 E-ECMP

作者通過流量網(wǎng)絡(luò)模擬器對 TE 和 E-ECMP 性能進行評估，然后是生產(chǎn)基準測試結(jié)果。最后是描述每種方案的復(fù)雜性。

5.5.1 模擬

生產(chǎn)作業(yè)排布的模擬結(jié)果表明，在非最優(yōu)作業(yè)調(diào)度場景下，每個源-目標對有 4 個 QP 的 E-ECMP 平均比 roofline 完成時間長 40%。將 QP 擴展到 32 個可以改進性能：最壞情況從 roofline 的 20% 提高到 52%。然而，大多數(shù) Job 都無法達到 roofline 的頂部。相比之下，當網(wǎng)絡(luò)中有足夠的容量時，TE 可以根據(jù)實際需求實現(xiàn) 100% 的利用率。然而，當網(wǎng)絡(luò)鏈路出現(xiàn)故障，低于 1:1 訂閱比時，TE 可能被 E-ECMP 超越。 

5.5.2 基準評估

在可控環(huán)境中，與 16 個上行鏈路設(shè)置上的 E-ECMP 相比，TE 在現(xiàn)實世界的 NCCL 基準上的鏈路利用率更加均衡。使用 E-ECMP 時，鏈路利用率差異很大：最大帶寬的 40%-90%；而 TE 均衡使用最大帶寬的 80%，減少了最壞的情況。如下圖 Figure 10 所示，在 128 個訓練節(jié)點下，TE 在 AllReduce 和 AlltoAll 集合通信中的表現(xiàn)比 E-ECMP 高出 5%-10%：

5.5.3 TE 的運維經(jīng)驗的教訓

作者在用于 Ranking 的 AI Zong 中部署 TE，并使用 E-ECMP 作為備用路由方案，以處理受故障影響的流量。作者觀察到，TE 在負載均衡方面與早期階段的固定路由方案類似：在仿真建模中表現(xiàn)良好，然而在網(wǎng)絡(luò)中發(fā)生多個鏈路故障時，TE 性能會下降，并且在實踐中發(fā)生的頻率比預(yù)期要高。此外，TE 還帶來了額外的軟件復(fù)雜性和開銷。雖然在 AI Zone 部署中可以管理，但并沒有應(yīng)用于整個數(shù)據(jù)中心（跨 Zone），這是因為網(wǎng)絡(luò)規(guī)模增加時，其額外的復(fù)雜性和開銷會進一步放大。因此，E-ECMP 為數(shù)據(jù)中心規(guī)模的集群提供了更好的運維平衡。

綜上，TE 作為針對 Ranking 工作負載的集群的主要路由方案，而 E-ECMP 是數(shù)據(jù)中心規(guī)模部署的主要路由方案。

5.6 未來方向：Flowlet Switching

雖然 TE 和 E-ECMP 構(gòu)成了作者的路由策略，并且適用于不同的部署場景，但是每種策略都有其權(quán)衡。

Flowlet Switching（Let it flow: resilient asymmetric load balancing with flowlet switching） 是一種替代方案，旨在解決上述兩種路由策略中出現(xiàn)的問題。該方案依賴于在流中發(fā)現(xiàn)間隙，當發(fā)現(xiàn)間隙時，流引擎會根據(jù)負載重新將流分配給新的 ECMP 成員端口。這是一種硬件輔助方案，由第一跳交換機（RTSW）支持，該交換機以微秒級的粒度對端口負載的變化做出響應(yīng)。在作者的測試中，這種方案在負載均衡和擁塞以及多鏈路故障場景下都表現(xiàn)出了卓越的性能。該方案的適應(yīng)性有助于以最小的 QP 擴展比例的情況下應(yīng)用到所有的工作負載，而無需根據(jù)工作負載定制 QP 擴展，有助于緩解 E-ECMP 的問題。

六、傳輸

6.1 概覽

不同級別網(wǎng)絡(luò)擁塞：分布式訓練會產(chǎn)生獨特的 Full Mesh 和分層流量模式（如 Tree 和 Ring），這兩種模式會產(chǎn)生不同的擁塞模式，如上 Table 2 中的 Buffer 占用率也不同。針對這種情況也沒有標準的最佳實踐來處理擁塞問題。如下圖 Figure 3 所示為 Ranking 模型和 LLM 的流量模式：

上一部分討論了由于負載均衡效率低下導(dǎo)致的持續(xù)擁塞的解決方案。然而，即使流量分配完美，集合通信流量模式（如 AlltoAll）也可能導(dǎo)致臨時緩沖區(qū)的積壓和突增。這種現(xiàn)象也引申出了對流量控制和擁塞控制的需求，以便通過避免流量丟棄和提供可預(yù)測的尾延遲來實現(xiàn)可預(yù)測的性能。這個部分深入探討相應(yīng)的傳輸設(shè)計和解決方案，以應(yīng)對與網(wǎng)絡(luò)擁塞相關(guān)的挑戰(zhàn)。

6.2 實現(xiàn)

作者實現(xiàn)了多種傳輸配置，以在 RoCE 設(shè)置中實現(xiàn)高帶寬、低延遲和可預(yù)測時延。

• 與 NIC 供應(yīng)商合作，將 GPUDirect 與 Linux 內(nèi)置驅(qū)動相結(jié)合，以提高軟件棧的可管理性。
• 使用 DSCP-based PFC，以及跨所有網(wǎng)絡(luò)交換機和 NIC 的單個無損隊列來防止 Layer 3 網(wǎng)絡(luò)連接上的數(shù)據(jù)包丟棄。
• 依靠 go-back-N 重傳機制來處理由于網(wǎng)絡(luò)不健康或鏈路抖動/關(guān)閉而導(dǎo)致的罕見數(shù)據(jù)包丟棄。然而，確認數(shù)據(jù)包（ACK 或 NACK）上的丟棄可能會導(dǎo)致本地 ACK 超時（LAT）長達毫秒級。因此，快速識別和隔離不健康的網(wǎng)絡(luò)元素和鏈路，并仔細調(diào)整 LAT 持續(xù)時間，對于可預(yù)測的訓練工作負載至關(guān)重要。

6.3 擁塞控制

雖然 PFC 有助于避免擁塞丟包，但在持續(xù)擁塞期間，逐跳的 PFC 傳播可能會導(dǎo)致 Head-of-Line（HoL）阻塞，從而導(dǎo)致流量不公平或性能不佳。作者最初為 200G 網(wǎng)絡(luò)部署了 DCQCN，這與之前的 RDMA 部署建議一致。作者的實現(xiàn)涉及以下幾點：

• 擁塞期間，交換機對正在傳輸?shù)臄?shù)據(jù)包進行 ECN 標記。
• 接收方 NIC 生成并發(fā)回擁塞通知數(shù)據(jù)包（CNP），以指示在收到標記的數(shù)據(jù)包時需要減慢流量。
• 發(fā)送方根據(jù)收到的 CNP 減少相應(yīng)流量的注入。

6.3.1 針對集合通信調(diào)優(yōu) DCQCN 的局限性

作者在部署 200G 和 400G RDMA 網(wǎng)絡(luò)時，發(fā)現(xiàn) DCQCN（也就是 RoCE 默認的擁塞控制）對于訓練中的集合通信不符合預(yù)期。

如下圖 Figure 12 所示，作者在 200G RDMA 部署中使用默認的 DCQCN 算法，并使用了更加嚴格的 ECN 閾值配置來最小化 PFC，然而調(diào)整后的性能（藍色）還不如 Baseline 的性能（紅色）。

如下圖 Figure 13 所示，通過進一步的微調(diào)，可以以 3%（非常微?。┑膬?yōu)勢獲得更好的完成時間，而 PFC 這樣的擁塞指標也變得更加糟糕。因此，作者采用了寬松的 ECN 標記，允許 CTSW 中建立緩沖區(qū)，同時保留默認的 DCQCN 配置。這也說明了調(diào)優(yōu) DCQCN 是一項非常有挑戰(zhàn)性的工作。

當網(wǎng)絡(luò)進一步過渡到 400G 時，作者識圖進一步調(diào)整 DCQCN 以適應(yīng)新的網(wǎng)絡(luò)速度和拓撲結(jié)構(gòu)。然而，作者發(fā)現(xiàn)固件中的 DCQCN 實現(xiàn)已經(jīng)改變，因此在 400G 網(wǎng)絡(luò)中并沒有采用 DCQCN。也就是，僅使用 PFC 進行流量控制，而沒有其他任何傳輸層擁塞控制。

6.3.2 通過集合通信庫的接收端驅(qū)動流量準入

為了緩解 400G 及更高速度的擁塞，作者聯(lián)合設(shè)計了集合通信庫和 RoCE 傳輸，強制以接收端驅(qū)動流量準入，以實現(xiàn)更好的性能。如下圖 Figure 14 所示，生產(chǎn)環(huán)境中使用的 GPU-to-GPU 通信架構(gòu)主要是 NCCL，其使用兩階段復(fù)制和接收端發(fā)起通信。每個 GPU 的 HBM 維護多個 Channel，用于并行傳輸分塊消息。

1. 發(fā)送端 GPU 線程首先將數(shù)據(jù)從計算緩沖區(qū)復(fù)制到可用 Channel 緩沖區(qū)。
2. 發(fā)送端 CPU proxy 線程只有在接收到接收端的 CTS（clear-to-send） 數(shù)據(jù)包后，才能發(fā)送 RDMA 寫入請求，該數(shù)據(jù)包包含大小和內(nèi)存信息。
3. 接收端的 GPU 線程然后將 Channel 緩沖區(qū)的內(nèi)容復(fù)制到對應(yīng)的 Compute 緩沖區(qū)。
4. 最后，雙方 CPU proxy 線程回收 Channel 緩沖區(qū)，接收端 CPU proxy 線程在 Channel 緩沖區(qū)準備好后發(fā)送另一個 CTS 數(shù)據(jù)包。?

作者充分利用這一機制作為接收端驅(qū)動的流量準入，以限制網(wǎng)絡(luò)上的 in-flight 流量，尤其是網(wǎng)絡(luò)擁塞開始堆積時。然而，配置正確的設(shè)置也比較有挑戰(zhàn)性：

• GPU 顯存與并發(fā)計算操作之間的資源競爭，通道數(shù)量受限。
• 因為 RoCE 的流量控制更為粗粒度，并且可能存在 end-host 緩慢的問題，因此設(shè)置 Channel 緩沖區(qū)大小需要比 IB 更仔細的平衡。

因此，作者采取了兩個措施來提高性能：

• 通過實驗確定在不同訓練 Job 大小和集合通信類型下 Channel 數(shù)量和 Channel 緩沖區(qū)大小。
• 在交換機上實現(xiàn)高優(yōu)先級隊列，以便為 CTS 數(shù)據(jù)包提供高優(yōu)先級，以加快通知并緩解潛在的帶寬饑餓問題。

PS：NCCL 中可以通過 NCCL_BUFFSIZE 設(shè)置緩沖區(qū)大小，也可以通過 NCCL_MAX_NCHANNELS 和 NCCL_MIN_NCHANNELS 現(xiàn)在 Channel 數(shù)目。

6.3.3 吸收網(wǎng)絡(luò)內(nèi)擁塞

前面提到過，對于單個 AI Zone 而言，其是 2 層 Clos 架構(gòu)，作者對 RTSW 使用具有共享和淺緩沖區(qū)架構(gòu)的交換機，CTSW 使用具有深緩沖區(qū)架構(gòu)的交換機。利用每個 Port 的大緩沖區(qū)有助于吸收任何短暫的擁塞，并確保 Port 能應(yīng)對背壓（back pressure），從而減少 Port 之間的 HoL 阻塞。鑒于 Spine 交換機的基數(shù)很高，作者認為這種無阻塞架構(gòu)是減少擁塞的額外的安全層。

6.4 討論

擁塞控制一直是 RDMA 網(wǎng)絡(luò)研究的重點。DCQCN 一直是以存儲為中心的網(wǎng)絡(luò)的“黃金標準”。但是，作者在分布式 AI 訓練工作負載方面的經(jīng)驗為定制擁塞控制算法提供了不同的視角。盡管關(guān)閉了 DCQCN，并且多個 RTSW 實例將 PFC 發(fā)送到開啟 deep-buffer 的 CTSW，但在過去 4 年中，作者并沒有遇到生產(chǎn)環(huán)境 AI 訓練流量導(dǎo)致 CTSW 持續(xù)向 RTSW 發(fā)送 PFC 的情況。具體來說，值得評估在沒有傳輸級擁堵控制的情況下運維的可行性。作者目前的解決方案依賴于集合通信庫和網(wǎng)絡(luò)之間的精心協(xié)調(diào)，可能依賴于 GPU 和網(wǎng)絡(luò)之間的相對吞吐量，這可能不適用于所有場景。

七、實驗

7.1 聯(lián)合調(diào)優(yōu)網(wǎng)絡(luò)和集合通信

由于開發(fā)環(huán)境和生產(chǎn)環(huán)境的差異，集合通信庫（如 NCCL）可能會通過 RoCE 互聯(lián)提供次優(yōu)的性能。比如開發(fā)人員環(huán)境中可能存在一些假設(shè)，包括：非常低的 RTT 時延（<10μs）、自適應(yīng)路由機制、無超額訂閱的非阻塞拓撲。這就需要對集合通信庫和網(wǎng)絡(luò)配置進行聯(lián)合優(yōu)化，以實現(xiàn)最佳性能。如下圖 Figure 15 所示，通過聯(lián)合優(yōu)化，作者的 RoCE 性能提高 2 倍以上：

7.2 路由和拓撲的影響

作者通過時間發(fā)展階段來研究一個 ZionEX AI Zone（基于 200G）的演變。如下圖 Figure 16 展示了數(shù)以萬計的 Job 在幾年內(nèi)運行的性能，并使用歸一化的 AllReduce 集合通信帶寬來量化。

• 第一階段后向網(wǎng)絡(luò) 1:1 的訂閱比例，第二階段是 RTSW 上行帶寬擴大 2 倍（冗余），可見第二階段性能相比第一階段顯著提高。第一階段性能較低和不一致性是因為之前描述的靜態(tài)路由流量沖突。第二階段雖然解決了性能問題，但是要投入 2 倍的網(wǎng)絡(luò)基礎(chǔ)設(shè)施。
• 第三階段表示遷移到流量工程時的情況，依然是第二階段的網(wǎng)絡(luò)，與第二階段性能類似，不過更加緊湊。第四階段是將訂閱比例從 1:2 降低到 1:1.125，以不影響性能的前提下降低 CTSW 硬件成本。?

7.3 可觀測性工具

在運維這些 RoCE 后向網(wǎng)絡(luò)時，需要對所有網(wǎng)絡(luò)組件（Fabric、Routing、Transport）以及集合通信進行觀測，以便快速診斷出故障或運行緩慢的工作負載。

• 面向 Job 的網(wǎng)絡(luò)錯誤：RDMA 對網(wǎng)絡(luò)問題非常敏感，它會影響 GPU 訓練的效率。為了快速檢查訓練任務(wù)背后的 RDMA 網(wǎng)絡(luò)狀況，作者構(gòu)建了相應(yīng)的檢測系統(tǒng)，自動收集網(wǎng)絡(luò)交換機、NIC、PCIe Switch 以及 GPU 等硬件錯誤。
• 面向運維人員的網(wǎng)絡(luò)錯誤：處理監(jiān)控和檢測異常，還執(zhí)行自動化的措施來修復(fù)許多問題。此外，也有一些內(nèi)部工具來自動檢測網(wǎng)絡(luò)連通性等問題。

7.4 故障排查示例

7.4.1 性能基準

作者在一個集群部署過程中觀察到性能退化問題，然而并沒有發(fā)現(xiàn)任何擁塞指標超出基準。進一步調(diào)查發(fā)現(xiàn)，唯一的不同是 CTSW 中的軟件 image。將 CTSW image 降級到與基線相同，性能退化問題得到解決。最終作者與供應(yīng)商合作，發(fā)現(xiàn) image 之間的差異是內(nèi)部數(shù)據(jù)包調(diào)度發(fā)生了變化，導(dǎo)致該設(shè)備 port 到 port 延遲變高。這也展示了持續(xù)觀測的必要性。

7.4.2 AI 訓練 Job 的動態(tài)特性

作者在遷移到支持 TE 控制器的訓練集群中，觀察到多個 CTSW 報告 RoCE 流量丟包。遷移包括：CTSW 重新配置、QoS 更改配置、RTSW 路由更改和 NIC 的 PCIe credit 升級。遷移后只有少數(shù)交換機報告流量丟棄，但累積的丟失量足以干擾某些 Job。經(jīng)過調(diào)查，發(fā)現(xiàn)根本原因是 CTSW 中關(guān)于 SRAM 緩沖區(qū)的大小設(shè)置已經(jīng)不能符合當前需求，導(dǎo)致緩沖區(qū)超過一半時發(fā)生尾丟棄（tail drop）。

八、參考鏈接

1. ??https://dl.acm.org/doi/pdf/10.1145/3651890.3672233??
2. ??https://engineering.fb.com/2024/08/05/data-center-engineering/roce-network-distributed-ai-training-at-scale/??
3. ??https://docs.nvidia.com/networking/display/rdmaawareprogrammingv17/rdma+verbs+api??
4. ??https://github.com/NVIDIA/nccl/issues/609??
5. ??https://arxiv.org/abs/2305.14516??
6. ??https://nvdam.widen.net/s/6269c25wv8/nv-spectrum-sn4000-product-brief??
7. ??https://www.arista.com/assets/data/pdf/Datasheets/7800R3-Data-Sheet.pdf??
8. ??https://dl.acm.org/doi/pdf/10.1145/3603269.3604860??
9. ??https://dl.acm.org/doi/10.1145/3098822.3098853??
10. ??https://dl.acm.org/doi/10.5555/3154630.3154664??

本文轉(zhuǎn)載自 ??AI閑談??，作者： AI閑談