横向对比分析
关联：总览.md — 名词定义 | fat-tree.md | torus.md | dragonfly.md | 厂商部署.md
本文从五个维度横向对比各拓扑：通信 pattern 适配、规模扩展、成本模型、路由策略、故障容忍。
通信 Pattern 与拓扑适配
集合通信操作概述
LLM 训练/推理中的四种核心集合通信：
| 操作 | 并行策略 | 数据量级 | 频率 | 对拓扑的需求 |
|---|---|---|---|---|
| AllReduce | TP, DP | 大 (100MB-10GB) | 每层/每 step | 高割集带宽 |
| AllToAll | EP (MoE) | 大，非均匀 | 每 MoE 层 | 全局均匀带宽 |
| P2P (Send/Recv) | PP | 中 (activation) | 每 stage 边界 | 低延迟路径 |
| AllGather / ReduceScatter | SP, TP | 大 | 每层 | 类似 AllReduce |
AllReduce 效率对比
理论带宽下界：任意 AllReduce 算法至少传输 $\frac{2(N-1)}{N} \cdot M$ 字节（来源：Thakur et al., 2005）。
各拓扑上的 AllReduce 算法选择与效率：
| 拓扑 | 最优算法 | 延迟项 | 带宽项 | 瓶颈 |
|---|---|---|---|---|
| Full Mesh | Recursive Halving-Doubling | $2\log N \cdot \alpha$ | $\frac{2(N-1)}{N} \cdot \frac{M}{\beta}$ | 端口注入带宽 |
| Ring | Ring AllReduce | $2(N-1) \cdot \alpha$ | $\frac{2(N-1)}{N} \cdot \frac{M}{\beta}$ | 延迟 $O(N)$ |
| 3D Torus | Dimension-Decomposition | $\sum 2(k_d-1) \cdot \alpha$ | $\frac{2(N-1)}{N} \cdot \frac{M}{\beta}$ | 割集带宽 $O(N^{2/3})$ |
| Fat-tree | Tree AllReduce / SHARP | $2\log N \cdot \alpha$ | $\frac{2(N-1)}{N} \cdot \frac{M}{\beta}$ | ECMP 碰撞 |
| Dragonfly | Hierarchical AllReduce | $\sim 4\log N \cdot \alpha$ | $\frac{2(N-1)}{N} \cdot \frac{M}{\beta}$ | 全局链路带宽 |
| Hypercube | Recursive Halving-Doubling | $2\log N \cdot \alpha$ | $\frac{2(N-1)}{N} \cdot \frac{M}{\beta}$ | 度数 $O(\log N)$ |
关键观察：
- 带宽项对所有拓扑的最优算法都相同——都达到理论下界。差异在于延迟项和实际可用带宽。
- 大消息（LLM 训练典型场景，$M > 100$ MB）：带宽项主导，Ring AllReduce 在任何拓扑上都接近最优。
- 小消息（inference 场景，$M < 1$ MB）：延迟项主导，Tree AllReduce / Recursive Halving-Doubling 显著优于 Ring（$O(\log N)$ vs $O(N)$ 步）。
AllToAll 效率对比
AllToAll 是 MoE 模型的核心操作。每个节点向所有其他节点发送不同的数据块。
$T_{\text{AllToAll}} \geq (N-1) \cdot \frac{M}{N \cdot \beta_{\text{bisection}}}$
| 拓扑 | 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 退化为串行传输 |
MoE 场景的特殊性：实际 MoE 的 AllToAll 是稀疏的——每个 token 只路由到 top-k experts（如 DeepSeek-V3 的 8/256）。稀疏 AllToAll 的流量比全 AllToAll 小 $\frac{k}{E}$ 倍（$E$ = 总 expert 数），但分布不均匀（热门 expert 接收更多 token），这种不均匀性在 Torus 上尤为致命。
Google 在 TPU v4 上的解决方案：通过 Expert 放置策略将高频通信的 Expert 放在 Torus 上的近邻位置 + OCS 动态调整拓扑（来源：ISCA 2023）。
P2P（Pipeline Parallelism）效率对比
PP 的 P2P 通信只在相邻 pipeline stage 之间发生，对拓扑的需求是低延迟的点对点路径。
| 拓扑 | P2P 效率 | 原因 |
|---|---|---|
| Full Mesh | 最高 | 1 跳直达 |
| Fat-tree | 高 | 2-3 跳（Edge -> Core -> Edge） |
| Dragonfly | 中 | 3-5 跳，取决于 stage 的组分布 |
| Hypercube | 中 | $O(\log N)$ 跳 |
| 3D Torus | 中-低 | $O(N^{1/3})$ 跳，取决于 stage 放置 |
| Ring | 低 | $O(N)$ 跳（最坏情况） |
PP 对拓扑的要求低于 TP 和 EP，因为：P2P 通信量相对较小（仅 activation，非全模型参数）；PP 通常只涉及少量 stage 对；拓扑感知的 stage placement 可将相邻 stage 映射到近邻节点。
综合适配矩阵
评分：1(差) - 5(优)
| 拓扑 | AllReduce(大消息) | AllReduce(小消息) | AllToAll(MoE) | P2P(PP) | 综合 |
|---|---|---|---|---|---|
| Full Mesh (<=72) | 5 | 5 | 5 | 5 | 5.0（仅限节点内） |
| Fat-tree | 4 | 5 | 5 | 4 | 4.5 |
| Hypercube | 4 | 5 | 4 | 3 | 4.0 |
| 3D Torus | 4 | 3 | 2 | 3 | 3.0 |
| Dragonfly | 3 | 3 | 3 | 3 | 3.0 |
| Ring | 3 | 1 | 1 | 1 | 1.5 |
Fat-tree 是唯一在所有通信模式上均表现良好的可扩展拓扑。 这解释了它在商用 AI 集群中的统治地位。
规模扩展特性
各拓扑的规模上限
| 拓扑 | 理论上限 | 实际上限 | 限制因素 |
|---|---|---|---|
| Full Mesh | ~72 (NVL72) | 72 | 端口数/功耗/散热 |
| Ring | 无限 | ~64 | 割集带宽不增长 |
| 3D Torus | ~10,000 | 8,960 (TPU v5p) | 环绕链路长度/OCS 端口数 |
| Fat-tree (3 级) | $k^3/4$ | ~65,536 ($k=64$) | 交换机 radix |
| Fat-tree (5 级) | $>100,000$ | 100,000 (xAI) | 成本/管理复杂度 |
| Dragonfly | $>100,000$ | ~63,744 (Aurora) | 全局链路光缆成本 |
| Hypercube | ~65,536 ($2^{16}$) | 65,536 (CM-2, 1987) | 度数 $O(\log N)$ |
割集带宽随规模变化
| $N$ | Fat-tree | 3D Torus | Dragonfly+ | 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%) |
关键趋势：
- Fat-tree 和 Hypercube 始终保持 100% 割集带宽，但 Hypercube 度数 $\log_2 65536 = 16$
- 3D Torus 的割集带宽/Fat-tree 比例从 100% ($N=64$) 快速下降到 10% ($N=65K$)
- Dragonfly+ 稳定在 ~70%，是大规模场景的性价比拐点
增量扩展能力
| 拓扑 | 增量扩展 | 说明 |
|---|---|---|
| Fat-tree | 好 | 在同一层级内添加 Pod，或增加层级 |
| Ring | 好 | 在环中插入新节点 |
| Torus | 差 | 改变维度大小需要重新布线 |
| Dragonfly | 中 | 可添加新 Group，但可能需要重配全局链路 |
| Hypercube | 极差 | $N$ 必须是 2 的幂，扩展意味着维度加 1，布线全变 |
| Jellyfish | 好 | 随机插入新交换机即可 |
Fat-tree 的增量扩展能力是其在数据中心广泛采用的重要原因——可以从小规模开始，按需扩展。
成本模型
网络组件成本参考
2024 年行业公开报价汇总：
交换机（$/port）：
| 类型 | 端口速率 | $/port（估计） |
|---|---|---|
| InfiniBand NDR | 400Gbps | $940 - 1,170 |
| InfiniBand XDR | 800Gbps | $1,200 - 1,500 |
| 以太网 (Broadcom Memory) | 400GbE | $625 - 860 |
| 以太网 (Broadcom Jericho3-AI) | 800GbE | $800 - 1,100 |
线缆/光模块（$/port-pair）：
| 类型 | 速率 | 距离 | $/pair（估计） |
|---|---|---|---|
| DAC (Direct Attach Copper) | 400G | <=3m | $50 - 100 |
| AEC (Active Electrical Cable) | 400G | 3-7m | $100 - 200 |
| AOC (Active Optical Cable) | 400G | 7-100m | $300 - 600 |
| 光模块 + 光纤 | 400G | >100m | $600 - 1,200 |
| 光模块 + 光纤 | 800G | >100m | $1,000 - 2,000 |
来源：行业公开报价汇总，2024
各拓扑的成本结构
以 $N = 1024$ 节点、$k = 16$ 端口交换机（3级 Fat-tree 中 $N = k^3/4 = 1024$ 要求 $k = 16$）、400G 链路为例：
Fat-tree (3 级)：
| 组件 | 数量 | 单价 | 小计 |
|---|---|---|---|
| Edge 交换机 | 128（= $k \times k/2 = 16 \times 8$） | $16 \times \$1,000 = $16K$ | $\$2.05M$ |
| Aggregation 交换机 | 128 | $\$16K$ | $\$2.05M$ |
| Core 交换机 | 64（= $(k/2)^2 = 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 |
3D Torus（直连）：
| 组件 | 数量 | 单价 | 小计 |
|---|---|---|---|
| 交换机 | 0 | - | $\$0$ |
| 链路（6 per node） | 3,072 | $\$200$（平均，含短距铜缆和长距光缆） | $\$614K$ |
| ICI 端口（芯片集成） | 6,144 | 含在芯片成本中 | $\$0$（边际） |
| 合计 | ~$0.6M |
归一化成本对比
| 拓扑 | 网络成本 / Fat-tree | 割集带宽 / Fat-tree | 性价比 (BW/$) |
|---|---|---|---|
| Fat-tree | 1.0x | 1.0x | 1.0x |
| 3D Torus | ~0.08x | ~0.40x | 5.0x |
| Dragonfly | ~1.4x | ~0.70x | 0.5x |
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% | 无交换机，ICI 集成在芯片中 |
路由策略对比
路由算法分类
| 算法 | 类型 | 适用拓扑 | 核心机制 |
|---|---|---|---|
| ECMP | 静态多路径 | Fat-tree | 5-tuple 哈希选择等价路径 |
| DOR | 确定性 | Torus/Mesh | 按固定维度顺序路由 |
| UGAL | 自适应 | Dragonfly | 动态选择 Minimal/Valiant |
| SHARP | 网内计算 | Fat-tree (IB) | 交换机执行 Reduce 操作 |
| E-cube | 确定性 | Hypercube | 按 XOR 位序修正 |
| Valiant | 随机化 | 通用 | 先到随机中间节点再到目标 |
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 仍受碰撞影响。
解决方案：
- Packet spraying：每个包独立选路径（而非每条流），但需要接收端重排序
- Flowlet-based：检测流内的间隔，在间隔处切换路径
- 集中式调度 (Hedera)：SDN 控制器监控链路利用率，动态迁移大象流
UGAL 在 Dragonfly 上的必要性
UGAL 的 Minimal vs Valiant 选择本质上是延迟 vs 负载均衡的权衡：
| 流量模式 | Minimal 吞吐 | Valiant 吞吐 | UGAL 吞吐 |
|---|---|---|---|
| 均匀随机 | 100% | 50% | ~95% |
| 邻组通信 | ~30% | 50% | ~80% |
| 对抗性 | ~10% | 50% | ~70% |
没有 UGAL 的 Dragonfly 在对抗性流量下几乎不可用（10% 吞吐）。
SHARP 的影响
| 指标 | 无 SHARP | 有 SHARP | 改善 |
|---|---|---|---|
| AllReduce 延迟 | $2\log N \cdot \alpha$ | $\log N \cdot \alpha$ | 2x |
| 网络传输字节 | $2 \cdot \frac{N-1}{N} \cdot M$ | $\frac{N-1}{N} \cdot M$ | 2x |
| 有效 AllReduce 带宽 | 基准 | +30-50% | - |
SHARP 仅适用于 InfiniBand Quantum 交换机，是 NVIDIA IB 生态的核心竞争力。以太网阵营无等价物。
死锁避免对比
| 拓扑 | 死锁风险 | 避免机制 |
|---|---|---|
| Fat-tree | 无（上行-下行无环） | 天然无需 |
| Mesh | 无（DOR 天然无环） | 天然无需 |
| Torus | 有（环绕链路成环） | 虚通道 (VC) + dateline |
| Dragonfly (Minimal) | 无（local-global-local 不回头） | 天然无需 |
| Dragonfly (UGAL) | 有（非最短路径成环） | 2-3 个 VC |
| Hypercube | 无（E-cube 按维度递增） | 天然无需 |
Fat-tree 和 Mesh 的天然无死锁特性降低了硬件复杂度和验证成本。
故障容忍
链路故障影响
| 拓扑 | 单链路故障影响 | 多链路容忍度 | 说明 |
|---|---|---|---|
| Full Mesh | 极小（$\frac{1}{N-1}$ 带宽损失） | $N-2$ 条 | $(N-1)$-connected |
| Ring | 严重（割集带宽减半 -> $b$） | 0 条（断开即分裂） | 最脆弱 |
| 3D Torus | 中（一个维度带宽降级） | $2n-1$ 条 | $2n$-connected |
| Fat-tree | 小（ECMP 自动绕路） | 多条（$k/2$ 冗余路径） | 高冗余 |
| Dragonfly | 中（全局链路故障影响组间通信） | 取决于组间冗余度 | 全局链路是单点 |
| Hypercube | 小（$\log N$ 条替代路径） | $n-1$ 条 | $n$-connected |
交换机故障影响
| 拓扑 | 单交换机故障影响 |
|---|---|
| Fat-tree (Edge) | 该 ToR 下所有节点断网 |
| Fat-tree (Core) | 割集带宽降低 $\frac{1}{k/2}$，ECMP 自动绕路 |
| Torus | 无交换机可故障（直连网络） |
| Dragonfly | 组内路由器故障：该路由器下所有终端断网 + 部分全局链路丢失 |
Fat-tree 的 Core 交换机冗余是其故障容忍的核心优势——$(k/2)^2$ 个 Core 交换机中任一个故障仅导致 $\frac{2}{k}$ 的割集带宽降级，且 ECMP 无感知切换到其他路径。
故障恢复时间
| 拓扑 | 故障检测 | 路由收敛 | 总恢复时间 |
|---|---|---|---|
| Fat-tree (ECMP) | ms 级 | 秒级（BFD + ECMP 更新） | 1-10s |
| Fat-tree (SHARP) | ms 级 | 需要重建 SHARP tree | 10-30s |
| Torus (DOR) | ms 级 | 需要全局路由重算 | 10s-min |
| Dragonfly (UGAL) | ms 级 | 自适应路由自动绕路 | ms-s 级 |
Dragonfly 的 UGAL 在故障容忍上有独特优势：自适应路由会自动感知故障链路的队列堆积，将流量切换到 Valiant 路径，无需等待路由协议收敛。
综合评估矩阵
| 维度 | Fat-tree | 3D Torus | Dragonfly | Hypercube |
|---|---|---|---|---|
| AllReduce 效率 | 高 | 高 | 中 | 高 |
| AllToAll 效率 | 最高 | 低 | 中 | 高 |
| P2P 效率 | 高 | 中 | 中 | 中 |
| 规模上限 | 100K+ | ~10K | 100K+ | ~65K |
| 增量扩展 | 好 | 差 | 中 | 差 |
| 网络成本 | 高 | 最低 | 中 | 中 |
| 故障容忍 | 最高 | 中 | 中 | 高 |
| 路由复杂度 | 低 (ECMP) | 低 (DOR) | 高 (UGAL) | 低 (E-cube) |
| 死锁风险 | 无 | 有 | 有 (UGAL) | 无 |
| 商业生态 | 最成熟 | Google only | HPE only | 几乎无 |
最终结论：
-
通用 AI 训练集群：Fat-tree 是唯一在所有维度上均无明显短板的选择。MoE 模型的流行进一步巩固了 Fat-tree 的地位（AllToAll 需要全割集带宽）。
-
超大规模低成本集群：3D Torus 在自研芯片生态中（Google TPU）是最优选择，成本为 Fat-tree 的 <10%。但前提是可以接受 AllToAll 效率低。
-
HPC 超算：Dragonfly 在 HPE Cray 生态中是唯一选择，UGAL 路由是其可用性的前提。
-
未来方向：OCS 动态拓扑（Google Orbiter）可能改变拓扑选型的逻辑——从"选一个固定拓扑"变为"按工作负载动态生成拓扑"。
参考文献
| 论文/资料 | 来源 | 核心贡献 |
|---|---|---|
| Thakur et al., "MPI Collective Optimization" | IEEE TPDS 2005 | AllReduce 带宽下界 |
| Kim et al., "Dragonfly Topology" | ISCA 2008 | UGAL 路由在各流量模式下的吞吐数据 |
| Al-Fares et al., "Hedera" | NSDI 2010 | Fat-tree 自适应流调度 |
| NVIDIA SHARP | NVIDIA | 网内计算实测效果 |
| Jouppi et al., "TPU v4" | ISCA 2023 | Torus AllToAll 瓶颈与 OCS 解决方案 |
| Meta "RoCE at Scale" | SIGCOMM 2024 | RoCE vs IB 工程权衡 |