摘要

AI大模型参数规模指数级增长，Scale-up网络作为AI超节点内计算加速器高速互联的专用架构应运而生，成为支撑大规模AI训练与推理的核心基础。本文深入研究超节点与传统计算集群的核心差异，系统分析超节点对Scale-up网络提出的六大核心特性要求，以及协议栈精简、全硬件卸载等协议实现关键技术，对主流协议的技术特点与性能进行对比。同时，通过系统分析当前Scale-up网络存在生态孤立、故障域扩大、容错能力不足等问题，展望了其性能升级、生态开放等发展趋势，并提出理想协议需具备开放兼容、低时延高带宽等核心特征，为技术研发与应用提供参考。

关键词

Scale-up网络；AI超节点；算力互联；内存语义；高速互联协议；无损传输

引言

Scale-up网络是用于超节点内实现高密度计算加速器（GPU/TPU/XPU/DPU）高速互联的专用网络架构，其构建的超节点是支撑万卡级AI训练、低延迟推理的核心基础设施，区别于数据中心集群内Scale-out横向扩展。

理想Scale-up网络通过高带宽、低时延、强一致性的互联设计，设法减少计算核心等待数据的消耗，消除多设备协同计算的通信瓶颈。在大语言模型（LLM）参数规模突破万亿、推理响应要求毫秒级的当下，Scale-up网络已成为AI算力节点协同的神经中枢，其技术特性直接决定模型训练效率与推理服务质量。

1 AI 超节点对Scale-up网络的核心特性要求

1.1 超节点的起源和定义

超节点（SuperPod）需求源于AI大模型参数规模指数级增长带来的算力与互联瓶颈。传统分布式集群存在算力分散、互联带宽不足、通信延迟高等限制，难以支撑千亿至万亿参数模型的高效训练与推理，以及超算任务的大规模并行计算需求。

解决这些痛点，需要单台具备足够算力和内存及访存带宽的超级计算机，在其内部实现全局统一编址与高效数据共享，满足张量并行、专家并行等计算模式对跨设备数据同步的低时延（百纳秒级）、高带宽（TB/s量级）需求，同时通过硬件资源池化、统一管理降低大规模算力协同的复杂度，避免数据冗余拷贝与通信拥堵。

传统单服务器CPU/GPU提供的能力，和上述希望的超级计算机差距甚远。解决方案是构造一台由数十至数百、千张GPU/NPU、专用互联芯片（如NVSwitch）、高速链路及统一管理系统组成的虚拟计算机。该计算机可能由多个机框或机架组成，通过Scale-up网络架构打破传统单服务器的硬件边界，将分散的计算单元以低时延、高带宽的专用互联技术紧密耦合，实现全局统一内存编址、资源池化管理与协同调度，对外呈现“单一计算实体”的特性，即超节点（SuperPod）。用户使用超节点时，无需感知底层硬件的分布式部署，可像操作单台计算机一样分配算力、调度任务、访问共享资源，底层的互联优化、故障隔离、负载均衡等复杂逻辑均由固件、专用管理器（如FM）等自动完成，最终以一体化的算力输出，支撑大规模AI训练与超算任务。

英伟达最早定义了超节点，其特征为节点内部处理器（GPU/CPU）通过Scale-up网络互联，处于同一个HBD（High Bandwidth Domain，超带宽域）。该定义目前仍然具有现实意义。

表1集群和超节点主要差异

上述的HBD域包含了软硬件两个层面，在硬件互联层面，超节点HBD域内采用NVLink、UALink等专用Scale-up互连协议，在加速卡（GPU/NPU）之间构建了高带宽、低延迟的通信域HBD。解决了传统架构中GPU间通信必须经由CPU/PCIe总线的通信瓶颈，为海量数据并行处理奠定了物理基础。在软件与系统层面，HBD内的计算节点资源管理也有所改变，计算节点能直接通过内存地址空间访问HBD内的内存地址，计算节点间的高速通信通常直接绕过OS内核协议栈，使用专用硬件完成数据读写，显著降低通信开销。

目前市场上出现近10种用于超节点的Scale-up协议，基本情况如表2。

表2 主要Scal e-up协议及发起者

1.2 Scale-up网络核心诉求

