摘要

  • Ultra Ethernet Consortium 是 Joint Development Foundation 下的一个项目，于 2023 年 7 月 19 日由 AMD、Arista Networks、Broadcom、Cisco、Eviden/Atos、Hewlett Packard Enterprise、Intel、Meta 和 Microsoft 共同启动。它是一个制定规范的产业联盟，既不是普通的公司，也不是网络运营商。
  • UEC 的范围远不止打造一条更快的以太网链路或替代 RoCE。厚达 573 页的 1.0.3 版规范覆盖了软件、传输、网络、链路和物理层，还延伸至管理、存储、测试与合规性等方面。
  • Ultra Ethernet Transport 融合了多种交付模式、数据包级多路径、选择性重传、发送端与接收端驱动的拥塞控制、ECN、可选的 Packet Trimming、可选的本地链路重传、可选的基于信用的流量控制以及可选的端到端传输安全。
  • AMD、Broadcom、Nokia 和 Keysight 推出的产品和演示表明，相关工作已经开始落地。不过，公开合规性目前主要仍依赖实现方自行声明；尚未看到全面的独立认证登记册，也未发布大规模部署的调查报告。
  • UEC 的战略机遇在于以太网已有的庞大部署量和多供应商供应链。最大的风险则来自端点复杂性、可选功能带来的碎片化、RAND 专利义务、尚未成熟的管理与测试，以及已发布规范与生产环境中经过验证的互操作性之间的落差。

为什么 AI 已经让网络成为计算机的一部分

Ultra Ethernet Consortium 源于计算经济的一次转变。在普通的企业网络中，交换架构应能以可接受的吞吐量和可用性承载大量彼此独立的数据流。而在大型 AI 训练系统或高性能计算机中，网络则会成为一大块同步计算的一部分。成千上万的加速器会通过集合操作交换模型参数、梯度或科学数据。某一个阶段可能要等到最慢的参与者收到所需信息后才能继续。因此，哪怕只是路径间轻微的不均衡、一次拥塞事件或一个丢包，就可能让昂贵的处理器闲置等待，尽管此时架构的平均利用率看上去还很健康。

这也改变了运营商的优化目标。总体带宽依旧重要，但已不再足够。同样关键的是作业完成时间、尾部延迟、Incast、丢包恢复、将流量分摊到多条并行路径，以及端点需要维护的状态量。一个网络如果能快速交付几乎所有的数据包，却让一小部分出现延迟，就足以拖垮整个集合操作。在传统流量下可以接受的丢包重传机制，如果仅仅因为一条长消息里缺少了一个数据包而浪费大量时间，就不再合适。一旦一条流被绑定在单一的等价路径上，它就可能表现不佳，而拓扑结构的其他地方明明还有空闲容量。

UEC 创立时的基本判断是，这些问题无法仅靠某个新的交换机功能或某个改进的拥塞算法来解决。通信路径始于网络之上，端于软件库和应用语义。它贯穿内存注册、远端操作、传输状态、数据包交付、拥塞控制、IP 转发、以太网链路、光学器件和物理层信令。如果这些层次被孤立地设计，一个地方的优化可能只是把瓶颈推到另一处，或在其他层次引入不兼容的假设。

UEC 的回应是一套协调一致的架构。它保留以太网和 IP，因为运营商了解这些技术，而且围绕交换机、光学器件、线缆、网络操作系统、遥测和管理已经形成了庞大的供应链。与此同时，它也在那些 UEC 认为不足以支撑大规模 AI 和 HPC 工作负载的地方做出修改或扩展。最终得到的结果并不是“换了个标志的普通以太网”，而是尝试让一张人们熟悉的网络承载起一种专用传输，其行为从软件 API 一直到通道速率都被明确定义。

这一区别解释了 UEC 对数字基础设施的意义。这个项目并不拥有加速器、工厂、数据中心或云区域。它所定义的是那些成员公司及其他实现方可以嵌入到 NIC、交换机 ASIC、系统、驱动、库和测试设备中的规范。只有当这些彼此独立的产品在面对故障、拥塞、升级和混合供应商组合时能够正确交换数据，影响力才会真正兑现。

UEC 是什么，不是什么

Ultra Ethernet Consortium 是一个正式项目的公开名称，其法律序列为 Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series。这种序列结构将项目归入 Joint Development Foundation 和更广泛的 Linux 基金会家族。它提供了现成的法律框架，涵盖会员资格、治理、知识产权、资金和对外关系，参与者无需为此成立新的独立实体。

这一结构很重要，因为 UEC 常被不准确地描述为公司、联盟或标准制定组织。它并非拥有股东、股权、估值或独立财务报表的商业实体。它不销售以太网产品，不运营公共网络，也不拥有其成员正在推广的硬件。它是一个拥有法律和知识产权框架的规范制定联盟。其公开文献旨在成为多家企业之间的实现约定。

UEC 同样不等同于 Ultra Ethernet Transport。UET 是规范核心的传输架构，但 UEC 的工作范围更广，包括通过 libfabric 的软件映射、数据包与消息语义、网络假设、链路层选项、物理层要求、管理、存储协调、性能与调试、合规性以及测试。把它简化为“一种新的 RDMA 协议”，会掩盖这种跨层设计的真正面目，而这套设计既雄心勃勃又相当困难。

UEC 也不是 IEEE 802.3 工作组。IEEE 802.3 按照自己的正式流程制定基础以太网 MAC 和 PHY 标准。UEC 依赖并与此生态保持联络，而非取而代之。同样的边界也适用于 UET 下面的 IETF 机制，包括 IPv4、IPv6 和显式拥塞通知；适用于维护 libfabric 的 OpenFabrics 生态；也适用于从事存储、开放硬件和加速器互联工作的各类组织。

该项目的网站曾使用过某些措辞，让人感觉它已具备国际标准组织的地位。更可靠也更充分的描述是：UEC 是一个在 JDF 框架下运作的国际规范制定组织。没有证据表明 UEC 属于国际标准化组织，其文献是 ISO 标准，或它拥有 ISO 标准编号。这种差异不仅是措辞上的，它还表明权威从何而来、参与如何运作，以及实现方可能面对的法律义务是什么。

