11.4 集群组网

在前几节中，我们讨论了单节点内 GPU 之间的高速互连（NVLink、NVSwitch）。然而，当训练规模从 8 卡扩展到数千甚至数万卡时，节点间的网络互连便成为整个系统的性能瓶颈。集群组网需要回答三个核心问题：用什么拓扑把节点连起来（网络拓扑）、用什么技术让数据高速搬运（RDMA 与无损网络）、以及如何在拥塞时保持高效（拥塞控制与负载均衡）。本节将依次展开这三大主题。

11.4.1 网络拓扑：从传统树到胖树与 Leaf-Spine

为什么 AI 集群需要专用网络拓扑？ 传统数据中心主要处理南北向流量（客户端与服务器之间），而 AI 分布式训练产生的是大规模的东西向流量（服务器之间）。以 All-Reduce 为例，数百个 GPU 需要在极短时间内同步梯度，任何一条链路的带宽瓶颈都会拖慢整体训练速度。因此，AI 集群的网络设计核心目标是高带宽、低延迟、无阻塞。

先回顾几种基础网络拓扑。星型拓扑将所有设备连到一个中心节点，简单但中心节点容易成为瓶颈；环形拓扑结构简单、布线成本低，但延迟随节点数线性增长；树形拓扑分层组织、易于扩展，但越靠近根节点的交换机流量越集中，根节点成为带宽瓶颈——这对 All-to-All 通信模式是致命的。

常见网络拓扑类型

胖树拓扑（Fat-Tree）。 为了解决传统树形拓扑的根节点瓶颈，Charles Leiserson 于 1985 年提出了胖树结构。其核心设计原则是保持从叶子到根的带宽不变——越到树根，枝干越"粗"。具体做法是在上层交换机之间使用更多的链路聚合，使得任意两个叶子节点之间的通信都能获得相同的二分带宽（Bisection Bandwidth）。胖树是现代 AI 数据中心最主流的拓扑方案之一。

Clos 网络。 Clos 网络是胖树的更一般化形式，由 Charles Clos 于 1953 年为电话交换系统提出。其核心思想是用大量低成本、小端口数的交换机，通过多级互连构建出大规模无阻塞网络（Non-blocking Network）。一个典型的三级 Clos 网络包含三层交换机：

第一级（Ingress）：接入层，连接服务器
第二级（Middle）：中间层，提供跨组连接
第三级（Egress）：出口层，连接目标服务器

只要中间级的交换机数量足够多，任意输入到任意输出都能找到不冲突的路径，从而实现无阻塞通信。Clos 网络的数学优雅之处在于：若每个 Ingress/Egress 交换机有 $n$ 个输入/输出端口和 $m$ 条到中间级的上行链路，则当 $m \geq 2 n - 1$ 时，网络是严格无阻塞的——任何新连接都无需重排已有连接即可建立。实际部署中常取 $m = n$ ，构成"可重排无阻塞"网络，配合动态路由即可满足 AI 集群需求。

Leaf-Spine 架构。 现代数据中心最常用的组网方式是两层 Clos 网络的工程实现——Leaf-Spine 架构。在这种架构中：

Leaf 交换机（叶交换机）：直接连接服务器，每台 Leaf 与所有 Spine 交换机都有连接
Spine 交换机（脊交换机）：作为骨干层，只与 Leaf 交换机互连，不直接连接服务器

这种"每个 Leaf 连所有 Spine"的全互连设计，保证了任意两台服务器之间的通信最多经过两跳（Leaf → Spine → Leaf），路径长度一致、延迟可预测。当需要进一步扩大规模时，可以在 Spine 之上再增加一层 Super-Spine，形成三级 Clos 网络。

举个具体例子：假设使用 64 端口的交换机，每台 Leaf 交换机用 32 个端口连接服务器、32 个端口上连 Spine。那么一个两层 Leaf-Spine 可以支持 32（Spine 数量）× 32（每台 Leaf 的下行端口）= 1024 台服务器。若每台服务器有 8 个 GPU，则可支撑 8192 个 GPU 的集群。如果再加一层 Super-Spine，规模可进一步扩展到数万节点。

GPU 集群的分层互连。 在实际的 AI 集群中，网络呈现明显的层次结构：

