當前，許多超大規(guī)模廠商正在競相構(gòu)建大型 GPU 集群，以適應GenAI訓練工作負載。本文探討了針對GenAI訓練工作負載進行優(yōu)化的各種網(wǎng)絡拓撲結(jié)構(gòu)，如Meta的Rail-Only 拓撲和Dragonfly拓撲，以及網(wǎng)絡中可能存在的一些擁塞點和各種擁塞控制解決方案。

01GPU Fabric拓撲

有兩種構(gòu)建 GPU 拓撲的方法：

# Fat-tree CLOS 具有非阻塞的any-to-any連接，不依賴于正在訓練的模型。

這是公有云提供商的首選方案，其 GPU 集群可用于訓練各種模型，包括具有大型嵌入表的推薦模型，這些嵌入表可跨所有 GPU 上創(chuàng)建 all-to-all 通信。然而，為成千上萬的 GPU 提供非阻塞連接是非常昂貴的，與扁平的spine/leaf拓撲相比，它需要更多交換機和更多的跳數(shù)。這些拓撲更有可能出現(xiàn)擁塞和長尾延遲。

# 針對特定訓練工作負載優(yōu)化的拓撲。

這種方法在為 LLM 訓練工作負載構(gòu)建專用 GPU 集群的超大規(guī)模廠商中很流行。優(yōu)化拓撲使集群高效且可持續(xù)。例如谷歌使用的3D torus和optical spine交換機，以及 Meta 使用的rail-optimized leaf交換機。一些 HPC 架構(gòu)還使用dragonfly拓撲來優(yōu)化 GPU 之間的跳數(shù)。

Meta：Rail-Only 拓撲

Meta的一篇論文（《Meta和MIT最新網(wǎng)絡架構(gòu)研究，對傳統(tǒng)架構(gòu)提出挑戰(zhàn)》）分析了大型 GPU 集群中的流量模式。他們將GPU 分組為高帶寬 (HB) 域集群，每個集群有 256 個 GPU。256 個 GPU 是GH200超級計算機的一部分，其中所有GPU 都通過NVSwitch層次架構(gòu)連接。HB 域通過rail-optimized交換機連接。從GPT-3/OPT-175B 模型的流量模式分析可得出以下結(jié)論：

整個集群99%的GPU對不承載任何流量；

論文中的熱圖反映了觀察結(jié)果。該論文提出，具有rail -only交換機的拓撲可以與非阻塞 CLOS 拓撲一樣執(zhí)行。在rail -only交換機中，所有 M 個 HB 域中的第 N 個 GPU 通過 400Gbps 鏈路連接到 M x400G rail交換機。

| 訓練 GPT-3 模型時 GPU 對之間的流量模式

在下面的拓撲中，當 GPU 需要將數(shù)據(jù)移動到不同rail中的另一臺服務器GPU 時，它會首先使用 NVlink 將數(shù)據(jù)移動到與目標 GPU 屬于同一rail的服務器內(nèi) GPU 內(nèi)存中。之后，數(shù)據(jù)可以通過rail交換機傳送到目的地。這可以實現(xiàn)消息聚合和網(wǎng)絡流量優(yōu)化。

| 具有rail-only交換機的 1024 個 GPU 集群的拓撲

| 具有rail 和spine交換機的 1024 個 GPU 集群的 CLOS 拓撲

rail-optimized連接適用于大多數(shù) LLM/Transformer模型。對于大于1024個 GPU的集群，需要使用spine交換機來實現(xiàn) GPU 間的數(shù)據(jù)并行通信。

| 具有 Rail-Spine 交換機的 2048 GPU 集群

Dragonfly拓撲

Dragonfly是由John Kim等人在2008年的論文Technology-Driven, Highly-Scalable Dragonfly Topology中提出，它的特點是網(wǎng)絡直徑小、成本較低，早期主要用于HPC集群。在這種拓撲結(jié)構(gòu)中，Pod 或交換機組連接到服務器，這些 Pod 還通過高帶寬鏈路直接相互連接。Dragonfly比傳統(tǒng)的leaf-spine拓撲需要的交換機更少，但當部署用于以太網(wǎng)/IP通信時，它也面臨著一定的挑戰(zhàn)。

| Dragonfly 拓撲示例

Dragonfly網(wǎng)絡在擴展性方面存在問題，每次需要增加網(wǎng)絡容量時，都必須對Dragonfly網(wǎng)絡進行重新布線，這增加了網(wǎng)絡的復雜性和管理難度。

