从芯粒到服务器：一文读懂大模型浪潮下的开放互连

编者按：

本文梳理了 UCIe/CXL/UAL/UEC 等开放互连标准的特性， 探讨了它们在 AI 场景下的应用和竞合，并从 AI 云基础设施视角出发，如何看待 SUE？Scale-Up 域的边界在何方？以及 CXL 在 AI 背景下的未来。

前言

过去的五到六年见证了 AI 大潮的汹涌澎湃，而在这巨浪之下，也涌动着开放互连标准的蓬勃发展：

• 2019 年 3 月，Compute Express Link（CXL）联盟成立，旨在解决当时异构 XPU 编程以及内存带宽和容量扩展所带来的挑战，以内存为切入点构建一个可编排的机柜级服务器架构。阿里作为以创始成员的身份成为 CXL 联盟董事会董事。 彼时，Transformer 架构已发布近两年，其潜力已在 BERT 上牛刀小试。

• 2022 年 3 月，Universal Chiplet Interconnect Express（UCIe）联盟成立。此时，基于芯粒（Chiplet）的芯片设计范式已成为后摩尔时代设计高算力芯片的业界共识，但整个行业还缺乏一个有号召力的，开放的 Die-to-Die 互连标准。UCIe 旨在填补这一空白。同年 8 月，阿里正式成为 UCIe 联盟董事会，成为中国大陆唯一个 UCIe 董事会成员。 那时，距离 ChatGPT 的发布还有 3 个月。 

• 2023 年 7 月，Ultra Ethernet Consortium（UEC）联盟成立。此时，整个行业正处在被 ChatGPT 点燃的百模大战中，大模型训练的需求爆炸式增长，而基于传统以太网的集群面对这波泼天富贵已显得力不从心。UEC 的成立正当其时，它旨在为 AI 和 HPC 重建一个高效开放的以太网。 同年 11 月，阿里云正式加入 UEC 联盟，成为 General 会员（UEC 两级会员体系中的高阶会员）。

• 2024 年 10 月，Ultra Accelerator Link （UAL）联盟成立，旨在应对模型尺寸以及推理上下文快速增长带来的对 Scale-up 网络的需求。2025 年 1 月，阿里以董事会董事的身份加入 UAL，成为中国大陆唯一个 UAL 董事会成员。

笔者有幸代表阿里云以 UCIe 和 CXL 董事会董事的身份，参与了 UCIe 1.0～3.0 标准, 以及 CXL 3.x～4.0（即将发布）标准的制定和发布；同样来自服务器团队的廷钰代表阿里云以 UAL 董事会董事的身份，参与了 UAL 1.0 标准的制定。正是因为这些在开放互连中的长远布局使阿里在 AI 大潮中占据了极为有利的硬件生态位，引领国内开放互连生态的发展。 本文旨在通过介绍 UCIe/CXL/UAL/UEC 的基本概念和特性，系统的梳理各个层次的开放互连在 AI Infrastructure 中的作用，帮助大家深入理解这些不同字母组合背后的含义和关系。

背景

大模型的迭代在 Scaling Law 的信仰下，高潮迭起，你方唱罢我登场， 令人目不暇接。现在回望，所谓的 Scaling Law 大致有三个阶段：

• Pre-training Scaling：在模型预训练阶段，通过增加模型参数数量，训练用的数据量，以及用于训练的计算资源（即传统的算法，数据和算力三要素），来提升基础大模型的输出精度。 

• Post-training Scaling: 在模型后训练阶段，通过基于专业数据集（Domain-Specific Dataset）的微调，Reinforcement Learning with Human Feedback（RLHF）以及 Teacher-Student 调教和蒸馏（Distillation）等手段， 使大模型的输出更具有专业素养，符合人类沟通习惯和价值观。 

• Test-time Scaling: 在模型 Inference 阶段，通过生成更多用于协助推理的 token，从而形成更高质量的模型输出。常见的方式比如：Chain-of-Thought（CoT）Prompting： 通过将问题分解为多个步骤，展示推理过程；Sampling and Voting： 通过针对一个 Prompt 生成多种可能的响应结果，借助 Majority Voting 选择最佳结果。 

图 1. 大模型 Scaling Laws. Source: [3]

如今，这三阶段 Scaling Law 依然在大模型的演进中起着各自的作用， 但是，Scaling 的重心已经转移到了 Test-time Scaling。这是从大模型竞赛到大模型落地应用自然过渡的结果；但另一方面，推理是对客服务的，它对延时指标（e.g. Time To First Token (TTFT)，Time Per Output Token (TPOT)) 和吞吐指标（Token Per Second（TPS)) 都有刚性需求，这对 AI Infrastructure 提出了与 Pre-training Scaling 截然不同的新挑战。 

为此，当黄教主端出了热气腾腾的 GB-200 NVL72 全家桶时，广大 CSP 们无不为之垂涎：NVIDIA-HBI（High Bandwidth Interface）连接了两颗 Blackwell Die，构成了一个完整 Blackwell GPU；同时，Grace CPU 通过 NVLink C2C（利用其 Chip-2-Chip 互连功能）连接了两个 Backwell GPU， 并以 2CPU：4GPU 的方式构建一个计算节点（A.K.A.，Compute Tray）；接着，NVLink 连接起 72 个 GPU（18 个计算节点），构成一个 Scale-up 网络；Backend 网络( 或 Scale-out 网络 )？ CX-7 （IBTA RDMA or RoCE）顶上。这全家桶，从计算到互连，都是业界顶流，全面回应了 CSP 所面临 Test-time Scaling 的痛点，着实让人心动。但这里问题是其核心互连都是 NVidia 独家私有。 对于 CSP 来说，这意味着，在商业上，弱势的议价能力和 Vendor Lock-in；在技术上，丧失了独立的优化空间；在产品上，不具备差异化特性和竞争力。 

因此，我们需要拥抱开放互连标准。 开放意味更多参与者，带来更多的选择性，更为健壮的供应链，也意味着更大的定制和优化空间。 而作为开放互连的代表，UCIe/CXL/UAL/UEC 涵盖了从芯粒互连到 Scale-out 网络的全链条，是我们构建 AI Infra 核心竞争力的重要阵地和抓手。 

UCIe：芯粒？成本！

何以芯粒？

基于芯粒（Chiplet）的设计方式已经成为当前高性能 CPU/GPU 的主流设计范式， 这是在后摩尔时代，应对单位晶体管成本下降缓慢的必然选择。为什么这么说呢？ 这是因为基于芯粒的设计在多个层面解决了成本的问题，如下图所示：

• 提升良率：通过将单一大尺寸硅片切分成小的硅片，再合封在一起的方式，缩小了晶圆上单个缺陷所影响的范围， 从而提高了硅片产出的良率，降低了单位硅片的成本。 

• 制程节点优化：通过将芯片的电路进行合理的切分，提升了电路功能和对应制程的契合程度。 比如，将 DDR 控制器，PCI 控制器等 IO 模块集中在 IO Die 中，而由于 IO Die 中模拟电路占比较高，对高端制程无刚性要求，因此可以采用较为成熟的制程，从而降低 IO Die 的制造成本。 

• 跨产品的芯粒复用：传统的单片 SoC 设计中， 如果要做多个不同的产品 SKU，要么在一个硅片上做个多个产品 SKU 的超集，然后在硬件上关闭某些核心或者加速器，形成不同的 SKU；要么针对每个 SKU 都设计一个硅片单独流片，这两者的整体成本都比较高。而基于芯粒的设计通过对 Core 芯粒和加速器芯粒的复用和组合，构成不同的产品 SKU。这种复用和组合灵活性带来的成本分摊，充分体现了芯粒设计的价值。

•  芯粒市场化：如果说跨产品的芯粒复用是在公司内部的芯粒复用，那么芯粒供应货架化则是跨公司的芯粒复用。它是当前板级设计中芯片货架化的商业模式在芯片内部的自然延伸，能使芯粒的设计和制造成本得到最大程度的分摊（Economy of Scale）。同时，通过市场竞争提升进一步提升可选择性和供应链的健壮性。 

