摘要

  • 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、可选数据包截断、可选本地恢复、可选基于信用的流量控制以及可选的端到端传输安全。
  • AMD、Broadcom、Nokia 和 Keysight 的产品和演示表明实现已开始，但公开一致性仍主要依赖供应商的自我声明，尚无完整的独立认证注册记录，也缺乏大规模部署的统计。
  • UEC 的战略机遇源自以太网的现有安装基础及其多供应商供应链。其主要风险包括端点复杂性、可选功能导致的碎片化、RAND 专利义务、管理和测试的成熟度有限，以及规范发布与生产环境中可验证互操作性之间的差距。

为何人工智能使网络成为计算机的一部分

Ultra Ethernet Consortium 的诞生源于计算经济学的变革。在普通的企业网络中，网络结构需要以可接受的吞吐量和可用性承载众多独立的数据流。而在大型人工智能训练系统或高性能计算（HPC）集群中，网络则成为统一同步计算的一部分。成千上万个加速器可能在集体操作过程中交换模型参数、梯度或科学数据。整个阶段可能因最慢的参与者尚未收到所需信息而停滞。因此，轻微的路径不平衡、偶发的拥塞或数据包丢失都可能让极其昂贵的处理器闲置，即便网络结构的平均利用率看似尚可。

优化标准随之改变。聚合带宽固然重要，但已远远不够。运营商还需关注作业完成时间、尾部延迟、incast、丢包恢复、并行路径间的流量分散以及端点所需维护的状态量。一个能快速传输大部分数据包却延迟一小部分的网络，可能会拖慢整个集体操作。对传统流量而言可接受的丢包重传方法，对于长消息中单个缺失的数据包可能耗时过久。被 ECMP 固定到单一路径的流，即使拓扑其他部分仍有可用容量，也可能性能不佳。

UEC 的基本主张是，这些难题无法通过单一的交换机功能或单一的拥塞算法来解决。通信路径始于网络之上——软件库和应用语义，并贯穿内存注册、远程操作、传输状态、数据包交付、拥塞控制、IP 路由、以太网链路、光学器件和物理信令。如果各层孤立设计，局部优化可能只是转移瓶颈，或在别处制造不兼容的假设。

UEC 的答案是协调架构。它保留以太网和 IP，因为运营商已深谙其道，且围绕交换机、光学器件、线缆、网络操作系统、遥测和管理已形成庞大的产业生态。它替换或扩展了该联盟认为不适合大规模 AI 和 HPC 工作负载的那些部分。其结果并非“带新标志的普通以太网”，而是一种尝试：让熟悉的网络承载专用传输，其行为从软件 API 到每通道吞吐量均有明确界定。

这一区别解释了为何 UEC 对数字基础设施至关重要。该项目不拥有加速器、工厂、数据中心或云区域。它定义的合约可供其成员及其他实现者集成到网卡、交换 ASIC、系统、驱动程序、库和测试设备中。只有当这些独立的产品在故障、拥塞、升级和多供应商混合环境下仍能正确交换流量时，其影响力才会真正显现。

什么是 UEC——以及它不是什么

Ultra Ethernet Consortium 是名为 Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series 法律系列的公开名称。该系列结构将项目置于 Joint Development Foundation 之下，更广泛地说，属于 Linux Foundation 家族。它为参与者提供了成员资格、治理、知识产权、资金和外部关系的既有框架，无需创建新的独立法人。

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

UEC 也不等同于 Ultra Ethernet Transport。UET 是该规范核心的传输架构。该联盟的工作范围更广：软件到 libfabric 的映射、消息和数据包语义、网络假设、链路层选项、物理需求、管理、与存储的对齐、性能与调试、一致性和测试。将该项目简化为“一种新的 RDMA 协议”恰恰掩盖了使其既充满前景又困难重重的跨层雄心。

UEC 也不是 IEEE 802.3 工作组。IEEE 802.3 根据自身正式流程制定以太网 MAC 层和物理层的核心标准。UEC 依赖于该生态系统并与之保持联系，但并非取代它。同样的界限也适用于 UET 所依赖的 IETF 机制，特别是 IPv4、IPv6 和显式拥塞通知（ECN）；适用于维护 libfabric 的 OpenFabrics 生态系统；以及活跃在存储、开放硬件和加速器互连领域的其他组织。

项目网站曾使用暗示其是国际标准组织的措辞。最安全且证据充分的描述是：它是 JDF 旗下的一家国际规范开发组织。没有任何记录表明它隶属国际标准化组织（ISO），或其文档为 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 贡献了交换 ASIC、网卡和高速 SerDes；HPE 和 Eviden 带来了 HPC 系统和专用互连的历史积累；Intel 贡献了处理器、以太网和软件；Meta 与 Microsoft 则代表了超大规模运营商，他们对提高大型 AI 集群的利用率和减少对单一垂直整合供应商的依赖有直接兴趣。

该联盟也汇集了彼此竞争的商业利益。其成员销售网卡、ASIC、系统、云容量、光学器件、软件和支持服务。其中一些成员拥有可能对实现至关重要的专利组合。某些成员受益于广泛的多供应商标准，同时又能通过差异化的专有功能获利。因此，该联盟并未消除竞争，而是创造了一个空间，让竞争对手在约定最低限度接口的同时，仍能通过实现质量、性能、集成和商业条件进行区别化竞争。

