Ascend Interconnect Evolution

导言

在昇腾通信栈的第五轴中，PCIe、片内 NoC、HCCS、RoCE 与 UnifiedBus 被放在同一行。看到这些概念，一个很自然的疑问是：它们为什么没有统一？是不是每一种新互联，都是为了解决上一代的缺陷，并最终取代前者？

这个问题抓住了技术演进，却预设了一条并不存在的替换链。这些概念分别工作在芯片内部、服务器 I/O、节点内 Scale-Up 和集群 Scale-Out 等不同范围，提供的事务与内存语义也不相同。本文从无法绕开的物理约束出发，沿历史纵轴梳理它们出现的契机，再用同一组维度比较其设计取舍，最后说明：什么时候一种新思想只需要增加后端，什么时候它会形成新的编程契约和代码仓。

一条不存在的替换链¶

《Ascend Communication Stack》把一次通信拆成五个责任轴：应用选择什么通信语义，Runtime 如何建立地址与资源，谁提交任务，谁搬运 Payload，以及字节最终经过什么互联。第五轴回答的是最后一个问题。

图 1：昇腾通信栈五轴架构。根据既有研究内容整理的自绘示意图。

“位于第五轴”只说明这些对象都参与承载字节，并不表示它们处于相同空间尺度。一笔跨设备传输可能连续经过多个对象：

AICore
  → 本芯片 NoC
  → HCCS / PCIe / UB / RoCE 接口
  → 板级走线、交换机或光网络
  → 对端芯片 NoC
  → 对端 HBM

同机 HCCS 传输通常是“本地 NoC → HCCS → 对端 NoC”；跨机 RoCE 传输则是“本地 NoC → RoCE Engine → Ethernet → 对端 RoCE Engine → 对端 NoC”。NoC 与 HCCS、RoCE 不是竞争后端，而是同一条端到端路径中的不同段。

另一方面，PCIe、HCCS、RoCE 和 UB 确实存在部分重叠：它们都可能承载设备间数据。但即使范围重叠，各自优先解决的矛盾仍不同：

PCIe优先保证通用设备接入和软件兼容。
HCCS优先优化固定昇腾平台内的高带宽、低时延 Scale-Up。
RoCE优先复用 Ethernet 实现跨节点 RDMA。
UB尝试把统一编址、远端操作、设备平等和资源池化提升为系统协议。

不要按发布时间排代际

NoC 与 PCIe 的代表性设计都在 2001—2002 年形成；RoCE v1 出现在 2010 年，早于 HCCS 的公开 Ascend 910 证据；UB 虽然到 2025 年才正式公开 2.0 规范，官方披露的研究起点却是 2019 年。发布时间不能直接转换成 PCIe → NoC → HCCS → RoCE → UB 的替换顺序。

物理约束不会消失¶

先暂时放下这些产品名。一条互联必须同时回答距离、端口、语义、可靠性和生态五类问题，而这些目标无法一起达到最优。

距离改变一切¶

信号从芯片内部走向封装、主板、机架和数据中心时，会逐步增加：

传播时延与每 bit 能耗；
SerDes、时钟恢复和编码开销；
串扰、衰减和误码；
FEC、重传、交换与多路径需求；
链路训练、故障隔离和运维成本。

片内 NoC 可以使用超宽并行链路和与 Floorplan 紧密配合的 Router；跨机网络却必须处理数米甚至更远距离上的信号完整性与局部故障。把 RoCE 的完整协议栈放进每个 AI Core，面积和功耗不可接受；反过来，裸片内 NoC 也不能直接驱动机架级光网络。

端口数量限制 Full Mesh¶

如果让每个节点都与其他节点直接相连，连接数为：

\[ L=\frac{N(N-1)}{2}. \]

8 个 NPU 尚可通过专用端口构造紧耦合互联；节点规模上升到数百、数千乃至数万后，端口、线缆和布线复杂度会迅速失控。系统必须从直连转向交换、分层和路由。

这也是不同拓扑长期共存的原因：

