Ascend Communication API Evolution

导言

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

同层为何看起来应该统一

把四个方框并排放在总图最上面，很容易把“同一责任轴”读成“同一抽象层”。这个期待并不荒唐：

• 它们都要识别通信参与者和远端地址；
• 都要注册、映射或管理通信内存；
• 都可能使用 HCCS、RoCE、RDMA、UDMA 或 Fabric Memory；
• 都需要异步提交、完成通知、错误处理和性能观测；
• 多个仓库里确实能看到相似的 Endpoint、Channel、Memory、Request 或 Handle。

如果只从“代码复用”看，合成一个大库似乎更简单。但软件抽象是否相同，不能用共同依赖判断。四条通信路径都搬字节，也不表示调用者对参与关系、内存对象、完成顺序和故障处理提出了相同要求。

可以先用四句话建立直觉：

• HCCL 解决“大家一起算完”。
• HiXL 解决“把这些 buffer 搬过去”。
• CANN SHMEM 解决“算子自己操作远端内存”。
• Mooncake UBShmem 解决“在通用库成熟前，把特定 KV 路径先跑通”。

这四句话不是宣传语，而是四种不同的完成条件。完成条件一旦不同，API 就很难靠改名统一。

事实与推断

下文把仓库首个可见提交、公开 PR、文档状态和 release 作为事实；把项目为何分叉、未来如何吸收作为基于接口与代码演进的推断。公开资料不足以还原 HCCL、ADXL、HiXL、SHMEM 和 UBShmem 的内部立项会议与闭源开发起点。

先拆回语义契约

判断两个库是否应该统一，可以先暂时忘掉项目名，问五个不能省略的问题。

1. 通信意图是什么。调用者要整个通信组得到 collective 结果，还是只要某段内存到达某个目标？
2. 参与者怎样组织。是固定 communicator 中的一组 rank、动态选择的源和目标，还是 PE/Team？
3. 内存对象是什么。是 collective buffer、注册 Memory Region、对称堆对象，还是通过 Fabric/IPC handle 导入的映射？
4. 谁在热路径发起。是 Host request、AICPU/AIV collective engine，还是 Kernel 内 Device API？
5. 何时允许继续。等待整个 collective、某个异步 request、quiet/fence/signal，还是 ACL stream 上的一次 copy？

若把库 A 替换为库 B 后，调用者必须补充新的参与者信息、改变内存分配方式，或重写完成与顺序逻辑，那么 A 与 B 就不是同一抽象。它们可以共享实现，却不能无损折叠为同一契约。

入口	应用声明的意图	核心对象	发起位置	完成或顺序边界	主要优化对象
HCCL	一组 rank 完成 AllReduce、AllGather、AlltoAll 等 collective	communicator、rank、collective buffer、算法与拓扑	Host、AICPU、AIV 或 CCU	整个 collective 的阶段与结果	拓扑算法、分块流水与组内协作
HiXL	动态源和目标之间传输一批已注册 buffer	engine、memory registration、transfer request	当前公开主路径主要由 Host 单边提交	request 的同步、异步完成与错误	建链、批量传输、多链路选择与兼容
CANN SHMEM	PE 对远端对称对象执行 RMA、AMO、signal 和同步	PE、Team、symmetric heap、Device API	Host bootstrap；AICore/SIMT 可直接发起	quiet、fence、signal/wait、barrier 与内存序	细粒度 Device RMA 与通算融合
Mooncake UBShmem	KV Cache 走 VMM 映射后的项目专用 copy 快路	segment metadata、Fabric/IPC handle、remapped VA、worker/stream pool	Mooncake Host worker + ACL stream	映射生命周期与 aclrtMemcpyAsync 完成	既有 transport ABI 下的 KV 路径落地速度

这些入口与公共资源的关系更接近下图。上层语义各自稳定，重复的地址、注册、拓扑和数据执行能力向下收敛。