HPE 的 Slingshot 互连提供了一个有用的技术传承示例。Slingshot 是一种兼容以太网的 HPC 架构，具有自适应路由和拥塞管理功能。与 HPE 相关的评论曾表示，一个“HPC 以太网”规范已贡献给 UEC，并估计 UET 的很大一部分源自 Slingshot 的传输思想。具体百分比未经独立核实，不应作为联盟的官方统计。更广泛的观点已有坚实支撑：UEC 并非从零开始，它汲取了 HPC、云、RDMA 和以太网的生产经验。

这种先前系统的混合也解释了为何“开放”一词需要精确定义。已批准的规范可公开下载，其架构旨在实现多供应商实现。但该项目同时也是一个场所，成员在此贡献已有知识、专利和产品路线图。文档的开放性并不消除附加在技术之上的经济和法律条件。

为竞争对手间协作设计的法律系列

Joint Development Foundation 模式为 UEC 提供了一个正式外壳，而无需使其成为普通的运营公司。该项目拥有自己的身份、范围、成员类别、指导委员会、工作组和知识产权义务。JDF 外壳提供法律和非营利基础设施，并可持有该项目的资产和协议。这种模式降低了创建联盟的成本，并为竞争对手提供了公认的协作流程。

指导委员会负责项目治理。其文件记载的职责包括协调工作组、批准新成员、管理资产和财务、指定或替换主席、监督进度以及管理项目发布和商标。协商一致是首选，若无法达成，章程规定在满足出席要求的合格参与者中，需获得四分之三的绝对多数。可向主席提交书面申诉。

首任主席是 Meta 的 Brad Booth。当前规范 1.0.3 列出 AMD 的 J Metz 为主席，HPE 的 Barry Davis 为副主席，Arista 的 Hugh Holbrook 为技术咨询委员会（TAC）主席，Marvell 的 Puneet Agarwal 为 TAC 副主席。Paul Congdon 被列为规范编辑。该文档还列出了物理、链路、传输和软件工作的负责人和作者。2026 年峰会议程提到了其他运营负责人。这些峰会角色不一定取代规范中的正式头衔；公开文档未提供完整的当前组织结构图。

章程承认三个类别：指导成员、普通成员和贡献者成员。指导成员参与治理，通常指定一名代表进入指导委员会。普通成员可参与所有技术小组，但无委员会席位。贡献者成员参与选定的小组，在绝对多数决策中无投票权。公开的成员页面推销普通和贡献者级别，年费分别为 20,000 美元和 5,000 美元，此外还需加入 Linux Foundation。但对指导级别的接纳途径和当前费用说明不够清晰。

这种形式上的权力差异很重要。广泛的成员基础可提供专业知识和实现覆盖，但治理并未平等分配。有能力占据指导席位、向多个小组派驻工程师并维持专利和产品项目的大型企业，比小型贡献者成员拥有更大的实际影响力。非成员可下载最终规范，但无法看到完整的草案过程，也无法平等参与。

内部信息不被视为普通商业秘密，但成员在获得相应委员会批准前不得公开草案。这一规则有助于竞争对手间讨论，又避免过早向市场释放信号。它也阻止外部观察者了解被拒绝的提案、投票、临时的实现顾虑或导致可选功能的谈判。最终规范是开放的；达到它的路径仅部分透明。

从四个工作组到 573 页规范

2023 年初次公开的结构基于四个工作组：软件、传输、链路和物理。这一序列反映了项目端到端的雄心。成员资格并非作为无限制的公共邮件列表开放。超过 200 家组织表达了兴趣，联盟在要求进行流程和反垄断培训的同时逐步接纳。这种谨慎可以理解，因为参与者是多个市场上的直接竞争对手，讨论共同的产品和协议要求。

到 2023 年 12 月，UEC 称约有 40 家企业和 300 多名个人参与。它成立了技术咨询委员会，并将结构扩展到八个工作组。TAC 旨在确保架构一致性：传输不能假定某工作组尚未接受的交换机行为、信令方法或 API。2024 年 3 月，联盟宣布已有 55 家企业和超过 750 名活跃参与者，并发布了对其计划架构更清晰的展示。

3 月份的更新介绍了后来进入规范性规范的核心思想：以 libfabric 作为面向软件的 API、数据包喷洒、灵活排序、多种交付模式、发送方和接收方拥塞控制、ECN、数据包截断、链路层重试、可选基于信用的流量控制、传输安全以及未来的网络内集体操作。它还确认 UET 可在现有以太网交换机上运行，增强型设备可提供额外性能。

机构规模同步扩大。UEC 在 2024 年 7 月称有 1,193 名活跃参与者，8 月称有 97 个成员组织。这些是特定时间点的数字，其定义未完全公开，不应机械地与后续公告相加。2025 年，UEC 宣布新增 27 家企业，但存在离职、合并和时间段重叠，无法得出精确的当前总数。其网站也说明并非所有成员都已列出。

