MRC协议开源：两层交换机如何连起13万块GPU
OpenAI联合NVIDIA、AMD、微软、Broadcom和Intel正式开源MRC协议，通过多平面网络、自适应包喷射和SRv6源路由三大机制，仅需两层交换机即可扩展至约13.1万块GPU，重构超大规模AI集群的网络架构。
MRC协议开源：两层交换机如何连起13万块GPU
参考阅读：
引言
OpenAI联合NVIDIA、AMD、微软、Broadcom和Intel，通过Open Compute Project（OCP）正式开源Multipath Reliable Connection（MRC）协议。
对于大多数网络工程师而言，协议开源并不罕见。但MRC受到行业广泛关注的原因在于，它并非针对某个网络功能进行优化，而是试图重新设计超大规模AI集群的网络架构。
根据OpenAI公开的数据，MRC已经部署在其最大规模的GB200超级计算机集群中，并支撑超过10万GPU规模的训练任务。在公开的参考架构中，两层交换网络即可扩展至约13.1万块GPU，而传统RoCE网络通常需要三层甚至四层Clos架构才能达到类似规模。
那么，MRC究竟解决了什么问题？又是如何实现如此大规模扩展能力的？
What Is MRC (Multipath Reliable Connection)?
MRC协议，全称 Multipath Reliable Connection（多路径可靠连接），是专为大规模AI训练集群设计的超算网络协议。
MRC协议不是凭空发明的全新技术。它以 RoCE（RDMA over Converged Ethernet）为基础扩展而来，融合了超以太网联盟（UEC）的部分设计思路，并引入 SRv6 源路由机制。这意味着：已有的RDMA编程模型可以无缝迁移，不需要重写上层代码。
一句话理解MRC协议：把原来一条800Gb/s的网络高速公路，拆成8条100Gb/s的并行车道，配上实时导航——数据自动绕开故障和拥堵，整体更快、更稳、造价更低。
为什么需要MRC？
大模型训练采用同步预训练模式：所有GPU在每个训练步骤必须同步完成数据传输，才能进入下一步。任意一次传输延迟，整个集群所有GPU必须原地等待。
OpenAI实测数据显示，Tier-0与Tier-1交换机之间每分钟都会出现多次链路抖动。传统BGP路由收敛需要数秒到数十秒，期间训练中断等待。GPT-4级别模型单次训练耗电约2.4亿度，每一次非计划中断，正在消耗的算力和电力直接清零。
问题的根源在于传统网络架构本身：组建十万卡级集群需要3到4层交换机，每多一层成本和故障点同步叠加；BGP路径重算秒级起步，故障期间所有传输挂起；传统RoCE协议要求每条数据流绑定固定路径，导致多平面网络中流量集中在同一条链路，其他平面带宽大量空闲。
MRC协议的三个核心机制，分别针对这三个问题设计。
MRC如何实现两层交换机连接13万GPU？
MRC能够支撑超大规模集群，并非依赖单一技术，而是多个机制协同工作的结果。
多平面网络
传统 AI 网络通常将每个 800Gb/s 接口视为一条独立链路使用。而在 MRC 架构中，一个 800Gb/s 网络接口会被拆分为多个更小的连接单元。例如，将其划分为 8 条 100Gb/s 链路，并分别连接到 8 台不同的交换机，从而构建出 8 个相互独立且并行运行的网络平面。
这一改变对交换机端口数的影响是直接的：以 51.2Tbps 交换机为例，在传统模式下可提供 64 个 800G 端口；当端口被拆分为 100G 后，同一台交换机能够支持多达 512 个连接。
借助这种架构，仅通过两层交换机即可构建覆盖约 13.1 万块 GPU 的全互联网络，而传统 800G 网络通常需要三层甚至四层交换架构才能达到相近规模。
多平面网络只是提供了更多可用路径，如何充分利用这些路径，还需要第二个机制配合。
自适应包喷射
即使拥有更多路径，传统RoCE协议依然会将单个数据流固定在某一条路径上。结果是部分链路持续拥塞，而其他链路仍然处于空闲状态。
MRC对此进行了调整。MRC会将一次传输中的数据包分散到数百条路径并行发送，同时跨越全部8个网络平面，并允许数据包乱序到达。
乱序到达如何处理？答案是每个MRC数据包都携带目标内存地址。接收端收到数据包后，直接按照地址写入对应内存位置，无需等待前序数据包到达，也不需要额外排序缓冲区。
路径状态管理主要分为三个层次：
-
**拥塞切换：**每条MRC连接都会维护路径状态信息。当系统检测到某条路径出现拥塞时，流量会自动切换到其他可用路径，使负载在不同路径之间保持均衡。
-
**丢包停用：**如果检测到丢包，系统会立即暂停使用对应路径，同时发起重传，并通过探测包持续检测该路径是否恢复正常。
-
**包裁剪（Packet Trimming）：**当交换机因为拥塞需要丢弃数据包时，不直接丢弃整个数据包，而是保留包头并转发给目标端，由目标端主动发起重传请求。
包裁剪解决了一个关键问题：拥塞引起的丢包不该触发路径停用，路径故障才该触发。没有这个机制，拥塞会被误判为路径故障，健康路径被错误停用，反而加剧拥塞。
多平面 + 包喷射 + 负载均衡 + 包裁剪协同运作，网络核心拥塞接近消除，故障检测和流量切换在微秒级完成。
SRv6源路由
前两个机制解决了路径利用率和拥塞问题，但路径失效后的路由收敛问题依然存在。
对此，MRC采用了另一种思路：不再依赖BGP动态路由，而是使用SRv6（IPv6 Segment Routing）源路由机制。路径决策由发送端完成，而不是由交换机动态计算。
转发过程如下：
- 发送端将完整路径写入数据包头部
- 每台交换机收到数据包后检查自身标识
- 若匹配，则移除当前标识并暴露下一跳信息
- 按静态转发表完成转发
这些静态转发表在网络部署时完成配置，运行期间无需动态更新。当某条路径失效时，MRC只需停止使用该路径并切换至其他路径，无需等待整个网络完成路由收敛。因此，故障恢复时间从传统网络的秒级缩短到微秒级。
SRv6还带来了另一个重要变化：交换机承担的控制面功能明显减少，更多专注于数据转发本身，网络行为也变得更容易预测和维护。
OpenAI公布的生产环境数据显示，在训练某个前沿模型期间，运维团队曾重启4台Tier-1交换机。在传统架构下，这类操作往往需要提前协调训练团队。而在MRC环境中，相关训练任务几乎未受到明显影响。
MRC会对AI网络产业产生哪些影响？
市场最初普遍认为，MRC会进一步推动高端交换芯片需求增长。但从MRC的设计逻辑来看，它优化的重点并不是继续堆叠更高规格的网络设备，而是通过更多并行链路和更简单的网络层级实现网络扩展。因此，MRC带来的影响更多体现在网络建设方式和硬件需求结构的变化上。
光模块：需求直接翻倍
800Gb/s接口拆分为8×100Gb/s链路后，同样规模网络所需光模块数量显著增加。以13万GPU规模网络为例，光模块数量预计将从约1.2万只增加至约2.4万只左右。与此同时，100G速率模块的重要性也将同步提升。由于多平面网络需要更多光纤连接，MPO连接器需求也可能随之增长。
交换芯片：数量增加，规格要求下降
支撑13.1万GPU规模的8平面网络大约需要6144颗交换芯片。虽然交换芯片总量增加，但所需规格却从102.4T级别下降至25.6T和51.2T级别。这意味着未来超大规模AI网络的扩展，不再完全依赖最高规格交换芯片，而是可以通过更多中等规格交换芯片实现网络扩容。
以太网生态的重要性提升
长期以来，InfiniBand凭借成熟的软件栈和高性能网络能力，在超大规模AI训练集群中占据重要地位。MRC基于RoCE和以太网生态构建，并通过OCP向行业开源，协议实现完全公开，不依赖特定硬件平台。
三个值得关注的不确定性
第一：MRC能否成为行业通用标准。
目前所有生产验证数据来自OpenAI。其他超大规模云厂商尚未公开跟进。若主要厂商选择UEC原生方案或其他路线，MRC的实际覆盖范围将远小于"行业标准"，上述需求变化的规模也会随之收窄。
第二：51.2T交换芯片的供应能否跟上需求。
当前主流51.2T交换芯片Broadcom Tomahawk 5交货周期高达70-80周，供需严重失衡。若供应端持续紧张，MRC架构的大规模部署将受到硬件交付周期制约。对于正在评估MRC部署方案的团队，Tomahawk 5的替代选型方案值得提前关注。
第三：InfiniBand生态仍具备较强竞争力。
MRC解决的问题并非InfiniBand无法解决的问题。未来英伟达完全有可能在下一代InfiniBand产品中引入类似机制，并结合自身软硬件生态进一步优化。对于已经大量投入IB生态的用户而言，继续升级现有体系仍然是一个现实选择。
结论
MRC协议改变的不是某一个技术参数，而是AI超算组网的基础逻辑：从"用更贵的交换芯片堆出更多层级"，变成"用更多中速链路构建更少层级"。三个核心机制——多平面网络、自适应包喷射、SRv6源路由——分别解决了层级成本、带宽利用率、故障恢复这三个长期并存的问题，且三者协同，缺一不可。