跳到主要内容

拓扑横向对比

按通信模式、规模扩展、成本、路由复杂度与容错能力多维比较主流集群拓扑

核心要点

  • Fat-tree 在所有维度无明显短板,是通用 AI 训练首选
  • 3D Torus 成本仅 Fat-tree <10%,但 AllToAll 效率低 (TPU 唯一)
  • Dragonfly 仅 HPC 超算 (HPE Slingshot 生态)
  • 大消息 AllReduce 带宽项各拓扑都达理论下界,差异在延迟项
  • MoE AllToAll 对全割集要求最高,Fat-tree 必备
  • 网络成本占 TCO: Google <10% / Meta 20-30% / NVIDIA 30-40%
  • 故障恢复:Dragonfly UGAL ms-s,Fat-tree ECMP 1-10s,Torus 10s-min

LLM 集合通信对拓扑有什么需求?

四种核心操作 + 各自需求 (@tbl-topo-cmp-ops):

操作并行策略数据量级频率对拓扑的需求
AllReduceTP, DP大 (100MB-10GB)每层/每 step高割集带宽
AllToAllEP (MoE)大,非均匀每 MoE 层全局均匀带宽
P2P (Send/Recv)PP中 (activation)每 stage 边界低延迟路径
AllGather / ReduceScatterSP, TP每层类似 AllReduce

@tbl-topo-cmp-ops 集合通信操作

AllReduce 在各拓扑上效率怎么对比?

理论带宽下界:任意算法至少传输 $\frac{2(N-1)}{N} \cdot M$ 字节[1]

各拓扑最优算法 (@tbl-topo-cmp-allreduce):

拓扑最优算法延迟项带宽项瓶颈
Full MeshRecursive Halving-Doubling$2\log N \cdot \alpha$$\frac{2(N-1)}{N} \cdot \frac{M}{\beta}$端口注入带宽
RingRing AllReduce$2(N-1) \cdot \alpha$同上延迟 $O(N)$
3D TorusDimension-Decomposition$\sum 2(k_d-1) \cdot \alpha$同上割集 $O(N^{2/3})$
Fat-treeTree AllReduce / SHARP$2\log N \cdot \alpha$同上ECMP 碰撞
DragonflyHierarchical AllReduce$\sim 4\log N \cdot \alpha$同上全局链路带宽
HypercubeRecursive Halving-Doubling$2\log N \cdot \alpha$同上$O(\log N)$

@tbl-topo-cmp-allreduce AllReduce 效率对比

关键观察

  • 带宽项对所有拓扑最优算法都相同,都达理论下界。差异在延迟项和实际可用带宽
  • 大消息 ($M > 100$ MB,LLM 训练典型):带宽项主导,Ring AllReduce 在任何拓扑上接近最优
  • 小消息 ($M < 1$ MB,推理场景):延迟项主导,Tree / RHD 显著优于 Ring ($O(\log N)$ vs $O(N)$ 步)

AllToAll 在各拓扑上效率怎么对比?

MoE 的核心操作:每节点向所有其他节点发送不同数据块。

$$\begin{equation} T_{\text{AllToAll}} \geq (N-1) \cdot \frac{M}{N \cdot \beta_{\text{bisection}}} \label{eq:topo-comparison-alltoall-bisection-bound} \end{equation}$$
拓扑AllToAll 效率原因
Fat-tree最高全割集 $\frac{N}{2}b$,ECMP 分散流量到多路径
Hypercube割集 $\frac{N}{2}b$,XOR 排列算法
Dragonfly割集 ~70% Fat-tree,全局链路在 AllToAll 下饱和
3D Torus割集 $O(N^{2/3})$,DOR 在 AllToAll 下 $O(\sqrt{N})$ 拥塞
Ring极低割集 $2b$,AllToAll 退化为串行

@tbl-topo-cmp-a2a AllToAll 效率对比

MoE 场景特殊性:实际 MoE 的 AllToAll 是稀疏的 — 每 token 只路由到 top-k experts (如 DeepSeek-V3 的 8/256)。稀疏 AllToAll 流量比全 AllToAll 小 $\frac{k}{E}$ 倍,但分布不均 (热门 expert 接收更多 token),这种不均在 Torus 上尤为致命。

Google TPU v4 解决方案:Expert 放置策略将高频通信 Expert 放在 Torus 近邻 + OCS 动态调整拓扑[2]

P2P (PP) 效率对比

核心问题:流水并行 P2P 通信在各拓扑上效率差异多大、哪些拓扑天然匹配 PP 的 stage 放置?