图 2. 基于芯粒设计的价值支柱

除了成本方面的优势，基于芯粒的设计模式还解决了芯片的极致性能问题，这在 GPU 侧体现的尤为突出。硅片的大小受到光罩尺寸（Reticle Size）的限制，对于 EUV 制程来说，它通常在 850mm^2 左右。 当前，GPU 对更高单芯片算力的追求已使硅片面积经触及了光罩尺寸，而芯粒提供了一种突破光罩尺寸对算力限制的途径：将多个大尺寸硅片合封在一起，提供远超单一硅片能实现的单芯片算力。 这实际就是 NVIDIA 的 Blackwell GPU（2 Die 合封）和 Rubin Ultra GPU（4 Die 合封）（参见下图 3.）背后的逻辑。

图 3. Rubin Ultra 4 个 Reticle Size GPU 合封

目前，前三个芯粒价值已经在芯片大厂（AMD，Intel，NVidia 等）中得到充分渗透，但基本是通过私有 Die2Die 互连实现的（比如，AMD 的 Infinity Fabric，NVidia 的 NVLink C2C）。而芯粒的市场化依然比较遥远，它的实现有赖于一个开放和可互操作的 Die2Die 互连协议。 不仅如此，开放的 Die2Die 协议还能让广大的芯片创业公司都快速搭上芯粒设计的大船， 与芯片大厂同台竞技，而不必投入大量资源自研的相关协议。从这层意义上来说，开放协议涉及到平权和产业的繁荣，这也是我们为什么要坚定的支持开放的另一个原因。 但是光有开放还不够，一个协议要有生命力，必须要有足够好的 KPI 和产业链上主流厂商的背书；能够体察业界痛点，持续演进；被业界广泛采纳。 UCIe 具备了这些维度上的特点：它的 KPI 在已有的芯粒互连协议中最具有竞争力；在产业链上得到了从 Fab（TSMC，三星）到封装（日月光）到设计（Intel，AMD，ARM，NVIDIA，Qualcomm）到应用（Alibaba，Google，Meta，Microsfot）主流公司的支持；3 年时间已经迭代到 3.0 版本，国内外主要 EDA 厂商已经开始销售 UCIe IP。

UCIe 协议概览

任何一个通信协议的设计都与它所要应对的信道状态和应用场景息息相关，UCIe 也不列外。作为芯粒间的互连标准，UCIe 要面对的是：

• 极短的信道长度：对于 2D/2.5D 封装，信道长度在毫米级，而对于 3D 封装，若通过混合键合（Hybrid Bonding）来实现，其信道长度在亚微米级。 这意味信道衰减较低，无需对传输数据做前向纠错（FEC）。

• 多元的信道介质：不同的封装技术会让信道处在不同的介质中，标准封装工艺通常会让信道穿越有机基板或玻璃基板，而先进封装通常会采用 Silicon Interposer（e.g., TSMC 的 Chip-on-Wafer-on-Substrate (CoWoS)) 或者硅桥（e.g. Intel 的 Embedded Multi-die Interconnect Bridge (EMIB) 等。不同的介质支持不同的信道密度，需要区别对待。

• 有限的 IO Pad 空间：硅片上 Micro-bump 资源相较于芯片的引脚资源来说更为丰富，但依然非常有限，毕竟当前的硅片设计大部分情况下都属于 IO Pad Limited，即 IO Pad 的面积决定了硅片的面积。这意味着 Die2Die 协议需要有很高的带宽密度（GB/s/mm or GB/s/mm^2）来减少对硅片 IO 资源的占用。这进而意味着更小的 Micro-bump Pitch，更高效的 Micro-bump 排布。 

• 极致的延时要求：芯粒合封通常有两个来源：一种是原本独立的板级加速设备被合封进芯片内部，此时跨 Die 传输延时相较于板级传输延时有天然的数量级优势，因此这种情况下，对跨 Die 延时的要求不高；另一种，也是更为重要的一种是通过切分将 SoC 分到多个 Die 上进行合封，此时跨 Die 延时越小越好。 UCIe 将目标设为<2ns (TX+RX)，这是一个极具竞争力又极具挑战性的目标。为达成这一目标，UCIe 采用了并行接口设计，以避免数据串行化带来的额外延时。这是综合考虑了信道长度和介质对信号完整性的影响，以及延时需求和 IO Pad 成本之间的权衡。 当前做得好的 IP 可以把延时控制在 10ns 以内。 

• 高标准的链接可靠性：Die 与 Die 的物理链接要么经过 Micro-bump（2D/2.5D），要么经过键合，两者对工艺的要求极高。如果在 micro-bump 焊点处或者键合处有杂质或缺陷，使用过程中容易出现电迁移造成链接失效。如果在服务器主板上出现这样的问题， 可以替换部件重新焊接；但在芯片内部，这种问题会导致整个芯片失效。 因此，跨 Die 链接需要引入冗余机制， 构建对此类问题的修复能力，提升可靠性。

• 支持多种协议的灵活性：如上所述， 芯粒合封通常有两种场景：一是将加速芯粒以 CXL 或 PCIe 设备的形式合封，此时跨 Die 通信的协议是 CXL 或 PCIe；另一种是各类多核计算芯粒的合封，此时跨 Die 通信涉及到连接片上网络（NoC）的各种一致性协议（e.g. CHI）甚至是自定义协议。 因此，UCIe 要做的是提供足够的灵活性，支持好各类已有的上层协议，而不是另起炉灶再定义一套上层协议。 

图 4. UCIe 协议框架

综合上述需求， UCIe 构建了三层协议栈：物理层，Die-to-Die 适配层和协议层。协议层和 D2D 适配层通过 Flit-Aware Die-to-Die Interface（FDI）衔接，而 Die-to-Die 适配层与物理层之间通过 Raw Die-to-Die Interface（RDI）衔接。 那么，为什么在 UCIe 协议中需要有这样的接口，而通常其他的协议栈中并没有呢？这和 UCIe 协议所要提供的上层协议灵活性有关。在 UCIe 中，协议层实质是个筐，各种协议都可以往里装：PCIe，CXL 和以 Streaming 形式出现的其他协议。FDI 负责将这些协议物理层以上的数据通过 Arbitration/Mux 的方式导入到 Die-to-Die 适配层。另外，Streaming 在 Raw Mode 下可以绕过 D2D 适配层直接进入到物理层。 因此，我们需要 RDI 将来自于 D2D 适配层的数据和 Raw streaming 数据进行 Mux。这也就是我们需要有 FDI/RDI 的原因：多个协议数据流之间的 Arb/Mux。

D2D 适配层主要通过 CRC 和 Retry 保证数据在跨 Die 传输的正确性。 物理层是 UCIe 协议中的大头，它负责链接初始化，Lane 映射和重映射（出现通道失效，冗余备份通道被激活时需要重映射）等。 一个物理层对应一个模组信号，包括 x16 或 x64 的 TX 和 RX 数据信号，一个前向时钟，一个 Valid 和 x2 的侧信道。 一个 D2D 适配层可以支持 1，2，4 个这样的模组信号。 为适配不同的信道介质，UCIe 区分了标准封装（UCIe-S）和先进封装（UCIe-A）两个 Profile，其中 UCIe-S 只支持 x16 数据信号，而 UCIe-A 支持 x64 数据信号，但两者都支持 32GT/s 的传输速率。先进封装单模组的带宽可达 256GB/s，更高的速率也在定义中。 

图 5. UCIe-3D 层次结构

