本文重点比较两条 Scale-Up 总线技术路线:Flit 原生总线方案和以太网增强方案。

1. 核心结论

Scale-Up 总线的分歧,本质不是“是否使用以太网物理层”,而是远端内存访问的语义、封装效率、端到端延迟和生态可复制性之间的取舍。

  • Flit 原生总线方案以 NVLink 和 UALink 为代表,核心目标是把跨 GPU 访问转换为原生内存语义。通过固定 Flit、专用事务层、信用流控和专用交换域来降低小粒度访问的不确定性,更适合张量并行、长上下文推理、远端 Load/Store/Atomic、KV Cache 共享等强同步场景。
    • NVLink 是当前工程成熟度最高的专有 Scale-Up 总线,但生态封闭,只能在NVIDIA GPU 系统中使用。
    • UALink 是开放 Flit 原生总线路线的主要代表,规范层面已经覆盖 UPLI、TL、DL、PL、管理和 Chiplet 集成,目标是构建跨厂商的 Accelerator Pod。不过其关键风险在于交换芯片、端侧 IP、运行时和通信库的量产成熟度。
  • 以太网增强方案以 SUE、ETH-X 和 EthLink 为代表,核心目标是在复用以太网 SerDes、MAC、交换芯片和运维生态的前提下,补齐 Scale-Up 所需的小包效率、可靠性和流控能力。它通过头压缩、事务聚合、LLR、CBFC/PFC、ECMP/QoS 等机制把以太网改造成可承载内存访问事务的低延迟 Scale-Up 总线。
    • SUE/ETH-X/EthLink 更贴近以太网产业链,适合希望复用以太网交换芯片、线缆、连接器、运维和多厂商供应链的系统。但由于地址翻译、内存模型和完成语义更多留给 XPU/IOD 端侧实现,软件可见的 Goodput 和尾延迟高度依赖端侧事务代理、保序、聚合和屏障优化。

2. 背景

AI 超节点正在从“多卡通过网络搬运数据”走向“多卡像一个更大的加速器”。这一转变要求互联不只提供带宽,还要让本地 GPU 访问远端 GPU HBM 像访问本地 HBM 一样。DeepLink 白皮书把问题拆成编程模型、内存模型、事务层、网络和远端 HBM 的完整语义链路:如果上层使用 Load/Store/Atomic/Fence,底层互联就必须处理保序、完成确认、地址翻译、重传、拥塞和故障隔离。

put / get / atomic / fence

Load / Store / Atomic / RDMA

Flit 或以太网帧

编程模型
NVSHMEM / PGAS / CUDA Kernel

内存模型
Release / Acquire / Fence / Atomic

事务层
NVLink TL / UALink TL / PAXI / SUE Command / EthLink TL

Scale-Up Fabric
专用总线或增强以太网

远端 HBM / 内存池

Direct Access
SM 发起细粒度访存

Direct Copy
Copy/SU Engine 批量搬运

从负载看,Scale-Up 需要同时支撑两类通信:

类型 典型路径 数据粒度 对互联的核心要求
Direct Access GPU SM 直接访问远端 HBM 字节级到 cache line / 小块 低延迟、保序、Atomic、Fence、可见性
Direct Copy Copy Engine / SU Engine 批量搬运 KB 到 MB 高吞吐、聚合效率、DMA 语义、流控和可靠性

Scale-Up 不是普通 RoCE/IB 的替代名词。Scale-Out 网络偏消息语义,强调跨机规模、拥塞控制和吞吐;Scale-Up 总线偏内存语义,强调小包、低时延、强同步和地址空间。

3. 技术路线

背景参考

AI 超节点 Scale-Up 互联

Flit 原生总线方案

以太网增强方案

NVLink
私有闭环,NVSwitch,SHARP

UALink
开放规范,固定 Flit,统一 Accelerator Pod

SUE
OCP/Broadcom,AFH,LLR,CBFC

ETH-X
ODCC/腾讯,PAXI,PRI,L2 LLR,CBFC

EthLink
字节跳动,LS+RDMA,OEFH,RH

OISA
以太增强与 CCA 路线参考

强语义 / 低延迟 / 专用交换

以太生态 / 压缩封装 / 端侧语义补齐

3.1 总线对比

下表把 Flit 原生总线和以太网增强方案放在同一组维度下比较。以太网增强列包括 SUE、ETH-X 和 EthLink;其中 SUE 侧重 XPU command transport,ETH-X 侧重 PAXI/PRI,EthLink 侧重同时承载 Load/Store 小块访问和 RDMA 大块搬运。

