摘要：今天，超级以太网联盟 (UEC)宣布发布UEC 规范 1.0，这是一个基于以太网的全面通信堆栈，旨在满足现代人工智能 (AI) 和高性能计算 (HPC) 工作负载的严苛需求。此次发布标志着我们朝着重新定义下一代数据密集型基础设施以太网迈出了关键一步。

今天，超级以太网联盟 (UEC)宣布发布UEC 规范 1.0，这是一个基于以太网的全面通信堆栈，旨在满足现代人工智能 (AI) 和高性能计算 (HPC) 工作负载的严苛需求。此次发布标志着我们朝着重新定义下一代数据密集型基础设施以太网迈出了关键一步。

UEC 规范 1.0 为网络堆栈的所有层（包括 NIC、交换机、光纤和电缆）提供了高性能、可扩展且可互操作的解决方案，从而实现了无缝的多供应商集成并加速了整个生态系统的创新。

UEC 规范正在推动整个行业的采用，通过推广开放、可互操作的标准来避免供应商锁定。随着积极的实施和合规计划的推进，UEC 正在为整个行业建立一个统一且易于访问的生态系统铺平道路。

超级以太网联盟技术咨询委员会主席 Hugh Holbrook 补充道：“超级以太网 1.0 规范是人工智能、高性能计算 (HPC) 和网络专家、系统和芯片供应商以及网络运营商通力合作的成果。它融合了与应用、传输协议、拥塞控制、直接内存访问、以太网链路和 PHY 技术以及网络安全相关的丰富知识、经验和理念。这对行业而言是一个里程碑式的发展，我非常高兴超级以太网的公开发布，这将进一步推动以太网在人工智能和高性能计算领域的成功。”

随着 AI 和 HPC 工作负载以前所未有的速度不断发展，UEC 的专用以太网创新实现了：

用于以太网和 IP 的现代 RDMA – 支持高吞吐量环境的智能、低延迟传输。

开放标准和互操作性——避免供应商锁定，同时加速整个生态系统的创新。

端到端可扩展性——从路由和配置到操作和测试，UEC 可扩展到数百万个端点。

专为现实世界集成而设计

UEC 1.0 基于全球采用的以太网标准，简化了从硬件到应用程序的整个技术栈的部署。它易于理解，并配备强大的工具，对于寻求低摩擦采用路径的云基础设施运营商、超大规模企业、DevOps 团队和 AI 工程主管来说尤其有价值。

“作为超级以太网联盟主席，我很荣幸地宣布发布 UEC 1.0 规范——这是我们在人工智能和高性能计算时代重新定义以太网使命中的一个重要里程碑，”超级以太网联盟指导委员会主席 J Metz 博士表示。“这项标准是整个行业前所未有的合作成果，它提供了当今和未来最苛刻的工作负载所需的低延迟、高带宽和智能传输。UEC 1.0 的发布仅仅是一个开始——超级以太网已经到来，它旨在扩展未来。”

在 GenAI 热潮初期，标准以太网的市场份额一度被 Nvidia 的 InfiniBand 抢占。此后，以太网开始重新夺回市场份额，这主要得益于成本、InfiniBand 的各种缺陷，以及在以太网基础上添加更多功能和定制的能力。

那这个新标准，会带来新变化吗？

超级以太网联盟候选版本 1：

深入审查

超级以太网联盟 (UEC) 候选版本 1 是一份内容丰富的文档，长达 565 页，于今日公开发布。这与优先考虑简洁性的 Ultra Accelerator Link v1 规范形成了鲜明对比。UEC 本质上并不简单；直接通读几乎难以理解。然而，通过结构化的方法可以揭示其底层逻辑。

UEC 项目旨在为以太网网卡和交换机提供传输层和流量控制层，以改善其在大型快速数据中心网络中的运行。传输层确保用户内容从源头传输到目的地，并承载现代人工智能或高性能计算 (HPC) 用户所需的所有命令。流量控制层确保数据以最佳速度流动，防止流量拥堵，并绕过故障或慢速链路进行重新路由。网络接口卡必须实现 UEC 才能正常工作。交换机是可选的，网络部分可以使用现有的以太网交换机。UEC 规范经过精心设计，因此不同供应商的设备应该能够互操作。

