新一代 AI 网络 | Ultra Ethernet UEC | UALink 对比 Broadcom Scale Up Ethernet SUELibFabric、分包喷洒、轨道优化、拥塞控制、ECN、ACK、流量控制、PFC、UEC 挑战

本文信息来源：semianalysis

作者：Tanj Bennett 和 Dylan Patel

在生成式 AI 热潮初期，标准以太网最初失去了大量市场份额，被 Nvidia 的 InfiniBand 所取代。自那以后，以太网开始逐步夺回市场份额，这主要得益于成本优势、InfiniBand 的各种缺陷，以及能够在以太网基础上添加更多功能和定制化能力。

亚马逊和谷歌的内部以太网实现已经弥补了很大一部分性能差距（尽管它们在基于 Nvidia 的网络方面仍然远远落后）。此外，像甲骨文和 Meta 这样的公司也在以太网基础上进行了大量投资，与 Nvidia 的差距并不算太大。

即使是 Nvidia 也承认以太网的主导地位，在 Blackwell 这一代，Spectrum-X 以太网的出货量远远超过了他们的 Quantum InfiniBand。总体而言，标准以太网在没有投入大量专有实现的情况下，性能仍然远远落后。

这正是 Ultra Ethernet Consortium（超以太网联盟）发挥作用的地方。它为大型 AI 网络标准化了许多改进，并将所有最大的参与者聚集在一个庞大的联盟中。

Ultra Ethernet Consortium 候选发布版 1：深度评测

Ultra Ethernet Consortium（UEC）候选发布版 1 是一份内容庞大的文件，共有 565 页，今天已公开发布 。这与 Ultra Accelerator Link v1 规范形成了鲜明对比，后者优先考虑简洁性。UEC 本身并不简单，直接通读几乎难以理解。然而，通过结构化的方法可以揭示其内在逻辑。

UEC 项目旨在为以太网 NIC 和交换机提供传输和流量控制层，从而提升其在大型、高速数据中心网络中的运行效率。传输层负责确保用户内容从源头到达目的地，并承载现代 AI 或 HPC 用户所需的所有指令。流量控制则确保数据以最佳速度流动，防止网络拥堵，并能在出现故障或慢速链路时进行重路由。网络接口卡必须实现 UEC，整个系统才能正常工作。交换机则是可选的，当前的以太网交换机也可以用于网络部分。UEC 规范制定得非常详细，以确保不同厂商的设备能够互操作。

UEC 背景与核心模块

UEC 在 Linux 联合开发基金会（JDF）下运营，并作为一个标准制定组织（SDO）运作。虽然以太网是 UEC 的基础，但 UEC 还利用了其他一些规范或行业经验作为构建模块。UEC 被设计为本地网络，旨在实现集群间 1 到 20 微秒的往返时延，专门面向数据中心。其主要目标是为 AI 训练、AI 推理和高性能计算（HPC）优化扩展型网络。该规范要求网络 PHY 必须采用以太网标准，并要求交换机具备现代以太网功能。

一个关键的构建模块是 Open Fabric Interfaces，也被称为 LibFabric。理解 LibFabric 可以帮助理解 UEC 规范的前 120 页。LibFabric 作为已经被广泛采用的 API，实现了 NIC 使用的标准化。现有的绑定或插件将 LibFabric 与高性能网络库连接起来，如 NCCL（来自 Nvidia）、RCCL（来自 AMD）、MPI（超级计算并行通信的鼻祖）、SHMEM（共享内存）和 UD（不可靠数据报）——这些都是 AI 或 HPC 超级集群所需的网络风格。

UEC 并不是一项全新的发明。相反，它是在已有的开放标准基础上构建的，为其运行定义了一个可互操作的框架。互操作性显然是核心关注点，因为 UEC 对 API 如何与 CPU 或 GPU 协作没有任何限制。LibFabric 围绕用于数据传输、接收和特殊值的命令队列以及完成队列展开。这种基于队列的 NIC 交互方式已经有 40 多年的历史。UEC 并不规定这些队列如何与 GPU 或 CPU 构建，但要求支持所有 LibFabric 命令：发送、接收、RDMA、原子操作和特殊命令。超过 100 页的文档详细说明了这些命令如何封装在消息头中，以确保不同厂商的 NIC 之间能够兼容执行。这实际上将 LibFabric 从 CPU/GPU 上的软件栈转变为 NIC 上的硬件加速命令集。

从 LibFabric 中提取并集成到 UEC 的一个关键概念是“作业（Job）”。作业代表分布在多个端点上的一组协作进程。虽然在功能上类似于 VXLAN，但它在 UEC 网卡中使用的是 Fabric End Points（FEPs），而不是以太网 VXLAN。单个网卡可以承载多个 FEP，但每个 FEP 只分配给一个作业，并且只能与具有相同 JobID 的其他 FEP 进行交互。受信任的 fabric 服务负责管理这些作业及其相关 FEP 的创建和终止。作业还可以包含加密域，实现安全的流量隔离。对于需要灵活成员管理的作业，也有相应的支持，以适应动态服务环境。这些 LibFabric 的概念和命令是强制性的组成部分。

