跳到主要内容

路由策略选型指南

核心要点：

  • Fat-tree 路由空间最大：ECMP / E-ECMP / WCMP / AR / Packet Spraying / DQPLB / PLB+PRR / SRv6 都可选
  • Torus 拓扑首选 DOR；Dragonfly 首选 UGAL；Jellyfish / Xpander 只能选 KSP
  • 选型核心权衡：带宽利用率 vs 延迟可预测性，训练偏前者推理偏后者
  • 大规模生产部署普遍采用多层协同（如 Fairwater = MRC + Multiplane + Static SRv6）

本文汇总各路由策略的适用场景和性能特性矩阵，结合拓扑类型给出选型建议。

策略性能矩阵​

核心问题：一张矩阵里各路由策略在延迟、带宽、适应流量类型上的综合评分如何排布？

策略带宽利用率延迟可预测性报文有序性硬件要求适用拓扑
ECMP受哈希碰撞限制高保证（流级别）通用 ASICFat-tree、Clos
E-ECMP + QP Scaling高（多 QP 降低碰撞）高保证支持 UDF 的 ASICFat-tree、Clos
WCMP高（权重适配链路容量）高保证通用 ASIC + SDNFat-tree（含故障链路）
AR per-flowlet高（实时拥塞感知）中基本保证专用 AR ASICFat-tree、IB
AR per-packet最高级别之一中不保证AR ASIC + 重排序Fat-tree、IB
DOR高（通信与维度对齐时）最高（确定性）保证通用（维度感知）Torus、Mesh
UGAL高（动态最短路/Valiant 切换）中保证支持队列深度读取Dragonfly
Packet Spraying最高（统计均匀分散）低（乱序恢复）不保证新一代 NIC + 重排序缓冲Fat-tree
KSP取决于 $K$ 和路径长度分布中（路径不等长）保证（流级别）TCAM 容量支持多路径Jellyfish、Xpander
DQPLB高（CQE 反馈动态调度）中保证（双序号 + IMM opcode）通用 RoCEv2 ASICRail-Optimized + 多 NIC
TE-CCL理论最优（离线 MILP 求解）高（编译时确定）保证任意（schedule plugin）任意 DAG（小规模）
PLB / PRR中（拥塞/故障触发 repath）中保证（idle period repath）现代 ASIC（含 flow label 哈希）+ Linux 6.0+Fat-tree / Clos IPv6
SRv6高（编译时最优路径）最高（编译时确定）保证SRv6 ASIC + IPv6任意 IPv6 网络（含跨 DC）

@tbl-route-selection-matrix 路由策略性能矩阵

按拓扑类型的选型建议​

核心问题：Fat-tree/Torus/Dragonfly 各自最优的路由策略和选型理由是什么？

Fat-tree / Clos（数据中心主流拓扑）​

Fat-tree 拥有丰富的等价路径，路由策略的选择空间最大。

场景推荐策略理由
通用互联网/混合流量ECMP流量熵值高，哈希碰撞概率低
AI 训练集群（AllReduce 为主）E-ECMP + QP Scaling解决大流低熵导致的哈希碰撞（$\href{/interconnect/路由算法/ecmp}{\text{(3.2)}}$）
含故障链路或非对称拓扑WCMP按实际链路容量加权分配流量
需要高实时性的拥塞响应AR per-flowletflowlet 边界重选路，选路判据同 per-packet（$\href{/interconnect/路由算法/自适应路由}{\text{(3.14)}}$）
极致带宽利用率（含 UEC NIC）Packet Spraying每报文独立分散（$\href{/interconnect/路由算法/packet-spraying}{\text{(3.28)}}$）
100K+ GPU + Rail-Optimized + 异构链路DQPLB通信库主动调度 QP + CQE 反馈（见 3.9 DQPLB）
流量矩阵规律 + 需要全局最优TE-CCL[1]MILP 离线求解，运行时按表执行（见 3.10 TE-CCL）
主机驱动拥塞/故障响应（IPv6）PLB + PRRhost transport 改 IPv6 flow label 触发 ECMP 重哈希（见 3.11 PLB / PRR）
全 IPv6 + 跨 DC + 需要路径编程SRv6SID list 编码完整路径（见 3.12 SRv6）

@tbl-route-selection-fattree Fat-tree / Clos 拓扑选型

典型案例：

  • Meta 24K GPU 集群：E-ECMP + QP Scaling[2]
  • Meta Llama4 训练（96K GPU）：NCCLX + DQPLB[3]
  • Microsoft Fairwater AI 数据中心：MRC + Multiplane + Static SRv6 三层协同[4]
  • Google 数据中心：PLB + PRR + Bolt 协同栈[5][6]

Torus / Mesh（Google TPU 系列）​

Torus 拓扑的规则结构使 DOR 成为首选，路径确定性强。

场景推荐策略理由
标准 3D Torus + AllReduceDOR + 维度分解通信与维度对齐，无跨维度链路竞争
需要提升 bisection bandwidthOCS 重配 Twisted Torus + DOR光交换动态重配拓扑
工作负载不与维度对齐有限的 ECMP（仅同维度内）DOR 路径多样性低，需局部多路径补充

@tbl-route-selection-torus Torus / Mesh 拓扑选型

典型案例：

  • Google TPU v4/v5/v6/Ironwood：3D Torus + DOR + OCS[7]
  • XLA 编译器在编译时将 TP/DP/PP 分配到对应 Torus 维度，路由静态确定

Dragonfly（HPC 超算）​

Dragonfly 的稀疏全局链路是瓶颈，需要 UGAL 的动态切换来平衡最短路和绕路。

