Ascend Communication Runtime Evolution

导言

在昇腾通信栈的第二轴中，HCOMM、SHMEM Runtime、IPC、CANN VMM 与 Fabric Memory 被放在同一个“资源、地址与运行时”区域。它们都在帮助程序访问另一进程、另一设备甚至另一节点的内存，因此很容易被理解成五套重复方案：既然目标相同，为什么不统一成一套 API？

这个问题真正触及的是系统抽象如何演进。五个概念共享“让数据可达”的目标，却分别承诺资源组织、PGAS 编程、进程共享、虚拟内存管理和内存池化；它们不是五代同类技术，而是从五个不同矛盾长出的责任边界。本文从第一性原理拆出这些不可互换的契约，再沿时间纵轴和能力横轴梳理其提出契机、公开时机、新仓库形成条件与未来收敛方向。

从同层不同物开始¶

《Ascend Communication Stack》把一次通信拆成五条相交的轴：应用选择通信语义，Runtime 建立资源与地址，Host 或 Device 提交任务，DMA 类引擎搬运 Payload，底层互联承载字节。第二轴处在“上层想做什么”和“下层怎样搬”之间。

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

把五个概念放在同一区域，只表示它们都可能参与通信前的资源与地址准备，并不表示它们属于同一个抽象层次：

HCOMM          通信资源与基础操作
SHMEM Runtime  PE、Team、对称堆与远端内存操作
IPC            已有 allocation 的跨进程共享
CANN VMM       虚拟地址、物理内存与权限的拆分管理
Fabric Memory  跨设备、跨介质的内存编址与池化

最容易误读的原因，是这五条路径最后都可能出现一个“本地可使用的地址”。但地址只说明怎样找到对象，不说明对象是谁拥有、允许做什么、何时完成、何时对其他观察者可见，也不说明对端失效后怎样回收。

同层不等于同类

架构图中的一层通常是一段责任带，而不是 Java 式的同一个父类。HCOMM 和 SHMEM Runtime 更接近通信软件，IPC 与 VMM 是 Runtime 机制，Fabric Memory 则可能指一种访问模式、一个跨层能力或一个独立池化系统。若先假定它们可以彼此替换，历史与接口关系都会被读反。

第一性拆解¶

先不使用任何产品名。一次可靠的远端内存访问，至少要回答七个无法由硬件带宽消除的问题：

参与者。进程、Rank、PE、Team、Device 或内存节点如何编号、发现和建立关系。
内存对象。访问的是普通 allocation、对称对象、注册内存、物理页，还是全局池中的逻辑对象。
命名空间。调用者持有本地 VA、远端 VA、<PE, symmetric address>、GVA，还是不可直接解引用的 handle。
授权方式。访问权来自 PID 白名单、VMM access、memory key，还是 Endpoint/Channel 的资源配置。
操作集合。系统允许 Map、Memcpy、Put/Get、Load/Store、Atomic、Signal 中的哪些动作。
完成与可见性。提交成功、DMA 完成、远端可见和并发程序可安全消费是不是同一时刻。
生命周期与故障。谁能 Unmap、Close 或 Free；异步消费者尚未结束、对端进程退出或节点失联时怎样处理。

可以把一个抽象写成契约元组：

\[ C = \langle P, O, N, A, X, V, L \rangle, \]

其中 \(P\) 是参与者，\(O\) 是对象，\(N\) 是命名空间，\(A\) 是权限，\(X\) 是操作，\(V\) 是完成与可见性，\(L\) 是生命周期。两个概念只有在这七项大体相同、且调用者无需补写额外协议时，才可能被同一 API 真正替代。

按这个标准观察第二轴，差异会立即显现：