接下来，UE 传输层负责将 LibFabric 命令和数据信息传递到 FEPs，这一过程可能通过以太网进行，但理想情况下会有可选层的支持。

分组层：第3.2节

规范在第 3.2 节变得真正有趣，这一节详细介绍了分组层。虽然没有明确注明，但这一层似乎大量借鉴了厂商在模块化交换机方面的丰富经验。它涉及将 LibFabric 消息分割成更小的数据包，并灵活地进行路由，同时明确考虑了可靠性和流量控制。UEC 的一个明确目标是将这些功能集成到传输层中。数据中心的延迟极低，因此需要硬件加速的错误恢复和流量控制，以实现最佳、平稳的流量。数据包会引入额外的头部信息，但有助于在 NIC 和交换机之间交换网络运行信息，而不依赖于消息流。在模块化交换机中，第二层内部交换机通过数据包来处理这些信息；而 UEC 则依赖于由 NIC 生成、具备增强流量控制的数据包，并通过增强型以太网进行传输。 %%

UEC 专为“胖”网络设计，其特点是在 FEP 之间存在多条等距且速度相同的路径。一种常见的现代实现方式是“轨道”配置。在 UEC 网络中，这可能涉及一块带有 800GbE 接口的 NIC，该接口由 8 条 100 Gbps 的通道组成。在交换机机架处，这 8 条通道中的每一条都连接到不同的交换机，比如 8 台交换机，每台都有 512 个 100G 端口。这允许多达 512 个 FEP 通过这 8 个端口连接。UEC NIC 被设计为通过分配一个“熵”编号，将消息分散到所有 8 条通道上，该编号在路径中每次选择输出通道时进行哈希。发送方选择一个熵值，以平衡各路径的使用，从而充分利用 800 Gbps 的吞吐量。关键在于，CPU 或 GPU 应用程序无需了解这些复杂性；它们只需通过 LibFabric 排队消息，NIC 则负责实现“轨道的魔法”。

Rail 魔法使得 512 端口交换机（目前流行的选择）可以并行使用，采用相同的拓扑结构，从而获得多倍的吞吐量。重大进步在于，端点由 UEC 在单个 NIC 内进行协调，使主机能够看到更大的吞吐量，而 NIC 则将流量分配到所有路径上。宽广的交换机基数对于构建大型集群非常宝贵，而一致的拓扑结构则简化了网络的构建和管理。UEC NIC 被设计为能够处理多层交换机的路由。额外的好处是，多路径上的数据包使 UEC NIC 能够提供极快的丢包替换和超高速流量控制，即使在应用调度不理想或偶发网络链路抖动的情况下，也能确保流量顺畅。

第 3 节到第 3.4 节详细介绍了数据包和报头的构建方式，并与 LibFabric 语义有一定关联。报头可能相当大，最大可达 44 字节，但针对频繁且较短的数据包，经过优化的报头最小可至 20 字节。在 UEC 预期的最低通道速率 100Gbps 下，20 字节（160 位）大约对应 1.6 纳秒。虽然 UEC 的最大吞吐量会低于裸以太网的理论最大值——模块化交换机通常采用稍快的背板以吸收数据包开销——但 UEC 的以太网本身就充当了背板，因此用户数据速率会略慢。这种权衡是为了实现几乎完美的数据流动，通常会提升实际数据速率。

第 3.5 节（第 219 页！）深入探讨了数据包操作的具体细节。与命令和队列不同，这部分是 UEC 独有的。文中对其进行了全面的规范，显然借鉴了模块化交换机的经验，但没有提供外部参考资料，这表明其设计是基于共识，而非源自某一市场上的单一解决方案。考虑到 UEC 依赖以太网作为背板，而现代模块化交换机使用的是专有背板，这样的做法也很合理。

连接是在即时建立的，无需 ACK（确认收到的回复）开销，因为消息会被分片成数据包。虽然同一条消息的所有数据包都会沿着相同的已选通道传输（便于修复和重组），但不同的消息本身可以并且会被分散到不同的通道上。通道的选择由报文头中的“熵”值引导（与真正的熵无关），该值代表路由选择，并带有关联的流量控制。

当启用加密时，建立数据包连接会产生一些开销（需要强制的往返确认）。实际性能需要在加密情况下进行基准测试。希望这部分开销不会太大。

丢失的数据包通过序列号推断，并通过特定请求进行替换，这在数据中心是合理的做法，因为数据中心的丢包率预计极低（否则就说明存在更大的系统性问题）。