Scale-up网络是超节点实现计算单元紧密耦合、满足低时延高带宽数据同步需求、对外呈现“单一虚拟计算机”特性的核心通信支撑，是超节点架构的骨骼和神经网络。Scale-up网络的核心要求围绕如下6点展开：点对点无阻塞高带宽；内存语义访问的统一空间；微秒级时延，纳秒级抖动；高可靠性；拓扑适配；兼容性与生态。

1）点对点无阻塞高带宽：TB级带宽，线性扩展

AI训练中，梯度同步、参数聚合等操作需高频传输PB级张量数据，要求Scale-up网络具备如下能力。

a）高带宽链路

链路带宽达200GB/s以上，使用112GT/s或224GT/s的SerDes成为常态，448GT/s的高速SerDes技术也逐步成熟，多组SerDes组成一条高速互联链路。芯片集成的链路数量和SerDes速率直接决定了芯片外联的总带宽。如下图GB300，片上总共使用36对（18 port）224G SerDes，使片上总双向带宽达到1.8TB/s。

图 1 B3 00带宽达到1.8TB/s

随着芯片制程不断进步，SerDes速率已由56G→ 112G→224G。OIF（光互连论坛）正在联合UALink（超加速器链路联盟）、UEC（Ultra Ethernet Consortium，超以太网联盟）、SNIA（torageNetworking IndustryAssociation，存储网络行业协会）、OCP（OpenComputeProject，开放计算项目）和IEEE 802.3等组织，积极制定开放的448G SerDes标准，有望在2026-2027年形成标准落地。

图 2 NVLi nk 片上带宽迅速增长

b）总带宽线性扩展

Scale-up域内互联GPU数量增加时，要求总带宽近于线性扩展，基本实现无损耗扩展。所以Scale-up网络普遍采用全互联或胖树拓扑，以保证HBD域内无通信瓶颈存在，确保实现：域内互联总带宽≈N（加速器数量）×单加速器带宽。如NVIDIA GB200 NVL72 服务器的 HBD 域包含72个B200GPU，每个B200有18个NVLINK Port，9个Switch Tray刚好共计18颗NVLINK Switch 芯片，因此每个B200的Port连接一个NVSwitch芯片，累计整个系统单个NVSwitch有72个Port，故整个机器刚好构成NVL72，把72颗B200芯片全部连接起来。通过 NVSwitch 胖树拓扑实现二层无收敛互联，域内总带宽为72×1.8≈129.6 TB/s，其宣传口径取整为130 TB/s。

图3 英伟达NVL72内部拓扑

c）链路灵活配置

和PCIe类似，Scale-up网络普遍支持灵活的链路配置，即一条链路（Link）可支持多种Lane数量的组合（x1,x2,x4等）。自CXL3.0改进后的CXL4.0协议（2025.11发布），除Serdes速率翻倍达到128GT/s，也突破原3.0协议和PCIe的最大Lane数量（16）限制，通过捆绑端口技术可实现点对点>16lane的带宽无缝倍增。 UALink支持以1、2、4lane为一个Link的组合（定义4 lane为一Station，一芯片可以有多个Station）。UB的链路支持1、2、4、8lane组合，同时还可以支持收发不对称的Lane组合。即发送与接收方的Lane数不同，例如TX x8 + RX x4、TX x2 + RX x8等。此灵活配置用于支持双向带宽要求差异化需求（如数据单向传输场景）。

一般情况下，x1/x2组合适用于低带宽需求场景，x4/x8等适用于高带宽场景（如加速器、存储设备互联），可根据连接要求进行组合调整。

2）内存语义：统一空间、Cache一致性

统一编址下的内存语义是超节点共享内存的基础，而硬件级Cache一致性是提升多设备共享内存效率的关键能力：

a）空间统一编址，支持原生内存语义

HBD域内空间统一编址，原生支持Load/Store、原子操作等内存级指令，域内GPU可直接访问远端GPU/CPU的显存/内存，省去传统消息机制（如RDMA）使用的 “数据拷贝 - 封装 - 传输 - 解封装 - 拷贝”的中间环节，大幅降低跨设备数据交互延迟及提升了访问效率。

如使用协议转换等方式实现内存语义，则失去了内存语义访问的高效优势。原生支持Load/Store内存指令，非常有利于通过GPU缓存预取机制，即将后续需要处理的数据或指令提前读入到缓存，遮蔽单纯的数据读写过程，提升GPU运行效率。