UCIe-3D 是 UCIe 2.0 中引入的新的 Die2Die 互连 Profile，建立在混合键合 3D 封装技术之上。 由于其信道长度几乎可以忽略，因此，UCIe-3D 的物理层可以也必须极致简化：一个信号驱动即可。 同时，由于 3D 封装将原先 2D/2.5D 封装中的 Shoreline 拓展到了整个 Die 平面， 如何组织这些信号端口就变的尤为突出。 如上图所示，为了便于管理， UCIe-3D 把这些信号以 0.02mm^2 为单位组织成一个 bundle，每个 bundle 中的有 x80 TX/RX 信号，并以 9um bump pitch 进行排布。相比之下， 2D/2.5D 的先进封装中的 bump-pitch 在 25～55um 之间。 由于混合键合易受到杂质的干扰，因此，UCIe-3D 在每一行的 bundle 中定义了两个冗余的 bundle，用于应对杂质/缺陷的影响。为什么要有两个冗余的 bundle？因为如果一个缺陷正好处在四个 bundle 的交接处，它就会让四个 bundle 变得不可用，正好每行两个。 这里 Bundle 的 remapping 并没有在 UCIe-3D 标准中定义，它需要上层的逻辑电路将该因素考虑进去，并提供相应的支持。 

UCIe 协议的应用

UCIe 芯粒合封的一个典型应用场景如下图（a）所示：两个计算 Die 通过 UCIe 相连，通过 CHI 协议实现计算 Die 之间的 Cache 一致性；同时一个计算 Die 再通过 UCIe 与加速 Die 互连，通过 CXL 协议，将加速器内存和计算 Die 内存构成统一空间，实现互访。 

UCIe 也推动了光电共封（Co-Packaged Optics，CPO）的发展。当前的产业链下，Optics Engine（OE）和计算芯粒通常分属不同公司。要实现共封，大概有几种方式：1. 计算芯片大厂收购光模块公司后，通过私有 Die2Die 协议实现光电共封；2. 通过私有 Die2Die 协议 IP 对光模块公司的定向授权，实现 CPO；3. 通过计算 Die 和 OE 共同遵循开放 Die2Die 协议 UCIe，来实现光电共封。我们认为第三种方式成本最低，灵活度最高，可以灵活实现标准封装或先进封装下的 CPO；但在实操中，实现来自两家公司 UCIe 的互操作，还存在前期系统验证和 EDA 工具不成熟等生态方面的挑战。而随着 CPO 在 AI 集群互连中变得日益重要， 它反过来对 UCIe 生态也是一种良性的促进。 

(a) Core Die 以及加速器 Die 的片上互连

(b). UCIe-based CPO

图 6. UCIe 互连应用场景

CXL：重塑服务器组织形态

CXL 联盟成立于大模型爆发之前，那时深度学习和各类卸载所带来的 XPU 盛行，整个行业所面临的问题是： 如何在服务器层面对这些异构设备进行灵活的编排和高效的编程；同时，在 CPU 核心数快速增长的背景下，如何应对内存带宽需求增长和芯片有限引脚资源的矛盾。 因此 CXL 以内存为切入点，构建一个基于内存语义的一致性互连， 并通过解耦计算和内存，实现可编排的机柜级服务器硬件架构。但它仍然是 CPU-centric 的，又受到到 PCIe 带宽的限制，因此在大模型爆发的时代，无法直击核心痛点，未能成为 AI 基础设施海量投资的焦点。即便如此，这种对服务器组织形态的重构依然意义深远，而且随着 PCIe 速率的提升，CXL 对 AI 基础设施的效能提升还在不断增强。 

CXL 主要特性：

关于 CXL 协议的核心概念，可参考“服务器CXL之路：CXL核心概念及标准演进”文章，这里就不再赘述。 上表总结了 CXL1.0 到 CXL3.2 标准所支持的特性清单。在这里，我们简单梳理下在笔者看来对 AI 有较大助力的 CXL 特性。

表 1. CXL1.0～3.2 支持的主要特性

• 内存扩展（Memory Expansion）和内存池化（Memory Pooling）: 内存扩展应该是目前为止 CXL 最为成熟的应用， 它能够通过 CXL 串行端口和 CXL Memory Module（Type 3 CXL Device，说人话就是 CXL 协议打包的 DDR 内存） 拓展 Host 内存容量。 同时，随着 XConn 的 CXL 2.0 交换机逐步推向市场， 通过交换机的内存池化又为内存容量的扩展提供了更加广阔的扩展空间。CXL 池化有两种形态：一种是以设备为粒度的池化，每个设备为 Single-Logic-Device（SLD），它只能以一个整体分配给某个 Host；另一种是将设备的物理资源分成多个逻辑设备(Up to 16) 并分配给不同 Host，这种设备被称为 Multi-Logic-Device (MLD)。MLD 常见于 CXL 存储设备，比如像 AliSCM 的 CXL Storage Class Memory。每个 MLD 中的逻辑设备（LD）都有一个 ID 来区分（LD-ID），但是这个 LD-ID 并不是 Host 可见的。CXL Switch 根据 Transaction 中的 Host Port 来找到其对应的 LD-ID，并通过 Fabric Manager 来构建和维护这样的映射表。内存扩展和池化为 LLM 推理服务系统提供了一个分层的缓存系统。 

• 统一的一致性内存空间: CXL 通过将 Host 内存和设备内存统一编址，构建了统一的内存空间，并借助 CXL.cache 实现一致性。由于可以通过 Host CPU 扩展大容量的 DDR 内存，这种特性在理论上能够很好的弥补当前 GPU 显存不足且昂贵的缺陷。 这个其实和 GB200 通过 NVLink C2C 实现 Grace 和 Blackwell 统一内存是一样的。但是在 CXL 上遇到了一些比较现实的挑战：首先，由于 CXL 基于 PCIe PHY，而当前相对成熟的 PCIe Gen5/6 的速率远低于 NVLink，这导致 Host 与 Device 之间数据搬移的延时较大，严重影响了统一内存的实际效果 。其次，设备对 Host 内存的访问需要通过 CXL.cache 协议，但该协议的实现复杂性较高，到目前为止，尚未见到成熟的支持 CXL.cache 的设备；而 PCIe Gen5/6 较低的速率进一步削弱了在 GPU 上集成 CXL 的动力。这种情况估计要等到 PCIe Gen7（128GT/s 的传输速率）成为主流后才能有所改变。

• 通过 GIM（Global Integrated Memory）的 Host-to-Host 内存共享 : GIM 是 CXL 3.1 提出的概念，用来实现 Host 之间的一致性内存访问。具体来说，GIM 指的是映射到本地主机物理地址空间中的远程主机的内存， 它可以让在同一 CXL Fabric 中的 Hosts 实现内存互访。这在一定程度上弥补了 CXL1.1/2.0 种非对称内存访问的短板（即只能实现 Host 与 Device 之间互访内存），结合设备之间的 P2P 内存访问，CXL 3.0+在形式上实现了对称的内存共享和互访。尽管在实现机理上有所不同：Host 与 Device 之间通过 CXL.mem 以及 CXL.cache, 而 Host 与 Host，Device 与 Device 之间通过 UIO（Unordered IO），但这种全域的内存共享能力，为当前内存受限的 AI 基础设施提供了很大的想象空间。

图 7. CXL Global Integrated Memory

CXL 在 AI 场景中的应用：

• 分层 KV Cache 缓存： 在用于大模型推理服务的集群中，由于需要同时服务多个用户，KVcache 的内存占用量非常庞大。如果单纯依赖 GPU 上的 HBM 或者 GDDR 来保存这些数据，整个 AI 推理系统会变得极其昂贵且效率低下，经济上不可持续。 利用 CXL 的内存池化，我们可以构建一个分层的 KV Cache 缓存体系： Host 经由 CXLSwitch 到 CXL 内存（e.g., Alimemory），CXL Storage Class Memory （e.g., AliSCM），乃至 CXL SSD（e.g., AliFlash）。在这基础上，利用 KV Cache 的访问热度，将 KV 值分配到不同的缓存层级中，可极大的缓解 KV Cache 在显存中的存储压力， 降低成本的同时又可提高 GPU 的运行效率。 