UEC上下文和核心块

UEC 在 Linux 联合开发基金会 (JDF) 下运营，并作为标准开发组织 (SDO) 运作。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（不可靠数据报）——这些网络类型是人工智能或 HPC 超级集群所必需的。

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

“作业”（Job）是源自 LibFabric 并集成到 UEC 的一个关键概念。作业代表一组分布在多个端点上的协作进程。虽然功能上与 VXLAN 类似，但它利用的是 UEC 网卡内的交换矩阵端点 (FEP)，而非以太网 VXLAN。单个网卡可以承载多个 FEP，但每个 FEP 都分配给一个作业，并且只能与共享相同作业 ID 的其他 FEP 交互。可信交换矩阵服务负责管理这些作业及其关联 FEP 的创建和终止。作业还可以包含加密域，从而提供安全的流量隔离。此外，还提供了具有灵活成员资格的作业，以适应动态服务环境。这些 LibFabric 概念和命令是必需组件。

接下来，UE 传输层负责将 LibFabric 命令和数据内容传送到 FEP，可能通过以太网，但理想情况下最好有可选层的支持。

数据包层：第 3.2 节

该规范真正有趣的地方在于3.2节，该节详细介绍了数据包层。虽然没有明确提及，但该层似乎大量借鉴了供应商在模块化交换机方面的丰富经验。它涉及将LibFabric消息分块成更小的数据包并灵活地路由，同时明确考虑了可靠性和流量控制。UEC的既定目标是将这些功能集成到传输层。数据中心的延迟非常低，因此需要硬件加速的错误恢复和流量控制才能获得最佳、流畅的流量。数据包引入了额外的报头，但有助于在网卡和交换机之间交换网络操作信息，而这与消息流无关。在模块化交换机中，交换机的第二层（内部层）通过数据包处理此操作；然而，UEC依赖于网卡生成具有增强流量控制的数据包，并由增强以太网承载。

UEC 专为“fat”网络而设计，其特点是 FEP 之间具有多条等距且速度相同的路径。一种常见的现代实现是“rail”配置。在 UEC 网络中，这可能涉及一个 NIC，例如，一个 800GbE 接口，包含 8 个 100 Gbps 通道。在交换机机架上，这 8 个通道中的每一条都连接到不同的交换机，也许是 8 个交换机，每个交换机有 512 x 100G 端口。这允许最多 512 个 FEP 连接到这 8 个端口。UEC NIC 旨在通过分配一个“entropy”数在所有 8 个通道上“spray”消息，该entropy数在路径中每次选择输出通道时对通道分配进行哈希处理。发送方选择一个entropy值来平衡路径的使用，以填满完整的 800 Gbps 吞吐量。至关重要的是，CPU 或 GPU 应用程序仍然不知道这种复杂性；他们只是通过 LibFabric 对消息进行排队，然后 NIC 处理“magic of rails”。

Rail magic 支持 512 端口交换机（目前较为流行的选择）以相同的拓扑结构并行使用，从而获得多倍吞吐量的优势。最大的进步在于，端点由单个网卡内的 UEC 进行协调，这样主机就能感知到巨大的吞吐量，而网卡则会将流量分配到所有路径上。广泛的交换机基数对于构建大型集群至关重要，而一致的拓扑结构则简化了网络的构建和管理。UEC 网卡经过精心设计，甚至可以处理跨多个交换机层的路由。此外，多路径上的数据包使 UEC 网卡能够提供极快的丢失数据包替换和超快的流量控制，即使在应用程序调度不理想或偶尔出现网络链路抖动的情况下也能确保流量顺畅。