统一空间也简化了软件开发难度，开发者无需关注数据分发、缓存同步、地址映射等底层细节，可按单节点模型开发并行软件，降低多设备协同的代码复杂度。

图 4 UALink通过MMU进行地址转换，实现全局访问

说明：

·跨Switch访问对端内存，使用GVA（Guest Virtual Address）地址发起访问。

·GVA地址经本地MMU转换为网络物理地址（NPA，NetWork PhysicalAddress）。

·NPA地址在对端MMU转换为本地系统物理地址（SPA，System Physical Address）。

·可优化方案统一全局编址，省略地址转换过程。

b）Cache一致性支持

超节点支持Cache一致性，可让域内多处理器（如 GPU/NPU）直接高效共享数据，无需手动处理数据拷贝与同步，大幅降低跨设备数据交互延迟、提升算力协同效率，简化多设备并行软件的开发复杂度。CXL 3.0/4.0 可实现全一致性多主机间内存池共享；NVLink 5.0 支持 GPU 与 Grace CPU 的 C2C 全一致性互联，UALink通过以下方式及软件方式来保证一致性：

◆读对端内存时如数据存在Cache（对端ACC处理器）中，要求Cache先行回写，以保证读取的内存数据是最新；

◆写对端内存时，如该段内存数据存在于Cache中，会将所涉及Cache行作废；

◆如写入数据被某核Cache，且只占Cache行部分时，需先将对应Cache行数据回写，再进行写入，同时将Cache核的该行Cache作废。

因硬件级Cache一致性协议（如MESI）在读写数据时，须确认和修改CacheLine状态，此过程存在多次和Cache端的交互。当HBD规模较大时，维护一致性的通讯与同步开销可能抵消并行效率，尤其在高并行密集访问场景下易降低数据吞吐量，导致链路的有效利用率降低。

同时，因需要复杂硬件逻辑维护一致性，会额外增加芯片面积与功耗，Scale-up协议可能有选择地部分支持一致性。即通过纯软件方式来保证读写的顺序（Fence操作），保证数据操作的完整性（如ETH-X实现）；也可以减小一致性的作用范围，仅限于CPU及和其直联的GPU间保证Cache一致性（如英伟达 NVLink C2C），在此范围外的一致性由软件保证，如在软件开发时避免出现可能导致Cache不一致的读写操作，可以使用Fence等机制来保证读写顺序。

UB使用对特定地址块的Ownership机制，提供对共享内存的读写控制访问权限，来保证跨节点数据一致性，也是一种值得借鉴的方式，但需考虑权限控制带来的管理复杂性。

图5 CXL的远端数据读取过程
需进行多次Snoop报文（红圈）交互来确认数据一致性

3）微秒级时延，纳秒级抖动

Scale-up网络的时延直接影响并行计算的同步效率，核心要求包括：

a）端到端微秒级时延

Scale-up网络的亚微秒级延迟要求是支撑AI大模型训练和推理的技术底线，其实现依赖于协议栈精简、硬件架构革新和系统协同优化的综合方案。通过内存语义支持、专用交换架构和低延迟FEC等关键技术，Scale-up网络实现了从传统消息机制的数据包传输到内存直接访问的转变，为超节点数据低延时读写提供了物理基础。

b）纳秒级抖动

Scale-up网络连接的GPU等加速器常进行张量并行、专家并行等操作，编译器与运行时会将设备间通信和计算过程重叠优化，此优化依赖稳定可预测的通信延迟。若抖动过大，会打破这种优化平衡，导致计算资源相互等待，训练或推理效率大幅下降，合理要求是将抖动控制在0.1μs内。

控制延迟抖动的实现路径一般围绕硬件架构、协议设计和流量管理等多维度进行优化。如广泛采用的Flit（Flow Control Unit，流控单元，即定长数据片）机制，配合下述Credit流控机制管控缓冲区，可有效降低避免了拥塞导致的抖动。同时，无损传输是低抖动的底线，频繁的重传虽可兜底数据完整性，但会引入更多的延迟抖动。因此低抖动要求本质上还需配合无损传输需求，将抖动控制在避免触发频繁重传的范围内，防止重传与抖动形成恶性循环，导致GPU 或加速器上下文中断等严重问题。

4）可靠性：无损传输+智能流控

