Ascend Communication Stack

导言

华为昇腾通信资料最容易制造一种错觉：DMA、HCCS、HCCL、SHMEM、Fabric Memory 和 AIV 直驱仿佛是一摞可以从上到下整齐堆叠的软件层。实际并非如此。这些词分别回答“谁组织通信、谁建立地址、谁提交任务、谁搬数据、数据走哪条物理链路、对端是否参与”中的不同问题。有些是库，有些是协议或硬件，有些只是数据路径属性；把它们画在同一层，关系一定会错。

本文把历史纵轴和技术横轴合并：先建立一张总地图，再逐个概念给出小白版与专业版解释，最后核对公开仓库的首次可见提交、立项目的、硬件范围、迁移和待废弃状态。研究截止日为 2026 年 8 月 26 日。

核心结论¶

这不是一座塔，而是五条相交的轴。HCCL、HiXL、SHMEM 和 TileXR 是不同用途的上层软件；DMA、MTE、SDMA、RDMA、UDMA 是数据执行机制；HCCS、PCIe、RoCE、UB 是互联；IPC、VMM、对称堆、内存注册是地址和内存语义；零拷贝与 AIV 直驱则是跨层属性。
内存语义是一份“允许观察到什么”的契约，不是一种内存或一条链路。狭义内存模型规定 load/store/atomic/fence 的顺序和可见结果；UBMEM/UMDK 语境采用更宽的系统口径，还涉及寻址、权限、远端操作、完成、同步和生命周期。支持远端地址访问不能自动推出 cache coherent、强一致、全局立即可见或持久化。
CANN 的 xDMA 是家族名，RDMA 与 RoCE 也不是同义词。当前 SHMEM 术语表把 xDMA 定义为 DMA 类引擎统称，可概括 SDMA、RDMA/RoCE、UDMA 等后端；MTE 在该项目的后端分类里与 xDMA 并列。RDMA 是远程访存能力和队列语义，RoCE 是把 InfiniBand RDMA transport 承载于 Ethernet 的具体协议；AMD/Xilinx XDMA 则是 FPGA PCIe DMA 产品。
HCCS、HCCL 不是同一类对象。HCCS 是服务器或超节点内互联；HCCL 是集合通信库，向上提供 AllReduce、AllGather、AllToAll 等语义，向下通过 HCOMM 等资源与传输层使用 HCCS、RoCE、PCIe 或 UB 能力。
UB、UBMEM、UDMA 和 URMA 也不是同义词。UB 是灵衢 UnifiedBus 互联体系；UBMEM 是内存语义；URMA 是 UB 上的统一远程内存访问模型；UDMA 是当前 CANN SHMEM/HCOMM 中面向 Ascend 950 的具体 DMA 数据后端。
SHMEM 与 HCCL 是两种编程模型。HCCL 从“整个通信组要完成哪个 collective”出发；SHMEM 从“当前 PE 要访问哪个 PE 的对称内存”出发。SHMEM 可以实现 collective，但不能因此把 HCCL 包含进 SHMEM。
ADXL 正在被 HiXL 新 API 取代，但兼容代码尚未删除。HiXL 公开仓从 2025 年 10 月起同时包含 HIXL 与 ADXL 接口；2026 年 4 月公开文档把 ADXL 明确列入“待废弃”。这应写作“API 迁移中”，不能写成“ADXL 已不可用”。
USE_UBSHMEM 不等于 cann/shmem。Mooncake 的 UBShmem transport 是基于 CANN VMM、Fabric/IPC 共享句柄和 ACL 异步复制的专用路径；固定公开源码没有调用 aclshmem Device API，也不能据名称推断为 AIV 直驱。
Fabric Memory 与 CANN VMM 是上下层关系。VMM 提供物理内存、虚拟地址、映射、权限和共享句柄；Fabric Memory 是利用这些机制，把超节点内远端内存纳入可访问地址空间的模式。VMM 本身不是传输协议。
零拷贝和 AIV 直驱都不是独立传输引擎。零拷贝描述中间副本是否被消除；AIV 直驱描述谁构造和提交通信任务。二者都不能回答数据最终由 MTE、SDMA、RDMA 还是 UDMA 搬运。
多数“立项时间”无法从公开资料核实。本文只把仓库首个可见提交、首次公开说明、首个标签和正式开源公告写成事实；内部立项、闭源实现沿革与芯片 RTL 时间没有一手证据时统一标为“暂未核实”。

读图原则

实线表示公开接口或源码能确认的调用或依赖，虚线表示可选后端、兼容关系或设计意图。“位于下方”不自动等于“被上方包含”；同一库也可能根据芯片、拓扑、数据方向和 CANN 版本选择完全不同的路径。

证据口径

事实来自官方规范、版本文档、公开源码或可复核 Git 历史；推断是由多个事实连接得到、但尚无官方一句话确认的判断；观点用于给出制图、迁移或验证建议。仓库首提交只代表“不晚于该日公开可见”，不能替代内部立项日期。

总体架构¶

先看总图，再读后面的概念卡。图中从上到下依次回答：程序选择什么通信语义、运行时如何建立地址和资源、谁提交任务、谁搬运数据，以及字节最终经过哪种互联。右侧的内存语义、零拷贝与 AIV 直驱是横向契约或属性，不能被误画成第六层传输协议。

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

阅读时应重点区分黄色主路径与紫色横向属性：相邻方框表示一次请求可能经过的责任边界，不表示上层只能依赖唯一后端，也不表示两个名词存在包含关系。

下面保留可复制、可搜索的 Mermaid 结构图；它与上图表达同一组关系，用于后续修改和局部引用。

flowchart TB
    subgraph APP["业务与算子"]
        FRAME["PyTorch / MindSpore / 训练与推理框架"]
        KV["Mooncake / KV Cache / 参数分发"]
        OP["自定义算子 / MC2 / 通算融合"]
    end

    subgraph API["通信语义与产品库"]
        HCCL["HCCL<br>集合通信"]
        HIXL["HiXL<br>Host 侧单边传输"]
        ADXL["ADXL compatibility<br>待废弃 API"]
        SHMEM["cann/shmem<br>PE + 对称内存 + RMA"]
        UBS["Mooncake UBShmem<br>VMM 映射快路"]
        TILE["TileXR<br>Tile 通信与融合算子"]
    end

    SEM["内存语义契约面<br>寻址 / 顺序 / 完成 / 可见性<br>原子性 / 一致性域 / 生命周期"]

    subgraph RES["资源、地址与运行时"]
        HCOMM["HCOMM<br>控制面 / 数据面资源"]
        VMM["CANN Runtime VMM<br>Reserve / Physical / Map / Access"]
        IPC["CANN IPC<br>导出 / 打开设备内存句柄"]
        SYM["SHMEM Runtime<br>Bootstrap / Team / 对称堆 / 注册"]
        UBMEM["UBMEM<br>UB 内存语义"]
        FM["Fabric Memory<br>远端物理内存映射模式"]
    end

    subgraph ENG["提交者与数据搬运引擎"]
        HOST["Host / AICPU 提交"]
        AIV["AIV 直驱<br>Device 侧提交与同步"]
        MTE["MTE<br>AI Core 内存搬运"]
        SDMA["SDMA"]
        RDMA["RDMA / RoCE Engine"]
        UDMA["UDMA<br>Ascend 950"]
        ACLCOPY["ACL Copy / LD-ST"]
    end

    subgraph FAB["互联与内存"]
        PCIE["PCIe / 片内 NoC"]
        HCCS["HCCS / SIO"]
        ROCE["RoCE / Ethernet"]
        UB["UnifiedBus / URMA"]
        MEM["Host DRAM / Device HBM-GM / Remote Memory"]
    end

    ZERO["零拷贝<br>跨层路径属性"]

    FRAME --> HCCL
    KV --> HIXL
    KV --> UBS
    OP --> SHMEM
    OP --> TILE
    ADXL -. "兼容层，迁移到新 API" .-> HIXL

    HCCL --> HCOMM
    HIXL -. "复用通信与运行时能力" .-> HCOMM
    HIXL --> VMM
    SHMEM --> SYM
    SHMEM -. "显式 RMA/AMO/同步语义" .-> SEM
    SHMEM -. "950 UDMA 资源" .-> HCOMM
    UBS --> VMM
    VMM -. "只覆盖映射、权限与生命周期的一部分" .-> SEM
    TILE --> IPC
    TILE --> HCCL
    TILE -. "UDMA 路径；公开真机验证待补" .-> SHMEM

    VMM --> FM
    IPC --> MTE
    SYM --> MTE
    SYM --> SDMA
    SYM --> RDMA
    SYM --> UDMA
    FM --> ACLCOPY
    HCOMM --> HOST
    HCOMM --> AIV
    HCOMM --> UBMEM
    UBMEM -. "UB 的内存语义实现路径" .-> SEM
    UBMEM --> UB

    HOST --> SDMA
    HOST --> RDMA
    HOST --> UDMA
    AIV --> MTE
    AIV --> RDMA
    AIV --> UDMA

    MTE --> PCIE
    MTE --> HCCS
    SDMA --> HCCS
    RDMA --> ROCE
    UDMA --> UB
    ACLCOPY --> HCCS
    ACLCOPY --> UB
    PCIE --> MEM
    HCCS --> MEM
    ROCE --> MEM
    UB --> MEM
    ZERO -. "逐路径检查中间副本" .-> VMM
    ZERO -.-> RDMA

图中最值得注意的是三条不能画成实线等号的关系：

UBShmem ≠ cann/shmem；
ADXL/HiXL Direct ≠ AIV Direct；
DMA/RDMA/UDMA ≠ 零拷贝。

关键时间线¶

总时间线分成三个阶段：通用机制与标准形成、昇腾公开软件栈成形，以及 Ascend 950 与 Device 直驱路径加速公开。下图用于建立整体节奏，后续表格保留精确日期、动机和证据边界。

图 2：通用通信机制、昇腾公开仓库与 Ascend 950 路线时间线。根据本文研究内容整理的自绘示意图。

图中 2025 年后的节点密度明显上升，但这只代表公开仓库和公开说明集中出现，不能倒推出对应项目都在 2025 年才内部立项。

