互连拓扑设计：Fat-tree、Torus 与 Dragonfly

当集群从几百个节点扩展到几万个节点，网络不再只是「把机器连起来」的管道，而成为决定系统性能上限与造价的结构。同一批网卡和交换机，用不同的拓扑组织起来，对分带宽、直径、成本可以差好几倍。TOP500 前列的机器几乎都在 Fat-tree、Torus、Dragonfly 三者中做选择——它们的取舍反映了「带宽、延迟、成本、可扩展性」四个维度上的不同权衡。本文讲清这三类拓扑的结构与适用场景，以及拓扑如何影响上层通信与作业调度。物理链路层的 InfiniBand 与 RDMA 机制见 InfiniBand 与 RDMA 。

互连的性能维度

评价一个互连拓扑，先约定几个量：

对分带宽是最关键的量：它决定「一半节点与另一半节点同时通信」时的总吞吐，也就是多数集合通信（allreduce、alltoall）的天花板。理想网络要求对分带宽随节点数线性增长（无阻塞），但代价是成本急剧上升。

延迟与带宽要分开看。小消息通信（如 halo 交换的边界行）受延迟主导，此时直径与跳数比链路带宽更重要；大消息通信（如 allreduce 的大缓冲）受带宽主导，对分带宽才是瓶颈。同一个拓扑对两类通信的「友好度」可能完全不同，因此不能只看单一指标选型。

对分带宽比 = 实际对分带宽 / 理想对分带宽（= 节点数 × 单节点带宽 / 2）
无阻塞网络：比值 = 1
超订网络：  比值 < 1，如 1:3、1:5

Fat-tree

结构

Fat-tree（胖树）是最常见的分层树形拓扑。经典的三层结构由三类交换机组成：

              Core 层（核心交换机，全互联）
             /            |            \
        Agg 层        Agg 层        Agg 层
        /    \        /    \        /    \
     Edge   Edge   Edge   Edge   Edge   Edge
      |      |      |      |      |      |
    节点   节点   节点   节点   节点   节点

用 k 端口交换机搭建的 k-ary fat-tree：k³/4 个节点，核心层 (k/2)² 台交换机，任意两台主机间最多 3 跳。它的关键性质是可构造为无阻塞：只要核心层交换机数量足够，边缘上行带宽与下行带宽相等，对分带宽等于节点总带宽的一半。

无阻塞与超订

全无阻塞 fat-tree 成本高（核心层交换机数量随规模平方增长）。实践中常用超订（oversubscription） 降低核心层规模：

1:1   无阻塞：每 1 条下行对应 1 条上行（成本最高）
1:3   轻度超订：常见于通用集群
1:5+  重度超订：预算受限、通信稀疏的场景

超订的代价是对分带宽下降：当一半节点同时与另一半通信，上行链路成为瓶颈，集合通信性能显著劣化。选超订比要看应用通信模式——通信密集的 CFD/气象作业宜低超订，I/O 密集或弱耦合作业可接受高超订。

k-ary fat-tree 的规模公式

用 k 端口交换机搭建经典三层 fat-tree，各层数量与可容纳节点数有闭式关系：

举例，用 64 端口交换机（k=64）：可容纳 64³/4 = 65536 个节点，核心层 32² = 1024 台交换机。可见规模扩大时核心交换机数量以平方增长，这正是全无阻塞 fat-tree 昂贵的原因。用 128 端口交换机（k=128）则能容纳 128³/4 ≈ 52 万 节点，但核心层达 4096 台。

现代数据中心常见的叶脊结构（Spine-Leaf） 是两层 fat-tree：Leaf 交换机连节点并上行到 Spine，Spine 全互联。它牺牲了「任意两节点 ≤3 跳」的严格保证（叶脊通常 2~4 跳），换来实现简单与横向扩展便利，是通用云集群的主流。

Torus

结构

Torus（环面）把节点组织成 N 维网格，每一维首尾相连成环。3D torus 中每个节点有 6 个邻居（±x, ±y, ±z）；Cray 的机器常用 3D 甚至 5D torus。

2D Torus (4x4)：
  A - B - C - D
  |   |   |   |
  E - F - G - H
  |   |   |   |
  I - J - K - L
  |   |   |   |
  M - N - O - P
  （D 连 A，P 连 M，构成环绕）

Torus 的最大特点是用直连链路代替交换机：每个节点既是计算单元又是路由器，省掉了大量交换机与线缆，成本远低于同规模 fat-tree。代价是直径大（随维度边长增长）且布线复杂（3D/5D 的物理布线是工程难题）。

维度路由

Torus 用维度顺序路由（Dimension-Order Routing, DOR）：按维度顺序逐维调整坐标，先走 x 维到目标 x，再走 y 维。这种路由简单、无死锁，但路径固定，遇到拥塞无法绕行。

Cray 的 Slingshot 与早期的 Aries/Gemini 都基于 torus，并支持自适应路由：在 DOR 基础上允许多条等长或非最短路径，动态避开拥塞链路，代价是需要虚通道（Virtual Channel）保证无死锁。

