摘要：当 AI 集群扩展到数万甚至十万张 GPU，真正拖慢训练的，未必是算力本身，而是连接这些 GPU 的网络。
过去两年，AI 基础设施的叙事几乎都围绕一个词展开：GPU。
谁买到了更多 H100、B200、GB200，谁就更有可能训练出下一代大模型；谁能锁定更多电力、数据中心和先进封装产能，谁就更接近 AI 时代的入场券。
但 OpenAI、英伟达、微软、AMD、博通和英特尔这次联合推出 MRC 协议，提醒行业看见另一个更隐蔽、更底层的问题：当 GPU 数量增长到几万、十几万甚至更高规模时，真正拖慢训练的不一定是算力本身，而是连接这些 GPU 的网络。
这也是很多人低估的一场战争。
GPU 之外，真正的瓶颈开始浮出水面
在小规模集群里，网络像水管，平时很少有人会把它当主角。但在超大规模 AI 工厂里，网络更像高速公路、城市路网和交通调度系统的总和。
一旦某条路拥堵、某个路口故障、某个交换机抖动，成千上万张 GPU 就可能一起等在那里。对于同步训练任务来说，最慢的一次通信，往往就会拖住整个训练步伐。
这就是 MRC 出现的背景。
MRC 全称是 Multipath Reliable Connection，多路径可靠连接。OpenAI 官方把它描述为一种新的超算网络协议，用来提升大规模 AI 训练集群中的 GPU 网络性能与可靠性。它建立在 RoCE，也就是 RDMA over Converged Ethernet 的基础上，并吸收 Ultra Ethernet 相关技术，同时结合 SRv6 源路由，让一次数据传输不再死守一条路径，而是可以被拆成大量数据包，分散到数百条路径上并发传输。[1]
这件事其实没那么玄
这听起来很技术，但本质并不难理解。
传统网络更像给一辆车规划一条路线。车从 A 点到 B 点，走哪条高速、哪座桥、哪个出口，路径基本确定。问题是，如果这条路堵了，或者中间某个节点出问题，车就会被卡住。
网络里的“车”就是数据流，“路”就是交换机和链路。
MRC 的思路是，不再让一个大数据流只走一条路，而是把它拆成许多包，像雨点一样“喷射”到多条路径上。哪个路径拥堵，就少走；哪个路径故障，就绕开；某些包晚到，也没关系，因为 MRC 数据包里带着最终要写入的内存地址，接收端可以把先到的数据先放到正确位置。
OpenAI 明确说，MRC 会把单次传输的数据包喷射到不同网络平面里的数百条路径上，并通过这种方式降低同步训练中的拥塞长尾。[1]
为什么这对大模型训练这么关键
因为今天的前沿模型训练，早就不是“单机跑程序”了，而是一个巨大的同步工程。
数据并行、张量并行、流水线并行、专家并行混在一起，GPU 之间要频繁交换梯度、激活值和参数片段。一次训练 step，往往要等所有相关 GPU 都完成通信后才能进入下一步。
只要少数连接变慢，整体训练就会被尾部延迟支配。
这也是 AI 超算和普通互联网服务最大的不同。网页慢一点，用户可能只是多等几百毫秒；推荐系统某个请求失败，可以重试或者降级；但一个跨越数万 GPU 的训练任务，如果网络反复抖动，就不是体验问题，而是百万美元级别的 GPU 时间浪费。
所以，MRC 的价值不只是“更快”，而是“更稳”。
它真正想解决的是“长尾”
OpenAI 和合作方在论文中把问题说得很直接：随着 AI 训练网络扩展到数十万 GPU，网络噪声、尾部延迟和故障会越来越难控制；解决方案必须做到三件事：均衡负载、处理拥塞、在链路和网络故障发生时不让训练任务中断。
更关键的是，MRC 已经不是实验室里的纸面协议。论文提到，它已在 OpenAI 和微软的大型训练集群中生产使用，用于训练 ChatGPT 和 Codex 相关的前沿大语言模型。[1]
这说明一个变化：AI 网络的竞争，已经从“有没有”进入“能不能稳定撑住”的阶段。
多平面网络，才是底层工程的关键一刀
MRC 背后还有一个重要设计：多平面网络（multi-plane network）。
过去，一个 800Gb/s 的网络接口往往被当成一条超宽高速链路。MRC 相关设计则可以把它拆成多个较小链路，例如八条 100Gb/s 链路，连接到不同交换机，形成多个独立网络平面。
这样做的好处很直接：冗余更强，路径更多，故障影响更小。某条链路坏了，不等于整块网卡或整台机器立刻失去通信能力，训练任务仍然可能继续跑下去。
这有点像把一条超宽但脆弱的主干道，改造成一张更细、更密、更有弹性的城市路网。单条路看起来没那么夸张，但整体更抗堵、更抗事故，也更容易调度。
从“交换机决定”到“端侧主动绕行”
更有意思的是，MRC 还改变了传统数据中心网络对动态路由的依赖。
在传统网络里，交换机会运行 BGP 等动态路由协议，判断路径、发现故障、重新收敛。但在超大 AI 集群中，交换机数量巨大，软件复杂度也巨大，一旦动态路由和端侧自适应机制相互影响，问题会变得非常难诊断。
OpenAI 的做法相当大胆：用 SRv6 源路由，让发送端直接指定数据包路径；如果某条路径发生丢包或异常，MRC 自己停止使用这条路径，而不是等待整个网络重新计算路由。[1]
这意味着，AI 网络正在从“交换机中心化调度”，转向“端侧协议主动感知和绕行”。
如果把 GPU 看作 AI 工厂里的工人，把网络看作传送带，那么过去的问题是：传送带一堵，所有工人停工；现在 MRC 想做的是，让每个数据包都知道可以换哪条传送带，并且在微秒级别绕过坏掉的那一段。
英伟达为什么这么积极
英伟达对此非常积极。NVIDIA 官方博客称，MRC 是一种 RDMA 传输协议，可以让单个 RDMA 连接把流量分布到多条网络路径上，提高吞吐、负载均衡和可用性；MRC 已经在 Spectrum-X Ethernet 硬件上优化，并作为 OCP 开放规范发布。[2]
英伟达还强调，MRC 部署在 Spectrum-X 上后，可以在微秒级检测路径故障并自动绕行，这对需要数千甚至更多 GPU 同步运行的训练集群尤其关键。[2]
这说明一个趋势：以太网正在加速进入 AI 后端网络核心区。
过去，高性能计算和 AI 训练集群长期依赖 InfiniBand，因为它低延迟、高吞吐、生态成熟。但随着云厂商、芯片厂商和大模型公司都在追求更开放、更可组合、更低成本的大规模部署，以太网阵营一直在努力补上“高性能训练网络”这块短板。
MRC 的出现，不等于 InfiniBand 会被立刻取代，但它确实强化了一个方向：未来 AI 工厂不会只拼 GPU，也会拼网络协议、网卡、交换机、拓扑设计和故障恢复能力。
这次合作阵容，说明行业已经进入“共同修路”阶段
更值得关注的是，这次合作阵容非常特殊。
OpenAI 是模型和训练任务的需求方，微软和 Oracle 是超算和云基础设施承载方，英伟达、AMD、博通、英特尔则覆盖 GPU、NIC、交换芯片和网络硬件生态。
它们愿意把 MRC 作为 OCP 规范发布，说明大模型基础设施已经进入“共同修路”的阶段。单家公司可以拥有自己的模型、数据和训练策略，但如果底层网络碎片化严重，整个行业的扩展效率都会下降。
这也是 OCP 的意义所在。OCP 规范文件显示，MRC 是由 AMD、Broadcom、Intel、Microsoft、NVIDIA、OpenAI 共同贡献的开放规范，目标是在标准以太网和现有软件接口之上，为 AI/ML 系统提供显式多路径、拥塞控制、路径健康跟踪和故障恢复能力。[3]
这不是普通企业马上能用的“网络优化技巧”
当然，MRC 不应该被理解成“普通企业明天就能拿来让自己的局域网变快”。
它面向的是极大规模 AI 训练网络，尤其是成千上万甚至十万级 GPU 集群。对大多数企业而言，它短期内更像一个风向标：AI 基础设施竞争正在从“买多少卡”进入“能否把卡高效组织起来”的阶段。
这背后其实是 AI 产业的一次重心转移。
第一阶段，大家比模型参数、训练数据和算法技巧。
第二阶段，大家比 GPU 采购能力、电力、数据中心和资本开支。
第三阶段，竞争开始深入到系统工程：网络、存储、调度、容错、冷却、电力稳定性、芯片互连、软件栈协同。
MRC 代表的正是第三阶段。
AI 公司越来越像新型工业企业
未来的大模型公司，越来越像一种新型工业企业。它们不只是写代码、训模型，而是在运营一种超级复杂的 AI 工厂。
这个工厂里，GPU 是机器，数据是原料，电力是能源，网络则是生产线。如果生产线不稳定，再贵的机器也会空转。
所以，MRC 的真正信号不是“又出了一个网络协议”，而是：AI 基础设施已经卷到最底层了。
从今天开始，判断一家 AI 公司的基础设施能力，不能只看它有多少 GPU，也要看它能否让这些 GPU 长时间、高利用率、低故障地协同工作。
模型能力的差距，表面上体现在 benchmark 上；但更深层的差距，可能藏在网卡、交换机、协议栈和训练任务不中断的能力里。
大模型时代最昂贵的资源，不只是算力，而是被稳定组织起来的算力。
MRC 之所以重要，就在于它试图回答一个越来越现实的问题：当 AI 工厂扩展到十万 GPU 级别，如何让每一块昂贵的 GPU 少等待、少空转、少被网络故障拖住？
这不是一条新闻里的技术细节，而是 AI 基建战争进入深水区的标志。未来的赢家，可能不只是模型做得最好的人，也是最懂得如何修路、管路、绕路的人。