OpenAI，这次又真·Open了一下。
刚刚，OpenAI通过OCP开放了超大规模AI训练时使用的网络协议——MRC。
这次开放的MRC，是实现微秒级故障恢复、能支持10万块以上GPU高效协作的底层通信协议。
核心奥义就是，在大规模的训练环境下，确保网络通信的稳定性。
而且这一波是和硬件厂商合作，在OpenAI的组织下，英伟达、AMD和英特尔都参与了这个项目。
有网友表示，把这些厂商聚在一起合作制定标准，简直比实现AGI还难以协调。
大规模集群，也要通讯稳定
这套MRC（Multipath Reliable Connection）协议，是OpenAI联合英伟达、AMD、英特尔、微软和博通，花了两年时间做出来的，上周通过Open Compute Project向全行业开放。
它现在跑在OpenAI所有*规模的NVIDIA GB200超算上，包括OCI在德克萨斯Abilene建的星际之门和微软的Fairwater超算。
这件事的背景是，同步预训练（synchronous pretraining）的通信模式对网络极度敏感。
十几万块GPU在每个训练step里以all-reduce为主要通信原语协同工作，单次迭代可触发数百万次点对点数据传输。
这类集合通信的完成时间由最慢的那次传输决定，任何链路拥塞或丢包都会以滚雪球的形式传导到整个job，轻则造成吞吐骤降，重则触发checkpoint回滚。
随着集群规模扩大，网络故障的*频率只会上升。
为了解决这个问题，MRC主要做了三件事。
*件是多平面网络拓扑（Multi-Plane Network）。
传统做法是把800Gb/s的网卡当一整条链路用，整个集群需要三四层交换机才能连起来。
MRC把它拆成8条100Gb/s子链路，各自连到独立的交换机，形成8个并行的网络平面。
单台交换机能接入的端口数因此扩大了8倍，拓扑也随之扁平，层数从三四层压到两层，13万块GPU的互联成本和故障点都随之大幅下降。
层数少还意味着故障点少，8个平面并行又意味着冗余路径大幅增加，这也是后面两项技术能够成立的物理基础。
第二件是自适应包喷射（Adaptive Packet Spraying）。
经典RoCE要求同一条RDMA传输的所有数据包走同一路径以维持顺序语义，这在多平面环境下会造成严重的流量碰撞和路径利用率不足。
MRC扩展了RoCE的乱序处理能力，在包头中嵌入目标内存地址，使接收端可以将乱序到达的包直接写入正确位置，从而允许将单次传输的包喷射到数百条路径上并行传输。
拥塞检测和路径切换则是在连接层完成，发现拥塞则换路，检测到丢包则立即停用该路径并触发重传，整个响应在微秒级完成。
这种模式可以理解为，原来一批货必须走同一辆车按顺序送达，MRC让这批货同时上几百辆车分头跑，每个箱子上贴好收货地址，到了直接入库，哪条路堵就换哪条。
集合通信对尾延迟极度敏感，这套机制几乎消除了网络核心的拥塞，直接压低了训练step完成时间的抖动。
第三件是用SRv6（IPv6 Segment Routing）静态源路由取代动态路由协议。
传统方案依赖BGP在交换机间动态计算和同步路由，链路故障时路由收敛需要数秒甚至更长，这段时间内训练流量会大面积中断。
SRv6将路径决策完全移到发送端，把逐跳的交换机标识符序列直接编码进数据包的目标地址，沿途每台交换机只需按本地静态路由表执行转发，无需感知任何拓扑变化。
还是拿物流来类比，这就相当于出发前就把完整路线写在包裹上，每个路口的工作人员只管照单操作，不需要和任何调度中心联系。
某条路径出现故障，MRC发送端直接停止在该路径喷包、切换到其他路径，交换机侧零感知、零动作，整类路由收敛引发的抖动从根本上被消除。
三层设计从拓扑、传输、路由三个维度同时发力，确保了大规模下的网络可靠性。
One More Thing
MRC技术博客公布之后，OpenAI还同步发布了一期播客。
这期播客中，OpenAI网络负责人Mark Handley和工作负载负责人Greg Steinbrecher聊了MRC从动机到落地的完整过程。
感兴趣的话，可以去听一听。