特性 NVLink / UALink 以太网增强(SUE / ETH-X / EthLink)
封装方式 固定 Flit,原生承载内存事务语义 AXI/命令/Load-Store/RDMA 语义映射到以太网帧;SUE 使用 XPU command,ETH-X 使用 PAXI,EthLink 使用 Memory Read/Write/Atomic/Message
帧头开销 头部较小且解析固定;UALink 控制 Half-Flit 为 32B,可打包多个事务 需要压缩标准以太网头;SUE 使用 AFH,ETH-X 使用 PRI,EthLink 使用 OEFH,并可叠加 RH 做可靠性补充
事务粒度 UALink 面向 64B 到 256B 等固定事务粒度,NVLink 早期 packet 可包含 0 到 16 个 128b data payload flit 变长以太网帧封装,效率依赖聚合和分片策略;EthLink 显式区分 LS 小包和 RDMA 大块搬运
链路利用率 目标接近 93% 到 95%;UALink TL 数据效率约 95.2%,NVLink 早期 256B transfer 约 94% 标准小包效率偏低;ETH-X 示例从约 56% 提升到 74% 到 77%;SUE/AFH 和 EthLink/OEFH 通过头压缩降低开销,实际 Goodput 依赖聚合、重传和端侧事务引擎
端到端延迟 面向百纳秒到亚微秒级路径;专用交换和信用流控更利于确定性 常见目标在亚微秒到数微秒;取决于交换芯片 cut-through、端侧代理、聚合策略、LLR/CBFC 和重传路径
流控机制 UALink 有 UPLI/TL/Switch 多层信用域;NVLink 内建链路级 CRC/replay 和专用流控 LLR + CBFC/PFC 是共性基础;SUE 有 PSN、ACK/NACK、GoBackN,ETH-X 有 PAXI credit,EthLink 有 RH 和 Switch Event Notification
地址空间与路由 UALink 支持 Fabric/网络地址模型,NVLink 是 NVIDIA 私有统一寻址域 地址翻译和内存管理多由 XPU/IOD/协议栈实现;ETH-X 使用 DA Mapping Register,EthLink OEFH 携带源/目的 GPU ID 并由交换机按 GPU ID 转发
交换芯片 专用 NVSwitch / UALink Switch;协议解析、转发和可靠性面向内存事务定制 复用或增强以太网交换芯片;需要支持 AFH/PRI/OEFH 解析、LLR、CBFC/PFC、QoS、遥测和故障事件反馈
网内计算 NVSwitch SHARP 已部署;UALink 2.0 引入 In-Network Compute ETH-X 白皮书定义 INCA 术语;SUE/EthLink 更强调传输、可靠性和流控,本身不主张完整网内计算
生态 NVLink 私有闭环;UALink 是开放联盟,成员和规范体系快速扩展 复用成熟以太网生态;SUE 有 OCP/Broadcom 规范基础,ETH-X 有 ODCC/腾讯路线,EthLink 来自字节跳动白皮书,标准化和跨厂商互操作成熟度仍需观察

从这张表可以看出,两条路线的分界不在物理层是否复用以太 SerDes,而在事务语义放在哪里兑现。Flit 原生方案把 Load/Store/Atomic 等内存事务直接放进固定 Flit 和专用交换域,路径短、确定性强,更适合细粒度同步和远端内存访问。以太网增强方案则把以太网改造成 Scale-Up 事务传输层,通过 AFH、PRI、OEFH、LLR、CBFC/PFC、RH 和端侧事务代理补齐小包效率、可靠性与保序能力。

以太网增强路线的语义覆盖更完整:SUE 更像开放的 XPU command transport,ETH-X 更像面向 AXI/PAXI 的超节点互联协议,EthLink 则把 GPU Load/Store 和 RDMA 同时纳入同一协议栈。以太网增强路线的关键价值在于让小块低时延访问和大块带宽型搬运可以共享以太 Scale-Up Fabric;关键风险则是多协议栈、多路径和端侧运行时必须共同处理乱序、可靠性、Cache Coherency 和 P99/P999 延迟。

4. Flit 原生总线方案

Flit 原生方案的核心思想是“用总线方式做互联”,即网络里的最小传输单元从设计之初就服务于内存访问事务,而不是先构造完整以太/IP/UDP 报文再承载事务。

GPU/XPU Core
Load / Store / Atomic

事务层 TL
请求、响应、顺序、Atomic

固定 Flit
控制 Flit / 数据 Flit

数据链路层 DL
信用、重传、打包

物理层 PL
高速 SerDes / FEC

专用交换芯片
NVSwitch / UALink Switch

远端 GPU/XPU HBM

4.1 NVLink

NVLink 是 NVIDIA 的专有 GPU-to-GPU 互联总线,和 NVSwitch、CUDA、NCCL、NVSHMEM、NVIDIA Fabric Manager 等软件栈一起构成 GPU 互联生态。其设计目标不是普通网卡通信,而是让多 GPU 域在带宽、延迟和拓扑上尽量像一个更大的加速器。

Pascal NVLink Packet 示意图如下。这里的格式用于说明早期 NVLink 的报文格式:链路上传输的是可变长度 packet,packet 由多个 128b flit 组成,而不是固定的以太网帧式报文。

NVLink Packet 基本格式

从图中可以看出,一个 NVLink packet 至少包含 header flit。header flit 本身是 128b,由 25b CRC、83b TL header 和 20b DL header 组成;TL header 描述事务层语义,例如 read/write/atomic等;DL header 服务于数据链路层,例如链路控制、packet 边界和重传相关信息;CRC 用于链路错误检测。packet 可以继续附带 Address Extension flit,用来承载多个 command 可能共享的地址扩展信息,例如高位地址;也可以按 command 需要附带 Byte Enable flit,用来描述部分字节有效性;真正的数据则放在 0 到 16 个 data payload flit 中。因为每个 payload flit 是 128b,也就是 16B,所以 16 个 payload flit 对应 256B 最大传输粒度。

