跳到主要内容

MRC

RoCEv2 RC 的多路径扩展如何在 100K GPU 规模生产运行

核心要点：

  • InfiniBand RC transport 的多路径扩展，per-packet spraying + OOO 直写内存
  • NIC 端用 Entropy Value 编程路径（128-256 EV/QP），交换机仅按 SRv6 uSID 转发
  • SACK + Packet Trimming + ECN 换路（不降速）配套乱序 + 拥塞响应
  • OpenAI Stargate / Microsoft Fairwater 上 75K+ / 100K+ GPU 规模生产运行

MRC（Multipath Reliable Connection）是 OpenAI 联合 AMD / Broadcom / Intel / Microsoft / NVIDIA 2026 年 5 月发布的 transport 层协议[1][2]，定位为 RoCEv2 RC 的多路径超集，已贡献给 OCP 并以 BSD-2-Clause 开源[3]。在 OpenAI Stargate 和 Microsoft Fairwater 集群上以 75K+ GPU 规模生产运行。

前置阅读：

MRC 在 RoCEv2 / UET 谱系中的定位是什么？​

核心问题：MRC 是要取代 RoCEv2 还是 UEC？它在协议栈中处于什么位置？

MRC 是 InfiniBand Reliable Connection (RC) transport 的多路径扩展[2]，保留 Verbs API 和 Queue Pair 抽象，应用层无需感知。但只支持 RDMA WRITE 和 WRITE_WITH_IMMEDIATE——READ / SEND / ATOMIC 的严格有序语义与 per-packet 乱序天然冲突。

MRC 与 Ultra Ethernet Consortium 的 UET 走了不同路线：

维度MRCUET / UEC 1.0
设计出发点最小化扩展 RoCEv2"从零开始"的新 Ethernet 协议栈
Spec 体量简洁（OCP 1.0 单文档）数百页（UEC 1.0 RC1）
部署状态已在 100K+ GPU 集群生产运行标准制定中，硬件生态跟进
发布渠道OCP（部署导向）UEC（标准导向）
硬件要求现有 ConnectX-8 / Pollara / Thor Ultra需 UEC 合规新硬件

@tbl-route-mrc-vs-uet MRC 与 UET 的设计路线对比

论文原话："Unlike UET, MRC is a minimal extension to RoCE."[1]

MRC 如何在 NIC 端把一条 QP 散布到几百条路径上？​

核心问题：传统 RoCEv2 一条 QP 哈希绑定一条路径，MRC 怎么做到 packet 级的路径分散？

MRC 的多路径能力建立在五个相互配合的机制上：Entropy Value 路径编程 + OOO 直写内存 + Selective ACK + Packet Trimming + ECN 路径回避。

Entropy Value（EV）：NIC 端路径编程​

MRC 不靠交换机的五元组哈希做多路径，而是在 NIC 端主动控制[1][4]：

  • 每个 QP 在建立时分配 128-256 个 EV（32-bit 值）
  • 每个 EV 编码一条具体路径（含所在 plane）
  • 发送端逐包轮转 EV：连续包使用不同 EV，因此走不同物理路径
  • 32-bit EV 跨 UDP 源端口（16-bit）+ IPv6 flow label（20-bit） 两个字段条带分配，触发交换机的 ECMP 哈希散布

关键差异：传统 RoCEv2 一条 QP 绑定一条路径，MRC 一条 QP 可以主动散布到几百条路径上，且散布粒度是 packet 级而非 flow / flowlet 级。

Out-of-Order 直写内存​

接收端不需要 reorder buffer[1]：每个 data packet 头部携带完整的 RDMA virtual address 和 remote key，接收 NIC 收到就直接 DMA 到目标地址，无需排序、无需暂存。这是 MRC 相对传统 RoCEv2 的根本突破——把"乱序到达"从问题变成非问题。

代价：每个 packet 头部多 20+ bytes，对小消息开销可观；接收端的 DMA 引擎需要支持 scatter-gather 到任意地址。

Selective ACK​

使用 SACK 精确指示哪些 packet 收到了，只重传实际丢失的包，不触发 go-back-N。这与 per-packet spraying 是配对设计——包乱序到达是常态，cumulative ACK 会把"晚到"误判为"丢失"。