Ultra Ethernet 规范 1.0 版于 2025 年 6 月 11 日发布。从那时起，UEC 不再仅是路线图，而是公开的实现参考。9 月发布的 1.0.1 版修正了接收方信用拥塞控制源算法和编辑性问题。1.0.2 版于 2026 年 1 月到来，修正了拥塞算法，但两份官方文档对日期（1 月 21 日或 28 日）不一致。应保留此不一致而非默默统一。

1.0.3 版于 2026 年 7 月 16 日发布，是截至研究时的当前参考。它有 573 页，新增了每通道 200 Gbit/s 信令和布尔协商能力。其发布说明还指出了有关数据包交付、拥塞信用、链路层重试和物理层有序集的关键修正，以及有关传输安全、原子操作和截断数据包的澄清。强制的修正与编辑性澄清之间的区别至关重要：一些更改改变了符合规范的行为，因此要求实现进行维护。

2026 年丹佛成员峰会标志着第二次转型。其议程聚焦于部署、产品化、一致性、管理、性能、调试、存储集成以及交换机与端点之间的测试。架构文档已存在；项目的公信力现在更依赖于实现者能否构建、认证、运营和升级跨组织边界的栈。

五层功能架构的统一体

当前规范将 Ultra Ethernet 划分为软件、传输、网络、链路和物理层。这种划分很有用，但项目的价值在于连接这些层的假设。

在顶层，AI 框架、MPI、SHMEM 和集体库通过 OpenFabrics 接口（特别是 libfabric）进行交互。UET 语义服务子层将应用操作转化为传输事务。数据包交付子层决定分段、排序、确认和恢复。拥塞管理控制注入到该结构中的数据量及其在多条路径间的分布。可选的传输安全保护端到端交换。IPv4 或 IPv6 提供网络转发。以太网提供链路，支持截断、链路层重试、基于信用的流量控制以及可选功能协商。物理层指定每通道 100 或 200 Gbit/s 的统计信息和信令。

这一结构保留了现有网络的关键部分。UEC 并未定义某种 IP 路由替代方案。它期望交换机提供传统的 ECMP 和 ECN。大量智能仍驻留在所谓 Fabric Endpoint 中，这些端点操作熵值、维护传输状态、放置数据并对拥塞信号做出反应。增强型交换机可添加功能，但该模型不要求在承载 UET 之前更换整个网络结构。

这创造了迁移优势和分类问题。一种部署可在具备 ECMP 和 ECN 的传统以太网上使用 UET 端点。另一种则可添加截断、链路恢复、基于信用的虚拟通道、高级遥测和未来的网络内操作。两者均可被称为“Ultra Ethernet”，但性能、恢复特性和操作复杂度却差异明显。

五层方法还使故障隔离更加困难。糟糕的结果可能源于应用映射、端点状态机、拥塞参数、队列配置、DSCP 映射、光学器件、固件或安全系统。仅仅让数据包通过是不够的。系统必须在大规模、混合流量、故障和版本变更期间保持预期的语义和性能。

软件契约：libfabric 而非专有应用 API

UEC 选择 libfabric 2.0 作为符合规范端点的北向参考 API。这一选择将项目与现有 HPC 和高级网络软件生态系统相连，而非要求每个框架采纳新的专有接口。libfabric 已经代表了架构（fabrics）、域、端点、完成队列、事件队列、地址向量、内存区域、消息、远程内存访问和原子操作。UEC 映射并约束这些概念，使供应商能将调用转化为 UET 行为。

战略价值在于传输层之上的连续性。MPI、SHMEM 和加速器通信库可保持熟悉的抽象，即便底层供应商发生变化。原则上，应用可请求操作，而无需知晓负责交付的网卡品牌或交换数据包的芯片品牌。这是通用传输可以创造真正供应商选择的关键机制之一。

抽象并不保证等效的实现。供应商可能提供不同的注入大小、分散-聚集限制、端点数量、原子操作、内存注册技术、完成行为、硬件加速和安全功能。因此，为同一 API 编译的库可能遇到不同的容量或性能限制。软件采购和认证需要的不仅仅是勾选“支持 libfabric”这一项。

软件层还承载作业和安全语义。AI 和 HPC 系统通常在共享基础设施上运行大量作业，每个作业都有自己的进程、内存区域和安全边界。规范必须识别哪个端点属于哪个作业、哪些缓冲区可访问、远程操作如何匹配，以及完成或错误信息如何返回给软件。这些决策决定了快速网络是否真正可被调度器、运行时和应用使用，而不仅仅是在数据包基准测试中令人印象深刻。

该项目依赖于 OpenFabrics 生态系统，因为它并不拥有 libfabric。这种关系说明了一个更普遍的特征：UEC 架构由在其他地方治理的组件组装而成。UEC 可以定义其传输如何映射到 libfabric，但必须与 API 的维护者和用户协调。类似的依赖关系也存在于以太网 IEEE、IETF 机制、存储组织和供应商的操作系统。

Fabric Endpoint 与工作负载配置文件

