拓扑设计：常见AI集群拓扑的原理与优缺点

AI训练集群的规模决定了其网络拓扑的基本形态。当集群从几十卡扩展到上千卡甚至万卡时，网络拓扑的选择直接决定了通信效率、成本上限和故障恢复能力。本章聚焦三种在AI集群中最为常见的拓扑结构：Fat-Tree（胖树）、Torus（环面/网格）和Dragonfly（蜻蜓），从原理出发，分析各自的适用场景与工程代价。

4.1 Fat-Tree：以交换层级换取无阻塞带宽

Fat-Tree 是一种基于 Clos 网络架构的树形拓扑，其核心思想是：越靠近根部的链路带宽越“粗”，从而保证任意两个叶子节点之间都能获得完整的对分带宽（Bisection Bandwidth）。在 AI 集群中，Fat-Tree 通常以三层结构实现：

叶层（Leaf）：直接连接计算节点（GPU 服务器），通常为 40G/100G 端口。
脊层（Spine）：负责连接所有叶交换机，不直接连接计算节点。
核心层（Core）：在超大规模集群中，脊层之上再增加一层核心交换机，用于跨 Pod 互联。

以最常见的 2 层 Fat-Tree（叶-脊）为例，若每台叶交换机有 k 个上行端口，则最多可连接 k 台脊交换机，整个网络可容纳 k²/2 台叶交换机，且任意两台叶交换机之间的路径数等于 k，所有路径等价，可通过 ECMP（等价多路径）实现负载均衡。

// 典型 Fat-Tree 参数示例（k=64）
叶交换机数量：64 台
脊交换机数量：64 台
可接入计算节点：64 × 32 = 2048 个（假设每叶下行 32 端口）
对分带宽：64 × 100Gbps = 6.4Tbps（无阻塞）

  工程要点：Fat-Tree 的“无阻塞”是有条件的——只有当所有上行链路都被充分利用且流量均匀分布时，才能达到理论对分带宽。实际训练中，All-to-All 通信模式（如数据并行中的梯度同步）容易造成流量热点，因此需要配合自适应路由或流控机制。

4.1.1 优点与局限

维度	评价
带宽保证	任意节点间路径等价，对分带宽可预测，适合同步训练
容错性	多路径冗余，单链路故障可通过 ECMP 快速切换
成本	需要大量高速交换机，端口利用率约 50%（上行:下行=1:1），成本较高
扩展性	增加一层核心可扩展规模，但延迟随之增加

Fat-Tree 适合对带宽敏感、通信模式相对均匀的同步训练场景，例如基于 All-Reduce 的数据并行。但它的成本随规模呈平方级增长，在万卡以上集群中，交换机和光模块的投入会占据总成本的 30% 以上。

4.2 Torus：以低维度直连换取低成本扩展

Torus 拓扑将计算节点组织成多维网格，每个节点仅与相邻节点直连，并在维度边界处回环连接（即“环面”）。常见的 AI 集群采用 2D-Torus 或 3D-Torus。以 3D-Torus 为例，每个节点连接 6 个邻居（X、Y、Z 轴正负方向），节点间通信通过逐跳转发完成。

// 3D-Torus 规模示例（每维 8 节点）
总节点数：8 × 8 × 8 = 512
每节点端口数：6（3 维 × 2 方向）
最大跳数：3 × (8/2) = 12 跳
对分带宽：约 512 × 链路带宽 / 4（受维度切割限制）

Torus 的核心优势在于极低的端口成本——不需要大量交换机，节点本身承担转发功能。这在 Google 的 TPU Pod 和部分国产 AI 芯片集群中得到应用。但代价是：

跳数不可控：远距离通信需要多跳转发，延迟随规模线性增长。
带宽非均匀：相邻节点带宽高，远端节点带宽低，对通信模式敏感。
故障影响面大：单节点故障可能导致局部路由绕行，甚至形成“空洞”。

典型误区：认为 Torus 的“低端口数”等于“低成本”。实际上，虽然交换机数量减少，但节点侧需要额外的网络接口（如 6 端口），且需要复杂的路由算法（如维度顺序路由、奇偶转向）来避免死锁。在 100G 以上速率下，节点侧光模块的成本可能抵消交换机节省的费用。

4.3 Dragonfly：面向超大规模的分层聚合拓扑