概念	起点问题	核心对象	命名方式	操作与完成	生命周期所有者
HCOMM	Collective 与通算融合怎样复用异构通信资源	通信域、RankGraph、Endpoint、Channel、Memory、Notify	Rank、Endpoint、Channel 及协议资源	基础通信动作、Notify、Fence；完成依具体数据面	通信域和资源管理器
SHMEM Runtime	Host 或 Kernel 怎样编程远端内存	PE、Team、对称堆、对称对象	`<PE, symmetric address>`	RMA、AMO、Signal、Fence、Quiet、Barrier	SHMEM 作业、Team 与对称堆
IPC	隔离进程怎样共享已有 Device allocation	已分配内存、导出 key、导入映射	导入方本地 VA + 共享 key	建立共享关系；数据操作由后续 Copy 或 LD-ST 决定	导出进程与导入进程共同遵守顺序
CANN VMM	VA、物理页和权限怎样独立管理	VA range、physical handle、mapping、access	预留 VA + 物理 handle	Reserve、Map、SetAccess、Export/Import；不定义 Payload 完成	显式 VMM 调用者
Fabric Memory	分散的 HBM/DRAM 怎样成为可池化、可寻址资源	Fabric handle、远端物理内存、GVA、内存池	统一或全局地址、远端映射	地址编排、Copy 或多 transport 访问；语义随产品层次变化	Fabric 服务、池管理器与客户端

这张表给出一个核心判断：未统一并不是技术债的充分证据，反而可能说明系统仍在正确保护不同契约。真正的重复要继续下钻到驱动、页表、物理 handle、注册缓存、拓扑探测和 transport 资源，而不能只凭“都能访问远端内存”认定五套 API 重复。

五个概念怎样长出¶

五条路径都与远端访问有关，但各自出现时面对的首要矛盾不同。以下日期均采用公开证据口径：仓库首个可见提交、公开说明与版本标签只能证明“不晚于该日公开”，不能替代内部立项时间。

HCOMM：从集合算法中抽资源¶

HCCL 早期首先要稳定回答：一组 Rank 怎样完成 AllReduce、AllGather、AllToAll 等 collective。随着 Ascend 代际、拓扑、链路和执行引擎增多，算法层若同时管理建链、Endpoint、Channel、内存注册、Notify、协议选择和 Device 侧资源，会产生两个问题：

资源实现与算法组合相互牵制。新增 UDMA、UBMEM 或 AIV 路径，需要修改原本只应关心 collective 调度的代码。
非 collective 场景无法复用。通算融合或自定义通信算子也需要 Channel、Notify 和内存资源，却不一定需要 HCCL 的完整 collective 入口。

HCOMM 的设计思路因此不是发明另一套 HCCL，而是把控制面和数据面基础资源从 collective 算法中向下抽取。HCCL 保留“整个通信组完成什么”；HCOMM 负责“怎样描述通信域和拓扑，怎样创建 Endpoint/Channel，怎样准备 Memory/Notify，怎样把基础动作交给不同协议后端”。

HCOMM 与 HCCL 于 2025 年 11 月 30 日正式开源，公开 Git 历史可见代码早于公告出现。这个时点应读作软件边界公开化，而不是 HCOMM 在 2025 年 11 月才从零诞生。其独立仓库的意义是让通信算法和资源层获得独立构建、版本与硬件适配节奏。

HCOMM 不能替代另外四者：它没有定义 SHMEM 的 PE/Team 和对称堆，也不承担通用 VA/物理页管理，更不会仅凭一个 Channel 把远端 DRAM 组织成全局内存池。

SHMEM Runtime：把远端操作下沉到程序¶

SHMEM 的历史远早于 CANN。Cray SHMEM 在 1990 年代形成，OpenSHMEM 在 2010 年代开始标准化 PE、对称内存、Put/Get、Atomic 与同步。它要解决的首要矛盾是：并行程序能否直接表达“当前 PE 对远端 PE 的同构对象做什么”，而不是把每次访问包装成双方匹配的消息。

CANN SHMEM 把这套 PGAS 思想落到 Ascend。公开仓在 2025 年 12 月出现首批代码，2026 年 2 月出现 v1.0 可见标签，v1.3 在 2026 年 4 月加入 AICore 直驱和 40 多个接口，v1.6 在 7 月继续完善 Ascend 950 的 UDMA、MTE、RDMA 与 SIMT 支持。这条演进线反映的不是换了一个地址 API，而是控制路径从 Host bootstrap 继续下沉到 Kernel：

