UEC规范v1.0 - 1.简介_整体架构_软硬件分层

UEC 解释

超级以太网联盟™ (UEC) 是一个基于共识的标准组织，隶属于 Linux 基金会。其成员公开合作，致力于定义和推广适用于现代计算环境的高性能以太网技术。本规范（简称“规范”）包含 UEC 的已批准交付成果，该术语的定义见 UEC 章程。本文档遵循知识共享署名-禁止演绎 4.0 国际许可 (CC BY-ND 4.0)。根据许可协议规定，您可以复制和重新分发本文档，但必须注明署名超级以太网联盟。但是，如果您基于该材料创作衍生作品，则不得分发该作品。许可协议副本可在 https://creativecommons.org/licenses/by-nd/4.0/ 获取。本规范按“原样”提供。 UEC 和 Linux 基金会（以下简称“双方”）不作任何明示或暗示的保证，包括但不限于适销性、适用于特定用途、不侵犯任何第三方知识产权或遵守适用法律的保证。使用本规范中的信息风险自负。本规范的结果和性能的全部风险由用户承担。在任何情况下，双方（定义如上所述）均不对任何其他方因与本规范或其管辖文件相关的任何诉讼原因而造成的利润损失或任何形式的间接、特殊、偶然或后果性损害承担责任，无论该等损害是基于违约、侵权（包括疏忽）或其他原因，也无论本规范的接收者是否已被告知存在此类损害的可能性。本规范可能包含对可能被主张专利权的技术的引用。UEC 不对任何此类权利的存在或状态作出任何陈述。本规范的实施者应全权负责从适当的权利持有人处获取任何必要的许可或授权。 UEC 保留根据其认为必要或适当的情况对本规范进行任何更改或修改的权利。UltraEthernet™ 和 UltraEthernetConsortium™ 是 UltraEthernetConsortium 在美国和其他国家/地区的未注册商标。保留所有权利。有关 UltraEthernetConsortium 的更多信息，请访问：https://ultraethernet.org

UEC简介

1.1 背景

超级以太网联盟 (UEC) 是一项行业努力，由众多贡献者共同发起，包括超大规模计算厂商、系统供应商、芯片供应商等，其使命是增强以太网在人工智能 (AI) 和高性能计算 (HPC) 中的应用。贡献者的目标是涵盖成功规范的各个方面，包括软件 API、网络协议、硬件友好性和可扩展性、网络操作、合规性和可扩展性。为了实现 UEC 的使命，本文档提供了用于以太网网络的新协议规范，以及对现有以太网协议的可选增强功能，以提高人工智能 (AI) 和高性能计算 (HPC) 应用的性能、功能和互操作性。超级以太网 (UE) 规范涵盖了与人工智能 (AI) 和高性能计算 (HPC) 工作负载相关的广泛软件和硬件：从符合 UE 标准的设备支持的 API 到传输层、链路层和物理层提供的服务，以及管理、互操作性、基准测试和合规性要求。UE 不要求或强制更改网络层或以太网物理层和链路层。例如，符合 UE 标准的实现可能使用规范发布时市场上常见的以太网交换机。但是，UE 提供可选的网络、以太网 PHY 和链路层功能，可为要求苛刻的应用程序提供更佳性能。随着时间的推移和经验的积累，其中一些可选功能可能会变得司空见惯，甚至成为必需功能。符合 UE 标准的实现支持本规范中的强制性要求。

1.1.1 UEC 组织

UE 架构包含经典 ISO/OSI 网络模型的四个较低层，以及软件服务和将这些服务公开给较高层的 API。这四个层中的每一层都由一个 UEC 工作组（在图 1-1 中以横线表示）负责，该工作组定义了所需的架构，并在可扩展性、功能、性能和互操作性方面具有严格的要求和特性。UEC 管理工作组提供以太网结构和端点管理。UE 管理架构包括管理协议、传输和数据模型。UEC 合规性工作组与技术咨询委员会 (TAC) 合作，定义合规性和互操作性要求。 UEC 管理工作组和调试与性能工作组与上述所有工作组进行互动。此外，UEC 正在为相关应用程序和工作负载添加网络服务以及存储服务。图 1-1 中以列表示的工作组是在以行表示的初始工作组之后成立的。他们对 UE 规范和其他独立文档的贡献计划在未来发布。UEC 隶属于 Linux 基金会联合开发基金会 (JDF)，是一个国际标准开发组织 (SDO)。UE 规范现已开放供公众下载。未来版本一旦创建并批准，也将公开提供下载。UEC 成员旨在向合适的标准组织和/或相关的开源社区提交其工作成果，以鼓励广泛采用，并为以太网、互联网协议 (IP)、软件和 API 开发的主流行业标准化工作做出适当的贡献。值得考虑的潜在相关 SDO 包括但不限于 IEEE、IETF、OCP、OFA、SONiC/SAI 以及各种存储和管理 SDO。

1.1.2 UE 传输配置文件

UET 指定了三种配置文件：AI Base、AI Full 和 HPC。AI Base 配置文件旨在提供当前和未来 AI 应用所需的功能，这些应用需要以最低成本实现高性能。AI Full 配置文件增加了一些附加功能（例如，可延迟发送、精确匹配和对原子原语的支持）。HPC 配置文件满足高性能计算应用的需求，在很大程度上是 AI Full 配置文件的超集。每个配置文件都列出了兼容产品在传输层提供的服务以及所需的独特功能。配置文件本身的定义在第 3.3 节中。终端硬件接口的细节超出了 UE 规范的范围。上层的软件 API 被指定用于提供与更高层软件的互操作性。目标是使支持给定配置文件的不同供应商的设备能够展现这些规范中描述的互操作性和功能。配置文件可能包含可选实现的功能。如果实现了可选功能，则它们必须遵循定义的规范才能声明合规性。

1.2 UE规范约定

1.2.1 规范性、信息性和实施声明(略...)

1.2.2 术语(...)

1.2.3 格式

图用于定义协议报头和协议序列交换。这些图的约定如下所示。如果图表和图与文本描述不经意地出现矛盾，则始终以文本为准。

1.2.3.1 报头格式

图 1-2 是一个完整报头堆栈的示例，如本规范其他部分所示。这些完整报头堆栈并未显示每一层中每个报头的所有细节，而是标识了解析报头和查找堆栈下一层所需的重要字段。报头堆栈的各层显示在左侧，并以颜色区分。