第 3 节至 3.4 节详细介绍了数据包和报头的构造，并与 LibFabric 语义有所关联。报头可能很长，最多可达 44 字节，但针对频繁传输的较短数据包优化后的报头可以小至 20 字节。在预期最低的 UEC 通道速度 100Gbps 下，20 字节（160 位）转换为大约 1.6 纳秒。虽然 UEC 的最大吞吐量将低于裸以太网的理论最大值（模块化交换机通常使用速度稍快的背板来吸收数据包开销），但 UEC 的以太网充当背板，导致用户数据速率略低。这种权衡是为了实现近乎完美的流量，这通常应该会提高实际数据速率。

3.5 节（第 219 页！）深入探讨了数据包操作的细节。与命令和队列不同，这是 UEC 独有的。它似乎规范详尽，显然借鉴了模块化交换机的经验，但没有提供任何外部参考，这表明它是一种共识设计，而非源自任何单一市场解决方案。考虑到 UEC 依赖以太网作为背板，而现代模块化交换机使用专有背板，这也合情合理。

由于消息被分片成数据包，连接可以即时建立，无需 ACK（确认接收的回复）开销。虽然同一条消息的所有数据包都遵循相同的选定通道（以便于修复和重组），但消息本身可以且将会被分散到不同的通道上。通道选择由报头中的“熵”值（与真实熵无关）决定，该值代表路由选择并具有相关的流量控制。

启用加密后，建立数据包连接会产生一些开销（强制往返 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 命令将其决定传达给发送方。

这些决策还可以通过调整特定的“entropy capacities”来重新平衡路由，从而改变用于消息喷洒的平衡。UEC 在一定程度上标准化了（前向）纠错率和丢包率的报告，从而能够检测使用弱链路的特定熵（entropy），并重新路由流量以避免这种情况。熵会在每个交换机上计算哈希跳跃选择，预计熵的数量级将比通道数量高出一个数量级，从而能够在最大程度上隔离弱链路，同时最大程度地降低对整体路由容量的影响。

至关重要的是，UEC-CC 弃用了一些流量控制方法。广泛使用的旧方法 RoCE 和 DCQCN 会降低 UEC-CC 的性能，因为与 UEC-CC 不同，它们不会直接更新流量控制以匹配流量问题的实际位置。优先级流量控制 (PFC) 没有必要，必须在交换机之间禁用，因为它可能会阻塞有效的流量。当网卡连接到交换机时，它也已被弃用，因为它缺乏 UEC-CC 的精度，并且可能会过度减少流量。基于信用的流量控制同样由于与 UEC-CC 的干扰而被弃用。

传输安全子层（第 3.7 节）

第 3.7 节“传输安全子层”技术性很强，而且看起来非常完善。它大量借鉴了成熟的方法，并融入了实用的更新。推荐的加密算法是后量子 DES 密码。防御性操作尤为重要，并制定了定期随机数 (nonce) 更改的规则。加密按域分配，域是作业中 FEP 的子集，其中包括一个用于自适应域的变体，支持客户端加入和离开的动态服务。巧妙的密钥派生方案允许在整个域中使用单个密钥，每个流都使用不同的密钥和随机数，同时最大程度地减少表空间占用（作业可以包含数万个端点）。

数据中心结构必须包含可信组件：用于设置域的安全域管理实体 (SDM)，以及包含可信硬件的网卡 (NIC)，用于将其端口连接到域。虽然验证和证明这些组件的版本超出了 UEC 规范的范围，但可以要求供应商支持现有的开放标准。

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

其他层

第 4 节，UE 网络层，主要讨论数据包修剪，这是拥塞控制的可选功能。

第 5 节，即 UE 链路层，旨在通过链路级数据包替换和交换机之间的流量控制来提升整体性能。我认为这会增加不必要的复杂性，尤其是在 UEC-CC 部分弃用了 CBFC（该层实现的）。在往返时间达到微秒的数据中心中，接收方前端端点 (FEP) 会根据全局流量信息做出质量流量控制决策，数据包丢失很少，并且 UEC 已经能够在按计划进行修复的同时绕过这些数据包（第 6 节很有帮助！）。规范的这一部分似乎增加了复杂性，却没有相应的价值。幸运的是，它是可选的，我敢打赌它永远不会被广泛使用。它肯定会使测试和互操作性测试（多供应商互操作性会议）变得复杂。