flowchart TB
    subgraph SEM["语义入口：保留差异"]
        HCCL["HCCL\nCollective"]
        HIXL["HiXL\nBuffer Transfer"]
        SHMEM["CANN SHMEM\nDevice PGAS RMA"]
        UBS["Mooncake UBShmem\nMapped KV Fast Path"]
    end

    subgraph RES["公共资源：逐步收敛"]
        HCOMM["HCOMM\nEndpoint / Channel / Memory"]
        VMM["CANN VMM / IPC\nHandle / Map / Access"]
        CAP["Topology / Capability / Registration / DFX"]
    end

    subgraph EXEC["数据执行与互联"]
        ENGINE["MTE / SDMA / RDMA / UDMA / ACL Copy"]
        LINK["PCIe / HCCS / RoCE / UnifiedBus"]
    end

    HCCL --> HCOMM
    HIXL --> VMM
    HIXL -. "能力与资源复用" .-> CAP
    SHMEM --> HCOMM
    SHMEM --> VMM
    UBS --> VMM
    HCOMM --> CAP
    VMM --> CAP
    CAP --> ENGINE --> LINK

图中箭头表示公开实现里可确认或正在增强的资源复用方向，不表示每次调用都经过所有节点，也不表示 UBShmem 已经被 HiXL 或 HCOMM 吸收。

四条路线如何分叉

横向契约解释了“现在为什么不同”，历史纵轴则回答另一个问题：为什么旧库没有顺势扩成新库，而要出现新的 API、模块甚至代码仓？

HCCL：先稳定集体结果

提出契机。HCCL 面对的早期核心负载是分布式训练。参与 rank 相对稳定，框架关心 AllReduce、AllGather、AlltoAll 等完整 collective；库不仅要搬数据，还要决定怎样分块、先与谁交换、在哪个阶段归约，以及如何利用 Ring、Mesh、RHD 或 Pipeline。

这使 HCCL 的基本对象从一开始就不是“源地址、目的地址和长度”，而是 communicator + rank group + collective operation。底层的点对点搬运只有被组织成一致算法，才能得到正确的集体结果。

公开时机。公开 MindSpore 材料表明，HCCL 不晚于 2020 年 3 月已经作为产品能力出现。当前 cann/hccl 与 cann/hcomm 仓库分别在 2025 年 11 月前后出现首个可见提交，并于 2025 年 11 月 30 日正式开源。这个时间只能说明公开节点，不能把 HCCL 的内部诞生日期写成 2025 年。

设计演进。当硬件从 A2/A3 扩到 Ascend 950，链路从 HCCS、PCIe、RoCE 扩到 UB，执行位置又增加 Host、AICPU、AIV 和 CCU 时，把所有资源管理都留在 collective 仓里会越来越重。HCCL/HCOMM 的拆分给出了演进方向：

早期：collective 算法 + 通信资源紧密耦合
  ↓
HCCL：算子、算法、拓扑、executor、template
HCOMM：RankGraph、Endpoint、Channel、Memory、Notify、基础操作

这里发生的是内部资源统一、外部 collective 语义稳定。HCCL 没有扩成 HiXL，是因为“整个组是否完成”不能等价改写成“若干 request 是否完成”；它也没有扩成 SHMEM，因为 collective buffer 不承诺对称堆、PE 寻址或 Device 内存序。

HiXL：动态 buffer 不再伪装成 collective

提出契机。Prefill/Decode 分离、RL 参数切换和 KV Cache 迁移改变了通信形态。源、目标、大小和生命周期都更动态，接收端也不希望为每次 READ/WRITE 配对一个 recv。应用需要的是注册一批 buffer、动态建链、提交同步或异步传输，再由库选择 HCCS、RoCE、UB 或 FabricMem。

若继续沿用集合通信式的固定 rank group，问题不会只是不够优雅。早期演进仍能看到 communicator/rank table 风格的资源组织；连接规模扩大后，这种方式会给弹性建链和生命周期带来压力。公开讨论曾出现过约 512 条链路量级的约束信号；该数字受版本和组网影响，不能写成 HiXL 的永久硬上限，但足以说明固定通信域不适合无限扩展的推理服务。

公开时机。Mooncake 在 2025 年 8 月 18 日合入 Ascend Direct/ADXL，说明旧接口已经进入真实 KV 传输项目。cann/hixl 于 2025 年 10 月 14 日出现首个可见代码提交，11 月继续补异步能力；2026 年 1 月 6 日加入 Fabric Memory 直传代码，3 月进入正式说明。2026 年 4 月 13 日，仓库把 ADXL 接口标为“待废弃”，但兼容头文件、实现和调用方仍然存在。

