我最初把 HCCL 理解成集合通信，把 HiXL 理解成单点通信。这个分法可以作为起点，却会让 SHMEM 无处安放：它既能一对一 Put/Get，也能做原子操作与同步，为什么还需要“对称内存”这套约束？

关键在于，HCCL、HiXL 和 SHMEM 并不只是在争夺同一种通信 API。HCCL 更接近“我要完成什么群体操作”，HiXL 更接近“我要把哪段数据传到哪里”，SHMEM 则把问题改写成“我要访问哪个 PE 上的哪个内存坐标”。它用跨 PE 的布局约束，换取设备侧可以低开销地定位和操作远端数据；但当各 PE 的容量需求严重不均时，这份约束也确实可能造成浪费。

《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 日。