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 即是拥抱一种更可持续、更高效的超大规模计算未来。