Scale-up网络的高可靠性是保障AI大模型长时间稳定训练、多GPU协同计算数据一致的关键，其可靠性要求聚焦数据一致性、传输稳定性和任务连续性，实现路径则贯穿物理层、链路层等多层架构优化，超节点高密度互联场景下，单丢包可能导致训练任务中断和阻塞，带来以下要求。

表3 主流互联协议要求的BER

a）无损传输：

为保证GPU间低延迟、高带宽数据传输可靠性，Scale-up网络协议的误码率（Bit Error Ratio，BER）要求为1e-12或更低。这一标准已成为行业共识，此要求（也包含了Scale out网络）基于如下考虑。

◆维持并行计算节奏稳定：在张量并行、专家并行等计算模式中，反向传播的梯度同步需在微秒级窗口内完成。若网络出现拥塞、丢包或重传等异常，会打乱流水线并行的节奏，原本计算与通信的协同平衡被打破，整体计算效率会大幅下降。

◆确保长时任务持续运行：AI大模型训练常需数千块GPU连续运行数周。一旦网络发生中断，不仅会浪费此前数天的计算资源，还可能导致训练任务彻底无法推进，因此网络需具备极强的稳定性，避免出现任何可能导致任务中断的故障。

5）拓扑适配：支持单级/双级拓扑，兼顾密度与扩展性

a）超节点拓扑一般在单机柜使用单级交换，在多机柜组成的超节点使用双级交换网络。

b）单级拓扑优化：单机柜内采用“全互联+多平面” 设计，协议需支持多平面并行传输（如每个平面独立交换机，GPU与所有交换机直连），数据可拆分至多个平面同时传输，提升带宽利用率，避免单平面瓶颈。

c）双级拓扑扩展：跨机柜扩展时，支持双级拓扑，一般为避免出现拥塞使用胖树拓扑。协议具备路由转发优化（如最短路径优先 + 自适应路由），减少跨机柜跳转时延。

d）拓扑透明性：对上层应用和AI框架屏蔽拓扑差异，无论单级还是双级拓扑，应用无需修改代码即可适配，协议自动完成路由选择和流量分发。

e）少数Scale-up协议还不支持多级拓扑，如UALink1.0，目前只支持1024个GPU的单层拓扑，不支持Switch级联。后续版本有望支持。

6）兼容性与生态：复用成熟生态，降低部署成本

Scale-up网络对生态兼容性有利于扩展技术生态，降低开发和部署要求。如最大限度兼容现有数据中心基础设施（如光模块、线缆、交换机、运维工具），避免专属硬件导致的高成本和软件框架的重复开发和降低开发技术门槛。以此降低部署成本并提升扩展灵活性，其实现路径按软硬件层面展开：

a）复用成熟标准：

借用现有成熟连接器件和生态，如PCIe或以太网物理层：兼容现有PCIe（CXL3.0\4.0）或以太网PHY(UALink\UB )及光模块（如 QSFP-DD、OSFP）和铜缆，无需定制硬件；支持802.3标准的速率协商、链路训练机制，降低硬件适配成本。例如 ESUN 协议完全复用标准以太网 PHY，仅在链路层扩展AI相关字段，现有交换机通过固件升级即可支持。目前除了CXL（兼容PCIe）和NVLink（私有）外，其余主流Scale-up协议（UALink、UB、ETH-X、SUE等）均在物理层兼容802.3标准。

b）兼容主流 AI 框架与芯片：

适配 PyTorch、TensorFlow 等主流 AI 框架，提供适配该网络的统一的软件开发套件（SDK），包含算子库、集合通信库、优化工具、OS等，让开发者无需关注底层协议细节。

2 Scale-up 网络的协议实现

为满足上述特性，Scale-up协议需在架构设计上突破通用网络局限，核心要求包括协议栈精简、全硬件卸载、内存语义原生支持、拓扑优化适配。普遍具备如下特性。

2.1 协议栈精简，FLIT数据单元

1）HBD域内节点间交互频繁，软件干预（如协议栈封装、队列管理）会引入微秒级时延，所以Scale-up协议需要抛弃软件协议栈，精简协议栈与报文格式，去除传统以太网UDP/IP的冗余字段，采用固定帧长（如640B/UALink）和极简头部，减少报文解析开销，也减少协议层级和跨层交互时延。