PP 对拓扑要求低于 TP 和 EP:P2P 通信量相对小 (仅 activation),仅涉及少量 stage 对,拓扑感知 stage placement 可将相邻 stage 映射到近邻节点。

拓扑P2P 效率原因
Full Mesh最高1 跳直达
Fat-tree2-3 跳
Dragonfly3-5 跳,取决于 stage 组分布
Hypercube$O(\log N)$
3D Torus中-低$O(N^{1/3})$ 跳,取决于 stage 放置
Ring$O(N)$ 跳 (最坏)

@tbl-topo-cmp-p2p P2P 效率对比

综合适配矩阵 (评分 1-5)

核心问题:一张矩阵表里各拓扑在 AllReduce、AllToAll、P2P 上的适配评分如何排布?

拓扑AllReduce (大)AllReduce (小)AllToAll (MoE)P2P (PP)综合
Full Mesh (≤72)55555.0 (仅节点内)
Fat-tree45544.5
Hypercube45434.0
3D Torus43233.0
Dragonfly33333.0
Ring31111.5

@tbl-topo-cmp-fit 综合适配矩阵

Fat-tree 是唯一在所有通信模式上均良好的可扩展拓扑。这解释了商用 AI 集群中的统治地位。

规模上限和割集随规模

核心问题:各拓扑的规模上限和割集带宽随 N 增长的趋势如何对比?

规模上限 (@tbl-topo-cmp-scale):

拓扑理论上限实际上限限制因素
Full Mesh~72 (NVL72)72端口/功耗/散热
Ring无限~64割集不增长
3D Torus~10,0008,960 (TPU v5p)环绕链路长度/OCS 端口
Fat-tree (3 级)$k^3/4$~65,536 ($k=64$)交换机 radix
Fat-tree (5 级)>100,000100,000 (xAI)成本/管理复杂度
Dragonfly>100,000~63,744 (Aurora)全局链路光缆成本
Hypercube~65,536 ($2^{16}$)65,536 (CM-2, 1987)度数 $O(\log N)$

@tbl-topo-cmp-scale 各拓扑规模上限

割集带宽随规模 (@tbl-topo-cmp-bb):

$N$Fat-tree3D TorusDragonfly+Hypercube
64$32b$$32b$ (100%)$\sim 22b$ (69%)$32b$ (100%)
256$128b$$80b$ (63%)$\sim 90b$ (70%)$128b$ (100%)
1,024$512b$$204b$ (40%)$\sim 360b$ (70%)$512b$ (100%)
4,096$2,048b$$512b$ (25%)$\sim 1,440b$ (70%)$2,048b$ (100%)
65,536$32,768b$$3,276b$ (10%)$\sim 23,000b$ (70%)$32,768b$ (100%)

@tbl-topo-cmp-bb 割集带宽随规模

关键趋势

  • Fat-tree 和 Hypercube 始终 100% 割集,但 Hypercube 度数 $\log_2 65536 = 16$
  • 3D Torus 比例从 100% ($N=64$) 快降到 10% ($N=65K$)
  • Dragonfly+ 稳定 ~70%,大规模性价比拐点

增量扩展能力

核心问题:各拓扑的增量扩展能力如何?哪些可以灵活增删节点、哪些必须按固定粒度扩展?

拓扑增量扩展说明
Fat-tree同层级添加 Pod 或增加层级
Ring环中插入新节点
Torus改维度大小需重布线
Dragonfly可添加新 Group,可能需重配全局链路
Hypercube极差$N$ 必须 $2^n$,扩展即维度+1 布线全变
Jellyfish随机插入新交换机即可

@tbl-topo-cmp-incr 增量扩展能力

Fat-tree 增量扩展能力是数据中心广泛采用的重要原因。

成本模型

核心问题:各拓扑在交换机、链路、光模块上的成本差异有多大?$N$=1024 时的绝对成本对比?

组件单价 (2024)

交换机 ($/port)

类型端口速率$/port
IB NDR400 Gbps$940 - 1,170
IB XDR800 Gbps$1,200 - 1,500
以太网 (Broadcom Memory)400 GbE$625 - 860
以太网 (Broadcom Jericho3-AI)800 GbE$800 - 1,100

@tbl-topo-cmp-sw-price 交换机单价

线缆/光模块 ($/port-pair)

类型速率距离$/pair
DAC400G≤3m$50 - 100
AEC400G3-7m$100 - 200
AOC400G7-100m$300 - 600
光模块 + 光纤400G>100m$600 - 1,200
光模块 + 光纤800G>100m$1,000 - 2,000