日期	公开事件	动机或变化	证据边界
1954–1957	大型机 I/O Channel/Data Synchronizer 展现现代 DMA 的早期形态	让 I/O 与计算并行，避免 CPU 逐字搬运	“第一台 DMA”受定义影响，本文不锁定唯一发明者
1979-09	Leslie Lamport 给出 Sequential Consistency 的经典定义	用“各处理器程序序 + 全局单一顺序”约束并发内存可观察行为	它是内存一致性模型，不是后来所有硬件的默认实现
1990 年代	Cray SHMEM 编程模型形成；远程直接访存与 HPC 互联逐步商品化	用单边 Put/Get 减少消息匹配开销	这是通用 SHMEM/RDMA 历史，不是 CANN 项目时间
1999–2000	InfiniBand 行业组织和 1.0 规范形成	标准化高性能网络的远程内存、队列和完成语义	RDMA 不是由华为项目发明
2007-10	IETF 发布 RDMAP RFC 5040	固化 direct placement、STag 保护和远端操作顺序规则	这是 RDMAP/iWARP 规范节点，不是 RoCE 或 UB 的诞生时间
2010	IBTA 发布 RoCE v1	将 InfiniBand RDMA transport 承载在二层以太网上	受同一二层广播域约束，不是普通 TCP/IP
2010–2012	OpenSHMEM 标准化组织与首批公开规范	把不同厂商 SHMEM 方言收敛为统一 API	CANN SHMEM 借鉴编程模型，不等于完整兼容声明
2014-09-16	IBTA 发布 RoCE v2	以 UDP/IP 封装获得三层路由能力	仍需 RDMA NIC、MR/QP/CQ 与拥塞/无损网络工程
2018-10-10	华为公开昇腾全栈方案与 CANN 1.0	形成从芯片、算子到框架的软件栈	DMA/HCCL/HCCS 的内部立项日暂未核实
2020-08-10	CANN 3.0 与 AscendCL 公开	用 Runtime API 统一设备、内存、Stream 与任务管理	当前 GitCode runtime 仓库公开时间更晚
2022-08 起	openEuler UMDK 出现公开 Git 历史	以内存语义为核心开放 URMA、URPC、ULOCK、USOCK 等 UB 软件组件	公开提交不是华为内部 UB/UMDK 立项日
2025-03	UB-Mesh 论文公开	以 UnifiedBus、分层 FullMesh、路由和拓扑感知 collective 面向万卡集群	论文不是完整 UB 产品 ABI
2025-08-13 至 08-18	Mooncake PR #740 合入 Ascend Direct	把 HCCS/RDMA、注册和传输委托给 ADXL	`USE_ASCEND_DIRECT` 是 Host 侧库路径，不是 AIV 直驱
2025-10-14	`cann/hixl` 首个可见代码提交；README 称 2025-10 开源	面向 PD 分离、RL 参数切换、KV Cache 的多链路单边传输	内部 ADXL/HiXL 立项时间暂未核实
2025-11-30	HCCL/HCOMM 正式开源	集合通信与通信基础资源分层解耦	Git 首提交分别早于公告数周，不等于内部诞生时间
2025-12-12	`cann/shmem` 首个可见提交	面向昇腾的对称内存、RMA/AMO 与通算融合	README 称 2025-12 首次上线
2025-12-25	`cann/runtime` 首个可见提交	公开 Runtime 与维测组件	CANN Runtime 产品本身早于仓库公开
2025-12-30	TileXR 首个可见提交	Tile 级异步通信、IPC 共享窗口和融合算子	无公开 tag/release；不能据此认定内部立项日
2026-01-06	HiXL 仓首次加入 Fabric Memory 模式直传能力	用统一编址和远端 DRAM 扩展 KV Cache 层级	2026-03 README 才将其列为正式动态
2026-01-18 至 01-26	Mooncake PR #1399 合入 `USE_UBSHMEM`	将 CANN VMM/Fabric 映射做成独立专用快路	与 cann/shmem 没有名称上的包含关系
2026-02-09	CANN SHMEM `v1.0.0`/`v1.0.1` 可见标签	形成首批可识别公开版本	tag 日期是公开版本节点，不是立项日
2026-03	HCCL 宣布 Ascend 950 单算子支持 AIV/AICPU 引擎；HiXL 宣布 FabricMem	控制路径继续下沉，内存池化进入公开产品路径	具体接口仍受产品与 CANN 版本约束
2026-04-08	CANN SHMEM `v1.3.0`	新增 AICore 直驱与 40+ 接口	Device 侧直驱能力进入公开版本
2026-04-13	HiXL 文档新增“待废弃 ADXL 接口”	对外 API 从 ADXL 向 HIXL 收敛	ADXL 仍保留实现和头文件，尚未删除
2026-05-25 起	TileXR UDMA 设计与实现继续公开	在 IPC/MTE、HCCL/MC2 之外增加注册内存与 Device UDMA 路径	代码与验收脚本已闭环，但公开资料明确仍需 A5 真机数据面验证
2026-06-11	SHMEM 术语表明确 `xDMA = DMA family`	消除把 xDMA 当单一引擎的歧义	当前集合可扩展，不应写死为永久枚举
2026-07-30	CANN SHMEM `v1.6.0`	完善 Ascend 950 RDMA、UDMA/MTE、SIMT 与诊断	项目活跃，未废弃
2026-08-26	本文截止	HCCL、HCOMM、HiXL、SHMEM、Runtime 均有近期提交	“活跃”指公开仓状态，不代表所有历史 API 都长期兼容

仓库日期怎么读

公开首提交、正式开源公告、首个 release/tag 和内部立项是四个不同日期。本文能核验前三者时分别列出；不能核验内部立项时不会用“首次提交”偷换。

横向对比¶

概念	对象类型	主要回答	发起或参与者	地址/内存契约	常见下层	公开状态
内存语义	跨层访问契约	哪些内存操作、顺序、完成与可见结果被允许	CPU、NPU、NIC、DMA engine 等观察者	寻址、保护、原子性、顺序、可见性、一致性域、生命周期	由 VMM、SHMEM、RDMA、UBMEM 等分别实现不同子集	基础概念；没有单一仓库或统一废弃状态
DMA	通用机制	谁替计算单元搬字节	CPU、Runtime 或 Device 提交	DMA/IOVA、页表、权限	片内总线、PCIe、HCCS、UB	长期基础机制
xDMA	CANN 家族名	一组高速 DMA 后端如何统称	取决于具体后端	取决于 SDMA/RDMA/UDMA	多种链路	活跃术语，不是独立产品
RDMA	远程访存机制/网络语义	如何直接访问远端注册内存	Host/NIC 或 Device	MR、key、QP、CQ	InfiniBand/RoCE 等	活跃
RoCE	RDMA 的 Ethernet 承载	如何让 IB transport/verbs 运行在以太网上	RoCE RNIC/NPU 网络引擎	沿用 MR、QP、CQ；v2 增加 UDP/IP 外层	v1 为 L2；v2 可 L3 路由	v1/v2 均未废弃，v2 为主流
UDMA	CANN 具体后端	如何在 UB/Ascend 950 上做统一 DMA	Host/AICPU/AIV 可提交	队列、Token、注册内存	UB/URMA	活跃，硬件特定
HCCS	硬件互联	服务器内 CPU/NPU 或 NPU 间怎么连	DMA/Load-Store 等使用	由平台和 Runtime 暴露	电/光链路、SIO 等	A2/A3 等平台活跃
UB	互联与协议体系	超节点内外的事务如何寻址、路由和传输	CPU、NPU、NIC、存储等多类发起者	EID、UMMU、Transaction/Transport、URMA	灵衢 Fabric、UBoE	新一代、活跃
UBMEM	UB 内存语义路径	如何把远端内存暴露为受保护、可操作的地址对象	HCOMM Endpoint/Channel、AIV/AICPU 等	注册、元数据交换、映射、远端访问契约	URMA/UB + UDMA/MTE 等资源	950 路径活跃；不是物理内存类型
HCCL	集合通信库	一组 rank 如何完成 collective	Host、AICPU、AIV 引擎	Rank、communicator、buffer	HCOMM + 多传输	活跃
SHMEM	单边内存库	PE 如何访问对称内存	Host 与 Device API	PE、Team、对称堆、RMA	MTE/SDMA/RDMA/UDMA	活跃
HiXL / ADXL	单边传输产品/API	应用如何跨多链路传一批 buffer	当前公开路径主要由 Host API 发起	注册内存、engine、request	HCCS、RDMA、FabricMem、UB	HiXL 活跃；ADXL 待废弃
IPC	进程间机制	不同进程如何共享句柄或地址	Host Runtime 建立映射	导出/打开 handle、peer VA	MTE/ACL copy/LD-ST	活跃
CANN VMM	内存管理 API	VA、物理页和权限如何拆分管理	Host Runtime	Reserve、Physical、Map、SetAccess	驱动页表/Fabric handle	活跃
Fabric Memory	部署/访问模式	如何把远端物理内存纳入本地可访问空间	Host/AICPU/Copy engine	VMM + 共享句柄 + 统一编址	HCCS 或 UB Fabric	活跃、平台受限
Mooncake UBShmem	项目专用 transport	KV Cache 如何走映射快路	Host worker + ACL stream	VMM/Fabric/IPC mapping	ACL copy	活跃；非 cann/shmem
TileXR	算子通信工具包	Tile 与融合算子如何组织通信	Host 建资源，AICore kernel 使用	`CommArgs`、peer window、UDMA registry	IPC/MTE、HCCL/MC2、UDMA	活跃；逐路径成熟度待验证
零拷贝	数据路径属性	中间软件副本是否被消除	不固定	不固定	DMA、映射、P2P 均可能	不是产品
AIV 直驱	控制路径属性	谁生成并提交通信任务	AIV/Vector Core	Channel、WQE、Notify、完成状态	MTE/RDMA/UDMA 等	新增支持中，严格依版本

基础机制¶

内存语义¶

先消歧

内存语义不是一种硬件、链路或软件仓库。狭义内存模型规定并发读写的允许观察结果；广义系统内存语义还包括地址、映射、权限、完成、可见性、原子性和生命周期。华为资料中的 UBMEM 又是第三个更具体的口径：它是远端内存注册、元数据交换、映射和地址式访问的一条实现路径，不是所有内存语义问题的总称。

小白版。内存语义像多人协作仓库的操作章程。生产者先把张量写进货架，再把 ready=1 的牌子翻过来；消费者看到牌子后才能取货。若系统只保证“两个动作最终都会发生”，却没有保证“货先到、牌子后翻且消费者此时已能看见货”，消费者就可能读到新牌子和旧张量。内存语义正是规定：谁能访问哪个货位、读写能否重排、何时算完成、其他观察者何时可见、并发改同一计数器是否原子。

在 Ascend SHMEM 中，一个具体做法是先 put 数据，再用 fence/quiet、put-with-signal 或匹配的 wait/barrier 建立发布与消费关系；具体选哪一个必须服从 API 的完成与内存序定义。类比有效之处是“门禁、操作顺序、收货回执和他人可见”确实是不同问题；失真之处是硬件里没有单一仓库管理员，编译器、cache、write buffer、DMA 队列、NIC、互联和远端执行单元都可能是独立观察者。

专业版。“内存语义”至少有三种常见口径：

狭义内存模型或内存一致性模型规定并发 load、store、atomic、fence 的允许执行和 read-from 结果，核心是 ordering、visibility、atomicity 与 consistency；它通常不负责虚拟地址映射、MR 注册和链路路由。Lamport 在 1979 年给出了 Sequential Consistency 的经典定义，现代 Arm、GPU/NPU 和分布式 RMA 系统通常暴露更弱、带作用域的顺序，需要显式同步。
广义互联或产品内存语义还把“远端内存能否像本地对象一样被命名和操作”纳入契约。openEuler UMDK 把 URMA 描述为统一内存语义，提供单边、双边和原子远端操作；CANN SHMEM 术语表则公开对称内存、RMA、AMO、Signal、Fence、Quiet、Sync/Barrier。本文讨论 UB/UBMEM 时采用这一广义口径，但把其中严格的可观察行为单独称为“内存序/一致性”。
UBMEM 产品语境强调把远端内存注册、交换元数据并映射为可寻址对象，再由 HCOMM/AIV 等路径使用；它是 Ascend 950 上的一种具体后端协议语义，不是语言级 memory model，也不是第三种物理介质。