设计演进。HiXL 把核心对象改成 Engine、RegisterMem、Transfer Request 和完成查询：

ADXL compatibility API ─┐
HIXL current API ───────┴→ common EngineFactory / HIXL Engine
                         → HCCS / RoCE / UB / FabricMem

后续 AutoConnect、HixlCS、Device UBoE 和跨代际路径继续把资源组织从“预先定义一组 rank”推向“按服务、能力和内存对象取得连接”。HixlCS 的 client/server 方向尤其重要：连接资源开始围绕服务端点而不是刚性的集合通信域组织。

所以 HiXL 值得独立，不是因为它发现了一条 HCCL 从未使用的物理链路，而是因为它建立了另一套北向对象、生命周期、错误与完成模型。ADXL 与 HIXL 也不是两套串行协议；它们是迁移中的两个 API 面，最终在共同引擎层会合。

CANN SHMEM：把控制权下沉到算子

提出契机。Host 单边传输仍要由 CPU/Runtime 组织 request。MoE、MC2、自定义融合算子和细粒度 token/tile 流水希望在数据刚就绪时，由 AICore 立即 put、get、signal、wait 或 atomic，减少 Host 下发和粗粒度同步。这里缺少的不是又一个 Host copy 接口，而是一套 Kernel 可见的 PGAS 契约。

OpenSHMEM 的思想早于 CANN 项目：PE、Team、对称对象、RMA、AMO 和同步来自长期发展的 SHMEM/OpenSHMEM 编程模型。CANN SHMEM 的新意在于把这套对象映射到昇腾 Host/Device API，并按芯片选择 MTE、SDMA、RDMA、UDMA 等后端。

公开时机。cann/shmem 于 2025 年 12 月 12 日出现首个可见提交，README 称 2025 年 12 月首次上线；2026 年 2 月出现首批 v1.0 tag。2026 年 4 月 8 日的 v1.3 加入 AICore 直驱和 40+ 接口，2026 年 7 月 30 日的 v1.6 继续完善 Ascend 950 的 UDMA/MTE/RDMA/SIMT 与诊断。

设计演进。新仓库需要自己拥有一组无法藏入 HiXL compatibility layer 或 HCCL executor 的对象：

• PE 与 Team决定参与者和子组；
• symmetric heap决定远端对象如何命名；
• RMA/AMO定义可执行的远端操作；
• signal/wait、quiet、fence、barrier定义完成、发布和顺序；
• Device headers 与 transport允许 AICore/SIMT 在 Kernel 内发起。

CANN SHMEM 与 HiXL 都可以被称为“单边通信”，但单边只表示 payload 不需要逐次匹配接收。HiXL 把一次传输建模为 Host request，SHMEM 把远端操作建模为并行程序中的内存动作。底层都能使用 RDMA 或 UDMA，不足以抹平这个差异。

当前公开资料也不足以声称 cann/shmem 已通过完整 OpenSHMEM 1.6 一致性测试；cann/shmem v1.6 与 OpenSHMEM 1.6 版本号相同不能被解释为完整兼容证明。

UBShmem：通用能力成熟前的项目快路

Mooncake UBShmem 最能解释“为什么会出现新代码”，也最容易因为名字被误读。

提出契机。Mooncake Transfer Engine 已有自己的 Segment、Metadata、Allocator、Worker、Stream Pool 和 transport plugin ABI。项目希望把远端 NPU HBM 通过 CANN VMM/Fabric handle 导入当前进程，缓存重映射关系，再在 ACL stream 上直接复制 KV Cache。等待通用库完全覆盖部署矩阵，会拖慢项目自己的交付节奏。

公开时机。Mooncake issue #1312 于 2025 年 12 月 31 日提出 VMM/Fabric Memory 路径；PR #1399 在 2026 年 1 月 18 日创建、1 月 26 日合入。2 月的 PR #1519 增加 IPC 与 allocator，3 月继续加入线程池、stream pool 和 Store 适配。

这里有一个重要的时间重叠：HiXL FabricMem 的首个可定位公开代码提交是 2026 年 1 月 6 日，Mooncake UBShmem 的实现 PR 是 1 月 18 日。两条路线几乎同时公开，更像通用产品能力与项目集成快路的并行试验，而不是一个成熟标准已经存在，Mooncake 又无视它重新实现。