Fabric Endpoint（FEP）是 UET 终止的逻辑点。它将操作系统实例连接到一个或多个隔离的架构，并可包括用户空间供应商、内核驱动程序、位于网卡或加速器上的传输、内存注册系统、安全上下文、完成队列、地址向量以及交付和拥塞控制所需的状态。

这种以端点为中心的设计允许交换机主要保持可识别的以太网和 IP 设备。FEP 选择熵值、维护数据包和拥塞状态、将数据放置到已授权的内存中，并解释确认、截断和其他反馈。这可以减少对交换机内专有路由智能的依赖。但这也将复杂性集中在网卡硅片、其固件、驱动程序和软件中。

UEC 定义了三种实现配置文件：AI Base、AI Full 和 HPC。它们并非三种不同的网络，而是不同的功能集。AI Base 针对常见的 AI 通信，具有较低的成本和状态需求。AI Full 增加了可延迟发送、精确匹配和一些读取或比较原子操作。HPC 配置文件包含 AI Full 的大部分能力，但排除了可延迟发送，并更强调排序、小消息和 HPC 语义。

配置文件系统试图避免让每个产品都必须实现全套功能。它承认高容量 AI 网卡可能优先考虑集体交换，而 HPC 端点可能需要更强的排序和更多的原子操作。然而，配置文件并未消除选项。一个产品可以在配置文件内实现可选功能，两个带有相同标签的产品仍可能在安全、链路增强、容量和性能方面存在差异。

术语本身已成为一个警示信号。权威规范 1.0.3 使用 AI Base、AI Full 和 HPC。一份 2025 年的合规性文档使用了 AI Base、AI Extended 和 HPC。最可靠的解释是“AI Full”是当前的命名，而该合规性文档已过时或不一致。在测试套件得到修正之前，供应商和买家必须识别出每个声明背后的规范版本和确切词汇。

从应用意图到数据包交付

在 UET 中，语义服务子层承载应用意图。它定义消息身份、缓冲区寻址、带标签和不带标签的操作、远程内存访问、原子操作、完成行为、作业标识符、缓冲区授权、响应和错误。数据包交付子层则决定这种意图如何变成数据包，以及这些数据包如何到达另一端。

对于可靠模式，端点之间建立数据包交付上下文（PDC）。PDC 包含序列号、确认、重复检测、排序模式、拥塞信息、反向状态和流量类别等。一个 PDC 对应于一种交付模式和一种流量类别，同一对 FEP 之间可以存在多个 PDC。

这种状态量并非次要问题。大型集群可能创建非常多的通信关系。如果每个关系都需要大量的目标状态，那么内存和查找成本将成为限制因素。因此，UEC 并未将所有操作强制纳入单一连接模型，而是定义了四种具有不同合约的服务。

可靠无序交付（RUD）确保在语义层恰好交付一次，同时允许数据包乱序到达。它支持数据包在多条路径上分布、选择性重传、重复消除和直接数据放置。因为目标可以按偏移量放置数据，而无需等待传输层的重排缓冲区，所以长集体操作可以利用多条路径，而不会因为单个缺失单元而阻塞所有数据包。

可靠有序交付（ROD）确保恰好交付一次且按顺序。它使用单一路径和单一熵值，丢弃乱序包，并依赖从第一个缺失序号开始的 Go-Back-N 重传。这一模式看似不如 RUD 先进，但它保留了要求严格排序操作所需的语义。UEC 将排序视为应用的要求，而非强加于所有传输的成本。

用于幂等操作的可靠无序交付（RUDI）做出另一种权衡。它确保至少交付一次并允许重复，从而减少了目标端通常的序列和确认状态。它可能适用于某些远程内存移动，之后再跟随单独的屏障。但若误用则危险：数据包层无法推断操作是否幂等，软件必须知晓。对非幂等操作使用 RUDI 可能使应用状态无效。

不可靠无序交付（UUD）提供尽力而为的数据报，没有通常的可靠性或排序保证。它属于相同的语义框架，但不承担与 RUD 和 ROD 一样的拥塞控制要求。当 UUD 与受控流量共享相同的队列或类别时，应用必须避免损害受控流量。

这四种模式揭示了一项核心哲学：网络应暴露多种机制，使软件能够将传输成本与操作语义对齐。好处是效率，代价则是更大的实现和测试表面积，以及更多可能不兼容的组合。

分散数据包：利用整个结构而非走运的路径

传统的 ECMP 常通过哈希将整个流固定到单一路由上。在大型 Clos 结构中，这导致一种抽签：多个大流可能相遇在相同的链路上，而等效的容量却在别处闲置。一个长的 AI 传输可能因其整个持续时间内抽到坏签而受限。

UET 在每个数据包级别改变熵值。发送方可使用数十个或数百个值，允许现有的 ECMP 机制将数据包分配到多条路径。数据包交付子层提供序列，拥塞管理子层选择熵值或路径，交换机应用其常规哈希，而反馈告知发送方哪些值看起来拥塞。

这种分布之所以可行，是因为其他组件配合。数据包可能乱序到达。RUD 可以直接放置数据，而不是等待完全重排。选择性重传只恢复缺失的部分。拥塞信号减少对不良路径的使用。因此，这不仅仅是简单的负载均衡技巧，而是一种围绕路径多样性构建的传输模型。