2）协议栈多采用“事务层-数据链路层-物理层”三级架构，此结构最早为PCIe采用，UALink等也为此架构。UB采用多层协议栈（物理层、链路层、网络层、传输层、事务层、功能层）灵活架构，在Load/Store同步访问内存事务时使用TP Bypass模式，即跨过传输层，无传输层协议栈开销，以减少协议时延开销，提供低延时访问能力。而在高负载、多路径等场景下采用需传输层参与的可靠传输模式（RTP/CTP）,这种设计增加了协议复杂度但提供了面对不同场景的访问灵活性。

3）Scale-up网络协议基本都采用了Flit（Flow ControlUnit，流控单元）机制，其核心是将数据包分割为固定大小的独立单元传输，由此带来三大核心好处：

◆适配硬件流水线化处理，固定长度无需动态解析，降低数据包转发时延；

◆实现精细化流控，可逐 Flit 配合 Credit 机制管控缓冲区，避免整帧阻塞导致的丢包与重传开销，提升传输可靠性；

◆减少缓冲区碎片，固定大小让资源分配更规整，同时支持 Flit 并行传输与乱序重组，提升链路利用率并降低时延抖动，适配 Scale-up 网络对低时延、高稳定的需求（如 AI 集群 GPU 间参数同步）。

2.2 全硬件卸载/CBFC/VC/LLR/轻量级FEC

1）全硬件卸载：包括协议处理（报文封装/解封装、错误检测、路由查找、地址解析、一致性维护、流控计算等）完全由硬件芯片（PHY/Switch）完成，无需软件协议栈和OS内核态用户态转换过程，协议处理实现CPU零占用数据传输，CPU仅负责硬件初始化配置。

2）支持硬件预取与缓存协同：GPU通过内存语义直接读取和预取远程数据，协议帧结构直接承载内存地址、访问权限等信息；预取数据的缓存命中率和编码方式与硬件预取算法相关，预取可极大减少处理器的数据等待时间，若不支持处理器预取，则会极大降低GPU处理效率。

3）逐跳流控：基于信用的流控（CBFC）经过PCIe/FC等互联协议多年的考验，已证明效果优于RoCE的PFC流控方案，目前Scale-up基本都使用CBFC（Credit Based Flow Control）进行流控。

4）虚拟通道（VirtualChannel，VC）技术：Scale-up协议普遍使用虚拟通道（VirtualChannel，VC）技术隔离不同流量类型，再结合基于VC的信用流控（CBFC）和VC缓冲区共用技术（PCIe 6.0、UALink、UB），有效缓解了HOL阻塞问题。

图6 PCIe 虚拟通道收发机制，Scale-up协议普遍采用该机制

5）高速Serdes：基于PAM4调制的112、224GT/s的高速SerDes已成为Scale-up协议核心物理层技术，其超高速率为超节点内GPU的低时延连接和内存共享提供保障。112、224GT/s在Scale-up连接上最先被NVLink所用，目前其带宽已不再似刚推出时遥遥领先，逐渐被其他Scale-up协议拉齐。

UB目前最高支持106.25 Gbps速率的SerDes（满足OIF CEI-112G-LINEAR-PAM4），同时也兼容低速如53.125 Gbps及自定义速率。在后续的版本中应该能很快支持224GT/s速率。需要注意的是SerDes速率和芯片制程相关，224G的SerDes需要求5nm以下的制程工艺支撑。

对于PCIe5.0和6.0，其基于32GT/s和64GT/s的SerDes因相对低速，已逐渐淡出主流。PCIe7.0（含CXL4.0）使用的128GT/s SerDes在速率上具备了一定竞争力，但其成熟时间太晚（~2028），实际在Scale-up网络中使用前景不乐观。更高的448GT/s SerDes是应对未来AI算力需求的关键技术，目前处于标准体系逐步完善，技术突破聚焦于调制格式优化（PAM6 or PAM8）、信道补偿与功耗控制，已进入原型验证在向商用过渡阶段。

NVLink使用的SerDes基本情况如表4。

表4 各代NVLi nk及使用的SerDes