实际设计。当前公开代码关系是：

Mooncake Store / KV Cache
  → UBShmemTransport：metadata、地址重定位、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_*。所以 UBShmem 里的 SHMEM 不能推出 PE、Team、对称堆或 AIV 直驱。它甚至不是一个独立顶层仓库，而是 Mooncake 内部的新 transport 模块；这再次说明新抽象与新代码边界不必一一对应于新仓库名。

后续收敛信号。2026 年 8 月，Mooncake PR #3285 用 ADXL/HiXL VMM 组织共享 Host KV segment，PR #3302 开始探测 AutoConnect/HixlCS 能力，PR #3453 又清理同设备 HCCS legacy offset。它们表明项目快路正在更多地消费通用建链和内存资源。

但这不是官方吸收公告。UBShmem 是否能退化为 HiXL FabricMem 的薄适配器，仍取决于 allocator、映射缓存、并发、连续与多页内存、拓扑覆盖、错误恢复和性能阈值是否一致。

时间轴揭示了什么

把四条路线放回同一张时间表，可以看到它们并非线性替代。

日期	公开节点	暴露的新问题	设计方向
2020-03 前后	HCCL 已作为 MindSpore 产品能力出现	固定 rank 组怎样高效完成 collective	算法、拓扑、分块和组内完成
2025-08	Mooncake 合入 Ascend Direct/ADXL	PD/KV 传输需要 Host 单边 buffer API	注册内存、批量 READ/WRITE、多链路
2025-10	HiXL 公开仓出现	旧通信域难覆盖动态推理服务	Engine/Request 与兼容层并行
2025-11	HCCL/HCOMM 正式开源	collective 与通信资源需要独立演进	算法层和资源层拆仓
2025-12	CANN SHMEM 公开；Mooncake 提出 UBShmem	Kernel 内细粒度 RMA 与项目映射快路同时出现	Device PGAS 与 VMM plugin 分叉
2026-01	HiXL FabricMem 与 Mooncake UBShmem 几乎同时公开代码	远端 HBM 映射和 KV 快路进入工程集成期	通用 capability 与项目 adapter 并行试验
2026-04	SHMEM v1.3；ADXL 标为待废弃	Device 直驱成熟，新旧 Host API 开始收口	SHMEM 扩展、HiXL API 迁移
2026-07	SHMEM v1.6	Ascend 950 多后端与 SIMT 能力继续补齐	UDMA/MTE/RDMA 组合而非单一替代
2026-08	Mooncake 探测 AutoConnect/HixlCS 并复用 HiXL VMM	项目快路需要接入通用资源管理	wrapper 变薄的早期信号

时间密度在 2025–2026 年突然增加，不能推出这些需求都在这一时期才出现。更稳妥的解释是三次重心变化：

1. 训练 collective 阶段先稳定组语义和拓扑算法，HCCL 成为框架主入口。
2. 分离式推理阶段把动态 buffer、内存注册和弹性建链推到前台，HiXL/ADXL 出现。
3. 通算融合与 Fabric 阶段要求 Device 侧 RMA 和远端内存映射，CANN SHMEM 与 UBShmem 分别从通用编程模型和项目落地两端推进。

因此，这不是 HCCL → HiXL → SHMEM → UBShmem 的代际链，而是工作负载增加后，语义入口不断分化、底层资源逐步汇合的过程。

哪些差异不能抹平

从横轴比较，四者之间既有本质差异，也有可以被历史演进消化的偶然差异。

本质差异

1. 参与关系不同。HCCL 要求一组 rank 对同一 collective 达成共同进度；HiXL 允许动态源和目标；SHMEM 以 PE/Team 组织并行程序；UBShmem 受 Mooncake Segment 与 transport 生命周期约束。
2. 内存对象不同。collective buffer、registered buffer、symmetric object 和 imported mapping 不能只用一个裸指针概括。
3. 发起位置不同。Host request、collective engine、AICore Device API 和 ACL worker 的热路径成本与故障处理完全不同。
4. 完成与顺序不同。collective completion、request completion、quiet/fence/signal 和 stream completion 不能共用一个含义模糊的 done。
5. 性能区间不同。规则 collective、动态大块 KV、细粒度 token/tile RMA 和重复映射的主要瓶颈分别落在算法、建链、提交/同步和映射缓存。