子问题	它真正回答什么	Ascend/UB 例子	不能据此推出
放置与介质	字节物理上在哪里	Host DRAM、Device HBM/GM、Remote Memory	可被任意发起者访问
寻址与保护	谁能用哪个地址、key 和权限访问	CANN VMM、IPC key、MR、UMMU、EID	已经完成或对端已可见
数据放置	payload 最终落入业务 buffer 还是 staging buffer	RDMA direct placement、HCCL buffer、SHMEM 对称对象	没有网络或内存流量
运输与执行	谁搬数据、经过什么链路	MTE/xDMA、RDMA over RoCE、UDMA over UB	自动获得强一致或全局地址
操作集合	能做 load/store、put/get、message 还是 atomic	SHMEM RMA/AMO、URMA Memory/Message/Atomic	所有操作具有同样顺序
原子性	一次更新是否不可分割	atomic add、swap、compare-swap	对其他地址也自动保序
顺序	哪些操作不能越过哪些操作	fence、acquire/release、队列内 ordering	前序操作已经远端完成
完成与可见性	何时可复用源 buffer，何时目标或消费者能看见结果	local/remote completion、quiet、signal/wait	cache 自动一致或数据已持久化
一致性与 coherence 域	多个观察者允许看到哪些值和顺序	CPU/NPU/device shareability、CMO、协议作用域	强一致覆盖所有节点和所有地址
所有权与生命周期	当前谁可安全访问，注册、映射和 key 要存活多久	VMM handle、IPC import、Endpoint/Channel、MR	资源可跨进程永久使用或异步完成前可 free
持久性	数据能否跨掉电、进程崩溃或设备复位保存	普通 DRAM/HBM 路径通常不承诺	remote completion 就等于 durable

两个关键不等式

Coherence ≠ Consistency。缓存一致主要约束同一地址的副本如何收敛，不能自动保证不同地址上的 payload 与 flag 按程序序被观察。Completion ≠ Visibility。提交返回、CQE 或本地完成不必然表示任意远端 CPU/AICore 已能安全消费；必须检查具体 API 的完成范围、通知和缓存维护规则。

与栈内对象的关系。CANN VMM 和 IPC 主要解决寻址、映射、权限与生命周期；DMA、UDMA 和 RDMA 执行数据操作，RoCE 只是 RDMA 的 Ethernet 承载；SHMEM 定义对称对象、RMA/AMO 与同步；UB 是互联体系，URMA 暴露远端操作，UBMEM/HCOMM COMM_PROTOCOL_UB_MEM 是具体内存语义路径。Fabric Memory 组织远端物理内存的映射和池化，零拷贝只统计中间副本，AIV 直驱只改变提交者。它们各自实现内存语义契约的一部分，任何一个词都不等于整份契约。

公开实现证据。HCOMM 的 Fence 文档只约束同一通信线程和 Channel 上屏障前后的读写完成顺序，不能外推成所有 CPU、AICore 和 cache 的全局强序；URMA API 又把 place_order、comp_order 和 fence 分开暴露，且支持度依传输模式而变。这正说明放置顺序、完成顺序、屏障和消费者可见性是四个要分别核对的契约，不是一个“已完成”布尔值。

历史与状态。1979 年 Sequential Consistency 是通用理论里程碑；1990 年代 SHMEM 把远端内存操作做成 PGAS API；InfiniBand/RDMA、OpenSHMEM 和 RoCE 又分别标准化队列/RMA、编程模型与 Ethernet 承载。华为/灵衢公开线索可追到 openEuler UMDK 的 2022 年公开 Git 历史，以及 2025 年 UB 2.0、2025–2026 年 HCOMM/SHMEM/UBMEM 的开放实现。“内存语义”不是一个独立仓库，不能给它填写单一立项日或废弃日；能版本化和废弃的是具体协议、API 与保证强度。

术语对应。货位门牌对应 addressability，门禁对应 protection/key，操作章程对应 operation semantics，先放货后翻牌对应 ordering，收货回执对应 completion，消费者实际看到新货对应 visibility，不可分割改库存对应 atomicity，多份账本保持同一货位更新顺序对应 coherence，撤销门禁与释放货位对应 lifetime/revocation。

易错点。Cache coherence 不等于跨地址的强一致性；atomic 只保证指定更新不可分割，不自动给周围普通读写加序；DMA/RDMA 完成的精确含义依 API 而定，不能把 CQE 一律解释为远端 CPU/NPU 已可消费；VMM 映射、零拷贝或“像本地指针”都不自动提供同步、持久化和故障原子性。

检查理解：

为什么“进程 B 能导入进程 A 的 Device VA”只回答了内存语义契约的一部分？
AIV 先 nonblocking put 张量、再写远端 ready flag 时，至少需要核对哪些顺序、完成和可见性保证？
一条 UB 链路支持原子写且多个端点能缓存远端数据，为什么仍不能推出系统对所有地址满足 Sequential Consistency？

DMA¶

小白版。DMA 像一支专门的搬运队。CPU、AICPU 或 AIV 填写“源地址、目的地址、长度和完成方式”后，搬运引擎沿片内总线、PCIe、HCCS、RoCE 或 UB 推进数据，计算单元不再自己执行逐字节读写。搬运队、搬运单、门牌和回执分别对应 DMA engine、descriptor/WQE、DMA/IOVA 地址和 Event/CQ/Fence。

类比的边界是：DMA 仍然真的移动了数据，通常不是“零拷贝”；“Direct”也不表示没有软件控制，更不表示可以越过 IOMMU、页表、注册与权限访问任意地址。

专业版。DMA 是让 I/O 设备、加速器或专用数据引擎绕开通用 CPU 的逐字节 load/store 循环，对可访问内存执行传输的机制。典型流程是：固定或注册页面，建立 IOVA/设备页表映射，生成单段或 Scatter-Gather descriptor，提交队列并写 doorbell，DMA 读源写目的，最后产生完成记录。非一致系统还要显式处理 cache flush/invalidate 与 memory barrier。Linux 的 DMA API明确区分 CPU 虚拟地址、物理地址和设备使用的 DMA 地址；CANN 的异步复制则以 Stream/Event 管理任务依赖。

栈内位置。VMM、SVM、IPC 或内存注册回答“地址能否被访问”；DMA 回答“由谁移动字节”；HCCS、PCIe、UB 回答“字节走哪条路”。因此总图把 DMA 家族放在运行时和互联之间。

历史、硬件与状态。1950 年代 I/O Channel 是现代 DMA 的早期祖先；2018 年公开的昇腾/CANN 全栈已把数据搬运作为基础能力，但华为内部 DMA 立项日暂未核实。当前 Runtime、Driver、HCOMM 和 SHMEM 均保留活跃的 DMA 路径；DMA 机制本身没有被废弃。不同 SoC 只是具体 DMA 单元、Channel 数量和链路不同。

易错点。DMA 不等于链路，不等于零拷贝；异步 API 返回也不等于完成。

检查理解：

为什么 DMA 不由 CPU 搬每个字节，却仍可能需要 CPU 初始化和收尾？
Pageable Host 内存经中转页再 DMA 到 NPU 时，能否称为端到端零拷贝？
两个进程共享同一物理页而没有 payload 复制时，DMA 是否必然发生？

xDMA¶

小白版。在 CANN SHMEM 语境中，xDMA 是“各种高速 DMA 搬运车”的类别牌，不是一辆叫 xDMA 的车。当前车队里可以有 SDMA、RDMA/RoCE 和 UDMA；MTE 在 SHMEM 的后端分类中与 xDMA 车队并列。

这个类比不能带到所有资料：AMD/Xilinx XDMA 是一套具体 FPGA PCIe DMA IP/驱动；华为光接入论文里的 xDMA 甚至是多址接入技术族。大小写不足以消歧，必须写出命名空间。

专业版。CANN SHMEM 术语表把 xDMA 定义为 Direct Memory Access family。公开引擎枚举只有 MTE、SDMA、ROCE 和 UDMA，并没有名为 ACLSHMEM_DATA_OP_XDMA 的具体后端。因此合理的包含图是：

CANN::xDMA-family
├── SDMA
├── RDMA / RoCE
└── UDMA

MTE  // 在 SHMEM 后端分类中与 xDMA 并列

这个集合用于表达当前公开实现，可继续扩展，不能当作永久封闭枚举。xDMA 没有独立仓库和独立 release；它随 cann/shmem、HCOMM 或 MemFabric 的实现演进。

同名旁支。AMD/Xilinx XDMA 面向 Host 内存与 PCIe FPGA Endpoint 的 H2C/C2H Scatter-Gather 传输；华为 FX600 示例使用的是 Xilinx 原生 XDMA IP，不是华为自研昇腾引擎。总架构图只保留 CANN::xDMA-family，其余放入同名异义说明。

历史与状态。cann/shmem 于 2025-12 首次上线；2026-06-11 的术语表提交正式消除了族名歧义。当前 xDMA 抽象活跃且无废弃公告。AMD XDMA 也仍在维护，但与本文昇腾主线无包含关系。

易错点。不能把 xDMA 画成 SDMA、RDMA、UDMA 之外的第四个引擎；不能从 SHMEM 的 xDMA 分类反推 HCCL 的所有私有实现。

检查理解：

为什么 xDMA 不能与 SDMA、RDMA、UDMA 并列？
日志出现 /dev/xdma0_h2c_0 且硬件是 Xilinx FPGA 时，应归入哪条技术线？
“RDMA 属于 xDMA”在哪个命名空间下成立，在哪些上下文会误导？

RDMA¶

小白版。RDMA 像让本地网卡拿着经过授权的库位编号，直接把货写入远端仓库。远端 CPU 不必为每一批货执行配对接收，但双方仍要先建仓、登记地址、交换钥匙并建立运输队列。

类比的边界是：真正系统还有内存注册、页表、QP 状态机、重试、拥塞控制、完成队列和内存序；“远端 CPU 不处理 payload”不等于对端完全没有控制面。

专业版。RDMA 是通过网络或设备互联对远端已注册内存执行 READ、WRITE、SEND/RECV 或 Atomic 的机制与队列模型。典型对象包括 Protection Domain、Memory Region、lkey/rkey、Queue Pair、Work Request/WQE、Completion Queue/CQE。InfiniBand 是原生 RDMA Fabric；RoCE 把 RDMA 语义承载于以太网。单边 READ/WRITE 不要求远端应用逐次贴出匹配 receive，但建链、注册和异常恢复仍需软件参与。

昇腾位置。RDMA/RoCE 可以是 HCCL/HCOMM 的跨节点传输、HiXL 的单边后端，也是 CANN SHMEM 的 xDMA 后端之一。它与 HCCS/UB 不是同一抽象：前者强调远端内存和队列语义，后者强调具体互联体系。

硬件与状态。RDMA 依赖支持 verbs/URMA 类资源的 NIC、Device 或互联，硬件矩阵与 CANN、HDK、网卡及无损网络配置共同决定。当前 HCCL、HiXL、SHMEM 均继续增强 RDMA，未见废弃公告。

易错点。RDMA 不等于 RoCE；RDMA 也不自动保证零拷贝，应用缓冲区、注册方式和中转池仍可能增加副本。

检查理解：