Packet Trimming：拥塞快速 NACK​

交换机拥塞时不丢整包，而是丢 payload、保留 header，并以高优先级把 trimmed header 转发到接收端。接收端识别 trim 标记后立即回 NACK。

这让发送端能区分两种情况：

  • 收到 trim NACK → 拥塞 → 暂时回避该 EV，不退休
  • 完全无响应（SACK 超时） → 链路故障 → 立即退休 EV，启动 probe 探测路径恢复

ECN：从"降速信号"改为"换路信号"​

传统 RoCEv2 收到 ECN 标记后降速（DCQCN 等）。MRC 把语义改了：接收端 echo ECN 时携带触发拥塞的具体 EV，发送端把该 EV 从活跃集合中移除——不降速，换路径。

既然有几百条路径可选，遇到拥塞的最优反应是绕开而不是慢下来。

SRv6 uSID 如何把路径压进 IPv6 目的地址？​

核心问题：标准 SRv6 SRH 每跳 16 字节，对 RDMA 小消息开销显著。MRC 怎么进一步压缩？

MRC 用 SRv6 micro-segment ID（uSID）格式编码路径，但不用独立的 SRH extension header——路径直接嵌入 IPv6 目的地址字段[1]：32-bit locator prefix + 6 × 16-bit uSID（每个对应路径上一台交换机）。

这比 3.12 SRv6 描述的标准 SRH 省 8 字节开销，但路径长度受限于 128 bit 地址字段（最多 6 跳）。超大规模部署时回退到完整 SRH 编码可额外编码 6 跳[5]。

NIC 根据当前 EV 查 uSID 映射表，生成完整路径的 IPv6 目的地址。交换机只按 IPv6 目的地址的 active uSID 段做转发，控制平面退化为静态：

维度传统 ECMPMRC + SRv6 uSID
路由决策每跳交换机哈希NIC 入口编程完整路径
控制平面BGP/OSPF 动态收敛完全禁用动态路由协议
路径确定性概率性（哈希碰撞）确定性（uSID 精确指定）
故障响应等待控制平面收敛（秒级）NIC 端微秒级 EV 退休
交换机复杂度标准 ECMP ASIC需支持 SRv6 uSID 转发

@tbl-route-mrc-vs-ecmp MRC 源路由与传统 ECMP 的对比

设计哲学："eliminates the entire Layer 3 control plane from the data center fabric"[4]——交换机只按静态转发表执行，所有路径智能集中在 NIC 和离线控制面。

故障切换时间整体在 tens of microseconds，相比传统 BGP/OSPF 收敛的 1-30 秒快约 10,000-3,000,000 倍（按 10 µs vs 30 s 上限至 100 µs vs 1 s 下限测算）。

多平面拓扑为什么是 MRC 的必要前提？​

核心问题：MRC 的 EV 编程靠多条物理独立路径生效，多平面拓扑提供这一基础。生产部署用几个 plane？

Microsoft Fairwater 公开的部署配置[6]："Our network design splits each NIC into multiple lower speed ports (i.e. eight x 100 Gbps) and builds multiple parallel network planes."

论文给出两种典型配置[1]：

  • 4 plane × 200 Gb/s = 800 Gb/s 总带宽
  • 8 plane × 100 Gb/s = 800 Gb/s 总带宽（Fairwater 选用）

每个 plane 连接到不同的 T0（ToR）交换机，平面之间物理独立——这是 MRC 的故障隔离基础。

故障爆炸半径​

配置单链路故障损失
单链路 800G100% NIC 带宽
4 plane × 200G25%（1/4）
8 plane × 100G12.5%（1/8）

@tbl-route-mrc-blast-radius 多平面配置下单链路故障的爆炸半径

8 plane 是 MRC 在生产环境的实际选择——故障粒度细，配合微秒级 EV 退休，单链路故障对训练任务几乎透明。

与传统单平面 RoCE 的拓扑对比​