Host 负责启动作业、建立 PE/Team、创建对称堆和准备传输资源。
Device 代码在计算过程中直接 Put/Get、Atomic、Signal 或 Wait。
fence、quiet、signal 和 barrier 对操作顺序、完成与程序可见性作出明确承诺。

这正是 SHMEM Runtime 无法并入 VMM 的原因。VMM 可以给对称堆提供 VA 和物理页，却不知道哪些 PE 必须获得对称对象，也不知道 quiet 应等待哪些远端操作。反过来，SHMEM 可以在内部复用 VMM、HCOMM、RDMA 或 UDMA，但不应把这些机制全部暴露为编程模型。

Runtime 的两个口径

“SHMEM Runtime”在本文中指支撑 PE、Team、对称堆、资源初始化、RMA/AMO 与同步的运行时整体，不等于 cann/runtime 仓库中的一组内存 API。两者名字都含 Runtime，却分别拥有并行编程语义和设备通用运行时语义。

IPC：从进程隔离中共享已有对象¶

操作系统把不同进程的虚拟地址空间隔离开。同一块 Device memory 即使物理上可被两个进程访问，进程 B 也不能安全地拿进程 A 的数值地址直接解引用。IPC 首先解决的就是这个局部、具体的问题：

导出方已经拥有一块 allocation。
Runtime 把它转换成可传递的共享 key 或 handle，并限制允许导入的进程。
导入方把同一底层对象映射为自己的本地 VA。
双方遵守 Close、Free 和异步任务完成的先后顺序。

IPC 的优势是便利与最小暴露。调用者不必显式选择物理页、预留地址区间和设置每一段 access；代价是控制粒度有限。它建立的是共享关系，不负责跨机建链，也不自动提供 Put/Get、Atomic、Fence 或全局一致性。

IPC 作为 Runtime 基础能力早于 cann/runtime 于 2025 年底公开 Git 仓；当前公开文档和样例展示了内存导出、带 PID 权限的导入和资源关闭流程。因此不能用仓库首提交给 IPC 定“诞生日期”，也没有必要因为 IPC 很重要就为它建立独立产品仓库。

CANN VMM：把地址与物理内存解耦¶

传统 malloc 风格接口把“选择物理内存、分配容量、取得 VA、建立映射和授予权限”压成一步，简单但难以应对大模型工作负载中的几个矛盾：

需要一大片连续 VA，物理页却希望按需提交或回收。
需要减少碎片、复用地址区间或保持稳定 VA。
需要把物理内存导出到另一进程、设备或 Fabric 节点，再映射到不同 VA。
需要对不同设备设置更精细的访问权限。

VMM 把这些动作拆开：先 Reserve VA，再创建或导入 Physical Handle，随后 Map，并通过 SetAccess 授权。它带来的关键思想是：

handle 不是 pointer，保留 VA 不是分配 Payload，完成 Map 也不表示发生了数据传输。

CANN 7.x 时期的公开文档已经能看到这类 VMM 能力，后续 CANN 9.0 文档和 Runtime 样例继续呈现 Reserve、Physical、Map、Access 与共享流程；2025 年底公开的 Runtime 仓库只是更晚的源码可见节点。VMM 长期留在 Runtime 内部很合理，因为它提供的是多个上层都会使用的通用地址机制，而不是独立的通信编程模型。

IPC 与 VMM 因此是“便利入口与机制入口”，不是前后代关系。IPC 从已有 allocation 出发，快速完成跨进程共享；VMM 允许调用者显式编排 VA、物理对象和权限。系统可以让 IPC 在内部使用相似驱动机制，同时保留两种北向接口。

Fabric Memory：从映射走向池化¶

大模型推理把内存问题从“本机显存够不够”放大成“Prefill、Decode、KV Cache、Host DRAM 与 Device HBM 怎样形成统一容量层级”。仅有 VMM 仍然不够：应用还需要知道哪些远端内存可用、怎样分配、怎样跨节点寻址、选哪条 transport、故障后怎样摘除，以及热数据怎样在 DRAM/HBM 间移动。

“Fabric Memory”在公开材料中至少有三个不同层次，必须先消歧：