片内 NoC 常用 Mesh，以线性数量的局部链路替代全局交叉开关；
有限规模的 HCCS 可以利用 Full Mesh、Ring 或产品定制拓扑；
RoCE 依赖以太交换网络获得跨机架扩展；
UB 把多级交换、大规模路由和高可用纳入超节点目标。

一致性不能无限外推¶

远端内存若要表现得更像本地内存，就必须维护地址、权限、顺序、可见性、原子性和缓存状态。参与者越多，目录状态、失效流量和故障恢复成本越高。

因此，下列推导都不成立：

PCIe 支持 MMIO 和 Load/Store，不能推出全系统 Cache Coherent；
HCCS 名称包含 Cache Coherence，不能推出所有产品、内存和观察者属于同一无限扩展的一致性域；
RoCE 支持 RDMA，不能推出远端 CPU/NPU Cache 自动一致；
UB 支持统一内存语义，不能推出所有远端操作具有最强顺序和本地 HBM 延迟。

地址可达、操作完成、对端可见和缓存一致是四份需要分别确认的契约。系统规模越大，越不能用一个“共享内存”标签覆盖全部问题。

专用效率与开放兼容冲突¶

HCCS 可以围绕固定芯片、拓扑和固件深度协同；PCIe 和 Ethernet 却要兼容多厂商设备、操作系统、交换机和旧软件。专用协议容易获得更高效率，开放协议则更容易形成稳定生态。

这不是设计成熟度的单向差距，而是产品目标的差异。如果一种协议既要求专用互联的效率，又要求通用 I/O 的兼容、网络的距离和全系统强一致，它最终仍会在内部拆成多种 Profile。

五种互联怎样形成¶

这些互联的历史不是一条线，而是不同空间尺度上的问题逐步暴露。下面按首次公开的关键节点梳理，内部立项时间无法核实的部分单独保留。

时间	公开事件	当时需要解决的矛盾	主要设计变化
2001—2002	NoC 研究范式形成	全局导线延迟、时钟偏斜、能耗与 SoC 组件扩展	把 SoC 看作微型网络，以 Router、分组、Mesh 和 QoS 组织片内通信
2002-04 至 07	3GIO 更名为 PCI Express，1.0 规范形成	并行 PCI 的频率、引脚和共享总线瓶颈，同时必须兼容既有软件	高速串行、点到点、分组化、分层协议，保留 PCI 配置与编程模型
2010	RoCE v1 发布	希望获得 RDMA 的直接放置和低 CPU 开销，但复用 Ethernet 基础设施	将 InfiniBand RDMA Transport 承载于 Ethernet L2
2014-09	RoCE v2 发布	RoCE v1 受单一二层广播域限制	增加 UDP/IP 外层，获得 L3 路由能力
2018—2019	Ascend 910、片内 Mesh NoC、HCCS 与 RoCE 路径公开	单芯片内部数据供给与单机多 NPU Scale-Up 同时成为瓶颈	片内 Mesh 汇聚 Core/Cache/HBM/I/O；HCCS 服务节点内互联；RoCE 服务网络扩展
2019	UB 研究启动	先进工艺受限，需要通过多芯片与系统架构延续算力增长	把“更多芯片像一台计算机工作”设为目标，重新设计互联、编址与资源语义
2025-03	UB 1.0 随 Atlas 900 A3 SuperPoD 交付	大规模超节点进入产品验证	从协议研究进入规模化部署
2025-09-18	UB 2.0 发布并开放规范	从单一产品走向万卡超节点和开放生态	强调总线级互联、平等协同、全量池化、协议归一、大规模组网和高可用

NoC：先把芯片变成网络¶

2002 年的代表性 NoC 论文已经指出：工艺继续缩小时，全局导线延迟可能超过时钟周期，单一全局时钟难以维持，通信能耗也不会像逻辑门那样自然下降。解决思路不是继续增加共享总线，而是用网络设计方法抽象片内电气、链路、路由和服务质量。NoC 原始论文

NoC 的关键设计包括：

