OpenAI、AMD、Broadcom、Intel、Microsoft、NVIDIA 组成的财团,通过 Open Compute Project 于 5 月 5 日公开 MRC——Multipath Reliable Connection——配套论文(Araujo et al., arXiv:2605.04333)详述其在 OpenAI 最大的 GB200 超算上的部署,包括与 Oracle Cloud Infrastructure 合作、位于德州 Abilene 的 Stargate 站点,以及 Microsoft 的 Fairwater。MRC 是最近 ChatGPT 与 Codex 前沿模型训练 run 背后的网络层,Gokul Chandra Purnachandra Reddy 在 Towards Data Science 上的深读把媒体覆盖漏掉的承重观察拎出来了:MRC 实际上把 Layer 3 控制平面从数据中心 fabric 中完全清除了。没有 OSPF、没有 BGP、没有 IS-IS、没有 FIB;交换机维护零动态转发状态。在 Reddy 知识范围内,这是迄今为止任何已公开记录的生产级 AI 训练 fabric 中,对动态路由最激进的剔除。
五个反直觉的设计决策,每一个单独看都不陌生,组合在一起却是激进:(1) 把 800 Gb/s NIC 拆成 8 条 100 Gb/s 链路,每条接到不同交换机——形成 8 个独立网络平面。两层拓扑在全二分带宽下支持 131,072 GPU,而常规三层拓扑大约只能撑 ~64K。最差路径 3 跳 vs 5-7 跳。光器件用 2/3、交换机用 3/5,相对三层部署。(2) 没有动态路由协议——只有静态路由,零转发状态,控制平面简单到一小队人可以同时管理多个超算。(3) 包喷洒(packet spraying):每次传输被分散到八个平面里的数百条随机路径;链路失败时,NIC 把那个 entropy 值退掉,把流量在微秒内重新分配到其余七个平面。(4) 故意有损以太网——刻意接受丢包,而不是搭起反压力级联,小部分丢包由选择性重传处理。(5) ECN 被重新用作负载均衡信号,而不是拥塞控制信号。800 Gb/s NIC 来自三家不同的硅厂商。
把问题框对了,工程上的取舍才能站得住脚。131,072 GPU 的同步预训练是 lock-step——每一步都要等最慢的传输完成。论文的原话框架:"随着算力 scale 上去,通信变得越来越被 outliers 主导。"在 ~300,000 美元/小时的云价格、10 万张 H100 级 GPU 这样的规模下,每步 10 毫秒的尾延迟、跨数千步累加起来,变成实打实的钱。生产事故那个故事是最该掂量的一段:一个 T0 交换机上的光模块抽风,四条链路连续 flap,影响了三个正在跑的训练节点;在常规网络下这会 crash 训练 job,而 MRC 下训练继续。链路故障的弹性账:800 Gb/s 单平面 NIC 一条坏链路损失 3% 带宽;100 Gb/s 多平面下损失 0.4%,且继续在剩下的七个平面上跑。这个架构买到的是可预测的带宽,代价是网络监控复杂度上去(要看八倍数量的链路),以及 ops 团队需要换一个不同于常规 L3 fabric 的心智模型。
对 builder 与基础设施团队:这是迄今为止关于"前沿实验室训练 fabric 长成什么样"最具体的数据点,而 OCP 公开版本意味着你可以直接研究协议设计,而不是靠岗位 JD 关键词反推。三条具体含义。第一,如果你在向接近前沿实验室的云供应商买容量,预期到 Q3,MRC 风格的多平面 fabric 会成为默认基线——你那些基于 single-path RoCE 的 workload 调优假设需要重做。第二,每一家专门为 AI fabric 出 OSPF/BGP 优化的网络 OSS 厂商,现在面对的是正在缩小的市场;OpenAI 这个财团是有据可查最大规模的"动态路由剔除"部署,他们往哪走,NVIDIA/Microsoft/Oracle 的客户就跟着往哪走。第三,这篇论文值得通读——Reddy 在 TDS 那篇是个好向导,但 arXiv 上的原文(2605.04333)才是规范引用。"五个反直觉决策"这个框架是编辑式的;真正令人惊讶的是:每一项都在 131K GPU 部署里同时通过了生产压力测试,而 OpenAI 财团选择公开"怎么做",而不是把这套工程当作私产留着。