aclrtMemFabricHandle 一类 Runtime 对象是可导出、导入或映射的能力令牌；它不是一套独立的内存池产品。
HiXL FabricMem是 HiXL 面向 Ascend A3 等平台的一种传输模式，利用 VMM 和 Fabric handle 访问远端 DRAM，数据仍可能由 SDMA/HCCS 等路径搬运。
Ascend MemFabric是更完整的池化系统，公开仓围绕 GVA、异构 DRAM/HBM、xcopy、client/server 与多 transport 插件组织代码。

公开节奏也说明它不是一条单线产品：Ascend MemFabric 在 2025 年 11 月前后公开；HiXL 仓于 2026 年 1 月 6 日出现可定位的 Fabric Memory 代码，3 月 README 将 FabricMem 列为公开能力。两者共享远端内存和统一编址思想，但产品边界不同。

Fabric Memory 新思想的重点不是“又发明一个 Map”，而是把地址机制升级成容量服务：

VMM：给我 VA、物理对象、映射和权限
Fabric Memory：给我可发现、可分配、可访问、可迁移、可恢复的远端内存资源

这就是它有时表现为 HiXL 的一个 capability，有时又值得形成 MemFabric 独立仓库的原因：前者主要扩展一条产品数据路径，后者承担了独立内存池、服务生命周期、多后端策略和兼容矩阵。

时间线不是替代链¶

把公开节点放在一条纵轴上，可以看到“旧思想、新机制、新负载”三股力量在 2025–2026 年汇合，而不是五代 API 依次替换。

时期	公开节点	当时暴露的主要矛盾	形成的设计方向
1990 年代	Cray SHMEM 编程模型形成	消息匹配妨碍细粒度单边访问	PE、对称对象、Put/Get 与同步
2010–2012	OpenSHMEM 标准化	多厂商 SHMEM 方言需要稳定语义	标准化 PGAS API，而非指定唯一 transport
2018–2020	CANN 1.0、CANN 3.0 与 AscendCL 公开	设备、内存、Stream 和任务管理需要统一 Runtime	建立通用设备 Runtime 基础
CANN 7.0–8.2	VMM、IPC 接口在公开开发文档中逐步可见	大块 VA、物理内存共享、进程隔离和细粒度权限	地址、物理页、映射和共享 handle 解耦
2025-11	HCCL/HCOMM、MemFabric 公开	算法资源耦合；远端 DRAM/HBM 需要池化	通信资源下沉；Fabric 内存服务独立
2025-12	CANN SHMEM 与 Runtime 公开仓出现	Device 侧 PGAS、Runtime 源码开放与新硬件适配	对称堆、RMA/AMO、基础内存机制产品化
2026-01 至 03	HiXL FabricMem 公开	PD 分离与 KV Cache 需要远端 DRAM 快路	VMM/Fabric handle 成为 HiXL capability
2026-04 至 07	SHMEM v1.3 至 v1.6	Host 调度粒度不足，950 后端与 SIMT 需完善	AICore 直驱，UDMA/MTE/RDMA 多后端并存

这条时间线不能写成：

IPC → VMM → SHMEM Runtime → Fabric Memory → HCOMM

更准确的纵向关系是五条不同来源的支线在新硬件和新负载处相交：

HCOMM 从 collective 的资源复用向下生长。
SHMEM Runtime 从 PGAS 编程语义向硬件落地。
IPC 从 进程隔离与共享出发。
VMM 从 虚拟内存与物理内存解耦出发。
Fabric Memory 从 远端容量池化与统一编址出发。

为什么公开节点集中

2025–2026 年节点密集，不等于这些需求同时被第一次想到。更合理的解释是：大模型推理与通算融合改变了访问粒度和容量需求，Ascend 950、UB/UDMA 等硬件能力改变了可实现边界，既有闭源能力又开始按 HCOMM、SHMEM、Runtime 和 MemFabric 的责任重新开放。工作负载、硬件和仓库边界同时变化，才造成了“新概念突然增多”的观感。

横向看不可互换处¶

纵向分析回答“为什么在那个时点出现”，横向分析则要在同一时点比较“它们究竟哪里不同”。最重要的不是 API 名字，而是替换后调用者要不要改变参与者、对象和完成规则。