@tbl-topo-cmp-cable-price 线缆/光模块单价

$N = 1024, k = 16, 400G$ 链路对比

Fat-tree (3 级) (@tbl-topo-cmp-ft-cost):

组件数量单价小计
Edge 交换机128$16K$2.05M
Aggregation 交换机128$16K$2.05M
Core 交换机64$16K$1.02M
Edge-Agg 链路 (DAC)1,024$75$77K
Agg-Core 链路 (AOC)1,024$450$461K
NIC (每节点)1,024$500$512K
合计~$6.2M

@tbl-topo-cmp-ft-cost Fat-tree 成本 (N=1024)

3D Torus (直连)

组件数量单价小计
交换机0-$0
链路 (6/node)3,072$200$614K
ICI 端口 (芯片集成)6,144含芯片成本$0
合计~$0.6M

@tbl-topo-cmp-torus-cost 3D Torus 成本 (N=1024)

归一化对比

拓扑网络成本 / FT割集带宽 / FT性价比 (BW/$)
Fat-tree1.0×1.0×1.0×
3D Torus~0.08×~0.40×5.0×
Dragonfly~1.4×~0.70×0.5×

@tbl-topo-cmp-norm 归一化成本对比

3D Torus 性价比是 Fat-tree 的 5 倍 — 但前提是 AllToAll 需求低 + 可自研芯片集成 ICI。这解释 Google 选 Torus 的经济逻辑。

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

网络成本占 TCO

集群类型网络成本占比
NVIDIA DGX H100 集群 (IB)30-40%
Meta H100 集群 (RoCE)20-30%
Google TPU Pod (Torus)<10%

@tbl-topo-cmp-tco 网络成本占 TCO

路由策略对比

核心问题:各拓扑适配的路由算法(ECMP/DOR/UGAL/KSP)有什么不同、死锁风险如何?

路由算法分类

算法类型适用拓扑核心机制
ECMP静态多路径Fat-tree5-tuple 哈希选等价路径
DOR确定性Torus/Mesh按固定维度顺序
UGAL自适应Dragonfly动态选 Minimal/Valiant
SHARP网内计算Fat-tree (IB)交换机执行 Reduce
E-cube确定性Hypercube按 XOR 位序修正
Valiant随机化通用先到随机中间节点再目标

@tbl-topo-cmp-routing 路由算法分类

ECMP 碰撞问题

Fat-tree 上 $k/2$ 条等价路径通过 5-tuple 哈希分配流。

碰撞概率 (balls-into-bins): $n$ 条流随机映射到 $m = k/2$ 条路径,最大负载期望 $\Theta(\frac{n}{m} + \frac{\log m}{\log \log m})$

AI 集群实际问题:AllReduce 流量模式是固定的 (同一组 GPU 反复通信),哈希值不变,碰撞是持久的。Rail-Optimized Fat-tree 缓解 DP AllReduce 碰撞 (限 Rail 内),但 TP AllReduce (跨 Rail) 和 MoE AllToAll 仍受影响。

解决方案

  1. Packet spraying:每包独立选路径,需接收端重排序
  2. Flowlet-based:检测流内间隔,在间隔处切换路径
  3. 集中式调度 (Hedera):SDN 监控链路利用率,动态迁移大象流

UGAL 在 Dragonfly 上的必要性

Minimal vs Valiant 是延迟 vs 负载均衡的权衡[3]:

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

@tbl-topo-cmp-ugal UGAL 流量模式吞吐

没有 UGAL 的 Dragonfly 在对抗性流量下几乎不可用 (10% 吞吐)。

SHARP 影响

指标无 SHARP有 SHARP改善
AllReduce 延迟$2\log N \cdot \alpha$$\log N \cdot \alpha$
网络传输字节$2 \cdot \frac{N-1}{N} \cdot M$$\frac{N-1}{N} \cdot M$
有效 AllReduce 带宽基准+30-50%-

@tbl-topo-cmp-sharp SHARP 影响

SHARP 仅适用于 IB Quantum 交换机,是 NVIDIA IB 生态核心竞争力。以太网阵营无等价物。

死锁避免

拓扑死锁风险避免机制
Fat-tree (上行-下行无环)天然
Mesh (DOR 天然无环)天然
Torus (环绕链路成环)虚通道 + dateline
Dragonfly (Minimal) (local-global-local 不回头)天然
Dragonfly (UGAL) (非最短路径成环)2-3 个 VC
Hypercube (E-cube 按维度递增)天然

@tbl-topo-cmp-deadlock 死锁避免对比

故障容忍