Torus 的优势依赖通信局部性：若应用主要在邻居间通信（如 stencil 的 halo 交换），torus 的短路径正好命中；若应用频繁全局通信（如 alltoall），torus 的大直径会成为瓶颈。这也是为何 torus 机器上要配合拓扑感知的进程映射。

维度数与直径的权衡

维度数越高，每维边长越短，直径越小，但每节点需要的端口越多：

提高维度能在大规模下压低直径，但端口数（= 2×维度数）限制了单个节点的布线复杂度。Cray 的机器从 3D torus（Gemini/Aries）演进到 Slingshot 的 高基数 torus，本质是在维度与基数之间重新平衡。高维 torus 的另一个好处是容错：单条链路故障时，可沿其他维度绕行，只要拓扑不连通性受损。

Dragonfly

结构

Dragonfly 是分层的高基数（high-radix）拓扑，用「组（group）」组织节点：

每个 group 内：全互联（all-to-all），含若干交换机与节点
group 之间：每个交换机连出若干全局链路（global link）到其他 group

用 a 个交换机、每交换机 p 个端口、h 条全局链路、g 个组，可容纳约 a·(p-h)·g 个节点。Dragonfly 的核心优势是极小的相对直径：任意两节点最多 3 跳（组内 1 跳、跨组 2~3 跳），而 torus 的直径随规模线性增长。

Dragonfly 相对直径：组内 ≤1 跳，组间 ≤3 跳（恒定，不随规模增长）

这让 Dragonfly 在数万节点规模下仍保持低延迟，同时用较少的全局链路控制成本——全局链路数与组数成正比而非平方。

拥塞与 Dragonfly+

Dragonfly 的隐患是全局链路拥塞：跨组流量若集中在少数全局链路上，会形成热点。经典场景是 alltoall——所有组两两通信，全局链路成为瓶颈。缓解手段：

• 自适应路由：在多个全局链路间动态分配流量。
• Dragonfly+：增加一层「组间直连」，减少跨组跳数，提升对分带宽。
• 拓扑感知放置：把通信密集的作业放在同组内，减少跨组流量。

Dragonfly 的组内全互联特性带来一个额外好处：同组内的通信延迟极低且无拥塞，因此调度器应尽量把通信最密集的进程对放进同一组。这也解释了为什么 dragonfly 机器上「作业放置」对性能的影响远大于 fat-tree——放置决定了多少流量必须走稀缺的全局链路。

路由与无死锁

拓扑只是骨架，路由算法决定数据怎么走。核心约束是无死锁。

确定性与自适应

确定性路由：路径唯一（如 fat-tree 的 ECMP、torus 的 DOR）
自适应路由：多条候选路径，按拥塞动态选择

自适应路由提升吞吐与容错（链路故障可绕行），但需要虚通道（Virtual Channel, VC） 打破环路依赖，否则可能死锁。

死锁与虚通道

在环状/网状拓扑中，若允许多个维度任意顺序转向，可能形成循环等待。DOR 通过「固定维度顺序」消除环，但牺牲了灵活性。自适应路由用 VC 分层：

VC0 走「低维 → 高维」的转向，VC1 走反向
同一 VC 内禁止形成环，跨 VC 的依赖单向，故无死锁

这是 torus 与 dragonfly 支持自适应路由的基础机制。理解它对调试「偶发通信挂起」很有帮助——某些挂起正是路由依赖与虚通道分配不当导致的。

值得注意的是，虚通道数量有限：每条物理链路的 VC 数目固定（如 4~8 个），当并发流量超过 VC 容量时会排队。这也是为什么「增加并发消息数」不一定提升性能——超过 VC 承载能力后，排队延迟反而上升。调优通信并发度时，应结合链路 VC 配置一起考虑。

拥塞控制

拓扑定了路由，但流量控制决定拥塞时谁先让步。InfiniBand 用基于信用的链路级流控（防止丢包）加上拥塞控制（Congestion Control）：

FECN（Forward Explicit Congestion Notification）：交换机标记拥塞包
BECN（Backward ECN）：接收端回传拥塞通知给发送端
DCQCN：基于 ECN 的速率自适应，动态调整发送速率

在 fat-tree 上，拥塞常出现在核心层上行链路；在 dragonfly 上，拥塞集中在全局链路。自适应路由 + 拥塞控制组合能显著改善热点表现，但调优参数（阈值、速率恢复曲线）依赖具体硬件与流量，需要实测标定。

拓扑故障与降级

拓扑的容错能力决定单点故障的影响范围。

Fat-tree：单链路/单交换机故障，ECMP 自动切换到其他等价路径，影响局部
Torus：单链路故障，可沿其他维度绕行，但需路由支持（否则可能不连通）
Dragonfly：单条全局链路故障，可能使某对组间的带宽减半，需备用路径

关键问题是拓扑是否仍连通以及对分带宽下降多少。设计时应预留冗余链路（如 dragonfly 每对组间多条全局链路），并在监控中跟踪「可用链路数 / 标称链路数」。链路降级往往先表现为某些通信模式的性能下滑，而非直接报错——这类「软故障」需要时间线工具配合拓扑信息才能定位。