• Retrieval-Augumented Generation （RAG）向量数据库：为解决大模型推理受训练数据的时效限制的影响，最新主流的 ChatBot 服务以及主流的 LLM 推理框架都支持 RAG：依据输入的 Embedding，查询向量数据库，从而获取与输入相关度较高的最新上下文信息。由于 RAG 处在整个推理的关键路径上，因此提高向量数据库的查询性能将直接影响到推理系统的性能。这里，至少有两个途径 CXL 可以发挥作用：一种途径是，通过内存扩展或者池化，创建一个巨大的 Host 侧内存空间，这样整个向量数据库都可以常驻内存，变成 In-memory database，使得延时和吞吐上都优于基于 SSD 存储的向量数据库；另一个种途径是，利用存内计算（In-Memory Computing）或近存计算（Near-Storage Computing）将 RAG 所需要的 Approximate Nearest Neighbor Search (ANNS)卸载到 CXL 设备上，这样可以减少主机 CPU 和设备之间数据传输，进一步提升向量数据库查询效率。 

UAL：内存语义下的精简 Scale-Up 互连

严格意义上来说，Scale-up 是一个节点内扩展的概念：我们通常所说的单机 4 卡，单机 8 卡即属于该范畴。但是随着模型尺寸的不断增加，上下文的增长，即便是单机 16 卡也无法放下一个模型。那就只能将一个模型放在多个机子的多张卡上，这在 HPC 语境下是再自然不过事：将一个负载任务拆分成多个 Partition 分布到多个节点上，再通过 Message Passing 等方式进行节点间的同步和通信。 问题在于大模型和典型的 HPC 负载有着明显的不同： 典型的 HPC 负载通常存在通信本地性（Locality），比如，计算流体动力学（CFD）中，基本的通信模式是 3D Nearest Neighbor（A.K.A., 3D Stencil），即一个分区仅和它直接相邻的分区进行通信，这就从根本上避免了昂贵的 All-to-All 通信；而大模型负载又“大”又“紧”，“大”是指计算量大，对内存容量要求大，故需要多张 GPU 卡，需要做切分；“紧”是指负载内部通信的紧耦合，即便是对切分比较亲和的专家并行（Expert Parallelism）也存在 All-to-All 等密集数据通信（单次通信 GB 级别，且无法通过 overlapping 被隐藏）。因此，我们就有了这样的需求： 既要分布在多个物理节点上的多张 GPU 卡，又要求卡间通信与单个物理节点内的通信在性能上无明显区别，这就是所谓的超节点 Scale-up 网络。 

UAL 协议概览

要实现对 Scale-Up 网络的支持, UAL 需要： 

• 支持内存语义，避免 RDMA 中 Producer-consumer 编程模式所带来的 Doorbell/Interrupt 延时开销。

• 精简协议栈， 减少在协议处理链路上的延时。 

• 采用高速率串口， 支持通道聚合，以满足 scale-up 带宽要求。

• Time-to-Market，充分复用现有技术，降低研发复杂度，能够快速实现应用和部署，充分挖掘大模型推理爆发式增长带来的红利。 

图 8. UAL 协议框架

基于上述需求，UALink 定义了四层协议栈，包含了协议层（Protocol Layer），事务层（Transaction Layer），数据链路层（Data Link Layer）和物理层（Physical Layer）。

• 物理层： UALink 复用了 IEEE802.3dj 以太网的物理层，采用 224G SerDes 来实现 200Gb/s 的传输速率。在减少了协议 IP 设计成本的同时，又实现了远高于 PCIe Gen5/6 的传输速率。 这里考虑了 40Byte 前向纠错码（FEC）和 256B/257B 的信道编码所带来的带宽损耗。这一通道速率已经与 NVLink 5.0 齐平，相较于 CXL 带宽问题有了极大的缓解。此外，4 条这样的通道一起构成了一个 UALink Station，它可以是一个 x4 的 UALink 端口，也可以 bifurcate 成 2 个 x2，或者 4 个 x1 的端口。UALink 通过这样 4 通道汇集以及对 Bifucation 的支持兼顾了高带宽与连接的灵活性。  

• 为了实现内存语义互访，UALink 在协议层接口（UALink Protocol Layer Interface（UPLI））定义了四个逻辑信号通道，分别是：Request，Originator Data，Read Response/Data，Write Response。其中，请求通道（Request Channel）包含请求地址、请求类型（读取、写入、原子操作以及其他自定义命令）、请求长度、Source 标识符、Destination 标识符等；读取响应/数据通道（Read Response/Data Channel）最多可包含四个节拍，每拍的 64 字节，共 256 字节数据；写入响应通道（Write Response Channel）主要的任务是告知原写请求的完成状态， 因此它不包含数据。通过这些通道，UALink 实现了对 Load/Store 内存语义操作的原生支持。 

• 事务层要解决的问题是如何高效的将来自于协议层的请求打包成 TL Flit。在 UALink 中，每个 TL Flit 大小为 64 Byte，其中 0-31Byte 构成 Lower TL Half-Flit，32-63 Byte 构成 Upper TL Half-Flit。TL 数据以 Half-Flit 为单位进行打包，并且第一个 lower Half-Flit 用来存放控制信息，这样的设计极大的降低了包解析时的复杂度，减少了延时开销。 但是 32 字节的空间用来放置请求控制信息显然是绰绰有余。 如下图（a）所示，此时控制信息占据了 16Byte，剩余的 16byte 都为 NOP 信息；同时，由于 TL Flit 以 64 Byte 为一个整体，因此 4 号 Flit 在其 Upper TL Half-flit 用来填充载荷数据后，其 Lower Half-flit 绝大部份也被 NOP 占据， 仅有 4 个字节用于 Flow Control（FC）。 可见这样的打包方式带宽利用率较低低，因此就有了下图（b）这样，将两个写请求合在一起打包，这样就可以充分利用原本被 NOP 占据的 lower Half-flit。此外，我们还可以附带上两个与当前请求无关的 WriteResponse 请求，因为它不带有载荷数据。 但此时，算上 FC 信息后，还有共 8 个字节的空间被 NOP 占据，我们能否把这些闲置资源也利用起来呢？于是就有了下图（c）这种模式。这里我们打包了三个完整的写请求以及三个 Compressed Write Response （CWR），这样没有空间被 NOP 闲置。 问题是，我们还能进一步提升打包的效率吗？ 这就涉及到了请求信息压缩。请求信息中相当一部分为地址信息（e.g.，64-bit 地址信息），但是由于访问的时空本地化（Temporal-Spatial Locality），通常一段时间内只会访问一段邻近的地址空间。因此，如果在发送端和接收端做地址 Cache，我们就可以仅传输一小部分的地址位（通常是低地址位）并通过地址 Cache 重新构建完整的地址。在此基础上，再通过对请求信息的其他部分重新编码，就可以实现用 8 字节代表原先完整的 16 字节请求字段。这样，我们就可以实现如下图（d）所示的，对 5 个写请求和 5 个 CWR 的打包。 除了高效打包，TL 还负责基于 Credit 的流控管理，在 TL Flit 中的 FC 域就是用来传递 credit 信息的主要途径。具体来说，在链接初始化时，所有虚拟通道（Virtual Channel）上的发送方都会收到接收方的缓存 credit， 发送方据此设定对应的 Credit 计数器；每次发送端发送一个 TL flit, 发送端根据 TL Flit 的大小，降低 credit 计数器的值，而接收方在处理完相应 Flit，并从缓存中移除该 Flit，新释放的 credit 被接受方放入相应 Response Flit 的 FC 域中；发送方在收到 Response 后，根据 FC 中的信息增加 credit 计数。由于在 UPLI 的设计中，无论请求是读或写，都有相应的 Response，因此发送方的 credit 计数器都能得到及时更新。

图 9. TL Flit 的组织形式