UEC 不要求每个交换机执行专有的自适应路由算法。基本实现可以在标准 ECMP 上使用伪随机或轮询选择。更先进的端点可以将 ECN、延迟或截断关联到某些熵值，并避开有问题的路径。特定供应商的自适应路由可以与 UET 共存，但不是路径意识的唯一来源。

承诺是更高的利用率和更低的尾部延迟。悬而未决的问题是不同的端点解释反馈的一致性，以及数据包分布如何与缓冲区、乱序、故障和混合流量交互。在均质实验室中有效的算法，在由多代交换机组成的大型结构中可能表现不同。独立、多供应商的证据仍然有限。

为三个不同瓶颈设计的三种拥塞机制

UEC 未定义万能算法。它区分了网络核心中的拥塞、接收端的 incast 和端点的缓冲区限制。

网络信号拥塞控制（NSCC）由源端驱动。发送方维护拥塞窗口，估计在途字节，并根据确认、否定确认、超时、延迟和来自网络的信号（如 ECN）调整窗口。它将窗口与数据包级多路径协调。UEC 认为，当数据包不再离开网络时，窗口会自然停止接纳数据，而纯基于速率的控制器可能误读缺失的反馈。

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

接收方信用拥塞控制（RCCC）针对 incast。当许多源同时向同一目的地发送时，最后一跳链路可能成为瓶颈，而核心却未拥塞。接收方跟踪需求、分配信用、调节聚合到达速率，并根据并发性调整每个源的隐式窗口。RCCC 可与 NSCC 一起运行，因为接收方过载和核心拥塞是不同的。

传输流量控制（TFC）也使用信用，但用于具有较小缓冲区且不能容忍丢包的点对点服务。其目标是直接防止溢出。它可以在使用或不使用多路径的情况下使用。将所有信用机制混为一谈会掩盖它们控制的不同故障域。

规范期望整个结构中有 ECN，并提出了操作假设，如在出口而非仅在入口处标记。端点结合确认、延迟和截断来解释 ECN。因此，所有交换机的一致配置至关重要。传输实现可能正确，但在配置不当的结构中仍表现不佳。

维护历史显示了困难。1.0.1 修复了 RCCC 源算法。1.0.2 修复了拥塞管理角例。1.0.3 修复了信用与链路层重试之间的交互。这些修复对于活的规范是正常的，但也证明信用、重传和路径之间存在微妙的相互作用。运营商将需要维持版本纪律和回归测试，而不仅仅是初始合规性。

数据包截断与精确的丢包恢复

截断改变了能力交换机在无法保留整个数据包时的行为。它不从丢弃没有信息的帧开始，而是移除部分或全部有效载荷，保留足够的头部和元数据以识别数据包，将其标记为截断，并将此缩减后的通知转发给接收方。然后，接收方可以向发送方精确指示缺失了哪些数据。

此信息比 ECN 标记更丰富。ECN 表示遇到了拥塞；截断则标识有效载荷未能存活的数据包。结合 RUD 和选择性重传，它可以加速恢复，而无需等待超时或为单个丢包重传长序列。

交换机功能是可选的，但符合要求的端点必须根据适用要求接收和解释截断包。这种不对称性允许在传统交换机上部署，同时为增强型结构提供更精确的反馈。这也带来了升级问题。部分升级的网络可能需要根据路径、配置文件或拓扑限制截断，以使所有接收方能处理它。

UEC 还为请求、控制包、重传和截断流量定义了差异化的类别。运营商必须一致地映射 DSCP 值、交换机和端点队列以及优先级。规范没有提供管理此映射的通用系统。错误可能导致控制流量饥饿、拥塞反馈失真，或使重传包与它们本应修复的流竞争。

截断说明了该项目的整体挑战。协议可以定义线上行为，但结果取决于队列、终端逻辑、遥测、配置和故障处理。互操作性是系统属性，而不仅仅是数据包格式属性。

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

链路层重试（LLR）试图在端到端传输作出反应之前从物理链路错误中恢复。对端检测到序列中断或损坏帧，发送链路否定确认，并触发从本地缓冲区重读该帧。如果恢复很快成功，传输可以避免更长的重传。

潜在价值随每通道速率和端口密度增加而增加。偶尔的光或电错误可能在同步作业中产生不成比例的延迟。然而，LLR 增加了序列状态、重读缓冲区、控制消息、拒绝窗口和新的故障模式。它还必须与信用更新和复位共存。1.0.3 修复了几个角例，包括 CBFC 与 LLR 信息之间的竞争状态。

基于信用的流量控制（CBFC）在链路层以虚拟通道粒度运行。它告诉发送方剩余的接收容量，并且可以提供比优先级暂停更精细的控制。UEC 将其描述为一种创建受控无损行为的方法，而不要求所有 UET 部署均为全局无损。CBFC 是可选的，UET 可以在尽力而为网络上工作。

CBFC 不是优先级流量控制的另一个名称。机制在信令和粒度上有所不同，尽管它们都试图防止溢出。然而，CBFC 要求一致的配置和其自身控制帧的正确交付。本地信用可以与端到端窗口和接收方信用交互，产生多个嵌套的调节循环。

