10 万卡集群：路由与拥塞控制的核心挑战及业界应对
10 万 GPU 集群的网络不是更大的网络，是一个物理定律不同的网络。本文系统拆解路由和拥塞控制面临的 8 个核心挑战，以及业界四条路线（RoCEv2、MRC、UET、InfiniBand）的应对策略和尚未解决的空白。
本文是 locsic.com AI 网络系列的延续。前序文章：「从 CLOS 到 ZCube：智算集群网络拓扑演进」、「MRC 协议：当网卡成为大脑」、「Scale-Across：AI 集群正在跨城生长」。
问题的物理本质
10 万卡集群的网络面对的不是一个抽象问题，而是三个物理量同时恶化：
| 物理量 | 1 万卡量级 | 10 万卡量级 | 后果 |
|---|---|---|---|
| 并发链路数 | ~万级 | ~十万级 | ECMP 哈希冲突从概率事件变成必然事件 |
| 单 step 参与通信的 GPU 数 | ~8,000 | ~100,000 | AllReduce/All-to-All 的 incast 规模放大 12 倍 |
| 任意时刻在网 packet 数 | ~百万 | ~数千万 | 任何微小的拥塞都会被放大为全局性的 buffer 压力 |
三个物理量叠加的后果是：在 1 万卡时可以靠调参解决的问题，到 10 万卡变成了结构性瓶颈。同步预训练的流量模式让这个瓶颈更加致命：每个训练 step 都是锁步计算，先并行算，再全局通信。通信轮次中最慢的一次传输决定整个 step 的耗时。尾延迟主导性能，而尾延迟正是路由和拥塞控制失效的直接产物。
路由挑战
挑战 1：ECMP 哈希冲突——流量分配不均
传统 RoCEv2 网络用 ECMP（Equal-Cost Multi-Path）做负载均衡：交换机对每个 packet 的五元组做哈希，选一条等价路径。这是流级别的分配：同一个 flow 的所有 packet 走同一条路。
在 10 万卡集群里，同时存在数百万条微流（micro-flow）。哈希是概率性的，当链路数上万、流数上百万时，必然出现多条大流量被哈希到同一条链路上。某条链路被两个 AllReduce 大流同时选中，延迟飙升，拖垮整个 step 的尾延迟。
规模放大的残酷性在于生日悖论效应。假设单条链路被哈希选中的概率是 1/N（N 条等价路径）。1 万卡时 N 可能是 64，冲突概率可接受。10 万卡时即便拓扑增大使 N 增至 256，但流数增长了 10 倍，至少一对大流碰撞的概率仍然趋近于 1。
业界思路：
| 方案 | 核心做法 | 代表 |
|---|---|---|
| 包级 spraying | 打破流级绑定，同一 flow 的 packet 分散到 128-256 条路径 | MRC（EV spraying）、UET（packet spraying） |
| 自适应路由 | 交换机根据端口利用率动态选路 | NVIDIA Spectrum-X Adaptive Routing、IB 自适应路由 |
| 拓扑感知路由 | 利用拓扑结构预计算最优路径，减少冲突概率 | ZCube/ATOP 拓扑搜索、Google Jupiter 外向路由 |
| 源路由 | 发送端在包头编码完整路径，精确控制每跳 | MRC + SRv6 uSID |
核心分歧在于：包级 spraying 彻底消除了哈希冲突，但要求接收端支持乱序（NIC 需要 OOO write engine）。自适应路由保留有序交付，但交换机需要维护端口利用率状态，且决策精度受限于交换机的局部视野。源路由把控制权完全交给 NIC，但需要拓扑全局信息和路径编排工具。
拓扑选择也在重塑路由问题。传统三层 Fat-Tree 的 ECMP 天然有哈希冲突风险，而 Dragonfly 拓扑（如 HPE Slingshot 在 Frontier/El Capitan 上的部署）用自适应路由绕开了 ECMP，但引入了拥塞下行为难预测的新问题。ZCube 非对称拓扑打破了「所有交换机端口数相同」的设计惯性，反而与源路由更搭：源路由不要求路径「等价」，NIC 可以根据每条路径的实际状态做精确调度。MRC 的 8-plane 两层 Clos 把单平面内的路径压到 3 跳，缩短了包喷射的乱序窗口。拓扑选择、路由协议、拥塞策略三者是 co-design 关系，不能独立讨论。
挑战 2：动态路由收敛延迟——故障恢复太慢
链路/交换机故障在 10 万卡集群里不是「是否发生」，而是「每天发生几次」。BGP/OSPF/IS-IS 在故障后需要检测、传播路由更新、重新计算最短路径、更新 FIB。整个收敛过程在大型集群里可能耗时几十毫秒到几百毫秒。
训练 job 对延迟极其敏感。一次路由收敛期间，受影响的 AllReduce 操作会超时。超时的后果不是降速，是整个训练 job 从上一个 checkpoint 重启，损失可能数十分钟到数小时的 GPU 时间。
更糟糕的是，收敛后的流量重分布可能引发新的 ECMP 哈希不平衡，造成次生拥塞。
业界思路：
| 方案 | 恢复速度 | 机制 |
|---|---|---|
| MRC + SRv6 静态源路由 | 微秒级 | NIC 检测到路径故障 → 退役对应 EV → 换路径，交换机不参与 |
| UET 自适应路由 | 毫秒级 | 交换机基于 ECN 反馈调整路由，NIC 不需要知道拓扑 |
| InfiniBand 自适应路由 | 秒级 | SM 建基础路由表（拓扑级），硬件在表内做包级自适应调度 |
| 传统 BGP 收敛 | 秒级到十秒级 | 检测故障 → 更新传播 → SPF 计算 → FIB 更新 |
MRC 做了一个关键的设计决策：完全禁用交换机的动态路由，所有路由智能集中在 NIC。论文给出的理由是，两个自适应系统（NIC 做路径选择 + 交换机做路由收敛）同时运作会互相干扰。NIC 知道哪些 EV 健康、哪些拥塞，能做出精确决策；交换机只有局部视野，做出来的决策反而可能跟 NIC 冲突。
挑战 3：跨域路由（Scale-Across 场景）
当集群从单机房扩展到同城多机房甚至跨城时（Meta、Microsoft、字节都在做），路由面临新维度：光纤维延迟。同城 RTT ~1ms，跨城 RTT 10-50ms。如果路由协议不感知延迟，把高延迟路径和低延迟路径混在一起做 ECMP，会制造巨大的尾延迟差距。
AllReduce 环形通信对路径延迟一致性极敏感——环上最慢的一跳决定整体速度。跨域部署要求路由协议能区分「近路」和「远路」，不能把不同延迟的路径当等价处理。
业界有几条思路在并行探索。上层交换机可以做延迟感知路由，区分近路和远路。训练框架侧，Megatron/DeepSpeed 的 parallelism planner 在分配 GPU 到物理位置时考虑网络拓扑，优先把通信密集的 parallelism group 放在同机房。NCCL 自动检测 NUMA/NIC/交换机亲和度，构建通信环时优先走近路。在算法层面，把跨域通信从同步 AllReduce 改为流水线异步通信（pipeline parallelism 天然容忍更高延迟），降低对低延迟路由的依赖。专有 DCI 方面，Google 的 B4/Jupiter 和 Microsoft 的 ExpressRoute 用 SDN 集中控制跨域路由。
这个方向目前没有成熟的通用方案。目前最实际的路径是框架侧适配（NCCL topology awareness + pipeline parallelism 跨域），网络层的延迟感知路由还停留在自研阶段。Meta 的两个 24k H100 集群分布在多个数据中心，其 RouteInfra 系统做了大来自研适配；字节跳动的 ByteScale 框架在框架层做了通信调度优化，而不是只依赖网络层。大部分超大规模用户都是自研适配。
挑战 4：路径编排的管理复杂度
传统网络的路由是「自愈」的：交换机自动运行路由协议，管理员不需要关心每条流走哪条路。但 MRC 的 SRv6 源路由、ZCube 的拓扑搜索都要求集中式路径编排。有一个控制器知道全局拓扑，为每对 GPU 计算最优路径，分配 uSID 编码，并在故障后重新计算。
OpenAI 没有公开这部分的实现细节。但从工程角度可以推断：
- 131K GPU 的全局拓扑状态需要实时维护
- 故障后路径重算需要在毫秒级完成
- uSID 分配需要避免冲突
- 新交换机上线/下线需要触发增量更新
这是一个尚未被产品化的领域。市场上没有支持 10 万卡规模的 SRv6 路径编排器商用产品。
拥塞控制挑战
挑战 5：PFC 风暴——无损网络的连锁故障
RoCEv2 依赖 PFC（Priority Flow Control）实现无损网络：接收端 buffer 快满时发 pause frame，让上游交换机暂停发送。pause frame 沿网络向上游传播，形成 head-of-line blocking。
在 10 万卡集群的三层 Clos 里，一条 pause frame 的传播链可能跨越 5-7 跳交换机。任何一个 incast 点（多个发送者同时向一个接收者发数据）都可能触发 pause 风暴，影响范围从单条链路扩大到整个 pod。更严重的是 PFC 死锁：不同优先级的 pause frame 互相阻塞，形成循环依赖。一旦发生死锁，整条通信链路永久停摆，需要人工干预。规模越大，拓扑越复杂，死锁场景越多。
业界有三条路线应对这个问题。MRC 直接禁用 PFC：交换机允许丢包，NIC 用 selective ACK 精确重传。这和互联网 TCP 的哲学一致，在一个会丢包的网络上实现可靠传输。好处是彻底消除 PFC 风暴和死锁风险，代价是丢包重传带来额外开销。UET 和 InfiniBand 走 credit-based 流控：接收端给发送端发额度（credit），有额度才发包，从源头避免 buffer 溢出，既不需要 PFC 也不允许丢包。但两者的实现层级不同：IB 的 credit 是链路级（每个 Virtual Lane 独立管理），UET 的是端到端（NIC 到 NIC）。代价是 credit 管理需要硬件支持和端到端透传。传统 RoCEv2 则保留 PFC，通过死锁检测和 buffer 超配来缓解风险，但在 10 万卡规模这条路的工程代价越来越高。
挑战 6：Incast——多打一的瞬时拥堵
AI 训练的 AllReduce 和 All-to-All 天然产生 incast：几百甚至几千张 GPU 同时向同一张 GPU（或一组 GPU）发数据。接收端 NIC 的入口带宽（800G）瞬间被打爆，buffer 溢出，触发 PFC 或丢包。
在 AllReduce 的 reduce-scatter 阶段，每张 GPU 接收来自环上所有其他 GPU 的数据片段。10 万卡的 AllReduce 环可能有 256 个参与者。即使每条流只发 1GB 数据片段，256 条流在短时间窗口内集中到达接收端，聚合数据量达 256GB 量级，远超任何交换机或 NIC 的 buffer 容量。这里的瓶颈不是单条流的体积，而是同时到达的流数。
业界思路：
| 方案 | 机制 |
|---|---|
| Packet trimming | 交换机拥塞时不丢整个 packet，剥离 payload 保留 header 转发。NIC 收到 trimmed header → 发 NACK 精确重传。区分了「拥塞丢包」和「故障丢包」 |
| 包喷射分散 incast | 把同一 flow 的 packet 打散到 256 条路径上，避免所有流量涌入同一台交换机 |
| 在网计算（In-Network Reduction） | 交换机做 Reduce 运算（求和/求最大），N 条流在交换机内合并成 1 条输出。通信复杂度从 O(N) 降为 O(1) |
| ECN + 降速 | 交换机标记 ECN，发送端收到后降速（DCQCN 拥塞控制） |
| 拓扑感知通信调度 | 训练框架根据物理拓扑安排通信对，减少跨交换机 incast |
在网计算是解决 incast 最彻底的方案。传统 AllReduce 的通信复杂度是 O(N)：N 张 GPU 参与一次 reduce-scatter + allgather，每张 GPU 需要收发 N 份数据。NVIDIA SHARP（Scalable Hierarchical Aggregation and Reduction Protocol）在交换机内做 reduce 运算，N 条流到达交换机后直接做加法/求最大值，输出 1 条结果流。通信复杂度从 O(N) 降为 O(1)，接收端的 buffer 压力从 N 倍降到 1 倍。
SHARP 已经发展到第四代。Quantum-X800 交换机提供 14.4 TFLOPS 的网内计算能力和 sub-100ns 的端口到端口延迟（GTC 2024 发布数据），在大规模 IB 集群上广泛部署。
但以太网生态的在网计算方案还不成熟。UEC 规范定义了 INA（In-Network Assistant）接口，Broadcom Tomahawk 6 的可编程流水线理论上可以实现 reduce 运算，但距离商用产品还有距离。如果以太网交换机能原生做在网 reduce，incast 压力可以直接降一个数量级。这是以太网追赶 IB 的关键里程碑。
集合通信算法与路由的协同也值得关注。Ring AllReduce 对网络延迟一致性极敏感，环上最慢的一跳决定整体速度，对路由的确定性要求很高。Tree AllReduce 对延迟更宽容但 incast 更严重（多层树同时汇聚）。All-to-All 对 bisection bandwidth 要求最高。不同 collective 操作适合不同的路由策略：Ring 搭配确定性源路由（MRC），All-to-All 搭配包喷射效果最好。训练框架（NCCL/CXCCL）在构建通信计划时应该感知底层路由能力，但目前 NCCL 对 MRC/UET 的适配仍在早期。
挑战 7：拥塞控制算法调参——大规模下的黑魔法
RoCEv2 的标准拥塞控制是 DCQCN（Datacenter Quantized Congestion Notification）：交换机标记 ECN → NIC 收到后降速 → 逐步恢复。DCQCN 有十几个参数（ECN 阈值、降速幅度、恢复速度、timer 等），在大规模集群里极难调好。
10 万卡集群里，不同位置的流量模式不同（接入层 vs 汇聚层 vs 核心层），不同训练阶段不同（计算阶段 vs 通信阶段），不同集体通信操作不同（AllReduce vs All-to-All vs AllGather）。一套参数无法适配所有场景，但为每种场景维护不同配置又增加了运维复杂度。
调参不当的后果：
- 太激进（ECN 阈值太低、降速太猛）→ 有效带宽下降，训练变慢
- 太保守（ECN 阈值太高、降速太少）→ buffer 溢出，PFC 风暴/丢包
业界思路：
| 方案 | 出发点 |
|---|---|
| DCQCN 精细调优 | 在大规模集群上反复实测，找到一组「足够好」的参数。工程上可行但不优雅 |
| NSCC（AMD 贡献） | 基于网络侧反馈的拥塞控制，同时被纳入 UEC 和 MRC 规范 |
| MRC 的「不降速只换路」 | 收到 ECN 不降速，标记对应 EV 为 congested 换一条路。把拥塞控制转化为路由问题 |
| UET 拥塞控制（源自 Slingshot） | 基于 HPE 多年超算实战经验调优的算法 |
| HPCC（High Precision Congestion Control） | 用 INT（In-Band Network Telemetry）获取精确链路负载，做精确降速。学术方案，商用部署少 |
MRC 的做法跟所有传统方案都不一样。传统拥塞控制收到 ECN 就降速，这减少了自己的发送量但也降低了整体吞吐。MRC 收到带 EV tag 的 ECN 后不降速，只是把对应路径标记为 congested，换一个 EV 继续全速发包。
挑战 8：长肥管道（Long Fat Pipe）——跨域拥塞
当集群跨机房部署时，光纤延迟使得网络管道变「长」变「胖」（BDP = 带宽 × 延迟增大）。同城跨机房 RTT ~1ms，800G 链路的 BDP 约 100MB——意味着在任何时刻「在路上」的 packet 有 100MB。
传统拥塞控制（DCQCN/TCP）基于反馈：发现问题 → 降速 → 恢复。反馈延迟等于 RTT。在 1ms RTT 下，从检测到拥塞到降速生效，已经有 100MB packet 在路上——这些 packet 无法回收，必须被 buffer 吃下或丢弃。
跨城（RTT 10-50ms）更严重：BDP 达到 GB 级，反馈型拥塞控制完全跟不上。
UET 的 credit-based 流控在跨域场景有天然优势：预分配额度，发送前就知道接收端能吃多少，不需要等反馈循环。MRC 的包喷射可以把流量分散到大量路径上，降低单路径的 BDP 压力。更直接的方案是跨域带宽超配，DCI 链路预留余量，牺牲成本换稳定性。训练框架侧则可以把跨域通信从同步 AllReduce 改为流水线异步通信，降低对低延迟的依赖。
这个领域目前还在早期探索阶段，没有成熟的通用方案。
四条路线的对比总览
| 维度 | 传统 RoCEv2 | MRC | UET | InfiniBand |
|---|---|---|---|---|
| 路由 | ECMP 哈希（流级） | SRv6 源路由 + 包喷射（包级） | 交换机自适应路由 + 包喷射（包级） | SM 建表 + 硬件包级自适应调度 |
| 故障恢复 | 秒级（BGP 收敛） | 微秒级（NIC 退役 EV） | 毫秒级（ECN 驱动重路由） | 秒级（SM 重算路由表） |
| 流控 | PFC（无损，易风暴） | 禁用 PFC，允许丢包+重传 | Credit-based（不丢包不用 PFC） | Credit-based（原生无损） |
| 拥塞控制 | DCQCN（ECN→降速） | ECN→换路不降速 | UEC CC（Slingshot 血统） | 链路级 credit + 传输级 CC |
| Incast 缓解 | 调 ECN/PFC 阈值 | 包喷射分散 + trimming | 包喷射 + trimming | SHARP 在网计算 |
| 成熟度 | ★★★★★ | ★★★★（1 家生产验证） | ★★★（规范阶段） | ★★★★★（NVIDIA 全栈） |
| 10 万卡就绪 | ❌（天花板明显） | ✅（131K 实跑） | ⏳（12-18 个月后） | ⚠️（经济规模 ≤64K GPU） |
尚未解决的问题
以下几个问题目前没有好的答案：
-
集中式路径编排产品缺失。 MRC 的 SRv6 源路由需要一个全局控制器：知道拓扑、算路径、分配 uSID、故障后重算。OpenAI 自研了这套系统但没开源。市场上没有支持 10 万卡规模的 SRv6 路径编排器商用产品。
-
混合负载隔离。 10 万卡集群不太可能只跑一个训练 job。不同 job 的通信模式互相干扰怎么管理？目前方案的隔离手段都比较粗糙——VLAN/VXLAN 隔离、PFC 优先级隔离、物理 plane 隔离。精细的、包级别的 QoS 在 10 万卡规模下几乎做不到。
-
在网计算的标准化。 SHARP 在 IB 生态很成熟，但以太网生态的在网计算还没有标准化。UEC 定义了 INA 接口但落地不够。如果以太网交换机能原生做 reduce 运算，incast 压力可以直接降一个数量级。
-
跨域拥塞控制。 跨机房/跨城训练的拥塞控制没有成熟方案。MRC/UET/IB 都是为单机房内的低延迟网络设计的。跨域场景需要新的拥塞控制算法——可能需要结合 credit-based 和反馈型，或者引入预测型拥塞控制。
-
调试和可观测性。 10 万卡集群里出了尾延迟问题，怎么定位是哪条链路、哪个交换机、哪个 EV 在制造问题？传统网络诊断工具（sFlow、INT、mirroring）在 800G 线速下采样率不够，全量捕获不可行。MRC 的 256 条路径 × 数千个 QP = 数十万个监控维度，数据量远超人类可读。可观测性是工程落地的隐藏瓶颈。 NVIDIA 的 DOCA telemetry 框架和 SONiC 的 streaming telemetry 在这个方向上做了一些工作，但距离「给运维团队一个可操作的 dashboard」还很远。
判断
路由和拥塞不能分开讨论
这篇文章的八个挑战看起来很多，但背后只有一个核心矛盾：路由决定了流量的分布，拥塞是分布不均的后果。传统网络把路由和拥塞控制分成两个独立问题，交换机负责路由（ECMP/BGP），终端负责拥塞控制（DCQCN/PFC）。MRC 把它们合二为一：收到 ECN 不降速而是换路，把拥塞控制重新定义为路径选择问题。UET 用 credit-based 流控从源头避免拥塞，也绕开了传统拥塞控制的「先拥塞再反应」模式。2026-2028 年的 AI 网络的标志，就是路由和拥塞控制走向融合。
没有银弹，只有 trade-off
四条路线各有硬伤。RoCEv2 在 10 万卡规模天花板明显，但在 3-5 万卡以下仍然是性价比最高的选择。MRC 有生产验证但只有 OpenAI 一家，路径编排工具未产品化。UET 行业共识最广但还没经过大规模验证，软件迁移成本高。InfiniBand 全栈成熟但被 NVIDIA 独家锁定，经济规模天花板在 64K GPU 左右：超过这个规模，IB 交换机的 144 端口限制迫使拓扑加层，延迟和成本同步上升。以太网交换机 ASIC 总带宽已超过 IB（如 Broadcom Tomahawk 5 的 51.2T vs Quantum-X800 的 115.2T，但以太网有更多供应商竞争），成本下降更快。规模成本优势不仅来自端口数，更来自多供应商竞争和规模经济。
选择哪条路线，本质上是在赌「你觉得哪个约束最先被解除」。赌 MRC 就是赌 OpenAI 的工程能力可复制；赌 UET 就是赌行业标准的力量；赌 IB 就是赌 NVIDIA 的全栈整合优势能维持。
中国市场的特殊路径
中国厂商面临一个额外维度：NIC 芯片的自主可控。MRC 和 UET 都依赖美国 NIC 芯片（ConnectX-8 / Pollara / Thor Ultra），中国目前没有对标产品。华为灵衢从系统层（内核+服务层+云层）绕开 NIC 硬件限制，用软件定义的方式做自适应路由和拥塞控制。性能上限不如 MRC 的硬件包喷射，但在美国芯片限制下是现实路径。国产交换机芯片（盛科/华为/新华三）在容量上差一代，但 MRC 简化了交换机需求，反而降低了追赶门槛。中国路径很可能是交换机先行适配 MRC/UET 的开放协议，NIC 通过国产替代或合作逐步跟进。
时间线判断
- 2026 年下半年：MRC 在 OpenAI/Microsoft 之外开始有第二家大规模部署（可能 Google 或 Meta）。UET 互操作测试进入实质性阶段。
- 2027 年：UET 1.0 兼容 NIC 量产（AMD Pollara 400 领先），第一批非 OpenAI 的 UET 集群上线。以太网在网计算（INA）开始有原型。
- 2028 年：MRC v2 或 UET 2.0 规范发布，融合两者的优点。以太网在 10 万卡规模的市场份额超过 InfiniBand。
这个时间线有不确定性。可能加速的变量：NVIDIA 如果开放 SHARP 给以太网生态、UEC 互操作测试超预期、中国国产替代进度快于预期。可能延迟的变量：MRC 在 OpenAI 之外的部署遇到工程坑、UET 软件迁移成本比预期更高、NVIDIA 通过降价保住 IB 市场份额。但方向相对清晰：以太网在大规模 AI 训练中替代 IB 是大概率事件，区别只在快慢。
声明： 本文基于 OpenAI MRC 论文（arXiv 2605.04333）、OCP MRC 1.0 规范、UEC 1.0 规范、RFC 9800（SRv6 压缩段列表编码）、NVIDIA/AMD/Broadcom/HPE 厂商公开资料，以及已发布的 locsic.com MRC 协议深度分析、AI 网络协议全景分析、灵晟超算纯 CPU 架构分析等文章交叉验证后撰写。不构成投资建议。文中数据截至 2026 年 7 月 31 日。