用 Network Interface 把 Core、Cache、HBM Controller 和 I/O 接入网络；
用 Router 和局部链路替代全局共享导线；
使用 Mesh、Ring 或应用定制拓扑；
通过流控、路由和调度区分延迟敏感与带宽敏感流量；
允许不同模块跨时钟域通信。

Ascend 910 后来采用 4×6 的二维 Mesh NoC，连接 32 个 Ascend Core、Cache 和 I/O；官方研究资料还描述了 1024-bit 相邻链路、无缓存设计和全局 QoS 调度。华为 Ascend 架构论文

NoC 没有统一成 PCIe 或 HCCS，是因为它首先服务芯片物理设计。其拓扑、位宽、Buffer 和路由策略要与 Floorplan、功耗和目标 Workload 一起决定。NoC 是一种设计范式，而不是等待所有芯片共同实现的一份外部线缆标准。

PCIe：先保护软件投资¶

传统并行 PCI 提升频率时，需要同时控制多根信号的时钟偏斜，Pin Count 和共享总线也越来越难扩展。2002 年完成的 3GIO 草案因此选择高速串行、点到点和分组化架构，并更名为 PCI Express。

PCIe 最重要的设计选择不是单纯增加带宽，而是硬件重新设计、软件尽量兼容：

使用 Transaction、Data Link 和 Physical 分层；
通过 x1、x4、x8、x16 Lane 组合扩展带宽；
用 Root Complex、Switch 和 Endpoint 构造系统；
保留 PCI Configuration Space、BAR、MMIO 和既有驱动模型；
支持设备发现、电源管理、热插拔、虚拟化和错误报告。

PCI Express 早期公告明确把串行点到点、分组协议、Load/Store 架构和 PCI 软件兼容列为设计目标；这些能力至今仍是 PCIe 难以被专用互联取代的原因。

但 PCIe 是 Root-Centric 的通用 I/O。多加速器 P2P 可能受到 Switch 层级、ACS、IOMMU 和 Host 拓扑影响，Collective 也不是它的原生抽象。因此更现实的长期分工是：

PCIe 保留启动、枚举、管理与通用 I/O，专用 Scale-Up Fabric 承担主要加速器数据面。

RoCE：保留 RDMA，替换承载网络¶

InfiniBand/RDMA 已经形成注册内存、Queue Pair、Completion Queue、直接放置和单边操作等成熟语义，但为此单独建设 InfiniBand Fabric 会增加设备和运维体系。RoCE 的思路十分克制：保留 InfiniBand Transport 与 Verbs，把承载换成 Ethernet。

它经历了两次关键变化：

RoCE v1，2010。直接运行在 Ethernet L2，只能工作在同一二层网络。
RoCE v2，2014。增加 UDP/IP 外层，获得跨 L3 路由能力。IBTA RoCEv2 公告

RoCE 的价值来自复用：

复用 Ethernet 交换机、线缆和运维经验；
复用 RDMA Verbs、MR、QP 与 CQ 软件模型；
让跨服务器通信绕开普通 TCP 数据路径中的部分 CPU 与复制开销；
通过交换和路由扩展到机架与集群。

代价也来自复用。RDMA 对丢包、乱序和尾延迟敏感，规模部署需要处理 PFC、ECN、DCQCN、QoS 和多路径；如果配置不当，暂停传播和拥塞会放大故障。IBTA RoCE 部署指南

这解释了为什么 RoCE 不会被 HCCS 取代：前者解决跨服务器、跨机架和可路由网络，后者首先解决受控平台内的 Scale-Up。UB 出现后 RoCE 也不会立即消失，因为已经部署的 Ethernet/RDMA 生态仍然具有独立价值。

HCCS：为昇腾 Scale-Up 做专用协同¶

Ascend 910 时代，单芯片内部的 NoC 只能连接本芯片组件。多颗 NPU 组成训练服务器后，仍然需要一种比普通 Host-Centric PCIe 更贴近 NPU—NPU 与 CPU—NPU 通信的互联。

HCCS 因而重点处理：

有限平台内的高带宽、低时延 NPU 互联；
NUMA 式远端访问和缓存/内存协同；
单机多卡 Collective 的稳定拓扑；
与 HCCL、HCCP、SDMA 和平台固件共同优化。