• 数据链路层在功能上，将事务层的 TL Flits 打包成 640 字节的 DL Flit，或者将 DL Flit 解包多个 TL Flits。这 640 Byte 的 DL Flit 还包含了 4Byte 的 CRC 编码，3Byte 的 Flit Header 以及 5 Byte 的 Segment Header。由于要维持 TL Flit 的原子性（即，一个 TL Flit 不能被分割到不同的 DL Flit 上），一个 DL Flit 中包含 9 个 TL Flit，考虑到用于 CRC 和 Header 的 12 字节，还剩 52 字节空余。这部分剩余空间可以用来容纳 DL-to-DL 消息或者只做 Padding。数据链路层还需要支持 UALink 构建 Lossless 的 Scale-up 网络， 这也是为何需要有 CRC 的原因：用它来检测传输过程中是否出现了误码，并由此决定是否要启用链路层重传（Link-Level Retry）。支持重传也就意味着发送端需要保存发送出去的 DL Flit，直到它收到来自接收端相应的 ACK；但链路层支持重传所需的 Flit 缓存大小相较于端到端重传在源端的缓存小很多，实现复杂度也更低。这里有必要再提下物理层中加入的 40Byte FEC，你可能会问，既然已经有了 CRC，为什么还需要 FEC？这是因为这里 FEC 通过纠正物理链路上传输出现的错误减少了循环冗余校验出错的概率，从而也减少了重传的概率，毕竟纠错的效率远高于重传；但是，FEC 的纠错能力也是有限的，当误码率超过其纠错能力时，就由 CRC 兜底，通过重传来修复。另一方面，FEC 涵盖的错误发生在物理传输链路上，而 CRC 还能涵盖部分缓存逻辑电路上的软错误。 因此，这两者是相辅相成的。 

地址转换：同 NVLink 一样，UALink 通过 PGAS（Partitioned Global Address Space）编程模型将不同节点加速器上的内存组织起来构成一个全局统一的内存空间，实现基于地址的跨节点互访。这里就涉及到三个方面的地址： Gest Virtual Address (GVA)，即源端加速器上所运行程序生成的地址； Network Physical Address（NPA），即网络物理地址，其中的部分信息用于指导 UALink 交换机路由；System Physical Address（SPA），即远端加速器上的物理地址，它指向最终要访问的内存。 这三个地址之间存在 GVA 到 NPA 再到 SPA 的单向映射转换关系，其中 GVA 到 NPA 的转换由源端的 MMU 负责，而 NPA 到 SPA 的转换由 Link MMU 负责。当然，GVA 不一定指向远端的地址，也有可能也是本地的地址，这也由源端 MMU 来负责区别和翻译。 UALink 通过使用 10-bit ReqDstPhysAccID 来查找交换器内部的路由表来进行路由操作，因此 UALink 可以支持最多 1024 个节点；而这 10bit 的 ReqDstPhysAccID 通常是从 NPA 中提取或转换得到的。

图 10. UAL 地址转换

UAL 协议：探讨

UAL 尽管实现了内存语义，但是它不支持硬件层面的内存一致性。 这是因为一方面，选择硬件层面不支持内存一致性，可以显著降低协议复杂性和实现成本，也降低了协议的延时开销; 另一方面在 Scale-Up 域，面向 PGAS 的编程对跨 GPU 的内存一致性并没有刚性需求，因为计算时的数据是以“Share Nothing”的方式分布的，但是 GPU 内部也有 cache，如何保证 GPU 间通信时能拿到最新数据，就依赖于软件同步，比如显式的 Cache Flush，Invalidation 和 memory fence 等。 因此与 CXL 不同， UAL 选择了轻硬件，重软件的模式，这对于专注于 Scale-up 的新协议来说，是一个务实明智的选择。 就像 NVLink 2.0 才开始在硬件层面支持内存一致性一样， 不排除 UAL 在生态站稳后，开始支持硬件一致性。

当前的 UAL 版本有点像 CXL.mem，但是不同的是，UAL 协议上是 64-byte 寻址，而 CXL 是 byte-addressable 的。 基于 64-byte 的寻址是 AI 类负载在 Scale-up 域中访存行为特征的反应，能有效简化数据包的组织形式，提升带宽利用率；而 CXL 的细粒度访存能力为更加通用的场景提供了编程灵活性。 另一个不同点是： UAL 支持原生的原子操作指令，但 CXL.mem 并没有原生原子操作命令，它需要 CXL.cache 的参与才能支持原子操作。 当然最终，原子操作都是有赖于目标端设备来实现。

UAL 采用 Credit-based Flow Control 和 Link Level Retry 来实现链路的无损传输。这样可以快速从丢包中恢复，避免端到端重传带来的长尾延时, 这对于 AI 集群系统的性能至关重要。

UEC：再造以太

传统的以太网，尽管在广域网互连中取得了巨大的成功，但是在数据中心场景，尤其是面向 AI 和 HPC 应用的场景中，出现了水土不服，这在 RDMA 上显的尤为突出。尽管借助 ROCEv2，RDMA 在数据中心得到了广泛的应用，但它依然面临着不少问题和挑战[4]，比如：

• RDMA 网络规模扩展性问题。RDMA 所依赖的 Queue Pair 配置是在 RDMA 环境初始化时设置完成的。尽管这种控制面和数据面分离的方式有它天然的好处，即在进行数据面操作时，无需考虑控制面，从而达到极高的传输效率，但这也意味着，初始化时需要将所有可能的 QP 都分配好。由于任意两个节点间的每个进程对都需要一个 QP，对于一个 N 个节点，每个节点有 P 个进程参与通信的系统，这意味着整个系统需要分配 P*P*（N-1）个 QP。而对于一个 scale-out 训练用集群，这个 N 可能会达到几万到数十万。考虑到一个连接状态信息可能多大 1KB， 显然，要维持这样规模数量的 QP，对硬件来说极为昂贵。

• 在一个有损（Lossy）网络上构建 RDMA 的天然缺陷问题。传统以太网是一个有损网络，没有链路层重传(LLR)，所有的重传都要通过端到端的传输层协议来实现，这一设计理念在广域网中是一个极具智慧的选择。它一方面降低了网卡和交换机的硬件成本，提升了网络规模扩展的效率；另一方面， 它也是一种高效的错误隔离手段，避免了因为硬件缺陷结合链路层重传而导致的错误扩散。但是 RDMA 要构建在无损网络之上，为了支持数据中心 RDMA，RoCEv2 通过三层的 ECN（Explicit Congestion Notification）和 CNP（Congestion Notification Package）再结合二层的 PFC（Priority Flow Control）构成的 DCQCN 来创建处一个近乎无损的网络。这是一个复杂的，混合了二层/三层的技术组合，带着浓浓的应对先天不足的无奈。 

因此，在面向 AI 和 HPC 负载的场景中，我们需要一个从头重新思考和构建的新以太，而不是在原有协议上的修修补补。

UEC 协议概览：

UEC 依然采用传统以太网的四层协议架构，但是在数据链路层加入了 Credit-based Flow Control 以及链路层重传的支持，实现了原生的无损网络，并对传输层做了根本上的重构，通过定义 Semantics Sublayer（SES），Packet Delivery Sublayer（PDS），Congestion Management Sublayer（CMS），以及 Transport Security Sublayer（TSS）四个子层，实现了对上层语义，短时连接，多路径，拥塞控制，传输安全等方面的支持。 

图 11. UE 整体架构图（Source:[2]）

短时连接（Ephemeral Connection）：为应对 RDMA 网络规模扩展性的问题，UEC 重新构建了 QP 的配置方式。它基于这样一个观察：一个节点不可能同时与所有其他节点及进程通信， 即便像是 All-to-all 这样的集合通信，它也是分解成点对点通信以一定的顺序完成（e.g.，Recursive-Doubling 算法）。因此，从一开始就为每个节点设置所有可能的 QP 其实是一种保守的资源 over provisioning。 一种更为高效的做法是预留少量的 QP 资源池，在实际通信时动态的复用和释放这些 QP 资源，这就是 Ephemeral Connection 的核心想法。具体来说，UEC 在 PDS 子层中定义了 Packet Delivery Context（PDC），这是一个动态创建的为连接提供上下文的逻辑结构，与它相关联的信息包含：Job_ID, source Fabric Address, destination Fabric Address, Resource Index, Traffic Class 等。 下图展示了短时链接构建的流程： 当源端发起连接的首个包时，它将源端的 PDC ID 和它期望目的端分配的 Context 信息放入包头，并将 SYN 设为 1；当目的地端收到这些 PDS 请求包时， 由于 SYN=1，它将检查相关连接是否已经建立；若没有，它分配一个 PDCID 并从相应的资源池中获取与之相关联的缓存资源，其中在 PDC 中 Resource Index，可以被看作是指向缓存队列的指针；之后，目的地端将新分配的 PCD ID 通过 ACK 返回给源端；源端收到 ACK 后，后续的 PDS 请求中 DPDCID 被设为目的地新分配的 PCDID，同时 SYN 被置为 0；至此，连接构建完成。可以看到，短时连接的建立过程极为高效，它和数据传输是同步进行的。

