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

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

《Ascend Communication Stack》把 HCCL、HiXL、CANN SHMEM 和 Mooncake UBShmem 放在第一轴。既然它们最终都在昇腾设备之间搬数据，也会复用相似的 Runtime、内存和硬件资源，一个很自然的问题是：为什么没有统一成一个库？

关键不在名字，也不在 payload 最后走 HCCS、RoCE 还是 UB，而在调用者究竟声明了什么契约。HCCL 声明 collective，HiXL 声明一批 buffer transfer，CANN SHMEM 声明 PE 对对称对象的 RMA/AMO，Mooncake UBShmem 则服务项目自己的映射型 KV 快路。本文沿公开时间线还原四条路线的提出契机与设计转折，再横向判断哪些差异必须保留、哪些历史包袱可以收敛。研究截止日为 2026 年 8 月 26 日。

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

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

我看到 Mooncake 为 Ascend 提供了三个编译开关：USE_ASCEND、USE_ASCEND_DIRECT 和 USE_UBSHMEM。最直接的问题是：它们是不是三套并列的通信 engine？特别是后两个名字里已经有 Direct 和 SHMEM，是否意味着数据传输已经由 AIV 直驱？

沿着合入 PR 和源码调用链看下去，答案逐渐清楚：这不是三套同层方案，而是 Mooncake 先后解决“能传”“通用地传”和“把远端内存映射后再传”三个问题留下的三条路径。更重要的是，按当前可见源码，三者都不能直接称为 AIV 直驱。