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

| Dragonfly 拓?fù)涫纠?/p>

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

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

02Fabric擁塞

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

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

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

| 網(wǎng)絡(luò)擁塞點(diǎn)

NIC -> Leaf Links

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

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

Leaf -> Spine Links

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

當(dāng)可以通過這些路徑到達(dá)目的地時，ECMP 會在leaf和spine鏈路之間的可用并行等價路徑上分發(fā)數(shù)據(jù)包。ECMP 旨在分散網(wǎng)絡(luò)流量以提高鏈路利用率并防止擁塞。交換機(jī)使用哈希函數(shù)來決定發(fā)送數(shù)據(jù)包的路徑。然而，當(dāng)系統(tǒng)熵值非常低時，哈希可能會導(dǎo)致并行鏈路利用率不均勻以及某些鏈路嚴(yán)重?fù)砣臎_突。某些流量模式在使用 ECMP 負(fù)載均衡時，鏈路利用率可能低于 50%。

Spine -> Leaf Links

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

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

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

Leaf -> NIC links

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

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

03擁塞控制解決方案

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

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

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

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

Scheduled fabric。

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

動態(tài)/自適應(yīng)負(fù)載均衡

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

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

packet spraying

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

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

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

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

Scheduled Fabric

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

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

EQDS

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

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

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

DCQCN

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

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

阿里HPCC/HPCC++

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

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

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

谷歌CSIG

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

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

CSIG 比 INT 更具可擴(kuò)展性，因?yàn)樗褂帽容^和替換機(jī)制從路徑上的瓶頸設(shè)備收集信號，而 INT 使用逐跳追加機(jī)制，要求每個設(shè)備插入自己的信息。

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

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

亞馬遜SRD

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

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

谷歌Falcon

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

新協(xié)議

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

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

04總 結(jié)

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

審核編輯：湯梓紅