6）链路层重传（Link-LevelRetry，LLR）：LLR是Scale-up协议的底层容错基石，所有主流高速互联协议均已采用，其本质是在直接相连的两个节点（如 GPU 与交换机、交换机与交换机）之间，针对物理层/链路层的误码、信号衰减等导致的数据传输错误，自动选择重传错误数据，避免错误向上层协议扩散。同时不依赖上层协议（如传输层、应用层），避免端到端重传的高开销，在不显著增加延迟的前提下，解决物理层高带宽传输的误码问题，为Cache一致性、高并行数据交互提供可靠保障。不同协议的差异仅在于重传粒度（Flit级/帧级）、确认机制（NACK/超时），核心目标均为适配Scale-up网络的低延迟、高可靠性需求。核心过程一般为如下4 步。

◆错误检测：接收端通过CRC校验、FEC（前向纠错）解码失败等机制，识别错误的数据包/ Flit。

◆重传触发：接收端向发送端反NACK（否定确认），或发送端未在超时窗口内收到ACK（确认），触发错误重传或超时重传。

◆缓存与重传：发送端缓存已发送但未确认接收的数据（如Flit、帧），收到NACK或超时后，优先重传该错误数据，而非重新发送整段数据流。

◆确认收尾：接收端正确接收重传数据后，发送 ACK，发送端收到后释放对应缓存，完成链路级容错。

7）轻量级FEC：轻量级FEC的纳秒级处理与Scale-up的低延迟需求完美匹配，是唯一能在不破坏性能前提下提供硬可靠性的机制，基本为Scale-up协议标配。轻量级FEC硬件实现简单，能有效纠正字节级的传输错误，同时不引入过多时延，减少因错误导致的重传和等待，提升实际吞吐量，在高负载、多GPU协作场景中优势显著。

8）非阻塞拓扑设计：域内采用全连接或胖树拓扑，无单点带宽瓶颈，保证HBD域内任意两卡通讯不占用其他链路带宽。

2.3 周边要求：FM/OS/BIOS

1）FM（Fabric Manager）

Scale-up网络作为超节点内算力卡高速互联的技术，常需 Fabric Manager（FM，网络管理器）实现设备管理、拓扑路由控制及故障排查等操作：

a）精准拓扑感知与集中配置：Scale-up网络随着GPU数量增加，会引入Switch等设备形成复杂互联拓扑，FM 需具备自动识别网络内 GPU、交换机、线缆等所有设备的能力，同时生成拓扑即设备连接关系与路由等配置信息。支持热插拔，支持拓扑弹性扩展，支持集中化的多设备配置，如对超节点内的 Switch 路由、端口参数、互联协议参数等统一配置。

b）内存空间管理：FM支持超节点内所有算力设备的虚拟地址分配和映射，构建全局统一的内存地址空间，将HBD域内各设备的本地显存、主机内存纳入同一管理视图。并可将此信息同步OS，方便OS为应用分配本地和远端内存并进行管理如地址转换等。

c）实时全面的运维监控：Scale-up网络承载超大规模AI模型训练时，对带宽和时延的稳定性要求极高，FM 可实时收集网络带宽占用率、数据传输时延、端口流量等核心指标。支持不同周期的统计报告，便于运维人员追溯运行异常的规律。

d）安全访问与权限管控：某些场景需要定义可被共享和独享的内存空间，有相应权限的节点才能访问共享空间，如UB的Ownership机制，FM（UBFM）负责管理共享空间及安全访问权限。

2）OS

Scale-up网络作为超节点内高算力设备（GPU/NPU/XPU）的紧密互联核心，对操作系统（OS）的要求聚焦于内存语义通信、硬件资源池化、长时稳定运行等核心场景：

a）OS零干预：Scale-up网络的端到端低延迟要求极致降低OS干预开销，OS需避免传统网络栈的多层协议处理（如 TCP/IP 协议栈、内核态-用户态切换）。要求支持用户态直接访问网络硬件及远端内存，减少中断响应、内存拷贝等开销，确保数据在GPU间通过Scale-up网络实现无OS干预的传输，达到原生内存语义访问要求。

b）资源管控：支持全局资源统一管控超节点内多算力卡共享内存地址空间。完全启动后，OS可接管或部分接管FM的功能，需要具备全局硬件资源池化能力，即统一管理跨设备的内存、缓存、网络带宽等资源，支持全局虚拟地址映射，让应用程序无需感知硬件分布，实现“单OS视图” 下的资源调度。同时需支持算力卡与网络设备的协同调度，如计算任务与通信任务的优先级绑定，确定虚拟通道（VC）优先级，避免资源竞争导致的性能抖动。

3）BIOS