图 12. 短时链接构建流程

多路径（Multipath）和包喷洒（Packet Spray）: 传统的 ECMP（Equal-Cost Multi-Path）是面向基于五元组（源和目的地址、源和目的端口，以及协议类型）定义的流。不同的流会被哈希到不同的路径上， 但同一个流中的所有数据包都沿同一条确定性路径转发。显然，对于 AI 场景中常见的大象流，这种方式并不能充分利用多路径带来的带宽。因此，在 UEC 中， 多路径的对象成了数据包，使得同一个 flow 中的不同数据包也可以走不同的路径。为达到这一目的， UE 在 UET 包头中引入了一些随机机制或者 Entropy，并参与到选择路径的哈希中。具体来说，当 UEC 使用 UDP 封装时，随机生成的 UDP 源端口被用作 Entropy。这是因为 UDP 中，一般发送方不期望得到接受方的回复，因此源端口通常是可选的，UEC 利用了这一点，将随机性注入数据包头中。若 UEC 不使用 UDP 封装而是仅采用 IP 封装，那么，就必须使用 UET Entropy Value（EV），作为 PDS 包头的一部分。网络节点可以通过选择不同的 EV，让每个数据包经过不同路径发送；也可以对数据包使用相同 EV，确保它们能够按序交付。

乱序包交付，顺序消息交付（Out-of-Order Packet Delivery with In-order Message Delivery）：在使用多路径和包喷洒的情况下，必然出现数据包的乱序到达。好在包括 AI/ML 类负载在内的大部分应用并不关注数据包到达的顺序，只关注消息到达的顺序。但也有些应用需要 In-order Packet Delivery，比如一些 Legacy 的 HPC 应用，网络入侵检测系统等。为此，UEC 定义了可靠无序交付模式（Reliable Unordered Delivery，RUD），不可靠无序交付模式（Unreliable Unordered Delivery, UUD），可靠有序交付（Reliable Ordered Delivery，ROD)，以及幂等可靠无序交付 （Reliable Unordered Delivery for Idempotent Operations，RUDI) 四种模式，来应对各种场景需求。 其中 RUD 是 UEC 默认的传输模式，它充分利用了多路径带来的高带宽利用率，结合 RDMA 所带来的 Direct Data Placement，让数据包直接放入应用的内存空间中，避免了 NIC 缓存中转。为确保消息的顺序交付， 每个消息都关连一个 ID（Message ID，MID），每发送/接收一个消息都会在本地递增该消息 ID。这样，若一个消息的数据包都到达，但是它的 ID 大于当前预期的 ID，该消息就被 Hold 住，直到前面的所有消息完成交付。 在这种模式下，若出现丢包现象，则采用选择性重传（Selective Retransmission）以实现高效的丢包恢复。 而 ROD 模式禁用了包喷洒，确保数据包能够顺序到达， 并采用传统的 Go-Back-N 重传的方式应对可能出现的丢包情况。 

拥塞控制: UEC 的拥塞控制主要承载在 CMS 上。它定义了两个互补的拥塞控制算法：一个是主要运行在发送端的基于网络信号拥塞控制（Network Signal-based Congestion Control，NSCC）；另一个是主要运行在接收端的基于接受端信用拥塞控制（ Receiver Credit-based Congestion Control，RCCC）。 它们可以单独使用，也可以一起使用。 

• NSCC 综合考虑两个网络指标： ECN 标识和 Round-Trip Time（RTT）。与传统的 DCQCN 不同， ECN 标识的拥塞信息不是通过 CNP 包反馈给源端，而是通过 ACK 包头上的 Congestion Control（CC）State 域来传递的，从这层意义上来说，它和 DCTCP 相似。不同的是，NSCC 还综合考虑 RTT，而 RTT 的测量是基于时间戳（Timestamp）来实现的：发送端会记录发送 PDS 请求的时间戳，同时也会记录对应 ACK 到达发送端的时间戳，两者的差再减去 ACK 包在接收端生成的时间，就是 RTT 较为精确的测量值。于是，我们就有了是否有 ECN 标识以及 RTT 高低所构成的四种不同状态组合，NSCC 将根据这些状态组合来调整发送窗口的大小，从而实现拥塞控制。  

• RCCC 通过以 Credit 表示的接收端可用缓冲区大小来做拥塞控制。从大的方面来讲， RCCC 的控制机制和传统的基于 Credit 拥塞控制方式差别不大：都是在发送端和接收端都维持 Credit Counter，在发送端每发送一个数据包，相应的 credit 计数器减一，当 credit 计数器到零时，发送端暂停发送数据包；当它收到来自于接收端的 Credit 更新（包含在 ACK 报文中）， 相应的 Credit 计数器将增加相应的量。 那么，发送端是如何在一开始知道接收端 Credit 数量的呢？这就是 RCCC 和传统的基于握手方式不同之处：RCCC 一开始通过一个小的“Eager Window”发送数据包，这个窗足够小，确保接收端不会出现 credit 耗尽的情况，同时，利用这期间的 ACK，发送端就可以知道接收端的 Credit 数量。

安全: UEC 专门强调了数据传输安全并由 TSS 来承载, 解决了传统 RDMA 网络上没有原生加密支持，依赖于 IPsec，性能开销大的问题。  TSS 可以有选择性的对 PDS 包头（不包含 Entropy 域）和 Payload 数据进行加密。这里我们介绍两点 UEC 的安全特性：

• 密钥分发：由于面向 AI 的负载，来自于一个租户的任务需要大量节点共同参与，如果采用传统的点对点密钥的方式，那么系统就要分发和管理 Nx(N-1) 份密钥，这不仅带来了高昂的密钥分发成本，而且也因管理密钥造成了不小的性能开销。事实上，这种点对点的加密对于一个租户来说没有必要。因此 TSS 定义了一个 Secure Domain（SD），所有在这个 SD 内的节点都共享相同的 Secure Domain Key（SDK）。 这个 SDK 通过安全的带外通道分享给所有 SD 节点。 每个节点上，TSS 采用 Key Derivation Function (KDF)，结合每个工作任务的 Session，从 SDK 中推演出相应的密钥。这样每个 Session，所有节点都有相同的密钥，不同 session 的密钥不同，而且也避免了每次 Session 密钥分发的开销。

• 重放攻击（Replay Attack）的防护机制。所谓 Replay 攻击，是指攻击方通过劫持或拷贝原通信数据包，然后向目的地重新发送这些数据包，使系统在未经用户授权的情况下，让系统重复之前的操作。由于 PDS 连接本质是无状态的，因此在建立 PDS 的时候，如果可以接受任意起始的 Package Sequence Number（PSN），UEC 系统就容易受到 Replay 攻击。为此，TSS 在一个 SD 中保留了 start_psn 和 expected_psn。当接收端收到的连接请求中 PSN 小于 expected_psn，接收端会生成一个 NACK，指示应使用的起始 PSN；否则，该请求将被接受。当 PDC 关闭时，目标端的 expected_psn 会被更新为该 PDC 的当前 PSN+1。这样当 Replay 攻击者发送之前的包文时， 由于报文的 PSN 小于 expected_psn，因此该报文不会被接受，从而避免了重放攻击。新的 expected_psn 值会作为关闭 PDC 确认（ACK）的一部分返回给源端，源端随后将 start_psn 更新为此值，以确保后续连接可以以零往返时间建立。