当前 CANN 文档将 HCCS 定义为 Huawei Cache Coherent System，是 CPU/NPU 或 NPU/NPU 间的高速总线。CANN HCCS 术语定义

HCCS 的内部提出和立项时间没有公开一手证据。可确认的公开边界是：

Ascend 910 于 2018 年公布、2019 年上市；
2019 年 Hot Chips 的 Ascend 910 架构已经展示 HCCS、片内 NoC 与 RoCE 接口；
2020 年 Atlas 900 官方资料明确列出 HCCS、PCIe 4.0 和 100G Ethernet；
后续华为研究资料描述过组内 HCCS、组间 PCIe 的 Ascend 910 服务器。

这组证据反而说明 HCCS 从一开始就没有全面替代 PCIe：旧服务器能够同时使用 HCCS 和 PCIe，不同代际又出现 Ring、Full Mesh、HCCS-L1/L2 与 SIO 等拓扑。它的性能来自产品专用协同，代价则是协议、端口、拓扑和软件栈与昇腾代际绑定。

Cache Coherence 的边界

HCCS 的全称不能代替具体产品的一致性说明。判断一块远端内存能否透明 Load/Store，仍需核对参与者、地址空间、Cache Domain、顺序、可见性与 Runtime API，而不能只看链路名称。

UB：把互联提升为系统协议¶

华为官方披露，UnifiedBus 的研究始于 2019 年。直接背景是先进工艺受限，单芯片算力不能只依赖制程推进，需要通过连接更多芯片延续系统能力。华为 UnifiedBus 主题演讲

UB 的变化不只是增加链路带宽，而是重新定义目标：

总线级互联。希望远端资源能够以事务和内存语义访问，而不只发送网络报文。
平等协同。CPU、NPU、内存、网络与存储不再完全受 Root—Endpoint 角色限制。
全量池化。把分散的计算、内存和 I/O 组织成可分配资源。
协议归一。统一设备标识、寻址、事务、可靠性与管理框架。
大规模组网。从服务器内部扩展到万卡超节点，并继续连接超节点集群。
高可用。把故障检测、隔离、绕路和运维作为大规模系统的基本能力。

从公开软件看，这些目标落到了 EID、UMMU、URMA、Memory/Message/Atomic 操作以及 UMDK 等对象上。它们说明 UB 的“统一”首先发生在事务、地址、权限和资源模型，而不是要求所有距离使用同一套电气信号。

官方在 Atlas 950 SuperCluster 中仍同时支持 UBoE 与 RoCE：UBoE 把 UB 承载到 Ethernet，使客户能够利用现有以太交换机；RoCE 则保留既有 RDMA 路径。这个设计直接给出了边界：

UB 试图统一互联语义，但仍允许原生 UB、UBoE、RoCE、PCIe 和旧代 HCCS 按硬件、距离与部署条件并存。

放进同一坐标系¶

逐个理解之后，才能进行有意义的横向比较。下面的“语义”只写各体系主要公开契约，不把某一产品的局部能力外推为整个协议的保证。

维度	片内 NoC	PCIe	HCCS	RoCE	UnifiedBus
典型范围	芯片内部	芯片、卡、服务器 I/O	服务器或受控超节点内 Scale-Up	服务器、机架、集群 Scale-Out	卡间、超节点，并通过 UBoE 延伸到集群
核心矛盾	全局导线、功耗、QoS	通用设备接入与软件兼容	昇腾多 NPU 低时延高带宽	Ethernet 上的 RDMA	统一事务、内存语义、池化和大规模可靠组网
拓扑倾向	Mesh、Ring、定制	Rooted Tree	Full Mesh、Ring、分层专用拓扑	Ethernet Switch、L3 路由	平等节点、多级交换、原生 UB 或 UBoE
主要语义	芯片内部定制事务	配置、MMIO、DMA、Atomic 等	平台相关的一致性与高速内存访问	MR、QP、CQ、RDMA Read/Write/Atomic	EID、UMMU、Load/Store、URMA Memory/Message/Atomic
开放程度	范式开放，实现定制	开放行业标准	华为产品协议	IBTA + Ethernet 生态	2.0 规范已开放，生态仍在形成
最大资产	面积、能耗和带宽密度	OS、驱动、设备和管理生态	昇腾软硬件协同	交换网络和 RDMA 软件生态	跨设备语义与超节点系统设计
主要代价	无法直接跨芯片复用	加速器 P2P/Collective 不是设计中心	产品、端口和拓扑绑定	拥塞与无损网络工程复杂	新硬件、ABI、互操作与运维成熟度