维度	HCOMM	SHMEM Runtime	IPC	CANN VMM	Fabric Memory
首要用户	HCCL、通信算子、融合框架	Host 程序与 AICore/SIMT Kernel	同机多进程 Runtime 程序	内存管理器、框架、上层通信库	KV/参数服务、内存池客户端
主要范围	单机、超节点或多机通信域	PE/Team 作业范围	通常是同一主机或设备可达域	设备 Runtime 可管理的 VA/物理对象	跨设备、跨节点、跨介质容量域
是否分配内存	管理通信内存资源，不定义通用 allocator	管理对称堆和对称 allocation	否，主要共享已有 allocation	显式创建物理对象并映射 VA	是，通常需要池化 allocator 或服务
谁发起数据动作	Host、AICPU、AIV 等，依数据面	Host 或 Device PE	IPC 本身不发起 Payload	VMM 本身不发起 Payload	Host、Copy engine 或产品定义的发起者
Payload 语义	基础通信操作与资源语义	Put/Get、AMO、Signal 等 PGAS 操作	由后续 Copy/LD-ST 决定	无，只管理地址与映射	Copy、远端访问或迁移，随产品而异
完成边界	Channel/Notify/Fence 等具体协议边界	Fence、Quiet、Signal/Wait、Barrier	只保证映射建立；完成依后续操作	Map 成功不等于数据搬运完成	请求、Copy 或服务级完成
故障域	通信域、Channel 和对端资源	PE/Team、对称堆和作业	导出/导入进程生命周期	handle、mapping 与设备上下文	内存节点、服务、transport 与池元数据

四组相邻概念尤其值得单独比较。

HCOMM 与 SHMEM Runtime¶

二者都可能使用 Endpoint、Channel、Memory、Notify 和 UDMA/RDMA 后端，但 HCOMM 首先提供通信资源，SHMEM 首先提供远端内存编程模型。若只保留 HCOMM，调用者仍需自己定义 PE/Team、对称对象和 Quiet；若只保留 SHMEM，HCCL 的算法层仍需要更通用的拓扑和资源抽象。最合理的统一方向是 SHMEM 复用 HCOMM 资源，而不是删除其中一个北向语义。

IPC 与 VMM¶

IPC 追求“把已有 allocation 安全地给另一进程使用”，VMM 追求“让调用者自己组合 VA、物理对象、映射和权限”。IPC 可以成为 VMM/驱动机制上的便利封装，但保留它可以减少调用复杂度和误用面。只有当 VMM 提供同等简单、同等安全的共享流程时，某些 IPC 实现代码才可能变薄；这不等于 IPC 语义消失。

VMM 与 Fabric Memory¶

VMM 是局部机制，Fabric Memory 是系统策略。VMM 不负责发现远端容量、选择 DRAM/HBM、维护池元数据、跨 transport 选路和服务故障恢复。Fabric Memory 若不复用 VMM，会重复实现页表和 handle；VMM 若试图直接承担池化，又会把通用 Runtime 绑定到特定部署策略。合适边界是机制下沉，策略上移。

SHMEM 与 Fabric Memory¶

二者都可能呈现“远端内存像可访问对象”的外观，但 SHMEM 用 PE 和对称地址表达并行算法，Fabric Memory 用全局地址或池对象表达容量服务。对称堆可以由 Fabric Memory 提供物理容量，Fabric 内存也可以被 SHMEM 注册，但 quiet、atomic 和 barrier 不能由一个池化 allocator 自动推出。

新思想何时需要新仓库¶

新名词不必然需要新代码仓。判断边界是否应独立，至少要看四项责任是否同时成立：

新的北向语义。出现了旧系统无法稳定表达的对象、操作或完成规则。
独立生命周期与故障域。它必须自行管理初始化、对端退出、异常恢复和资源回收。
多后端策略。它需要在芯片、链路、DMA 引擎、内存介质或部署方式之间选择路径。
独立兼容矩阵。它需要自己的版本、测试、性能和硬件适配节奏。

用这四项回看五个概念：

