MRC协议如何改变大规模AI训练的网络瓶颈?

2 参与者

MRC协议如何改变大规模AI训练的网络瓶颈?

OpenAI 联合 AMD、Broadcom、Intel、Microsoft、NVIDIA 等巨头,通过 Open Compute Project 开源了专为大规模 AI 训练设计的网络协议 MRC(Multipath Reliable Connection)。这不是一次模型发布,而是一次对底层网络架构的“外科手术”--直击当前超大规模训练的核心痛点。


🚧 为什么网络才是大规模训练的真正瓶颈?

我们总在讨论“多少参数”“多少GPU”“算力多强”,但现实是:

当数万甚至十几万张 GPU 协同训练时,网络成了最拖后腿的一环。

  • 每一步训练都需要所有 GPU 同步交换海量梯度数据;
  • 哪怕一次微秒级丢包或延迟波动,整个集群就得“等所有人齐”才能继续;
  • 传统网络协议在极端规模下故障恢复慢(秒级),导致训练中断或性能骤降;
  • GPU 明明满配,却常因网络卡壳而“干等”--利用率上不去,成本下不来。

OpenAI 作为全球顶级 AI 基础设施使用者,显然是被这个问题反复“教育”过。


🔧 MRC 的核心创新:把“单行道”变成“立体交通网”

MRC 的设计哲学很清晰:不依赖传统网络的复杂控制,而是从物理层到协议层全面重构路径管理。

✅ 1. 多平面网络(Multi-Plane Fabric)

  • 将一块 800Gb/s 网卡拆分为多个低速率链路(如 8×100Gb/s);
  • 构建多个并行、独立的数据平面;
  • 实现天然冗余 + 更浅的交换层级 → 支持十万级 GPU 直连;
  • 同时降低功耗、成本和故障域。

✅ 2. 自适应数据包喷洒(Adaptive Packet Spraying)

  • 打破 TCP 单路径限制:一个数据流被拆成多个包,同时走数百条不同路径
  • 接收端按内存地址直接重组,无需等待顺序;
  • 遇拥塞自动绕行,避免“堵车传染”;
  • 引入“数据包修剪”机制:仅转发包头触发重传,防止小拥塞被误判为链路失效。

✅ 3. 源路由 + SRv6(Source Routing)

  • 抛弃 BGP 等动态路由协议,发送端直接指定完整路径写入数据包;
  • 交换机只需查静态表转发,控制平面极度简化;
  • 故障恢复从 秒级 → 微秒级:链路断了?下一条路径立刻顶上,几乎无感知。

📈 实际效果:训练更稳、更快、更省

OpenAI 已在最大规模的 GB200 超算集群(包括与 Oracle、Microsoft 合作的站点)全面部署 MRC:

  • 即使每分钟发生多次链路抖动,训练作业几乎不受影响;
  • 支持热重启交换机或维护链路,无需暂停训练;
  • 单条链路或 GPU 网卡故障?作业继续运行,仅带宽轻微下降,性能损失远小于容量损失
  • GPU 利用率显著提升 → 训练时间缩短 + 电费降低;
  • 多租户环境下,作业间干扰大幅减少,资源隔离性增强。

🌐 为什么选择开源?

MRC 不是闭源私有协议,而是通过 Open Compute Project (OCP) 完全开源。这意味着:

  • 任何企业、研究机构都可以基于此构建自己的超大规模训练网络;
  • 推动行业标准化,避免“每家都造轮子”;
  • 加速 AI 基础设施的民主化--小团队也能享受接近 OpenAI 级别的网络可靠性。

这不仅是 OpenAI 的“自用工具”,更是对 AI 算力生态的一次基础设施级贡献。


💡 总结:MRC 重新定义了“可靠”在大规模训练中的含义

它不再追求“零故障”,而是在故障常态化的前提下,实现近乎无感的容错与恢复。 通过多路径、源路由、智能调度三位一体的设计,MRC 让网络从“训练瓶颈”转变为“透明支撑层”。

未来,随着模型规模继续膨胀,MRC 这类底层协议创新,或许比新模型架构更值得关注。

📌 AI 的下一场竞赛,可能不在算法,而在网络。


原创文章,更多AI科技内容,微信搜索“橙市播客”小程序

加入讨论

2 条评论

延伸阅读