拥塞控制：UEC-CC（第 3.6 节）

第 3.6 节介绍了 UEC-CC，这是一套拥塞管理系统——虽然是可选的，但却是选择 UEC 的核心原因之一。这里的设计选择非常明智。UEC-CC 采用基于时间的机制，转发延迟精度可达亚 500 纳秒。前向和后向路径会被独立测量，这意味着网卡需要在绝对时间上同步，尽管规范中并未明确说明。双向测量能够准确地将拥塞归因于发送方和接收方。如果启用 UEC-CC，交换机必须使用 ECN（显式拥塞通知），并且应采用现代 ECN 变体，即在每个流量类别上设置拥塞标志，并在数据包发送前立即测量。这能提供最新的拥塞信息，并针对不同流量类别进行差异化处理。在严重拥塞时，数据包可以被裁剪，仅保留墓碑头部，以明确告知接收网卡出现了问题——单纯丢弃数据包会减缓纠正措施的响应速度。

这种机制至关重要，因为接收端 FEP（每个 NIC 有一个或多个）负责控制发送端的发送速率。在数据中心仅有几微秒的往返时延（RTT）下，发送端在未收到 ACK 的情况下只能在极短的时间窗口内发送数据。接收端决定授予多少新数据包，从而可以在几微秒内暂停发送端，通常能够防止数据丢失。接收端通过 ECN 标志收集丰富的流量状况信息，这些信息分布在多个通道和流量类别中，使其既能获得单独的信用计数，也能掌握所有到达数据的整体情况。接收端通过 ACK 和一种特殊的 Credit CP 命令将其决策传达给发送端。

这些决策还可以通过调整特定的“熵容量”来重新平衡路由，从而改变用于消息喷洒的平衡方式。UEC 对（前向）纠错率和丢包情况的某种程度的报告进行了标准化，使得能够检测到使用弱链路的特定熵，并将流量重新路由以避开该链路。熵在每个交换机处对跳数选择进行哈希处理，预计熵的数量将比通道多一个数量级，这样就可以在对整体路由容量影响最小的情况下隔离出弱链路。

关键的是，UEC-CC 废弃了一些流控方法。广泛使用的旧方法 RoCE 和 DCQCN 会降低 UEC-CC 的性能，因为与 UEC-CC 不同，它们不会直接根据流量问题的实际位置来更新流控。PFC（优先级流控）是没有必要的，必须在交换机之间禁用，否则会阻塞有效流量。在网卡与交换机连接处也不推荐使用 PFC，因为它缺乏 UEC-CC 的精确性，可能会过度减少流量。基于信用的流控同样被废弃，因为它会干扰 UEC-CC 的工作。

传输安全子层（第3.7节）

第 3.7 节，传输安全子层，内容极为技术化，显得非常专业。它大量借鉴了经过验证的方法，同时融入了实用的更新。推荐的加密算法是后量子 DES 密码。对防御性操作给予了高度重视，制定了定期更换随机数的规则。加密按域分配，即作业内 FEP 的一个子集，并包括支持动态服务的自适应域变体，允许客户端动态加入和离开。一种巧妙的密钥派生方案允许整个域内使用单一密钥，每个流都采用不同的密钥和随机数，但所需的表空间极小（一个作业可以有数万个端点）。

数据中心结构必须包含受信任的组件：一个安全域管理实体，用于设置域，以及包含用于其端口接入域的受信任硬件的 NIC。虽然验证和证明这些组件的版本超出了 UEC 规范的范围，但已有开放标准可供厂商支持。

第3.8节为第3.7节提供了一个有用的参考文献列表。

其他层

第 4 节，UE 网络层，主要讨论了分组修剪，这是一项用于拥塞控制的可选功能。

第 5 节，UE 链路层，旨在通过链路级分组替换和交换机之间的流量控制来提升整体性能。在我看来，这属于不必要的复杂性，尤其是在 UEC-CC 部分已经弃用 CBFC（本层实现的功能）的情况下。在数据中心中，往返时延只有微秒级，接收端 FEP 能够利用全局流量信息做出高质量的流控决策，丢包现象极为罕见，UEC 本身也能在修复调度期间绕过丢包（第 6 节对此有所帮助！）。这一部分规范似乎增加了复杂性，却没有带来相应的价值。幸运的是，这部分是可选的，我敢打赌它永远不会被广泛采用。它肯定会让测试和即插即用活动（多厂商互操作性会议）变得更加复杂。

第 6 节，UE 物理层，主要推荐多通道 100Gb 以太网，遵循 802.3/db/ck/df 规范。文中简要致歉，指出由于 200Gb 尚未正式发布，无法引用。UALink 规范引用 200Gb 没有问题，而这正是行业的发展方向。UEC 应该以此为起点，而不仅仅是最终目标。