Simple Read 的示意图展示了请求和响应如何复用这种 flit 结构。

NVLink Simple Read Packet

对 64B read 来说,requestor 先发送一个读请求 header flit;target 返回读响应 header flit,并跟随 4 个 data payload flit。4 个 128b payload flit 正好承载 64B 数据。这说明 NVLink 的 read 响应并不是把数据藏在命令头里,而是用 header flit 表达响应语义,再用后续 payload flit 承载数据,从而让小请求和大数据返回都能复用同一套 packet 结构。

NVLink Packet CRC 的作用是支撑链路级可靠性。Pascal NVLink Packet 对 CRC 与 replay 的说明如下。

NVLink CRC and Replay Packet Length

NVLink CRC and Replay Buffer

这些图里,虚线框表示 packet 边界,右侧 Seq ID 表示链路上连续 flit 的发送顺序。NVLink 在 header flit 中放置 25b CRC,可检测最大 packet 中最多 5 个随机 bit 错误,或单 lane 上最多 25b 的短 burst 错误。CRC 的计算覆盖当前 header 和前序 payload,这样接收端可以尽早获得 packet 长度与边界信息,同时完成错误检测。发送端会把已发送数据暂存在 replay buffer 中;当接收端确认 CRC 正确后,相关 packet 才能释放。如果出现错误,链路从最后一个已 ACK 的 packet 之后开始 replay。也就是说,NVLink 的 flit 结构不仅服务于事务封装,还直接服务于低延迟解析、链路保序、错误检测和硬件重传。

NVLink 的优势:

  • 成熟度最高:GPU、交换芯片、系统软件、通信库和调度工具链协同成熟。
  • 延迟和 Goodput 强:低协议开销、专用交换、原生支持 GPU 内存访问模式。
  • 网内计算领先:NVSwitch 的 SHARP 已在集合通信中形成硬件加速能力。
  • 系统设计确定:NVIDIA 可对端侧、交换、驱动、通信库和拓扑做端到端协同。

NVLink 的约束:

  • 私有生态:跨厂商 XPU 很难直接进入同一个 NVLink 内存语义域。
  • 成本和供应链绑定:高性能来自端到端封闭协同,也意味着替代和议价空间有限。
  • 可观测性与控制权边界由 NVIDIA 定义:系统集成方更多是调优和使用,而不是协议层共建。

4.2 UALink

UALink 是开放 Flit 原生总线路线的主要代表。UALink 规范定义了加速器与交换机之间的低延迟、高带宽互联,目标是在 AI computing pod 中支持最多 1024 个加速器;UALink 2.0 规范引入 In-Network Compute;200G DL/PL 2.0 将数据链路层和物理层从 Common 规范中拆分,以便随物理层速率快速演进。

UALink 2.0 规范显示,UALink 的基本协议栈包括:

  • UPLI:面向加速器端的协议层接口,支持 split request/response、多 outstanding、read/write/atomic memory operation。
  • TL:把 UPLI 的请求、响应和数据通道编码成 64B TL Flit。每个 64B TL Flit 分为两个 32B Half-Flit,控制 Half-Flit 可以承载请求、读响应、写响应、流控/NOP 信息。
  • DL:把 64B TL Flit 打包成 640B DL Flit,并提供链路控制消息、UART 机制、重传和速率适配。
  • PL:基于 IEEE 802.3dj 方向的高速物理层,支持 200G serial 相关速率,例如 200GBASE-KR1/CR1、400GBASE-KR2/CR2、800GBASE-KR4/CR4。

UPLI
Read / Write / Atomic

TL
64B TL Flit

32B Control Half-Flit
请求 / 响应 / FC / NOP

32B Data Half-Flit
数据 / Message / AuthTag

DL
640B DL Flit

PL
200G SerDes / FEC / 64B/66B / 256B/257B

UALink Switch / Remote Accelerator

UALink 的几个关键点值得注意:

  • 固定粒度降低不确定性:64B TL Flit 到 640B DL Flit 的设计,使事务解析、缓存、仲裁和信用回收更容易硬件化。
  • 请求压缩依赖地址缓存:TL 定义 Tx/Rx Address Cache 同步机制,未压缩请求可加载地址缓存,后续压缩请求通过 cache way 重构地址字段,用较小头部承载高频访存。
  • 内存语义明确:UPLI 支持读、写、Atomic;规范中定义请求/响应排序、Strict Ordering Mode、Single-Copy Atomicity 等机制。
  • 地址翻译保持实现灵活:UALink 2.0 的地址翻译模型允许 SPA/NPA 等形式,也允许 flat global addressing;Switch 使用 identifier-based routing,地址翻译可由具体实现选择。
  • 物理层复用成熟 SerDes,但不是普通以太网帧:PL 可复用以太相关物理能力,TL/DL 仍是为 Scale-Up 内存事务定制的 Flit 协议。

UALink 的优势:

  • 开放性:目标是让多厂商加速器进入同一类 Scale-Up Fabric。
  • 语义强:从 UPLI 到 TL/DL 都面向 Load/Store/Atomic 和远端内存访问构建。
  • 效率高:固定 Flit、请求压缩、信用流控有利于小包和高频事务。
  • 演进空间清晰:Common、DL/PL、Chiplet、Manageability 规范分层推进,便于物理层和管理面独立迭代。