因此，应根据 UEC 的实际职能来评判。它协调竞争对手和运营商围绕共同的技术设计展开工作，发布规范，管理工作组和已披露的专利义务，制定合规文件并维护与相邻组织的关系。但仅凭宣布，它既不能让产品实现互操作，也无法驱使市场采纳其架构。

由九家公司组成的创始联盟

该联盟于 2023 年 7 月 19 日由九家处于 AI 和 HPC 供应链不同位置的组织共同宣布成立：AMD、Arista Networks、Broadcom、Cisco、Eviden——当时与 Atos 关联——、Hewlett Packard Enterprise、Intel、Meta 和 Microsoft。这样的广度从一开始就是一种战略优势。仅由交换机厂商开发的传输可能忽略应用和端点边界；仅由加速器厂商主导的设计可能围绕某个硬件生态过度优化；仅仅来自云厂商的项目则可能缺少将架构转化为产品所需的芯片、光学和系统专长。

AMD 带来了处理器、加速器和端点网络能力。Arista 和 Cisco 贡献了大规模以太网交换和运营经验。Broadcom 提供了交换芯片、NIC 和高速 SerDes。HPE 和 Eviden 则拥有 HPC 系统及专用互联的历史。Intel 贡献了处理器、以太网和软件能力。Meta 和 Microsoft 代表了超大规模运营商，它们对提高大型 AI 集群的利用率并降低对单一集成供应商的依赖有着直接兴趣。

这一联盟内部同样存在彼此竞争的商业利益。成员企业销售 NIC、交换芯片、系统、云容量、光学器件、软件和支持服务。其中一些成员拥有实现 UEC 可能必需的多项专利。有些成员既从一个广泛的多厂商标准中受益，又同时可以通过差异化的私有功能盈利。因此，该联盟并未消除竞争，而是创造了一个舞台，让竞争对手可以就最低限度的接口达成一致，并继续在实现质量、性能、集成和商业条款上展开角逐。

HPE 的 Slingshot 互联是一个有用的技术渊源例证。Slingshot 是一种兼容以太网的商用 HPC 架构，具备自适应路由和拥塞管理能力。接近 HPE 的评论曾表示，一份“HPC 以太网”规范已经贡献给 UEC，并估计 UET 很大一部分源于 Slingshot 的传输思路。确切百分比未经独立证实，不应视作联盟的正式说法。但更广泛的看法有充分依据：UEC 并非从零开始，而是从 HPC、云网络、RDMA 以及以太网的生产经验中汲取了大量养分。

这种既有系统的混合体，也正是使用“开放”一词需要分外谨慎的原因。已获批准的 UEC 规范可以公开下载。架构本就是为了多厂商实现而设计。然而，该项目同样是一个成员贡献既有知识、专利和产品路线图的地方。文档本身的开放性并不能消除其技术的经济或法律条件。

一个支撑竞争对手合作的法律序列

Joint Development Foundation 的模式为 UEC 提供了正式的外壳，同时又没有把它变成一家普通的运营公司。该项目拥有自己的名称、范围、会员层级、指导委员会、工作组和知识产权义务。JDF 架构提供企业非营利基础设施，并可以持有项目资产和合同。这降低了组建联盟的成本，也让竞争对手有了一套被认可的合作流程。

指导委员会负责管理项目。其记录的职责包括协调工作组、吸纳会员、管理资产和财务、遴选或免除主席、监督进展以及管控公开发布和项目品牌。首选共识。如果无法达成共识，章程规定，在符合出席要求的合格会员中启动四分之三绝对多数机制。书面投诉可提交给主席。

首任主席是来自 Meta 的 Brad Booth。当前的 1.0.3 规范列出了来自 AMD 的 J Metz 为主席，来自 HPE 的 Barry Davis 为副主席，来自 Arista 的 Hugh Holbrook 为技术咨询委员会主席，以及来自 Marvell 的 Puneet Agarwal 为 TAC 副主席。Paul Congdon 被列为规范编辑。该文件还列出了物理层、链路层、传输层和软件层工作的负责人和作者。2026 年峰会日程还提到了更多运营负责人。这些角色未必替代规范中的正式头衔；一份完整的当前组织架构图尚未公开。

章程设有三类会员：指导会员、普通会员和贡献者会员。指导会员参与治理，通常任命代表加入指导委员会。普通会员可以在所有技术组中工作，但不参加指导委员会。贡献者会员在选定组别中参与，且在绝对多数决策中无表决权。当前的公开会员页面宣传普通和贡献者级别的年项目费分别为 20,000 美元和 5,000 美元，外加 Linux 基金会会员费。其对指导级别的加入途径或当前费用说明不够清晰。

正式权力的差异值得关注。广泛的会员基础可以带来专长和实现广度，但治理权力并非均匀分布。那些占据指导席位、向多个工作组派出工程师并能维护专利和产品议程的大公司，因此拥有比小型贡献者会员更大的实际影响力。非会员可以下载最终规范，但看不到完整的起草过程，也无法以同等条件参与。

内部项目信息并未按普通企业机密处理，但会员在相关委员会批准发布之前不得披露草案材料。这有利于竞争对手在非公开阶段讨论未成熟的想法，而不会过早向市场释放信号。与此同时，外部人士无法查看被拒绝的提案、表决记录、实施过程中的中间顾虑，或者隐藏于可选功能背后的协商。最终成果是开放的；通向终点的路径却仅仅部分可见。

从四个工作组到一份 573 页的规范

UEC 在 2023 年首次公开的架构聚焦于四个工作组：软件、传输、链路和物理层。这一顺序反映了端到端的抱负。成员资格并未立即以无限制公开邮件列表的形式开放。超过 200 家组织表达了兴趣，而联盟则分阶段开展入驻，并伴以流程和反垄断宣导。这种谨慎可以理解，因为参与者在多个市场上直接竞争，并且将讨论共同的产品和协议要求。