RDMA WRITE 为什么可以不让远端应用贴出一条匹配接收？
已经使用 RoCE 时，为什么还要关心 PFC、拥塞、MR 和 CQ？
如果数据先复制到注册的 staging buffer 再 RDMA，哪一段破坏了端到端零拷贝？

RoCE¶

小白版。把 RDMA 看成仓库机器人的作业规则：MR 是获准访问的货架，QP 是收发车道，CQ 是完成回执箱。RoCE 是让这套规则跑在 Ethernet 道路上。RoCE v1 只在同一二层园区通行；RoCE v2 给报文套上 IP/UDP 外层，可以经三层路由跨子网，目的 UDP 端口为 4791。

PFC 像某优先级车道逐跳亮红灯暂停，ECN 则让交换机给拥堵报文盖章，接收端返回 CNP，发送端再降速。类比的边界是：RoCEv2 不是普通 UDP socket；可靠性、顺序、PSN、ACK/NAK 与重传仍由 InfiniBand transport/QP 类型实现，UDP 主要承担可路由封装和选路熵。

专业版。RoCE（RDMA over Converged Ethernet）是 IBTA 定义的 InfiniBand RDMA transport over Ethernet，不是 RDMA 能力本身，也不是 verbs API：

HCCL / HiXL / CANN SHMEM / 存储框架
  → verbs：PD + MR(lkey/rkey) + QP(SQ/RQ) + CQ
  → IB transport：RC / UC / UD 等语义
  → RoCE v1：Ethernet L2
     RoCE v2：UDP/IP over Ethernet
  → RoCE RNIC/NPU 网络引擎 + Ethernet switches

维度	RoCE v1	RoCE v2
外层	Ethernet 二层封装	Ethernet + IPv4/IPv6 + UDP
路由范围	同一 L2 域，不能跨 IP 子网	可经标准 L3 路由
QoS 线索	VLAN/PCP	DSCP/ECN、UDP 4791
上层对象	QP、MR、CQ、verbs	QP、MR、CQ、verbs 基本不变

IBTA 于 2010 年发布首版，2014-09-16 发布 RoCEv2。v1 仍有实现支持，v2 是大型可路由数据中心的主流选择；截至研究截止日均无标准废弃公告。PFC 是 IEEE 802.1Qbb 的逐跳、按优先级 pause，不是 RoCE 报文格式；ECN/CNP/发送端算法构成拥塞反馈，DCQCN 只是常见实现而非唯一选择。只开 PFC 可能造成队头阻塞、pause 扩散甚至死锁，不能写成“开启即绝对无损”。

在昇腾栈中。HCCL、HCOMM、HiXL 和 CANN SHMEM 可把 RoCE 作为跨节点数据面；HCCS 是专用 scale-up 互联；UnifiedBus 是另一套计算互联与内存语义；UBoE 是 UB over Ethernet。UBoE 与 RoCEv2 即使都使用 UDP/IP/Ethernet，承载的上层协议、地址资源和控制栈仍不同，绝不是 RoCEv3。A2/A3 长期保留 Device RoCE；950 增加 Device UB/UBoE/UDMA，但 Host RoCE、XSCALE/HNS 1825 RDMA provider 等路径仍存在，因此属于重心迁移而非全局 EOL。

术语对应。登记货架是 MR/lkey/rkey，机器人车道是 QP 的 SQ/RQ，任务单是 WR/WQE，回执箱是 CQ/WC，园区内送货是 RoCE v1，IP 信封跨城是 RoCE v2，逐跳红灯是 PFC，拥堵盖章并反馈降速是 ECN→CNP→RP。

易错点。RoCE、RDMA 与 verbs 分属承载、能力和 API；RoCEv2 不是普通 UDP 应用；PFC 不等于拥塞控制或绝不丢包；UBoE 不是 RoCEv2 的别名。

检查理解：

为什么 RoCE v1 不能跨 IP 子网，而 v2 可以？上层 verbs 是否必须重写？
已开启 PFC 却出现长尾和 pause 扩散，应怎样检查 ECN、CNP 与发送端调速闭环？
950 的 Host RoCE 与 AIV UBoE 都经 Ethernet 时，为什么仍是两条不同协议栈？

UDMA¶

小白版。UDMA 是 Ascend 950/UB 路径上的一类具体“远端搬运车”。AIV 或 Host 把远端目标、长度和权限写成 WQE 放进发送队列，UDMA 引擎沿 UB/URMA 访问远端内存，最后通过 CQ 或 quiet() 告知完成。

“Unified”表示它服务于统一互联和多类内存访问，不表示能在所有昇腾芯片上替代 MTE、SDMA 或 RDMA；早期文档偶尔把 UDMA 展开为 User-space DMA，本文采用当前 SHMEM 术语表的 Unified Direct Memory Access。

专业版。CANN SHMEM 把 UDMA 列为 xDMA 具体后端，围绕 QP/队列、内存注册、Token、WQE、CQ 和 RMA/AMO 组织数据面。Device 侧低阶 API 可以由 AIV 直接生成和提交 WQE；高阶接口则在 SHMEM 的 PE、对称地址和内存序语义下封装它。WQE 可能经 UB/MTE 暂存下发，但大块 payload 由 UDMA 执行，不能据描述符下发路径把 UDMA 误判成 MTE payload copy。

硬件、时间与状态。当前 SHMEM Quick Start 把 UDMA 限定到 Ascend 950，并要求 CANN 9.1.0、对应 toolkit/ops 与 HCOMM 资源接口。2026 年 SHMEM v1.3–v1.6 持续补齐 AICore 直驱、UDMA/MTE、Atomic 和示例；它是活跃新后端，不是废弃接口。

易错点。UDMA 不是所有 DMA 的新名字；UDMA enabled 也不意味着任何旧算子会自动获得透明回退和加速。

检查理解：

UDMA 与 URMA、UB 分别处在哪三个抽象层？
为什么 UDMA 的描述符可能经过 MTE，却仍不能说 payload 由 MTE 搬完？
在 A3 上运行的程序能否仅凭升级 SHMEM 就假设 UDMA 可用？

通信与互联¶

HCCL¶

小白版。把多张 NPU 想成分头做题的学生。每个人算完一份梯度后都要拿到总和是 AllReduce；每个人都要收齐所有人的分片是 AllGather；人人向不同目标发送不同块是 AlltoAll。HCCL 像物流总调度：识别要完成的集体任务，再根据人数、数据量和道路拓扑选择 Ring、Mesh、RHD、Pipeline 等方案。

HCOMM 更像基础设施部门，负责通信域、RankGraph、Endpoint、Channel、内存、Notify 和读写归约原语。真实系统没有一台中央服务器逐包指挥；各 rank 按一致的算法并发推进。

专业版。狭义 HCCL 是 cann/hccl 的集合通信算子、算法选择、executor、template 与拓扑适配；广义官方口径则由 HCCL 集合通信库 + HCOMM 通信基础库组成。典型调用链是：

框架 collective/P2P API
  → HCCL selector / executor / template
  → HCOMM control plane + data plane resources
  → HOST / AICPU_TS / AIV / CCU
  → HCCS / PCIe / RoCE-RDMA / UB

HCCL 负责“整个通信组做什么、怎样拆阶段和分块”；HCOMM 负责“有哪些资源、通道和基础动作”；链路和 DMA 引擎负责真正搬运。单算子/图模式是框架接入维度，HOST/AICPU/AIV/CCU 是通信算法展开与执行维度，两者不能混成一列。

历史。公开 MindSpore 文档证明 HCCL 至少在 2020-03 已作为产品能力使用。旧 Ascend/cann-hccl 参考代码仓于 2024-07 可见；当前 cann/hccl 和 cann/hcomm 双仓分别在 2025-11-15、2025-10-17 出现首提交，并于 2025-11-30 宣布正式开源。2026 年继续加入 Ascend 950 AIV/AICPU、图模式和静态库，7 月发布 v9.1.0/v9.2.0-beta.1，HCCL 整体未废弃。旧 Gitee 仓 Paused 更应理解为仓库迁移或参考线停止，不能当作产品 EOL。

硬件。当前栈覆盖 Ascend 950、A3、A2 及部分更早训练/推理产品，但协议和执行引擎矩阵并不一致：950 引入 UB、UBMEM、AIV/CCU 等新资源；A2/A3 仍主要出现 HCCS、RoCE 和不同 Host/AICPU 路径。

易错点。HCCS/RDMA/UDMA 是 HCCL 的可用下层，不是与 AllReduce 同层的替代品；HCCL 也不等于某一种 Ring 算法。

检查理解：

如何同时解释“HCOMM 是 HCCL 基础库”和“HCCL 包含 HCOMM”两句话？
小数据 AllReduce 使用 AIV 引擎时，算法、Channel、AIV 执行和 UB/HCCS 分别在哪一层？
仅用 UDMA Put 写远端显存，为什么不能直接称为 HCCL AlltoAll？

HCCS¶

小白版。HCCS 是厂区内部的高速轨道，SDMA 是轨道上的自动货车，HCCL 是物流调度中心。A3 中还可把 SIO 看成同一紧耦合模组内的短桥，RoCE 看成去远端园区的公路，UB 看成新一代统一轨道体系。

类比不能推出“用了 HCCS 就有应用透明共享内存”。昇腾 Host 与 Device 仍可能有独立地址空间，应用还要显式复制、IPC 映射或 VMM 注册；全称中的 Cache Coherence 也不能替代对具体一致性域的核验。

专业版。当前昇腾术语推荐全称是 Huawei Cache Coherence System；部分早期资料写 Cache Coherent System，暂无证据表明是两个协议版本。在鲲鹏 CPU 语境中，HCCS 连接 die/socket 并参与真正的缓存一致性体系；在昇腾语境中，它是 HCCL/HCOMM 可使用的高带宽 NPU 互联和通信协议。Profiler 把 HCCS 列为 link type，把 SDMA 列为 transport type，直接说明典型路径是 SDMA over HCCS，而不是两个同义词。

HCCL collective algorithm
  → HCOMM/HCCP 控制适配
  → SDMA 搬运任务
  → HCCS / HCCS_SW 链路
  → 对端 NPU HBM

与 SIO 的边界。A3 公开拓扑中，两个处理器/die 通过 SIO 形成 HiAM，HiAM 间走 HCCS-L1，计算节点间走 HCCS-L2，不同逻辑 SuperPoD 再走 RoCE。SIO 与 HCCS 在 CANN 中也是独立协议枚举。

代际与状态。公开产品证据至少可追到 2019 年的 Kunpeng 920 四路服务器和 Ascend 910/Atlas 900。A2、A3 和部分鲲鹏产品截至本文日期仍使用 HCCS；Ascend 950 的 scale-up 主路径转向 UB 2.0。HCCS 无独立公开数据面仓和完整协议规范，也没有整体废弃公告，因此准确说法是在 950 上被 UB 局部替代，在 A2/A3/鲲鹏上仍活跃。

公开灰区。华为 2025 年演讲把 Atlas 900 A3 SuperPoD 称为 UB 1.0，当前 CANN/MindCluster 文档又继续暴露 SIO、HCCS-L1/L2。公开资料不足以判断 UB 1.0 与 HCCS 是封装、复用、兼容模式还是品牌层次，不能直接写 UB 1.0 = HCCS。