指标传统 3 层 RoCE（800G 单链路）MRC 2 层多平面（8×100G）
最大 GPU 数65,536131,072
交换机数5,1206,144（+20%）
最大跳数5-73
总链路数196,6081,179,648（约 6×）
光模块数基准约 6×

@tbl-route-mrc-topo-compare MRC 多平面 vs 传统单平面 RoCE 拓扑指标[7][4]

MRC 在生产中的实际表现？​

核心问题：75K+ GPU 集群、96% 线速、微秒级故障恢复——这些数字在哪些场景下验证过？

集群规模​

  • OpenAI Stargate（Oracle Abilene, Texas）：已部署 MRC，规模见 75,000 GPU 生产预训练任务
  • Microsoft Fairwater（Wisconsin）：8×100G multiplane，规模 100K+ GPU
  • 用于训练 OpenAI 的最新前沿模型（注意 MRC 2026 年 5 月发布，2022 年 ChatGPT 初代和 2021 年 Codex 初代均未使用 MRC 网络）

论文明确记录的两个生产任务规模[1]：

  • 50,000 GPU 预训练任务（用于 transceiver 故障测试）
  • 75,000 GPU 预训练任务（用于 switch reboot / link flap 测试）

性能指标​

  • 96% 线速利用率：800G 链路实测约 770 Gb/s goodput
  • 启动收敛：约 2 分钟内收敛到 < 1 包/秒/NIC 丢包率（约 2500 万包丢 1 个）
  • NCCL sendrecv（42,020 GPU 规模）：大消息达 92 GB/s（约 92% 理论峰值）

故障恢复案例​

75K GPU 集群记录的三类故障[1][7]：

  1. Switch reboot：4 次 T1 重启，最大一次影响约 25% QPs，约 580,000 包丢失，吞吐快速恢复，任务未中断
  2. Link flap：T0-T1 链路持续抖动，"almost no impact on the job, MRC swapped EVs onto unaffected paths"
  3. Transceiver glitch（50K GPU）：吞吐下降约 25%，约 1 分钟恢复，任务未中断

对比基线​

论文承认没有同规模 RoCEv2 集群作直接 A/B 对比，仅给出小规模对比[1]：

  • 64 GPU AMD Pollara 400G AllReduce：单 MRC QP（spraying 256 路径）优于 16 RoCEv2 QP
  • 0.1% 丢包率：MRC 保持正常性能，RoCEv2 性能严重下降
  • 1% 丢包率：MRC 吞吐降至约理论值的 1/3（论文自述的性能断崖）

MRC 与 RoCEv2 / Spectrum-X 的根本差异在哪？​

维度传统 RoCEv2 + ECMPSpectrum-X 自适应路由MRC
路径粒度流（5 元组哈希）flowlet / packet（交换机本地决策）packet（NIC 端 EV 轮转）
路径决策位置交换机每跳哈希交换机实时队列感知NIC 端源路由（EV 编码进包头）
乱序处理不允许需 reorder bufferOOO 直写内存
拥塞响应PFC 暂停AR 实时绕路ECN 路径回避（不降速）
PFC依赖部分依赖完全禁用

@tbl-route-mrc-vs-spectrum MRC 与传统 RoCEv2 / Spectrum-X 的路径管理对比[8]

关键差异：Spectrum-X 的 packet spraying 决策在交换机侧（需要专门 ASIC），MRC 的 spraying 决策在 NIC 端（标准 ECMP ASIC 也能转发）。这让 MRC 不依赖特定交换机硬件，部署门槛低。

MRC 的隐性代价和未解问题是什么？​

per-packet spraying 的乱序代价​

MRC 通过 OOO 直写内存绕过传统 reorder buffer，但乱序本身仍有隐性代价：

  • 每包 20+ bytes header 开销：小消息（< 256 byte）的 goodput 显著低于理论峰值。论文承认 MRC 不适合推理场景（"jitter-sensitive small messages"）
  • 1% 丢包性能断崖：论文自述"even MRC only gets around a third of the intended throughput at 1% loss"
  • DMA 引擎要求：接收 NIC 必须支持任意地址 scatter-gather DMA，老一代 NIC 无法软件升级