到 2023 年 12 月，UEC 报告已有约 40 家公司、超过 300 名参与者。它设立了技术咨询委员会，并扩展至八个工作组。TAC 的任务是保证架构的一致性：一项传输设计不能假定某种交换机行为、信令或 API，而这些又没有被其他工作组同意提供。到 2024 年 3 月，联盟报告已有 55 家公司和超过 750 名活跃参与者，并对计划中的架构给出了更清晰的描述。

三月份的更新引入了后来在正式规范中出现的概念：libfabric 作为软件侧 API，数据包喷洒，灵活排序，多种交付模式，发送端和接收端驱动的拥塞控制，ECN，数据包裁剪，链路层重传，可选的基于信用的流量控制，传输安全以及未来可能的网内集合操作。它还强调，UET 可以在现有以太网交换机上运行，而增强型交换机则能提供额外的性能。

机构覆盖范围随技术工作一同扩大。UEC 在 2024 年 7 月报告有 1,193 名活跃参与者，8 月报告有 97 个成员组织。这些都是基于未完全公开定义的历史数据，不能机械地累加到后续统计中。2025 年，UEC 表示又有 27 家公司加入；但退出、合并和统计周期重叠等因素使得无法得出精确的当前总数。该网站本身也提示，并非所有成员都会被显示出来。

2025 年 6 月 11 日，联盟发布了 Ultra Ethernet Specification 1.0。由此，UEC 从路线图变为了公开的实现基准。1.0.1 版本于 9 月跟进，修正了接收端信用控制的源算法以及若干编辑性问题。1.0.2 版本于 2026 年 1 月发布，修正了拥塞管理算法，而官方文献对其发布日期是 1 月 21 日还是 28 日存在矛盾。这一不一致应当保持可见，不应默默消除。

1.0.3 版本于 2026 年 7 月 16 日发布，是本次研究截止时的最新参考。它共 573 页，新增了对每通道 200 Gb/s 信令的支持以及一项布尔协商能力。发布说明还列出了数据包交付、拥塞信用、链路层重传和物理层控制序列集的必要修正，以及传输安全、原子操作和被裁剪数据包方面的澄清。必要修正与编辑性澄清之间的区别很重要：某些更改会影响合规行为，进而影响实现的维护。

在丹佛举行的 2026 年成员峰会展示了第二次转变。议程聚焦于部署、产品化、合规、管理、性能、调试、存储集成以及交换机和端点测试。核心架构文档已经存在；项目的可信度将越来越取决于：不同组织的实现方能否跨边界共同构建、认证、运行和升级整个协议栈。

跨越五个功能层的架构

现行规范将 Ultra Ethernet 划分为软件、传输、网络、链路和物理层。这种划分很有帮助，但该项目的真正价值在于把这些层连接起来的那些假设。

在顶层，AI 框架、MPI、SHMEM 和集合通信库通过 OpenFabrics 接口（尤其是 libfabric）进行交互。UET 语义服务子层负责将应用操作翻译为传输事务。数据包交付子层则决定消息如何被分片、排序、确认和恢复。拥塞管理层控制有多少数据进入架构，以及流量如何分布到各条路径。可选的传输安全保护端点之间的通信。标准的 IPv4 或 IPv6 完成网络层转发。以太网提供链路层，并可选支持数据包裁剪、链路层重传、基于信用的流量控制和功能协商。物理层定义了每通道 100 或 200 Gb/s 的统计和信令要求。

这种结构保留了现有网络的重要部分。UEC 并未定义 IP 路由的替代方案，而是期望沿用传统的 ECMP 和支持 ECN 的交换机。很多智能被置于网络架构端点中，由它们控制熵值、跟踪传输状态、安放数据并响应拥塞信号。增强型交换机可以增加功能，但该设计并不要求每次部署都必须更换全部架构后才能传输 UET 流量。

这带来了迁移上的优势，也制造了分类上的困难。一个部署可以在传统以太网上结合 ECMP 和 ECN 使用 UET 端点。另一个部署则可能增加裁剪、链路重传、每虚拟通道的信用、更丰富的遥测，以及日后引入的网内功能。两者都可以标榜为“Ultra Ethernet”，但它们的性能、恢复能力和运营复杂性可能相差甚远。

这种五层方法还让故障定位变得更难。糟糕的结果可能源自应用映射、端点状态机、拥塞参数、交换机队列配置、DSCP 映射、光学器件、固件或安全系统。仅仅会转发数据包是不够的。整个系统必须在规模扩展、混合流量、故障和版本变更面前，保持预期的语义和性能。

软件契约：用 libfabric 替代私有应用 API

UEC 选择 libfabric 2.0 作为合规端点的基本北向 API。这一决定将该项目与现有的 HPC 和高级网络生态联系在了一起，而不是迫使每个框架去适配一套新的私有接口。libfabric 已经定义好了 fabirc、域、端点、完成队列、事件队列、地址向量、内存区域、消息、远端内存操作以及原子操作。UEC 映射并限制这些概念，以便提供者能将调用转换为 UET 行为。

其战略价值在于传输层之上的连续性。MPI、SHMEM 和加速器通信库可以使用熟悉的抽象，而底层的提供者可以变化。原则上，应用程序可以请求一次操作，而无需知道哪家供应商提供了 NIC 来完成数据包交付，或哪块交换芯片在转发数据包。这正是共用传输层实现供应商选择的核心机制之一。

抽象并不保证同等水平的实现。提供者在注入大小、分散/聚集限制、端点数量、原子操作、内存注册、完成行为、硬件卸载以及安全性功能上可能存在差异。因此，针对同一 API 编译的库，可能遇到不同的性能或能力边界。采购和软件认证需要的远不止在“支持 libfabric”上勾选一下。

UEC 的软件层还承载着作业和授权语义。AI 和 HPC 系统常常在共享基础设施上运行多个作业，每个作业带有自己的进程、内存区域和安全边界。规范必须明确：哪个端点属于哪个作业，哪些缓冲区可以被访问，远端操作如何映射，以及完成或错误信息如何返回给软件。这些决定将决定，一个高速网络究竟能否被调度器、运行时和应用真正利用，还是仅仅在数据包基准测试中令人赞叹。