易错点。HCCS 不是 HCCL，不是 SDMA，也不能仅凭名字推出任意 CPU/NPU 指针透明一致。

检查理解：

如何用“路线、车辆、调度中心”区分 HCCS、SDMA 和 HCCL？
A3 的 HiAM 内、HiAM 间、节点间和逻辑 SuperPoD 间分别可能使用什么链路？
产品手册只写“支持 HCCS”时，还要查哪些信息才能判断能否透明 load/store？

UB¶

先消歧

SuperPoD、EID、URMA、UBoE 语境中的 UB 是 UnifiedBus（灵衢）；Ascend C 算子里的 __ubuf__、LocalTensor、ub2gm 则是 AI Core 片上的 Unified Buffer。后者是核内暂存空间，不是前者的一层。

小白版。UnifiedBus 像把芯片、加速卡、节点和内存池接成一台大机器的交通体系：EID 是门牌，UMMU 负责把统一地址翻译到真实内存，UB Controller 处理协议，URMA 的 Jetty/工作请求则像异步快递单。应用通常通过 HCCL、HCOMM、SHMEM 或内存服务使用它，而不是直接“调用一根总线”。

这个类比的边界是：UB 不只是物理道路，还规定寻址、事务、流控、可靠性、内存和管理语义；“像访问本地内存”也不等于远端延迟、故障和一致性真的与本地 HBM 相同。

专业版。UnifiedBus 是面向 SuperPoD 的互联技术和分层协议栈。公开 2.0.1 规范覆盖 Physical、Data Link、Network、Transport、Transaction 和 Function 层；上层可使用同步 Load/Store，也可用 URMA/Jetty 异步提交 Memory、Message、Atomic 等事务。典型软件关系是：

HCCL / SHMEM / HCOMM / UB Service Core
  → URMA、liburma、UB OS 组件
  → UMMU、UB Controller、交换网络
  → 原生 UB PHY 或 UBoE 承载

华为称 2019 年开始研究 UB；openEuler/umdk 的公开 Git 历史可追至 2022-08；Atlas 900 A3 被公开称为 UB 1.0 落地，2025-09-18 发布 UB 2.0 和 Atlas 950 路线。截至研究截止日，规范与软件仍在活跃演进。A2/A3 的 HCCS 与 950 的 UB 重心迁移更适合画成按代际和拓扑并存，而不是宣称 UB 已全面删除 HCCS、PCIe 或 RoCE。

术语对应。统一交通网是 UnifiedBus，门牌是 EID，地址翻译与权限检查是 UMMU，同步访问是 Load/Store 模型，异步投递与完成是 URMA Jetty/JFC，在 Ethernet/IP 上承载 UB 事务是 UBoE。

易错点。UB 不是 HCCL，也不是 URMA API；UBoE 不是 RoCE 的别名；支持 UB 不自动等于端到端零拷贝或 CPU cache coherent。

检查理解：

DataCopy(dstGm, srcUb) 中的 UB 为什么不是 Atlas 950 的 UB 端口？
一次 URMA 单边写至少会经过哪些软件对象和协议层？
只知道产品支持 UBoE，为什么不能推出它使用 RoCE verbs？

内存与运行时¶

UBMEM¶

小白版。UBMEM 像先让两端登记仓库、交换门禁和柜位，再把远端柜位映射成当前进程可使用的地址视图。Endpoint/Channel 主要负责“双方认识并完成映射”，后续 payload 可以由 AIV、UDMA、MTE 等资源访问映射地址；Channel 本身不一定像传统网络 Send/Recv 那样承运每一箱数据。

类比的边界是：本地式地址不等于本地性能或本地故障模型，也不表示任意指针自动获得权限、缓存一致性和全局可见性。

专业版。CANN SHMEM 把 UBMEM/UBmem 定义为“内存语义”；HCOMM 则把它编码为 COMM_PROTOCOL_UB_MEM，由 UbMemEndpoint、AivUbMemChannel、AivUbMemTransport 等组件建立注册、元数据交换和映射。它不属于 CommMemType：实际内存仍是 Host DRAM 或 Device HBM，因此 UBMEM 是协议语义和 HCOMM 后端，不是第三种物理内存。

HCCL / SHMEM / MoE 算子
  → HCOMM engine + Endpoint + Channel
  → COMM_PROTOCOL_UB_MEM：注册、交换、映射
  → URMA/UB 地址和访问能力
  → AIV、UDMA、MTE 等执行资源

HCOMM 公开仓首提交为 2025-10-17；公开 API 中 COMM_PROTOCOL_UB_MEM 可追至 2026-03-30，当前实现路径在 2026-06-03 的架构调整中出现。这些是公开可见时间，不是内部立项时间。当前公开支持矩阵只在 Ascend 950PR/950DT 的 AICPU_TS 与 AIV engine 下列出 UB_MEM；A2/A3 未列出。实现仍在 master，属活跃演进而非废弃。

术语对应。登记仓库是通信内存注册，交换柜位是 Channel 元数据交换，远端柜位成为本地编号是 remote mapping，真正搬箱子的是 UDMA/MTE/AIV，跨节点统一仓库治理则是更上层的 Fabric Memory/MemFabric。

易错点。UBMEM 不是内存介质，不是 Unified Buffer，也不等于 URMA、UDMA 或完整 Fabric Memory；HCCL 文档中的“支持 UB”还可能指 UB_CTP、UB_RTP、UBoE，不能全部窄化为 UB_MEM。

检查理解：

为什么存在 COMM_PROTOCOL_UB_MEM，却没有 COMM_MEM_TYPE_UB_MEM？
已取得远端 buffer 的本地映射地址后，Endpoint、Channel 与 UDMA/AIV 分别还做什么？
系统支持 URMA 或 Fabric Memory，能否推出 HCOMM 必然选择 UB_MEM？

SHMEM¶

四个同名对象

Cray SHMEM 是 1993 年起的历史实现；OpenSHMEM 是厂商中立的 PGAS API 标准；cann/shmem 是面向昇腾的 OpenSHMEM 风格实现与扩展；POSIX/System V shared memory 则是同一 OS 上的共享页机制。Mooncake 的 UBSHMEM 还是另一个项目专用 transport 名，不能仅凭名字合并。

小白版。SHMEM 像让一组编号分店各自按相同规则摆放一套“对称货架”。PE 0 可以把货 put 到 PE 3 的对应货位，也可以 get 回来，或用 atomic add 不可分割地更新计数器；Team 是参与操作的分店子集，quiet 等待此前搬运完成，fence 约束先后次序，barrier 则让一组 PE 在检查点会合。

类比的边界是：对称不表示虚拟地址、数据值或物理内存完全相同，只表示实现能从“本地对称对象 + 目标 PE”定位远端对应对象。单边 payload 也不表示初始化、建 Team、分配和异常处理完全不需要多方协商。

专业版。OpenSHMEM 是 PGAS 模型：物理内存仍分区归属各 PE，逻辑上允许对 symmetric object 做 RMA put/get、AMO、signal、wait、collective 和同步。cann/shmem 把这套语义映射到 Ascend Host/Device API：Host 侧负责 bootstrap、PE/Team、对称堆、Stream 和 transport；Device 侧允许 AICore/SIMT kernel 直接发起 RMA、AMO 和同步。

模型 / 自定义算子 / 通算融合
  → aclshmem_* / aclshmemx_*：PE、Team、对称堆、RMA、AMO、Sync
  → CANN Runtime / VMM / HCOMM 资源
  → MTE、SDMA、RDMA、UDMA
  → PCIe、HCCS/SIO、RoCE、UB

OpenSHMEM 1.0 于 2012 年发布，当前正式规范为 2024 年发布的 1.6。cann/shmem README 称 2025-12 首次上线，2026-02 有首批 v1.0 tag，v1.3 在 4 月加入 AICore 直驱和更多 API，v1.6 在 7 月继续完善 Ascend 950 的 UDMA/MTE/RDMA/SIMT。A2/A3 的 910B/C 主要使用 MTE、SDMA、RDMA；950 增加 UB/UDMA。项目活跃，但公开资料不足以声称它通过了完整 OpenSHMEM 1.6 一致性测试；cann/shmem v1.6 与标准版本号相同只是巧合。

术语对应。分店编号是 PE，分店小组是 Team，对应货架是 symmetric heap，远端写/读是 put/get，原子改数是 AMO，等本人发出的任务完成是 quiet，规定远端操作顺序是 fence，逻辑统一而物理分散是 PGAS。

易错点。SHMEM 不是 Linux 共享内存；对称堆不是一块全局物理 RAM；SHMEM 可以有 collective，HCCL 也不是它的子集；put 返回是否足以让远端消费取决于 blocking、quiet、signal 和内存序；底层也不必固定为 RDMA。

检查理解：

为什么对称堆既不是所有 PE 共用一块物理内存，也不要求数据值相同？
nonblocking put 后 PE 3 的 kernel 要安全读取，还需要哪些完成或通知步骤？
一个名为 USE_UBSHMEM 的开关需要哪些调用符号证据，才能认定它使用 cann/shmem？

UBSHMEM¶

小白版。Mooncake 的 UBShmem 像先把一段远端 NPU HBM 的“房卡”放入元数据：源进程导入 Fabric handle 或 IPC key，把远端地址重定位为本进程可用的 VA，然后让 ACL stream 上的 aclrtMemcpyAsync 搬运 KV Cache。映射会被缓存，后续传输可以复用。

类比的边界是：房间没有被搬到本机，payload 仍然发生设备数据搬运；“shared memory”只表示可共享和重映射的设备内存，不是 OpenSHMEM 的 PE、Team、对称堆与 Device put/get。

专业版。UBShmemTransport 是 Mooncake Transfer Engine 的 Ascend 专用可选后端，可用 USE_UBSHMEM=ON 构建、以 protocol="ubshmem" 选择：

Mooncake Store / KV Cache
  → UBShmemTransport：元数据、地址重定位、worker/stream pool
  → Fabric：MallocPhysical → ReserveVA → Map → Export/Import handle
    或 IPC：GetExportKey → ImportByKey → peer access
  → aclrtMemcpyAsync
  → CANN Runtime / Driver / NPU Fabric

它的 CMake 链接 AscendCL，当前源码没有链接 cann/shmem，也没有调用 aclshmem_*。与 Mooncake ub transport 的 URMA/UMDK 路径、Ascend Direct 的 ADXL/HiXL 路径同样不能合并。Mooncake issue #1312 于 2025-12-31 提出以 CANN VMM 构建类似 NVLink 的 Fabric Memory transport；PR #1399 于 2026-01-26 合入首次公开实现，2 月增加 IPC/allocator，3 月增加线程池、stream pool 和 Store 适配，之后仍在维护。它是活跃但非默认推荐总入口。

当前构建资料要求 CANN、Driver 和 Lingqu 的相应版本。基础 VMM API 可跨多代硬件，但 Fabric handle 的公开跨服务器约束曾明确限定 Atlas A3；950PR/DT 支持相关 IPC/VMM API，却不能由此反推出 Mooncake 已公布完整逐型号验证矩阵。

术语对应。房卡是 Fabric handle/IPC key，登记簿是 TransferMetadata，本地入口是 imported VA mapping，换门牌是 address relocation，多名搬运工是 worker/ACL stream pool，真正搬数据的是 aclrtMemcpyAsync。