层级	互连技术	典型带宽	通信范围
GPU 间（节点内）	NVLink / NVSwitch	450-900 GB/s	同一服务器的 8 路 GPU
节点间（机架内）	InfiniBand / RoCE	100-400 Gb/s	同一 Leaf 下的服务器
机架间（集群内）	InfiniBand / RoCE	100-400 Gb/s	经 Spine 交换机跨机架

张量并行因通信频率极高，通常部署在节点内的 NVLink 上；流水线并行和数据并行的通信量相对较低，适合部署在节点间的 InfiniBand 或 RoCE 网络上。这种将并行策略与网络层次对齐的设计，是大规模训练系统性能优化的关键。

其他拓扑方案。 除了胖树/Clos 之外，业界还在探索其他拓扑结构：

环面拓扑（Torus）：Google TPU 采用的方案，将 TPU 芯片排列成 2D/3D 网格并首尾相连形成环面。每个节点只与直接邻居通信，不依赖中心交换机，扩展性极强。这种结构非常适合 Ring All-Reduce 等集体通信操作，但非邻居间的数据传输需要多跳中继，不适合任意节点间的 All-to-All 通信。
蜻蜓拓扑（Dragonfly）：将节点分组，组内全连接、组间通过少量链路互连。任意两个节点间最多只需经过两跳（组内 → 组间 → 组内），网络直径极小。但组间链路容易成为瓶颈，需要配合自适应路由使用。
UB-Mesh：华为提出的统一总线网格架构，采用统一总线协议将本地总线概念扩展至数据中心级别，通过分层局部多维全互连实现任意节点间的高效通信。
Rail-Only：博通在 Tomahawk 6 芯片中集成的简化互连方案，针对 AI 加速器间通信模式进行深度优化，减少不必要的协议转换和路径选择开销。

不同拓扑各有取舍，选择取决于具体的规模需求、成本预算和通信模式。以下 Python 代码可以直观理解 Leaf-Spine 拓扑中的路径数量与带宽关系：

python

def leaf_spine_capacity(n_leaf: int, n_spine: int,
                        downlink_bw_gbps: float,
                        uplink_bw_gbps: float,
                        servers_per_leaf: int) -> dict:
    """计算 Leaf-Spine 网络的关键容量指标"""
    total_servers = n_leaf * servers_per_leaf
    # 每对 Leaf 之间有 n_spine 条等价路径
    paths_between_any_two_leafs = n_spine
    # 每台 Leaf 的总上行带宽
    leaf_uplink_total = n_spine * uplink_bw_gbps
    # 每台 Leaf 的总下行带宽
    leaf_downlink_total = servers_per_leaf * downlink_bw_gbps
    # 超额比 = 下行总带宽 / 上行总带宽（1:1 为无阻塞）
    oversubscription = leaf_downlink_total / leaf_uplink_total
    return {
        "总服务器数": total_servers,
        "任意两Leaf间等价路径数": paths_between_any_two_leafs,
        "每Leaf上行总带宽(Gbps)": leaf_uplink_total,
        "每Leaf下行总带宽(Gbps)": leaf_downlink_total,
        "超额订阅比": f"{oversubscription:.1f}:1",
    }

# 典型配置: 32 台 Leaf, 32 台 Spine, 每 Leaf 下连 32 台服务器
result = leaf_spine_capacity(
    n_leaf=32, n_spine=32,
    downlink_bw_gbps=400, uplink_bw_gbps=400,
    servers_per_leaf=32
)
for k, v in result.items():
    print(f"  {k}: {v}")
# 输出:
#   总服务器数: 1024
#   任意两Leaf间等价路径数: 32
#   每Leaf上行总带宽(Gbps): 12800
#   每Leaf下行总带宽(Gbps): 12800
#   超额订阅比: 1.0:1

可以看到，当上行端口数等于下行端口数且带宽相同时，超额订阅比为 1:1，即无阻塞设计。

11.4.2 RDMA 技术与无损网络

传统 TCP/IP 的瓶颈。 分布式训练中，GPU 之间需要频繁交换梯度、激活值等大量数据。如果使用传统的 TCP/IP 协议栈，数据从应用程序出发，需要经历用户空间到内核空间的上下文切换、内核缓冲区的多次拷贝、协议栈的逐层封装解封——整个过程 CPU 深度参与，延迟在毫秒量级，远远无法满足大规模训练对微秒级通信的需求。