UALink 的约束:

  • 交换芯片是关键瓶颈:协议文本成熟不等于系统成熟,UALink Switch 的量产、互操作、RAS 和管理软件决定落地速度。
  • 跨厂商语义一致性难:即使 Fabric 统一,端侧 MMU、缓存策略、Atomic、Fence 和驱动运行时也需要统一。
  • 网内计算处于规范到产品的过渡期:UALink 2.0 已引入 In-Network Compute,但与 NVSwitch SHARP 的成熟度相比,仍需要硬件和通信库验证。

4.3 NVLink 与 UALink 对比

维度 NVLink UALink
标准属性 NVIDIA 私有协议 开放联盟标准
成熟度 已规模部署,NVSwitch/NCCL/SHARP 闭环成熟 规范成熟度提升,硬件生态仍在形成
语义 NVIDIA GPU 内存语义深度集成 面向跨厂商加速器的 Load/Store/Atomic
交换芯片 NVSwitch 已量产并持续迭代 UALink Switch 是落地关键变量
网内计算 SHARP 已部署 UALink 2.0 引入的能力,产品化待观察
生态取舍 性能和确定性强,锁定 NVIDIA 开放潜力高,但协同成本更高

5. 以太网增强方案

以太网增强方案的核心思想是“用以太生态承载 Scale-Up 语义”。它不是把 RoCE 原样搬进 Scale-Up,而是在以太网基础上压缩头部、增强流控、增加链路级重传,并把 AXI/事务语义映射为更高效的以太网帧。

GPU/XPU NoC
AXI / 自定义命令 / LS-RDMA

端侧事务代理
PAXI / SUE Command / EthLink TL

聚合与打包
多事务合并

压缩以太头
AFH / PRI / OEFH

增强以太数据链路
LLR + CBFC/PFC + QoS

标准/增强以太交换芯片

远端端侧代理

远端 HBM

语义兑现重点

以太生态复用

这条路线的典型矛盾是:以太网成熟、便宜、开放、可运维,但原始以太网帧并不是为 GPU 远端内存小事务设计的。对于 128B 数据负载,几十字节的以太/IP/UDP 或自定义头部会显著拉低有效载荷比例。因此 SUE/ETH-X/EthLink 都把头压缩、事务聚合、无损流控和重传机制作为核心。

5.1 SUE

SUE,即 Scale Up Ethernet,是 OCP 发布的以太网 Scale-Up 规范,由 Broadcom 贡献。OCP SUE 1.0.0 规范的 Scope 明确是“transport over Ethernet for Load / Store and single-sided memory operations between XPUs”。这说明 SUE 并不是普通 NIC 协议,而是面向 XPU-to-XPU 内存操作的以太网传输框架。

SUE 的目标能力包括:

  • 单跳低延迟:典型部署是 single switch hop。
  • 规模:最多 1024 个 XPU。
  • 事务类型:one-sided operations,memory load-store-atomics,较小事务。
  • 延迟目标:E2E latency 小于 2us RTT。
  • 带宽:每个 SUE 实例 800Gbps,并可扩展到 1.6Tbps。
  • SerDes:200Gbps,同时支持 100G 和 50G。
  • 虚拟通道:最多 4 个,用于独立流量类别和避免死锁。
  • 以太兼容:支持标准 Ethernet,也提供 compressed header、LLR、CBFC。

SUE 的协议栈逻辑是:

  1. XPU NoC 发出 command。command 的具体 opcode 和语义由 XPU 定义,SUE 只看到命令、目的 XPU、数据存在标记和长度等字段。
  2. Mapping and packing layer 按目的端和 traffic class 聚合多个 command,形成 SUE PDU。
  3. SUE PDU 映射为单个 Ethernet packet。
  4. 网络头可使用标准 Ethernet/IP/UDP,也可使用 AFH Gen 1 或 AFH Gen 2。
  5. LLR 和 PFC/CBFC 提供无损链路服务;SUE transport 在不可恢复错误时提供重传。
  6. 目的端解包后把 command 交回 XPU NoC。
目的 XPU 目的 SUE Ethernet Switch SUE Instance 源 XPU 目的 XPU 目的 SUE Ethernet Switch SUE Instance 源 XPU Command + optional data per-destination queue + packing Reliability Header + PSN Ethernet packet with AFH/standard header single-hop forwarding PSN check / ACK / NACK unpacked command ACK or NACK

SUE 的关键取舍:

  • 语义边界在端侧:SUE 使用 shared memory model,但地址翻译由 XPU 在 SUE instance 外处理;内存注册、保护域等管理也在 SUE 外部。
  • 命令透明:SUE 可承载 put/get/atomic,甚至未来 cache coherency 服务,但这些服务的完整实现不是 SUE 的范围。
  • 顺序模式可选:strict ordering 保证同一源、目的、VC 的事务按序交付;unordered mode 则允许多端口负载均衡,但顺序不保持。
  • 可靠性分层:SUE transport 使用 PSN、ACK/NACK 和 GoBackN 保序和重传;LLR 处理链路层错误;CBFC/PFC 处理无损流控。
  • AFH 头压缩:AFH Gen 2 基于 IEEE 802.c 的 Structured Local Address Plan,定义 12B 和 6B 两种 header 选项,降低头部开销。