核心问题:各拓扑在单点故障下的路径冗余、影响半径和恢复能力如何对比?

链路故障影响

拓扑单链路故障多链路容忍说明
Full Mesh极小 ($\frac{1}{N-1}$)$N-2$$(N-1)$-connected
Ring严重 (割集减半)0 条 (断开即分裂)最脆弱
3D Torus中 (一个维度降级)$2n-1$$2n$-connected
Fat-tree小 (ECMP 自动绕路)多条 ($k/2$ 冗余)高冗余
Dragonfly中 (全局链路影响组间)取决于组间冗余度全局链路单点
Hypercube小 ($\log N$ 条替代)$n-1$$n$-connected

@tbl-topo-cmp-link-fail 链路故障影响

交换机故障影响

拓扑单交换机故障影响
Fat-tree (Edge)该 ToR 下所有节点断网
Fat-tree (Core)割集降 $\frac{1}{k/2}$,ECMP 自动绕路
Torus无交换机可故障 (直连)
Dragonfly组内路由器故障:该路由器下终端断网 + 部分全局链路丢失

@tbl-topo-cmp-sw-fail 交换机故障影响

Fat-tree 的 Core 冗余是其故障容忍核心优势 — $(k/2)^2$ 个 Core 任一故障仅导致 $\frac{2}{k}$ 割集降级,ECMP 无感知切换。

故障恢复时间

拓扑故障检测路由收敛总恢复时间
Fat-tree (ECMP)ms秒级 (BFD + ECMP 更新)1-10s
Fat-tree (SHARP)ms需重建 SHARP tree10-30s
Torus (DOR)ms需全局路由重算10s-min
Dragonfly (UGAL)ms自适应路由自动绕路ms-s 级

@tbl-topo-cmp-recovery 故障恢复时间

Dragonfly UGAL 在故障容忍上独特优势:自适应路由自动感知故障链路队列堆积,无需等路由协议收敛。

综合评估矩阵

核心问题:一张综合矩阵里各拓扑在通信效率、成本、扩展性、路由复杂度、容错五维的最终排位?

维度Fat-tree3D TorusDragonflyHypercube
AllReduce 效率
AllToAll 效率最高
P2P 效率
规模上限100K+~10K100K+~65K
增量扩展
网络成本最低
故障容忍最高
路由复杂度低 (ECMP)低 (DOR)高 (UGAL)低 (E-cube)
死锁风险有 (UGAL)
商业生态最成熟Google onlyHPE only几乎无

@tbl-topo-cmp-final 综合评估矩阵

最终结论

  1. 通用 AI 训练集群:Fat-tree 是唯一所有维度无明显短板的选择。MoE 流行进一步巩固地位 (AllToAll 需全割集)
  2. 超大规模低成本集群:3D Torus 在自研芯片生态 (Google TPU) 中最优,成本为 Fat-tree <10%。前提是接受 AllToAll 效率低
  3. HPC 超算:Dragonfly 在 HPE Cray 生态唯一选择,UGAL 是可用性前提
  4. 未来方向:OCS 动态拓扑 (Google Orbiter) 可能改变选型逻辑 — 从"选一个固定拓扑"变为"按工作负载动态生成"

Takeaway

知识点核心结论
AllReduce 大消息带宽项各拓扑均达理论下界,差异在延迟和实际带宽
AllReduce 小消息延迟项主导,Tree/RHD $O(\log N)$ 优于 Ring $O(N)$
AllToAllFat-tree 全割集最高,3D Torus 最差 ($O(\sqrt{N})$ 拥塞)
规模上限Fat-tree 5 级 100K+,TPU 9K,NVL72 仅 72
成本Torus 性价比 5× Fat-tree (前提 AllToAll 低 + 自研芯片)
TCO 网络占比Google <10% / Meta 20-30% / NVIDIA 30-40%
路由复杂度Fat-tree ECMP 最简单,Dragonfly UGAL 最复杂
故障恢复Dragonfly UGAL ms-s 最快,Torus DOR 10s-min 最慢
商用结论Fat-tree 唯一在所有维度无短板,AI 训练首选

参考资料

  1. Thakur R. et al., Optimization of Collective Communication Operations in MPICH, IEEE TPDS 2005. https://doi.org/10.1109/TPDS.2005.90
  2. Jouppi N. et al., TPU v4, ISCA 2023. https://arxiv.org/abs/2304.01433
  3. Kim J. et al., Technology-Driven, Highly-Scalable Dragonfly Topology, ISCA 2008. https://doi.org/10.1109/ISCA.2008.19