RDMA 的核心机制。 RDMA（Remote Direct Memory Access，远程直接内存访问）从根本上重构了网络通信的数据路径。它依靠两大核心机制实现高性能：

内核旁路（Kernel Bypass）：应用程序不再通过系统调用进行通信，而是直接调用用户态的 RDMA 库（Verbs API）与支持 RDMA 的网络适配器（RNIC）交互。整个数据面操作跳过操作系统内核，大幅减少上下文切换开销。
零拷贝（Zero-Copy）：数据从应用程序注册的内存区域直接通过 DMA 传输到网络，无需在用户缓冲区和内核缓冲区之间拷贝。接收端的 RNIC 同样直接将数据写入目标内存。

RDMA 与 TCP/IP 数据路径对比

RDMA 的工作流程。 要使用 RDMA 通信，应用程序需要经历以下步骤：

资源准备：分配保护域（PD，Protection Domain）、完成队列（CQ，Completion Queue）和队列对（QP，Queue Pair）。QP 是 RDMA 通信的基本单元，由发送队列（SQ）和接收队列（RQ）组成。同时，将一块内存区域注册给 RNIC（称为 MR，Memory Region），使硬件可以直接访问该内存。
连接建立：通信双方通过带外方式（通常是 TCP 连接）交换各自的 QP 信息和内存区域的远程访问密钥（RKey）。
数据传输：应用向 QP 提交工作请求（WR，Work Request），RNIC 硬件从队列中取出请求并通过 DMA 执行数据传输，整个过程 CPU 不参与。
完成通知：操作完成后，RNIC 向 CQ 中写入完成项（WC，Work Completion），应用通过轮询 CQ 获知操作结果。

RDMA 支持两种操作模式。双边操作（Send/Receive） 类似传统消息传递，接收方需要预先提交接收请求。单边操作（Read/Write） 允许一端直接读写远端内存，远端 CPU 完全不参与——这对分布式训练中的梯度同步特别有价值，因为它最大限度地减少了远端 CPU 的干扰。

下表对比了 RDMA 与传统 TCP/IP 在关键性能维度上的差异：

特性	传统 TCP/IP	RDMA
数据路径	用户空间 → 内核空间 → 网卡	用户空间 → 网卡
CPU 参与度	高（协议栈管理、数据拷贝）	极低（仅发起请求）
数据拷贝次数	多次	零拷贝
通信延迟	毫秒级	微秒级
编程接口	Socket API	Verbs API

RDMA 的三种协议实现。 RDMA 是一种技术理念，具体有三种协议实现：

InfiniBand（IB）：原生 RDMA 架构，性能最高、延迟最低，但需要专用的 IB 网卡、IB 交换机和 IB 线缆，构建和维护一套独立于以太网的专用网络，成本较高。
RoCE（RDMA over Converged Ethernet）：在以太网上承载 RDMA 协议。RoCE v2 基于 UDP/IP 封装，支持三层路由，是当前以太网 AI 集群的主流选择。但它要求网络是无损的——RDMA 的重传机制采用 go-back-N 策略，任何丢包都会导致性能急剧下降。
iWARP：基于 TCP/IP 的 RDMA 实现，可在普通以太网上运行，无需无损网络支持，但性能不如前两者。

下表对比了三种 RDMA 协议的关键特性：

特性	InfiniBand	RoCE v2	iWARP
底层协议	原生 RDMA 架构	以太网 / UDP/IP	TCP/IP
性能表现	最高，延迟最低	接近 IB，延迟略高	受 TCP 影响，延迟最高
网络要求	专用网络（IB 网卡、交换机、线缆）	无损以太网（需 PFC/ECN）	标准以太网
部署复杂度	高（独立网络）	中等（需精细配置交换机）	低（即插即用）
路由能力	不支持 IP 路由	支持 IP 路由	支持 IP 路由

在大规模 AI 集群中，InfiniBand 长期占据主导地位，NVIDIA 的 Quantum 系列交换机搭配 ConnectX 系列网卡提供了端到端的高性能 IB 方案。近年来，随着 RoCE v2 技术的成熟和以太网方案成本优势的凸显，越来越多的集群开始采用基于 RoCE 的以太网组网方案。华为的 CloudEngine 交换机搭配自研智能网卡、博通 Tomahawk 交换机芯片搭配 Thor 系列网卡等，都是典型的 RoCE 方案。