5.2 ETH-X

ETH-X 是 ODCC/腾讯等推动的 Scale-Up 以太增强协议路线。《ETH-X Scale Up 互联协议白皮书 V1.0》明确指出,ETH-X 是为超节点架构中跨 GPU 高效数据访问设计的协议,适用于大规模 GPU 间高速、低延迟通信。

ETH-X 的整体目标是让 Scale-Up 域内的 GPU、CPU 和内存池协同工作,逻辑上更接近“超级 GPU”。它既要支持 Direct Access,也要支持 Direct Copy,并在未来考虑 Scale-Up 与 Scale-Out 融合。

ETH-X 协议栈如下:

软件接口
通信库 / Runtime / 驱动

PAXI 事务层
GPU-GPU 访存协议

数据链路层
GPU-Switch 互通协议

物理层
IEEE 802.3 Ethernet PHY

D2D 互联
计算 Die 与 IO Die

CAXI / DAXI / APB

DA Mapping Register
GPU ID 到网络地址

TL Flit 到 MAC Packet

PRI 头压缩

L2 LLR

CBFC / PFC

ECMP / QoS

5.2.1 PAXI 事务层

PAXI,即 Peer-to-Peer AXI,是 ETH-X 定义的 GPU-GPU 访存事务层。它把 GPU 侧 CAXI/DAXI/APB 等接口信号转换为可通过以太链路承载的事务包。

PAXI 发送端的大致流程:

  1. GPU 发出远端访问请求或响应,进入 PAXI 时表现为 DAXI 或 CAXI 接口信号。
  2. Scale-Up 判断目的端是否有足够 credit,若不足则反压。
  3. PAXI 根据 AXI User 字段查找 DA Mapping Register,得到目的 GPU 的网络地址。
  4. AXI 五个独立通道按仲裁规则打包为 TL Flit。
  5. 同一 DA 的 TL Flit 可继续合并为 MAC Packet;APB TL Flit 优先级最高,CAXI/DAXI 使用 WRR。
  6. 对每个目的 GPU 维护 AR/AW credit,控制 outstanding 读写事务数量。
  7. PAXI 保证相同 DA 的事务按到达 PAXI 接口的顺序发送;相同类型、相同地址事务需要相同路径和相同 Flow Entropy。

这一设计说明 ETH-X 把大量“内存语义兑现”工作放到了端侧 IOD/PAXI:包括 AXI 通道仲裁、目的地址映射、credit、保序、聚合和屏障协同。

5.2.2 PRI 帧格式

ETH-X 的数据链路层重点是提升小包转发效率。PRI,即 Packet Rate Improvement,通过压缩以太头来减少事务的固定开销。

ETH-X 白皮书中的效率例子很直观:假设 Load 请求和响应的 Command 各 16B,Data 为 128B,内存事务本身效率为:

128 / (16 + 16 + 128) = 80%

如果直接放在以太上传输,加入 34B IP 包开销,效率变为:

128 / (16 + 16 + 128 + 34 + 34) = 56%

当头部压缩到 6B 时,效率提升为:

128 / (16 + 16 + 128 + 6 + 6) = 74%

再叠加多事务聚合,例如 4 组请求聚合,白皮书给出的例子可提升到约 77%。这也是以太增强方案必须做头压缩和聚合的直接原因。

ETH-X PRI 帧的关键元素:

  • 12B PRI 统一转发头,取代以太网帧中的 DMAC 与 SMAC。
  • 前 2B 为 Network DeviceID,用作网络路由字段。
  • 其余 10B 为 User Defined Address,供设备内部寻址,网络转发节点忽略。
  • 2B EtherType 作为新型以太网标识。
  • TTL、DSCP、ECN 和 Flow Entropy 支持生命周期、QoS、拥塞标记和负载均衡。
  • VLAN+PRI 增强帧可同时支持隔离和头部压缩。
5.2.3 可靠性、流控和调度

ETH-X 数据链路层还包括:

  • L2 LLR:链路层重传机制,利用扩展前导码承载报文序列号,降低链路错误恢复开销。
  • CBFC:信用式流控,在链路伙伴之间维护 Credit ConsumedCredit Freed 计数器,减少缓冲需求并支持更多无损 VC。
  • PFC:基础优先级流控,用于无损优先级队列。
  • ECMP:通过 PRI 头部中的 Flow Entropy 做等价路径负载均衡。
  • QoS:识别 PRI 的 DSCP 和 VLAN PCP,把 Direct Access、Direct Copy、控制流等送入不同调度队列。
  • 物理层:遵循 IEEE 802.3 PMD/PCS,支持 100G、200G、400G、800G 速率,并面向 50G/100G/200G lane 演进。
5.2.4 D2D 与 IO Chiplet

ETH-X 白皮书还把计算 Die 与 IO Die 的 D2D 互联作为重要组成。采用 IO Chiplet 的优势是把计算工艺和 IO 工艺解耦,便于复用已有 IO 芯粒,并按产品档位灵活配置互联带宽。UCIe 可作为计算 Die 与 IO Die 的互联基础,其适配层提供 CRC、重传、电源管理和多协议复用能力。