概念	是否需要独立仓库	设计判断
HCOMM	是	已形成通信资源北向接口、独立硬件/协议适配与测试边界，适合与 HCCL 算法解耦
CANN SHMEM	是	PE/Team、对称堆、Device API、RMA/AMO 和同步构成完整编程模型
IPC	通常否	是 CANN Runtime 的基础共享流程，没有独立产品生命周期和策略面
CANN VMM	通常否	是 Runtime 通用机制，应被多个上层共同复用
HiXL FabricMem	当前更像 HiXL 内部 capability	主要扩展 HiXL 数据路径，版本和请求模型仍跟随 HiXL
Ascend MemFabric	是	GVA、异构池化、client/server、`xcopy` 和多 transport 已形成独立系统责任
Fabric handle	否	只是能力对象或 ABI，不是独立产品契约

因此，“产生了新代码仓”最有价值的信号不是代码数量，而是责任已经无法跟随原系统的版本和故障边界演进。反之，把每个 handle、每种数据路径都拆成仓库，只会把真正可复用的机制割裂。

跨生态旁证¶

CUDA 生态提供了一组很接近的横向样本：CUDA IPC 负责跨进程共享，CUDA VMM 负责 VA 与物理 allocation 的显式管理，NVSHMEM 负责 PE、对称堆、RMA/AMO 和同步。NVSHMEM 的动态对称堆可以在内部使用 CUDA VMM，多节点 NVLink 场景又可以通过 Fabric handle 导出 allocation。

这些实现可以共享驱动、页表与 handle，NVIDIA 仍然保留 IPC、VMM 和 NVSHMEM 的不同 API。这个旁证说明：

实现复用不等于语义合并。VMM 为 NVSHMEM 服务，并不会让 VMM 获得 Quiet 或 Team 语义。
便利接口与机制接口可以共存。IPC 面向常见共享流程，VMM 面向精细控制。
Fabric handle 只是能力令牌。它解决 allocation 怎样跨 Fabric 导出，不自动变成内存池或 PGAS 编程模型。

昇腾第二轴的多概念并存因此不是孤例。系统软件常见的正确形态，就是底层机制逐渐统一，而面向不同调用者的契约继续分立。

未来可能怎样收敛¶

下面是基于公开接口与仓库演进作出的设计推断，不是官方路线图。最可能出现的不是“五合一 API”，而是三层收敛。

公共机制下沉¶

驱动页表、物理 handle、Export/Import、权限、注册缓存、拓扑探测、错误码和 DFX 最适合成为公共机制：

共享驱动、页表、handle、注册缓存与 transport 资源
            ↑                         ↑
       CANN VMM / IPC             HCOMM resources
            ↑                         ↑
  SHMEM Runtime / HiXL FabricMem / Ascend MemFabric

这可以减少重复注册、重复建链和多份映射缓存，也能让不同上层共享 Ascend 950 的 UDMA/UBMEM 等资源。

上层语义继续分立¶

IPC 仍需要“一块已有 allocation 怎样共享”的短流程；VMM 仍需要对 VA 和物理页的精细控制；SHMEM 仍要承诺 PE、Team、RMA、Atomic、Fence 和 Quiet；Fabric Memory 仍要编排容量、介质和路径；HCOMM 仍要服务不限定为 PGAS 的通信资源。

这种分立不是保守，而是防止调用者为缺失语义各自补协议。一个表面统一的 remote_memory_op() 如果把完成、故障和生命周期留给上层，通常只是把复杂度从库中赶回应用。

产品适配层逐步变薄¶

HiXL FabricMem、SHMEM 对称堆和 MemFabric GVA 若逐步消费同一套 VMM/Fabric handle，产品层 wrapper 可以减少重复逻辑。是否能够删除某条专用路径，应至少观察以下信号：

HCOMM 对 UB_MEM、URMA、UDMA 等 Endpoint/Channel 资源形成稳定兼容面。
SHMEM 动态对称堆和 Fabric Memory 使用相同的物理 handle、权限与注册缓存。
HiXL 或 MemFabric 能覆盖上层已有的 allocator、并发、映射缓存和故障恢复要求。
同一后端在正确性、p99 时延、CPU/AIV 占用和中间副本上不把成本转嫁给调用者。

如果这些条件尚未满足，删除适配层只会把真实差异藏进不可见分支。

推断边界