在 Hot Interconnects 2023 上，Bill Dally 博士提出了一種拓撲，其中組和組之間可以直接連接到光電路交換機（OCS）。這樣，就算添加額外的組、更改直接鏈路，也不會對連接性造成太多的干擾。通過引入OCS技術(shù)，可以實現(xiàn)布線自動化，從而有效解決了擴展過程中重新布線的難題，提高了網(wǎng)絡的可管理性和靈活性。

02Fabric擁塞

無損傳輸對于優(yōu)化訓練性能至關(guān)重要。任何網(wǎng)絡丟失都會觸發(fā) RoCE 中使用標準NIC的 go-back-N 重傳，這會浪費帶寬并導致長尾延遲。

雖然可以在所有鏈路上啟用鏈路級PFC，但如果分配的緩沖區(qū)在隊列之間進行共享，那么擴展的PFC可能會造成排隊阻塞、浪費緩沖區(qū)空間、死鎖、PFC風暴等。PFC 應作為防止流量丟失的最后手段。

我們先看看網(wǎng)絡中的擁塞點：

| 網(wǎng)絡擁塞點

NIC -> Leaf Links

在rail-optimized的leaf 交換機中，對于服務器間流量，NCCL/PXN 利用節(jié)點內(nèi)的 NVSwitch 將數(shù)據(jù)移動到與目標位于同一rail上的 GPU，然后在不跨越rail的情況下將數(shù)據(jù)發(fā)送到目標GPU，從而實現(xiàn)NIC到leaf的流量優(yōu)化。

雖然每個 GPU 可以向其rail交換機發(fā)送 400Gbps 的數(shù)據(jù)，但并非所有 GPU 到leaf交換機的鏈路都是完全飽和的，在服務器到leaf鏈路之間會產(chǎn)生不均勻的帶寬分配。因此，一些超大規(guī)模企業(yè)不喜歡rail-optimized的leaf交換機，他們更喜歡在從服務器到leaf交換機的所有可用鏈路上對 GPU 流量進行負載平衡。

Leaf -> Spine Links

在rail-optimized網(wǎng)絡中，leaf-spine主要是數(shù)據(jù)并行流量，這些流具有較高的帶寬并且持續(xù)時間較長。例如，每個H100 GPU 具有 80GB 內(nèi)存，梯度可能會占用該內(nèi)存的 1/10 (約8GB)。當 GPU 使用單個 QP（流）通過 400Gbps 上行鏈路發(fā)送 8GB 數(shù)據(jù)時，會產(chǎn)生大于160ms 的流量，需要由rail交換機處理。

當可以通過這些路徑到達目的地時，ECMP 會在leaf和spine鏈路之間的可用并行等價路徑上分發(fā)數(shù)據(jù)包。ECMP 旨在分散網(wǎng)絡流量以提高鏈路利用率并防止擁塞。交換機使用哈希函數(shù)來決定發(fā)送數(shù)據(jù)包的路徑。然而，當系統(tǒng)熵值非常低時，哈?？赡軙е虏⑿墟溌防寐什痪鶆蛞约澳承╂溌穱乐負砣臎_突。某些流量模式在使用 ECMP 負載均衡時，鏈路利用率可能低于 50%。

Spine -> Leaf Links

Spine到Leaf的擁塞可能在以下情況時發(fā)生：

spine交換機和每個leaf 交換機之間可能存在多個并行鏈路，用于負載均衡鏈路間流量的 ECMP 可能會造成鏈路利用率不均勻。

In-cast流量。Incast 是一種流量模式，其中許多流匯聚到交換機的同一輸出口上，耗盡該接口的緩沖區(qū)空間并導致數(shù)據(jù)包丟失。當 GPU 集群中并行運行多個訓練任務時，也可能會發(fā)生這種情況。

Leaf -> NIC links

它們承載高帶寬流水線并行和數(shù)據(jù)并行流量。

流水線并行流量負載在很大程度上取決于模型架構(gòu)和分區(qū)。它具有高帶寬和突發(fā)性，GPU 之間具有微秒突發(fā)性。這兩種流量模式結(jié)合在一起可能導致鏈路發(fā)生incast情況。

03擁塞控制解決方案

下面列出的各種技術(shù)可用于緩解 GPU fabric中的擁塞，最終的部署取決于支持這些協(xié)議的網(wǎng)卡/交換機以及GPU集群的規(guī)模。

提高鏈路利用率：如果任意兩臺交換機或交換機/網(wǎng)卡之間的所有并行路徑都可以到達目的地，則將流量均勻分布在這些路徑上。動態(tài)/自適應負載均衡和數(shù)據(jù)包噴灑（packet spraying）就屬于這一類。更多到達目的地的路徑將有助于減少網(wǎng)絡交換機中的隊列堆積。