无损网络与 PFC。 RoCE 网络正常运行的前提是无损传输——网络中不能发生丢包。当多条链路的流量汇聚到同一个交换机端口时（称为 Incast 现象），端口缓冲区可能被填满，超出部分的数据包会被丢弃。为了在以太网上实现无损传输，业界引入了 PFC（Priority-based Flow Control，基于优先级的流量控制） 机制。

PFC 是 IEEE 802.1Qbb 标准定义的链路级流量控制协议。它的核心思想是：当接收端交换机检测到某个优先级队列的缓冲区即将溢出时，向上游发送暂停帧（Pause Frame），通知上游立即停止发送该优先级的流量；当缓冲区水位降到安全阈值以下时，再发送恢复帧（Resume Frame）。

PFC 工作机制示意

PFC 保证了不丢包，但也引入了一系列问题：

队头阻塞（Head-of-Line Blocking）：PFC 的控制粒度是优先级队列而非单条流。当某条流引起的拥塞触发了 PFC 暂停，同一队列中所有无关的流也会被阻塞。

PFC 队头阻塞示意

PFC 风暴：由于 PFC 是逐跳反压，当前方持续拥塞时，暂停帧会逐级向上游传导，波及越来越多的链路，形成风暴。
PFC 死锁：如果网络中存在环路（配置错误、路由收敛瞬态等），PFC 的反压可能形成环形等待，导致死锁——所有端口都在等待对方恢复，没有外力干预无法自行恢复。

缓解这些问题的工程手段包括：将不同业务流量分配到不同优先级队列以减少队头阻塞的影响范围；通过 watchdog 机制在 PFC 暂停超时后强制解除以防止死锁；在网络设计中严格避免环路。但最根本的解决思路是：PFC 只是无损网络的最后一道保险，不应被频繁触发。更好的策略是通过拥塞控制算法在拥塞发生之前就主动降低发送速率，从而减少 PFC 的触发频率。二者的关系可以类比为：拥塞控制是"温和的减速带"，PFC 是"紧急刹车"。

11.4.3 拥塞控制

拥塞控制与 PFC 流控有本质区别：PFC 是逐跳的、粗暴的"暂停/恢复"机制，而拥塞控制是端到端的、精细的速率调节机制。拥塞控制算法检测网络中的拥塞信号，将信息反馈给真正的发送端，由发送端动态调整发送速率。

拥塞检测的三种方式。 检测拥塞的信号主要有三类：

基于丢包：传统 TCP 的做法（如 Tahoe、CUBIC 算法），以丢包作为拥塞信号。但对 RDMA 不适用——RDMA 的 go-back-N 重传机制意味着任何一个包的丢失都会导致后续大量数据的无效重传，等到丢包再降速为时已晚。
基于 ECN（Explicit Congestion Notification，显式拥塞通知）：ECN 利用 IP 头中 Differentiated Services 字段的最后两位。发送端将 ECN 字段设为 01 或 10，表明自己支持 ECN 功能。当交换机检测到出口队列深度超过阈值时，将经过的数据包 ECN 字段改为 11（Congestion Experienced），标记过程基于 RED（Random Early Detection）算法——队列越深，标记概率越大。这种随机标记对不同流相对公平：发送数据越多的流，被标记的概率也越大。ECN 是 RoCE 网络中最主流的拥塞检测方式。
基于 RTT（Round-Trip Time）：通过定期发送计时数据包测量往返延迟来推断拥塞程度。RTT 升高意味着数据包在队列中排队等待，拥塞加剧。相比 ECN 只能反映"是否超过阈值"的二值信息，RTT 能更精确地量化端到端延迟。但 RTT 测量易受 ACK 包排队的干扰，需要通过硬件级精确计时或高优先级 ACK 通道来保证准确性。

DCQCN 算法。 DCQCN（Data Center Quantized Congestion Notification）是 2015 年由 Microsoft 和 Mellanox 联合提出的 RoCE v2 拥塞控制算法，也是目前部署最广泛的方案。它将整个控制流程分为三个角色：