这张表揭示了一个容易忽略的事实：UB 与 HCCS、RoCE 的差异不只在带宽，而在抽象边界。HCCS 更像特定平台的 Scale-Up 互联，RoCE 更像具有远端内存能力的网络，UB 则尝试把互联、内存语义和资源池化放入同一系统体系。

类似趋势也出现在其他生态。UALink 1.0 使用 Read、Write 和 Atomic 内存语义构造开放的加速器 Scale-Up 网络；CXL 在 PCIe PHY 上增加缓存与内存协议；NVLink/NVSwitch 则通过全栈协同扩大 GPU Scale-Up Domain。这些方案并没有汇聚成唯一协议，说明产业共同追求的是远端资源的一等公民化，但各家仍在开放程度、语义强度和软硬件协同上选择不同位置。UALink 1.0 白皮书

新思想为什么形成新仓库¶

“新互联出现，所以一定会新建代码仓”仍然不够准确。PCIe 和 RoCE 的演进恰好展示了另一条路线：尽量复用原软件模型。

PCIe 保留 PCI 配置与编程模型，因此主要扩展既有内核 PCI 子系统和设备驱动。
RoCE 保留 InfiniBand Verbs，因此能力进入 RDMA Core、内核 RDMA 子系统和厂商驱动。
片内 NoC 与 HCCS 的大量实现位于 RTL、固件和闭源驱动中，也未必存在独立公开仓库。

只有新思想越过“链路实现”边界，形成新的北向语义、资源生命周期、多后端编排或独立兼容矩阵时，才需要一个独立仓库承载。

新的软件责任	公开仓库与时间	为什么需要独立演进
统一远端内存语义	`openEuler/umdk`，公开历史始于 2022-08，URMA 主体于 2023-09 出现	URMA、远端 Memory/Message/Atomic、驱动接口、RPC 和 Socket 加速形成 UB 原生软件边界
通信资源与 Collective 算法解耦	`cann/hcomm`，首个可见提交 2025-10-17	Endpoint、Channel、Memory、Notify、控制面与数据面需要独立于某个 Collective 算法演进
Host 单边传输跨多代链路	`cann/hixl`，首个可见提交 2025-10-14	用稳定 Engine/Register/Transfer API 屏蔽 HCCS、RDMA、UB、UBoE 与 FabricMem 差异
Device 侧对称内存与 RMA	`cann/shmem`，首个可见提交 2025-12-12	PE、Team、对称堆、RMA、Atomic、Signal 和 Device 直驱构成完整编程模型
Collective 语义继续独立	`cann/hccl`	AllReduce 等操作仍需要拓扑、分块、算法选择和 Executor，不会因底层统一内存语义而消失

这些仓库并不与五种互联一一对应。更准确的关系是：

HCCL：一组 Rank 要共同完成什么
HIXL：Host 要把哪些 Buffer 搬到哪里
SHMEM：Device PE 要访问哪个 PE 的对称对象
HCOMM：操作需要哪些通信域、Endpoint、Channel 和硬件资源
UMDK / URMA：UB 上允许哪些远端内存与消息操作

仓库时间口径

首个公开提交只说明代码“不晚于该日公开可见”。它不能代替内部立项、闭源产品首次实现、芯片 RTL 定版或正式发布日。尤其不能因为 HCOMM、HIXL、SHMEM 在 2025 年密集开源，就断言相关需求也在 2025 年才出现。

所以，新代码仓真正反映的是责任边界重画：从只提供链路和搬运，演进到稳定表达地址、权限、操作、完成、故障与多后端选择。