發(fā)送端驅(qū)動的擁塞控制算法 (CCA) 依賴于 ECN 或來自交換機的實時遙測。根據(jù)遙測數(shù)據(jù)，發(fā)送端將調(diào)節(jié)發(fā)送給fabric的流量。

接收端驅(qū)動的擁塞控制：接收端向發(fā)送端分配用于傳輸數(shù)據(jù)包的Credit。

Scheduled fabric。

可以更好地處理擁塞的新傳輸協(xié)議。

動態(tài)/自適應負載均衡

當目的地可以使用并行鏈路到達時，以太網(wǎng)交換機中的動態(tài)/自適應負載均衡會動態(tài)地將流量從擁塞鏈路轉(zhuǎn)移到空閑鏈路。為了不對流內(nèi)的數(shù)據(jù)包重新排序，大多數(shù)實現(xiàn)都會尋找流中的間隔（gap）來進行負載均衡。如果gap足夠大，就表示這個gap之前的數(shù)據(jù)包已經(jīng)傳輸了很遠，不用擔心通過空閑鏈路發(fā)送的數(shù)據(jù)包會比之前的數(shù)據(jù)包提前到達目的地。

動態(tài)負載均衡的一種極端形式是packet-level spraying。

packet spraying

另一種流行的方法是packet spraying。Fabric中的每個交換機均勻地在所有可用(且不擁塞)的并行鏈路上進行packet spraying，可以將并行鏈路利用率提高到90%以上。當一個流 (QP) 的數(shù)據(jù)包被spray時，它們會采用不同的路徑通過fabric，經(jīng)歷不同的擁塞延遲，并且可能會無序地到達目標 GPU。

NIC 應具有處理無序 RDMA 事務的邏輯/硬件。Nvidia 的 ConnectX NIC可以處理無序 (OOO) RDMA 操作。然而，它們在不損失性能的情況下支持的重新排序量是有限的。Nvidia 對此功能提供有限的現(xiàn)場支持，尚不清楚其最新版本的NIC是否正式支持數(shù)據(jù)包重新排序。

云提供商的另一種選擇是使用支持 RDMA 操作重新排序的硬件來構(gòu)建自己的網(wǎng)卡，并在客戶構(gòu)建的 GPU 服務器中使用它們。在構(gòu)建自定義NIC時，使用 Nvidia 的 Bluefield DPU 也是一種選擇。Bluefield支持無序RDMA操作，(很可能)將它們存儲在本地內(nèi)存中，然后在重新排序事務時將數(shù)據(jù)包寫入GPU內(nèi)存。然而，與標準NIC中的簡單 ASIC/FPGA 相比，DPU更加昂貴且耗電。除了數(shù)據(jù)包排序之外，它們還有許多 AI/ML 訓練工作負載并不需要的功能。如果 Bluefield 確實使用本地內(nèi)存進行重新排序，則會增加事務的額外延遲，并浪費 NIC 中用于存儲數(shù)據(jù)包的內(nèi)存資源，而數(shù)據(jù)包在重新排序時可以存儲在 GPU 內(nèi)存中。

亞馬遜/微軟的自定義NIC支持數(shù)據(jù)包重新排序。其他交換機供應商也可能正在構(gòu)建可以支持數(shù)據(jù)包重新排序的智能網(wǎng)卡（或網(wǎng)卡中使用的 ASIC）。

Scheduled Fabric

為了順利工作，Scheduled Fabric在每個端點leaf交換機中都需要大量入口緩沖/狀態(tài)，以便對發(fā)往集群中的所有端點 GPU 的數(shù)據(jù)包進行排隊，它還需要在這些端點交換機上為所有無損隊列提供大的出口緩沖區(qū)。

在傳輸數(shù)據(jù)包之前，有一個額外的 RTT 延遲（用于端點交換機之間的請求-授予握手）。此外，該方案目前還沒有明確的標準，每個供應商都有自己的專有協(xié)議，控制平面管理非常復雜，尤其是當某些鏈路/交換機發(fā)生故障并需要增加額外容量時，這需要客戶對每個供應商的產(chǎn)品有深入的了解。供應商鎖定的風險很高。

EQDS

