OpenAI 搞定了 AI 训练的最大瓶颈:数十万块 GPU 如何完美同步协作?

ANGEL Guest

本期关键点

•  AI 模型训练的本质是让全球最快的 GPU 阵列做同一件事，通信瓶颈决定了训练速度

•  传统互联网网络设计依赖「大数定律」，恰好与 AI 训练的同步需求完全相反

•  规模越大故障越频繁：系统翻倍，故障间隔减半，数百万条光纤链路中随时有东西在坏

•  OpenAI 开发了 MRC（多路径可靠连接）协议，让数据包在数千条路径间智能分流

•  MRC 引入「包修剪」技术：拥塞时只转发包头，接收端立即触发重传，消除歧义

•  当网络链路故障时，MRC 在毫秒内自动切换路径，无需等待传统路由协议收敛（原来需数秒）

•  部署 MRC 后，OpenAI 直接关掉了交换机路由协议，全部改用静态路由——MRC 自己找可用路径

•  数据中心建设期间频繁断线，但训练任务完全没有受到影响

•  MRC 已通过 OCP 发布为开放标准，英伟达、AMD、博通、英特尔均参与

•  太空计算目前不现实：延迟太高、故障率太高、没法派工程师去修

导语

5 月 6 日，OpenAI 发布播客第 18 期，首次公开了训练前沿模型背后的网络架构突破——MRC（Multipath Reliable Connection，多路径可靠连接）。

这两位嘉宾分别是 OpenAI 核心网络团队的 Mark Handley（伦敦大学教授）和工作负载系统团队的 Greg Steinbrecher。他们向主持人 Andrew Mayne 揭示了一个反直觉的事实：AI 模型训练面临的最大瓶颈不是算力不足，而是网络通信——当你把数十万块 GPU 绑在一起做同一道计算题时，任何一条光纤断掉，整场训练都可能停摆。

这期节目的价值在于，它从底层基础设施的视角解释了为什么训练大模型如此困难，以及 OpenAI 如何通过与英伟达、AMD、英特尔、博通等公司的合作，找到了一个可以惠及整个行业的解决方案。

正文

一、从量子计算到 AI 网络：两位工程师的来时路

Andrew Mayne：介绍一下你们的背景。

Greg Steinbrecher：我本科读物理和数学，想做量子计算机。博士期间我意识到量子计算机还做不出来，但我发现我们为量子计算机设计的光控芯片看起来很像网络交换机。后来我做了些数据中心网络的仿真研究，发现传统网络硬件还有很大优化空间。AI 爆发后，我们需要构建大型 GPU 集群，我也就被卷进了网络设计的坑。大约一年前我加入了 OpenAI，负责让 GPU 的使用效率尽可能高——模型训练够不够快？有没有被网络卡住？出了故障能不能快速恢复？

Mark Handley：除了在 OpenAI 的工作，我同时也是伦敦大学的教授，搞网络研究已经几十年了。最早我研究的是如何在互联网上做视频会议，后来我们写的标准成了 4G/5G 网络的基础。大约十年前我开始关注数据中心网络，发现这是一个可以做完全不同事情的地方——因为数据中心里你只需要让内部的设备互相达成一致，不需要全世界都同意。

二、AI 训练为什么「碾碎」了传统网络设计

Andrew Mayne：AI 改变了一切，也改变了数据中心的设计思路。为什么？

Mark Handley：传统互联网设计的基本逻辑是：很多人各自做各自的事，人越多反而越平滑，大数定律起作用。但 AI 训练完全相反——我们把世界上最快的一批 GPU 拴在一起，让它们同时做同一件事。这意味着，如果一块 GPU 慢了一拍，所有其他 GPU 都得等它。这差不多是你能想到的最恶劣的网络负载。

Greg Steinbrecher：关键在于，GPU 之间的通信本身就是计算的一部分。它们不是各干各的，而是在一起做一道大计算题。你必须让它们互相沟通，达成共识，才能完成一步计算。而且一切都是在锁步（lockstep）中进行的——所以我们不能依赖平均速度，只看最坏情况。我们关心的是第 100 百分位的统计数据，是「尾巴的尾巴」。

