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

01GPU Fabric拓撲

有兩種構建 GPU 拓撲的方法：

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

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

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

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

Meta：Rail-Only 拓撲

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

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

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

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

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

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

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

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

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

Dragonfly拓撲

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

| Dragonfly 拓撲示例

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

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

02Fabric擁塞

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

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

我們先看看網絡中的擁塞點：

| 網絡擁塞點

NIC -> Leaf Links

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

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

Leaf -> Spine Links

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

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

Spine -> Leaf Links

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

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

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

Leaf -> NIC links

它們承載高帶寬流水線并行和數據并行流量。

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

03擁塞控制解決方案

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

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

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

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

Scheduled fabric。

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

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

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

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

packet spraying

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

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

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

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

Scheduled Fabric

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

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

EQDS

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

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

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

DCQCN

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

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

阿里HPCC/HPCC++

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

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

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

谷歌CSIG

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

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

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

CSIG 標簽在結構上與 VLAN 標簽相似，這使得網絡能夠重新利用現有的 VLAN 重寫邏輯來支持 CSIG 標簽。這可以簡化網絡內隧道和加密的實現和兼容性。

現有的 CCA 可以使用 CSIG 信息來調整流量，以便更準確地控制網絡和incast擁塞。

亞馬遜SRD

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

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

谷歌Falcon

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

新協議

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

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

04總 結

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

審核編輯：湯梓紅