邊緣排隊數(shù)據(jù)報服務（EQDS，Edge-Queued Datagram Service）是一種為數(shù)據(jù)中心提供的新數(shù)據(jù)報服務，它將幾乎所有隊列從核心網(wǎng)絡轉(zhuǎn)移到發(fā)送主機。這使得它能夠支持多個（沖突的）高層協(xié)議，同時只根據(jù)任何接收端驅(qū)動的信用/credit方案向網(wǎng)絡發(fā)送數(shù)據(jù)包。這意味著發(fā)送端只有在從接收端收到Credit時才能發(fā)送數(shù)據(jù)包，而接收端只有在有足夠的緩沖區(qū)空間時才授予Credit，并計量授予不超過接收端的訪問鏈路速度。這樣，網(wǎng)絡交換機可以使用非常小的緩沖區(qū)運行，并最大限度地減少擁塞/數(shù)據(jù)包丟失。

EQDS 使用packet spraying來均衡網(wǎng)絡核心中的負載，避免流沖突，并提高吞吐量。此外，這個協(xié)議的優(yōu)點是它沒有引入另一個傳輸層協(xié)議，它通過動態(tài)隧道向現(xiàn)有傳輸層提供數(shù)據(jù)報服務。

EQDS 可以在端點 NIC 的軟件中實現(xiàn)。但是，對于高帶寬服務器，應該在 NIC 硬件中實現(xiàn)。Broadcom 收購了發(fā)布此協(xié)議的公司，并且可能正在構(gòu)建具有此功能的 NIC 硬件。

DCQCN

對于 RoCEv2 RDMA 流量，需要更快的擁塞響應，而無需通過主機軟件。2015 年由 微軟和 Mellanox 提出的DCQCN擁塞控制算法，通常在網(wǎng)卡中實現(xiàn)。當交換機檢測到擁塞時, 將出口包打上ECN標記, 接收端收到ECN包后, 因為有發(fā)送端的QP信息, 發(fā)送擁塞通知包CNP給發(fā)送端, 這時候假如發(fā)送端收到多個接收端發(fā)來的ECN包, 發(fā)送方會使用DCQCN來降速和調(diào)度發(fā)送。一段時間發(fā)送端沒有收到CNP時, 這個時候需要恢復流量。

為了使該算法發(fā)揮作用，交換機不應在 ECN 標記之前發(fā)送 PFC，PFC 是在極端擁塞情況下防止數(shù)據(jù)包丟失的最后手段。

阿里HPCC/HPCC++

雖然 ECN 指示網(wǎng)絡中存在擁塞，但指示的粒度非常粗，只有一種狀態(tài)可以指示數(shù)據(jù)包是否在fabric中的某臺交換機中遇到擁塞。當發(fā)送端開始降低速率時，擁塞/隊列堆積已經(jīng)發(fā)生，這會增加網(wǎng)絡的延遲，并且擁塞控制算法（如 DCQCN）必須迅速采取行動以避免觸發(fā) PFC。另外，依賴ECN的方案很難計算出發(fā)送速率要降低多少。

阿里在2019年的SIGCOMM上提出了HPCC（高精度擁塞控制），試圖解決以上問題，其背后的關(guān)鍵思想是利用來自INT的精確鏈路負載信息來計算準確的流量更新。數(shù)據(jù)包從發(fā)送端傳播到接收端的過程中，路徑上的每個交換機都會利用其交換 ASIC 的 INT（帶內(nèi)遙測） 功能插入一些元數(shù)據(jù)，報告數(shù)據(jù)包出端口的當前負載，包括時間戳 (ts)、隊列長度 (qLen)、傳輸字節(jié) (txBytes) 和鏈路帶寬容量 (B)。當接收方收到數(shù)據(jù)包時，會將交換機記錄的所有元數(shù)據(jù)通過ACK發(fā)送給發(fā)送端。然后發(fā)送端根據(jù)帶有網(wǎng)絡負載信息的 ACK 決定如何調(diào)整其流量。

HPCC 通過利用交換機的遙測信息，可以實現(xiàn)更快的收斂、更小的fabric隊列以及發(fā)送端的公平性。HPCC++ 對 HPCC 擁塞控制算法添加了額外的增強功能，以加快收斂速度。

谷歌CSIG

CSIG是交換機向端點設(shè)備發(fā)送擁塞信號的另一種方式，谷歌在 OCP 2023 中開源了該協(xié)議。CSIG旨在以更少的數(shù)據(jù)包開銷實現(xiàn)與 HPCC/HPCC++ 類似的目標。CSIG 的一些顯著特征如下：

CSIG使用固定長度的報頭來承載信號，而 INT 使用隨跳數(shù)增長的可變長度報頭，這使其在帶寬和開銷方面更加高效。