超节点存在多个CPU服务节点，对应多个BIOS。和常规BIOS一样，BIOS在启动负责启动初始化与资源协同，区别是资源范围扩大到整个HBD域即超节点内部所有可视资源。通过 ACPI接口等为上层OS系统提供统一硬件抽象与基础服务：

◆硬件初始化与建链：完成本地硬件初始化，实现Scale-up总线链路自协商与建链，确保超节点内各计算节点（如 GPU/NPU）的物理互联可达。

◆资源枚举与配置：参与超节点内资源的枚举，配合FM完成地址分配、路由表配置，构建全局资源视图。

◆资源管理：常规通用功能，如镜像加载，操作系统启动，向OS提供底层硬件抽象信息如报硬件拓扑、内存范围、中断、RAS错误等信息。支持热插拔与故障隔离，保障超节点稳定运行。

3 主流Scale-up协议对比

当前市场形成NVLink、CXL、UALink、SUE、ESUN、UB等几个主流方案，核心特性均支持100G以上的SerDes，对PCIe和以太生态的复用程度各有差异。主要Scale-up协议的定位及技术特点见表5。

表5 主要S cale-up协议的定位及技术特点

4 Scale-up网络目前的问题和短板

除相对成熟但封闭的NVLink、UB协议外，目前还有多个Scale-up协议在同步发展，协议栈和硬件的生态孤立，导致Scale-up网络还远未到达PCIe或以太的成熟阶段。而极致的紧耦合架构，故障隔离能力下降，使Scale-up网络的可靠性和可维护性低于传统集群。

4.1 专用硬件与协议及软件栈生态孤立，成熟度和容错能力低

超节点为追求低延迟，依赖专用互联硬件（如定制NVSwitch、UALink Switch交换机等）和私有协议（如 NVLink协议、UB协议）及尚不成熟的开放协议（如UALink、ESUN、ETH-X协议等），协议分头进化呈碎片化发展，生态较传统以太/RoCE或PCIe标准协议比较不够成熟。

超节点的软件栈高度依赖厂商专属框架（如NVIDIA CUDA、HW CANN等），传统分布式集群使用的容错技术难以适配HBD紧耦合架构，使得Checkpoint成为超节点的通用容错技术。然而为提升容错性，增加Checkpoint频率或冗余节点，均会占用大量互联带宽、时间和计算资源，从而抵消超节点的算力协同优势。

这些短板导致超节点在恢复成本可接受的场景（如大规模AI训练推理、超算任务）被亲睐，而在高可用和高可靠性场景（如在线推理、实时数据处理）中，其容错能力不如传统Scale out集群，规模使用将受到限制。

4.2 故障域显著扩大，单点故障易引发雪崩效应

超节点的计算单元（GPU/NPU）、互联链路、Switch通过Scale-up网络形成一台逻辑上的超大型算力单元，资源共享度极高（如共享内存地址空间、缓存状态、互联带宽），缺乏传统集群的节点物理隔离边界。传统Scale out集群通过松耦合节点隔离故障，故障域一般限于单节点。而超节点为追求低延迟算力协同，采用全连接互联、共享资源池甚至Cache一致性等设计，导致故障易扩散、检测难、恢复复杂。传统集群虽算力协同效率低，但故障影响范围小、恢复快，可用性高于超节点。

当前主要问题体现在：

1）核心互联交换机故障：超节点多采用全连接或胖树拓扑，核心交换机是所有计算节点的通信枢纽，一旦故障，整个超节点的算力协同完全中断。

2）单颗计算节点（GPU/NPU）故障：因Cache一致性要求全局状态同步，故障节点的缓存数据（如未写回的模型参数、梯度）可能处于脏状态，若不隔离会污染全局数据，导致计算结果错误，因此通常需暂停整个超节点任务。

3）高速链路故障：专用互联链路（如224G SerDes）是算力协同的神经纤维，单条链路故障可能导致数据传输中断或误码，而全连接拓扑中链路冗余小、密度极高（如64节点全连接需 2016 条链路），故障概率随规模线性增加。

4）如HBD域支持全域Cache一致性，则协议要求节点间实时同步缓存状态（如Invalidate、Update消息），若某节点故障导致消息丢失或超时，会触发全局一致性冲突（缓存状态不一致），进而导致其他节点陷入等待-重试循环，最终引发整个超节点算力停滞。