UEC 协议：探讨

综上，可以看到 UEC 是对传统以太网在数据中心中应用的经验提炼，对 RDMA 网络所面临问题的全面思考，并在此基础之上提供了一个崭新的网络基座。 很多传统以太网在数据中心中遇到的问题将不复存在。 

和 UAL 一样，UEC 也通过 CBFC 和 LLR，实现了链路层的无损传输，这充分响应了大规模 AI 集群在长尾延时方面的诉求。同时，对可能出现的失效因 LLR 的扩散问题，在数据中心的高可观察/高可控环境下，有多种技术和手段予以应对。

UEC 所面对的 Scale-out 网络规模大约在万卡到数十万卡量级。 这样的规模决定了其通信时延的量级，进而决定了 UEC 必然要采用面向连接的消息语义，而非面向内存的 LD/ST 语义。 面向连接的消息语义意味着有消息准备和消息到达通知等开销，通信粒度较大，时延较长，但是它可以在程序层面通过异步非阻塞（non-blocking）通信机制让计算隐藏一部分的通信延时；而面向内存的 LD/ST 语义则意味着更细的通信粒度（Cacheline 级别），更短的延时（数百纳秒内），在 GPU 上，Load 延时隐藏通常通过 Warp 的快速切换来实现。这两种截然不同的机制决定了 Scale-out 网络和 Scale-up 网络存在着清晰的边界。Scale-Up 网络无法支撑起 Scale-out 网络的规模；反过来， Scale-out 网络也无法实现 Scale-up 网络的性能。 

竞合的互连江湖

Scale-up Ethernet (SUE)： 何方神圣？

如果你了解 UALink 的成立过程， 你会发现博通一开始是在创始成员名单中，但后来并不在董事会成员中，而是自立门户，拉起了一杆 SUE 的大旗。 这里就有两个问题： 首先 SUE 是个啥？根据博通在 25 年 7 月发布的"33 页"SUE 规范，我们可以发现 SUE 和 UAL 有着诸多相似之处：都采用 200G 以太网的 PHY，都支持 LLR 和 CBFC，都支持内存语义, 支持的超节点规模都是 1024 个。 但技术上，两者最根本的区别在对数据的封装上。UAL 定义了全新的传输层和数据链路层的封装格式，其中传输层的包头包含了内存操作类型，支持原生的内存语义；而 SUE 要么采用传统的 UDP+IP+以太网包头封装，要么采用 AI Forwarding Header Gen 1/2 格式的封装，如下图所示。 SUE 上内存操作请求被放在 SUE Payload 中，发送到对端。可以看到，SUE 的封装沿用了很多传统以太网的做法，相较于 UAL 复杂度更高，链路所需的延时也更高，大约比 UAL 多出数百纳秒。

图 13. SUE 的几种数据打包格式

那么，博通为什么弃 UAL 而推 SUE？ 这得从另一方面的信息来解读: 几乎在发布 SUE 规范的同时， 博通就发布了支持 SUE 的 Tomhawk Ultra Switch 芯片，并且和 Tomhawk 5.0 实现了 Pin 脚兼容。这说明，博通在 SUE 上已经在背后耕耘了很久。起初推动 UAL 成立的目的大概率是看看能否将 SUE 的这套规范推进到 UAL，从而以近乎零成本占据 Scale-up 互连的最佳生态位。但在 UAL 坚持从头设计精简的封装模式后，如果还留在 UAL，那反而成了后续 SUE 产品的反向宣传，不如退出。那么，博通为什么选择 SUE 这条路线呢？我们推断这是因为它在以太网交换机上有太多的利益。在以太网基础上进行轻量化改造，能够实现快速 time-to-market， 先下手为强，抢到 Scale-up 互连的蛋糕， 不香么？ 相比之下，最早支持 UAL 的芯片或交换机可能要等到 2026 年年末。 

我们乐见博通能从 NVLink 虎口夺食， 但不认为 SUE 是 Scale-Up 协议发展的趋势。 如前所述，一个好的 Scale-Up 协议必须是延时导向的，内存语义原生的精简协议，才能解决 Scale-Up 网络的需求。而 SUE 复用了不少以太网的封装模式，看起来更多的是一个产品策略。虽然博通声称 SUE 是开放标准，谁都可以使用，但是相比 UAL 标准的 253 页和 UEC 的 563 页，SUE 这 33 页规范，像是个产品说明书，多少让人感觉少了些诚意。

Scale-up 域，何处是边界？

Scale-up 域的大小根本上由两个因素决定：模型的大小和 GPU 算力及显存大小。模型的大小主要由两方面决定：静态的模型参数规模和动态的内存 KV Cache。 下图（a）展示了 QWen 系列模型的大小。可以看到，突破模型大小边界的任务还是由语言类大模型来承担，其他各种专项或者多模态模型明显小于同代次 LLM 模型参数规模。但是即便是 LLM，它模型参数的增长已经过了爆发式增长期，开始逐渐减缓。这背后一个更深层次的原因是，用来训练的数据已经接近人类产生的公开文本数据的上限，如下图（b）所示。 这在某种程度上也解释了为何当前 Pre-training Scaling 逐渐变缓。但也是因为随着 scaling 的重心转移到 test-time scaling 上， 长上下文所带来的 KV cache 的内存需求迅速增加，对内存容量的需求甚至超过了模型参数。 但为了应对 KVCache 对内存容量的挑战，业界也有大量的针对 KVcache 的量化，压缩，和注意力稀疏化的工作，来减少 KVcache 的增加对内存容量和性能的影响。 所以，综合来看，我们的判断是大模型对内存容量的需求在未来还会持续增长，但是增长速度会明显放缓。 

（a）

（b）

图 14. (a)通义大模型参数规模；(b) LLM 训练用数据 vs 人类产生的数据 [5]。 

接着，我们再来看 GPU 算力/显存密度。下表展示了 NVIDIA 和华为的 GPU/NPU 产品线在算力和显存容量上的对比。 可以看到，NVIDIA 的单位 GPU 的 FP4 算力几乎以每年两倍的速度在增长，而显存容量在 Rubin Ultra 这一代比之前增加到近 4 倍。相比之下华为的昇腾系列，虽然算力也以每年两倍左右的速度在增长，但由于起点较低，在算力密度上和 NV 产品线保持着大约 25 倍的差距。显存容量方面， 昇腾 960 和 Rubin 相仿，但是与 Rubin Ultra 相比也差了 4 倍。 虽然国内还有众多其他的 GPU 生产商， 但这些差距基本反映了当前国内在半导体制程，HBM，以及先进封装方面整体落后于美国的现状。

表 2. 两家 GPU 产品线的算力和显存对比

基于这样的现状和地缘政治，我们可以推断中美两国 AI 集群将呈现两种不同的形态：美式 AI 集群，由于单卡算力和显存密度高，其 Scale-up 域会尽量锚定在一个机柜内，毕竟这样 Scale-up 域无需经过多级交换机，整体通信延时是最优的。尽管 NVIDIA 将推出 Vera Rubin CPX Dual Rack 产品，但这是一种 PD 分离的组织方案, 两个机柜并不在一个 Scale-up 域：Rubin CPX 机柜专用于 Prefill，通过 InfiniBand 或 Ethernet 与 VR NVL144 机柜相连。国内的 AI 集群，由于单卡算力密度和显存密度较低，其 Scale-up 域必然比美式集群的 Scale-up 域大。一个典型的例子就是华为的 CloudMatrix384 [6]，它有 16 个机柜，其中 12 个用于计算，4 个用于互连交换；384 个 NPU 被分配到 48 个计算节点中，每个计算节点含 8 个 NPU；所有 NPU 通过两级 UB（Unified Bus）交换机连接，其中，一级交换机在计算节点内部，一级和二级交换机间通过 LPO（Linear Pluggbale Optics）互连。两级交换可以支撑更大规模的 Scale-Up 域，384NPU 处理器显然不是它能达到的上限。因此，我们预计 Scale-up 集群规模会经历扩大再收缩的过程： 规模扩大是因为当前国产单卡的算力和内存密度演进速度还未赶上大模型的发展速度，扩展超节点规模是最直接的应对方式；但是随着单卡算力和内存密度的快速提升，系统对互连延时的敏感性也迅速增加，过长的延时将使集群算力利用率迅速下降，因此像 CloudMatrix384 这样的两级交换超节点架构，必然要回归到单级交换，单机柜超节点的形态。 这必然对机柜的高密度架构设计，供电和散热都提出了巨大挑战。从这层意义上来说说， 单机柜的硬件工程能力（高密，供电，散热）决定了超节点规模的边界。 阿里云在这一领域也走在业界的最前沿。