这意味着 ETH-X 的工程形态更像“XPU + IOD + Ethernet Switch”的组合,而不是单纯在 GPU 上加一个以太口。

5.3 EthLink

EthLink,即 Ethernet Link,是字节跳动在《GPU Scale-up 互联技术白皮书》中提出的自研 Scale-Up 网络协议。EthLink 目标是为 AI 集群提供低延迟、高带宽的高速互联传输。白皮书中更具体地说明,EthLink 同时承载 GPU 发起的 Load/Store 语义和 RDMA 语义,网络范围覆盖 GPU 服务器内部互联和跨机 GPU 互联。

EthLink 的基本判断是:Scale-Up 不应只支持 Load/Store,也不应把传统 RDMA 原样搬进 GPU 内部。Load/Store 适合小块、离散地址和时延敏感场景,例如控制信息、推理和细粒度同步;RDMA 适合 MB 到 GB 级大块数据搬运,可以减少 SM 或计算引擎持续生成 Load/Store 地址的开销,更适合训练中的张量并行、专家并行等大流量通信。因此,EthLink 把双语义支持作为核心设计点。

EthLink 协议栈如下:

GPU 操作
Load / Store / RDMA / Atomic / Message

Scale-Up 事务层
Memory Read / Memory Write / Atomic / Message

EthLink 网络报文
EthLink-LS / EthLink-RDMA Payload

RH
端到端可靠性补充

OEFH
Source / Destination GPU ID

以太网链路层
LLR + CBFC/PFC + 低延迟 FEC

低时延以太交换机
单跳 Scale-Up Fabric

远端 GPU Memory

5.3.1 语义层与事务层

EthLink 在 GPU 侧把协议栈分为 Scale-Up 语义层和 Scale-Up 网络层。语义层又分为 GPU 操作和 Scale-Up 事务层:GPU 操作包括 Load、Store、RDMA Write、RDMA Write with Immediate、RDMA Read、Atomic 和 Message;事务层则把这些操作转换成 Memory Read、Memory Write、Atomic 和 Message 等基础事务,再形成网络报文发往远端 GPU。

这种映射关系可以概括为:

GPU 操作 EthLink 事务映射 主要用途
Load 单次 Memory Read 小块远端读取、低时延访问
Store 单次 Memory Write 小块远端写入
RDMA Write 多个 Memory Write 大块数据写入远端 Global Memory
RDMA Write with Immediate 多个 Memory Write + 1 个 Write Message 大块写入并向远端 SM 传递立即数或通知
RDMA Read 多个 Memory Read 从远端 Global Memory 读回大块数据
Atomic Atomic 事务 远端同步与计数类操作
Message Message / Write Message 控制信息和通知

白皮书还给出一个偏软件协同的 Cache Coherency 选择:从片外 Global Memory Load 到 GPU 内 Shared Memory 时,数据可以缓存在 Cache 中;从 Shared Memory Store 回片外 Global Memory 时不写入 Cache,而是直接写入片外内存;必要时由系统软件清除 Cache,保证 Cache 与片外 Global Memory 一致。这个选择体现了 EthLink 的边界:它希望避免在更大 Scale-Up 网络中强行用网络硬件维护完整 cache coherency,把一致性成本转移给更可控的软件和运行时阶段。

5.3.2 报文封装、可靠性和拓扑

EthLink 的网络层重点包括 OEFH、RH、LLR、CBFC 和 Switch Event Notification。

  • OEFH,即 Optimized EthLink Forwarding Header,用更短的头部替代标准 ETH+IP+UDP 头,以降低报文开销。OEFH 包含 source GPU ID 和 destination GPU ID,交换机可根据 GPU ID 转发。
  • RH,即 Reliability Header,用于端到端可靠性,是对链路层 LLR 的补充。
  • LLR 处理链路上的 CRC 错误等丢包。发送端缓存报文,发生错误时在链路层重传,直到对端确认收到。这样可以降低对强 FEC 的依赖,使 RS-272 等低延迟 FEC 更可行;如果引入光互联,也有利于使用 LPO 来降低光链路延迟。
  • CBFC/PFC 处理交换机内部 buffer 丢包。白皮书更强调 CBFC,因为它可与 VC 绑定,并通过 credit 更精确地感知对端 buffer 状态。
  • Switch Event Notification 用于单层交换拓扑的故障反馈。Scale-Up 为降低延迟通常采用单层交换;一旦远端链路或端口故障,源 GPU 未必天然知道跨交换机的远端链路状态,因此交换机需要快速把 port event 反馈给源 GPU,让 GPU 侧 multi-path 尽快切换路径。

在拓扑上,EthLink 假设每个 GPU 服务器部署多个 EthLink 协议栈,每个协议栈支持 1 到 4 个以太网接口,服务器之间通过低时延以太交换机互联,同一个 Scale-Up 网络域最大支持 1024 个 GPU 节点。多协议栈和多端口可以提升带宽,但 Multi-Path 负载均衡会引入跨协议栈乱序;白皮书明确指出,这类乱序无法完全在 EthLink 内部保序,需要由上层应用处理。

5.3.3 EthLink 的关键取舍