UEC 使用基于 LLDP 的协商来发现可选功能，并防止一方开启邻居不拥有的能力。协商必须考虑配置文件、虚拟通道、DSCP 和优先级映射、重置、升级和部分组合。1.0.3 增加了布尔协商能力，突出了每条链路上明确一致的重要性。

这些选项创造了一条从基础以太网到增强型结构的路径，但也创建了一个市场语言可能掩盖的矩阵。一个交换机可以在没有截断、LLR 或 CBFC 的情况下正确传输 UET。另一个可能仅在某些版本或端口模式下支持这些功能。因此，可信的部署文档必须描述精确的功能集，而不仅仅是引用联盟名称。

每通道 100 和 200 吉比特的物理信令

物理层将 UEC 锚定在硬件路线图中。最初的 1.0 工作聚焦在每通道 100 Gbit/s。1.0.3 增加了每通道 200 Gbit/s。这一演进使规范与下一代更高密度的链路对齐，但并不能证明所有 UEC 产品立即支持这一速率。

PHY 工作还涵盖纠错统计、已纠正和不可纠正码字的速率、物理层有序集、链路质量报告以及物理错误与 LLR 之间的交互。这些细节很重要，因为恢复决策取决于较低层次可以观察和报告的内容。

在更高速率下，光学器件、SerDes、FEC、本地恢复和传输重传之间的边界变得经济上重要。更强的 FEC 可以减少残余错误，但代价是延迟和能耗。LLR 可以更快地恢复本地损坏，但需要缓冲区和状态。端到端恢复在网络中较简单，但可能浪费更多时间。UEC 试图定义这些层次之间的合作，而不是让每个供应商单独优化。

200G 通道的加入也表明目标在移动。1.0 的实现者必须在为新的物理能力做准备的同时保持兼容性。测试设备、固件和管理系统必须区分每个端口支持的内容。买家不应从通用的 UEC 声明中推断通道速率。

可选的端到端传输安全

传输安全子层（TSS）提供端点之间可选的保护。其威胁模型不假设交换机可信。它可能提供机密性、完整性、重放保护、作业隔离、安全域、组密钥、密钥轮换以及与硬件信任根的集成。

设计使用安全域，其成员共享加密上下文。通过标识符、关联号、纪元、安全源身份和派生机制，应能实现比每对端点一个独立会话更大的规模。这在加速器数量和作业成员快速变化时是必要的。

协议只是安全系统的一部分。运营商必须管理密钥颁发机构、证书或其他信任根、作业成员资格、分发和撤销、纪元变更、端点恢复、硬件加密和遥测。一个网络可能符合某个配置文件，但未启用每个 TSS 功能。因此，“符合 UEC”并不自动意味着加密。

可选性反映了不同的部署假设。一个专用的物理受控架构可能优先考虑性能，并依赖环境控制。多租户云可能需要强隔离和加密保护。采购的配置文件和过程必须使这种差异可见。

最严重的风险不仅仅是加密开销，而是大规模生命周期故障：过期成员资格、延迟撤销、不一致的纪元、故障后恢复或无法证明哪个作业可以访问哪块内存。这些问题将传输安全与规范核心之外的其他编排和身份系统联系起来。

如今“符合 UEC”意味着什么

UEC 已开始随 1.0 版发布合规性文档，但公开体系尚未构成成熟的独立认证制度。当前可用的套件主要设计为实现者的自我声明。矩阵将需求与配置文件连接起来，测试台建议描述了端点和交换机的配置。尚未发现公开的完整注册表，其中独立权威机构记录接受全面 UEC 计划的产品成功和失败。

这一区别至关重要，因为市场上有多种声明。一个产品可能是围绕开发中的 UEC 功能设计的。它可能实现了某些线上行为。它可能支持某个配置文件或其中的一部分，具体到特定的软件版本。一个供应商可能声称完全符合。一个实验室可能通过交换机生成 UET 流量。这些声明中没有一项自动等同于独立的、多供应商的、端到端的认证。

测试台建议有用但刻意有限。它们提供了拓扑和良好实践检查，而非完整的系统认证。它们排除或不完全涵盖一般互操作性、性能、压力、规模和 API 生命周期。它们不能证明在混合 UET/RoCE 流量中、部分升级期间、重复故障、大型密钥域或最大端点数量下的行为。

AI Full 与 AI Extended 的不一致也表明合规性必须严格版本化。买家应询问涵盖哪个规范、哪个补丁级别、哪个配置文件、哪些可选功能、哪些链路模式以及哪些安全功能。他们还应知道证据来自内部测试、双边演示、联盟活动还是独立实验室。

下一步可信的证据应该是链接到确切版本的公开测试套件、多供应商互插拔测试、独立管理的结果（包括失败）以及区分端点、交换机、软件和完整系统的注册表。在此之前，“符合 UEC”应是调查的开始，而非结论。

附带 RAND 专利义务的公开文档

1.0.3 规范可公开下载，并以 Creative Commons 署名-禁止演绎 4.0 许可分发。该许可允许重新分发署名，但不允许发布修改版本。很重要的一点是，版权访问与专利访问是分开的。