场景推荐策略理由
标准工作负载UGAL动态选择 Minimal 或 Valiant（$\href{/interconnect/路由算法/ugal}{\text{(3.27)}}$）
高强度 AllToAll（MoE）UGAL + 全局链路容量规划AllToAll 天然均匀分布，Valiant 比例高
全局 AllReduce分层通信限制在组内，全局链路只传规约结果
研究/探索Q-adaptive强化学习路由（学术阶段）

@tbl-route-selection-dragonfly Dragonfly 拓扑选型

典型案例：

  • HPE Slingshot（Frontier 超算）：UGAL
  • Dragonfly 在大规模 LLM 训练中受全局链路限制，行业正在评估替代方案

Rail-Optimized（NVLink + InfiniBand 双网络）​

节点内 NVLink 和节点间 IB 是两个完全独立的网络域，路由策略分层处理。

层级推荐策略理由
NVLink 域内（8/72 GPU）NVSwitch 全互联无需路由选择，全交叉带宽
InfiniBand 域间硬件 AR per-flowlet + SHARPHCA 硬件重排序对应用透明
并行策略分配TP 在 NVLink 域内，PP/DP 走 IB最大化 NVLink 高带宽利用

@tbl-route-selection-rail Rail-Optimized 双网络选型

决策流程​

核心问题：给定集群拓扑和流量模式，路由策略选型的决策流程是什么？

是否有明确的拓扑类型？
  |
  +-- Torus/Mesh --> DOR（+ OCS 优化）
  +-- Dragonfly --> UGAL
  +-- Jellyfish/Xpander --> KSP（K-Shortest Paths）
  +-- Fat-tree/Clos --> 继续判断
        |
        v
流量矩阵规律 + 拓扑稳定 + 求解器可用？
  |
  +-- 是 --> TE-CCL 离线最优 schedule
  +-- 否 --> 继续判断
        |
        v
GPU 规模 >= 100K + Rail-Optimized + 异构链路？
  |
  +-- 是 --> DQPLB（通信库 + CQE 反馈）
  +-- 否 --> 继续判断
        |
        v
全 IPv6 + 跨 DC 或需要路径编程？
  |
  +-- 是 --> SRv6（与 MRC / Multiplane 协同）
  +-- 否 --> 继续判断
        |
        v
有 IPv6 + Linux 6.0+ host stack（需主机响应拥塞/故障）？
  |
  +-- 是 --> PLB + PRR + 拥塞控制（Bolt/Swift/DCTCP）
  +-- 否 --> 继续判断
        |
        v
是否已有 UEC 1.0 NIC？
  |
  +-- 是 --> Packet Spraying（统计均匀分散）
  +-- 否 --> 继续判断
        |
        v
是否有 AR ASIC（Quantum/Spectrum-4/Tomahawk 4+）？
  |
  +-- 是 --> 自适应路由（per-flowlet）
  +-- 否 --> 继续判断
        |
        v
AI 工作负载（大流、低熵）？
  |
  +-- 是 --> E-ECMP + QP Scaling
  +-- 否（通用流量） --> 标准 ECMP

带宽利用率与延迟的权衡​

核心问题：路由策略中带宽利用率和延迟之间如何权衡？包喷洒和自适应路由的代价是什么？

所有路由策略都在以下两个维度间做取舍：

带宽利用率：从 ECMP 到 Packet Spraying 递增，但随之而来的是更高的系统复杂度、硬件要求和不确定性。策略越激进（如 per-packet 分散），链路利用越均匀，但需要更多硬件支持（重排序缓冲、AR ASIC）。

延迟可预测性：DOR 提供最高确定性（路径在部署时由坐标差唯一确定），AR 和 Packet Spraying 的延迟受实时网络状态影响，尾延迟较高。

AI 推理场景（对尾延迟敏感）倾向于确定性路由；AI 训练场景（对吞吐量敏感）倾向于高带宽利用率策略。

Takeaway​

选型维度推荐
Fat-tree 通用流量ECMP
Fat-tree + AI 训练E-ECMP + QP Scaling，规模 ≥ 100K 升级 DQPLB
Fat-tree + IPv6 + host 控制PLB + PRR + Bolt
Fat-tree + 全 IPv6 跨 DCStatic SRv6 + MRC + Multiplane
Torus / MeshDOR + 维度分解
DragonflyUGAL
Jellyfish / XpanderKSP
流量矩阵规律 + 小规模TE-CCL 离线 schedule
UEC NIC 在手Packet Spraying

参考资料​

  1. Liu et al., Rethinking ML Collective Communication as a Multi-Commodity Flow Problem, SIGCOMM 2024. https://dl.acm.org/doi/10.1145/3651890.3672249
  2. Gangidi et al., RDMA over Ethernet for Distributed AI Training at Meta Scale, SIGCOMM 2024. https://dl.acm.org/doi/10.1145/3651890.3672233
  3. Collective Communication for 100k+ GPUs, arXiv:2510.20171 (Meta, 2025). https://arxiv.org/abs/2510.20171
  4. segment-routing.net, Microsoft: SRv6 powers the largest AI DC in the world, 2025-10. https://www.segment-routing.net/news/2025-10-13-Microsoft-SRv6-powers-the-largest-AI-DC-in-the-world/
  5. Qureshi et al., PLB: Congestion Signals are Simple and Effective for Network Load Balancing, SIGCOMM 2022. https://dl.acm.org/doi/10.1145/3544216.3544226
  6. Wetherall et al., Improving Network Availability with Protective ReRoute, SIGCOMM 2023. https://dl.acm.org/doi/10.1145/3603269.3604867
  7. Jouppi et al., TPU v4: An Optically Reconfigurable Supercomputer, ISCA 2023. https://arxiv.org/abs/2304.01433