Scale-up 互连结构（Scale-up Fabrics）
随着 AI 工作负载扩展到数千个加速器，机架级系统的互连结构（也称 scale-up 互连结构）正受到高度关注。2025 年，多项重大进展正在重塑 scale-up 互连的格局。
UALink 联盟发布了其 1.0 规范------一种专为加速器之间高效通信设计的内存语义互连。博通（Broadcom）发布了自己的 scale-up 互连规范，并计划通过 OCP（开放计算项目）推动其标准化。超以太网联盟（Ultra Ethernet Consortium，UEC）也定义了若干对标准以太网的增强，可用于 scale-up 互连。
本文讨论 scale-up 互连的需求，对 UALink 的四层协议栈和交换结构架构做技术概览，并介绍博通的 Scale-Up Ethernet（SUE）方案，随后比较它们的性能、延迟，以及面向 AI 驱动的机架级系统的就绪程度。
Scale-up 互连结构
Scale-up 互连结构是一种高速、低延迟的互连系统，专门用于连接单台服务器或机架级系统内的加速器（如 GPU 或 AI 处理器）。它实现了高效的内存语义通信，以及跨多个加速器单元的协同计算。
为了在加速器之间以最小延迟实现最大带宽，scale-up 互连应具备以下特性。
高带宽 / 单级交换结构
互连必须在 GPU 之间提供极高的带宽------显著高于典型的 scale-out 互连------以高效应对加速器之间繁重的通信需求。这些加速器频繁交换大张量并行或流水线并行的数据，需要将数据均匀地分布到多条链路上，以避免拥塞并降低通信延迟。
为了在不增加延迟的前提下实现高带宽，互连通常组织为单级网络：数据包从源到目的地恰好只经过一个交换机，没有中间跳。
Scale-up 互连通常包含多个并行的交换平面（fabric plane），每个平面由一台专用的 scale-up 交换机构成。在 N 平面设计中，共有 N 台独立交换机，每个加速器都有到全部 N 台交换机的专用链路。因此，当某个加速器需要向另一个加速器发送大事务时，它可以同时将流量分布到所有交换平面上。这种并行方式显著提升网络吞吐量，并确保加速器以低延迟、无瓶颈地通信。
使用 M×M 的 scale-up 交换机时，一个 pod（加速器组）内最多可互连 M 个加速器，每个加速器都与所有交换平面建立专用连接。
（图 1 ------ Scale-up 互连结构。）
（图 2 ------ Scale-up 与 scale-out 场景示例。）
共享内存语义
在 scale-up 互连中，各 XPU 应当能像访问本地内存一样，对远端加速器的内存执行 load 和 store 操作。换句话说，所有加速器的内存聚合起来，应对每个加速器呈现为单一的内存池。
现代处理器、GPU 和加速器通常以 256 字节缓存行大小的数据单元进行操作。因此，scale-up 互连应支持通过这些 load/store 指令向远端加速器读写 256 字节的条目。
虽然缓存一致性对 HPC 应用是必需的，但对 AI 工作负载而言并非硬性要求------AI 负载通常不涉及多个加速器同时修改同一块内存内容。
无损传输
互连必须是无损的，并提供可靠链路。因为 load/store 内存语义与 scale-out 场景常用的远程直接内存访问（RDMA）事务不同，无法容忍丢包。端点可以选择在传输层实现 go-back-N 重传（重传丢包之后的所有数据包）或选择性重传（只重传丢失的数据包）。
重传虽然保证了数据完整性，但会引入内存开销和延迟。举例来说，若互连往返时间（RTT）约为 2 微秒、总带宽为 9.6 Tbps，那么每个加速器需要约 2.4 MB 的重传缓冲。这个缓冲不算巨大，但会增加芯片面积和功耗。重传还会增加延迟，可能破坏张量并行或流水线并行数据交换中紧密的同步关系，从而损害性能。
另一方面，不做重传也有代价：任何未纠正的链路错误或内存 ECC 错误都会触发内存访问故障，导致 GPU 或加速器上下文 halted，甚至可能中止内核执行。显然，未纠正的错误在 scale-up 互连中是不可接受的。
因此，尽管传输层重传是必要的兜底手段，互连设计的首要目标必须是健壮的无损通信，从根本上避免重传开销。
细粒度的逐跳流控
为防止缓冲区溢出和队头阻塞（head-of-line blocking），互连应支持按端口、按流量类别（或虚拟通道）的逐跳流控。按流量类别的流控能让使用不同流量类别的请求和响应互不阻塞地通过交换结构。
在加速器对之间为读写请求和响应建立端到端信用（credit），也有助于防止持续的 incast 场景（多个加速器同时向同一个目的加速器发送流量）。
加速器间通信零软件开销
端点向远端内存发起内存读/写操作时，不应有额外的软件开销。换句话说，需要软件进行队列对（QP）分配、内存注册、虚拟地址空间分配等操作的 GPU-Direct RDMA，并不适合 scale-up 传输------因为延迟会升至数十微秒量级。
GPU/加速器通常通过硬件将 load/store 操作打包、封装上传输层和数据链路层头部后送上 scale-up 互连，全程无软件介入。
服务器内部的 AI 流量（无论训练还是推理）大多涉及从几千字节到数百兆字节的大块传输，远超 256 字节的 load/store 事务。有人可能会问：相比使用预先建立好 QP 和虚拟地址空间、把软件开销降到最低的轻量级 RDMA，load/store 语义是否真有显著优势？答案是：把大块传输拆成较小的事务可以实现更高的链路利用率和更低的延迟，使加速器在收到较小分段后立即开始处理数据。正因如此，许多超大规模云厂商仍然偏好在加速器间通信中使用 load/store 语义。
高带宽效率
带宽效率指数据帧中承载实际有效载荷数据的比特占比。带宽效率应尽可能接近 100%。互连应以最小的协议开销在端点之间传递内存读/写请求、响应和信用信息。
超低延迟
端到端延迟应尽可能低。这对那些无法把加速器间通信时间与有用计算工作重叠或掩盖的应用尤为重要。
对于推理工作负载，加速器之间累积的（未被隐藏的）延迟------尤其是混合专家（MoE）模型和思维链推理------可能会达到用户可察觉的程度。这些模型每生成一个 token 都需要多次服务器内部 GPU 通信，而最终响应可能涉及数千个 token 的生成。
低抖动
可预测、抖动极小的延迟对 AI 工作负载的高效执行至关重要，尤其是大规模推理和紧耦合同步的训练任务。编译器和运行时通常尝试通过将 GPU 间通信操作与独立计算重叠来优化性能。要有效调度这种重叠，系统高度依赖稳定且可预测的通信延迟。
内存序保证
互连必须保持内存序保证。具体而言，对于发往远端加速器同一个 256 字节对齐地址区域的任何内存读或写，互连必须按源加速器发出它们的顺序送达。对这类事务重排会破坏内存一致性，导致程序行为出错。
最佳的功耗-性能-面积（PPA）
这一点对任何交换机都成立，对机架级系统则更为关键------需要降低机箱功耗和成本（包括硅片成本以及交换板卡散热管理的成本）。
面向 scale-up 的 UALink
超级加速器链路（Ultra Accelerator Link，UALink）是一种专为 scale-up 设计的高速内存语义互连。因此，该协议试图解决上一节列出的所有需求。
该互连可扩展至 1,024 个加速器，使各加速器能像访问本地内存一样，直接 load/store 访问远端加速器的内存。
UALink 交换机（ULS） 是一种专用的高性能交换机，为使用 UALink 协议通信的加速器端点之间提供无阻塞连接。一个 Pod 由通过 UALink 交换机连接的所有加速器组成。UALink 支持在一个 pod 内划分虚拟 pod 的概念：属于不同虚拟 pod 的加速器即使同处一个 pod 也无法互相通信。
UALink 组织为四层协议栈：协议层------称为 UALink 协议层接口（UPLI）、事务层（TL）、数据链路层（DL）和物理层（PL）。
（图 3 ------ UALink 协议栈。）
UALink 协议层接口（UPLI）
UPLI 是逻辑协议层，负责生成和解释加速器之间交换的请求和响应。它支持内存语义操作，如内存读/写或原子操作。发起方（Originator）的每个请求都与完成方（Completer）的一个响应配对，构成一个完整事务。因此，这些协议层事务是双向（two-sided）的。
UPLI 为读和写的请求及响应分别设置了独立的虚拟通道。这些通道独立运作，彼此之间没有顺序要求。
该协议允许以 64 字节节拍（beat）进行最大 256 字节的读写。将每个事务对齐到最大 256 字节（缓存行大小）可确保数据与内存子系统的粒度自然对齐，避免部分缓存行访问，并简化硬件设计。
协议层可以在任意两个加速器之间按通道提供端到端信用，以管理缓冲区使用并防止溢出。
每个加速器拥有的 UPLI 接口数量与其支持的交换平面数量相同。
事务层（TL）
事务层将 UPLI 消息转换为 64 字节单元序列（称为 TL flit）进行传输。每个 flit 进一步细分为两个半 flit（half-flit），分别承载事务的控制信息或载荷数据。
- 控制半 flit 可包含源/目的加速器 ID、虚拟通道号、内存地址等信息，数据半 flit 则承载写数据或读数据。
- TL flit 可以背靠背紧密打包，实现极高的链路利用率。
在接收侧，事务层从输入的 TL flit 序列中提取读响应，并将其送往相应的 UPLI 通道。
数据链路层（DL）
数据链路层在两个直连（点对点）的 UALink 设备之间（如加速器与交换机端口之间）可靠地传送 TL flit。
它把 64 字节的 TL flit 封装进更大的数据帧------640 字节大小------附带循环冗余校验（CRC）和头部。在物理层，每个 640 字节的 DL flit 被映射到一个 680 字节的 RS FEC 码字。这使得 FEC 和 CRC 能干净地作用于每个数据链路单元。
UALink 支持带链路级重传（LLR）的可靠链路协议：任何损坏或丢失的 DL flit 都可在链路层重传。由于不可纠正的 FEC 错误或 CRC 错误被局限在单个 DL flit 内，因此避免了部分帧重传。
DL 层还支持按端口（可能也按虚拟通道）的基于信用的流控，以避免队头阻塞。
物理层（PL）
UALink 1.0 直接构建在 IEEE 以太网 PHY 技术之上，通过 IEEE P802.3dj 定义的 212.5 Gb/s 串行信令支持每通道 200 Gb/s。其 PHY 本质上就是改动极小的标准以太网 SerDes。
UALink 支持 200G、400G 和 800G 端口速率，分别使用每端口 1、2 或 4 条 200G 通道。利用以太网 PHY 使 UALink 能在物理编码子层（PCS）内复用成熟技术，如 64B/66B 线路编码和 KP4 前向纠错（FEC）。
标准以太网通常采用 4 路交织 FEC 以获得更好的突发错误纠正能力，但这会增加延迟；UALink 可选支持更简单的 1 路或 2 路 FEC 交织，以牺牲部分纠错强度换取更低延迟。
因此，UALink 允许厂商以极小的改动复用现有的 100G/200G 以太网 SerDes IP 和固件，显著降低开发风险和总拥有成本（TCO）。这也让系统能直接使用为以太网开发的现有铜缆、连接器、重定时器（retimer）以及未来的光模块。
（图 4 ------ UALink 协议事务。）
UALink 交换机
UAL 交换机在机架级系统或服务器内连接多个加速器。为与下一代以太网交换结构的端口基数（radix）看齐，第一代芯片可能瞄准 102.4T（512×200G），内部采用 512×512 交换结构。
交换结构可以按虚拟通道在 TL flit 边界处进行交换。这种定长 flit 交换（不同于以太网交换机的变长包交换）简化了交叉开关（crossbar）、调度器和数据通路单元的设计，并降低了交换核心的延迟。
用标准以太网做 scale-up？
UAL 1.0 规范刚刚发布，第一代 UAL 交换机至少还要 1.5 到 2 年才能用于机架级系统。在此期间，标准以太网能否填补 scale-up 网络的空白、抢在 UAL 之前？让我们看看：
- 标准以太网不支持带链路级重试的可靠链路。虽然它在端点支持 FEC，但对于 100G 及以上的通道速率，单靠 FEC 并不够。典型的 FEC 后误码率 1e-15 意味着一条 100G 链路每 2.78 小时出现一次错误，这对加速器间工作负载是不可接受的。
- 流控机制基于 PFC（优先级流控）。PFC 在 Clos 拓扑中以引发队头阻塞著称，但在单交换机系统中表现尚可。不过，与基于信用的流控机制相比，它需要两倍的缓冲。
- 目前可得的商用芯片（merchant silicon）浅缓冲交换机（51.2 Tbps）可能并未针对 500 ns 以下的延迟做高度优化。
- 这些交换机带有许多 scale-up 并不需要的功能，因此在面积/功耗上并未优化。
- 目前没有任何开放标准定义协议层，也没有定义协议层事务如何封装进标准以太网帧。
虽然仍可用标准以太网交换机加自定义协议构建 scale-up 互连，但它们可能无法达到最佳性能或利用率。
下一代以太网交换机能胜任 scale-up 吗？
可靠、无损的链路
UEC 草案为标准以太网链路定义了链路层重试（LLR）和按流量类别的基于信用的流控（CBFC）。其实现方式是：向 64b/66b 数据流中注入特殊的控制有序集（Ordered Set），在传输数据包的同时携带确认（ACK）、否定确认（NACK）和信用更新。如果得以实现，这些特性将使以太网交换机具备与 UALink 类似的可靠无损互连能力。
博通的 Scale-Up Ethernet（SUE）框架
博通在 2025 年 4 月的 OCP 全球峰会上发布了 SUE 框架，以回应对标准以太网用于 scale-up 的顾虑。该规范引用了 LLR 和 CBFC 特性。虽然草案未明确说明这些特性是否来自 UEC 规范，但以太网 scale-up 交换机的实现可以遵循 UEC 规范来实现这些特性，以实现多厂商互操作。
- 规范中的协议层看起来与 UPLI 非常相似，区别在于事务是单向（one-sided）的------换句话说，写操作没有显式 ACK。它同样有虚拟通道的概念，可将不同事务类型映射到不同虚拟通道，以减少队头阻塞。
- 与 UALink 1.0 不同，SUE 框架给予加速器架构师灵活性，可以将自己的专有协议层事务打包进以太网帧。这种灵活性至关重要：加速器可以复用其现有的协议层事务逻辑，只需用以太网帧封装后即可在互连上传输。
事务可以按"命令 + 可选数据"的形式打包。命令可以是读/写请求或读响应。命令通常包含目的内存地址、通道号、命令/数据长度等信息。数据是与命令关联的数据（写数据/读响应数据）。有些命令（如读请求）没有关联数据。
- 每个加速器可以有多个 SUE 接口，与其连接的交换平面数量相匹配。
- 发往每个目的地、每个流量类别的事务在加速器的互连端点（FEP）逻辑中各自排队。
- 如果一个队列中有多个事务，它们可以合并成一个协议数据单元（PDU），最大可达 4 KB。标准以太网帧由此获得优势------以太网头部开销可以摊薄到多个事务上。
- 规范要求为该 PDU 添加可靠头部（用于重传）和 CRC，并使用 AI 头部（一种新定义的头部，合并压缩了标准 L2/L3 头部以降低头部开销）或标准以太网/IP/UDP 头部发送。
- 硬件可以限制可合并事务的数量，从而减少包长的变化。
- 打包事务的逻辑相对简单：只是把发往同一目的地/通道的完整事务串接起来，组成更大的 PDU。
- 在接收侧，SUE 逻辑解封装以太网头部，提取出命令和数据序列，并将其送往加速器协议接口。
（图 5 ------ 使用 SUE 的 load/store 事务。）
端到端延迟/抖动
历史上，以太网被认为是有损的，存在抖动和可变延迟。这对标准以太网交换机来说确实如此，但商用芯片厂商的新产品宣称可以实现低且可预测的交换延迟。
专为数据中心内部应用设计的以太网交换机，可以通过去除不必要的报文处理功能、缩短流水线深度、精简数据结构/缓冲区/队列来大幅降低延迟，还可以启用直通转发（cut-through）等优化。借助这些优化，一些商用芯片厂商宣称在先进工艺节点上可实现约 250--300 纳秒的延迟。不过实际延迟在很大程度上取决于交换机端口基数，以及交换机是否采用 chiplet 实现------任何 die-to-die 接口都可能显著增加延迟（约 50 ns）。
然而，如果为降低延迟而把大部分标准以太网功能剥掉，得到的本质上就是另一台只能用于 scale-up 的专用交换机。厂商也就无法再宣传传统以太网"同一台交换机同时用于前端和后端数据中心网络的 scale-up/scale-out"这一优势。
这些以太网或 UALink 交换机实际达到的空载延迟，在很大程度上取决于具体实现选择，因厂商而异。鉴于定长 flit 传输的简单性，UALink 交换机会略有延迟优势。
端到端延迟由若干与所选互连无关的固定部分组成，例如以太网 PHY/SerDes、加速器与交换机之间的线缆等。SUE 规范给出：使用 5 米线缆时，端到端延迟单向 500 ns，读事务 RTT 为 1 微秒。这个数字相当激进，因为 MAC、PHY 和链路层本身就可能占去交换机延迟中的 100--150 ns，只剩约 100 ns 给报文处理和交换。
（图 6 ------ 往返延迟。）
延迟的粗略估算见表 1。
| 组件 | UALink 互连延迟 (ns) | 以太网互连延迟（scale-up 优化交换机）(ns) | 以太网互连延迟（scale-up/scale-out 混合交换机）(ns) | 备注 |
|---|---|---|---|---|
| XPU：协议层事务到数据包/flit | 25 | 25 | 25 | 应相近。高度依赖微架构和工艺节点 |
| XPU→交换机：DL(MAC)/PHY/SerDes（收发对） | 150 | 150 | 150 | UALink 与以太网使用相同的 SerDes/PHY |
| 5m Twinax 铜缆 | 23 | 23 | 23 | |
| 交换机 | 75 | 100 | 200 | 高度依赖端口基数、缓冲、微架构和工艺节点。直通处理（以太网）。如果同一交换机同时用于 scale-up 和 scale-out，且为某些 scale-out 功能设置了更深的流水线，以太网很难做到 200 ns 以下。面向 scale-up（仅支持 1K 端点）的以太网交换机可以达到与 UALink 相近的延迟（约 100 ns） |
| 交换机→XPU：DL/PHY/SerDes（收发对） | 150 | 150 | 150 | 直通 MAC；UALink 与以太网使用相同的 SerDes/以太网 PHY |
| 5m Twinax 铜缆 | 23 | 23 | 23 | |
| XPU：数据包/flit 到协议层事务 | 25 | 25 | 25 | 应相近。高度依赖微架构 |
| 端到端（单向） | ~471 | ~496 | ~596 | |
| RTT（读操作） | ~942 | ~992 | ~1,192 | 专用 scale-up 以太网：比 UALink 多约 5% 的延迟 |
（表 1 ------ 各组件延迟的近似值。）
在其他条件相同的情况下，专为 scale-up 打造的以太网交换机可能多出约 5% 的 RTT 延迟。至于抖动，在以太网交换机中减少发送端包长的变化有助于将抖动降到最低。
包序保证
以太网交换机支持按流保序，流可以由源/目的地址和流量类别字段确定。利用这一能力，可以在任意加速器对之间的请求和响应通道（当它们映射到不同流量类别时）上保持严格的顺序。
链路效率（或带宽效率）
带宽效率衡量通信链路上传输的总比特/字节中承载有用数据（此处为内存读或写数据）的比例。
效率与延迟目标之间存在微妙的平衡。如果目标是保持绝对最小延迟、不愿等待多个事务凑齐后再打包以降低协议开销，那么效率可能会降低。
在 SUE 框架中，使用新的 AI 头部时，开销如下：
- 20 字节（12 字节帧间隙、7 字节前导码、1 字节定界符）；
- 6 字节 AI 头部；
- 8 字节可靠头部；
- 4 字节 R-CRC 和 4 字节帧校验序列（FCS）。
如果两端点都支持，短距离高质量链路上可以采用 8 字节的缩减帧间隙（IPG）。
表 2 展示了 SUE 框架下不同帧长的字节效率。
| 事务数 | 帧长 (B) | 固定开销 (B) | 命令的可变开销 (B) | 总字节数 | 带宽效率 (%) |
|---|---|---|---|---|---|
| 1 | 256 | 42 | 18 | 316 | 81.0 |
| 2 | 512 | 42 | 36 | 590 | 86.8 |
| 3 | 768 | 42 | 54 | 864 | 88.9 |
| 4 | 1,024 | 42 | 72 | 1,138 | 90.0 |
| 5 | 1,280 | 42 | 90 | 1,412 | 90.7 |
（表 2 ------ 承载 256 字节事务时的 SUE 效率。）
如果一个以太网帧只携带单个 256 字节的读/写数据，带宽效率约为 81%。但在典型的 AI 训练/推理工作负载中，GPU 之间在任意交换平面上交换的数据约为 2 KB 或更多，会被切分成多个 256 字节事务，且发往同一目的加速器的 256 字节事务通常不止一个。加速器的互连接口逻辑可以把多个发往同一输出端口的事务聚合进一个以太网帧，从而形成更大的帧。大帧内的打包可以非常高效（5 个 256 字节事务时为 91%）。
SUE 占优的场景是：事务小于 256 字节且不是 64 字节边界的整数倍。由于 SUE 没有 flit 的概念，这些非 256 字节事务可以背靠背紧密打包，没有 flit 碎片化开销。打包逻辑取决于具体实现。
在 UALink 中，每个事务都有一个 32 字节的控制半 flit，承载请求/写确认和流控信息。如果有多个发往同一目的地的写请求，可以在每个控制半 flit 中打包多个请求。
UALink 事务是双向的：每个标准写请求（16 字节）都有一个响应（8 字节），这也会造成效率损失。UALink 协议允许压缩请求/响应（当两端缓存了地址时，请求无需携带内存地址的全部比特）。
表 3 展示了效率（假设请求和响应均未压缩）。
| 事务数 | 载荷大小 (B) | ~DL 效率 | 控制半 flit 数 | 总字节数 | 带宽效率 (%) |
|---|---|---|---|---|---|
| 1 | 256 | 0.98 | 1 | 288 | 87.1 |
| 2 | 512 | 0.98 | 2 | 576 | 87.1 |
| 3 | 768 | 0.98 | 3 | 864 | 87.1 |
| 4 | 1,024 | 0.98 | 4 | 1,152 | 87.1 |
| 5 | 1,280 | 0.98 | 5 | 1,440 | 87.1 |
（表 3 ------ 无压缩时的 UALink 效率。一个 32 字节控制字包含一个 16 字节写请求和一个 8 字节写响应。虽然响应走相反方向，但其开销也应计入。为简化起见已在此计入。）
采用压缩头部后效率有所提升，如表 4 所示。
| 事务数 | 载荷大小 (B) | ~DL 效率 | 控制半 flit 数 | 总字节数 | 带宽效率 (%) |
|---|---|---|---|---|---|
| 1 | 256 | 0.98 | 1 | 288 | 87.1 |
| 2 | 512 | 0.98 | 1 | 544 | 92.2 |
| 3 | 768 | 0.98 | 2 | 832 | 90.5 |
| 4 | 1,024 | 0.98 | 2 | 1,088 | 92.2 |
| 5 | 1,280 | 0.98 | 2 | 1,344 | 93.3 |
（表 4 ------ 采用压缩写请求（8 字节）和写响应（4 字节）的 UALink。单个控制 flit 内可打包更多请求。）
这种打包逻辑可能很复杂，效率高度依赖于流量模式和具体实现。基于缓存的地址压缩可用于任何协议------如果端点协议支持压缩，SUE 同样可以受益。
当事务小于 256 字节时，UALink 可能因字节使能（byte-enable）和 64 字节碎片化而产生更多开销。表 5 展示了 128 字节事务的效率。非 64 字节整数倍的事务（如 129 字节等）效率会更低，但这类事务在这些工作负载中并不常见。
| 事务数 | 载荷大小 (B) | 控制半 flit 数 | 数据半 flit 数 | UALink 总字节数 | UALink 效率 (%) | 以太网总字节数 | 以太网效率 (%) |
|---|---|---|---|---|---|---|---|
| 1 | 128 | 1 | 5 | 192 | 65.3 | 188 | 68.1 |
| 2 | 256 | 2 | 9 | 352 | 71.3 | 334 | 76.6 |
| 3 | 384 | 3 | 13 | 512 | 73.5 | 480 | 80.0 |
| 4 | 512 | 4 | 17 | 672 | 74.7 | 626 | 81.8 |
| 5 | 640 | 5 | 21 | 832 | 75.4 | 772 | 82.9 |
（表 5 ------ UALink 与 SUE 中的 128 字节事务。）
UALink 协议允许加速器与交换机之间传输的 DL flit（640 字节紧密打包的 flit）承载发往不同加速器端点的事务。这种灵活性使 DL flit 能被完全填满，提高了加速器与交换机端口之间的链路利用率。而在以太网中，只有当多个事务都发往同一目的加速器时，才能被打包进同一个以太网帧。
因此，每种互连的带宽效率高度依赖于：
- 地址缓存。 UALink 假定这是默认模式，大多数情况下可使用压缩头部。SUE 规范虽未明确提及，但端点同样可以实现缓存以减少命令开销。
- 事务大小。
- 流量模式 ------ 队列中是否有足够多的事务可供高效打包（对 UALink 而言，是打包进 32 字节控制半 flit；对以太网而言，是把多个事务打包进一个帧）。
功耗/面积
无论基于以太网还是基于 UALink 的交换机，采用 200G PAM4 SerDes 的 IO 逻辑都可能占交换机功耗的三分之一到一半。交换逻辑 die 的功耗对比则完全取决于实现和工艺节点。
统一 scale-up/scale-out？
虽然 SUE 框架规范明确没有包含这一点，但以太网交换机使构建 scale-out/scale-up 统一网络成为可能。例如，微软在基于其 MAIA 100 加速器构建网络时就采用了这种策略，并提到使用一种自定义的"类 RoCE"协议在加速器之间做内存读/写。如果加速器选择构建统一网络，低延迟以太网交换机可以提供这种灵活性。不过，业界广泛共识是：针对 scale-up 和 scale-out 通信各自的独特需求分别优化互连，目前仍是为多样化 AI 工作负载最大化性能的最佳路径------哪怕这意味着要在数据中心里管理异构的互连。
就绪程度
时间线如何呢？
链路级重试和信用流控特性在 UEC 中已有良好定义，多家 IP 厂商已开始支持。据博通一位高级副总裁的 LinkedIn 帖子，博通可能已经实现了采用 SUE 框架的交换机，芯片预计今年晚些时候可用。如果进展顺利，博通的以太网方案将比 UAL 交换机领先一年。
加速器厂商/超大规模云厂商会继续沿用现有机制、在下一代加速器中采用 UALink，还是押注采用 SUE 的低延迟以太网交换机？我们拭目以待......
一款支持无损互连、具备可靠链路、链路层基于信用的流控和自定义头部的超低延迟以太网交换机，是 NVLink 或 UALink 在 scale-up 领域的有力替代方案。如果交换机能在不牺牲延迟的前提下支持 scale-out 所需的典型规模和功能，以太网还能让超大规模云厂商和数据中心在 scale-up 和 scale-out 网络中使用同一种交换芯片。
| 标准 | UALink 互连 | 以太网互连 |
|---|---|---|
| 规模 | 1,024 个加速器 | 1,024 个加速器 |
| PHY | 以太网 PHY（为降延迟略有修改） | 以太网 PHY（可做类似降延迟增强） |
| 数据链路帧长 | 固定 640B | 可变------最大 4,096B |
| 单向（one-sided）？ | 是 | 是 |
| 按类别/通道的信用流控 | 是 | 是 |
| 事务大小 | 256B | 256B |
| 单向事务？ | 否，写也有响应 | 是 |
| 传输级重试 | 无 | 变长数据包 |
| 请求/响应隔离 | 虚拟通道 | 虚拟通道（在交换机内映射到不同流量类别） |
| 排序 | 按加速器对/按端口/按通道。协议还允许仅在 256 字节地址边界内保序，交换机可实现这一点 | 难以实现基于地址边界的宽松排序。以太网交换机可通过按流排序支持按加速器对/按端口/按通道的保序 |
| 交换粒度 | 64B TL flit | 变长数据包 |
| 带宽效率 | 高度依赖流量模式。5×256B 写时最高约 95%。事务小于 256B 或非 64 字节整数倍时可能有效率损失 | 高度依赖流量模式。5×256B 写时最高约 91%。取决于实现，变长事务的碎片化开销更小 |
| 端到端延迟 | 略低于 1 µs | scale-up 优化交换机约 1 µs；scale-up/scale-out 混合交换机约 1.2 µs |
| 抖动 | 更小 | 可能更大，尤其是包长变化时。可通过收紧包长范围来控制 |
| 允许专有协议 | 否 | 是。虽然 SUE 框架规定了一种用以太网发送事务的方法，但端点可自行定义以太网头部内的载荷格式。更大的灵活性允许复用现有协议 |
（表 6 ------ 对比总结。）
总结
行业正处在一个十字路口。
未来的 UALink 交换机可以为以内存为中心的操供高效、确定性的性能和最小的开销。以太网凭借其低延迟和链路可靠性增强也紧随其后。UALink 芯片预计 2026 年下半年问世。以太网似乎略有上市时间优势------低延迟 SUE 交换机预计约 2025 年下半年推出。
归根结底，行业采用取决于工作负载需求：在专用化（UALink）与生态灵活性和兼容性（以太网）之间权衡；取决于可集成进加速器的控制器 IP 的可用性；也取决于以太网和 UAL 交换机的量产情况、成本和功耗。
UAL 和超以太网各有优劣，长期来看，两种方案可能会继续共存。
你怎么看？
Sharada Yeluri 是瞻博网络（Juniper Networks）工程高级总监，负责交付用于 Juniper PTX 系列路由器的 Express 系列芯片。她在 CPU 和网络领域持有 12 项以上专利。
本文改编自作者在 LinkedIn 上的原文。
本博客作者观点仅代表其本人，不一定反映 APNIC 的观点。本博客适用行为准则。
原文：Scale-up fabrics
发布日期：2025 年 6 月 3 日