突破AI训练瓶颈：OpenAI解决大规模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连接着数十到数百个网络组件——仅光收发器中就可能包含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

整理：每日天使·如有问题欢迎留言

作者提示：投资观点，仅供参考

欢迎扫码提交信息加入我们。

我们将经认证真实身份的创业者、投资人邀请至对应的社群，若想加入可以扫码填写问卷，经认证后邀请加入。

关于我们 ▼

About Us