第6节，即UE物理层，主要推荐遵循802.3/db/ck/df规范的多通道100Gb以太网。简短的致歉指出，由于200Gb并非官方标准，因此无法引用。UALink规范引用200Gb没有任何问题，而且这正是当前的趋势。UEC应该以此为起点，而不是仅仅达到目标。

6.3 小节探讨了如何使用 FEC（前向纠错）遥测技术来监控和评估链路级可靠性。虽然 FEC 对任何网络爱好者来说都极具吸引力，但其要点很简单：FEC 非常有效，能够让正确初始化的数据中心链路上出现丢包的情况变得极其罕见。很高兴在规范中看到它。

UEC：主要优势

综上所述，采用UEC的令人信服的理由包括：

硬件加速的 LibFabric。

精心设计的工作结构与现代加密技术相结合。

数据中心拥塞控制，正确实施。

消除有问题的 RoCE 和 DCQCN。

现有的 CCL、MPI、SHMEM 和 UD 开源插件。

UEC：注意事项

值得注意的是，使用 LibFabric 的 Amazon EFA 网络插件支持并非易事。虽然提供了插件配置，但 Nvidia 的立场往往并不支持，尽管支持底层接口，但仍然倾向于使用其专有解决方案。据报道，该插件在 EFA 网卡上获得了良好的性能，但在较新的 UEC 网卡上的性能仍有待观察。

必须检查通用的互操作性，不仅要检查“是否正常工作”，还要检查当端点来自不同供应商时性能是否稳定。当中间网络不是 UEC 时，检查 UEC 网卡的工作情况也很有用——只要确保交换机支持 UEC 确实使用和要求的功能，例如最佳实践的 ECN 生成。

与 UALink 和 SUE 的比较

尽管编写过程同样细致，Ultra-Accelerator Link 的规格说明长度还不到 UEC 的一半。Broadcom Scale-Up 以太网的描述则细致但不拘泥于形式，只有 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 或基于信用的流量控制（最好是）来处理流量控制。考虑到 PFC 在单交换机级别最有效，而 CBFC 可以提供更顺畅的运行，这种方法肯定有效。

UALink 实现了连接加密。SUE 更简单地指出，以太网应该提供可靠性、数据完整性和加密。

SUE 将消息喷洒和跨轨道负载均衡委托给端点内的软件层。这对于专门从事此类软件的公司来说无疑是一大优势。

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

内存映射和主机结构

内存映射通常被称为“内存语义”。映射——使用一个大型虚拟地址空间为每个主机分配其自身可识别的范围——允许主机处理器使用读写指令和内存操作。它们不包含诸如排序和一致性之类的内存语义。不会发生内存侦听，也不会对集群周围的缓存进行智能更新。

对于包括 UEC 在内的所有这些系统，数据中心的运行速度和低延迟正在促使端点迁移到主机芯片结构上的协处理器，而不是通过日益过时的“IO 总线”进行远程控制。这更像是将端点（NIC）视为多核系统中的一个核心。这简化了计算核心（流式 GPU 或经典 CPU）之间发送命令以及端点与主机内存交互的高效互操作。

我们可以预期 SUE 和 UALink 将以集成到主机芯片中的 IP 块形式出现，而不是将它们作为单独的芯片。NVlink 已经存在一段时间了，英特尔 Gaudi 3 或微软 Maia 100 等芯片也通过以太网链路实现了这种功能。这简化了 IP 块，但也要求它们足够简单，以减少在主机芯片中的占用空间。UEC 的复杂性可能会体现在单独的 NIC 中，但很快就会集成到主机架构中。或许是以 chiplet 的形式？

*免责声明：本文由作者原创。文章内容系作者个人观点，半导体行业观察转载仅为了传达一种不同的观点，不代表半导体行业观察对该观点赞同或支持，如果有任何异议，欢迎联系半导体行业观察。

来源：半导体行业观察一点号