CSIG 比 INT 更具可擴展性，因為它使用比較和替換機制從路徑上的瓶頸設(shè)備收集信號，而 INT 使用逐跳追加機制，要求每個設(shè)備插入自己的信息。

CSIG 標簽在結(jié)構(gòu)上與 VLAN 標簽相似，這使得網(wǎng)絡能夠重新利用現(xiàn)有的 VLAN 重寫邏輯來支持 CSIG 標簽。這可以簡化網(wǎng)絡內(nèi)隧道和加密的實現(xiàn)和兼容性。

現(xiàn)有的 CCA 可以使用 CSIG 信息來調(diào)整流量，以便更準確地控制網(wǎng)絡和incast擁塞。

亞馬遜SRD

亞馬遜開發(fā)了一種名為SRD (可擴展可靠數(shù)據(jù)報) 的新傳輸協(xié)議來解決 RoCEv2 的局限性。SRD 不保留數(shù)據(jù)包順序，而是通過盡可能多的網(wǎng)絡路徑發(fā)送數(shù)據(jù)包，同時避免路徑過載。SRD 的創(chuàng)新在于有意通過多個路徑分別發(fā)包，雖然包到達后通常是亂序的，但AWS實現(xiàn)了在接收處以極快的速度進行重新排序，最終在充分利用網(wǎng)絡吞吐能力的基礎(chǔ)上，極大地降低了傳輸延遲。

SRD 集成在亞馬遜的 Elastic Fabric Adapter (EFA) 中，并與商用以太網(wǎng)交換機配合使用。它使用標準 ECMP 進行多路徑負載平衡。發(fā)送方通過操作數(shù)據(jù)包封裝來控制 ECMP 路徑選擇。發(fā)送方知道每個多路徑中的擁塞情況（通過為每個路徑收集的 RTT），并且可以調(diào)節(jié)通過每個路徑發(fā)送的數(shù)量。SRD 根據(jù)傳入確認數(shù)據(jù)包的時序和 RTT 變化所指示的速率估計來調(diào)整其每個連接的傳輸速率。

谷歌Falcon

在 2023 年 OCP 全球峰會上，谷歌開放了其硬件輔助傳輸層 Falcon。Falcon 的構(gòu)建原理與 SRD 相同，通過多路徑連接、處理網(wǎng)卡中的無序數(shù)據(jù)包、選擇性重傳以及更快更好的基于延遲的擁塞控制 (swift) 來實現(xiàn)低延遲和高帶寬的可靠傳輸。網(wǎng)絡交換機不需要任何修改來支持該傳輸層。

新協(xié)議

2023年7月成立的超以太網(wǎng)聯(lián)盟（UEC）的目標之一是優(yōu)化鏈路級和端到端網(wǎng)絡傳輸協(xié)議或創(chuàng)建新協(xié)議，以使以太網(wǎng)fabric能夠更好地處理大型 AI/ML 集群。然而，由于UEC 聯(lián)盟的創(chuàng)始成員都已在其交換機/網(wǎng)卡和主機堆棧中適應了不同的專有解決方案，因此尚不清楚他們將以多快的速度實現(xiàn)這些目標。

即使提出了一個新協(xié)議，也不清楚具有定制解決方案的超大規(guī)模廠商是否會立即適應新標準。與 RDMA/RoCE 一樣，任何新的傳輸協(xié)議都需要經(jīng)歷多代才能獲得可靠的實現(xiàn)。與此同時，商業(yè)交換機供應商必須繼續(xù)關(guān)注行業(yè)發(fā)展方向，并為終端擁塞控制提供更好的遙測和擁塞信號選擇。

04總 結(jié)

本文詳細敘述了 genAI/LLM 模型的 GPU 流量模式，以及如何針對這些流量模式優(yōu)化網(wǎng)絡拓撲。當前，該行業(yè)正處于為大型 GPU 集群部署以太網(wǎng)fabric的早期階段。如果packet spraying和端到端擁塞控制在 AI/ML/HPC 集群中使用的大型 IB 網(wǎng)絡表現(xiàn)依然出色，那么以太網(wǎng)fabric將受益于相同的功能。然而，在超大規(guī)模廠商確定適合自己的方案，并發(fā)布其協(xié)議（通過 UEC 或獨立）以供網(wǎng)卡/交換機適應之前，拓撲和擁塞管理功能還需要一些試驗和調(diào)整?？偟膩碚f，以太網(wǎng)fabric和交換機供應商的前途非常光明！

審核編輯：湯梓紅