易错点。UBSHMEM 不是 CANN SHMEM/OpenSHMEM，也不等于 UBMEM；共享映射不等于零数据搬运；支持 aclrtMapMem 不等于支持完整跨服务器 Fabric 路径。

检查理解：

为什么 UBShmem 不是“华为版 OpenSHMEM”？
首次写同一远端 buffer 时，handle、metadata、地址重定位和 copy 如何排序？
A2 支持 VMM 基础 API，为什么仍不能推出跨服务器 UBShmem 可用？

IPC¶

小白版。昇腾 IPC 内存共享像进程 A 租下一个 Device 保险柜，再把不透明“取物凭证”交给进程 B。B 不能直接使用 A 的 devPtr 数值，因为两者地址空间不同；B 要用 key 向 Runtime 导入同一底层 allocation，获得自己的 Device VA。两边门牌可以不同，但指向同一份物理数据。

类比的边界是：IPC key 只负责对象识别、授权和映射，不负责替应用交换 key、同步消费者，也不代表访问时没有 HBM/P2P/HCCS/UB 流量。

专业版。aclrtIpcMem* 是比通用管道、Socket 更窄的 CANN 共享设备内存 API：

Exporter：aclrtMalloc → IpcMemGetExportKey → 可选 PID 白名单
                   │ 普通 IPC/RPC/元数据只传 65-byte key
Importer：IpcMemImportByKey(+ peer access) → importer-local Device VA
Cleanup：所有 importer Close → exporter Close → aclrtFree

key 不是 VA。导出进程提前释放原 allocation 会使导入映射失效。它与显式 VMM shareable handle 的区别是：IPC 从已有 VA/size 导出 key，Runtime 隐藏物理页和 VA 管理；VMM 从 physical handle 出发，由应用显式 Reserve/Map/SetAccess，Fabric V2 handle 还能覆盖特定跨服务器拓扑。

Mooncake UBShmem 于 2026-01 先加入 Fabric/VMM 模式，2026-02 增加 MC_USE_UBSHMEM_IPC=1：导出 65 字节 key、导入 peer allocation，再用重定位 VA 执行 ACL copy。cann/runtime 2025-12-25 的公开首提交已含 IPC 声明，2026-03 增加公开样例；更早产品文档至少可追到 CANN 8.2 周期。当前样例覆盖 950PR/DT、A3、A2 等产品，未见废弃声明。

零拷贝边界。IPC 让两个进程共享同一 allocation，因此可消除“再复制一份给 B”的额外 buffer copy；B 实际读取产生的内存/互联流量，以及后续复制到另一 buffer 的动作仍然存在。它为零额外副本创造条件，但不自动证明端到端零拷贝。

术语对应。保险柜是 Device allocation，凭证是 opaque IPC key，白名单是 import PID trustlist，新开一扇门是 import mapping，B 的门牌是 importer-local Device VA，显式管理地契与门牌则是 VMM physical handle + Reserve/Map。

易错点。IPC key 不是指针；IPC key、VMM handle、Fabric handle 结构与流程不同；性能材料中的 IPC 还可能是 Instructions Per Cycle；共享 allocation 不自动解决可见性、完成和生命周期。

检查理解：

为什么不能只把导出方 devPtr 的数值交给另一进程？
Mooncake IPC 模式里，key、导入 VA、地址重定位和实际搬运分别发生在哪层？
两进程映射同一 Device allocation，为什么仍不足以证明整个 KV Cache 链路端到端零拷贝？

CANN VMM¶

小白版。VMM 像把“门牌、房间、门牌到房间的绑定、门禁”拆开管理：aclrtReserveMemAddress 先圈连续门牌但不占真实存储；aclrtMallocPhysical 买物理内存并返回不可解引用的产权 handle；aclrtMapMem 建立 VA→物理页关系；aclrtMemSetAccess 再设置可访问设备和权限。Export/Import 只是转交产权凭证，不会搬 payload。

类比的边界是：VA 不天然全局相同，Map/Unmap 有页表与同步成本，粒度、TLB、peer 可达性、生命周期也不是房屋类比能表达的。

专业版。CANN Runtime VMM 是把虚拟地址保留、物理内存分配、映射、权限和共享解耦的一组 API；没有名为 CreatePhysical 的正式 CANN API，准确名称是 aclrtMallocPhysical。标准生命周期是：

GetAllocationGranularity
  → ReserveMemAddress + MallocPhysical
  → MapMem → MemSetAccess → 使用 virPtr
  → 等所有异步消费者完成
  → UnmapMem → ReleaseMemAddress → FreePhysical

共享时，出借方 Export shareable handle 并通过 Socket/RPC/MPI 等旁路传 token；借入方 Import 得到本地 physical handle，仍需 Reserve/Map/SetAccess。普通 aclrtMalloc 则一次返回已可用指针，隐藏上述分层；aclrtIpcMem* 从既有 VA 导出 key并直接返回 importer-local 指针，控制粒度也更粗。

VMM 公开证据不晚于 CANN 7.0.0 的 2024-01 文档；2024 年 torch_npu 已用预留大 VA、按需 Map/Unmap 实现 expandable segments；cann/runtime 2025-12 才公开源码，不能把仓库首提交当作 API 立项日。当前基础 API 支持 950、A3、A2 与部分旧 Atlas，但物理内存属性、V2 handle 和跨服务器 Fabric 能力需要逐接口看矩阵：当前公开文档中的跨 AI Server Fabric sharing 仅 A3。整体活跃，未废弃。

与 Fabric 的边界。aclrtMemFabricHandle 是 V2 共享句柄格式；HiXL FabricMem 是 A3 上利用 VMM、地址交换、页表映射和 SDMA/HCCS 的访问模式；MemFabric 是有 GVA、池化管理和多 transport 的独立系统。三者都不是 VMM 的别名。VMM 也只是零拷贝的使能手段：官方基础样例仍会对映射地址调用 aclrtMemcpy。

术语对应。圈门牌是 Reserve VA，买房是 MallocPhysical，产权凭证是 aclrtDrvMemHandle，挂门牌是 Map，发门禁是 SetAccess，可转交凭证是 shareable/Fabric handle，退门牌与退房分别是 ReleaseAddress 与 FreePhysical。

易错点。handle 不是指针；Reserve 成功不代表物理页已分配；Export/Import 不是数据传输；使用 VMM 不自动更快、不自动全局同 VA，也不自动端到端零拷贝。

检查理解：

只 Reserve 得到 virPtr 后，为什么还不能写入？
进程 B 导入 handle 后，向 kernel 传指针前还要完成哪些调用？
“VMM + Fabric handle = 跨机零拷贝 Fabric Memory”还缺哪些地址、数据路径和硬件证据？

产品与跨层路径¶

ADXL / HIXL¶

命名与状态

官方拼写是 HIXL（Huawei Xfer Library），类名为 hixl::Hixl；本文在一般叙述中沿用更常见的 HiXL 写法。ADXL 的可信英文全称未公开，不能自行展开。官方把 ADXL 标为待废弃，但不是已经删除。

小白版。HIXL 像昇腾设备搬家公司：应用给出本地与远端地址，它根据芯片和拓扑选择 HCCS、RoCE、UB 或 FabricMem 路径。ADXL 是旧柜台，HIXL 是新柜台；Mooncake 等老客户仍在旧柜台办业务，因此兼容层继续维护，但新项目应迁往 HIXL。

类比的边界是：远端仍要初始化、注册内存并保持生命周期，只是不需要为每次 READ/WRITE 调一次匹配 recv；Host 单边也不是 CPU 直接解引用远端指针，payload 仍由硬件引擎搬运。

专业版。HIXL 是 Host 侧单边传输库，提供 Engine、RegisterMem、Connect、同步/异步 Transfer 和完成查询。当前 ADXL 并非独立旧引擎，也不是简单 typedef：adxl::MemDesc/TransferOpDesc 会转换为 hixl::* 类型，AdxlEngineImpl 与 hixl::Hixl 最终在共同 EngineFactory/HIXL Engine 层会合。

Mooncake / vLLM / SGLang / LLM-DataDist
  → ADXL compatibility API ─┐
     HIXL current API ──────┴→ common HIXL Engine
  → A2/A3：HCCS、RoCE；A3 可选 FabricMem
     950PR/DT：RoCE、UB/UBoE、UB_RTP 等

公开 CANN 8.3 RC1 时期已存在 ADXL 文档；Mooncake 2025-08-18 合入 Ascend Direct/ADXL；cann/hixl 于 2025-10-14 公开首个代码提交。2026-04-13 仓库加入“待废弃 ADXL”文档，但头文件、测试和 Mooncake 调用仍在，2026-08 兼容 API 甚至继续增加 Fabric handle 能力；截至截止日没有最终删除版本。HIXL 活跃，ADXL 处于迁移期。

零拷贝边界。注册用户 buffer 且底层可直接访问时，HIXL 可以省掉应用中转 buffer；启用 OPTION_BUFFER_POOL 或 Host 内存不可直达时仍会 staging。因此“支持 zero-copy”不是所有配置的无条件保证。

术语对应。旧柜台是 adxl::AdxlEngine，新柜台是 hixl::Hixl，备案是 RegisterMem，搬运地址单是 TransferOpDesc，一端主动下单是 one-sided READ/WRITE，中转仓是 buffer pool。

易错点。ADXL/HIXL 是两个 API 面而非两套串行协议；待废弃不等于已不可用；HIXL Direct 是 Host 发起而非 AIV 直驱；FabricMem 是 VMM/统一编址模式，不是网络协议。

检查理解：

为什么 ADXL 与 HIXL 不能只概括成“旧名与新名”？
Decode 端从 Prefill HBM 读取 KV Cache 前，两端分别要准备什么，哪端提交 READ？
950 Host-to-Host 传输如何在 Host UB、Device UB+UBMEM、RoCE 与 A3-only FabricMem 之间判断？

TileXR¶

小白版。TileXR 把大 Tensor 拆成许多小 tile，让一部分 tile 还在通信时，另一部分已经计算。CommArgs 是 Kernel 可见的路线板，记录 rank、伙伴窗口地址、credit、能力位和可选 UDMA 信息；IPC window 只是开放装卸口，真正搬数据的是 AI Core 的 DataCopy/MTE、HCCL/MC2 路径或 UDMA。

类比的边界是：tile 没有全项目唯一固定大小，CommArgs 也不承载 payload；选择 UDMA 后不会自动保证失败时等价回退到 MTE/HCCL。

专业版。TileXR 的公开定位是 eXtreme Rendezvous for Asynchronous Tile Communication，位于算子通信运行时和编排层，当前可见三类分支：

TileXR Host Runtime + tiling → Device CommArgs
  ├─ IPC window + flag/credit → MTE / DataCopy
  ├─ HCCL Device API + MC2 tiling → collective 与计算融合
  └─ registered regions + UDMAInfo → put/get/signal/quiet

2025-12-30 是当前公开历史中首个可见提交；2026-01 增加 MC2 示例和 communicator/IPC window；此后加入 UDMA、SDMA、EP/MoonEP 等。A2/A3 可见 MC2 示例和 IPC/MTE 分支，UDMA Quickstart 则限定 A5/Ascend 950、arch 3510。代码已形成 Host 注册、区域交换、QP/WQ/CQ、Device wrapper、demo 与检查脚本闭环，但公开 ASCEND_VERIFICATION.md 明示维护环境没有物理 Ascend 卡，因此不能把预期日志写成 A5 真机性能已验证。项目无废弃公告，成熟度应按算子和路径分别判断。