DCQCN 架构：拥塞点、通知点、反应点

CP（Congestion Point，拥塞点）：即发生拥塞的交换机。当出口队列深度在 $K_{min}$ 和 $K_{max}$ 之间时，按概率 $p$ 对经过的数据包标记 ECN；超过 $K_{max}$ 时以 100% 概率标记。

ECN 标记概率与队列深度的关系

NP（Notification Point，通知点）：即数据接收端。收到 ECN 标记的数据包后，向发送端发送 CNP（Congestion Notification Packet）报文。为避免 CNP 泛滥，每隔一定时间间隔（默认约 4 微秒）才发送一次。
RP（Reaction Point，反应点）：即数据发送端。收到 CNP 后按照 AIMD（加性增、乘性减） 策略调节发送速率。

DCQCN 的速率调节逻辑如下。发送端维护一个拥塞程度参数 $α \in [0, 1]$ ，周期性更新：

α \leftarrow (1 - g) \cdot α + g \cdot F

其中 $g$ 是平滑因子， $F$ 为当前周期是否收到 CNP（收到为 1，否则为 0）。降速时，当前速率 $R_{c}$ 按比例削减：

R_{c}^{new} = R_{c} \cdot (1 - α / 2)

升速时分为快速恢复和主动恢复两个阶段。快速恢复阶段取当前速率与目标速率 $R_{t}$ 的均值：

R_{c}^{new} = (R_{c} + R_{t}) / 2

主动恢复阶段则根据两个指标判断拥塞程度：距离上次收到 CNP 的时间间隔 $T$ 和已发送的数据包数量 $B C$ ，并设阈值 $F$ 。当两者都未达到 $F$ 时，以基础步长 $R_{AI}$ 温和恢复；当两者都超过 $F$ （长时间大量发送且无拥塞反馈）时，以更激进的步长 $R_{HAI}$ 快速恢复。这种分级升速策略在保守避免拥塞与快速恢复带宽利用率之间取得了平衡。

PFC 与 DCQCN 的协同。 在实际部署中，PFC 和 DCQCN 构成两层防线。正常情况下，DCQCN 通过 ECN 标记提前感知拥塞并温和降速，交换机队列深度维持在可控范围内，PFC 不会被触发。只有当拥塞来得太快、DCQCN 来不及降速时（如突发的 Incast），PFC 才作为最后手段紧急反压。好的网络设计应尽量让 DCQCN 承担主要调控职责，PFC 仅处理极端突发。

其他拥塞控制算法。 除 DCQCN 外，还有几种值得关注的方案：

TIMELY（Google，2015）：纯基于 RTT 的算法，不依赖交换机 ECN 标记，仅通过测量 RTT 变化来检测拥塞。优点是对交换机无要求，但 RTT 测量精度受限。
HPCC（阿里巴巴，2019）：利用交换机在数据包中嵌入的精细遥测信息（队列深度、链路利用率等），发送端据此精确计算出目标速率，一步到位地调整，收敛速度远快于 DCQCN 的迭代式调节。
Swift（Google，2020）：改进的基于延迟的拥塞控制，区分了网络内延迟和端侧延迟，在 Google 数据中心大规模部署，用于替代早期的 TIMELY 算法。

11.4.4 负载均衡

即使拥塞控制能在检测到拥塞后及时降速，更理想的做法是从一开始就将流量均匀地分布到所有可用路径上，避免某条链路过载而其他链路空闲——这就是负载均衡要解决的问题。

数据包与流的概念。 在深入负载均衡之前，需要区分两个基本概念。数据包（Packet） 是网络层的最小传输单元。流（Flow） 是共享相同五元组（源 IP、目的 IP、源端口、目的端口、协议号）的一系列数据包序列——例如，GPU-1 到 GPU-2 的一次数据传输所产生的所有数据包构成一个"流"。负载均衡的核心问题就是：以"流"为单位还是以"包"为单位来分配路径？