图 1-3 是本规范其他部分中使用的单独详细报头图的示例。字节从顶部到左侧依次标记。字节的最低有效位 (LSB) 位于左侧第一位，最高有效位 (MSB) 位于右侧。报头字段标记在字节标签下方，顶部，字节偏移标签的右侧。报头字段宽度基于实际位大小。保留字段在接收时将被忽略，并以零形式传输。每个单独的报头都是一个独立的图，显示报头从字节偏移量零开始的位置。接收数据包中报头的实际偏移量取决于先前报头的具体格式，这些报头未在独立图中显示。

标头字段的描述在详细标头图后的表格中提供。

1.2.3.2 序列图

图 1-4 展示了本规范中使用的序列图示例。序列图用于说明两个实体之间以及实体内各个功能层之间特定信息交换的时间线。事件时间线自上而下流动。序列图并非对实体之间交换的完整信息集进行规范性描述，而是用于描述通信场景的特定实例。该示例展示了外部实体（例如，libfabric 提供程序）向 UET 语义层提供的消息，以及如何将其分解为数据包并传递到 PDS 层以便通过网络传输到远程目标。一些重要的 UET 标头字段显示在指示通过网络传输的数据包的箭头上方。信息交换期间发生的操作和事件使用虚线箭头和支持文本突出显示。

1.2.4 参考文献

UE 规范提供了规范性参考文献和信息性参考文献。规范性参考文献是确保 UE 组件之间互操作性的必需文献。信息性参考文献旨在提供更多背景信息，并帮助您进一步理解 UE 的运行环境。UE 规范的每一章都可能提供一份规范性参考文献和信息性参考文献列表。本介绍性材料使用了以下规范性参考文献：

[1] IETF RFC 2119，“用于在 RFC 中指示需求级别的关键词”，1997 年。[在线]。可访问：https://www.rfc-editor.org/rfc/rfc2119。 [2] IETF RFC 8174，“RFC 2119 关键词中大写字母和小写字母的歧义”，2017 年。[在线]。可访问：https://www.rfc-editor.org/rfc/rfc8174。 [3] IETF RFC 2474，“IPv4 和 IPv6 报头中的差异化服务字段 (DS 字段) 定义”，1998 年。[在线]。可访问网址：https://datatracker.ietf.org/doc/html/rfc2474。 [4] IETF BCP14，“IETF 最佳实践 14”，2023 年。[在线]。可访问网址：https://datatracker.ietf.org/doc/bcp14/。

1.3 系统视图和术语

人工智能和高性能计算 (HPC) 领域正在快速发展。人工智能模型的变化速度甚至更快。这就需要能够针对各种人工智能和高性能计算 (HPC) 工作负载进行水平和垂直扩展的精细调整系统。水平扩展涉及添加更多端点和/或光纤交换机。垂直扩展涉及通过添加更多处理能力、内存和/或存储空间来扩展端点。算法和模型的演进速度正在超越硬件（主要体现在内存、存储和网络方面）。最优系统需要平衡计算、网络（即网络结构）和相关数据（即模型参数和训练数据）这三个要素。UE 规范明确地阐述了网络技术，并隐式地阐述了其他要素。UE 规范涵盖了分布式工作负载，无论是人工智能还是高性能计算 (HPC)，并且自然地继承了一些并行计算的命名规则。图 1-5 提供了 UE 规范所涉及的并行计算组件、术语和概念的系统概览。下文将对 UE 环境及其相关命名规则进行概述和介绍。本标准中规定的组件的流程、协议和操作的技术细节将在后续的规范章节中提供。UE 被指定在集群内运行，其中包括通过网络结构互连的节点。每个端口实现 IEEE Std 802.3 定义的单个媒体访问控制 (MAC)，并可选地包含其所遵循的 UET 配置文件所需的任何 UE 特定扩展。一条链路连接两个端口。交换矩阵接口 (FI) 是一个物理实体，它提供一个或多个端口，并将一个或多个交换矩阵端点 (FEP) 暴露给一个或多个操作系统实例 (OSI)。交换矩阵地址 (FA) 可以是 IPv4 或 IPv6 地址，FEP 是一个逻辑上可寻址的实体，被分配了单个 FA。UE 传输协议终止于 FEP，并可选地包含安全上下文。具体而言，一个 FEP 只能由单个 OSI 使用，并且一个节点可以有一个或多个 FEP。每个 OSI 可以使用一个或多个 FI 和一个或多个 FEP 连接到交换矩阵。交换机具有两个或多个端口，是交换矩阵的一部分，是一种数据包转发设备。数据包根据转发信息沿着路径转发，该信息包括数据包的 FA、其他报头字段（例如，用作熵值的 UDP 源端口）以及交换机状态。任何两个具有相同路径转发信息的数据包都应采用相同的路径通过交换矩阵。结构平面是一组通过链路（可选交换机）连接的 FEP，允许任何 FEP 与同一组中的其他 FEP 通信。不同结构平面之间的 FEP 通信不在本规范的讨论范围内。路径存在于结构平面内，但不存在于结构平面之间。结构由一个或多个结构平面组成。

节点是具有一个或多个前端端点 (FEP) 的计算设备。集群是由一组通过结构连接的此类节点组成的集合（请注意，图 1-5 中的简化图仅用于说明目的，仅显示集群中的单个节点。典型的用户设备 (UE) 部署可能包含数十万个节点）。加速器是一种计算模块或设备，旨在高效执行特定功能。CPU 是用于任意计算的通用处理器。CPU 和加速器都连接有内存，FEP 可以通过虚拟寻址访问该内存。节点可能具有本地存储，并包含一个或多个 CPU 和/或一个或多个加速器。用户是具有集群节点访问权限的实体。用户可以执行进程。进程是在特定用户拥有的 OSI 上执行的程序实例，并在内存中拥有私有虚拟地址空间 (VAS)。进程由其运行所在 OSI 的唯一进程 ID (PID) 标识。进程地址空间 ID (PASID) 是每个 OSI 中 VAS 的唯一标识符。集群可以以两种截然不同的方式使用，并且可能共存：