这些差异如果被塞进一个 API，只会得到两种结果：要么退化成最小公共 copy 接口，丢掉 collective、atomic 和内存序；要么形成一个包含大量 mode、flag 和隐式约束的万能对象，把复杂度推回调用者。

偶然差异

以下差异更可能随演进被收敛：

• HCCL 与 HCOMM 的仓库边界和资源所有权；
• ADXL 与 HIXL 两套北向命名及兼容头文件；
• 各库重复的内存注册、拓扑探测和错误码；
• Mooncake transport plugin 为赶上项目发布节奏形成的专用 wrapper；
• 同一种 Fabric/VMM handle 在不同上层的封装方式；
• 不同仓库各自维护的 DFX、capability probe 和回退判断。

所以“为什么没有统一”不能只回答“因为需求不同”。更完整的判断是：语义契约的差异需要长期保留，资源管理和历史兼容的差异才是收敛对象。

新思想何时值得新仓库

“演进会产生新代码仓”只在特定条件下成立。一个新后端、一个新芯片分支或一次性能优化，并不自动需要独立仓库。更可操作的判断标准有四个：

1. 新的北向对象。旧 API 是否无法稳定表达新的参与者、内存对象和操作？
2. 独立生命周期与故障域。新能力是否必须自己处理初始化、连接、异步完成、对端退出和资源回收？
3. 多后端策略。它是否需要在多芯片、多链路、多内存类型之间独立选择与回退？
4. 独立兼容矩阵。它是否需要与原仓库不同的版本、测试、发布和调用方迁移节奏？

按这个标准回看四条路线：

• HCCL/HCOMM 的拆分成立，因为 collective 算法与通信资源已经拥有不同的复用范围和发布责任。
• HiXL 独立成立，因为动态 buffer transfer、Engine/Request、注册内存与多链路选择形成完整产品面。
• CANN SHMEM 独立成立，因为 PE/Team、对称堆、Device RMA/AMO 和内存序构成新的编程模型。
• Mooncake UBShmem 更适合作为项目内模块，因为它优先服从 Mooncake transport ABI，并未形成跨项目的完整北向标准。

反过来，如果变化只是在相同 API 下增加 UDMA 后端、替换 descriptor 格式或优化某个拓扑算法，把它留在原仓库通常更合理。新仓库应该承载新的稳定契约，而不是为每个新缩写建立纪念碑。

未来会怎样收敛

以下是根据公开接口与代码变化连接得到的推断，不是华为或 Mooncake 的正式路线承诺。

语义入口继续并存

HCCL、HiXL 与 CANN SHMEM 很可能长期保留三个入口：collective、Host buffer transfer 和 Device PGAS RMA。它们可以互相调用或复用资源，但调用者仍需要明确自己等待的是什么结果。

这种结构并非昇腾独有。NVIDIA 生态同时保留 NCCL、NIXL 和 NVSHMEM：分别面向 collective、异构单边数据传输和 Device PGAS。这个横向旁证不能证明 Ascend 的官方路线，却说明共享 CUDA/NIC/内存基础设施与保留多种上层语义并不矛盾。

公共资源继续下沉

更值得统一的部分包括：

• HCOMM Endpoint、Channel、Memory、Notify 与基础操作；
• CANN VMM/IPC 的 physical handle、VA、Map 与 Access；
• 注册缓存、拓扑与 capability discovery；
• HCCS、RoCE、UB/FabricMem 路径选择；
• 错误码、日志、profiling、回退和故障恢复。

当这些能力成为稳定公共层，新语义库不必再次实现芯片和链路细节，旧库也更容易在不改变 API 的情况下获得新后端。

项目快路逐步变薄

Mooncake UBShmem 最可能的长期形态不是与 HiXL 永久维护两套完整 Fabric Memory 产品，也不是立刻删除，而是逐步缩成 Mooncake 语义与通用能力之间的适配层。

这个判断成立至少需要六个条件：

1. HiXL FabricMem 覆盖 Mooncake 的 allocator 和 Segment 生命周期；
2. 映射缓存与重复传输的 p99 不劣于 UBShmem；
3. 连续、多页和不同粒度的内存都能正确处理；
4. A3、Ascend 950 及目标拓扑具有清楚的 capability matrix；
5. 对端退出、异步失败和资源回收语义一致；
6. Mooncake 现有 transport ABI 不需要暴露大量 HiXL 私有细节。