第 6.3 小节探讨了使用 FEC（前向纠错）遥测来监控和评估链路级别的可靠性。对于任何网络爱好者来说，这都很有趣，但核心很简单：FEC 极其高效，在正确初始化的数据中心链路上，丢包现象极为罕见。很高兴在规范中看到这一点。

UEC：主要优势

总的来说，采用 UEC 的有力理由包括：

• 硬件加速的 LibFabric。
• 与现代加密技术集成的精心设计的作业结构。
• 数据中心拥塞控制，正确实现。
• 消除了有问题的 RoCE 和 DCQCN。
• 现有的开源插件支持 CCL、MPI、SHMEM 和 UD。

UEC：注意事项

值得注意的是，针对使用 LibFabric 的 Amazon EFA 网络的插件支持并不简单。虽然提供了插件配置，但英伟达的态度往往并不支持，尽管支持底层接口，却更倾向于自家的专有解决方案。据称该插件在 EFA NIC 上表现良好，但在更新的 UEC NIC 上的性能还有待观察。

必须检查通用互操作性，不仅要看“能用”，还要确保当端点来自不同厂商时性能依然可靠。同样值得关注的是，当中间网络不是 UEC 时，UEC NIC 的表现如何——前提是你确保交换机支持 UEC 所使用和要求的最佳实践 ECN 生成等功能。

与 UALink 和 SUE 的对比

Ultra-Accelerator Link 的规范长度不到 UEC 的一半，尽管两者的编写都同样严谨。Broadcom Scale-Up Ethernet 的描述虽然细致但较为非正式，只有短短 20 页，并且假定其所描述的内容简单明了。

UALink 和 SUE 都专注于 ScaleUp，类似于 Nvidia 的 NVLink。它们仅支持单一交换机层级，最多可连接 1024 个端口（即 GPU 或 xPU）。相比之下，这比 UEC 旨在实现多层交换机、数万个端点的扩展型网络要受限得多。这三种规范都假设 AI 或 HPC 集群采用最大化交换机端口数的轨道网络。

SUE 和 UALink 在其规范中自信地提及 200GbE 链路，这让 UEC 显得有些落后。

UALink 和 UEC 一样，将流量分散到多条通道上。UALink 明确详细说明了基于信用的流量控制。而 SUE 则将此推迟，建议在以太网内部通过客户端软件来实现——规范更为简单，但实际效果大致相同。UALink 将 4 条通道绑定在一起（例如 4×200），以实现更快的消息传输，而 SUE 和 UEC 都认为 200G 通道已经足够快。这是 UALink 在复杂性上多出的一点，但其价值似乎有限。

SUE 建议以太网通过 PFC 或更优选的基于信用的流量控制（CBFC）来处理流量控制。鉴于 PFC 在单一交换机层面上最为有效，这种方法肯定是可行的，而 CBFC 则能带来更平滑的运行效果。

UALink 为连接实现了加密。SUE 则更简单地表示，可靠性、数据完整性和加密应由以太网提供。

SUE 将消息喷洒和跨轨道负载均衡的任务委托给端点内部的软件层。这对于专注于此类软件的公司来说显然是一个优势。

SUE 和 UALink 都提供内存映射接口。两者的规范都没有规定内存映射的具体实现方式，但它们都期望通过读取或写入对应于大型虚拟系统中另一个端点的内存地址来实现消息的发送和接收。这些接口的效率应与 NVLink 相当，但由于它们没有复制 NVLink 的数据包格式，因此需要插件或新的底层代码支持。

内存映射与主机互连

内存映射通常被称为“内存语义”。映射——使用大型虚拟地址空间为每个主机分配其独有的可识别范围——允许主机处理器使用读写指令，即内存操作 。但它们不包括诸如顺序性和一致性等内存语义 。没有进行内存嗅探，也不会在集群中智能地更新缓存。

对于包括 UEC 在内的所有这些系统来说，数据中心对运行速度和低延迟的需求正在促使端点转变为主机芯片内部结构上的协处理器，而不再是通过日益过时的“IO 总线”远距离连接。现在的端点（NIC）更像是多核系统中的另一个核心。这简化了计算核心（流式 GPU 或传统 CPU）发送指令以及端点与主机内存交互的高效互操作。

我们可以预期，SUE 和 UALink 会作为 IP 模块集成到主机芯片中，而不是作为独立芯片出现。NVlink 早就采用了这种方式，像 Intel Gaudi 3 或 Microsoft Maia 100 这样的芯片也通过以太网连接实现了这一点。这简化了 IP 模块，但要求它们足够简单，以减少在主机芯片中的占用空间。UEC 的复杂性很可能会体现在独立的 NIC 上，但很快也应该会集成到主机互连结构中。也许会以小芯片（chiplet）的形式出现？