一、背景

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

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

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

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

二、摘要

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

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

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

三、引言

3.1 IB & RoCEv2

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

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

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

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

3.2 集合通信（Collective Communicatin）

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

如下圖 Table 1 列出了主要集合通信原語(yǔ)的特點(diǎn)以及每種集合通信的要求：

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

3.3 訓(xùn)練工作負(fù)載

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

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

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

每個(gè)集合通信操作中 GPU 數(shù)量的趨勢(shì)：無(wú)論是 Ranking Job，還是 LLM Job，每個(gè)集合通信操作中 GPU 的數(shù)量并沒(méi)有與 Job 大小以相同的速度增長(zhǎng)。這是因?yàn)樵诖笠?guī)模訓(xùn)練中會(huì)使用多維并行策略，這有助于限制最大集合通信操作中 GPU 的數(shù)量，即使運(yùn)行的 Job 中有成千上萬(wàn)個(gè) GPU。因此，本文中的其他部分主要關(guān)注涉及 16-128 個(gè) GPU 的集合通信操作。

3.4 Shallow Buffer Switch & Deep Buffer Switch

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

• Shallow Buffer Switch

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

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

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

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

3.5 DSCP-based PFC

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

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

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

四、硬件

4.1 訓(xùn)練節(jié)點(diǎn)

4.1.1 概覽

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

• Intel CPU Tray：

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

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

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

4.1.2 Intel CPU Tray

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

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

4.2 網(wǎng)絡(luò)拓?fù)?/h3>

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

如下圖 Figure 5 所示為其前向（Frontend）和后向（Backend）網(wǎng)絡(luò)拓?fù)洌?/p>

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

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

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

• AI Zone：兩層 Clos 拓?fù)?，無(wú)阻塞

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

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

如下圖所示為我們根據(jù) LLaMA 3 技術(shù)報(bào)告數(shù)據(jù)繪制的集群網(wǎng)絡(luò)拓?fù)洌≒S：不一定嚴(yán)格對(duì)齊），其總共包含 24K GPU，采用 3 層 Clos 網(wǎng)絡(luò)：

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

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

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

五、路由

5.1 挑戰(zhàn)

在 AI 訓(xùn)練工作負(fù)載中有如下幾個(gè)有挑戰(zhàn)性的特點(diǎn)：

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

5.2 ECMP 和路徑固定

5.2.1 ECMP

作者最初考慮使用廣泛采用的 ECMP，它根據(jù)五元組的哈希值隨機(jī)放置數(shù)據(jù)流：源 IP、目標(biāo) IP、源 UDP 端口、目標(biāo) UDP 端口以及協(xié)議。然而，由于低熵問(wèn)題，ECMP 在訓(xùn)練工作負(fù)載中表現(xiàn)不佳。作者使用最大均值比（MMR，也就是負(fù)載最大鏈路的流數(shù)量和每個(gè)鏈路平均的流數(shù)量之比）來(lái)衡量 ECMP 均衡性，這是因?yàn)榧贤ㄐ胖械拇蠖鄶?shù)數(shù)據(jù)流大小相同。作者觀察到 16 個(gè)鏈路模擬中 1000 個(gè)流的平均 MMR 超過(guò) 1.2。如下圖 Table 2 所示，實(shí)際上這種情況要糟糕的多。這種負(fù)載不均衡會(huì)導(dǎo)致大象流發(fā)生碰撞的概率大得多，從而造成嚴(yán)重?fù)砣⒔档途W(wǎng)絡(luò)吞吐量和 Job 性能。

5.2.2 路徑固定

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

5.2.3 短期和長(zhǎng)期方案

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

5.3 增強(qiáng)的 ECMP

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

5.3.1 QP 擴(kuò)展

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

5.3.2 自定義哈希

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

5.3.3 QP 權(quán)衡

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

5.3.4 不同 QP 擴(kuò)展方案

作者評(píng)估了兩種 QP 擴(kuò)展策略：

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

對(duì)于生產(chǎn)環(huán)境中的 NCCL 消息大小，作者觀察到第二種方案表現(xiàn)良好，這項(xiàng)功能對(duì)于 ECMP 的可擴(kuò)展性非常重要，因?yàn)樗黾恿朔謱蛹贤ㄐ牛ㄈ?AllReduce）的網(wǎng)絡(luò)流。

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

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

5.3.5 超越 E-ECMP 的動(dòng)機(jī)

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

5.4 中心化流量工程

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

5.4.1 控制平面

控制平面包含 3 個(gè)組件：

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

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

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

5.5 對(duì)比 TE 和 E-ECMP

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

5.5.1 模擬

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

5.5.2 基準(zhǔn)評(píng)估

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

5.5.3 TE 的運(yùn)維經(jīng)驗(yàn)的教訓(xùn)

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

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

5.6 未來(lái)方向：Flowlet Switching

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

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

六、傳輸

6.1 概覽

不同級(jí)別網(wǎng)絡(luò)擁塞：分布式訓(xùn)練會(huì)產(chǎn)生獨(dú)特的 Full Mesh 和分層流量模式（如 Tree 和 Ring），這兩種模式會(huì)產(chǎn)生不同的擁塞模式，如上 Table 2 中的 Buffer 占用率也不同。針對(duì)這種情況也沒(méi)有標(biāo)準(zhǔn)的最佳實(shí)踐來(lái)處理?yè)砣麊?wèn)題。如下圖 Figure 3 所示為 Ranking 模型和 LLM 的流量模式：

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

6.2 實(shí)現(xiàn)

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

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

6.3 擁塞控制

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

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

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

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

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

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

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

6.3.2 通過(guò)集合通信庫(kù)的接收端驅(qū)動(dòng)流量準(zhǔn)入

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

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

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

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

因此，作者采取了兩個(gè)措施來(lái)提高性能：

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

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

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

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

6.4 討論

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

七、實(shí)驗(yàn)

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

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

7.2 路由和拓?fù)涞挠绊?/h3>

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

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

7.3 可觀測(cè)性工具

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

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

7.4 故障排查示例

7.4.1 性能基準(zhǔn)

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

7.4.2 AI 訓(xùn)練 Job 的動(dòng)態(tài)特性

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