术语对应。小托盘是 tile/chunk，路线板是 CommArgs，共享装卸口是 IPC window，伙伴入口表是 peerMems[]，红绿灯是 flag/credit，叉车是 MTE/DataCopy，边运边算方案是 MC2，远端输送线是 UDMA。

易错点。TileXR 不是 HCCL 新名字；IPC 不搬 payload；MC2、HCCL、MTE、UDMA 是按算子选择的分支而非串行必经栈；有 demo 不等于公开真机验证完成。

检查理解：

peerMems[] 已有远端地址，为什么仍不能说 IPC 已搬完数据？
all_gather_matmul 中 TileXR、MC2、HCCL 与底层链路分别位于哪层？
910B 上初始化成功但 UDMAEnabled(args)=false，为什么不能证明 UDMA 可用？

Fabric Memory¶

必须拆成三个对象

HiXL FabricMem 是 A3 超节点传输模式；Ascend MemFabric 是独立的异构内存池化系统；aclrtMemFabricHandle 只是 CANN VMM 的 128 字节共享能力 token。三者不能放进同一个方框后画等号。

小白版。HiXL FabricMem 像 A3 园区的“统一门牌 + 高速内部货运”：导入远端房产凭证，把远端页挂入本地页表，再由 SDMA 沿 HCCS 搬货。MemFabric 则像跨园区仓储平台：统一分配 GVA，把 DRAM/HBM 编成池，并从 UB、RoCE 等运输商中选择 xcopy 路径。Fabric handle 只是电子房产证，拿到后仍要 Reserve/Import/Map/SetAccess。

类比的边界是：统一门牌不表示任意 CPU/NPU 可普通 load/store，也不表示没有物理数据移动；页表、IOMMU、权限、粒度、故障和完成语义都必须显式处理。

专业版。HiXL FabricMem 的机制是 MallocPhysical → Reserve/Map → 交换 Fabric handle/地址段 → 访问方 Import 并注入页表 → 地址翻译与分段 → SDMA over A3 HCCS → 完成后反向释放。它服务 D2RH、RH2D 和 D2D，当前只支持 Atlas A3，要求 CANN 9.0+、HDK 25.5+、Lingqu 1.5+，并需显式启用且与部分 buffer-pool 配置互斥。

MemFabric 则提供 Global Memory Management、逻辑 GVA、DRAM/HBM pooling、统一 xcopy 与 transport plugins：当前 README 把 A3 映射到 Device UB 1.0、A2 映射到 Device RoCE，另有 Host UB/RoCE；当前未把 Ascend 950 列入已支持表。它于 2025-11 对外开源。HiXL FabricMem 首个可定位公开代码提交为 2026-01-06，3 月进入正式说明；两者截至 2026-08 都仍活跃。

术语对应。HiXL 的园区门牌是 Fabric VA pool，MemFabric 的仓位号是逻辑 GVA，电子房产证是 aclrtMemFabricHandle，录入地址簿是 Import + Reserve/Map，A3 内部货运是 SDMA over HCCS，跨园区运输商是 UB/RoCE plugin。

易错点。Fabric handle 不是 Fabric Memory；HiXL FabricMem 不是 MemFabric；当前 HiXL A3 路径写 HCCS/SDMA，MemFabric A3 写 Device UB 1.0，不能用一条 Fabric Memory → UB 覆盖；“单边零拷贝”仍有 SDMA/xcopy 的真实 payload 移动。

检查理解：

拿到 Fabric handle 后，为什么还不能把它传给 kernel 当指针？
A2 跨机 HBM 池化为什么更应归入 MemFabric 而非 HiXL FabricMem？
“Fabric Memory → UB → 零拷贝”这条唯一链遗漏了哪些控制面、VMM 和数据面分支？

零拷贝¶

小白版。普通路径会把货从业务箱倒进中转箱、运输、再倒进目标业务箱；零拷贝路径让 DMA/NIC 直接从源业务 buffer 送到目标业务 buffer，或让两个进程映射同一物理 allocation。这里的“零”通常指 CPU 没有 memcpy或没有多余 staging，不是字节没有沿 HBM、总线或网络移动。

类比的边界是：协议头、cache line、页表、IOMMU、分片、重传与算法 scratch 都可能产生额外流量；DMA 也可能因地址不可达落入 bounce buffer。因此必须先声明计数边界。

专业版。对 payload P 从逻辑源 S 到逻辑目的 D，本文建议记录：

Z(P, S→D) = (C_cpu, C_bounce, T_payload, M_map, R_app)

C_cpu：CPU 对整段 payload 的 memcpy/materialize 次数；
C_bounce：进入或离开 staging/bounce/relay buffer 的边数；
T_payload：DMA/SDMA/RDMA/MTE/网络等必要物理运输；
M_map：Reserve、Register、Import、Map、页表注入等控制面操作；
R_app：远端应用 CPU 是否要为每次传输主动接收或搬运。

因此，CPU 零拷贝只要求 C_cpu=0；严格无 staging 的传输还要求 C_bounce=0，但跨机时 T_payload≥1；IPC/VMM 同页别名在建立阶段可以 T_payload=0, M_map>0，后续消费者读取仍产生内存/互联流量。

路径	可以证明的“零”	不能自动证明
DMA/RDMA 直达已注册业务 buffer	CPU copy 与 staging 可为 0	bounce fallback、RDMA inline copy、协议 scratch 不存在
IPC 映射同一 allocation	建立共享关系不复制 payload	应用没有先拷入或再拷出，跨 Device 没有链路流量
CANN VMM/Fabric handle	Export/Import/Map 只处理地址和能力	后续 `aclrtMemcpy`、SDMA 或 LD/ST 也为 0
HiXL/FabricMem	可省用户中转与远端应用 CPU	buffer pool 没启用、SDMA/HCCS 不搬字节
HCCL 激活通信内存	消除官方定义的 HCCL 中转 buffer	collective 的传输、归约和所有算法 scratch 消失
AIV/cann-shmem 直驱	Host 不在每次操作热路径	UB/GM、MTE、UDMA 的 payload movement 消失

零拷贝不是华为产品、协议或仓库，因此没有统一立项、版本或 EOL；某个 API 被废弃只代表一条实现路径迁移。

术语对应。“CPU 没搬”是 C_cpu=0，“直接到业务内存”是 C_bounce=0，“共享同一页”是 multiple VA map one allocation，“单边”主要回答 R_app=0，“直驱”回答谁提交任务，均不能单独推出端到端零拷贝。

易错点。DMA/RDMA 不自动零拷贝；Export/Import/Map 不传 payload；远端 CPU 不参与只证明单边性；AI Core 的 Unified Buffer 若只是中转，就必须计入 staging。

检查理解：

DMA 没有普通 CPU memcpy，但 SWIOTLB 发生 bounce，应归入哪种零拷贝口径？
A Export VMM 内存、B Import+Map，但 A 先 memcpy 数据进共享区，五元组应如何计？
HCCL Activate 消除内部 buffer 后，怎样分别按 CPU-copy、无 staging 和总物理移动判断 AllReduce？

AIV 直驱¶

小白版。把通信看作快递：AIV 是车间工人，WQE 是快递单，doorbell 是通知硬件取单的铃，CQE 是回执，notify/signal 是送货同时按门铃，quiet 是等待此前订单达到规定完成状态；真正运货的卡车仍是 UDMA、RDMA/URMA、MTE 或 UB 引擎。

传统细粒度路径可能让 AIV 每轮请求 Host/AICPU 排任务；AIV 直驱则由 Vector Core 直接构造并发布 WQE、敲 doorbell、轮询 CQ 或等待 signal。类比的边界是：Host 没有完全消失，Endpoint、MR、Channel、远端地址与队列元数据通常仍由 Host/HCOMM 预先建立。

专业版。AIV 直驱是数据面提交者/控制路径属性，不是新的 DMA 或网络协议：

Host / HCCL / HCOMM 控制面
  → 建通信域、Endpoint/Channel、注册 MR、交换地址与 key
  → 下发 WQ/CQ/doorbell/channel entity
AIV Kernel fast path
  → 生成 WQE → publish SQ/WQ → ring doorbell
  → UDMA/RDMA/URMA/MTE/UB engine 搬运
  → poll CQ / wait notify / quiet

HCCL 的 HCCL_OP_EXPANSION_MODE=AIV 表示 collective 在 Vector Core 展开执行，与低层 WQE 直驱相关但不完全等号；大消息或受限场景可能回退 AICPU。HCOMM 的 COMM_ENGINE_AIV 表示申请给 AIV 数据面使用的 channel；HCOMM 本身不是传输引擎。cann/shmem 则用 Device API 封装 put/get、put-with-signal 和 quiet，950 UDMA 路径依赖 HCOMM 控制面。

公开资料不晚于 CANN 8.x 已出现 HCCL AIV 展开；2026-04 的 SHMEM v1.3 明确增加 AI Core 直驱，CANN 9.1 beta2 点名 Ascend 950PR 的 AIV 直驱 RoCE/URMA。硬件范围必须拆开：A2/A3 的有限 HCCL AIV 场景不等于支持 950 的 UDMA AIV 直驱。能力仍在扩展，未废弃。

术语对应。快递单是 WQE，传送带是 SQ/WQ，敲铃是 ring doorbell，回执是 CQE，送货并通知是 put-with-signal，等本人此前操作完成是 quiet，预办通行证是 Endpoint/Channel/MR 控制面。

易错点。AIV 不亲自跨卡搬字节；AIV mode 不保证任何数据量都不回退；直驱不表示 Host 控制面消失；quiet 是本 rank 的完成性原语，不是多 PE barrier；MC2 Kernel 跑在 AIV 上也不自动等于通信由 AIV 直驱。

检查理解：

AIV 敲 doorbell 后，为什么仍不能说“AIV 就是 UDMA 引擎”？
aclshmemx_udma_put_signal_nbi + quiet(peer) 中，控制面、提交者、搬运引擎和完成机制分别是什么？
HCCL 配置 AIV 却在大消息回退 AICPU，怎样用配置与 profiling 判断本次是否真正直驱？

组合路径与演进¶

为什么不能只画包含树¶

同一个请求可以同时被五种分类描述。以“Mooncake 把 PE 0 的 KV Cache 写到 PE 1”为例：

产品/API 轴：应用可能调用 HiXL/ADXL，也可能选择 Mooncake UBShmem。
内存轴：HiXL 要注册内存；UBShmem 要通过 VMM 导入对端共享物理内存并重建 VA 映射。
提交轴：当前公开 Mooncake 路径主要由 Host worker 和 ACL stream 发起；不能凭 Direct 或 SHMEM 字样推断 AIV。
引擎轴：实现可能选择 RDMA、SDMA、ACL copy 或 UB 后端。
互联轴：物理字节可能走 RoCE、HCCS 或 UB。

因此，“HiXL 包含 RDMA”“UBShmem 包含 VMM”最多只是在某一固定版本和路径上的实现关系；更稳定的表达是：上层选择语义，运行时建立地址和资源，提交者生成任务，引擎搬运 payload，互联承载字节。