CXL 能否王者归来？

在 2021-2022 年，CXL 几乎统一了包含 GenZ，OpenCAPI，CCIX 在内的主要服务器级内存一致性互连，风头盛极一时。但随着 LLM 大模型的兴起，大量的资本被吸引到 AI 基础设施的建设上，CXL 领域的投入因为无法看到短期收益而大幅减少，其发展从聚光灯下，移到了幕后。但是 CXL 标准并没有停止演进，自从 CXL 3.1 推出 GIM 之后，CXL 就开始摆脱非对称内存访问的标签。从功能上来讲， CXL 具备了 UAL 的几个关键特性：内存语义，设备间内存互访；此外，它还具有 UAL 不具备的特性，比如，Host 和设备的统一编址（UMA）以及通过 CXL 交换机的 GPU 资源池化，前者可以为推理系统提供更加庞大且相对廉价的内存，而后者则为节点的 GPU Scale-Up 提供了另外一种技术路径。 但是不幸的是，PCIe 的速率问题严重影响了 CXL 潜力的发挥：当前主流的 PCIe Gen5 的速率才达到 32GT/s，而 PCIe Gen 8 虽然速率将达到 256GT/s，其 x4 的带宽和 UAL 1.0 的 x4 带宽基本持平，但是它要到 2028 年才可能有相应的 IP，而要被集成到 GPU 中，则需要等待更长的时间。 这里的有两个问题需要回答： 

• GPU 集成 CXL 的动因是什么？由于 GPU 是以 PCIe 设备的形式呈现给操作系统的，因此 GPU 上必须要集成 PCIe 接口。即便是像 GB200 那样，CPU 和 GPU 之间通过 NVLink-C2C 相连，它们之间也需有一个 x1 的 PCIe 通道来做 GPU 的枚举和设备配置等控制面的工作，而 NVLink-C2C 则负责数据面的数据搬移工作。但这是 NVIDIA 的专属方案，在开放世界中，最主要的方式依然是采用 PCIe 来同步承接控制面和数据面的工作，并且常以 x16 的端口形态出现，以满足 CUDA Kernel Launch 时数据搬移所需带宽。但除此以外，在 AI 集群中，GPU 的 PCIe 端口带宽利用率很低，这其实是一个不小的浪费。而当 PCIe 演进到 Gen7/8，在这之上的 CXL 一方面提供了与 UAL 相近的带宽，另一方面也实现了 Host 和 GPU 的 UMA，两者结合可以极大的改善带宽利用率。相对于 PCIe，它不增加额外引脚数，不会对芯片紧张的 IO Pad 面积增加额外的压力。这里面的巨大正收益将驱使非 NVIDIA 的 GPU 集成 CXL，使它们与 NVIDIA GPU 在 UMA 上处在同一水位上。

• 对于集成 CXL 的 GPU，其集群的组织形态有什么变化？像 GB200 那样，Host CPU 和 GPU 之间的直连是利用 CXL-enabled GPU 的最直接的方式。此时由于 CPU 引脚资源受限，同时又要预留较多引脚给 DDR 内存，因此单个 CPU 直连的 GPU 数目较少，CXL 在这里的作用就是构建 Host 与 GPU 之间的 UMA。但 CXL 还提供了另外一种集群组织形态：GPU 通过 CXL 3.1 Switch 连到 CPU。此时，CPU 与挂载在 Switch 上的各个 GPU 之间构成统一的内存空间；同时，GPU 与 GPU 之间通过 CXL Switch 实现点对点通信。 由于 CXL 的 P2P 通信地址分配和 UAL 的地址分配存在冲突，因此，在采用 CXL Switch 后，GPU 就只能通过它来构成 Scale-Up 域。该 Scale-Up 域的 GPU 数量取决于 CXL Switch 的端口数量，64 或 32 是一个可以实现的配置（当然，可以通过两级交换机的方式实现单个 Scale-Up 域更多的 GPU 数量支持，但访存延时将增加）。而 Scale-Out 通信则通过挂载在同一个 CXL Switch 上的多张网卡来实现。与现有超节点集群不同，这个组织架构一定程度上回归了传统基于 PCIe 交换机的集群构建模式，但因为 CXL，也具有了一些令人期待的特性：通过 CXL Switch，它提供了更加灵活的 CPU-GPU 配比；通过 CXL Memory，提供了更加灵活和低成本的内存扩展等。我们认为这是一个值得探索的方向，当然也有赖于整个 CXL 上下游生态的共同努力。诺能成, 则是 CXL 的高光时刻，我们拭目以待。 

结语

过去几年，大模型的爆发式发展对 AI 基础设施提出了巨大的需求，我们见证了私有互连的春天：那些具有完整芯片产品线且积极布局互连技术的公司，比如 NVIDIA（NVLink），AMD（Infinity-Fabric），以及华为（Unified Bus），是最先吃到这波 AI 基建浪潮红利的玩家。 而开放互连的春天要来的晚一些：UAL 和 UEC 相应的产品落地可能需要到 26 年年底。好在整个行业已经通过 UCIe/CXL/UAL/UEC 构建起了一个从芯粒互连到 Scale-Out 互连的完整技术路图。 或许感受到了来自于开放互连的压力，NVIDIA 也开始尝试 NVLink IP 授权的商业模式，结合近期 Intel 和 NVIDIA 的合作，不难想象在不久的将来，我们可能会看到在 x86 CPU 通过 NVLink 与 NV GPU 相连的服务器产品。这反过来把压力传递到了开放互连这边。 这是“独行快，众行远”的生动展现；我们也希望通过私有和开放的相互竞争，彼此成就，推动互连技术的发展，最终实现 AI 的普惠。

参考文献

[1]. Yiren Zhao, Ran Shu, and Yongqiang Xiong. 2025. SRC: A Scalable Reliable Connection for RDMA with Decoupled QPs and Connections. In Proceedings of the 9th Asia-Pacific Workshop on Networking (APNET '25). Association for Computing Machinery, New York, NY, USA, 44–50. https://doi.org/10.1145/3735358.3735366

[2]. Hoefler T, Schramm K, Spada E, Underwood K, Alexander C, Alverson B, Bottorff P, Caulfield A, Handley M, Huang C, Raiciu C. Ultra Ethernet's Design Principles and Architectural Innovations. arXiv preprint arXiv:2508.08906. 2025 Aug 12.

[3]. Wu, X., 2025. Sailing by the Stars: A Survey on Reward Models and Learning Strategies for Learning from Rewards. arXiv preprint arXiv:2505.02686.

[4]. Hoefler, Torsten, Duncan Roweth, Keith Underwood, Bob Alverson, Mark Griswold, Vahid Tabatabaee, Mohan Kalkunte et al. "Datacenter ethernet and rdma: Issues at hyperscale." arXiv preprint arXiv:2302.03337 (2023).

[5]. https://epoch.ai/blog/will-we-run-out-of-data-limits-of-llm-scaling-based-on-human-generated-data

[6]. Zuo, P., Lin, H., Deng, J., Zou, N., Yang, X., Diao, Y., Gao, W., Xu, K., Chen, Z., Lu, S. and Qiu, Z., 2025. Serving Large Language Models on Huawei CloudMatrix384. arXiv preprint arXiv:2506.12708.

[7]. https://01.me/en/2023/09/towards-compute-native-networking/