工作组章程通常使用传统的基于合理和非歧视（RAND）专利许可的模式。RAND 不一定意味着免费。该术语不保证统一价格，不消除谈判，也不阻止对有效性、必要性、地域或防御条款的诉讼。商业立场取决于每项声明的专利、成员的承诺以及任何双边许可。

UEC 维护一个必要的索赔声明的公开注册表。截至研究时，可见与 Broadcom、Microsoft、Huawei、Qualcomm、AMD、HPE、Google 和 Marvell 等相关的声明，包括与未来 1.1 工作相关的申请。该注册表通过告知实现者在构建或销售产品前可能需要调查知识产权来提升透明度。

该联盟不确定所声明的专利是否有效、真正必要、被侵权或可能以给定价格获得。它也不公布通用许可。因此，较小的实现者可能承担较大成员更容易吸收的法律和交易成本。一份公开规范仍可能导致市场集中，要是专利澄清、芯片成本和测试较高的话。

知识产权框架也影响治理激励。企业贡献技术以扩大其产品的市场，并使其现有能力在共同设计中得到代表。专利声明只有在尽早并足够清晰时才能减少意外。它们并不能消除许可证在架构采用后成为障碍的风险。

因此，诚实的描述是“公开出版的、多供应商的规范，具有 RAND 专利承诺”，而不是“普遍免版税”。买家既需要技术概况，也需要许可路径。

第一波产品与测试浪潮

实现证据在 1.0 版附近变得可见，但它们对应于不同的成熟度水平。

AMD 于 2025 年 4 月推出其 Pollara 400 AI 网卡，并描述为围绕发展中的 UEC 能力设计。Pollara 是一个重要的可编程平台，表明传输已达商业硬件。措辞仍然至关重要：为发展中的 UEC 功能设计，并不等同于针对所有最终 1.0.3 要求的独立认证。

Broadcom 于 2025 年 6 月宣布 Tomahawk 6 作为一款 102.4 Tbit/s 的交换 ASIC，具有适合 UEC 结构的功能。10 月，它宣布了 Thor Ultra 800G 网卡，并声称完全符合 UEC 功能。这是一个重要的供应商声明，但公开证据并不能将其转化为独立的联盟证书。产品的样品状态、软件成熟度和确切配置文件必须区分开来。

Nokia 和 Keysight 于 2025 年 10 月宣布了通过 800 Gigabit 以太网的 Nokia 7220 和 7250 交换机系列的端到端 UET 流量演示。Keysight 提供了流量生成和验证。该测试表明 UET 可以穿越商业系统，并且测试工具正在发展。它没有证明完整的、多供应商的端点配置文件、生产规模或所有选项的独立认证。

其他成员描述了与 UEC 相关的交换机、系统、软件或测试计划，2026 年峰会强调了产品化。现有元素支持向实现转型的观点。它们尚未提供精确数量的已出货 UET 网卡、已认证交换机、已部署云区域或完整结构。

对这一浪潮的最佳解读是证据链。规范使设计成为可能。芯片和网卡的宣布显示投资。流量演示展示部分互操作性。矩阵组织需求。运营商部署报告将证明运营价值。独立的互插拔测试和生产结果将提供仍缺乏的更广泛公信力。

RoCE、InfiniBand、Slingshot 与 UALink

UEC 进入了一个存在成熟技术和相邻系统的市场。其战略论点并非以太网从未承载过 RDMA，也不是专用架构不起作用。它声称，当前 AI 工作负载的规模和同步性决定了需要一个从端到端重新思考的以太网架构，在交付、路径利用和拥塞方面具有更大的灵活性。

RoCEv2 是直接的前身和广泛部署的技术。它在可路由以太网上传输 RDMA，并拥有广泛的应用和产品支持。UEC 批评常见部署将整个流固定到单一路径、Go-Back-N 恢复、接收端重排、DCQCN 调整困难、许多架构中依赖优先级流量控制，以及在 incast 或集体突发流量下的行为。这是 UEC 的技术立场，而不是证明所有 RoCE 网络都差劲的证据。

比较是动态的。供应商可以在保持 RoCE 兼容性的同时，向可编程网卡添加自适应路由、数据包喷洒、更好的拥塞控制或其他 UEC 思想。AMD 围绕 Pollara 的通信已经将 RoCEv2 和 UEC RDMA 作为可编程硬件上的两种选择。因此，UEC 既可以作为完整传输层与 RoCE 竞争，又可以影响其演变。

InfiniBand 是主要的专用替代方案。它提供一个集成的 RDMA、拥塞、链路可靠性和管理生态系统，并拥有长期的 HPC 经验。InfiniBand Trade Association 的 2.0 工作包括 200 Gbit/s XDR 通道和更新的遥测。UEC 最有力的区别并不是声称 InfiniBand 缺乏性能，而是试图通过以太网供应链、标准 IP 路由和更广泛的供应商选择来实现 AI/HPC 行为。

HPE Slingshot 占据中间位置。这种兼容以太网的 HPC 结构，具有自适应路由和拥塞管理，为 UET 提供了重要的前身。它证明了可以在以太网上构建专用行为，同时也说明了受控商业平台与行业规范之间的差异。