multipath transport 的根本权衡：追求路径多样性 vs 接受乱序代价。MRC 选择前者并把代价压到最低，但代价不为零。

与 RoCEv2 的迁移路径​

MRC 作为 RoCEv2 RC 的扩展而非替换的好处：

  • Verbs API 不变：NCCL / libfabric / UCX 等无需重写
  • 硬件兼容：ConnectX-8 / AMD Pollara / Broadcom Thor Ultra 都已支持
  • 渐进迁移：同一集群可 MRC QP 与 RoCEv2 QP 共存

但仅 WRITE / WRITE_WITH_IMMEDIATE 的约束意味着 READ-heavy workload（KV cache 跨节点查询）无法直接受益。需要应用层调整为"sender pushes, receiver does not pull"模式——这对 LLM 训练影响小，对推理影响大。这部分解释了为什么 MRC 优先用于训练。

独立验证缺口​

最大的开放问题：所有公开生产数据都来自 MRC 合作方（OpenAI、Microsoft、AMD、Broadcom、NVIDIA、Intel）。第三方独立复现 100K GPU 规模 + 96% 线速 + 微秒级故障恢复的数据目前没有。

唯一已知的对照是 AWS SRD（Scalable Reliable Datagram），技术上与 MRC 高度重合（per-packet spraying / OOO delivery / fast retransmit / multipath），且在 AWS 规模运行多年——但 SRD 不开源、不发表论文、不参与 OCP。

当一个 non-partner organization 在 10K+ GPU 上独立部署 MRC 并复现性能，MRC 才算真正完成从"OpenAI 内部协议"到"行业开放标准"的跨越。

Takeaway​

知识点核心结论
协议定位RoCEv2 RC 的多路径扩展，仅 WRITE / WRITE_WITH_IMMEDIATE
EV 机制128-256 EV/QP，跨 UDP 源端口 + IPv6 flow label 触发 ECMP
OOO 直写每包携带 RDMA addr + rkey，无 reorder buffer，每包 20+ B 开销
拥塞响应ECN 标记 EV，发送端换路而非降速
故障检测Packet Trimming（拥塞 NACK）+ SACK 超时（故障 NACK）
路径编码SRv6 uSID 嵌入 IPv6 目的地址（6 跳）；大规模回退 SRH
多平面8 plane × 100G，单链路故障爆炸半径 1/8
生产规模OpenAI 75K GPU / Microsoft Fairwater 100K+ GPU，96% 线速
vs UET现有硬件可跑 vs 新 Ethernet 栈，预期长期共存

参考资料​

  1. Multipath Reliable Connection: A Production-Ready Transport for AI Networking at Scale, arXiv:2605.04333, OpenAI / AMD / Broadcom / Intel / Microsoft / NVIDIA, 2026. https://arxiv.org/html/2605.04333v1
  2. Open Compute Project, MRC 1.0 Specification, 2026. https://www.opencompute.org/documents/ocp-mrc-1-0-pdf
  3. OCP-Multipath-Reliable-Connection, GitHub. https://github.com/opencomputeproject/OCP-Multipath-Reliable-Connection
  4. The Counterintuitive Networking Decisions Behind OpenAI's 131,000 GPU Training Fabric, Towards Data Science. https://towardsdatascience.com/the-counterintuitive-networking-decisions-behind-openais-131000-gpu-training-fabric/
  5. Broadcom, Enabling AI Networking at Scale with Multi-path Reliable Connections (MRC). https://www.broadcom.com/blog/enabling-ai-networking-scale-with-multi-path-reliable-connections-mrc
  6. Microsoft Tech Community, Building resilient networks for AI supercomputers, 2026. https://techcommunity.microsoft.com/blog/azurehighperformancecomputingblog/building-resilient-networks-for-ai-supercomputers/4516919
  7. MRC, Ultra Ethernet, Microsoft OpenAI 75K GPU 800G, supercomputing.news. https://www.supercomputing.news/ai/mrc-ultra-ethernet-microsoft-openai-75k-gpu-800g
  8. NVIDIA, Spectrum-X Ethernet integrates MRC. https://blogs.nvidia.com/blog/spectrum-x-ethernet-mrc/

延伸阅读​