Scale-up 互连结构Scale-up Fabrics随着 AI 工作负载扩展到数千个加速器机架级系统的互连结构也称 scale-up 互连结构正受到高度关注。2025 年多项重大进展正在重塑 scale-up 互连的格局。UALink 联盟发布了其 1.0 规范——一种专为加速器之间高效通信设计的内存语义互连。博通Broadcom发布了自己的 scale-up 互连规范并计划通过 OCP开放计算项目推动其标准化。超以太网联盟Ultra Ethernet ConsortiumUEC也定义了若干对标准以太网的增强可用于 scale-up 互连。本文讨论 scale-up 互连的需求对 UALink 的四层协议栈和交换结构架构做技术概览并介绍博通的 Scale-Up EthernetSUE方案随后比较它们的性能、延迟以及面向 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 和虚拟地址空间、把软件开销降到最低的轻量级 RDMAload/store 语义是否真有显著优势答案是把大块传输拆成较小的事务可以实现更高的链路利用率和更低的延迟使加速器在收到较小分段后立即开始处理数据。正因如此许多超大规模云厂商仍然偏好在加速器间通信中使用 load/store 语义。高带宽效率带宽效率指数据帧中承载实际有效载荷数据的比特占比。带宽效率应尽可能接近 100%。互连应以最小的协议开销在端点之间传递内存读/写请求、响应和信用信息。超低延迟端到端延迟应尽可能低。这对那些无法把加速器间通信时间与有用计算工作重叠或掩盖的应用尤为重要。对于推理工作负载加速器之间累积的未被隐藏的延迟——尤其是混合专家MoE模型和思维链推理——可能会达到用户可察觉的程度。这些模型每生成一个 token 都需要多次服务器内部 GPU 通信而最终响应可能涉及数千个 token 的生成。低抖动可预测、抖动极小的延迟对 AI 工作负载的高效执行至关重要尤其是大规模推理和紧耦合同步的训练任务。编译器和运行时通常尝试通过将 GPU 间通信操作与独立计算重叠来优化性能。要有效调度这种重叠系统高度依赖稳定且可预测的通信延迟。内存序保证互连必须保持内存序保证。具体而言对于发往远端加速器同一个 256 字节对齐地址区域的任何内存读或写互连必须按源加速器发出它们的顺序送达。对这类事务重排会破坏内存一致性导致程序行为出错。最佳的功耗-性能-面积PPA这一点对任何交换机都成立对机架级系统则更为关键——需要降低机箱功耗和成本包括硅片成本以及交换板卡散热管理的成本。面向 scale-up 的 UALink超级加速器链路Ultra Accelerator LinkUALink是一种专为 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 协议层接口UPLIUPLI 是逻辑协议层负责生成和解释加速器之间交换的请求和响应。它支持内存语义操作如内存读/写或原子操作。发起方Originator的每个请求都与完成方Completer的一个响应配对构成一个完整事务。因此这些协议层事务是双向two-sided的。UPLI 为读和写的请求及响应分别设置了独立的虚拟通道。这些通道独立运作彼此之间没有顺序要求。该协议允许以 64 字节节拍beat进行最大 256 字节的读写。将每个事务对齐到最大 256 字节缓存行大小可确保数据与内存子系统的粒度自然对齐避免部分缓存行访问并简化硬件设计。协议层可以在任意两个加速器之间按通道提供端到端信用以管理缓冲区使用并防止溢出。每个加速器拥有的 UPLI 接口数量与其支持的交换平面数量相同。事务层TL事务层将 UPLI 消息转换为 64 字节单元序列称为 TL flit进行传输。每个 flit 进一步细分为两个半 flithalf-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 层还支持按端口可能也按虚拟通道的基于信用的流控以避免队头阻塞。物理层PLUALink 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.4T512×200G内部采用 512×512 交换结构。交换结构可以按虚拟通道在 TL flit 边界处进行交换。这种定长 flit 交换不同于以太网交换机的变长包交换简化了交叉开关crossbar、调度器和数据通路单元的设计并降低了交换核心的延迟。用标准以太网做 scale-upUAL 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 EthernetSUE框架博通在 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协议层事务到数据包/flit252525应相近。高度依赖微架构和工艺节点XPU→交换机DL(MAC)/PHY/SerDes收发对150150150UALink 与以太网使用相同的 SerDes/PHY5m Twinax 铜缆232323交换机75100200高度依赖端口基数、缓冲、微架构和工艺节点。直通处理以太网。如果同一交换机同时用于 scale-up 和 scale-out且为某些 scale-out 功能设置了更深的流水线以太网很难做到 200 ns 以下。面向 scale-up仅支持 1K 端点的以太网交换机可以达到与 UALink 相近的延迟约 100 ns交换机→XPUDL/PHY/SerDes收发对150150150直通 MACUALink 与以太网使用相同的 SerDes/以太网 PHY5m Twinax 铜缆232323XPU数据包/flit 到协议层事务252525应相近。高度依赖微架构端到端单向~471~496~596RTT读操作~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)总字节数带宽效率 (%)1256421831681.02512423659086.83768425486488.941,02442721,13890.051,28042901,41290.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 数总字节数带宽效率 (%)12560.98128887.125120.98257687.137680.98386487.141,0240.9841,15287.151,2800.9851,44087.1表 3 —— 无压缩时的 UALink 效率。一个 32 字节控制字包含一个 16 字节写请求和一个 8 字节写响应。虽然响应走相反方向但其开销也应计入。为简化起见已在此计入。采用压缩头部后效率有所提升如表 4 所示。事务数载荷大小 (B)~DL 效率控制半 flit 数总字节数带宽效率 (%)12560.98128887.125120.98154492.237680.98283290.541,0240.9821,08892.251,2800.9821,34493.3表 4 —— 采用压缩写请求8 字节和写响应4 字节的 UALink。单个控制 flit 内可打包更多请求。这种打包逻辑可能很复杂效率高度依赖于流量模式和具体实现。基于缓存的地址压缩可用于任何协议——如果端点协议支持压缩SUE 同样可以受益。当事务小于 256 字节时UALink 可能因字节使能byte-enable和 64 字节碎片化而产生更多开销。表 5 展示了 128 字节事务的效率。非 64 字节整数倍的事务如 129 字节等效率会更低但这类事务在这些工作负载中并不常见。事务数载荷大小 (B)控制半 flit 数数据半 flit 数UALink 总字节数UALink 效率 (%)以太网总字节数以太网效率 (%)11281519265.318868.122562935271.333476.6338431351273.548080.0451241767274.762681.8564052183275.477282.9表 5 —— UALink 与 SUE 中的 128 字节事务。UALink 协议允许加速器与交换机之间传输的 DL flit640 字节紧密打包的 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是是按类别/通道的信用流控是是事务大小256B256B单向事务否写也有响应是传输级重试无变长数据包请求/响应隔离虚拟通道虚拟通道在交换机内映射到不同流量类别排序按加速器对/按端口/按通道。协议还允许仅在 256 字节地址边界内保序交换机可实现这一点难以实现基于地址边界的宽松排序。以太网交换机可通过按流排序支持按加速器对/按端口/按通道的保序交换粒度64B TL flit变长数据包带宽效率高度依赖流量模式。5×256B 写时最高约 95%。事务小于 256B 或非 64 字节整数倍时可能有效率损失高度依赖流量模式。5×256B 写时最高约 91%。取决于实现变长事务的碎片化开销更小端到端延迟略低于 1 µsscale-up 优化交换机约 1 µsscale-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 日