跳到主要内容

Dragonfly 拓扑

关联:总览.md — 名词定义与评估指标体系


基本结构

Dragonfly(Kim et al., ISCA 2008)是三级层次结构:

终端节点
└─> 路由器(Router)
└─> 组内本地链路(组内全互联)
└─> 组间全局链路(Global Links,少量长距离)

每个**组(Group)内的路由器彼此全互联,形成一个高带宽域。不同组之间通过少量全局链路(Global Links)**互联——全局链路数量远少于组内链路,但连接范围覆盖所有组对。

每个路由器有三类端口:

  • $p$ 个终端端口(连计算节点)
  • $a-1$ 个本地链路(连同组其他路由器,组内全互联)
  • $h$ 个全局链路(连其他组的路由器)

平衡设计$a = 2p = 2h$,使本地链路带宽与全局链路带宽匹配。

Dragonfly+Shpiner et al., IEEE HOTI 2017)改进版本:

  • 组内改为 Fat-tree 代替全互联
  • 每对组之间有多条全局链路(而非 Dragonfly 原版的 1 条)
  • 增加路径多样性,降低自适应路由的激进程度需求

关键参数

标准 Dragonfly(平衡设计,$a = 2p = 2h$):

属性
每组路由器数$a$
组数$g = ah + 1$
路由器总数$a \cdot g$
终端总数$N = p \cdot a \cdot g$
路由器度数$p + (a-1) + h$
网络直径3 跳(local -> global -> local,最小路由)
全局链路总数$\frac{g \cdot a \cdot h}{2}$

关键数据——全局链路数量:

$N$Fat-tree Spine 链路Dragonfly 全局链路节省倍数
10,000~60,000~12,0005x
100,000~800,000~120,0006.7x

全局链路通常是长距离光缆(跨 rack/跨 row),单价远高于本地链路(铜缆)。Dragonfly 减少全局链路数是其成本优势的核心。


路由算法

Minimal Routing

最多 3 个路由器跳(local -> global -> local),即网络直径。

核心问题:对抗性流量(如某个 Group 的所有节点同时向另一个 Group 发送)使少数全局链路饱和,而其他全局链路空闲。

Valiant 路由

先路由到随机中间 Group,再到目标 Group。路径最多 5 跳(local -> global -> local -> global -> local),最坏情况吞吐为 Minimal 的 50%,但在对抗性流量下远优于 Minimal。

UGAL(Universal Globally Adaptive Load-balanced)

Dragonfly 的必配路由算法:

对每个数据包:
1. 计算 Minimal 路径的预估代价 C_min = queue_depth(minimal_port) + hops_min
2. 随机选一个中间 Group,计算 Valiant 路径代价 C_val = queue_depth(valiant_port) + hops_val
3. if C_min < C_val × bias_factor:
选 Minimal
else:
选 Valiant

UGAL 为什么是 Dragonfly 的必须配置

  1. 全局链路是稀缺资源——每组仅 $ah$ 条出口链路,占总链路的 ~10-20%
  2. Minimal routing 在非均匀流量下使部分全局链路过载 >5× 而其他空闲
  3. Valiant routing 在均匀流量下浪费 50% 带宽
  4. UGAL 动态切换:均匀流量时 >90% 选 Minimal,对抗性流量时 >80% 选 Valiant
  5. 实测 UGAL 在所有流量模式下达到 Minimal 和 Valiant 中较优者的 90%+ 吞吐

各流量模式下吞吐对比:

流量模式Minimal 吞吐Valiant 吞吐UGAL 吞吐
均匀随机100%50%~95%
邻组通信~30%50%~80%
对抗性~10%50%~70%

来源:Kim et al., ISCA 2008Jiang et al., 2009

UGAL 变体

  • UGAL-L:基于本地队列深度决策(低开销但信息不完整)
  • UGAL-G:基于全局负载信息(更准确但需要额外带宽传播状态)
  • PAR (Progressive Adaptive Routing):在路径的每一跳都可以从 Minimal 切换到 Valiant

死锁避免:Minimal routing 无死锁(路径严格 local -> global -> local,不回头)。Valiant/UGAL 的非最短路径会引入环,需要 2-3 个虚通道(VC)打破环依赖。


