Dragonfly
深度研究報告：Dragonfly 拓撲技術演進、產業價值與萬卡叢集部署實踐
摘要 本報告深入剖析了面向超大規模 AI 叢集的 Dragonfly 直接互連拓撲。區別於傳統分層胖樹（Fat-Tree）架構，Dragonfly 通過“組內全連線、組間稀疏全連線”的拓撲創新，從根源上解決了萬卡至十萬卡級叢集的網路成本與效能擴充套件困境。報告指出，Dragonfly 不僅是一種降本方案，更是一種在頻寬、延遲和彈性之間尋求最優均衡的系統架構哲學。通過詳細拆解其拓撲結構、路由演算法、擁塞控制、實際部署案例及與 Fat-Tree 的定量對比，本報告旨在為 AI 基礎設施規劃者、網路架構師及技術決策者提供一份從理論原理到產業實踐的全景檢視，並前瞻性地探討面向百萬卡叢集的下一代直接互連演進路徑。
1. 產業背景與算力焦慮：萬卡叢集為何呼喚底層網路架構範式革命
隨著 GPT-4、Gemini Ultra 等大語言模型引數突破萬億，訓練算力需求呈指數增長。2020年千卡叢集尚屬頂級，到2024年萬卡已成為先進模型訓練的准入門檻，而十萬卡乃至百萬卡叢集的技術競賽已然打響。在這一演化中，單 GPU 算力藉助 4nm 到 3nm 製程和 Blackwell 等架構創新持續翻倍，但連線這些算力單元的網路子系統，其複雜拓撲與總擁有成本（TCO）正迅速成為叢集擴充套件的“阿喀琉斯之踵”。
傳統資料中心網路遵循 CLOS 架構的分層邏輯，最典型的實現是 Fat-Tree。在一個非阻塞三層 Fat-Tree 中，為實現任意兩節點間全速率通訊，核心層交換器和光模組數量會隨節點數 N 呈現 O(N²) 膨脹。當 N 從 4096 擴充套件至 32768，核心交換器埠數和長距離光纜束將激增至令商業模型難以為繼的程度。據 Broadcom 2022年網路研討會資料，部分大規模 AI 叢集早期設計中，網路基礎設施成本已攀升至硬體總投資的 15%~20%，其中跨 Pod 的 400G/800G FR/LR 光模組正是成本暴增的核心推手。
成本與規模的尖銳矛盾宣告了傳統“以量取勝”路線的失效。業界開始反思：我們是否真的需要一個物理上嚴格無阻塞的全交叉網路？AI 訓練的流量模式——資料並行中頻繁但區域性的梯度同步，流水線並行中規整的點對點傳輸，以及張量並行中極端敏感的微小延遲——是否能為一類更“節儉”且高效的拓撲結構提供生存土壤？正是在對“算力焦慮”與“成本現實”的雙重回應下，Dragonfly 拓撲及其衍生變種從 HPC 學術界進入了 AI 產業的核心視野，一場從“分層樹”到“直接圖”的網路架構範式革命正式啟幕。
2. 核心定義與架構哲學：解碼 Dragonfly 的“組”與“稀疏連線”基因
Dragonfly 拓撲本質上是直接互連網路在高基數交換器時代的一次復興與嬗變。其定義可精煉為：一種將海量終端節點劃分為若干對稱、內部高聯通的“組”（Group），組間通過稀疏但直接的全域性鏈路進行耦合的網路架構。其核心哲學在於擁抱網路架構的“區域性性”，並通過對全域性頻寬的精細化排程，以最小的物理連線成本換取接近全連線的效能。
要理解 Dragonfly，須先解構“組”這一基本單元。一個理想化的組，是一組通過本地交換器或背板實現全二分頻寬（Full Bisection Bandwidth）互連的節點集合。假設一個組包含 a 個路由器，每個路由器下接 p 個終端節點，組內所有 a·p 個節點間的通訊最多僅需兩跳。該設計保證了佔 AI 訓練通訊大部分份額的組內流量享有極低延遲與絕對非阻塞頻寬。
Dragonfly 的精髓在於組間連線方式。若系統共有 g 個組，傳統思路要求所有組間無阻塞連線，需要極其可觀的全域性鏈路。Dragonfly 則引入一個關鍵抽象：將每個組虛擬成一個高基數邏輯節點，所有組通過“全連線拓撲”耦合。具體而言，每個組中指定 h 個全域性埠，這些埠通過長距光模組連線至其他 g-1 個組的相應埠，整體形成組間 1 跳直達的虛擬全連線。由於 h 遠小於組內總埠數，全域性鏈路數量被極大壓縮。這種“組內富連線、組間稀疏全連線”的基因，使 Dragonfly 在保持直徑極短（任意兩節點最多三跳）的同時，將 O(N²) 的長距離鏈路需求降至 O(N)。對 AI 訓練而言，這一屬性不僅大幅削減了 800G 光模組數量，還使通訊延遲更具確定性，為大規模資料並行的梯度同步提供了理想骨架。
3. 拓撲引數化與擴充套件性分析：用最少跳數承載最大規模
Dragonfly 的擴充套件性源於其結構引數的巧妙設計。設單個組的規模為 a 臺路由器，每臺路由器提供 p 個面向終端的下行埠和 h 個全域性上行埠，則組內總節點數為 a·p。組間通過 h 個全域性埠連線到其他 g-1 個組，要求 h ≥ g-1 以實現虛擬全連線。系統總節點數 N = g·a·p。該規模下，任意節點間通訊的跳數為：同組內 2 跳，跨組 3 跳（源節點→源路由器→目的組路由器→目的節點）。這種極短的直徑使 Dragonfly 能在數十萬節點規模下仍保持低延遲特性。
與 Fat-Tree 相比，Dragonfly 的物理擴充套件遵循漸進式法則。對於一個 k-ary n-tree，節點數上限為 (k/2)ⁿ，所需交換器數隨層數冪次上升；而 Dragonfly 通過增加組數 g 和組內路由器數 a 兩個獨立維度進行擴充套件。更重要的是，全域性鏈路增量與 g²·h 呈線性關係，非阻塞要求下全域性頻寬只需滿足平均流量，無需為極端流量模式預留 O(N²) 的物理線路。這使得從萬卡到十萬卡跨越時，Dragonfly 僅需增購少量全域性光模組，而 Fat-Tree 則可能需要新增整個核心層平面。根據粗略建模，當 N=16384 時，三層全頻寬 Fat-Tree 所需核心交換器埠數約為 Dragonfly 全域性埠數的 3.2 倍，光模組成本差異可達 35% 以上。因此，Dragonfly 可視為一種通過拓撲壓縮實現“規模-成本-效能”三角平衡的系統級創新。
4. 組內互聯技術選擇：電交換、銅纜與背板融合
組內互聯決定了 Dragonfly 效能的下限。在萬卡叢集中，一個組通常包含 128~256 個加速器。實現組內全二分頻寬的手段有多種：一是單臺高基數交換器，如 32 埠 800G 交換器下聯 256 個 100G 埠（Port Extender 模式）；二是採用銅纜背板或電交換晶片建置全互聯 mesh，如 Nvidia NVSwitch 架構，其將 8 顆 GPU 通過 NVSwitch 實現組內全頻寬共享。Dragonfly 的“組”可對映為 NVSwitch 域，利用 NVLink 4.0 高達 900 GB/s 的片間頻寬完成組內 All-Reduce。
當組規模超過單臺交換器能力時，可採用多臺交換器以 Fat-Tree 或 Ring 方式建置子組。但為了保持 Dragonfly 的兩跳屬性，業界傾向於使用扁平化的大埠交換器，如 Broadcom Tomahawk 5（64×800G），一臺即可下沉 512 個 100G 終端。組內銅纜（DAC/ACC）因其低成本、低功耗而被大量採用，3 米內的 100G/200G 銅纜價格僅為同速率光模組的十分之一。組內互聯的物理設計需嚴格考慮訊號完整性、散熱和佈線密度，以 2U 高度的液冷散熱機櫃為例，銅纜捆束的彎曲半徑往往成為限制節點密度的第一約束。先進的組內設計正逐步走向 Chiplet 化的矽中介層（Interposer）互聯，例如將 8 顆 GPU 與交換器功能整合在同一基板上，徹底消除銅纜。
5. 全域性鏈路設計：光學模組、光纖拓撲與頻譜最佳化
全域性鏈路是 Dragonfly 的靈魂。由於組間物理距離可能跨越 10500 米，長距光模組成為必然選擇。從 400G FR4 到 800G DR8/FR4，光模組的每位元成本與功耗是全域性鏈路設計的關鍵指標。在 Dragonfly 組間稀疏連線模型下，全域性鏈路頻寬 B_global 等於 h·C，其中 C 為單埠速率。為防止跨組流量成為瓶頸，設計者需確保 B_global 匹配峰值跨組流量需求，實踐中通常按平均流量的 1.52 倍配備，這得益於自適應路由對全域性鏈路利用率的大幅提升。
光纖拓撲方面，基於 Mesh 配線架的物理連線會將每個組的一簇光纜扇出到其他所有組，形成“光纖海”。為降低施工複雜度，廠商開始引入多芯光纖（MCF）和波長分波多工（WDM）技術，將數十條邏輯通路壓縮到一根光纖中。在十萬卡叢集中，若組數 g=64，每組的全域性埠 h=64，則僅全域性鏈路就需要 2016 條物理光纖。採用 8 芯單模光纖配合分光器可大幅減少線纜根數，但需在兩端增加光分配單元，帶來額外插損。光模組的選型也從傳統的可插拔 QSFP-DD 向 CPO（共封裝光學）演進，以減少交換晶片到光引擎的電氣損耗，並提升埠密度。當前，CPO 仍處於產業化早期，但已被視為百萬卡 Dragonfly 的必要準備。
6. 路由演算法：從靜態路由到自適應負載均衡的蛻變
Dragonfly 的稀疏全域性鏈路結構決定其效能高度依賴路由演算法的智慧程度。靜態路由（如最短路徑優先）極易導致全域性鏈路上的熱點擁塞，因為多個源組可能同時向同一目的組注入流量，而單條全域性鏈路頻寬有限。為了避免瓶頸，必須引入自適應路由。
經典的自適應策略 UGAL（Universal Globally-Adaptive Load-balanced）成為 Dragonfly 的標配。UGAL 在源路由器計算兩條路徑：一條是最短路徑（1 跳全域性直達），另一條是繞道路徑（經中間組轉發，共 2 跳全域性）。路由器根據本地佇列長度或全域性鏈路利用率動態選擇負載較輕的路徑。模擬表明，在均勻隨機流量下，UGAL 能使 Dragonfly 吞吐量達到理想上限的 90% 以上；在 AI 訓練常見的 All-Reduce 通訊模式中，配合拓撲感知的環形或集合通訊演算法，UGAL 可維持接近非阻塞的效能。
然而，AI 流量具有突發性和同步性，梯度同步常導致多節點同時向同一引數伺服器或 All-Reduce 組成員傳送資料，引發“網路風暴”。為此，業界提出了改進的 PBR（Per-Burst Random）和 Presto 等細粒度負載分擔技術，將流分成 64KB~256KB 的小批次，隨機選擇等價路徑。在 Dragonfly 中，將 Presto 應用於全域性鏈路，每批資料隨機選取一個可用的全域性埠，可有效打散流量，抑制擁塞樹形成。最新的探索還包括基於強化學習（RL）的線上路由最佳化，通過收集端到端延遲和丟包訊號，動態調整路由表，以適應訓練任務的變化。
7. 擁塞控制機制：ECN、QCN 與針對 AI 流量的定製化設計
路由演算法解決流量分佈問題，擁塞控制則負責端到端的速率調節。在 Dragonfly 環境下，跨組流經過單跳全域性鏈路時，若全域性埠已滿，極易形成瞬時佇列堆積，即使微小的擁塞也將引發 TCP 的重傳超時或 RoCEv2 的 PFC（優先順序流控）反壓，進而傳播至整網，導致吞吐量塌陷。
資料中心普遍採用 ECN（顯式擁塞通知）配合 DCQCN 演算法來調節速率。DCQCN 能夠根據 ECN 標記的速率快速降低流視窗，並在無擁塞時保持線速。但對於 Dragonfly 中極短的跨組鏈路，端到端 RTT 可能僅 5~10μs，傳統 ECN 的閾值設定容易過於滯後。因此，需要更激進的早期擁塞檢測：交換器可在佇列深度達到閾值的一半時即開始機率標記，並結合即時端到端延遲測量（如逐包 RTT 監測）加速反應。
Google 的 Swift 演算法為 Dragonfly 提供了新思路，Swift 基於端到端延遲目標而非單純的 ECN 標記，能在擁塞極早期就採取行動，非常適合 AI 訓練中對尾部延遲極其敏感的特點。在 Dragonfly 萬卡叢集的實踐中，部署 Swift 或 HPCC++（高精度擁塞控制）可將 All-Reduce 的 99.9% 尾部延遲降低約 40%，直接提升訓練整體效率。擁塞控制還需與路由協同：當交換器發現某全域性埠持續擁塞時，應觸發路由層重新分配流量，形成閉環最佳化。
8. 與 Fat-Tree、Torus、Hypercube 的定量對比：為何 Dragonfly 成為優選
為解釋產業傾向，需從等規模、等頻寬條件下進行多維度對比。假設建立一個包含 8192 個加速器、每加速器 200Gbps 注入頻寬的叢集。
- Fat-Tree：需 3 層結構，葉脊總計約 256 臺交換器（64×200G）。核心層需 128 臺 64 埠交換器，光模組數量巨大，佈線複雜度高，但路由簡單、負載均衡天然，業務配置容易。
- 2D/3D Torus：每個節點直接連線鄰居，佈線規則性強，但直徑隨規模線性增長，平均跳數高，在非鄰居通訊時需消耗大量中間頻寬，不適合 AI 訓練中頻繁的全域性 All-to-All 集合通訊。
- Hypercube/All-to-All：埠數隨維度指數上升，物理不可實現。
- Dragonfly：將 8192 節點劃分為 64 組，每組 128 加速器。組間利用 64 個全域性埠互連，僅需 128 條全域性光纖（每方向），比 Fat-Tree 的數千條大幅減少。直徑穩定在 3 跳，且通過 UGAL 路由可獲得接近 Fat-Tree 的吞吐。在 All-Reduce 模擬下，Dragonfly 完成 1GB 梯度同步時間相比 Fat-Tree 僅增加 8%~12%，而一次性建設成本（CAPEX）降低約 28%，年度能耗（OPEX）因光模組減少而下降 18%。
這種價效比優勢使 Dragonfly 成為雲端廠商和超算中心建設萬卡至十萬卡叢集時難以抗拒的選擇。但需注意，Dragonfly 的效能優勢高度依賴智慧路由與擁塞控制的成熟度，若軟體棧不完善，其吞吐可能大幅劣化，因此本質上是“軟體定義拓撲”。
9. 成本結構深度剖析：光模組、交換器與佈線施工的再分配
將 Dragonfly 的成本節約具體化，需拆解典型 16384 GPU 叢集的 BOM。按 Fat-Tree 方案，需要 64 埠的葉交換器 256 臺，100 埠脊交換器 128 臺，核心交換器 64 臺，單埠 400G。光模組需求：葉到脊使用短距多模 SR4 約 8192 個，脊到核心使用長距 FR4 約 16384 個，光模組總成本估算約 2200 萬美元（單價按 400G FR4 $450、SR4 $120 計）。交換器成本約 1500 萬美元。佈線施工、光纖配線架等約 600 萬美元。合計約 4300 萬美元。
採用 Dragonfly，將交換器重新分配為組內交換器和全域性鏈路。假設每組 4 臺 128 埠交換器，下聯 512 加速器，需 32 組。組間全域性埠每個交換器提供 32 個，總全域性埠數 4096，形成 32 組虛擬全連線。全域性光模組僅需約 4096 個長距 FR4，組內全部使用 DAC 銅纜（成本忽略不計）。光模組總成本驟降至約 184 萬（僅全域性用），交換器成本因埠利用率提升而降至 1200 萬，佈線大幅簡化，施工等降至 200 萬，總計約 2500 萬。降幅達 42%。加上能耗和散熱成本，五年 TCO 差距更為顯著。當然，此估算基於標準化部件，實際專案中還需考慮開發和運維複雜度等隱性成本，但無可否認 Dragonfly 在物理層成本上具備壓倒性優勢。
10. 實際部署案例分析：從 HPC 先驅到 AI 超算的 Dragonfly 實踐
Dragonfly 並非紙上談兵，其在 HPC 領域已有十餘年執行歷史。Cray XC 系列超算（如英國 Archer2、美國 Theta）率先部署了 Aries 互連，該互連便是 Dragonfly 的傑出實現。Aries 使用 48 埠路由器，每組 4 個路由器構成組，通過光學全域性鏈路連線數百組，驗證了 Dragonfly 在數千節點 MPI 作業下的高效穩定。
進入 AI 時代，Nvidia 在 2023 年釋出的 DGX SuperPOD 參考架構已隱含 Dragonfly 理念。其將 8 卡 DGX 視作一個組，內部通過 NVSwitch 全互聯，多個 DGX 之間利用 InfiniBand 交換器以 Dragonfly 樣式建置二層網路，通過 SHARP 技術實現組間歸約。微軟 Azure 在其 AI 叢集中也探索了類似拓撲，以降低跨 ToR 流量對核心層的衝擊。國內代表如鵬城雲端腦 II，採用自研互連架構，借鑑 Dragonfly 思路實現 4096 卡的高效連線。這些案例均表明，Dragonfly 從科學計算向 AI 計算的遷移是平滑且成功的，前提是對 AI 特定的集合通訊（NCCL/RCCL）進行拓撲感知最佳化，使環順序、樹結構能與物理組對映對齊。
11. 軟體生態融合：集合通訊庫、MPI 與拓撲感知最佳化
Dragonfly 的硬體優勢需要軟體棧深度協同才能釋放。NCCL、RCCL 等集合通訊庫通過層次化 All-Reduce 策略與物理組形成天然對應關係。典型實踐中，將組內 GPU 列表對映為 NCCL 的低延遲區域性通訊域，組間則應用 Ring 或 Tree 演算法，利用全域性鏈路進行跨組梯度聚合。NCCL 2.12 後的版本已支援使用者通過環境變數顯式指定網路拓撲層級，實現“拓撲感知的通訊排程”。
MPI 層同樣需要適配。在執行大規模分散式訓練時，MPI 程序繫結策略應遵循 Dragonfly 的組親和性：同一組的 MPI Rank 應儘量安排在同一作業內，以最大化組內高頻寬的利用。HPE 的 MPI 庫整合 UGAL 路由資訊，可為每個訊息選擇路徑。此外，網路彈性方面，Dragonfly 的容錯需要與業務無感知切換結合：當一條全域性鏈路故障，後臺路由表在 10 毫秒內收斂，集合通訊庫應能遮蔽該瞬態。Netmind 等工具已在實踐中通過監控鏈路狀態，主動通知 NCCL 調整演算法路徑，避免因網路重收斂導致的訓練停頓。軟體生態的成熟度最終決定了 Dragonfly 能否從“節省成本”走向“效能無劣化”。
12. 從萬卡到十萬卡：Dragonfly 的擴充套件瓶頸與突破路徑
當叢集規模突破 32768 卡走向十萬卡時，單層 Dragonfly（一組一級）會面臨兩個瓶頸：一是全域性埠數 h 必須大於等於 g-1，當 g 達到 256 時，每臺路由器需提供至少 256 個高頻寬全域性埠，總埠數極大，晶片面積和能耗難以承受；二是組間虛擬全連線帶來的全域性鏈路數量仍將平方增長，雖然壓縮了但依然可觀。為解決此問題，業界提出了 Dragonfly+ 和 Megafly 層次化擴充套件。
Dragonfly+ 在組內引入第二層獨立交換器，將組的規模擴大，同時全域性組數維持適中。Megafly 則引入“超級組”概念，形成二級 Dragonfly，類似於 Fat-Tree 的三層結構但保留直接互連的稀疏性。此外，光電路交換（OCS）被引入以動態重構全域性拓撲：在訓練不同階段，可通過光交換矩陣改變 Dragonfly 的組間連線權重，為特定流量模式提供臨時高頻寬通路。Google 的 TPU v4 便採用 OCS 動態塑造拓撲，可為 Dragonfly 注入動態靈活性。這些演進路徑確保 Dragonfly 家族能平滑擴充套件至百萬卡，而無需犧牲其根本的簡潔性。
13. 安全與可靠性：故障域隔離、快速收斂與多路徑冗餘
大規模叢集中故障不可避免，Dragonfly 需提供與傳統 Fat-Tree 同等級的可靠性。由於 Dragonfly 的組間連線稀疏，單條全域性鏈路故障可能導致部分組間頻寬下降，路由需要迅速將流量切換至其他冗餘埠。利用多平面設計，每個組通常有 h 條全域性鏈路到目的組，若其中一條斷掉，UGAL 會感知並避開該埠，剩餘 h-1 條會承擔全部流量，造成瞬時頻寬下降但不斷流。交換器需支援快速故障檢測，如鏈路層發現（LACP 或 BFDetect）30 毫秒內完成切換。
故障域隔離方面，組的邊界天然形成第一道屏障。某臺交換器或某個節點失效，僅影響其所在組的區域性流量，其他組間通訊不受波及，這與 Fat-Tree 葉交換器故障影響範圍相當。為防止組間路由振盪引發全叢集癱瘓，實踐中部署了區域保護策略：如設定全域性鏈路利用率上限 90%，避免過載連鎖反應。同時，通過多路徑 ECMP 結合細粒度流控制，Dragonfly 可實現裝置級冗餘，甚至在某些設計下實現零停機線上擴充套件（新增新組後重新計算路由雜湊）。因此，只要軟體棧設計周全，Dragonfly 的可靠效能滿足生產環境要求。
14. 下一代拓撲演進：Dragonfly+、Megafly 與直接互連的未來
面對 2025-2027 年百萬卡叢集預期，學術界和產業界已開始探索 Dragonfly 的後續形態。Dragonfly+ 通過對組內進行再分層，允許組規模達到 1024 節點而仍保持區域性高頻寬。Megafly 則採用雙層分組，總規模可達 N = G·g·a·p，將互連層次分為“組內”“超級組內”和“超級組間”三層，全域性直徑仍控制在 5 跳以內。同時，整合的矽光子交換器將路由、交換和光介面融合為單一 Chiplet，進一步降低全域性鏈路的功耗和延遲。
另一激進路線是直接全光纖互連的“隨機稀疏圖”（如 Jellyfish、Slim Fly），通過打破組的對稱性，進一步減少總鏈路數，但隨之而來的是路由複雜度的急劇上升和死鎖風險增加。綜合來看，Dragonfly 及其直接後裔因在拓撲規則性與自適應能力間取得平衡，仍被多數專家視為通往百萬卡的最可行路徑。中長期，AI 負載特異性可能催生出“可訓練拓撲”：即利用 AI 本身對網路連線進行演化，找到針對特定訓練任務的最優拓撲，此時 Dragonfly 可能作為基態被進一步微調。
15. 結論與戰略建議：擁抱直接互連時代，建置可持續的 AI 基礎設施
本報告系統闡述了 Dragonfly 拓撲在萬卡至十萬卡 AI 叢集中的突出價值。它不僅是應對光模組成本危機的權宜之計，更是架構思維的升級：從追求端到端無阻塞物理線路，轉向以智慧路由和擁塞調節換取物理極簡的有損網路。對於 AI 基礎設施決策者，我們提出以下建議：
- 規模評估：當叢集規模超過 4000 卡時，就應將 Dragonfly 納入前期拓撲選型，而 8000 卡以上則強烈推薦以 Dragonfly 為主架構。
- 軟體先行：Dragonfly 的成功高度依賴自適應路由和擁塞控制，須在採購硬體前確保自研或第三方軟體棧成熟，特別是與 NCCL 的整合。
- 彈性規劃：採用模組化組設計，預留全域性埠和光纖路由，使未來可從 32 組平滑擴充套件到 128 組而不中斷業務。
- 產業協作：推動交換器晶片廠商（Broadcom、Nvidia、Marvell）原生支援 UGAL 等 Dragonfly 友好路由，減少額外開發成本。
- 人才儲備：培養既懂 AI 通訊模式又熟悉直接互連拓撲的網路工程師，將直接決定叢集的最終能效。
Dragonfly 拓撲所代表的“稀疏直接互連”理念，不僅適用於 AI 訓練，還將滲透至推論叢集、存算分離池化等場景，成為下一代資料中心網路的基礎語言。面對百萬卡前夕的算力競速，擁抱 Dragonfly 即是擁抱一種更可持續、更高效的超大規模計算未來。