该项目依赖 OpenFabrics 生态，因为它并不拥有 libfabric。这种关系展现了 UEC 的一个更广泛特征：其架构由多个在不同位置受控的组件构成。UEC 可以定义其传输如何映射到 libfabric，但必须与 API 维护者和用户进行协调。类似依赖还存在于 IEEE 以太网、IETF 网络、存储组织以及各供应商的操作系统。

网络架构端点和工作负载剖面

网络架构端点（Fabric Endpoint，简称 FEP）是 UET 终止的逻辑位置。它将一个操作系统实例与一个或多个隔离的网络平面连接起来，并可能包含用户空间提供者、内核驱动、NIC 或加速器侧的传输、内存注册、安全上下文、完成队列、地址向量以及数据包交付和拥塞控制所需的状态。

这种以端点为中心的设计让大多数交换机能够保持为熟悉的以太网和 IP 设备。FEP 负责选择熵值、维护数据包和拥塞状态、将数据放入已授权内存，并解释确认、裁剪和其他反馈。这有助于降低对交换机内部私有路由智能的依赖，同时将复杂性集中于 NIC 芯片、固件、驱动和软件。

UEC 定义了三种实现剖面：AI Base、AI Full 和 HPC。它们并非不同的网络类型，而是规定了实现必须支持的各项功能。AI Base 旨在以较低的实现和状态代价覆盖常见的 AI 通信。AI Full 增加了可延迟发送、精确匹配以及 fetch 或 compare 类原子操作。HPC 剖面涵盖了 AI Full 的绝大部分，但排除了可延迟发送，并更加注重排序、短消息和 HPC 语义。

剖面体系旨在避免每个产品都必须实现最大功能集。它承认，一款高流量的 AI NIC 可以优先考虑集合数据传输，而 HPC 端点则需要更强的排序和原子操作支持。即便如此，可选性仍未消失。一个产品可以在某一剖面内实现可选功能，而两个标称相同剖面的产品，在安全功能、链路扩展、容量和性能上仍可能不同。

就连术语本身也成了一种警示信号。权威的 1.0.3 规范使用 AI Base、AI Full 和 HPC。而一份 2025 年的独立合规 readme 却使用 AI Base、AI Extended 和 HPC。最合理的解释是，“AI Full”为当前术语，而合规材料已过时或前后不一致。在公开测试套件得到修正之前，厂商和采购方都应明确声明自己所依据的规范版本以及声明背后的精确剖面用语。

从应用意图到数据包交付

在 UET 内部，语义服务子层承载着应用的意图。它定义了消息身份、缓冲区寻址、带标记和无标记操作、远端内存访问、原子操作、完成行为、作业标识符、缓冲区授权、响应和错误。数据包交付子层随后决定如何将这一意图转换为数据包，以及它们如何到达另一个端点。

对于可靠模式，端点之间会建立数据包交付上下文（Packet Delivery Context，PDC）。一个 PDC 包含状态信息，如数据包序号、确认、重复检测、排序模式、拥塞信息、返回路径状态和流量等级。一个 PDC 关联一种交付模式和一种流量等级；同一 FEP 对之间可以存在多个 PDC。

这些状态并非无关紧要的实现细节。大型集群可能产生数量巨大的通信关系。如果每条关系都需要庞大的目标状态，端点的内存和查找开销就可能成为瓶颈。因此，UEC 并未强制要求所有操作都套入单一的连接模型，而是定义了四种具有不同可靠性和排序契约的交付服务。

可靠无序交付（Reliable Unordered Delivery，RUD）将每个数据包恰好一次地交给语义层，但允许它们不按顺序到达。它支持通过多条路径的数据包喷洒、选择性重传、重复抑制以及直接数据放置。由于目标可以根据偏移放置数据，而无需等待传输层的重排缓冲区，一次长集合操作就可以同时利用多条路径，而不必让所有数据包排在一个丢失片段之后。

可靠有序交付（Reliable Ordered Delivery，ROD）保证恰好一次、按序交付。它使用单一路径和一个熵值，丢弃乱序到达的数据包，并采用从第一个缺失序号开始的 Go-Back-N 恢复。这看起来不如 RUD 精巧，但它为那些需要严格排序的操作保留了语义。UEC 将排序视为应用需求，而不是让每次传输都承担其代价。

面向幂等操作的可靠无序交付（Reliable Unordered Delivery for Idempotent Operations，RUDI）侧重于另一面。它至少一次交付并允许重复，从而降低了目标端所需的常规序号和确认状态。当重复操作不会改变最终结果时（例如某些远端内存传输，配合后续独立的屏障），这会很有用。但若应用不当，则非常危险。数据包层本身并不会判断幂等性；必须由软件来决策。若对非幂等操作使用 RUDI，就可能产生无效的应用状态。

不可靠无序交付（Unreliable Unordered Delivery，UUD）以尽力而为的方式传递数据报，不提供常规的可靠性和排序保证。它属于同一语义框架，但不像 RUD 和 ROD 那样承担拥塞控制的要求。如果队列或流量等级被共享，应用必须防止 UUD 损害那些受拥塞控制的流量。

这四种模式反映了 UEC 的核心哲学：网络应该提供多种机制，以便软件能根据操作的语义来适配传输成本。其收益在于效率；代价则是更大的实现和测试表面积，提供商、应用或运营方都可能选择不兼容的组合。

数据包喷洒：让网络物尽其用，而非指望运气

传统 ECMP 通常通过哈希将整个流绑定到一条路由。在宽阔的 Clos 架构中，这就变成了一场抽奖。多条大流可能挤在同一条链路上碰撞，而其他地方的等价容量却白白闲置。于是，一条长的 AI 传输就会因为一个糟糕的哈希，在整个生命周期里被限制住。

UET 的应对方式是在数据包级别改变熵值。发送方可以使用数十甚至数百个熵值，这样交换机现有的 ECMP 机制就会将数据包分散到许多条路径上。数据包交付子层提供序号信息，拥塞管理子层选择熵或路径，交换机执行其常规的哈希，反馈信息则告诉发送方哪些值存在拥塞嫌疑。