Dragonfly 拓扑专为超大规模（万卡以上）设计，其核心思想是分层聚合：将节点划分为多个“组”（Group），组内采用全连接或高基数连接，组间通过少量“干线”连接。每个组内部带宽充足，组间带宽相对有限，但通过精心设计的路由算法，使得平均跳数保持在 2-3 跳以内。

一个典型的 Dragonfly 拓扑参数如下：

// Dragonfly 参数示例
组内节点数：p = 16
每组干线端口数：h = 8
组数：g = 16
总节点数：p × g = 256
任意节点间最大跳数：3（源组内 1 跳 + 组间 1 跳 + 目的组内 1 跳）

Dragonfly 的关键优势在于极低的网络直径——无论集群规模多大，任意节点间的跳数不超过 3 跳（在理想路由下）。这使得它非常适合对延迟敏感的通信模式，如 Transformer 模型中的 Layer-wise 同步。同时，由于组间链路数量远小于组内链路，整体线缆成本显著低于 Fat-Tree。

4.3.1 路由与负载均衡的挑战

Dragonfly 的难点在于路由策略。由于组间链路是稀缺资源，如果多个流同时选择同一条干线，就会造成拥塞。常见的解决方案包括：

自适应路由：根据当前链路负载动态选择下一跳，避免热点。
Valiant 路由：随机选择一个中间组转发，将流量打散到全网。
显式拥塞控制：通过 ECN（显式拥塞通知）或 PFC（优先级流控）反馈调整发送速率。

  工程实践：在 NVIDIA 的 DGX SuperPOD 中，实际采用的是类似 Dragonfly 的“Rail-Optimized”拓扑——将同一 GPU 索引的节点组织成“Rail”，每个 Rail 内部全连接，Rail 之间通过脊层互联。这种设计兼顾了局部带宽和全局扩展性，是 Dragonfly 思想在商用集群中的变体。

4.4 三种拓扑的对比与选型

维度	Fat-Tree	Torus	Dragonfly
典型规模	数百 ~ 数千节点	数百 ~ 数千节点	数千 ~ 数万节点
最大跳数	2 ~ 4 跳	随维度增长（如 3D-Torus 为 3×d/2）	≤ 3 跳
对分带宽	高（可设计为无阻塞）	低（受维度切割限制）	中（组间带宽受限）
成本	高（交换机数量多）	低（节点直连）	中（组间干线少）
路由复杂度	低（ECMP 即可）	中（需防死锁）	高（需自适应/Valiant）
故障恢复	好（多路径冗余）	差（局部故障影响路由）	中（需快速重路由）

选型建议：

若集群规模在 2000 卡以内，且追求稳定的训练性能，Fat-Tree 是最稳妥的选择。
若成本敏感且通信模式以邻近通信为主（如卷积模型），可考虑 Torus，但需接受带宽不均。
若规模超过 5000 卡，且对延迟有严格要求，Dragonfly 或其变体是更优解，但需要成熟的软件栈支持。

4.5 常见误区与复盘

误区一：追求“无阻塞”就选 Fat-Tree。
实际上，无阻塞的前提是流量均匀。在 MoE（混合专家）模型中，不同专家节点的流量差异可达 10 倍以上，此时 Fat-Tree 的 ECMP 可能因哈希不均导致局部拥塞，性能反而不如自适应路由的 Dragonfly。

误区二：Torus 的跳数少就代表延迟低。
跳数少不等于延迟低。每跳的转发延迟（约 100-200ns）加上排队延迟，在拥塞时可能远高于 Fat-Tree 的 2 跳但无拥塞的路径。Torus 更适合“尽力而为”的通信，而非延迟敏感型同步。

误区三：忽略拓扑与集合通信库的适配。
即使选择了合适的拓扑，如果 NCCL/RCCL 等集合通信库不支持该拓扑的优化路由（如 Ring 算法在 Torus 上的维度顺序），实际带宽利用率可能不足 50%。选型时必须同步评估软件栈的成熟度。

在实际工程中，没有“最好”的拓扑，只有“最匹配”的拓扑。建议在选型前，先用小规模集群（如 32-64 卡）模拟目标模型的通信模式，测量实际带宽和延迟，再决定是否投入大规模建设。同时，预留 10%-20% 的端口余量用于故障替换和未来扩展，避免因单点故障导致整个训练任务中断。