5）当节点故障出现时，传统集群可通过虚机迁移等方式快速完成故障恢复。超节点恢复通常需如下步骤，故障恢复过程和成本远超传统集群：

a）更新全局路由表，切断故障节点的输入输出链路，将故障节点从资源池移除，禁止新任务调度至该节点，阻止故障扩散。

b）如不更换故障硬件，需基于最近一次Checkpoint 快照，在剩余正常节点上重构任务并行逻辑（并行策略里剔除故障节点和链路），重新加载后运行。

c）如更换了故障硬件，需完成联通性和稳定性后，将新节点纳入资源池，完成地址、路由更新，加载CheckPoint并重新启动任务。

d）由上，因紧耦合架构，无论是否进行坏件更换，超节点及Scale-up网络故障的恢复过程远超传统集群。

5 Scale-up协议发展展望

Scale-up协议作为超节点算力协同的核心支撑，未来将围绕 “性能升级、生态开放、架构融合” 三大方向演进，同时针对性优化可维护性与可靠性短板，趋势归纳如下。

1）物理层兼容以太网成为协议底座主流选择，开放生态加速落地

以太网凭借成熟生态与成本优势，将逐步成为Scale-up协议物理层的主要技术底座。UALink、ESUN（Ethernet Scale-up Network）等基于802.3物理层的方案持续渗透，通过协议优化实现低时延与高带宽（适配 112、224GT/s乃至448GT/s SerDes速率），打破NVLink等私有协议的厂商绑定。PCIe因速率低、迭代慢，暂难以成为Scale-up网络主流，但因其广泛生态仍将长期存在。超以太网联盟（UEC）、OCP等开放组织将推动接口与互操作标准统一。经过一定时间的市场、技术竞争，统一标准将解决协议碎片化发展问题，提升多厂商GPU\Switch的兼容性，降低部署与维护复杂度。

2）性能持续突破，光电互联协同发展

单机柜内将保留铜缆互联的低成本优势，通过高速铜缆模组迭代满足短距高带宽需求；跨机柜场景中，光互联成为必然选择，CPO、OCS（Optical Circuit Switch，全光交换机）、低延迟光模块技术规模化应用，突破电互联物理极限。协议层面将优化报文头设计与流控机制，结合新一代448GT/s SerDes等新技术，进一步提升带宽利用率与传输稳定性。

3）架构融合创新，兼顾效率与弹性

“Scale-up域内高速互联+Scale-out域间弹性扩展”的融合架构将成为智算中心主流架构，通过一张以太网承载两类流量，避免多张网络部署的复杂性。域内依托高带宽协议支撑张量并行、专家并行等计算模式，域间通过弹性路由实现负载均衡，既满足低时延数据同步需求，又提升系统容错能力。同时，协议将采用分层模块化设计，实现功能独立升级与故障域隔离，减少局部问题对全局的影响。

4）国产化与智能化并行，生态持续完善

国内厂商与相关组织将加速推动开放Scale-up协议适配，兼容主流国产算力芯片，采用以数量换性能的方式，弥补单卡性能差距，抢占大规模建设的市场份额。Scale-up网络智能化运维工具将逐步普及，通过统一监控平台实现链路状态可视化、故障秒级定位与自动化恢复，降低人工干预成本。同时硬件层面将优化供电、散热与维护设计，提升系统整体可用性与运维效率。

6 理想的超节点Scale-up协议

理想的超节点Scale-up协议核心是开放兼容、低时延高带宽、无损可靠且灵活扩展。需基于开放生态（如以太网），打破厂商锁定，兼容多品牌多厂家GPU/CPU与其他硬件。物理层支持200G及以上高速SerDes；链路层通过帧头压缩、链路重传（LLR）和信用流控（CBFC）提升效率与可靠性；事务层原生支持内存语义，实现GPU间直接访存。需适配从单机柜到级联超节点的多场景，支持铜缆/光纤混合组网，时延控制在百纳秒级，有效带宽利用率超90%，同时具备低功耗、低成本特性，并拥有完整的软件（OS、BIOS开放框架等）生态，以满足AI训练中TP/EP并行的严苛通信需求。

整体来看，Scale-up协议将在保持高性能优势的基础上，通过开放标准化、光电协同与架构创新，持续优化可维护性与可靠性，成为支撑AI大模型训练与推理的核心技术底座，同时为国产化算力建设提供关键支撑。