拓扑感知的调度与通信优化

拓扑只有配合上层才能发挥价值。

作业放置（Topology-Aware Placement）

调度器应尽量把同一作业的进程放在网络邻近的节点上：

# Slurm 拓扑感知调度：按 switch/tree 层级紧凑分配
sbatch --distribution=block:block --switches=1 job.sh

--switches=1 要求作业落在单台交换机下，最小化跨交换机流量。对 Dragonfly，调度器应优先把作业放进单个 group；对 torus，应按维度顺序分配连续坐标。

进程映射（Rank Mapping）

即使节点分配合理，rank 的物理位置也影响通信效率。MPI 提供多种映射策略：

# 按 socket/node 循环绑定，匹配应用的通信模式
mpirun -np 1024 --map-by ppr:4:node --bind-to core ./sim

# 用主机文件指定拓扑
mpirun --hostfile hosts_topo.txt --map-by node ./sim

对 stencil 应用，让逻辑邻居 rank 映射到物理邻居节点，能让 halo 交换走最短路径；对 alltoall 密集的应用，则希望 rank 均匀分布在组间以平衡全局链路。

集合通信的拓扑适配

集合通信算法应感知拓扑：fat-tree 上的 allreduce 用递归倍增（recursive doubling）利用树结构；dragonfly 上的 allreduce 需分层（组内 reduce，组间 reduce，组内 broadcast）以减少跨组流量。NCCL 与 MPI 库都在做这类适配，NCCL 集合通信 中的 ring/tree 算法选择正是拓扑感知的体现。

光互连与共封装光学

规模扩大后，铜缆的传输距离与功耗成为瓶颈。超过数米的链路必须用光模块，而光模块的功耗与成本随端口数线性增长——在数万节点的系统里，光模块可能占网络总功耗的相当比例。

共封装光学（Co-Packaged Optics, CPO） 把光引擎与交换芯片封装在一起，缩短电信号路径，降低功耗与延迟：

传统：交换芯片 → 电信号走 PCB → 可插拔光模块 → 光纤
CPO：  交换芯片 → 硅光引擎（同一封装内）→ 光纤

CPO 让交换机能提供更高的端口密度与更低的每比特功耗，是支撑下一代十万级节点互连的关键技术。对拓扑设计的影响是：交换机基数继续提高，使得高基数拓扑（Dragonfly、高基数 torus）更具吸引力，因为每端口成本下降后，用更多端口换取更小直径变得更划算。

除了 CPO，光电路交换（Optical Circuit Switching, OCS）也在超算中崭露头角：用可重构的光开关按需建立大带宽直连通道，为集合通信提供「专线」。它的挑战是切换延迟（毫秒级），因此只适合持续时间长的大流量，而小消息仍走电交换。

网络仿真与拓扑评估

在真机上验证拓扑设计代价高昂，实践中先用仿真器评估。常用工具：

仿真的输入是流量模式（traffic pattern）：均匀随机、最近邻、热点、alltoall 等。拓扑的性能高度依赖流量模式——同一天拓扑，均匀随机流量下的表现与最近邻流量下可能截然不同。因此评估必须用应用的实测通信模式，而非默认的均匀流量。

评估流程：
1. 用工具（如 MPI 追踪）采集应用通信矩阵
2. 把矩阵喂给仿真器，跑目标拓扑
3. 对比对分带宽利用率、平均延迟、拥塞热点
4. 调整拓扑参数（维度、超订比、全局链路数）迭代

选型对比

选型的经验法则：

1. 通信模式决定一切：局部通信（stencil）→ torus；全局通信（alltoall）→ fat-tree；折中 → dragonfly。
2. 预算约束下的扩展性：想扩展到数万节点又控制成本，dragonfly 是主流选择。
3. 延迟敏感：直径小的 fat-tree 与 dragonfly 优于 torus。
4. 运维复杂度：fat-tree 最易管理，torus 布线最难，dragonfly 的拥塞调优需要经验。

集群层面的拓扑管理、交换机监控与故障排查，属于 HPC 集群运维 的日常职责；而作业如何被放到拓扑的哪个位置，则由 Slurm 集群调度 的放置策略决定。

一个常被忽视的事实是：拓扑的性能只有在上层配合时才能兑现。同一台 dragonfly 机器，若调度器把 alltoall 密集的作业打散到所有组，跨组全局链路必然拥塞；若把作业收拢到少数组内，性能可提升数倍。硬件拓扑与软件放置是硬币的两面，任何一面的短板都会让另一面的投入白费。

小结

互连拓扑是「性能、成本、可扩展性」三角上的选择。Fat-tree 用交换机换取低直径与可配置的对分带宽，成本最高；Torus 用直连链路换取低成本，代价是直径大、依赖通信局部性；Dragonfly 用高基数与分组换取大规模下的低直径与可控成本，隐患是全局链路拥塞。理解对分带宽、直径、超订比与无死锁路由，你就能判断一个应用在给定拓扑上是「顺风」还是「逆风」，并通过拓扑感知的放置与映射把硬件潜力榨出来。