数据包喷洒之所以可行，是因为设计中的其他部分提供了支撑。数据包可以乱序到达。RUD 可以直接放置数据，无需等待传输层的完整重排。选择性重传只恢复丢失的部分。拥塞反馈减少了对问题路径的使用。因此，这一机制并非孤立的负载均衡技巧，而是一套建立在路径多样性之上的传输模型的一部分。

UEC 并不要求每台交换机都运行某种私有的自适应路由算法。基础实现可以通过标准 ECMP 采用轮询或伪随机熵值。更高级的端点则可将 ECN、延迟或裁剪信号关联到特定熵值，并避开拥塞路径。厂商自有的自适应转发可以与 UET 共存，但它并不是获取路径知识的唯一来源。

其承诺是更优的架构利用率和更低的尾部延迟。尚未明朗的是，不同端点将以多高的一致性来解释反馈，以及数据包喷洒会如何与交换机缓冲区、乱序、故障和混合流量相互作用。在均匀的实验室中表现良好的算法，在含有多个交换机世代和流量等级的大型架构中可能表现迥异。独立的多供应商证据仍然有限。

三种拥塞机制应对三种不同的瓶颈

UEC 并未定义某种万能的拥塞算法，而是区分了网络核心拥塞、接收端 Incast 以及端点缓冲区受限这三种情况。

网络信号拥塞控制（NSCC）由源端驱动。发送方维护拥塞窗口，估算在途字节数，并根据确认、否定确认、超时、延迟以及 ECN 等网络信号来调整窗口。窗口行为和基于数据包的多路径相互配合。UEC 认为，当数据包无法再从网络发出时，窗口本身就会停止再接纳新数据，而纯速率控制器则可能错误地解读丢失的反馈。

这是联盟的架构论点，并非独立证明每一个 NSCC 实现都优于 DCQCN 或其他 RoCE 拥塞机制。结果取决于算法细节、交换机标记、拓扑、流量模式以及参数。因此，“使用了 NSCC”并不是一个足够的性能声明。

接收端信用拥塞控制（RCCC）针对的是 Incast。当大量源端同时向同一目标发送数据时，即使网络核心并未拥塞，最后一段链路也可能成为瓶颈。接收端追踪需求，并在发送方之间分发信用，从而调节整体到达速率，并让每一条源端流的有效窗口随竞争情况而变化。RCCC 可以与 NSCC 协同工作，因为接收端拥塞和核心拥塞性质不同。

传输流量控制（TFC）同样使用信用，但面向缓冲区有限的点对点服务。其目的是在丢包容忍度较低时直接防止接收缓冲区溢出。TFC 既可配合多路径使用，也可脱离多路径运行。将所有这些信用机制同等看待，会掩盖它们各自试图控制的不同故障域。

规范期望在整个架构中普遍部署显式拥塞通知，并包含了关于标记的操作假设，包括建议在出队而非仅在入队时标记。端点结合确认、延迟和裁剪来解释 ECN。因此，统一的交换机配置是必不可少的。一次正确的传输实现在一张配置错误的架构中仍然可能得到糟糕的结果。

版本维护的历史也凸显出难度。1.0.1 版本修正了 RCCC 源端算法。1.0.2 版本修正了某些拥塞管理情形。1.0.3 版本纠正了信用与链路层重传之间的交互。这些都是活着的规范的正常标志，同时也证明信用、重传和路径控制状态以微妙的方式相互作用。运营方需要的不仅是首日的合规，更是严格的版本纪律和回归测试。

数据包裁剪与精确丢包恢复

数据包裁剪（Packet Trimming）改变了支持该功能的交换机在无法保留完整数据包时的行为。它不再不提供任何信息就将帧丢弃，而是移除大部分或全部的有效负载，保留足够用于辨识的报头和元数据，将该数据包标记为“已裁剪”，并将缩短后的通知继续发送到接收端。接收端随后可以更精确地告知发送方到底丢失了哪些数据。

这比 ECN 标记蕴含的信息更多。ECN 表示发生了拥塞；裁剪则指名了一个其有效负载未能存活的数据包。配合 RUD 和选择性重传，这可以加快恢复，而不必等待超时或因一次丢失而重传一长串数据包。

该交换机功能是可选的，但合规端点必须能够在适用要求下接收并解读已被裁剪的数据包。这种不对称性支持了在传统交换机之上部署，同时允许增强型架构提供更丰富的丢失信息。但这也带来了升级问题：一个部分增强的网络可能需要对裁剪功能按路径、剖面或拓扑加以限制，以确保每个接收端点都能正确处理它。

UEC 还为请求、控制数据包、重传和已裁剪的流量定义了不同的流量等级。运营方必须一致地映射 DSCP 值、交换机队列、端点队列和优先级。规范本身并没有为此提供一套通用的管理系统。映射错误可能导致控制流量饿死、拥塞反馈失真，或者让恢复数据包与它们尝试修复的流量争抢资源。

数据包裁剪也昭示出该项目更大的实现挑战。协议可以定义在线缆上发生的行为，但最终的运营效果取决于交换机队列、端点逻辑、遥测、配置和故障处理。互操作性是一种系统属性，而不仅仅是数据包格式的属性。

链路恢复、信用与功能协商

链路层重传（LLR）试图在物理链路上就处理故障，而不是等到端到端传输来反应。对端检测到一个序号缺口或一个损坏的帧，就发送一条链路本地的否定确认，促使发送方从本地缓冲区重传受影响的帧。如果恢复足够迅速，传输层就可以避免较长的端到端重传。

随着通道速率和端口密度的增加，这带来的潜在价值也随之上升。偶然的光或电故障，在紧密同步的作业中可能造成不成比例的延迟。但 LLR 也增添了序号状态、重放缓冲区、控制消息、丢弃窗口和新的故障类型。它还必须同时与信用更新和链路重置协作。1.0.3 版本修正了多个边缘场景，包括 CBFC 信用信息与 LLR 之间的竞态条件。