1. 在并行作业模型中执行（例如，MPI/*CCL 或 SHMEM）。
2. 在客户端/服务器模型中执行，客户端可以连接到服务器（例如，存储或函数即服务 (FaaS)）。

每个数据包都带有一个标识符，指示其参与的模型。并行作业执行的特点是“运行至完成”模型，而客户端/服务器执行通常无限期地运行服务器，为无限数量的客户端提供服务（通常具有复杂的可靠性和可用性保证）。两个 FEP 需要 IP 级连接才能通信。如果任何 FEP 都关联一个 FA（即 IP 地址），则用户设备 (UE) 网络支持多端口 FEP。与 FEP 关联的 FA 用作从该 FEP 发送的所有数据包的源，或用作发送到该 FEP 的所有数据包的目标。 FEP 可以有多个端口（例如图 1-6 中的场景 A）。UE 不强制要求如何使用这些端口。许多多端口配置都是可行的，包括：成员端接于同一交换机的链路聚合 (LAG)（例如图 1-6 中的场景 D）；成员端接于不同交换机的多交换机 LAG（例如图 1-6 中的场景 E）；或 IP 级多路径连接，通过多个端口或主备配置到达 FEP 的独立地址。其他支持在通用 Fabric 接口上实现多个端口的方案也是可行的，并且取决于具体实现（例如图 1-6 中的场景 B、C 和 F）。图 1-6 中的场景 F 展示了 Fabric 接口卡上的嵌入式交换机。

在多端口 FEP 架构中，UET 拥塞管理子层会为每个数据包选择熵值。UET 不强制多端口主机使用任何特定的端口选择方法；不同实现方式可能存在差异。信息文本：在多端口配置中，网络应提供一种机制，允许 FEP 检测目标 IP 地址（例如，对等 FEP 的 FA）是否在任何给定平面上不可达，如果是，则避免将该平面用作目标。可能的实现方法包括使用 IP 路由协议或 ICMP 不可达消息将不可达信息告知 FEP。然而，UET 并不强制任何特定技术。未来可能会在 UET 中定义机制来确定可达性。两种不同的计算模型在寻址方面有所区别：并行作业和客户端/服务器。单个 FEP 可以设计为支持两种或仅支持一种计算模型的流量类型。两种模式可以在单个 FEP 上同时运行。图 1-7 和图 1-8 是集群内两种不同计算模型的概览

并行作业是运行在同一用户集群上并进行通信的进程集合。作业通常集体启动，并由集群内的 JobID 唯一标识。JobID 用于寻址和授权。作业由一个或多个 Rank 组成，这些 Rank 是协作计算特定工作负载的进程。一个作业可以在每个 OSI 上生成多个 Rank，而一个 OSI 可以承载多个作业的 Rank。如果一个作业全局包含 R 个进程/Rank，则它们的 RankID 编号为 0 到 R-1。在并行作业模型中，本地 PIDonFEP 寻址范围从 0 到 P-1，其中 P 个进程与给定作业的 FEP 相关联。如果每个 FEP 都关联相同数量的进程，则每个端点都可以轻松计算特定 RankID 的 PIDonFEP。例如，假设一个作业在 N 个节点上的 R 个 Rank 上运行，每个节点都有 F 个 FEP。 RankID 的范围是 0 到 R-1，每个节点的等级是 R/N，每个 FEP 的等级是 R/N/F。在这种情况下，P 是 R/N/F，PIDonFEP 的范围是 0 到 P-1，或 0 到 R/N/F-1。服务器是节点上的软件实体，为一个或多个客户端提供服务。客户端和服务器通过 FEP 进行通信。服务器 PIDonFEP 标识特定 FEP 上可用的服务，资源索引标识该服务中的资源。同一个 FEP 可能被多个服务器（在单个 OSI 上）使用，并且单个服务器可能通过 FEP 上的多个 PIDonFEP 提供服务。客户端/服务器 JobID 在概念上与“N 对 1”连接相同，因为它用于客户端向服务器的授权，但它可能是短暂的，因为它仅在流量活跃时存在。服务器 PIDonFEP 和资源索引的组合在概念上与 TCP/UDP 端口相同。 UET 服务器可以使用众所周知的服务器 PIDonFEP 值和一组特定服务的资源索引，UET 客户端可以使用预配置的静态服务器 FA 或各种发现机制将服务器的主机名或别名解析为 FA，例如 DNS 或“hosts”文件，从而允许客户端与服务器建立通信。此外，UET 客户端和服务器可以选择使用非 UET 发现方法，例如首先建立 TCP/IP 连接，然后交换 UET 功能、地址和标识符。UET 具有相对和绝对端点寻址模式（参见图 1-9）。相对寻址模式在并行作业模型中提供连续寻址，以确保可扩展到最大进程数。绝对寻址用于客户端/服务器模型。在相对寻址模式下，UET 定义了目标地址的四个互补部分：1. 标识 FEP 的 FA。2. 唯一标识集群中作业的 JobID。3. 范围从 0 到 P-1 的 PIDonFEP。 4. 资源索引 (RI)，用于标识目标进程内的服务、库或其他实体（例如，MPI 与 *CCL）。当数据包到达目标 FEP 时，可以根据 JobID 和 FEP 上的 PID 的组合来确定目标 PASID。

参考文本：假设一个作业包含 K 个端点，每个端点有 P 个进程。此寻址方案允许在源端使用大小为 K-1 的表转换为目标 FA，然后在目标端使用大小为 P 的表转换为目标进程。在一个支持每个端点多个作业的系统中，JobID 会区分目标端的不同作业，从而找到大小为 P 的正确 PIDonFEP 表。这避免了在源端使用单一平面地址空间时所需的 O(KP) 个表条目。此方法将 O(KP) 个表条目替换为 O(K+P) 个条目。K 预计为数万，P 预计为数百。

在绝对寻址模式下，UE 定义了地址的三个互补部分：1. 标识 FEP 的 FA。2. 标识与目标 FEP 关联的 OSI PID 之一的 PIDonFEP。3. 标识目标进程内的服务或其他实体的资源索引 (RI)。

RI 用于寻址服务器中的特定子程序或功能（例如，运行 FaaS 或 rPC 服务）。当数据包到达目标 FEP 时，目标 PASID 将根据 FEP 上的 PID 确定。JobID 不属于寻址的一部分，但用于授权。消息代表 UE 网络中的单个通信事务。图 1-10 展示了消息通信传递背后的主要概念。事务由调用 UET libfabric 提供程序的进程创建，该提供程序又调用语义层。语义子层创建各种消息以完成事务。在源 FEP，消息及其关联的缓冲区被拆分成一组按空间顺序排列的数据包，这些数据包的内存寻址方式与源 FEP 相同。这些数据包沿着路径在网络中发送和路由，可能无序。消息最初可能涉及 UET 语义规范中讨论的会合协议步骤。此类消息的源称为发起方 (initiator)，目的地称为目标 (target)。每个数据包都有一个源 FEP 和一个目标 FEP。路径是一组有序的链路（位于节点和/或交换机之间），两个 FEP 通过这些链路进行通信。在不考虑网络结构中的数据包丢失的情况下，沿相同路径发送的相同流量类别 (TC) 的数据包始终会按照它们在源 FEP 处发送的顺序在目标 FEP 处接收。当数据包在两个 FEP 之间沿多条路径路由时，无法保证不同路径之间的到达顺序。UET 期望交换机在路由不变的情况下，从同一 PDC 沿相同路径递送两个具有相同熵值和流量类别的数据包。UE 传输协议 (UET) 定义了 FEP 之间通信的协议、数据包格式和 FEP 策略。FEP 可以设计为支持并行、客户端/服务器或两种流量类型。数据包递送上下文 (PDC) 是两个 FEP 之间的单向逻辑实体，通常是瞬时实体（由传输协议定义），它存在于发起方 FEP 和目标 FEP 中，用于控制数据包的成功传输。数据包传送子层 (PDS) 创建并使用 PDC 来提供所需的排序和可靠性传送模式。可靠性是通过确认数据包（即 ACK 和 NACK）实现的，目标端将这些数据包传输给源端，以指示端到端接收成功。拥塞管理子层 (CMS) 控制源端在任何给定时间内可以传输到目标端的字节数。数据包窗口是指 CCC 上未完成的未确认字节数的最大值。同一作业的多个进程可以共享一个 PDC，而一个进程可以使用多个 PDC 与另一个进程通信。两个 FEP 之间可以有一个或多个 PDC，每个数据包都标识一个关联的 PDC。

1.3.1 工作负载 [信息性]

本小节中的信息为背景资料，代表了截至 UE 规范 v1.0 发布时工作负载的最新水平。UE 面向以下四种工作负载：1. 人工智能训练 (AIT) 2. 人工智能推理 (AII) 3. 高性能计算 (HPC) 4. 客户端/服务器（例如，存储流量）

1.3.1.1 人工智能训练工作负载

人工智能训练工作负载最初以“三维并行”为特征，其中通信模式可以表示为三维环面（如果有利的话）。第一个维度是数据并行 (DP)，其中单个小批量中的示例通过多个模型副本进行处理，并且梯度或权重通过全归约 (AllReduce) 操作进行同步。第二个维度是流水线并行性 (PP)，其中每个流水线阶段都是模型的一组层，前向激活和后向误差的通信在不同加速器上的相邻层之间进行，从而形成具有点对点通信的流水线。第三个维度是算子并行性 (OP)，它取决于层的类型。对于大型语言模型 (LLM)，主要的层运算是矩阵乘法。因此，层将实现并行矩阵乘法，该运算也可以用 allreduce 运算来表示。“混合专家”模型通常使用专家并行性 (EP)，它在 3D 并行性视图中类似于算子并行性。EP 将 k 个（通常 k=16 到 256）模型捆绑在一起，并在它们之间执行 alltoall(v) 运算。alltoall(v) 运算并不总是平衡的。人工智能推理并行性与之非常相似。不同之处在于它不考虑数据并行性，并且通常使用非常小的批次。因此，作业大小和传输的消息通常都较小。后来，额外的并行维度（例如序列并行和上下文并行）被添加，并可能导致更高维度的通信结构。以工作负载为例（大约在2023年），著名的GPT-3模型在96个Transformer层中拥有1750亿个参数。在FP16中存储这些参数需要350 GiB，这需要多个2023年可用的最先进的加速器（不考虑训练期间存储的激活或其他临时值或副本）。在这种情况下，如果流水线中有六个加速器，而运算符并行维度中有四个加速器，则每四个加速器就有16个GPT解码器层。在2023年可用的加速器上，这将花费大约160毫秒的计算时间。然后，每个维度（流水线和运算符）每层的通信量为50 MiB。假设目标服务级别目标是200毫秒，那么40毫秒用于流水线通信和环路Allreduce（发送两次数据）。现在，每个加速器会向 allreduce 发送 16*2 次 50 MiB 数据，并沿着流水线维度发送一次。因此，它需要在 40 毫秒内传输 1.7 GiB 数据，即 41 GiB/s 的吞吐量。为了降低延迟，可以扩展运算符维度并减少通信时间。对于 10 毫秒的服务级别目标，大约需要 150-200 GiB/s 的吞吐量。AI 训练工作负载遵循 3D 并行方案，但除了权重之外，每个加速器通常还会存储权重的“黄金副本”以及其各层的所有激活输出，直到它在反向传播中应用梯度。通常，AI 训练工作负载需要极高（廉价）的带宽，并且对延迟的敏感度较低到中等。典型的消息大小在兆字节或更大范围内。

1.3.1.2 AI 推理工作负载

AI 推理工作负载遵循 3D 并行方案，但不提供数据并行性，因为每个输入样本都是一个用户请求。它们可以分批处理，但通常仅用于提高加速器效率。AI 推理工作负载有时具有严格的服务级别目标要求，以满足交互式使用模式。在这种情况下，批次较小，从而导致激活（管道消息）和操作（allreduce）也较小。这些通常保持在千字节大小范围内。以 GPT-3 上的生成式 AI 推理为例。在这种情况下，仅输入一个标记，而不是上面 GPT-3 示例中的完整序列。因此，所有内容大约都小一个序列长度（GPT-3 为 2048）。实际上，生成推理系统通常使用束搜索来提高质量。当束宽度为 4 时，总收缩因子为 512。不幸的是，权重内存保持不变，导致相同的分布（OP=4，PP=6）。现在计算时间可以小到 1 毫秒，每个加速器将发送 3.3 MB 的数据。如果服务级别目标为 1.2 毫秒，则 Reduce 将在 0.2 毫秒内完成，带宽需求为 16 GB/s——但现在 allreduce 的大小约为 100 KB。如果将它们拆分到多个平面，那么消息大小将ld 应该在个位数千字节的范围内。分布式键值缓存会增大带宽需求！推理通常比训练需要更低的延迟。

1.3.1.3 HPC 工作负载

HPC 工作负载分为两类：(1) 低深度 (LD)，高度并行；(2) 高深度 (HD)，依赖链较长。HD 工作负载通常具有细长的有向无环图 (DAG)，导致执行对延迟敏感。许多高扩展性问题都属于此类。以天气预报为例。在这种情况下，计算必须在一定时间内完成。算法在模拟过程中会运行多次迭代，其中时间步长与分辨率成反比。更精确、更高分辨率的模型会缩短时间步长。实际上，此类模型的通信开销较高 (25-50%)，并且大多是重复发送的小消息（单包消息，大小为 2.5 kiB）。许多其他工作负载属于低深度，因此对延迟的敏感度较低。大多数弱扩展性工作负载都属于此类，因为用户可以调整本地域大小以在给定系统上良好运行。其中一些工作负载可能需要高带宽（例如 AI 训练）或高消息速率（例如图算法）。

1.3.1.4 客户端/服务器（例如存储流量）

存储流量将数据从存储服务器传输到端点，是客户端/服务器通信的一个例子。通信堆栈通常将较大的请求拆分成多个较小的消息（例如，几个 MiB 甚至几个 KiB）。这些消息的大小在某种程度上可以根据传输协议进行调整。数据访问模式和大小取决于用户，很少由系统管理员控制。因此，随机 incast 事件（例如，许多客户访问同一存储服务器）会定期发生。

1.4 软件

1.4.1 AI 和 HPC API 接口

UE 旨在支持 libfabric v2.0 API，并与 libfabric 社区合作，以允许终端与 AI 框架和 HPC 工作负载交互。某些 UE 可选功能需要网络设备（例如交换机）的支持才能实现数据包修剪等高级功能。为此，网络操作系统 (NOS) 需要扩展才能支持 UE 功能。UE 目前不支持跨管理域的交互。

1.4.2 Fabric 终端软件栈

图 1-11 显示了在 FEP 上运行的软件栈。UE 旨在支持现有的 AI 训练 (AIT) 和 AI 推理 (AII) 框架。这些框架，例如 TensorFlow、PyTorch、JAX 等，有望在 UE 软件栈上无缝运行。换句话说，UE 的目标是使依赖于这些框架的应用程序能够迁移到由 UE 驱动的节点，而无需进行任何更改。这些框架通常会利用依赖于硬件且特定于供应商的 *CCL 库。然而，兼容 UE 的 *CCL 库虽然没有直接指定，但不需要应用程序进行任何更改。

1.4.3 交换机软件栈

图 1-12 显示了支持 UE 功能的交换机软件栈示例。UE 在现有的以太网交换机上运行，但可以通过支持交换机中的可选 UE 功能来获得额外功能。UE 环境中的交换机预计会运行各种网络操作系统（例如 SONiC、FBOSS、Junos OS、IOS 等）。交换机芯片中的可选 UE 功能可以通过已针对 UE 进行适当增强的交换机芯片抽象接口（例如 SAI）访问。交换机的转发范例及其相关的网络操作系统 (NOS) 无需进行任何更改。基于 IP 的转发可以保持不变；但是，UE 定义了可选功能（例如，数据包修剪）。

1.4.4 网络操作系统 (NOS) 接口

NOS 为交换机提供必要的配置和控制服务。某些 NOS 组件可能需要更新才能支持 UE 功能。以下是一些示例：

• UE 组织特定的 LLDP TLV。

• 数据包修剪。

图 1-12 显示了各种交换机模块的分层结构。交换机抽象接口 (SAI) 上方的层称为 NOS 控制平面，下方的功能称为 NOS 数据平面。控制平面软件通过抽象 API 与数据平面功能交互。一个示例接口是开放计算项目 (OCP) 中开发的交换机抽象接口 (SAI)。SAI 在供应商提供的软件开发工具包之上提供了一个抽象层。这种抽象有助于 NOS 与一组一致的 API 进行交互，以便进行硬件编程。请参阅以下参考资料：

• https://www.opencompute.org/wiki/Networking

• https://www.opencompute.org/wiki/Networking/SAI

SDN 控制器可能是 UE 实现的一部分，但不在 UE 规范的范围内。

1.5 网络

1.5.1 AI 和 HPC 网络分类

UE 区分三种网络类型，如图 1-13 所示：1. 前端网络 2. 后端横向扩展网络 3. 纵向扩展网络

1.5.1.1 前端网络

前端网络是数据中心的运营网络，它将所有计算节点连接到外部世界（例如，其他数据中心或互联网上的最终客户）。这使得前端网络成为数据中心中最重要的组件之一。前端传输的任何可用性损失都会对客户造成直接影响并产生相关成本。由于前端网络连接客户和远程数据中心，它可能支持各种传输协议（例如 TCP/IP、UDP/IP 和 QUIC），这些协议可在毫秒级延迟的长距离链路上运行。此外，计算节点的多租户特性被频繁使用，并且可能需要网络覆盖来支持虚拟机迁移和网络虚拟化。从根本上讲，前端网络承载两种类型的流量：往返于外界（即其他数据中心和客户）的“南北向”（NS）流量和来自同一数据中心内网络端点的“东西向”（EW）流量。每种流量类型都有根本不同的特征。例如，EW 流量通常比 NS 流量占用更高的带宽，并且数据包的“价值”较低（即，它们可以被丢弃并重新传输，且成本低于 NS 流量）。此外，由于EW流量通常连接各种服务，例如微服务的深度调用链、无服务器函数或存储访问，因此通常具有更严格的延迟（例如微秒级）和更高的带宽要求（例如数十Gb/s）。NS流量通常面向客户，瓶颈通常发生在数据中心之外。这些特性可能会将延迟限制在个位数毫秒级，带宽限制在数十Mb/s。处理除了提供高可用性之外，处理两种类型的流量使得前端网络非常复杂。交换机和网卡需要支持复杂的功能，例如过滤、策略、封装和安全。

1.5.1.2 后端横向扩展网络

后端网络通常是一个专用的高性能网络，相对于前端网络而言，其范围有限——通常部署在“集群”（例如，一组行）中。有时也称为“横向扩展”网络。后端横向扩展网络通常形成自己的第 3 层子网，并且通常不直接连接到前端网络。前端和后端网络之间的通信通常通过具有连接到两个网络的网络接口的计算节点进行。后端横向扩展网络用于非常特殊的用途。例如，HPC 后端横向扩展网络支持通过消息传递接口 (MPI) 进行通信，而深度学习后端横向扩展网络则用于传输训练流量。面向 AI 的后端横向扩展网络可能包含特殊用途的优化，例如交换机支持对海量数据进行集体操作；而面向 HPC 的后端横向扩展网络可能仅支持针对小型集体的延迟优化。拥有两个网络可能会增加整个系统的成本（即两个网络而不是一个——独立的前端和后端网络）。然而，两个网络可以实现流量（即互不干扰）和设计（即允许不同的架构和技术部署）的完全分离。在一些经典的 HPC 系统中，后端横向扩展网络为计算节点提供所有连接和网络服务。然而，这是通过在 HPC 传输协议（例如门户、IPoIB）之上改造传统传输协议（例如 TCP/IP）并接受其中隐含的权衡来实现的。

1.5.1.3 纵向扩展网络

纵向扩展网络通常是非常专业的短距离互连，通常仅配备一层交换机，甚至可能根本没有交换机。历史上的纵向扩展网络支持 I/O 一致性，而这并非在所有类型的互连中都始终存在。用于连接加速器（例如，被称为 GPU、FPGA 或专用 SoC 的 XPU）的现代示例包括 AMD 的 XGMI、NVIDIA 的 NVLINK、Intel 的 Xe Link、交换式 PCIExpress 和 CXL 系统。这些网络的功能通常包括内存语义（类似于用于批量传输的 RDMA），以及最低的可用延迟（针对小规模或程序化内存访问，目标是亚微秒级）。UE 主要关注后端和横向扩展网络，但 UE 技术的概念和部分内容可能适用于纵向扩展网络。在典型的 2024 数据中心环境中，这三种类型的网络具有不同的特征，如表 1-1 所示。说明性文本：本规范专注于后端横向扩展网络。UEC 将考虑对前端和纵向扩展网络提供机会性支持。其目的是在权衡利弊时，支持前端或纵向扩展网络的目标不会影响后端横向扩展部署的性能，也不会影响本规范的交付时间表。

1.5.2 UE 传输 (UET) 目标

UET 专注于支持高性能计算 (HPC) 和人工智能 (AI)（AIT 和 AII）的工作负载和用例。UET 主要针对 RDMA 服务，并致力于提供最佳、现代化且高度优化的传输服务，用于在 AI 和 HPC 工作负载中承载 RDMA。表 1-2 总结了其一般特征。这三种用例（即专用 AI 训练集群、云 AI/HPC 和大规模 HPC）涉及充分利用单个应用程序完整系统规模的组织，以及在机器的大部分空间中运行单节点应用程序的组织，以及介于两者之间的所有应用场景。 UET 的目标是通过单一传输协议服务于这些用例的广泛性。UET 的另一个目标是提供加速器友好的接口。这涉及定义一个规范，以最大限度地降低集成端点所需的硬件复杂性。另一方面涉及定义一个软件解决方案，使加速器和其他处理器能够在硬件中完成更多工作。例如，UET 可以允许加速器拥有“快速路径”，并将其他功能（例如管理和复杂的错误处理）转移到单独的处理器（例如主机 CPU）。硬件实现以及端点与加速器接口的细节超出了本规范的范围。虽然 UET 利用多路径和网络遥测辅助的改进拥塞控制在尽力而为的网络上提供了出色的性能，但它也适用于无损网络。对于尽力而为的网络，UET 汲取了以太网、TCP/IP 和部署在各种应用中的大规模网络的成功经验中的两个基本教训。包括云端——传输协议应提供丢包恢复功能，并且许多大规模无损交换结构在不触发队头阻塞和拥塞扩散的情况下运行具有挑战性。遵循这些原则，UE 传输建立在分布式路由算法和基于端点的可靠性和拥塞控制的成熟路径之上。

1.5.3 网络结构

网络结构由以太网交换机和下文所述的相关元素组成。

1.5.3.1 元素

UE 交换结构包含三个通用功能平面：控制平面、数据平面和管理平面。这些平面如图 1-14 所示，并描述如下。

1.5.3.1.1 控制平面

控制平面负责运行关键功能（例如路由协议），以维持交换结构交换机之间的通信。该层由网络操作系统 (NOS)（例如 SONiC、FBOSS 等）管理。控制平面使用标准 API（例如 SAI）或特定于供应商的 API 与交换机数据平面交互。

1.5.3.1.2 数据平面

数据平面，也称为转发平面，负责在网络中转发数据包。该层涵盖用户设备 (UE) 端点（即 FEP）和网络交换机。为了清晰起见，数据平面不控制或管理用户设备 (UET) FEP。该层包含交换机硬件的低级抽象，并负责根据控制平面提供的转发信息转发数据包。

1.5.3.1.3 管理平面

管理平面负责确保交换结构的运行、可靠性和安全性。管理系统和相关协议执行软件升级、监控和其他管理活动。管理平面使用标准接口（例如 Netconf、gNMI、SNMP 等）与控制平面交互。管理平面操作的管理对象由标准化数据模型（例如 YANG）定义，并由与供应商无关的软件（例如 OpenConfig）支持（参见：https://openconfig.net）。

1.5.3.2 UE 交换机在物理网络中的运行

符合 UE 标准的交换机可在两种类型的物理网络中运行：1. UE 数据平面网络：通过 UE 交换机将前端端点 (FEP) 相互连接的网络。该网络承载各种工作负载的应用流量，并针对 UE 规范进行了优化。2. 交换机管理网络：每个交换机至少提供一个专用以太网端口，用于连接非结构端点，例如 SDN 控制器、结构管理器、遥测收集器、SNMP 服务器以及其他负责管理基础设施的设备。该网络对延迟不敏感，通常对带宽要求较低。

1.5.3.3 拓扑

拓扑是 AI 和 HPC 结构的关键组成部分，因为它通过确定网络直径和等分带宽来设定性能界限。部署需要考虑能耗和物理方面（例如电缆成本）方面的最佳系统成本。本规范中的拥塞管理针对的是 Clos 网络，但不排除其他拓扑。但是，除了折叠式 Clos 网络（即胖树）之外，其他拓扑结构均未设定优化或性能目标。本规范中的拥塞管理已在胖树网络拓扑上进行了模拟。

1.5.3.4 网络约束

UE 结构受限于使用基于 IPv4/IPv6 的三层转发。目前尚未指定使用隧道（例如 VXLAN）的 UE 结构，该问题留给实现者解决。多租户可以在 FEP 级别通过加密租户应用程序数据、JobID 的特定分配来解决，也可以利用现有的隧道机制。UE 不需要更改网络层，可以使用现有的路由协议。UE 交换机使用等价多路径 (ECMP) 路由进行负载均衡，其中熵值由 UET 拥塞管理子层 (CMS) 管理。拥塞管理算法的设计预期是，架构交换机不会修改熵值，并且任何两个具有相同熵值的数据包在 UE 架构中采用相同的路径。CMS 期望 UE 交换机支持 IETF RFC 3168 中规定的显式拥塞通知 (ECN)，但附加限制是在出队传输而不是入队时标记拥塞数据包。数据包修剪（如第 4.1 节所述）是一种额外的拥塞通知机制，它使用多个差异化服务代码点 (DSCP) 来识别可修剪和已修剪的数据包，并确保它们映射到适当的流量类别以进行快速转发。流量类别体现在端点和交换机中用于区分数据包传输的机制和资源中（例如，队列、缓冲区、调度器）。流量类别与一个彼此之间可以相互区分优先级。数据包使用接收数据包的属性和报头字段映射到流量类别。UE 主要依赖 IP 报头中的 DSCP 字段来识别接收数据包的流量类别。信息文本：流量类别在多个级别指定。UE 将 libfabric 层指定的流量类别映射到整个交换矩阵中的流量类别。例如，UET 建议将请求和 ACK/NACK 分为不同的流量类别。UET 选择流量类别的广义定义，以确认包含排队资源和转发机制的实现，这些实现支持对由差异化服务代码点 (DSCP) 标识的数据包进行差异化转发。DSCP 可以识别 64 种不同的差异化服务，其中 16 种可供本地定义和使用。实现提供了多种方法来配置 DSCP 标识的数据包到端点链路和交换机级别的流量类别的映射。目前 UE 尚未识别或定义用于执行此映射的标准。在某些情况下，多个 DSCP 值可能会映射到同一个流量类别（请参阅 CMS 第 3.6.4.7 节中的 UET DSCP 映射表）。UE 功能依赖于在端点和整个交换矩阵中对流量类别的一致配置和使用。UE 建议使用一致的映射，网络运营商负责确保这种一致性。图 1-15 显示了应用程序请求的流量类别与端点和交换机链路层可用流量类别的映射。虚线框内的项目是 UE 运营商在 UE 解决方案堆栈的不同层可用的配置值。应用程序可以使用 fi_domain() 库 API 指定所需的 libfabric 流量类别。如果未指定，UE libfabric 映射第 2.2 节提供了用于请求的默认 DSCP 值。CMS 规范在第 3.6.4.7 节中提供了一个 DSCP 到流量类别的映射表。该表描述了不同类别的 DSCP 值如何映射到链路上的流量类别。来自 libfabric 层的消息请求的 DSCP 值会被传递并分类为 DSCP_TRIMMABLE 或 DSCP_NO_TRIM。UET 协议包含生成的 ACK、NACK 和控制数据包的 DSCP 值，这些值被分类为 DSCP_CONTROL。UET 协议还可以使用 DSCP_TRIMMABLE_RETX 对重传数据包进行分类。所有这些 DSCP 类别都会映射到链路级流量类别 TC_high 和 TC_low，这两个类别的优先级彼此较高或较低。修剪数据包的交换机（在图 1-15 中用剪刀图标表示）会根据它们在交换矩阵拓扑中的位置，将 DSCP 值更改为 DSCP_TRIMMED 或 DSCP_TRIMMED_LASTHOP。修剪数据包的 DSCP 值可以映射到第三个流量类别（TC_med）（如果可用），否则将使用 TC_high。将 DSCP 值映射到交换机内部流量类别的管理操作是特定于供应商的，或者当前尚未指定。 UET 拥塞管理子层的设计目标是至少使用两种流量类别来实现高性能。网络运营商负责分配和配置 UET 使用的流量类别。UET 数据包类型与流量类别的映射取决于网络是尽力而为还是无损传输。更多详细信息，请参阅 CMS 第 3.6.4.7 节。

1.6 UE 规范概述：层

UE 规范涵盖从软件层到物理层的多个层级。图 1-16 按层级展示了 UE 规范的必需组件和可选组件。以下章节概述了各层：

1.6.1 软件层

第 2 节提供了 UE 软件规范。其中包括与 libfabric API 的映射。libfabric 映射：符合 UE 标准的实现支持 Open Fabrics 接口 - libfabric API https://ofiwg.github.io/libfabric/。Libfabric v2.0 表示符合 UE 标准的终端的基准 API。Libfabric 是北向 API，用于定义 UE API 并检查其合规性。UE 规范应与 libfabric 社区保持一致。之所以选择 Libfabric，是因为它支持基于 RDMA 的 Fabric 上的多种工作负载，并且许多构建硬件和软件的供应商都已实现该 API 以满足规范。多家供应商已成功打造出支持基于 MPI 的 HPC 应用的产品，同时支持 PGAS、SHMEM 和其他编程模型。同时，供应商也创建了支持常用 AI 框架（例如 PyTorch、TensorFlow 或 ONNX）的库。所有这些供应商的产品都已被证明能够轻松高效地映射到 libfabric 上。UEC 与 libfabric 社区合作，根据需要扩展 libfabric API，以支持新的 UE 功能。

1.6.2 传输层

UE 传输层规范在第 3 节中提供。UE 传输协议旨在满足 HPC 和 AI 工作负载的网络需求。定义了不同的配置文件，以便进行产品优化，以满足工作负载的独特需求。预计 AI 和 HPC 工作负载的网络需求将日益重叠。UE 传输协议支持广泛的实现。UE 传输协议的组件包括消息语义、数据包传输可靠性模式、拥塞管理和安全性。语义 (SES)：SES 子层旨在通过 libfabric 映射集成到广泛部署的 AI 框架和 HPC 库中。使用 libfabric 的应用程序通过该结构交换消息，并使用流行的零拷贝技术将这些消息直接放入彼此的缓冲存储器中。SES 子层指定了一个协议，该协议定义了如何识别应用程序消息、如何寻址相关缓冲区以及如何对消息执行首选操作。SES 子层是 UE 传输层和 libfabric 提供程序之间的主要接口。数据包传送子层 (PDS)：应用程序需求决定了选择合适的 UET 数据包传送服务。不同的应用程序针对不同的可靠性和数据包顺序约束对消息传送进行了优化。通过 UET 分层模型和相关库，应用程序可以选择最适合其需求的传输协议功能。PDS 子层定义了一个具有多种操作模式的协议，可提供可靠、不可靠、有序和无序数据包传送服务的所有组合。拥塞管理子层 (CMS)：端到端拥塞管理对于实现高网络效率、减少数据包丢失和最小化延迟至关重要，同时还要保持竞争流之间的公平性。网络中使用流量类别来区分具有不同特征和需求的流量。为了保持公平性并确保低延迟控制环路，UE 拥塞管理设计用于同一流量类别中的所有流量。流量类别的配置由网络运营商负责。通过允许 UET 拥塞管理在整个交换矩阵中启用多路径数据包喷洒并避免拥塞信号到达时出现热点，可以实现高网络效率和低延迟。在 UET 下，具有无序流的 PDC 可以同时使用通往目的地的所有路径，从而更均衡地使用所有网络路径。通过实时拥塞管理引导，在端点和交换机之间协调选择路径，可以避免链路负载不平衡。这种细粒度的负载平衡可以提高网络利用率并减少尾部延迟。传输安全子层 (TSS)：AI 训练和推理通常发生在需要作业隔离的托管网络中。此外，AI 模型日益敏感，并成为宝贵的商业资产。鉴于此，UE 传输层在设计时就融入了网络安全，可以加密和验证 AI 训练或推理作业中计算端点之间发送的所有网络流量。随着作业规模的增长，有必要在不增加主机和网络接口会话状态的情况下支持加密。为此，UET 引入了新的密钥管理机制，允许在参与作业的大量计算节点之间高效共享密钥。它旨在高效地实现人工智能训练和推理所需的高速和大规模计算。托管在大型以太网上的高性能计算 (HPC) 作业具有类似的特性，并且需要类似的安全机制。请注意，TSS 是一项可选功能。

1.6.3 网络层

可选的 UE 网络层功能规范在第 4 节中提供。UE 不需要对网络层进行任何更改，但 UET 拥塞管理需要支持 IETF RFC 3168 中规定的显式拥塞通知 (ECN)，但附加限制是在出队传输时（而不是入队时）标记拥塞数据包。数据包修剪：在交换矩阵中，拥塞是不可避免的。随着交换矩阵速度的提高以及有限的交换芯片缓冲压力的增加，拥塞信号变得更加普遍，这些信号中的信息在确定纠正措施方面变得更加重要。 UE 定义了一个数据包修剪功能，允许交换机截断竞争数据包，修改截断数据包的 DSCP 字段，并将截断的数据包作为拥塞信号转发到目的地。数据包修剪提供的拥塞信息比单独的 ECN 位要多得多。对于交换机而言，数据包修剪是可选的；而对于前端端点 (FEP) 而言，数据包修剪是接收已修剪数据包的强制要求。

1.6.4 链路层

可选的 UE 链路层规范在第 5 节中提供。UE 规范在链路层添加了几个可选特性，同时也承认推出支持这些特性的产品可能需要更长时间。某些工作负载可能会从这些特性中受益，而大规模实验可能是证明这一点的最佳方式。此外，其他标准制定组织 (SDO)（例如 IEEE 802）可能有兴趣更改其中一些特性。图 1-17 显示了 UE 链路层规范相对于 IEEE 802 链路层架构的重点领域。 UE 针对链路层的可选建议与阴影区域有关。所有功能均为 UE 合规性的可选功能。

链路层重试 (LLR)：随着速度和规模的增加，以及加速器网络中常见的极端带宽密度，仅依靠端到端重试来解决数据包丢失问题的传统方法对于延迟敏感型工作负载而言越来越繁重。链路层的本地错误处理已被证明在横向扩展 HPC 网络（例如百亿亿次系统中使用的网络）中非常有用。UE 规范为以太网提供了此功能。

基于信用的流量控制 (CBFC)：传统上，以太网网络避免使用基于信用的链路，这在结构技术中很常见。但是，一些最近推出的产品对它进行了支持，并对某些工作负载进行了可选的改进。CBFC 是 UE 链路层的一项可选功能。

UE 链路协商：UE 规范支持“现有以太网交换机”，但引入了多个可选的新功能，这些功能受益于发现和功能协商功能。虽然 UE 的目标是在专用后端网络上运行以进行加速器间通信，但这一目标并不会减轻支持网络上所有实体（端点和交换机）之间的发现和功能协商的需求。UE 推广了“配置文件”的概念，该概念描述了必需和可选功能。为了与配置文件支持的功能进行互操作，有必要检测、发现并在所有网络实体之间达成共识。UE 假设像 LLDP 这样的标准协商机制在业界已经普及，并且可以扩展用于上述目的。

1.6.5 物理层

UE 物理层规范在第 6 节中提供。UE 的物理层规范使用 IEEE 802.3 标准定义的每通道 100G 信令。图 1-18 显示了 UE 物理层规范相对于 IEEE 802.3 PHY 架构的重点领域。UEC 对物理层的可选建议与阴影区域相关。

IEEE 802.3 100G 每通道信令：UE 物理层部分列出了 UE 范围内的 IEEE 802.3 规范。

信道质量假设：加速器节点比标准端点或 TOR 交换机更复杂。在发布时，假设 IEEE 标准已足够，同时鼓励 UE 产品构建更稳健的信道。

用于预测链路质量的 FEC 统计数据：UE 网络通常包含多条受前向纠错 (FEC) 保护的高性能链路，这些链路上由于物理层错误导致的数据丢失极其罕见。然而，在大规模网络中，可能存在一些异常链路，其错误频率高于网络其他链路。在大规模并行应用中，此类链路可能需要频繁重传，从而成为整个网络的性能瓶颈。UE PHY 规范包含一种根据 FEC 解码器统计数据估算每条链路上 PHY 错误平均间隔时间 (MTBPE) 的方法。这种估算方法可以识别性能不佳的链路，从而提供提升网络性能的机会（例如，通过从网络中删除最薄弱的链路或维护其端点）。