一、背景

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

Meta 在其 LLaMA 3 技術報告中簡單提到用于訓練 LLaMA 3 的大規模 GPU 集群，不過在報告中并沒有詳細介紹其集群的構成以及相應的網絡解決方案。Meta 最近發布了相應的 Paper，我們這里進行簡單介紹。

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

對應的 Meta Blog：RoCE networks for distributed AI training at scale - Engineering at Meta

二、摘要

近年來，AI 模型的計算密度和規模都快速增長，推動了高效、可靠的專用網絡基礎設施的建設。本文中，Meta 作者介紹了其用于分布式 AI 訓練的 RoCE 網絡設計、實現和運維。

其設計原則涉及對工作負載的深刻理解，作者將這些間接轉化為各種網絡組件的設計：

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

三、引言

3.1 IB & RoCEv2

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

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

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

RDMA verbs 消息封裝在以太網/IPv6/UDP 數據包中，并通過常規以太網絡進行傳輸，打包/解包封裝在 RDMA NIC 硬件中處理。如下圖所示為對應的 RoCEv2 Packet Format：

3.2 集合通信（Collective Communicatin）

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

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

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

3.3 訓練工作負載

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

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

如下圖 Figure 2 所示為不同模型中各類通信原語實際通信 Message 大小（通信的元素數量）的分布，可以看出，不同模型的 Message 大小變化很大：

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

3.4 Shallow Buffer Switch & Deep Buffer Switch

在網絡交換機設計中，緩沖區（Buffer）是用來臨時存儲數據包的內存區域，通常用于應對網絡流量高峰或者臨時的擁塞情況。根據緩沖區大小的不同，交換機可以分為淺緩沖交換機（Shallow Buffer Switch）和深緩沖交換機（Deep Buffer Switch）。

• Shallow Buffer Switch

• 小緩沖區：每個端口通常配置有相對較小的內存緩沖區（例如幾百 KB 到幾 MB）。
• 低延遲：由于緩沖區較小，淺緩沖交換機通常具有較低的轉發延遲，適合延遲敏感的應用場景。
• 適用場景：淺緩沖交換機通常用于低延遲、高性能的環境中，當網絡流量相對穩定且網絡拓撲設計良好時，淺緩沖交換機的性能表現良好。

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

比如 NVIDIA 的 SN4000 系列以太網交換機都是 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

在傳統的以太網中，流量擁塞時會導致數據包丟失，從而影響網絡性能。為了解決這個問題，出現了優先級流控（PFC, Priority Flow Control），它通過暫停某些優先級的流量來防止擁塞，但PFC 是基于端口優先級（CoS, Class of Service）進行控制的。

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

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

四、硬件

4.1 訓練節點

4.1.1 概覽

訓練節點配置上與常見的 8*H100 Server 相當，同樣是每個 GPU 對應 1 個 400G NIC，并且 8 個 GPU 通過 NVSwitch 實現全互聯。不過其結構有所不同，采用 Grand Teton 平臺，如下圖所示為 Grand Teton 系統的概覽，其分為 3 個 Tray：

• Intel CPU Tray：

• 兩個 CPU，通過 UPI 連接。
• 每個 CPU 還會連接一個前向網絡對應的 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 實現全互聯。?

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

4.1.2 Intel CPU Tray

如下圖所示為其 CPU Tray 的結構：

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

4.2 網絡拓撲

4.2.1 網絡概覽

如下圖 Figure 5 所示為其前向（Frontend）和后向（Backend）網絡拓撲：

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

4.2.2 后向網絡

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

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

• Leaf Switch 對應 Rack Training Switch（RTSW），使用銅制 DAC 電纜連接 Rack 內的 GPU NIC。
• Spine Switch 對應 Cluster Training Switch（CTSW），通過單模光纖和 400G 可插拔光模塊連接 RTSW。
• 同一個 Zone 內的 Rack 通過 CTSW 實現 Full Mesh 互聯，構成無收斂網絡。

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

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

• 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 連接，實現 Full Mesh，1:1 收斂比。所以每個 Pod 需要有 16 個 Cluster Switch。一個 Pod 內就可以包含 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，對應每個 Aggregation Switch 使用 128 個 400G Port。
• Data Center：總共有 8 個 Pod，也就是 24K H100 GPU。?

五、路由

5.1 挑戰

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

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

5.2 ECMP 和路徑固定

5.2.1 ECMP

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

5.2.2 路徑固定

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

5.2.3 短期和長期方案

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

5.3 增強的 ECMP

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

5.3.1 QP 擴展

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

5.3.2 自定義哈希

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

5.3.3 QP 權衡

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

5.3.4 不同 QP 擴展方案

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

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

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

PS：如果使用 NCCL 的話，可以使用 “NCCL_IB_QPS_PER_CONNECTION” 和 “NCCL_IB_SPLIT_DATA_ON_QPS” 兩個環境變量來調整：

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

5.3.5 超越 E-ECMP 的動機

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

5.4 中心化流量工程

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

5.4.1 控制平面

控制平面包含 3 個組件：

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

5.4.2 數據平面

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

5.5 對比 TE 和 E-ECMP

作者通過流量網絡模擬器對 TE 和 E-ECMP 性能進行評估，然后是生產基準測試結果。最后是描述每種方案的復雜性。

5.5.1 模擬

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

5.5.2 基準評估

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

5.5.3 TE 的運維經驗的教訓

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

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

5.6 未來方向：Flowlet Switching

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

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

六、傳輸

6.1 概覽

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

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

6.2 實現

作者實現了多種傳輸配置，以在 RoCE 設置中實現高帶寬、低延遲和可預測時延。

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

6.3 擁塞控制

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

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

6.3.1 針對集合通信調優 DCQCN 的局限性

作者在部署 200G 和 400G RDMA 網絡時，發現 DCQCN（也就是 RoCE 默認的擁塞控制）對于訓練中的集合通信不符合預期。

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

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

當網絡進一步過渡到 400G 時，作者識圖進一步調整 DCQCN 以適應新的網絡速度和拓撲結構。然而，作者發現固件中的 DCQCN 實現已經改變，因此在 400G 網絡中并沒有采用 DCQCN。也就是，僅使用 PFC 進行流量控制，而沒有其他任何傳輸層擁塞控制。

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

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

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

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

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

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

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

PS：NCCL 中可以通過 NCCL_BUFFSIZE 設置緩沖區大小，也可以通過 NCCL_MAX_NCHANNELS 和 NCCL_MIN_NCHANNELS 現在 Channel 數目。

6.3.3 吸收網絡內擁塞

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

6.4 討論

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

七、實驗

7.1 聯合調優網絡和集合通信

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

7.2 路由和拓撲的影響

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

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

7.3 可觀測性工具

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

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

7.4 故障排查示例

7.4.1 性能基準

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

7.4.2 AI 訓練 Job 的動態特性

作者在遷移到支持 TE 控制器的訓練集群中，觀察到多個 CTSW 報告 RoCE 流量丟包。遷移包括：CTSW 重新配置、QoS 更改配置、RTSW 路由更改和 NIC 的 PCIe credit 升級。遷移后只有少數交換機報告流量丟棄，但累積的丟失量足以干擾某些 Job。經過調查，發現根本原因是 CTSW 中關于 SRAM 緩沖區的大小設置已經不能符合當前需求，導致緩沖區超過一半時發生尾丟棄（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??

本文轉載自 ??AI閑談??，作者： AI閑談