基于信用的流量控制（CBFC）在链路层面、按虚拟通道工作。它告知发送方接收端还剩余多少容量，并可以比宽泛的优先级暂停更细化。UEC 将其描述为可控无损行为的一种手段，而不必让每一张 UET 架构都彻底无损。CBFC 是可选的，且 UET 被设计为也能在尽力而为的网络上工作。

CBFC 并非优先级流量控制（PFC）的简单别名。两者的信令和粒度不同，尽管目标都是防止缓冲区溢出。CBFC 依然需要一致的配置，并保证其自身控制帧的正确交付。本地信用也可能与端到端的窗口和接收端信用相互作用，构成多层嵌套的控制回路。

UEC 使用基于 LLDP 的协商来发现可选链路功能，并防止某一端激活对端不支持的某项能力。协商必须涵盖剖面、虚拟通道、DSCP 与优先级映射、重置、软件升级以及部分功能组合。1.0.3 版本新增的一项布尔协商能力更加凸显了在每条链路上进行显式协商的必要。

这些可选项创造了一条从基础以太网到增强以太网的道路，同时也形成了一张可能被采购语言掩盖的矩阵。一台交换机可以完好地转发 UET，却不支持裁剪、LLR 或 CBFC。另一台可能仅在特定软件版本或端口模式下才提供这些功能。一份可信的部署证明需要列出精确的功能范围，而不仅仅是一个联盟名称。

每通道 100 和 200 Gb/s 的物理层信令

物理层将 UEC 牢牢锚定在硬件路线图中。起初的 1.0 工作围绕每通道 100 Gb/s 的信令展开。1.0.3 版本新增了每通道 200 Gb/s。这使规范契合了更高密度链路和系统的新一代要求；但文档中的能力并不证明所有 UEC 产品都能立即支持该速率。

PHY 工作还涉及前向纠错统计、可纠正与不可纠正码字比率、控制序列集、链路质量报告，以及物理层故障与 LLR 之间的互动。这些细节之所以重要，是因为传输层关于恢复的决策，依赖于更低层能够观测和报告的内容。

随着信令速率提高，光学器件、SerDes、FEC、链路重传和传输层恢复之间的边界变得更加经济显著。更强的 FEC 可以降低残余错误率，但代价是延迟和功耗。链路重传能更快修复局部故障，却需要缓冲区和状态。端到端重传在全局实现上更简单，但可能浪费更多时间。UEC 试图定义这些层次如何协同工作，而不是让每家供应商独自优化。

引入 200G 通道也说明了联盟所面对的目标是动态变化的。1.0 版的实现方必须在保持兼容性的同时，规划新的物理能力。测试设备、固件和管理系统必须能区分每个端口支持的能力。采购方不能仅凭一条笼统的 UEC 声明就推断通道速率。

可选的端到端传输安全

传输安全子层（TSS）可以提供端点到端点的可选保护。其威胁模型不要求信任交换机。它能够实现机密性、完整性、重放保护、作业隔离、安全域、组密钥、密钥轮换，并与基于硬件的信任根集成。

该设计使用安全域，其成员共享加密上下文。标识符、关联编号、代际、安全源端身份和密钥派生，被设计为比逐对端点的独立会话更具规模。当加速器集群和作业成员关系快速变化时，这种设计是必要的。

协议只是整个安全体系的一部分。生产环境中的运营者必须运行密钥授权机构、证书或其他信任根、作业成员服务、分发与吊销、代际切换、端点恢复、硬件加密以及安全遥测。一张网络可以符合某个剖面，而未必启用所有可选的 TSS 功能。“UEC 合规”并不自动等同于“数据已加密”。

这一可选性反映了不同的部署假设。一个专用、物理受控的网络架构可能更侧重性能，并依赖环境措施；而一个多租户云环境可能需要强隔离和加密保护。剖面和采购体系必须清楚呈现这种差别。

最大的风险不仅在于加密开销，更在于大规模的生命周期失效：过期的成员关系、滞后的吊销、不一致的代际、端点故障后的恢复，或根本无法证明哪个作业有权访问哪段内存。这些问题将传输安全与核心规范之外的编排和身份系统联系在一起。

“UEC 合规”目前在多大程度上成立

UEC 已开始发布 1.0 版合规资料，但公开体系尚不是一个成熟的独立认证机制。当前可用的工具包主要面向实现方自行声明。矩阵将规范要求与剖面相对应，测试床指南则描述了推荐的端点和交换机配置。尚未发现一套全面的公共登记册，由独立实体宣布某个产品在完整的 UEC 项目中通过或未通过。

这种区分至关重要，因为市场上流转着各种不同的说法。一个产品可能是围绕正在演进中的 UEC 功能设计的；它可能已实现选定的线缆功能；它可能在某个软件版本中支持一个剖面或部分功能。一家厂商可能声称完全的功能合规。一个实验室可以通过一台交换机生成 UET 流量。但这些声明中，没有一项能自动等同于独立的、端到端的、多供应商认证。

公开的测试床建议很有用，但被刻意限制在有限范围内。它们提供推荐的最佳实践拓扑和检查，而非完整的系统认证。更广泛的互操作性、性能、压力、规模和 API 生命周期则被排除在外，或未被充分覆盖。这些材料并不能证明当 UET 与 RoCE 流量混合、分部升级、遭遇重复故障、面对大规模密钥域或联盟所宣称的最庞大端点规模时的行为。

AI Full 与 AI Extended 之间的不一致更凸显了合规为何需要严格的版本控制。采购方应当追问：某项声明适用于哪个规范版本、修补级别、剖面、可选功能、链路模式和安全特性。答案应当说明证据究竟来自内部测试、双边演示、联盟活动还是独立实验室。

下一个可信的步骤将是：公开的、绑定到确切规范版本的测试定义；多厂商互插拔大会；独立管理的结果，包括负面结果；以及一份能够区分端点、交换机、软件和完整系统的登记册。在此之前，“UEC 合规”只是一道入门问题，而不是一份完整的保证。

一份公开文件，带有 RAND 专利义务