AI 集群中的"大象流"。 传统数据中心的流量以大量短小的**"老鼠流"（Mouse Flow）（如网页请求）为主，ECMP 的统计性均衡就足以应对。但 AI 训练截然不同。在数据并行的 All-Reduce 阶段，所有 GPU 必须同步梯度。NCCL 通信库会将可达数百 GB 的梯度数据切分为大块（Chunk），指挥所有 GPU 在同一时刻通过 GPUDirect RDMA（绕过 CPU，从显存直通网卡）并发传输。从网络的视角看，每条大块数据传输都是一条持续时间长、占用带宽极高的"大象流"（Elephant Flow）**。由于这种传输是全局并发的（例如 64 个 GPU 同时爆发），网络中会瞬间涌入大量并行的大象流，对负载均衡提出了严峻考验。

ECMP：静态哈希负载均衡。 ECMP（Equal-Cost Multi-Path，等价多路径路由）是最基础的负载均衡技术。当交换机发现有多条等价路径到达同一目的地时，会对每个数据包的五元组（源 IP、目的 IP、源端口、目的端口、协议号）计算哈希值，取模后选定路径。同一条流的所有数据包五元组相同，因此被固定路由到同一条路径上，保证了数据包顺序。

然而 ECMP 在面对 AI 训练负载时会严重失效。静态哈希无法感知流的实际带宽占用，多条"大象流"可能被哈希到同一条物理链路上——这就是哈希碰撞。被碰撞的链路严重拥塞，而其他等价路径可能完全空闲。由于 All-Reduce 是同步操作，整个训练必须等待最慢的那条流完成，ECMP 的路径不均衡直接拖慢全局训练速度。

ECMP 哈希碰撞示意

Spray and Reorder：按包喷洒与重排。 既然按流哈希导致大象流堆积，最直接的改进就是抛弃流粒度，改为按包分发。入口交换机采用轮询策略，将连续的数据包"喷洒"到所有可用的上行链路上，从根本上消除哈希碰撞，实现近乎完美的负载均衡。

但这种方式带来了致命问题：数据包乱序。同一条流的数据包走不同路径到达，由于各路径的物理长度、光纤延迟、排队情况不同，到达顺序被打乱。对于 RDMA/RoCE 来说，严重乱序会被误判为丢包，触发 go-back-N 重传机制，性能急剧下降。因此，出口交换机（Egress Leaf）必须配备硬件重排序缓冲区（Reorder Buffer），按序列号将乱序到达的数据包重新排列后再转发给目标 GPU。

然而，重排序缓冲区本身又引入了新的队头阻塞风险：如果某个包因走了慢路径而延迟到达，缓冲区必须"扣住"所有后续已到达的包等待该慢包，整个流被最慢的那个包卡住。这种方案效果极致，但需要专用的高端交换机芯片（如 NVIDIA、博通的定制 ASIC），成本高昂且存在厂商锁定风险。Google 在其 TPU 专用 Clos 网络（Jupiter 架构）中控制了从网卡到交换机的整个技术栈，采用了这种"全栈自研"的激进方案，用极致的硬件复杂性换取极致的网络性能。

Flowlet：流片交换。 Flowlet 机制在"按流"和"按包"之间找到了精妙的平衡点。其核心概念是流片（Flowlet）——来自同一条流的、在时间上连续的一组数据包。如果一条流的发送中出现了超过特定阈值的空闲间隙，间隙两侧的数据包就被视为不同的流片。

Flowlet 动态路径切换机制

Flowlet 交换的工作原理是：

新流片到来时：交换机实时评估所有路径的拥塞状况（队列深度、链路利用率等），为新流片选择当前最优路径
流片内部：所有数据包固定走同一条路径，保证严格按序到达
空闲间隙超时后：交换机认为进入了新流片，重新进行动态路径选择

间隙阈值通常设置为大于不同路径间的最大延迟差，确保前一个流片的数据包已经全部到达后，后续流片才切换路径，从而避免跨流片的乱序。

这三种方案的核心取舍可以用下图概括：

三种负载均衡方案对比

特性	ECMP（静态哈希）	Spray and Reorder	Flowlet（流片交换）
均衡粒度	Per-Flow（流）	Per-Packet（包）	Per-Flowlet（流片）
决策方式	静态，流开始时一次性决定	静态，按包轮询	动态，每个流片重新决策
数据包乱序	无	严重	基本无
硬件要求	低，标准商用交换机	极高，需专用重排缓冲区	中高，需高速定时器
核心优势	简单、无乱序	完美负载均衡	动态均衡且无乱序
核心缺点	哈希碰撞	成本高、HOL 阻塞	均衡度非完美

