编者按： 为什么训练大语言模型需要如此苛刻的网络条件？InfiniBand 真的是"封闭"技术吗？英伟达在 AI 网络领域的优势究竟从何而来？
文章从 LLM 训练的梯度下降过程切入，生动阐释了为何在包含数万 GPU 的集群中，哪怕一个 GPU 延迟 20 微秒，都会造成算力的巨大浪费。作者随后对比了企业网络、超大规模云网络和高性能计算网络三种场景，指出只有 HPC 网络的设计理念与 AI 训练需求高度契合。文章还破除了一个普遍的认知误区：InfiniBand 并非 Mellanox 或英伟达的私有技术，而是 1999 年由 180 余家企业联合制定的开放行业标准；同样，从 Mellanox 时代就开始推动的 RoCE 协议，也为今天的 AI 以太网方案（如 Spectrum-X 和 UEC 1.0）奠定了基础。
作者 | Austin Lyons
编译 | 岳扬
本文将解析低延迟与低抖动如何主导分布式训练的迭代效率，指出现有传统以太网技术的局限性，并阐释 InfiniBand 为何能成为高性能计算锁步工作负载的默认网络架构。
我们还将厘清一些常见的认知误区（别担心，我在撰写本文前也曾存在这些误解！）。例如：Mellanox 并非 InfiniBand 技术的发明者，InfiniBand 也并非私有协议，而是由行业联盟制定的开放标准。从 Mellanox 到 Nvidia，长期通过 RoCE 及其演进技术支持以太网横向扩展。文中还将明确定义网络技术中"开放"的真实含义。当然，精彩内容不止于此！
01 AI 通信网络的特殊性
那么 AI 工作负载对通信网络究竟有何需求？
注：本文讨论的 AI 训练特指推动生成式 AI 热潮的大语言模型及其变体的训练。
本质上，大语言模型的训练是一个分布式计算任务 ------ 成千上万台机器协同解决单一问题。
分布式计算并非新概念。还记得曾利用志愿者电脑运行蛋白质模拟的 Folding@Home 吗？
Vijay Pande：早在 2000 年我们就萌生了借助海量计算机解决问题的构想 ------ 与其用一台电脑耗时百万天，不如用十万台电脑在十天内完成。但当时面临一个关键的抉择：是止步于理论探讨，还是付诸实践？于是我们决定创建 Folding@Home，将理论转化为现实。2000 年夏天我们编写了软件的初始版本，于同年 10 月正式发布。幸运的是当时吸引了大量关注者 ------ 所谓"大量"指的是约五千至一万人。八年后，该项目已发展到拥有近 25 万个活跃处理器，累计参与设备超 200 万台。
如今的 AI 算力集群同样规模惊人。训练尖端模型可能需要数十万个 GPU 协同工作：每个 GPU 处理部分计算任务后，需与同伴交换结果。正是这种结果共享环节，让网络性能成为关键支撑......或瓶颈所在！
作为习惯看图理解知识内容的人，我将通过示意图展示 LLM 训练过程中惊人的网络通信量。为控制篇幅（毕竟没法花太多时间绘图），仅以简易图示说明，但您可由此推想数十万台设备互联的场景。
02 梯度下降与网络通信
假设我们在四个 GPU 上训练一个大语言模型，每个 GPU 都在内存中保存着完整的模型权重。这一假设虽然经过简化，但仍有教学意义。
宏观来看，AI 的训练过程本质就是几个步骤的重复循环。
前向传播 -- 每个 GPU 处理一部分训练样本，根据上文预测下一个词元。比如"Four score ___"可能会预测出"and"。
反向传播 -- 每个 GPU 计算梯度，这些信号指示了应该如何调整权重来减少误差。例如刚才预测"and"是正确的，那这部分就不需要调整。
梯度聚合（全规约） -- 在每个 GPU 计算出自己的调整量（梯度）之后，它们会互相比较并取平均值，确保所有 GPU 获得统一的模型更新指令。这一过程需要 GPU 之间进行大量的双向通信！
权重更新 -- 所有 GPU 应用相同的更新指令调整权重，保持模型的一致性。如果没有这种同步，每个 GPU 都会自行其是，最终训练出不同的模型。
若想深入了解，3Blue1Brown 有一个出色的梯度下降讲解视频[1]。
这是我制作的一个示意图，让大家先有个直观感受。全规约是分布式训练的核心。每个 GPU 都必须完成计算、贡献自己的梯度，然后等待聚合结果，之后才能继续前进。
每条线代表两个 GPU/XPU 之间的某种网络通信
如果有某一个 GPU 产生延迟了，其他所有 GPU 都必须停下来等待。
想象一下步骤 1 中所有黄色的 GPU 在不同时间点收到各自的输入，它们将不得不空转，直到每个输入都接收完毕。
这就是为什么在 AI 通信网络中延迟和抖动如此让人重视。
延迟是数据包在网络中传输的单向时间，包括传输、交换和排队延迟。 在这个只有四个 GPU 的例子中，很难想象会有延迟......但在大规模场景下，当数千个 GPU 通过一两层交换机连接时，拥堵就会发生，延迟也会累积。AI 训练需要尽可能低的延迟。
抖动是指延迟的波动性。可以把它想象成上面 GPU 的接收结果的到达时间分布。 即使平均延迟非常低，这种波动性也会导致结果到达时间的不确定性。AI 训练需要非常低的抖动。
假设一个包含 10,000 个 GPU 的集群完成一次全规约操作需要 40-45 微秒，但唯独有一个掉队者花了 60 微秒。这可不妙！每个 GPU 都不得不额外等待那 20 微秒。9999 个 GPU 各自多等 20 微秒，加起来就是 0.2 秒的 GPU 时间！对于如此庞大的集群来说，由于网络性能不佳导致 GPU 空转损耗，这可能意味着真金白银的损失。☠️
因此，确定性的、低抖动的通信对于保持 GPU 快速且步调一致地前进至关重要。
那么，传统的网络技术能否满足要求，为 AI 训练提供确定性的、低抖动的通信呢？
答案当然是不能 😎 所以就有了 InfiniBand，所以就有了为 AI 重新设计以太网的事情，比如 Spectrum-X......我下面会解释。
我猜想读到这里的大部分读者并非网络通信专家，所以我们快速梳理一下常见的网络应用场景，看看为什么传统以太网不是为这种需求设计的。
2.1 通用的企业网络场景
我们从最简单的场景说起。
阅读以下这个演示样例时，请始终思考一个问题：这种网络技术能否以低延迟和低抖动支持大规模的 AI 训练？
大多数传统网络系统诞生时，分布式 AI 训练尚未兴起，其设计理念源于截然不同的应用场景。将企业交换机直接用于 AI 数据中心并非易事。
首先来看企业网络场景。
企业网络中有多台服务器，每台服务器运行多个虚拟机处理不同的工作负载
企业网络需同时运行多种业务应用：如邮件服务器、数据库、ERP、CRM、分析工具等。这些工作负载通常运行在搭载多个虚拟机的高性能多核服务器上，每个虚拟机隔离执行独立任务。
这些工作负载常在数据中心内部相互通信，产生东西向流量，例如分析工具从数据库拉取数据。
分析工具与数据库间的"东西向"通信
此类场景默认采用以太网作为基础架构。
整个系统围绕企业需求设计。因此交换机侧重于提供安全功能（如隔离人力资源系统与开发环境）和流量管理（如在大型文件传输时保障视频通话流畅）。
这类网络多采用博通的 Trident 系列芯片。例如相关视频[2]展示了基于 Trident 4 芯片的交换机的监控功能，虽视频稍旧，但仍具参考价值。
企业网络能否满足 AI 训练的需求？答案是否定的。其设计目标本就不包含超低延迟与抖动！
企业级交换机强调功能性与灵活性，而非确定性。普通业务场景可接受一定的延迟与抖动，因为工作负载相互独立。数据库查询或邮件传输中的数据包延迟不会阻塞其他应用。
这些网络生来就不是为大规模 AI 训练所需的锁步式、低抖动通信而构建的。
2.2 超大规模云网络
更接近了一些......
超大规模数据中心专为将单一服务扩展至数百万乃至数十亿用户而构建，例如 Gmail、YouTube、Netflix 或亚马逊电商。成千上万台服务器各司其职，共同构成一个庞大的分布式系统。
以太网仍是默认的基础架构。
在此规模下，成本与能效是需要首要考量的因素。交换机的设计追求高端口密度和高带宽，以极低功耗传输海量数据。
博通 Tomahawk 系列便是典型代表。相关视频[3]介绍了上一代 Tomahawk 4 芯片，并将其与 Trident、Jericho 系列进行对比（建议观看 1:50 至 2:50 部分）。
这类网络能否胜任 AI 训练？
超大规模云网络以保持服务响应速度为目标，注重降低平均延迟，但无需保证确定性。
网络波动（抖动）在可接受范围内。慢查询可重试，数据副本确保了系统韧性。
就此而言，超大规模网络架构因已具备协调大型分布式系统的能力，相比企业网络更接近 AI 训练需求。但它们仍无法满足 LLM 训练的要求 ------ 后者需要成千上万的 GPU 在每次迭代中保持严格同步。
2.3 超级计算机（高性能计算）
近期"超级计算机"一词热度攀升，诸如"丹麦的 AI 超算"或"桌面级 AI 超算"的报道频现。
当然，超级计算机或高性能计算集群的概念早已有之。每每提到"超级计算机"，我总会想到克雷公司的传奇设备。
组装完成的克雷超级计算机外观（红色圆柱体）。Source[4]
拆除面板后的内部结构如下：
印刷电路板间密布的连接线缆...这正是某种形式的网络！
这张照片让我联想到现代 AI 超级计算机的结构：
埃隆公布的 Colossus 2 机房照片。Source[5]
顺带一提，埃隆的这张照片揭示了为大规模 AI 训练和推理设计的网络基础设施为何如此热门。
紫色线缆代表 CRDO。你可以想象连接数十万 GPU 需要多少 Credo 有源电缆[6]！
Colossus 还搭载大量 Nvidia Spectrum-X 交换机和 Nvidia SuperNIC[7]。这正是英伟达网络业务版图扩张的缩影。
回归正题。
超级计算机由大量处理器构成，每个处理器能同步处理海量数据（单指令多数据[8]），适用于核科学模拟与气象预报等科学计算。维基百科"TOP 500[9]"超级计算机榜单收录了丰富的发展史料。
与企业级网络环境或超大规模网络环境不同，高性能计算（HPC）任务是横跨数千服务器的单一工作负载。一个模拟任务可能调度数万 CPU 或 GPU 节点，每个节点承担部分计算任务。
是否似曾相识？这完全契合 AI 训练的运行模式！
与 AI 工作负载类似，HPC 需要节点间持续通信来保持全局同步。因此，HPC 网络专为超低延迟和近乎零抖动而设计。任一节点产生延迟将导致整个模拟任务停滞 ------ 这与 LLM 训练过程面临的挑战完全一致！
事实上......InfiniBand 这类技术正是为 HPC 环境量身定制的。
03 面向 AI 工作负载的 InfiniBand
自诞生之初，InfiniBand 就瞄准了需要数千处理器锁步运行的分布式计算场景。
其设计特性堪称 AI 网络的理想清单（本文暂不深入技术细节，后续另文探讨，此处概述要点）：
- 远程直接内存访问（RDMA） ：允许 GPU（与 CPU）直接读写对方内存，绕过 CPU 与系统内存，消除了缓冲区之间复制数据与上下文切换的性能开销。
- 无损转发：InfiniBand 采用基于信用的流量控制机制避免数据包丢弃，从设计上保障零丢包，从而消除抖动与代价高昂的重传。
- 直通交换（Cut-through switching） ：InfiniBand 交换机在收到数据包头时立即开始转发，无需等待完整帧到达，最大限度降低每跳延迟。
- OS bypass 与 Transport Offload：InfiniBand 网卡将传输功能（如可靠传输、拥塞控制）从 CPU 卸载，应用程序可绕过操作系统内核直接向网卡提交任务。这大大减少了软件开销与延迟。
正因如此，InfiniBand 非常适合 AI 训练。它本就是为低延迟、低抖动的分布式计算工作负载而生。
但众所周知，英伟达并非 InfiniBand 的发明者。
啊不错！若您听过《Acquired》播客的英伟达专题便知，没错，Mellanox 堪称史上最成功的收购案例之一。
但您是否知道... Mellanox 也非 InfiniBand 的发明者！
是的！说实话我曾以为 Mellanox 创造了 InfiniBand。毕竟现在 InfiniBand 是私有技术。
但我最近才了解到... InfiniBand 并非私有协议。
但如今只能从英伟达购买 InfiniBand 交换机和线缆了，对吧？这不算私有吗？
好吧，这里需要厘清很多概念。单一的供应商并不意味着技术私有化。我们稍后会详解。
在本文的调研过程中，我对 InfiniBand 有了全新认知。若您也曾存在类似误解，实属正常 ------ 毕竟我们曾站在同样的信息盲区。
3.1 开放与封闭
在 2001 年 IEEE 国际集群计算会议的特邀论文《Aspects of the InfiniBand Architecture》[10]中，IBM 的 Gregory F. Pfister 写道：
"InfiniBand 架构（IBA）是一种用于服务器 I/O 和服务器间通信的新行业标准架构。它由 InfiniBand 贸易协会（IBTA）制定，旨在为当前及未来的服务器系统提供所需的可靠性、可用性、性能与扩展性保障 ------ 这些特性远非面向总线的 I/O 结构所能企及。"
行业标准？由行业协会制定？
看来 Mellanox 确实不是 InfiniBand 的发明者！
继续往下看。
"IBTA 由 180 余家企业在 1999 年 8 月联合创立，目的是共同开发 IBA。该协会也向高校、研究实验室等机构开放。指导委员会成员来自戴尔、康柏、惠普、IBM、英特尔、微软和太阳微系统，由 IBM 与英特尔共同担任主席。赞助企业包括 3Com、思科系统、富士通-西门子、日立、Adaptec、朗讯科技、NEC 和北电网络。"
原来有这么多企业参与其中！
"来自 IBTA 成员企业的约 100 名专家历时 14 个月共同定义和描述了 IBA......它应当为技术创新与厂商差异化提供充分的空间。"
显然，InfiniBand 的起源与"私有"毫不相干。它诞生于 90 年代末计算与网络巨头组成的开放标准委员会。
这个行业协会是如何起步的？根据 2006 年《NetworkWorld》中的一篇文章[11]：
"有些读者可能还记得 90 年代康柏、惠普和 IBM 共同推动的 Future I/O 高速串行连接技术。或许也有人对英特尔、微软和太阳微系统联合推出的一项竞争技术【Next Generation I/O (NGIO)】留有印象。"
"最终两大阵营合并力量，共同开发被普遍视为下一代服务器与存储连接技术的 InfiniBand。"
"最初这项合作成果被称为 System I/O，但这个名字未能持续多久。如今我们称其为 InfiniBand。"
两个相互竞争的开放标准计划合并为一个，也就是我们现在所知的 InfiniBand。
事实上，InfiniBand 这种协作、开放的基础，与当下超以太网联盟（UEC）[12]的发展如出一辙。UEC 在 2023 年成立时宣称[13]：
"今日宣布成立的超以太网联盟正在汇聚行业领军企业，共同构建一个完整的基于以太网的高性能网络通信栈架构。人工智能（AI）与高性能计算（HPC）工作负载正在迅速发展，它们既需要顶尖的功能性、互操作性、性能表现及较低的总体拥有成本，同时又不能牺牲开发者友好性与终端用户体验。超以太网解决方案将利用以太网的普遍性与灵活性来处理各种工作负载，同时兼具可扩展性和成本效益。"
"超以太网联盟由在高性能解决方案领域拥有深厚积淀的企业共同创立。各成员正以平等的方式为更广泛的高性能生态系统做出重要贡献。创始成员包括 AMD、Arista、博通、思科、Eviden（Atos 旗下业务）、HPE、英特尔、Meta 和微软，这些企业在网络、人工智能、云与大规模高性能计算部署领域拥有数十年经验。"
两者何其相似！都是主要计算与网络厂商联合为分布式工作负载设计高性能架构。
因此将 InfiniBand 定性为"封闭"，而将 UEC 定性为"开放"并不准确。二者最初都是由行业联盟起草的开放规范，任何人都可参照实施。
理论上，任何企业都可以基于 InfiniBand 规范开发 IB 交换机和网卡与英伟达竞争。
技术规范是公开可用的。这已经是最大程度的开放了。
诚然，创办一家 InfiniBand 初创公司可能不是最佳商业决策，但这完全是可能做到的。
我认为困惑源于此：虽然英伟达是目前唯一大规模供应 IB 设备的厂商，但这是市场选择的结果，而非规范限制。
准确来说，AI 网络领域的"开放"，指的是规范制定过程的可参与性和可实现性，而非现有供应商的数量。
那么什么是封闭的规范？
如果某公司编写仅供内部使用的保密产品需求文档，这属于封闭。若员工离职携带该文档至竞争对手，即使新设计存在差异，也构成商业秘密侵权。这才是封闭。
显然超以太网拥有开放的规范。UEC 1.0 规范可免费查阅[14]。任何企业都可参照该产品需求文档（PRD）开发解决方案。Astera Labs 正在这样做[15]。
但你猜怎么着！InfiniBand 同样拥有开放的规范。虽然需要支付 5000 至 10000 美元成为 IBTA 会员才能查阅（并非免费），但这不意味着"封闭"。
实际上，威斯康星大学图书馆馆藏有 InfiniBand 1.0 规范的两卷本书籍，读者可通过馆际互借借阅。我刚查询发现爱荷华州立大学图书馆的书架上就有一本。
可见，获取其规范或许需要借书证或协会会费，但该规范本身并非封闭。它不属于任何单一企业的私有财产。
我先前认为 InfiniBand "封闭"的认知是错误的！
3.2 InfiniBand 的渊源
最初的 InfiniBand 联盟引入了许多对当今 AI 训练工作负载来说非常重要的技术。
那么，它最终是如何与 Mellanox 联系起来的呢？
Ted Kim 博士 2004 年的一篇博客文章[16]提供了第一手的资料。Ted[17] 在太阳微电子任职期间，曾参与了 InfiniBand 1.0 规范的撰写。
Ted 回忆道，互联网泡沫破灭和英特尔转向 PCI Express，引发了 InfiniBand 的衰落：
有一段时间，InfiniBand 非常热门。关注度不断上升，涌现出大量初创公司，人人都在宣传自己的 IB 路线图。随后泡沫破裂了。这不仅仅是 IB 的问题 ------ 而是整个互联网泡沫的破灭、股市调整、企业 IT 支出趋于谨慎、经济衰退、9·11 事件等等共同作用的结果。最终，没人愿意采纳或投资这样一项影响深远的技术变革。于是，新一轮的怀疑情绪开始蔓延。
然后另一个打击接踵而至。英特尔决定停止 IB 芯片开发，尽管他们仍在推广这项技术。他们为什么要这么做？我只能在此猜测。他们最初的开发基于 1x 链路（译者注：指的是单通道链路，即由一个信号通道组成的物理连接。），但这一选择似乎偏离了市场（4x 成为了最受欢迎的规格）。英特尔也难以摆脱研发上的财政压力，因此需要将资源转向 PCI Express 的开发。此外，他们可能也对 IB 市场接受度不佳的状况做出了反应。无论如何，英特尔的退出让许多人认为 IB 市场规模有限。这也导致一大批供应商延迟扩张或收缩了他们的 IB 路线图。微软离开了 IBTA，转而投向 RDMAC。初创公司或合并或失败。残酷的现实摆在眼前。在 SIGCOMM 2003 会议上有人问我："InfiniBand 是不是已经死了？"
看来 InfiniBand 当时几乎夭折！Ted 继续写道。
时至今日。在经历漫长的低落和绝望之后，IB 似乎正在特定市场卷土重来......
Mellanox 是那些坚持下来的初创公司之一，即使在互联网泡沫破裂后的黑暗时期，也持续为 HPC 领域开发 InfiniBand。
顺带一提，如果您正在寻觅网络专家，Ted 似乎最近结束了在 SambaNova 的工作，根据其 LinkedIn 信息[17]，他正在寻找工作机会。
在过去的十年里，InfiniBand 已成为 HPC 工作负载的黄金标准，这一点可从世界大多数顶级超级计算机（位列 TOP500 超级计算机榜单[18]中的那些）都采用它得到印证。
04 面向 HPC/AI 的以太网
正如你所料，直到最近，都鲜有超级计算机在 HPC 网络采用以太网。
然而，由于 Ethernet 的无处不在，从 InfiniBand 诞生之初，就一直有人在问："为什么不能直接用以太网？"
那篇 2001 年的 IBM 论文中写道：
"人们经常问及 InfiniBand 架构的一个问题是：'我们为何需要另一种网络架构？为何不使用以太网和 IP？'"
正如我们之前讨论过的，以太网最初并非为高性能分布式计算工作负载设计。
直到 RoCE（RDMA over Converged Ethernet）问世才改变这一局面。妙极了，一个缩写词（RDMA）嵌套在另一个缩写词（RoCE）里，哈哈。
RoCE 成功将 InfiniBand 的"verbs"引入以太网世界。这些"verbs"是软件可调用的 RDMA 基本操作，包括 read（直接从对端内存拉取数据）、write（直接向对端内存写入数据）以及 send/receive（消息式通信）。它们允许 GPU 在彼此内存之间传输数据，而无需 CPU 介入。
而且，请注意下面这句话：
Mellanox 协助编写了 RoCE 规范，且 InfiniBand 贸易协会还在大力推广它！
等等，我原以为故事是这样的：
- Mellanox 被 Nvidia 收购了
- Nvidia 只关心"私有"的 InfiniBand/NVLink
- Nvidia 通过捆绑销售强迫客户购买 InfiniBand/NVLink
事实恰恰相反，Nvidia 内部那些出身 Mellanox 的网络团队，长期以来一直是以太网用于分布式计算的坚定支持者。
2009 年《HPCWire》一篇题为《An Ethernet Protocol for InfiniBand》[19]的文章指出：
"无损以太网进入数据中心是大势所趋...但由于其技术原理趋近 InfiniBand，Voltaire 和 Mellanox 等厂商正借此进军以太网领域。'我们不会天真地认为全世界都将转向 InfiniBand，'Mellanox 营销副总裁 John Monson 表示..."
'我们坚信业界已有经过验证且广泛应用的 RDMA 传输机制，'Monson 断言，'它就是 InfiniBand。'
他指出，如若你的目标是实现 10Gb 的无损以太网，完全可以在以太网框架内植入类似功能。Mellanox 将其 RDMAoE 原型称为低延迟以太网，但实质上就是运行在以太网上的 InfiniBand...
这些 InfiniBand 先驱将他们的经验应用于以太网，展示了这些经验如何让以太网更适合 HPC（以及 AI）。
"如今你能在 10Gb 以太网上实现接近 InfiniBand 的延迟，"IBTA 市场工作组联合主席、Mellanox 市场传播总监 Brian Sparks 表示，"且不必面对 InfiniBand 的技术门槛和随之而来的陡峭的学习曲线。"
但 RoCE 的性能仍略逊于 InfiniBand：QDR IB 可实现 32 Gb 带宽与亚微秒级延迟，而 RoCE 当时仅限于 10Gb 带宽及微秒级延迟。不过对大多数应用而言，10Gb 带宽已绰绰有余...
对于偏好以太网的客户来说，借助 RoCE，他们能获得更接近 InfiniBand 的特性与性能，虽仍存在一定差距但方向是对的。
有人可能会疑惑 IBTA 及 InfiniBand 的拥护者为何要推动一种以太网协议。若 RoCE 成功，势必会蚕食 InfiniBand 市场。但此观点有失偏颇：首先，严格意义上的纯 InfiniBand 厂商已不复存在 ------ Mellanox、Voltaire 与 QLogic 均以某种形式提供以太网产品。市场早已判定 InfiniBand 技术的普及存在天然上限，RoCE 为这些厂商提供了触达此前无法吸引的客户的新途径。他们判断，RoCE 与 InfiniBand 之间仍有足够大的性能差距，足以支撑两种技术共存。
这句话至今依然成立："RoCE 是这些厂商触达此前无法吸引的客户的又一途径。" 即使在 15 年后的今天，在 LLM 训练与推理时代，我依然坚信这一点。头部客户将性能置于一切之上；其他客户则寻求性能与成本的平衡；还有一些企业更愿意沿用他们熟悉的技术。
而且有证据表明，IBTA 十多年来一直在为偏好以太网的用户推动以太网在 HPC/AI 领域的应用。根据 IBTA 在 2015 年的一篇文章[20]：
"IBTA 今日宣布启动 RoCE 计划，以进一步推动 RDMA over Converged Ethernet（RoCE）技术的发展，并提升 RoCE 的行业认知度......该计划将帮助我们向需要最高性能以太网络的群体提供解决方案信息和资源...RoCE 倡议汇集了 IBTA 中致力于展示该技术的性能与效率优势、以及多厂商竞争生态价值的成员。"
早在十年前，他们就已构想出一个多厂商生态系统......如今，这一愿景正随着 Nvidia 之外的厂商推动以太网用于 AI 网络而逐步实现。
这一生态系统的基石，正是 RoCE 的第二代版本------RoCEv2，它为 HPC/AI 工作负载增加了更多功能。
如今新兴的 AI 专用以太网协议栈，例如 Nvidia 的 Spectrum-X 和 Ultra Ethernet Consortium 的 UEC 1.0 规范，都直接构建于 RoCEv2 之上，在保留 RDMA 语义的同时，也着力解决其原有缺陷。我们将在后续文章中详细解析这些创新。
05 英伟达的 AI 以太网方案
所以今天的 InfiniBand 是一个开放标准规范，却只有单一供应商提供产品。
但你猜怎么着？英伟达同样推出了名为 Spectrum-X 的 AI/HPC 以太网解决方案。这步棋下得漂亮。
这里有一段短视频[21]，现在你应该能看懂其中一些内容了！
如视频所示，英伟达的 Spectrum-X 将其交换机和 DPU/SuperNIC 协同搭配，构成面向 GPU 集群的"全栈式网络架构"
06 英伟达芯片战略的优势
在探究横向扩展技术时，我意外发现了英伟达芯片战略中一个被低估的优势。
英伟达共设计了七种不同类型的芯片。
其一是 GPU，其二是基于 Arm 的CPU，另外五款全是网络芯片。
你瞧瞧！
来自英伟达演示 PPT 的截图
这种在网络领域的深耕非常重要。这也是为什么博通（Broadcom）能够为超大规模云厂商定制 AI ASIC ------ 因为它早已具备将加速器互联所需的网络技术专长。
而 Nvidia 用于反驳的观点自然是：那些定制 ASIC 厂商能否既跟上 AI 加速器飞快的迭代节奏，还能同步应对同样高速演进的网络需求？博通（Broadcom）加上云厂商内部的芯片团队，真的能跟得上吗？
Courtesy Nvidia.
相较之下，AMD 虽然拥有 GPU 和 CPU 产品，但在横向扩展（scale-out）和纵向扩展（scale-up）的竞争力上，仍依赖更广泛的生态系统 ------ 即 UEC 和 UALink。他们的赌注是：网络领域的专业厂商能否足够快速地创新，并与 AMD 步调一致，最终在系统层面实现同步发展。
END
本期互动内容 🍻
❓在阅读本文之前，您是否也曾认为 InfiniBand 是英伟达的"私有"技术？这个"认知误区"的澄清，是否改变了您对 AI 基础设施竞争格局的看法？
文中链接
1\][www.youtube.com/watch?v=IHZ...](https://link.juejin.cn?target=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DIHZwWFHWa-w "https://www.youtube.com/watch?v=IHZwWFHWa-w") \[2\][youtu.be/PvA4LvPJg0I](https://link.juejin.cn?target=https%3A%2F%2Fyoutu.be%2FPvA4LvPJg0I "https://youtu.be/PvA4LvPJg0I") \[3\][youtu.be/B-COGMbaUg4](https://link.juejin.cn?target=https%3A%2F%2Fyoutu.be%2FB-COGMbaUg4 "https://youtu.be/B-COGMbaUg4") \[4\][www.computerhistory.org/revolution/...](https://link.juejin.cn?target=https%3A%2F%2Fwww.computerhistory.org%2Frevolution%2Fsupercomputers%2F10%2F7%2F68%3Fposition%3D0 "https://www.computerhistory.org/revolution/supercomputers/10/7/68?position=0") \[5\][x.com/elonmusk/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Felonmusk%2Fstatus%2F1947715674429919279 "https://x.com/elonmusk/status/1947715674429919279") \[6\][credosemi.com/products/hi...](https://link.juejin.cn?target=https%3A%2F%2Fcredosemi.com%2Fproducts%2Fhiwire-aec%2F "https://credosemi.com/products/hiwire-aec/") \[7\][nvidianews.nvidia.com/news/spectr...](https://link.juejin.cn?target=https%3A%2F%2Fnvidianews.nvidia.com%2Fnews%2Fspectrum-x-ethernet-networking-xai-colossus "https://nvidianews.nvidia.com/news/spectrum-x-ethernet-networking-xai-colossus") \[8\][en.wikipedia.org/wiki/Single...](https://link.juejin.cn?target=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSingle_instruction%2C_multiple_data "https://en.wikipedia.org/wiki/Single_instruction,_multiple_data") \[9\][en.wikipedia.org/wiki/TOP500](https://link.juejin.cn?target=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FTOP500 "https://en.wikipedia.org/wiki/TOP500") \[10\][ieeexplore.ieee.org/document/96...](https://link.juejin.cn?target=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F960002 "https://ieeexplore.ieee.org/document/960002") \[11\][www.networkworld.com/article/845...](https://link.juejin.cn?target=https%3A%2F%2Fwww.networkworld.com%2Farticle%2F845980%2Fservers-infiniband-back-to-the-beginning.html "https://www.networkworld.com/article/845980/servers-infiniband-back-to-the-beginning.html") \[12\][ultraethernet.org/](https://link.juejin.cn?target=https%3A%2F%2Fultraethernet.org%2F "https://ultraethernet.org/") \[13\][ultraethernet.org/leading-clo...](https://link.juejin.cn?target=https%3A%2F%2Fultraethernet.org%2Fleading-cloud-service-semiconductor-and-system-providers-unite-to-form-ultra-ethernet-consortium%2F "https://ultraethernet.org/leading-cloud-service-semiconductor-and-system-providers-unite-to-form-ultra-ethernet-consortium/") \[14\][ultraethernet.org/wp-content/...](https://link.juejin.cn?target=https%3A%2F%2Fultraethernet.org%2Fwp-content%2Fuploads%2Fsites%2F20%2F2025%2F06%2FUE-Specification-6.11.25.pdf "https://ultraethernet.org/wp-content/uploads/sites/20/2025/06/UE-Specification-6.11.25.pdf") \[15\][www.asteralabs.com/news/astera...](https://link.juejin.cn?target=https%3A%2F%2Fwww.asteralabs.com%2Fnews%2Fastera-labs-to-share-vision-for-expanding-opportunities-in-ai-infrastructure-with-ualink%2F "https://www.asteralabs.com/news/astera-labs-to-share-vision-for-expanding-opportunities-in-ai-infrastructure-with-ualink/") \[16\][web.archive.org/web/2014080...](https://link.juejin.cn?target=https%3A%2F%2Fweb.archive.org%2Fweb%2F20140808200954%2Fhttps%3A%2F%2Fblogs.oracle.com%2FRandomDude%2Fentry%2Fhistory_hype_to_pragmatism "https://web.archive.org/web/20140808200954/https://blogs.oracle.com/RandomDude/entry/history_hype_to_pragmatism") \[17\][www.linkedin.com/in/ted-kim-...](https://link.juejin.cn?target=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fted-kim-8816641%2F "https://www.linkedin.com/in/ted-kim-8816641/") \[18\][top500.org/](https://link.juejin.cn?target=https%3A%2F%2Ftop500.org%2F "https://top500.org/") \[19\][www.hpcwire.com/2009/05/21/...](https://link.juejin.cn?target=https%3A%2F%2Fwww.hpcwire.com%2F2009%2F05%2F21%2Fan_ethernet_protocol_for_infiniband%2F "https://www.hpcwire.com/2009/05/21/an_ethernet_protocol_for_infiniband/") \[20\][www.infinibandta.org/infiniband-...](https://link.juejin.cn?target=https%3A%2F%2Fwww.infinibandta.org%2Finfiniband-trade-association-launches-the-roce-initiative-to-advance-rdma-over-converged-ethernet-solutions%2F "https://www.infinibandta.org/infiniband-trade-association-launches-the-roce-initiative-to-advance-rdma-over-converged-ethernet-solutions/") \[21\][youtu.be/nKqfi3q4S5I](https://link.juejin.cn?target=https%3A%2F%2Fyoutu.be%2FnKqfi3q4S5I "https://youtu.be/nKqfi3q4S5I") **本文经原作者授权，由 Baihai IDP 编译。如需转载译文，请联系获取授权。** **原文链接：** [www.chipstrat.com/p/gpu-netwo...](https://link.juejin.cn?target=https%3A%2F%2Fwww.chipstrat.com%2Fp%2Fgpu-networking-basics-part-3-scale "https://www.chipstrat.com/p/gpu-networking-basics-part-3-scale")