Ultra Ethernet Specification 1.0.3 可以公开下载，并以知识共享署名-禁止演绎 4.0 许可证发布。这允许共享并注明出处，但不允许在该许可证下分发修改版本。更重要的是，版权访问与专利访问是彼此独立的。

已记录的工作组章程普遍采用了一种传统的规范模型，即合理且无歧视（RAND）的专利许可。RAND 未必意味着免版税，不能保证统一价格，不会消除协商，也无法阻止围绕有效性、必要性、地域范围或防御性条款的争议。实际的商业处境取决于每一项具体的专利声明、其会员义务以及双边许可。

UEC 维护了一份公开的必要专利权利要求登记册。截至研究截止日期，可以看到来自 Broadcom、Microsoft、Huawei、Qualcomm、AMD、HPE、Google、Marvell 等公司的声明，其中包括针对未来 1.1 工作的提交。这份登记册增加了透明度，因为它表明，实现方在开发或交付产品之前必须评估知识产权。

联盟明确表示，它不对某项已披露的专利是否有效、是否确实必要、是否被侵犯或以何种价格可获得做出判断。它也不发布联合授权许可。因此，较小的实现方可能承受更大的法律和交易成本，而大型会员则更容易吸收。一份公开可得的规范，仍可能催生一个商业上高度集中的生态系统，尤其当专利释放、芯片成本和测试开销相当高昂时。

知识产权框架也塑造着治理激励。企业贡献技术，既是为了为其产品创造更大的市场，也是为了保证已有能力被纳入共同设计。专利声明只有在及时且足够清晰时，才能保护实现方免受突袭。它们无法消除这样一种可能：随着采用范围扩大，授权许可反而成为壁垒。

因此，更诚实的描述应当是“已公开发布，支持多厂商，并有 RAND 专利义务”，而不是“普遍免版税”。采购团队需要同时了解技术剖面和许可路径。

第一波产品与测试

在 1.0 版发布前后，实现证据才开始大量出现，但这些示例的成熟度各不相同。

AMD 于 2025 年 4 月推出了其 AI NIC Pollara 400 的商业可用性，并描述其围绕正在演进中的 UEC 能力而设计。Pollara 是一种可编程端点平台，也是表明该传输已进入出货硬件的重要信号。这里的措辞非常关键：“围绕正在演进中的 UEC 功能设计”，并不是在 1.0.3 的全部最终要求下获得独立认证。

Broadcom 于 2025 年 6 月发布了 Tomahawk 6 交换芯片，拥有 102.4 Tb/s 吞吐量和 UEC 相关功能。10 月，又推出了 Thor Ultra 800G NIC，并声称完全符合 UEC 功能。这是一项重要声明，但公开证据尚未将其变为独立联盟证书。相关指标、软件成熟度和确切的剖面支持需要单独说明。

Nokia 与 Keysight 于 2025 年 10 月共同宣布了一次端到端演示，在 Nokia 的 7220 和 7250 系列数据中心交换机上以 800 Gigabit Ethernet 传送 UET 流量。Keysight 提供了流量生成和验证。该测试表明，UET 流量可以通过商用交换系统，且测试设备支持正在形成。但它并不能证实完整的、多厂商的端点剖面、生产级的规模，以及对所有可选功能的独立认证。

其他成员也描述了支持 UEC 的交换机、系统、软件或测试计划，2026 年峰会更是高度聚焦于产品化。这些证据支持着向实现阶段的过渡，但尚不足以支撑精确的出货 UET NIC 数量、已认证交换机数、生产云端区域数或完整的网络架构数。

这波产品浪潮最合理的解读，是一条证据链：公开规范使设计成为可能；芯片与 NIC 发布展现了投入；流量演示证明了部分互操作性；合规矩阵映射了各项要求；运营商的部署报告则能体现运营价值。独立的互插拔大会和生产环境下的实际成果，才能建立起目前仍显缺失的更广泛可信度。

RoCE、InfiniBand、Slingshot 与 UALink

UEC 进入了一个已存在成熟替代方案和相关技术的市场。其战略论点不是“以太网从未承载过 RDMA”，也不是“专用架构不起作用”，而是：当前 AI 工作负载的规模和同步性，需要一套能提供更灵活交付、更优路径利用和更精细拥塞控制的端到端以太网新架构。

RoCEv2 是直接的前身，也是重要的存量技术。它在可路由以太网上承载 RDMA，并有广泛的应用和产品支持。UEC 对典型 RoCE 部署的批评包括：整条流被绑定到单一链路、Go-Back-N 恢复、接收端重排、DCQCN 调优困难、许多设计依赖优先级流量控制，以及在 Incast 或集合通信突发场景下表现欠佳。这是 UEC 的技术立场，但并不意味着每一张 RoCE 网络都表现糟糕。

这种比较是动态的。厂商可以将自适应路由、数据包喷洒、更好的拥塞算法或其他类 UEC 的功能植入可编程 NIC，同时保持 RoCE 兼容性。例如，AMD 对 Pollara 的描述就把 RoCEv2 和 UEC RDMA 都呈现为可编程硬件上的选项。因此，UEC 既可以作为完整传输层与 RoCE 竞争，又可能影响未来 RoCE 产品的发展。

InfiniBand 是龙头地位的专用架构替代方案。它提供了一套集成的 RDMA、拥塞、链路可靠性和管理生态，拥有长期的 HPC 经验。InfiniBand 贸易协会的 2.0 工作包含 XDR 对每通道 200 Gb/s 和更新遥测的支持。UEC 最有力的差异化不在于宣称 InfiniBand 缺乏性能，而在于能够通过更广泛的以太网供应链、标准的 IP 路由和更大的多供应商选择，来实现 AI 和 HPC 的行为表现。

HPE Slingshot 处于中间地带。它是一种兼容以太网的商用 HPC 架构，具备自适应路由和拥塞管理能力，并为 UET 提供了关键的技术前身。它表明，专用行为可以构建在以太网之上，也提醒着，一个受控的商用平台与一个行业范围的规范之间是有区别的。