业界的选择。 不同的技术生态对应不同的负载均衡策略：

NVIDIA InfiniBand 生态：Quantum 系列交换机内置了自适应路由（Adaptive Routing），交换机本身感知下游链路拥塞并动态选路，理念与 Flowlet 接近但实现更底层、更高效。这套端到端的闭环生态是 IB 网络长期保持性能领先的核心之一。
Google 自研生态：作为 Spray and Reorder 的坚定拥护者，Google 在其 TPU 专用 Clos 网络中控制了从网卡到交换机的整个技术栈，采用激进的 Per-Packet 喷洒方案，用极致的硬件复杂性换取完美的负载均衡。
主流以太网生态：博通 Tomahawk 和 Jericho 系列交换机芯片内置了基于 Flowlet 的动态负载均衡（DLB） 功能，ASIC 实时监测出口队列拥塞并在流片粒度上做动态路径决策。Arista、Cisco、Dell 等厂商的 AI 网络方案都以此为核心卖点。Flowlet 机制因其在性能与成本之间的精妙平衡，已成为 RoCE 以太网 AI 集群的事实标准。

总结来说，静态 ECMP 在 AI 集群中已经过时。技术路线的选择取决于生态控制力和成本约束：全栈自研者选 Spray and Reorder，端到端 IB 方案选自适应路由，开放以太网生态选 Flowlet。

11.4.5 拓扑、协议与策略的协同

至此，我们已经分别讨论了网络拓扑、RDMA/无损网络、拥塞控制和负载均衡四个维度。在真实的万卡级 AI 集群中，这四个维度并非独立工作，而是紧密协同的整体：

拓扑决定路径：Leaf-Spine/Fat-Tree 提供了多条等价路径，为负载均衡创造了条件。
RDMA 决定传输方式：内核旁路和零拷贝保证了单条路径上的极致性能，但对丢包和乱序极度敏感。
PFC + 拥塞控制保证无损：DCQCN 在正常负载下通过 ECN 反馈温和调速，PFC 作为最后防线应对突发 Incast，二者配合确保 RoCE 所需的无损环境。
负载均衡确保路径利用率：Flowlet 或自适应路由将大象流动态分散到多条路径上，避免单条链路过载。

这四层机制从上到下形成了一个完整的网络栈：拓扑提供物理基础，RDMA 提供传输效率，拥塞控制保障稳定性，负载均衡优化利用率。任何一层的设计缺陷都会成为整个系统的瓶颈。

本节小结

集群组网是大规模 AI 训练的"血管系统"，直接决定了数千张 GPU 能否如同一台计算机般协同工作。本节的核心要点包括：

网络拓扑：胖树（Fat-Tree）/Clos 网络通过多级交换实现无阻塞通信，Leaf-Spine 是其工程化的两层实现。AI 集群呈现明显的分层互连结构（NVLink → InfiniBand/RoCE → Spine 骨干），不同并行策略应与网络层次对齐。
RDMA 技术：通过内核旁路和零拷贝将通信延迟从毫秒级降至微秒级。InfiniBand 和 RoCE v2 是两大主流实现，前者性能最优但成本高、需专用网络，后者可复用以太网基础设施但依赖无损网络。
无损网络：PFC 通过逐跳反压保证不丢包，但会引发队头阻塞、风暴和死锁等副作用。PFC 应作为最后防线，由拥塞控制算法承担主要调控职责。
拥塞控制：DCQCN 基于 ECN 标记实现端到端的 AIMD 速率调节，是 RoCE 网络的标准拥塞控制算法。HPCC、Swift 等新方案通过更精细的信号（遥测信息、RTT）实现更快的收敛。
负载均衡：ECMP 的静态哈希在面对 AI 训练的"大象流"时严重失效；Spray and Reorder 通过按包喷洒实现完美均衡但成本极高；Flowlet 在流粒度和包粒度之间取得平衡，已成为主流以太网 AI 集群的首选方案。

11.4 集群组网 ​

11.4.1 网络拓扑：从传统树到胖树与 Leaf-Spine ​

11.4.2 RDMA 技术与无损网络 ​

11.4.3 拥塞控制 ​

11.4.4 负载均衡 ​

11.4.5 拓扑、协议与策略的协同 ​