收敛不等于已合并

当前证据只支持“底层资源与能力探测正在收敛”。它不支持“四个上层概念会统一成一个 API”，也不支持“UBShmem 已被 HiXL FabricMem 吸收”。ADXL 的最终删除版本、UBShmem 的长期归属和内部项目路线仍未公开确认。

用实验判断统一边界

名字和架构图只能提出假设。要验证统一边界是否放对，最小实验应在同一硬件、同一 CANN 版本和可比内存位置上覆盖四种负载。

负载	要保护的上层契约	关键观测
规则 AllReduce	全组 collective 结果与算法进度	算法选择、分块、尾延迟、组内异常
动态 KV 批量传输	注册、弹性建链与 request completion	建链成本、p99、CPU、并发 request、回退
Kernel 内 put + signal	Device 发起、远端完成与消费者可见	AIV 占用、提交时延、quiet/fence、内存序
重复 Fabric/VMM 映射	handle、VA、mapping cache 与生命周期	首次映射、缓存命中、页粒度、释放与失败恢复

除了峰值带宽，还要同时记录：

• 初始化、注册、建链和映射的一次性成本；
• 小消息、tile 与大块 buffer 的吞吐拐点；
• CPU、AICPU、AIV 和内存资源占用；
• 中间 copy、staging buffer 与真实 payload bytes；
• 完成通知到远端消费者安全可见的时间；
• 对端退出、超时、重试、回退和资源清理行为。

如果同一个公共后端能以薄适配器保持四种契约，并且没有把某类负载的关键成本转嫁给调用者，说明实现层统一是成功的。若统一 API 迫使 collective 调用者管理 request、让 HiXL 用户理解 PE 对称地址，或让 SHMEM Kernel 等待 Host worker，那么统一边界就放得太高了。

结论

回到开头：HCCL、HiXL、CANN SHMEM 和 Mooncake UBShmem 为什么没有统一？

因为它们不是四个版本的同一种通信库。HCCL 以集体结果为中心，HiXL 以动态 buffer request 为中心，CANN SHMEM 以 Device PGAS 内存动作和顺序为中心，UBShmem 则以 Mooncake 的映射型 KV 快路为中心。相同硬件只说明它们可以共享底层实现，不足以证明上层契约相同。

现在可以确认的是：公开代码已经显示 HCOMM、VMM、注册、拓扑和 capability probe 在被更多入口复用；时间线也显示 HiXL FabricMem 与 UBShmem 是几乎同时出现的并行尝试，而不是简单的前后替代。

仍不能确认的是内部立项日期、ADXL 最终删除版本、UBShmem 的正式归宿，以及所有硬件组合下的性能等价性。下一步若要判断哪条路线会被吸收，应比较同一组参与者、内存对象、完成语义和故障条件，而不是继续从 Direct、SHMEM 或 Fabric 这些名字推断包含关系。

参考资料

1. Ascend Communication Stack：总体架构
2. CANN HCCL 仓库与HCCL 简介
3. CANN HCOMM 仓库与HCOMM README
4. CANN HiXL 仓库
5. HiXL：待废弃 ADXL 接口
6. HiXL：FabricMem 模式
7. CANN SHMEM 仓库、术语表与硬件/版本矩阵
8. OpenSHMEM Specification Releases
9. Mooncake PR #740：Ascend Direct/ADXL
10. Mooncake issue #1312：Ascend UBShmem transport
11. Mooncake PR #1399：UBShmem/Fabric Memory
12. Mooncake PR #1519：UBShmem IPC 与 allocator
13. Mooncake UBShmem transport
14. Mooncake PR #3285：共享 Host KV segment
15. Mooncake PR #3302：AutoConnect/HixlCS 能力探测
16. Mooncake PR #3453：同设备 HCCS legacy offset 清理
17. NVIDIA NCCL User Guide
18. NVIDIA NVSHMEM Documentation
19. NVIDIA NIXL

证据口径

以上链接用于支持公开接口、代码状态和时间节点。内部立项、闭源固件、芯片 RTL 沿革与尚未公告的产品路线仍保持未确认状态。