EthLink 的优势在于语义覆盖更完整:它把 Load/Store 和 RDMA 都放进 GPU Scale-Up 域,而不是只强调细粒度访存或只强调大块搬运。对于训练,RDMA 语义有利于大块模型并行流量;对于推理和控制面,Load/Store 语义有利于小块、离散地址和低时延访问。OEFH、RH、LLR、CBFC 和 Switch Event Notification 也说明它不是普通 RoCE,而是面向 GPU Scale-Up 做了头部、可靠性和故障反馈优化。

EthLink 的约束也很清晰:它目前主要来自字节跳动白皮书和产业文章,标准化开放程度、跨厂商互操作、交换芯片支持、通信库适配和外部生态成熟度仍需观察。由于多协议栈负载均衡可能把乱序暴露给上层,实际 Goodput 和 P99/P999 延迟会高度依赖 GPU 端事务引擎、运行时、通信库和应用对乱序的处理能力。

5.4 SUE、ETH-X 与 EthLink 对比

维度 SUE ETH-X EthLink
组织与定位 OCP 规范,Broadcom 贡献,以太 Scale-Up transport ODCC/腾讯等白皮书,面向超节点 GPU 互联 字节跳动自研白皮书方案,面向 GPU Scale-Up 以太互联
上层接口 XPU command,可类似 AXI4 或自定义 signal PAXI,显式对接 CAXI/DAXI/APB GPU 操作层,支持 Load/Store、RDMA、Atomic、Message
事务抽象 SUE command / PDU PAXI TL Flit / MAC Packet Memory Read、Memory Write、Atomic、Message
头压缩 AFH Gen 1 / Gen 2,6B 或 12B 选项 PRI 12B 统一转发头,VLAN+PRI 可选 OEFH,按 source/destination GPU ID 转发,替代 ETH+IP+UDP 头
可靠性 E2E Retry、PSN、ACK/NACK、GoBackN,LLR L2 LLR,PAXI credit,CBFC/PFC RH 补充端到端可靠性,LLR 处理链路错误,CBFC/PFC 处理 buffer 丢包
顺序 strict / unordered 模式 同 DA 顺序、同类型同地址同路径 Flow Entropy 同路径需保序;Multi-Path 跨协议栈乱序由上层应用处理
地址与路由 XPU 外部处理,SUE 不定义完整内存管理 DA Mapping Register 映射 GPU ID 到网络地址 OEFH 携带源/目的 GPU ID,交换机按 GPU ID 转发
拓扑与规模 单跳低延迟,最多 1024 XPU 面向超节点与 IO Chiplet/D2D 组合 每服务器多 EthLink 协议栈,每栈 1-4 个以太口,域内最多 1024 GPU
物理生态 以太 SerDes、以太交换、OCP 生态 以太 PHY/MAC/交换,加 IO Chiplet/UCIe 适配 低时延以太交换、低延迟 FEC、LLR/CBFC,强调以太生态复用
开放边界 规范较清晰,但 XPU opcodes 不透明 白皮书较系统,PAXI/PRI/LLR/CBFC 细节更面向实现 白皮书披露较完整,但标准化、跨厂商互操作和外部生态仍待观察

6. 关键维度横向比较

维度 Flit 原生总线:NVLink / UALink 以太网增强:SUE / ETH-X / EthLink
基本抽象 内存事务原生进入 Fabric AXI/命令/LS/RDMA 语义映射到以太网帧
封装单位 固定或强约束 Flit 变长以太网帧,靠头压缩与聚合优化
小包效率 头部小、解析固定,目标 90% 以上 标准以太小包效率低,需 AFH/PRI/OEFH/聚合提升
延迟确定性 更强,交换与流控为内存事务定制 依赖交换芯片 cut-through、端侧代理、聚合与流控
事务粒度 适合细粒度 Load/Store/Atomic SUE/ETH-X 偏端侧命令或 AXI 事务;EthLink 显式区分 LS 小包和 RDMA 大块搬运
地址空间 NVLink 私有统一域;UALink 支持 Fabric/网络地址模型 地址翻译多由 XPU/IOD 厂商实现
流控 信用流控、虚拟通道、链路级重传 LLR + CBFC/PFC + transport replay/credit/RH
交换芯片 专用 NVSwitch / UALink Switch 复用或增强以太交换芯片
网内计算 NVSwitch SHARP 成熟;UALink 2.0 规范引入 ETH-X 白皮书定义 INCA 术语;SUE/EthLink 本身不主张完整网内计算
生态 NVLink 封闭成熟,UALink 开放待成熟 以太生态成熟,Scale-Up 语义需端侧补齐

7. 工程取舍

7.1 性能优先时,Flit 原生更自然

Direct Access 的最大敌人不是平均带宽,而是每一笔远端 Load/Store/Atomic 的尾延迟和顺序不确定性。Flit 原生方案从 TL/DL/PL 到 Switch 都知道自己在承载内存事务,可以更早、更硬件化地处理:

  • 请求和响应压缩。
  • 同地址保序。
  • Atomic 返回。
  • Fence 排空。
  • 信用回收。
  • 多播和规约。

因此,强同步、小包高频、TP-heavy、长上下文 KV Cache 共享等场景更偏向 Flit 原生路线。