通信性能特性

Hierarchical AllReduce

利用 Dragonfly 的组结构做两级归约:

  1. 组内 AllReduce(利用高带宽本地链路)
  2. 组间 AllReduce(仅交换组间归约结果,减少全局链路流量)

这将全局链路上的数据量从 $M$ 降至 $M/a$$a$ = 每组路由器数)。

AllToAll on Dragonfly

MoE 的 AllToAll 是 Dragonfly 的最大挑战。全对全流量使所有全局链路同时饱和,且流量分布不均匀。UGAL 可缓解但不能完全解决——根本原因是全局链路的总带宽不足以支撑全割集通信。

Dragonfly 的割集带宽约为 Fat-tree 的 70%,AllToAll 效率处于中等水平。

拥塞特性

  • 全局链路是瓶颈:占总链路 10-20%,但承载所有跨组流量
  • Minimal routing 下的热点:对抗性流量使特定全局链路过载 5-10x
  • UGAL 后的残余拥塞:非最短路径增加网络总流量,在高负载时全局链路仍可饱和
  • AI workload:TP 应在同组内完成(本地链路带宽高);DP AllReduce 跨组时 UGAL 有效负载均衡;MoE AllToAll 是最差场景

适用场景

Dragonfly 主要出现在以下场景:

  1. HPC 超算集群:HPE Cray Slingshot 生态,Frontier、Aurora、El Capitan 等超算
  2. 大规模 DP 密集型工作负载:DP AllReduce 的流量模式相对均匀,UGAL 可有效处理
  3. 以 PP + DP 为主的训练策略:MoE AllToAll 不是主要通信瓶颈时

局限性

  1. 割集带宽低于 Fat-tree:约为 Fat-tree 的 70%,AllToAll 效率受限
  2. 必须配合 UGAL:没有自适应路由,对抗性流量下性能急剧下降(10% 吞吐)
  3. 全局链路是单点瓶颈:每对组之间的全局链路数量有限,故障影响显著
  4. 商用生态仅 HPE Cray:Slingshot 是目前唯一商用化的 Dragonfly 实现,生态锁定
  5. MoE AllToAll 性能差:不规则流量分布在 Dragonfly 上产生严重拥塞

成本分析

Dragonfly 的设计目标就是最小化昂贵的全局链路:

链路类型数量增长阶
本地链路$g \cdot \frac{a(a-1)}{2}$$O(N)$
全局链路$\frac{g \cdot a \cdot h}{2}$$O(N^{2/3})$(平衡设计)

Dragonfly 的成本优势在万节点以上才显现——全局链路数 $O(N^{2/3})$ vs Fat-tree Spine 链路 $O(N)$。在 1024 节点规模下,Dragonfly 成本反而可能高于 Fat-tree。


在大模型集群中的实际应用

所有大规模 Dragonfly 部署均使用 HPE Cray Slingshot 互联:

系统规模互联拓扑
Frontier (ORNL)37,888 MI250XSlingshot-11Dragonfly
Perlmutter (NERSC)6,159 A100Slingshot-11Dragonfly
Aurora (ANL)63,744 GPU MaxSlingshot-11Dragonfly
El Capitan (LLNL)44,544 MI300ASlingshot-11Dragonfly

来源:OLCF FrontierNERSC PerlmutterHPE Slingshot

Dragonfly 与 AI 训练的适配性:上述系统以 HPC 工作负载为主(CFD、气候模拟、分子动力学)。AI 训练(尤其 MoE 模型)的 AllToAll 流量在 Dragonfly 上表现不理想,这是 AI 集群不选择 Dragonfly 的主要原因。Frontier 等系统承载 LLM 训练时,MoE AllToAll 效率低于 Fat-tree 集群。


参考资料

资料关键内容
Kim et al., ISCA 2008Dragonfly 拓扑原始论文,UGAL 路由数据
Jiang et al., 2009UGAL 各流量模式吞吐分析
Shpiner et al., IEEE HOTI 2017Dragonfly+ 论文
HPE Slingshot商用 Dragonfly 实现