公开证据支持“底层资源正在收敛”，不支持“HCOMM、SHMEM Runtime、IPC、VMM 与 Fabric Memory 将合并成同一 API”。内部立项时间、闭源固件、完整硬件矩阵和未来删除版本仍无法从公开资料确认。

怎样验证抽象边界¶

名字和架构图只能给出假设。要判断两个概念是否真的可合并，可以在同一硬件与 CANN 版本上建立四条最小路径：

用 IPC 导出已有 Device allocation，并在另一进程导入、访问和关闭。
用 VMM Reserve、创建物理对象、Map、SetAccess，再导出和导入 handle。
用 SHMEM 建立 PE/Team 与对称堆，在 Kernel 中执行 Put + Signal，并用 Quiet/Wait 建立完成关系。
用 HiXL FabricMem 或 MemFabric 映射远端 DRAM/HBM，重复建立映射并传输相同 Payload。

比较时不能只看峰值带宽，还要记录：

建立成本：初始化、建链、注册、Reserve/Map 和首次访问时间。
稳态成本：p50/p99 时延、带宽、CPU 占用、AIV 占用和队列深度。
语义成本：调用者额外实现了多少同步、权限和生命周期协议。
数据路径：是否发生 staging copy，真正执行搬运的是 MTE、SDMA、RDMA 还是 UDMA。
故障成本：导出进程退出、远端节点失联、异步任务未完成时能否安全恢复。

只有当一个公共后端既保留各入口的完成与故障契约，又没有显著恶化关键工作负载，才说明统一边界放对了。删掉一个 API 不是统一；让调用者不再重复处理同一机制，才是统一。

总结¶

HCOMM、SHMEM Runtime、IPC、CANN VMM 与 Fabric Memory 没有统一，根因不是项目彼此无知，而是它们从不同矛盾出发：

HCOMM 把异构通信资源从 collective 算法中解耦。
SHMEM Runtime 把 PGAS 远端操作和完成语义交给 Host 与 Device 程序。
IPC 在进程隔离下共享已有 allocation。
CANN VMM 把 VA、物理内存、映射和权限拆开管理。
Fabric Memory 把远端 HBM/DRAM 提升为可发现、可分配和可恢复的容量服务。

纵向看，五条路线分别继承了 SHMEM 编程模型、设备 Runtime、虚拟内存、集合通信资源化和大模型内存池化的历史；横向看，它们拥有不同的参与者、命名空间、操作、完成和生命周期。未来最合理的方向是实现机制收敛、产品适配层变薄、上层语义继续分立。

参考资料¶

华为与 CANN¶

CANN HCOMM 仓库与HCOMM README，访问于 2026-08-27。
HCOMM 架构说明与CommProtocol 硬件矩阵，访问于 2026-08-27。
CANN SHMEM 仓库、术语表与硬件/版本矩阵，访问于 2026-08-27。
CANN Runtime 仓库与Runtime 内存样例，访问于 2026-08-27。
CANN 7.0 aclrtFreePhysical、CANN 9.0 VMM 编程指南与aclrtMallocPhysical，访问于 2026-08-27。
CANN 9.1 IPC 内存导出接口与Runtime IPC 样例，访问于 2026-08-27。
CANN HiXL 仓库与FabricMem 模式，访问于 2026-08-27。
Ascend MemFabric，访问于 2026-08-27。
华为 2018：昇腾全栈全场景 AI 方案与 CANN 1.0，2018-10-10。
华为 2020：CANN 3.0 与 AscendCL，2020-08-10。

标准与跨生态资料¶

OpenSHMEM Specification Releases，访问于 2026-08-27。
Sandia：Implementing OpenSHMEM for the Adapteva Parallella，访问于 2026-08-27。
CUDA Driver API：Virtual Memory Management与CUDA IPC Memory，访问于 2026-08-27。
NVSHMEM：Using NVSHMEM与Symmetric Heap Memory Management，访问于 2026-08-27。

证据口径

以上资料支持的是公开接口、仓库状态、版本节点和设计能力。公开首提交只表示不晚于该日已有可见代码；内部立项、闭源实现、芯片微架构和未发布路线图均不作确定性补写。