UALink 更多是互补而非直接替代。其当前公开的 200G 规范聚焦于加速器之间覆盖一个 Pod 的低延迟 Scale-up 互联，并描述了最多 1,024 个加速器的系统。UEC 1.0 主要是 Scale-out 架构，通过交换机连接节点。一个数据中心可以在计算 Pod 内部使用 Scale-up 链路，而在 Pod 或节点之间使用 UEC。未来 UEC 在优化 Scale-up 传输和网内集合通信方面的工作，可能拉近两者边界，形成融合或竞争。

NVIDIA Spectrum-X 和私有的加速器架构是另一种参照。紧密集成的协议栈可以更迅速地优化硬件、软件和支持，但会增加对单一生态的依赖。UEC 以部分集成换取共同的接口和供应商多样性。这种取舍是否合理，取决于性能、支持、专利条款、互操作性和总拥有成本，而非抽象地看“开放”标签。

运营问题比协议本身更复杂

一份 573 页的规范可以定义很多要求，但一张面向生产的架构仍需一套运营模型。UEC 1.0 把大量管理性工作留在了规范核心之外或边缘位置。运营方必须在端点和交换机之间一致地配置剖面、流量等级、ECN 阈值、熵集合、可选链路功能、密钥、固件、遥测和故障处理规则。

混合流量让任务更难。一张数据中心架构可能同时承载 UET、RoCE、TCP、存储、管理，以及有序和无序的 UET 服务。队列分配以及这些类别之间的公平性，不能仅靠每个协议都实现正确来解决。一个拥塞算法在孤立情况下也许表现良好，但当与其他有着不同反馈和假设的控制器竞争时，就可能表现糟糕。

端点复杂性是另一项结构性风险。UET 将多路径、直接放置、选择性重传、多种交付模式、窗口与信用控制、裁剪接收、安全性以及大量状态，都放入了 FEP。这可能增加 NIC 芯片面积、固件体积、验证工作量、功耗以及需要诊断的故障条件数量。端点智能固然支撑了宽泛的供应链，但也可能将最复杂的实现正好转移到每台服务器都必须购买的那个部件上。

可选功能在创造产品差异化的同时，也带来了碎片化。一家厂商可能优化一款面向传统 ECMP 和 ECN 的基础 AI Base 端点；另一家则可能支持 AI Full、TSS、裁剪、LLR 和 CBFC。两者都位于 UEC 生态中，但运营方不应假设它们有同等的语义、性能或安全性。合规矩阵必须演变为运营能力矩阵。

版本维护将是持续性的。从 1.0.1 到 1.0.3 的修正涉及了拥塞、信用、重传和数据包行为。一个大型集群可能同时包含多个版本的 NIC 固件、交换机发布和测试工具。若某一层在未与其他层协调的情况下升级，就可能引发联盟试图避免的那种跨层竞态条件。

因此，UEC 的外部联盟是关键性的，而非仅仅形式上的。开放计算项目将传输与开放系统和硬件相连。OpenFabrics 联盟与 libfabric 社区连接着应用。IEEE 802.3 提供正式的以太网工作。SNIA 与 NVM Express 带来了存储和管理要求。IETF 的技术提供了 IP、ECN 和相关机制。这些组织拥有不同的决策流程和路线图；联络可以降低重复劳动，但并不保证同步采纳。

最终的运营检验还是持续运行的底层基础设施。一份文档可以规定行为，一个厂商可以发布产品，一个联盟可以组织一次峰会，但这一切都不能替代一个由若干互不隶属的端点和交换机组成的集群，在拥塞、故障和升级环境下完成真实作业，并让运营商能够解释到底发生了什么。

当前形势：从规范成功走向实现可信度

到 2026 年 7 月，UEC 已经实现了其在刚起步时还充满不确定性的若干目标。它凝聚起了一个广泛的联盟，构建了一套整合的五层架构，发布了一份完整的 1.0 规范，并以修订版本保持了规范的维护，新增了每通道 200G 支持，公开了专利声明，并催生了一系列产品和测试宣告。该项目是活跃的，其议程已明显转向实现。

这些进展让接下来的不确定性变得更加重要，而非更小。目前，尚未有一份统一的权威登记册公布精确的当前会员和指导委员会名单。公开的会员页面与章程对加入路径的描述不尽相同。正式的 TAC 领导层与峰会上的角色未能完全对齐。1.0.2 的发布日期在官方文档中存在冲突。合规工具包仍在使用过时的剖面术语。这些都没有毁掉架构，但在一个版本精确性至关重要的项目中，每一点都反映出文档控制和透明度的信号。

更显著的空白在于采用情况。UEC 并未发布部署普查或经独立验证的产品注册表，也无独立的预算或经审计的财务报表。公开证据尚未证实在联盟所宣称的最大规模目标下，存在一张完全可互操作的 UEC 1.0 网络。厂商的演示和声明虽然宝贵，却都来自具有商业利益的参与方。与最新 RoCE、InfiniBand 及集成以太网平台的独立性能对比仍然有限。

机遇仍然相当可观。以太网是数据中心中最小的公分母，AI 基础设施市场足够庞大，能够容纳新一代的 NIC、交换机、光学器件和软件。运营商有强烈的动机去避免单一厂商锁定并提高加速器利用率。一套共同的协议栈可以将这些动机转化为采购力量。

风险在于，“Ultra Ethernet”可能变成无法互通的特性子集的大伞。如果基础转发能够通行，而各剖面、拥塞控制、安全性和管理却彼此分歧，那么品牌扩散的速度可能快于互操作性的建立。如果 RAND 授权昂贵或不明确，供应商阵容可能会收窄。如果 RoCE 产品吸收了 UEC 最吸引人的那些理念而无需更换新的传输层，UEC 就可能虽影响市场，却无法成为主导标签。

如今的核心问题已不再是“联盟能否发布一份雄心勃勃的规范”，它已经做到了。问题在于，独立的组织能否实现同样的约定，获取必需的技术授权，大规模运营这样一张架构，并在持续演进中维持兼容性。UEC 只有在上述这些要求经受住与运行代码的碰撞之后，才能真正成为基础设施。