未来会统一什么¶

从当前证据看，近期最可能发生的是三条并行路径。

多互联继续共存¶

片内互联：NoC
通用接入与管理：PCIe
A2 / A3 Scale-Up：HCCS
Ascend 950 Scale-Up：UB
跨超节点：UBoE 或 RoCE

新硬件会移动主路径，但已经部署的系统、驱动和交换网络不会随新协议发布而消失。描述状态时，应使用“新代际重心迁移”，而不是“旧协议已废弃”。

上层语义先收敛¶

HCCL、HIXL 和 SHMEM 可以保持不同编程模型，HCOMM、Runtime 和 UMDK 则逐渐复用：

内存注册、Handle、页表和权限；
Endpoint、Channel、Queue 与 Completion；
拓扑发现、能力查询和路径选择；
故障诊断、重连与多路径资源。

这是一种更现实的统一：应用意图稳定，底层后端可发现，真实路径可验证。

UB 扩大系统边界¶

如果 UB 规范、ABI、交换生态和软件工具成熟，它可能吸收更多 HCCS Scale-Up 和部分 RoCE 场景。但判断这一趋势不能只看带宽，需要观察：

UB 是否从可选后端变为新产品默认数据面；
UBoE 是否获得通用交换机和跨厂商互操作支持；
URMA/UMDK ABI 是否稳定并被更多上层框架直接采用；
大规模拥塞、故障隔离、热插拔和可观测性是否达到生产要求；
HCCS 是否停止获得新硬件支持，而不只是某一代产品未枚举；
PCIe 是否逐步收缩到启动、管理和通用 I/O，而不再承担主要 NPU 数据面。

即使这些条件全部满足，NoC、PCIe 和 Ethernet PHY 仍不会消失。被统一的将是更靠上的事务、地址和资源语义，而不是不同距离上的全部物理实现。

怎样验证一次互联演进¶

面对新的协议名、性能数字或代码仓，可以先按一条真实路径追问，而不是立即判断“谁取代了谁”。

空间范围是什么。它服务 Die、Package、Board、Rack 还是 Cluster？
谁是发起者。CPU、AICPU、AIV、NIC 还是 DMA Engine？
地址怎样表示。本地 VA、BAR、MR/rkey、EID/UMMU 地址还是项目私有 Handle？
操作语义是什么。Memcpy、Load/Store、RDMA Read/Write、Message 还是 Atomic？
完成到哪里。本地提交、本地完成、远端内存完成还是消费者已可见？
真实物理路径是什么。是否依次经过本地 NoC、I/O Die、专用链路、交换机和对端 NoC？
故障域是什么。链路丢包、节点复位、对端进程退出后由谁发现和恢复？
旧系统怎样兼容。新增的是后端、兼容层、全新 API，还是独立产品契约？

只有这些问题的答案发生实质变化，才能判断一次演进究竟是速率升级、协议封装、软件重构，还是新的系统架构。

总结¶

回到最初的问题，PCIe、片内 NoC、HCCS、RoCE 与 UB 没有统一，并不是因为产业遗漏了一次显而易见的合并，而是因为它们面对的距离、端口规模、语义强度、故障模型和生态成本不同。

现在可以确认的是：

NoC 解决芯片内部的可扩展通信；
PCIe 保护通用 I/O 与软件生态；
HCCS 服务受控昇腾平台的高性能 Scale-Up；
RoCE 用 Ethernet 承载成熟 RDMA 语义；
UB 尝试把事务、内存语义、设备角色和资源池化提升为超节点系统协议。

仍不能确认的是 HCCS 的内部立项时间，以及部分 A3 产品中 HCCS/SIO 与 UB 1.0 的精确协议包含关系。公开资料不足时，最稳妥的写法仍然是保留版本与产品边界。

因此，观察未来互联时，真正值得追踪的不是又出现了多少新名字，而是：新的设计是否改变了地址、权限、操作、完成和故障契约；它是否形成了一个需要独立演进的软件责任。这才是新协议走向新代码仓的分界线。