UALink 通常是互补的。其公开的 200G 规范针对机箱内加速器之间的低延迟扩展连接，描述了多达 1,024 个加速器。UEC 1.0 主要是通过交换机跨节点的横向扩展结构。一个数据中心可以在一个机箱内使用扩展连接，在机箱间或节点间使用 UEC。未来 UEC 关于优化扩展连接和网络内集体操作的工作可能会使边界接近，并产生聚合或竞争。

NVIDIA Spectrum-X 和专有结构展示了另一种权衡：集成栈可以快速优化硬件、软件和支持，但增加了对单一生态系统的依赖。UEC 用一部分这种集成换取公共接口和选择性的承诺。该权衡的价值将取决于性能、支持、专利、互操作性和总成本，而非仅靠“开放”作为口号。

运营问题超越协议本身

一个 573 页的规范可以定义许多需求，但生产结构仍然需要一个运营模型。1.0 版在规范性文档周围留下了大量的管理工作。运营商必须一致地配置配置文件、流量类别、ECN 阈值、熵集、链路选项、密钥、固件、遥测和故障策略。

混合流量使任务更复杂。一个结构可能同时承载 UET、RoCE、TCP、存储、管理以及有序或无序的 UET 服务。队列分配和公平性并不能仅靠每条协议正确运行来解决。一个拥塞控制在隔离时可以良好运行，但在面对使用不同信号的另一个控制器时可能行为失常。

端点复杂性是另一个结构性风险。UET 在其中放置多路径、直接放置、选择性重传、多种模式、基于窗口和信用的控制、截断包接收、安全以及大量状态。这可能会增加硅片面积、固件大小、验证工作量、能耗和待诊断的故障。终端智能使广泛的供应商链成为可能，但也使每个服务器中的组件变得复杂。

可选功能创造了差异化和碎片化。一个供应商可以针对传统 ECMP 和 ECN 优化 AI Base。另一个可能支持 AI Full、TSS、截断、LLR 和 CBFC。两者都参与同一个生态系统，但不能保证相同的性能或安全性。合规性矩阵必须成为运营能力矩阵。

版本维护将是持续的。1.0.1 到 1.0.3 的修正涉及拥塞、信用、恢复和数据包。一个大型集群可能包含多个网卡固件版本、交换机软件和测试工具。在不协调其他层的情况下升级一层，可能会暴露联盟试图避免的跨层竞争。

因此，外部联盟至关重要。OCP 将传输与开放硬件和系统连接起来。OFA 和 libfabric 连接应用。IEEE 802.3 带来正式的以太网过程。SNIA 和 NVM Express 带来存储和管理。IETF 机制提供 IP、ECN 和其他基础。这些组织有不同的流程和时间表；联络可减少重复，但不保证同时采用。

最终的测试是可运营的基础设施。一份文档可以定义行为，一个供应商可以宣布产品，一个联盟可以组织峰会。没有什么能取代一个集群，在那里独立的端点和交换机在拥塞、故障和升级下完成真实作业，而操作员能够解释结果。

当前相关性：从文档胜利到实现可信度

到 2026 年 7 月，UEC 已实现其启动时不确定的多个目标。它组建了广泛的联盟，产生了跨越五层的集成架构，发布了完整的 1.0 规范，进行了维护，增加了 200G 通道，披露了专利声明，并引发了产品和测试公告。该项目是活跃的，其议程已明显转向实现。

这种进展使不确定性更加重要。没有单一的注册表公布当前的成员总数和指导委员会的构成。成员页面和章程对访问方式的描述不同。TAC 的正式领导层与峰会角色未完全协调一致。1.0.2 的日期在官方文档之间存在分歧。合规性套件使用了过时的配置文件术语。这些问题都不会破坏架构，但每个问题都标志着在精确版本至关重要的项目中，文档控制的质量。

最大的差距涉及采用。UEC 不发布部署统计、独立产品注册表、独立预算或经审计的账目。没有公开证据证明在声称的最大规模上可互操作的 1.0 网络全功能运行。供应商的演示和声明有用但带有商业利益。与 RoCE、InfiniBand 和集成以太网平台的中立比较仍然有限。

机遇仍然巨大。以太网是数据中心的最大公约数，AI 市场可以支撑新一代网卡、交换机、光学器件和软件。运营商有强烈的激励避免单一供应商依赖并提高加速器利用率。一个共同的栈可以将这些激励转化为采购杠杆。

风险在于“Ultra Ethernet”可能成为一套不兼容子集的保护伞。如果基本传输有效，但配置文件、拥塞、安全和管理出现分歧，品牌可能比互操作性传播得更快。如果 RAND 许可证昂贵或不确定，供应商链可能收窄。如果 RoCE 吸收了最具吸引力的想法而不改变传输层，UEC 可能影响市场而不成为主导标签。

决定性的问题不再是联盟能否发布一个复杂的规范——它已经做到了。问题是独立的组织能否实现相同的合同、获得必要的许可、大规模运营该结构并随演进保持兼容性。UEC 成为基础设施的程度，仅限于其声明经受住生产代码检验的程度。