Andrew Mayne：听起来 GPU 规模翻倍，故障率也会翻倍？

Greg Steinbrecher：是的。如果你假设故障是独立的，系统翻倍，平均故障间隔时间就减半。更要命的是，每个 GPU 连着 tens 到 hundreds 个网络组件——光收发器里可能就有 8 个激光器。一层层交换机叠上去，同一个建筑里可能有数百万条光纤链路。规模大到一定程度，故障频发到你根本做不了同步工作。

三、MRC：用「智能分流」和「包修剪」重构网络

Andrew Mayne：你们发明了 Multipath Reliable Connection，怎么解决这些问题的？

Mark Handley：核心洞察有两层。第一层：如果你把数据包分散到很多条路径上均匀发送，可以避免网络拥塞热点——只在一个地方可能拥塞，就是多个发送者同时发往同一个目的地的时候。第二层：数据包走不同路径会导致乱序，如果丢包了，你很难判断是丢了还是只是迟到了。我们发明了「包修剪」技术：当网络队列快满时，我们不丢弃整个包，而是切掉数据负载，只转发一个极小的包头到目的地，目的地立刻就能触发重传。这完全消除了「丢了还是迟到了」的歧义。

Greg Steinbrecher：Mark 有点谦虚了。MRC 最大的突破在故障处理上。传统做法是，一条链路断了，交换机要通知邻居，邻居再通知邻居，层层传播，用 BGP 这种路由协议，收敛需要几秒甚至几十秒。这几秒里 GPU 全在空转。MRC 干了一件很反直觉的事：它彻底打破了集中协调的思路。每个终端点自己独立地在毫秒内发现某条路径不可用，然后直接不用它了。不需要等任何中央权威来告诉你。

Andrew Mayne：部署效果怎么样？

Greg Steinbrecher：我们是在数据中心建设过程中就启用了 MRC。当时到处都在施工，光纤频繁拔插，链路断了又修、修了又断，频率远超正常运营期。我们完全没注意到。MRC 自动处理了一切。事实上，因为我们发现 MRC 自己就能找到可用路径，我们干脆把交换机的路由协议全部关掉了，用完全静态的路由。有些路径本来就是坏的，无所谓，MRC 会自己绕过去。这帮我们砍掉了整个路由管理那套复杂度。

四、开源 MRC：基础设施是整个行业的共同命运

Andrew Mayne：你们决定把 MRC 开放给所有人用？

Mark Handley：是的，规范已经通过 OCP 发布为开放标准。我们是开放标准的坚定信奉者。我们的网络全部基于以太网——它本身就是开放标准。我们受益于整个行业的创新速度，如果整个行业都在往同一个方向推进，对所有人都有利。

Greg Steinbrecher：基础设施是整个行业的共同命运。如果供应链分裂了，大家各自搞不同的技术和底层硬件，那才是真正的浪费。我们不认为 MRC 作为 OpenAI 独占技术会更好。

Andrew Mayne：对终端用户来说有什么好处？

Greg Steinbrecher：你能更快地获得更好的、更智能的模型。MRC 让我们加速了研究和部署的每一个环节，让研究人员不用再担心任务失败，不用关心自己被调度到哪个机架上。你会看到一个越来越精彩的模型发布节奏。

Andrew Mayne：还有个疯狂的问题——AI 计算会不会搬到太空去？

Mark Handley：很难想象。延迟是巨大问题，故障率也是巨大问题。我们现在每天都靠微软和 Oracle 的工程师钻进机房修东西。在轨道上怎么修？

Greg Steinbrecher：我物理出身，研究过卫星，但太空计算的障碍太大了。还是脚踏实地，在地球上多建些数据中心吧。

视频链接：https://www.youtube.com/watch?v=TiW96H5HmAw