四条主开发路径¶

集合通信主线¶

框架 collective
  → HCCL 算法、拓扑与 executor
  → HCOMM 控制面/数据面资源
  → AICPU / AIV / Host 执行引擎
  → HCCS / RoCE / PCIe / UB

这条线解决的是一组 rank 如何共同完成操作。Ring、Mesh、RHD、分层 AllToAll 等算法关心数据如何切片、哪个 rank 先发给谁、如何 reduce 或 gather。底层 transport 只完成其中的点对点步骤。

Host 侧单边传输主线¶

KV Cache / 参数切换 / 内存池化应用
  → HiXL 新 API（ADXL compatibility 仍在）
  → 注册内存、建链、同步/异步 request
  → HCCS / Host RoCE / Device RoCE / UB / FabricMem

这条线以buffer 批量传输为中心。它不要求应用理解 collective 算法，也不要求用户手动管理 PE 对称堆。HiXL 的价值是用十余个核心 API 屏蔽多硬件和多链路差异；代价是底层路径和零拷贝程度要结合内存类型、注册状态和 buffer pool 判断。

Device 侧单边通信主线¶

AIV / 自定义算子
  → cann/shmem Device API
  → PE、对称地址、RMA/AMO、Signal/Quiet/Barrier
  → MTE / SDMA / RDMA / UDMA

这条线把通信控制推进到 AICore Kernel。它适合通信与计算融合、细粒度 token 流水和减少 Host 下发，但必须正确管理完成、内存序、队列并发和 Vector Core 资源竞争。

映射型 Fabric 快路¶

Mooncake UBShmem / HiXL FabricMem
  → CANN VMM 申请物理内存与预留 VA
  → Export / Import Fabric 或 IPC handle
  → Map + SetAccess
  → ACL copy / SDMA / Fabric 后端访问映射地址

这条线的关键不是重新发明一个 SHMEM 标准，而是把远端物理内存变成本进程可寻址的地址对象。映射建好之后，后续 copy 不必每次重新交换远端地址描述；但容量对齐、连续空间、权限、句柄生命周期和异常回收会成为新的瓶颈。

TileXR 为什么跨了多条线¶

TileXR 不是通用 transport 的简单别名。其当前公开代码同时出现三类路径：

独立 all_gather 使用 CommArgs.peerMems、IPC 共享窗口和 Kernel 内同步；
all_gather_add、all_gather_matmul 等 MC2 算子使用 HCCL 对象；
UDMA 路径把注册区域、UDMAInfo、WQ/CQ/QP 与 Device put/get/signal/quiet 加入 CommArgs。

这说明 TileXR 位于算子通信组织层：它可以消费 IPC/MTE、HCCL/MC2 或 UDMA 能力，却不应被画成这些底层机制的父类。当前代码已形成 Host 注册、区域交换、transport/QP 初始化、CommArgs 上传、Device wrapper 和 demo 的流程闭环；但公开真机验证清单明确说维护环境没有物理 Ascend 卡，因此只能写“代码与验收流程完成，A5/950 数据面仍待公开实测”，不能把 expected output 当成验证结果。

硬件代际不是简单替换¶

从当前公开支持矩阵看，更接近事实的画法是并存与重心迁移：

A2/A3 继续大量使用 HCCS、MTE、SDMA 与 RoCE；
Ascend 950 引入 UB、URMA/UDMA、UBMEM 与新的 AIV/HCOMM 资源；
跨超节点、异构或现有以太网部署仍需要 RoCE/RDMA；
PCIe、Host 内存、页表和 Runtime 不会因为 UB 出现而消失。

因此，UB 是新一代统一互联与内存语义方向，不是在 2026-08-26 已经把 HCCS 和 RoCE 从所有产品一次性删除的证据。

仓库与项目边界¶

公开仓库	首个可见提交/公开节点	主要责任	不能据此推出
`cann/hccl`	Git 首提交 2025-11-15；README 称 2025-11-30 正式开源	集合算法、算子 API、拓扑与 executor	HCCL 在 2025 年才内部诞生
`cann/hcomm`	Git 首提交 2025-10-17；随 HCCL 于 2025-11-30 公开	通信控制面、数据面、endpoint/channel/memory 资源	HCCS、RDMA 或 UB 被 HCOMM 发明
`cann/hixl`	2025-10-14 首个代码提交	单边 buffer 传输、LLM-DataDist、FabricMem、ADXL 兼容	`Direct` 必然由 AIV 发起
`cann/shmem`	2025-12-12 首提交；2026-02 首批 tag	对称内存、PE/Team、RMA/AMO/同步与 Device API	完整实现 OpenSHMEM 全部规范
`cann/runtime`	2025-12-25 首提交	Device、Stream/Event、内存、任务与 DFX	CANN Runtime 产品从 2025 年才存在
`Ascend/memfabric_hybrid`	2025-04-14 首提交；README 称 2025-11 开源	全局 VA、内存池化、xcopy 与多后端	Fabric Memory 只有这一种实现
`LingquLab/TileXR`	2025-12-30 首个可见公开提交；无正式 release	Tile 通信、共享窗口、融合算子与 UDMA 路径	有代码不等于已有公开 A5 真机性能验证
`kvcache-ai/Mooncake`	2025-08 合入 ADXL；2026-01 合入 UBShmem	KV Cache/内存池传输与多 transport	Mooncake 的 UBShmem 就是 CANN SHMEM

“废弃”应该怎样表述¶

本文采用四档状态，避免把“旧”“不支持本芯片”和“已删除”混为一谈：

活跃：仓库或版本仍在发布，如 HCCL、HCOMM、HiXL、SHMEM、Runtime、RDMA、UDMA。
待废弃：官方明确标记但接口仍保留，当前典型是 ADXL compatibility API。
平台迁移：新硬件把主路径从 HCCS/SDMA 转向 UB/UDMA，但旧平台仍使用旧路径。
未证实停用：只有长时间无提交或集成缺口，没有 EOL 公告。TileXR 应描述为“活跃、逐路径成熟度和公开硬件验证待核”，不能直接标红为废弃。

可能的演进路径¶

路径一：HCCL/HCOMM 收敛 collective，UB 成为 950 主力后端¶

推断。最可能的主线是 HCCL 继续保持框架集合通信入口，HCOMM 进一步统一 AICPU、AIV、CCU、RoCE、HCCS 与 UB 资源。UB 在 Ascend 950 超节点内承担更多内存语义和低时延访问，但跨超节点 RoCE 继续存在。

成立前提：UB 软硬件规格、驱动、HCOMM 资源、算法和运维工具共同成熟。
先行信号：HCCL 新版本把更多 950 collective 默认算法切到 AIV/UB；HCOMM ub_mem、URMA/UDMA endpoint 从 legacy/experimental 收敛到稳定 API。
失效条件：UB 生态兼容和故障恢复成本过高，或跨节点场景长期仍只能由 RoCE 主导。

路径二：HiXL 新 API 取代 ADXL，Host 单边传输成为应用主入口¶

推断。KV Cache、参数切换和分布式内存池更可能消费 HiXL 的稳定 API，而不是让每个上层项目继续直接拼 HCCL 私有传输或维护 ADXL 兼容对象。

成立前提：HIXL API 覆盖 ADXL 的同步/异步、自动建链、错误码、内存类型和 FabricMem 能力。
先行信号：Mooncake 等项目从 adxl::AdxlEngine 迁移到 HIXL 头文件；构建选项不再依赖 ADXL compatibility 包。
失效条件：兼容层长期更稳定、迁移收益有限，或新 API 在异步/多目标/异常恢复上缺失关键能力。

路径三：SHMEM/AIV 直驱扩展通算融合，项目专用 wrapper 被迫对齐¶

推断。细粒度 MoE、MC2 和自定义算子会继续推动 Device 侧 RMA、Atomic、Signal 与 UDMA/RDMA 直驱。TileXR 之类项目若要持续演进，需要把自己的 UDMA ABI、资源所有权和完成语义与 CANN/HCOMM 的稳定接口持续对齐，并补齐 A5 真机验证。

成立前提：Device API 的多核并发、错误报告、性能阈值和硬件覆盖足够稳定。
先行信号：更多官方算子样例直接使用公共 Device API；TileXR 公布 A5 双卡运行日志、正确性和带宽/时延测试。
失效条件：AIV 资源竞争抵消低时延收益，或 Host/AICPU 路径在主流负载上已足够高效。

证据缺口¶

内部立项日期。HCCL、HCCS、ADXL、HiXL、UDMA 和 Fabric Memory 的内部项目启动时间没有公开一手档案；本文只给公开证据时间。
HCCS 与 UB 的产品边界。公开文档能确认 A2/A3 和 950 的主路径差异，但尚缺一份覆盖所有服务器形态、所有 CANN 版本的统一退役矩阵。
UDMA 的正式全称沿革。当前 SHMEM 术语表采用 Unified DMA，TileXR 等材料曾使用 User-space DMA；需要产品规范给出跨版本命名说明。
HCCL 私有数据面。公开源码能看到 HCOMM、AIV、UBMEM、URMA 等对象，但不能把所有 engine 的闭源固件细节和链路选择还原为完整微架构。
TileXR 可运行性。需要 Ascend 950、配套 CANN/ops/HCOMM 版本做真实编译与端到端测试，确认 UDMA put/get/signal/quiet 的正确性、异常恢复和性能；当前公开 expected output 不能替代实测。
UBShmem 的命名。它是否会在 Mooncake 后续版本改名以避免与 OpenSHMEM/CANN SHMEM 混淆，尚无公开计划。
零拷贝的测量口径。需要在具体链路上同时记录 CPU memcpy、DMA copy、staging buffer、页映射和网络 bytes，才能证明是“局部零拷贝”还是“端到端零拷贝”。

参考资料¶

证据口径

以上链接支持的是公开能力、源码状态和公开时间节点。内部立项、未开源固件、RTL 微架构及所有产品组合没有公开证据时，本文不作确定性补写。

Ascend Communication Stack

核心结论¶

总体架构¶

关键时间线¶

横向对比¶

基础机制¶

内存语义¶

DMA¶

xDMA¶

RDMA¶

RoCE¶

UDMA¶

通信与互联¶

HCCL¶

HCCS¶

UB¶

内存与运行时¶

UBMEM¶

SHMEM¶

UBSHMEM¶

IPC¶

CANN VMM¶

产品与跨层路径¶

ADXL / HIXL¶

TileXR¶

Fabric Memory¶

零拷贝¶

AIV 直驱¶

组合路径与演进¶

为什么不能只画包含树¶

四条主开发路径¶

集合通信主线¶

Host 侧单边传输主线¶

Device 侧单边通信主线¶

映射型 Fabric 快路¶

TileXR 为什么跨了多条线¶

硬件代际不是简单替换¶

仓库与项目边界¶

“废弃”应该怎样表述¶

可能的演进路径¶

路径一：HCCL/HCOMM 收敛 collective，UB 成为 950 主力后端¶

路径二：HiXL 新 API 取代 ADXL，Host 单边传输成为应用主入口¶

路径三：SHMEM/AIV 直驱扩展通算融合，项目专用 wrapper 被迫对齐¶

证据缺口¶

参考资料¶

华为与 CANN¶

项目源码与演进记录¶

通用标准与历史¶

评论