7.2 生态优先时,以太增强更现实

以太增强方案的吸引力在于供应链和系统工程:

  • SerDes、连接器、线缆、光模块、交换芯片、运维工具成熟。
  • 多厂商可以围绕以太交换和开放帧格式协作。
  • 产品化可以从标准以太能力渐进增强,例如先支持标准帧,再支持 AFH/PRI/OEFH、LLR、CBFC。
  • 与现有数据中心网络、SONiC、遥测和运维体系更容易融合。

但它的代价是,内存语义不天然存在于以太 Fabric 中,必须由端侧 IOD、事务代理、驱动、运行时和通信库共同补齐。只要任何一环处理不好,Goodput、P99 延迟和可调试性都会受影响。

7.3 关键不是峰值带宽,而是 Goodput

Scale-Up 的有效性能取决于:

  • 有效载荷比例:头部、FEC、重传、信用消息和空闲填充都会吃掉带宽。
  • Outstanding 深度:远端响应越慢,端侧队列越容易被占满。
  • 保序粒度:全局保序简单但吞吐低,选择性保序复杂但更高效。
  • Fence 代价:系统级屏障可能阻塞多个 GPU 和多个 IOD 平面。
  • 负载均衡与顺序冲突:多路径提升带宽,但同地址事务必须避免乱序。
  • 可观测性:没有端到端计数器、时间戳和事件关联,就很难定位 Goodput 损失。

峰值链路带宽

协议开销

端侧队列深度

交换与流控

保序 / Fence

重传 / RAS

Goodput

训练吞吐 / 推理 P99 / 通信库效率

8. 选型建议

否或可由端侧补齐

Scale-Up 互联选型

是否锁定 NVIDIA 生态?

优先 NVLink / NVSwitch
成熟性能闭环

是否需要原生强内存语义?

关注 UALink
重点验证 Switch、端侧 IP、运行时

是否优先复用以太生态?

关注 SUE / ETH-X / EthLink
重点验证端侧语义、头压缩和 P99

评估私有总线或混合架构

适合:TP、远端 Atomic、KV Cache、细粒度共享

适合:Direct Copy、RDMA 搬运、聚合事务、多厂商以太供应链

具体建议:

场景 更适合的路线 原因
NVIDIA GPU 机柜级超节点 NVLink / NVSwitch 性能、SHARP、NCCL/NVSHMEM 和系统软件成熟
多厂商 XPU 但追求原生内存语义 UALink 开放 Flit 总线,语义更接近 NVLink
国内/自研 XPU,重视以太供应链 ETH-X PAXI、PRI、LLR、CBFC 和 IO Chiplet 路线完整
需要同时覆盖 LS 小包和 RDMA 大块搬运 EthLink 语义层同时定义 Load/Store 与 RDMA,并映射到 Memory Read/Write/Atomic/Message
以太交换芯片生态优先,XPU 可自定义命令 SUE OCP 规范清晰,AFH/LLR/CBFC 复用以太能力
大块搬运、Direct Copy、EP/DP 流量占优 SUE / ETH-X / EthLink 聚合或 RDMA 化后,以太增强方案效率更容易接近目标
细粒度同步、远端 Atomic、频繁 Fence NVLink / UALink 端到端强语义和低延迟更关键

9. 后续跟踪指标

后续判断哪条路线真正可用,不能只看 PPT 上的带宽,而要看以下可量化指标:

  1. 端到端 RTT 与 P99/P999 延迟,分别测 64B、128B、256B、1KB、4KB。
  2. 小包 Goodput,区分标准以太网帧、压缩头、聚合开启和聚合关闭。
  3. Atomic 与 Fence 延迟,尤其是跨多 GPU、多 IOD、多路径场景。
  4. 同地址保序和 Flow Entropy 策略,是否在负载均衡和正确性之间可调。
  5. 交换芯片能力,是否支持 cut-through、LLR、CBFC、PRI/AFH/OEFH 解析、QoS 和遥测。
  6. 通信库承接情况,NCCL、RCCL、OpenSHMEM、NVSHMEM 类库是否真正使用新语义。
  7. RAS 与故障恢复,链路错误、重传风暴、端点故障、热插拔和降级运行如何处理。
  8. 多厂商互操作,地址空间、Atomic、Fence、管理面和安全隔离是否一致。

10. 总结

Flit 原生总线和以太网增强方案会长期并存。前者更像“把远端 GPU 继续组织成本地可编程资源”,后者更像“把成熟以太网改造成足够好的 Scale-Up 事务传输层”。

NVLink 已经证明了强语义总线在 AI 超节点中的价值;UALink 试图把这种能力开放化、标准化。SUE、ETH-X 和 EthLink 则试图把以太生态拉进 Scale-Up 域,以更低供应链门槛换取接近专用总线的效率。最终胜负不会只由链路速率决定,而会由端侧事务引擎、交换芯片、通信库、运行时、RAS 和可观测性共同决定。

如果用一句话概括:Flit 原生方案胜在“语义天然、路径短、确定性强”;以太增强方案胜在“生态成熟、成本弹性、产业协同空间大”。真正的系统选型,需要先判断工作负载最缺的是强语义低延迟,还是开放生态和规模化供应链。

11. 参考资料

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