Ascend Data Movement Evolution

导言

在昇腾通信栈的第四轴里，ACL Copy、LD-ST、MTE、IPC、SDMA、RDMA 与 UDMA 被放在相邻位置。看到这么多搬运相关名词，一个很自然的判断是：它们大概是同一种能力的不同代际，后来者之所以出现，是因为前一代不够好。

这个判断抓住了技术演进的一部分，却把几类不同对象混在了一起。这些概念不是七代同类传输引擎，而是地址能力、操作表达和执行后端在不同距离、粒度与控制路径下的组合。本文从无法绕开的物理成本出发，再沿历史纵轴和技术横轴解释它们为何没有统一，以及什么时候一种新思想才真正值得形成新的代码仓。

一个看似合理的误读

《Ascend Communication Stack》中的总图，从上到下依次回答通信语义、地址与资源、提交者、搬运机制和物理互联。第四轴正好位于“谁提交任务”和“字节从哪里走”之间，因此很容易被读成一排可互换的传输引擎。

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

真正需要先拆开的，是第四轴内部的对象类型：

地址与权限：IPC / VMM / 内存注册
        ↓
操作表达：ACL Copy / LD-ST / Put / Get / Atomic
        ↓
执行后端：MTE / SDMA / RDMA / UDMA
        ↓
物理互联：NoC / PCIe / HCCS / RoCE / UnifiedBus

这是一张责任关系图，不表示每条真实路径都会经过所有方框。IPC 可能只建立共享映射，随后程序直接 LD-ST；aclrtMemcpyAsync 也可能根据地址和拓扑落到不同底层路径。相邻不等于同类，更不等于替代关系。

不是七代技术

ACL Copy 是 Runtime API，LD-ST 是访问方式，IPC 主要建立跨进程地址关系；MTE、SDMA、RDMA 和 UDMA 才更接近搬运引擎或远端数据机制。若先把它们统称为“七种传输引擎”，后面的历史和包含关系一定会错。

无法消失的成本

把行业名词暂时放下，一次数据访问至少要支付六类成本：建立地址和权限、提交任务、移动 Payload、确认完成、保证消费者可见，以及处理故障。可以用一个不追求精确、但便于定位问题的式子表示：

$$
T =
T_{\text{address}}

• T_{\text{issue}}
• \frac{\text{Bytes}}{\text{Bandwidth}}
• T_{\text{completion}}
• T_{\text{visibility}}
• T_{\text{recovery}}.
  $$

七个概念优化的并不是同一项：

• ACL Copy主要降低应用编程和路径选择复杂度。
• LD-ST减少细粒度访问的队列化提交成本。
• IPC把跨进程映射和授权成本从每次访问中分离出来。
• MTE让搬运进入 AI Core 流水，与计算重叠。
• SDMA承担节点内大块系统级搬运，避免占用计算单元。
• RDMA处理跨节点直接放置、远端保护和网络完成。
• UDMA面向 UnifiedBus，把远端队列、内存语义、原子操作和 Device 侧提交结合起来。

为什么不能让其中一个包办全部工作？因为下面这些约束不会因 API 设计而消失：

1. 距离不同。核内、卡内、同机多卡、跨进程、跨服务器和超节点具有不同的时延与故障域。
2. 粒度不同。几个字节的 flag、几十 KB 的 tile 和数 GB 的 KV Cache，不会由同一种提交方式同时达到最优。
3. 地址不同。本地 VA、IPC 导入地址、RDMA MR/rkey、UDMA 注册内存和 Token 不能无条件互换。
4. 完成不同。指令结束、Stream Event、MTE Pipeline Event、CQE、quiet() 和远端消费者可见并不是同一个“完成”。
5. 发起者不同。Host、AICPU、AIV 或其他控制单元都可能生成任务；是否允许 Device 直驱会改变热路径和资源竞争。
6. 代际不同。A2/A3 与 Ascend 950 的互联和执行资源不同，软件不能为了接口整齐而放弃已经部署的硬件。

所以，真正值得追求的不是一个万能搬运器，而是上层意图统一、底层能力可发现、路径选择可验证。

七个概念怎样走到一起

它们并不是沿同一条时间线依次出现。更准确的历史，是作用域不断扩大后，系统逐步把访问表达、数据执行和地址控制解耦。

从 LD-ST 到 ACL Copy

LD-ST 是处理器访问内存的基础方式，不存在一个可归属给某个 Ascend 仓库的单一提出日期。它适合小粒度、随机或状态型访问，例如 flag、计数器和队列状态；代价是每次访问都要服从地址翻译、缓存和内存序规则。

当 Host、Device 和不同 Device 拥有独立地址空间后，仅靠普通 LD-ST 已不能给应用提供稳定的数据交换接口。2020 年 8 月，CANN 3.0 公开 AscendCL 统一编程接口，目标是让同一套应用代码适配多种设备形态、操作系统和框架。华为 CANN 3.0 与 AscendCL

aclrtMemcpy、aclrtMemcpyAsync 由此承担一种不同责任：应用提供源地址、目的地址、长度、方向和 Stream，Runtime 再识别 H2D、D2H、同卡或跨卡 D2D。当前 Runtime 文档也明确表示，Device-to-Device 复制可由 Runtime 根据源、目的地址判断实际路径。CANN Runtime 数据复制

这次演进统一的是应用接口，不是把所有硬件搬运器改造成了一个引擎。

从 MTE 到 SDMA

AI Core 的 Cube 和 Vector 计算速度很快，但数据分布在 GM、L1、L0 和 Unified Buffer 等不同存储层。若计算单元自己用普通指令搬完整个 tile，算力会长期等待数据。

MTE 的设计因此贴近计算流水。MTE1、MTE2、MTE3 服务不同存储层之间的数据移动，搬入、计算和搬出可以配合双缓冲与 Pipeline Event 重叠。官方架构文档也直接把 MTE1/2/3 定义为 AI Core 内的数据传输 DMA 单元。Ascend C 硬件架构

但节点内跨卡和 Host—Device 的大块传输不应该持续占用 AI Core。SDMA 把搬运提升到系统层，常见于 HCCS、PCIe、SIO 等节点内路径。官方性能工具把 SDMA 列为节点内传输类型，把 HCCS、PCIe、SIO 列为链路，同时把 RDMA 单列为跨节点路径。MindStudio 通信分析

二者的边界由此变得清楚：MTE 优化算子内 tile 流水，SDMA 优化系统级大块搬运。即便新的 Device API 允许 AIV 直接提交 SDMA 任务，提交者发生了变化，Payload Engine 的职责仍没有消失。

MTE、SDMA 的内部立项时间和首次 RTL 版本没有公开一手证据。现有材料只能确认公开产品与文档中的能力，不能用某次开源或文档发布日期替代技术诞生日期。

从 IPC 到 RDMA

操作系统必须隔离进程，所以进程 A 的 Device 指针对进程 B 通常没有意义。多进程推理、权重共享和 KV Cache 复用却又希望避免重复分配和复制，这正是 IPC 内存共享出现的契机。

IPC 的典型流程是：出借进程导出 key 或 handle，Runtime 检查页粒度、设备关系和进程权限，借入进程再导入一个对自己有效的 Device VA。双方还要共同维护引用、关闭顺序和原内存生命周期。CANN Runtime IPC

这里最容易误解的一点是：IPC 不一定搬 Payload。导入之后，程序可以直接访问共享页，也可以再用 MTE 或 ACL Copy 读取数据。IPC 解决的是地址和授权问题。

作用域扩展到跨服务器后，问题又变了。除了远端地址，还要处理网络路由、Memory Region、key、Queue Pair、Completion Queue、拥塞、重试和异常恢复。2007 年的 RDMAP RFC 5040 已明确提出 Direct Data Placement、远端读写、减少中间复制和 Kernel Bypass。RFC 5040

因此，IPC 不能自然升级成 RDMA。前者假设受支持的共享域和映射关系，后者面对独立主机与网络故障域；它们只是都使用了“远端地址”这个表面相似的词。

UDMA 为什么在此时出现

传统系统很容易把通信划成两类：节点内走 SDMA，节点间走 RDMA。但 SuperPoD 希望在更大的 Scale-Up 域内统一连接 CPU、NPU、内存和存储，同时支持 RMA、Atomic、Signal 与 Device 侧直接提交。原来的“机内/机外”边界开始变得不够用了。

这里特指 CANN 语境中的 Unified Direct Memory Access。它围绕 UnifiedBus 的地址、队列、Token、WQE、CQ 和远端内存操作组织数据面。UDMA 的描述符可能经 MTE 暂存或下发，但大块 Payload 由 UDMA 执行，不能因为两者出现在同一条调用链就把它们合并。

公开时间需要分层理解：

• 华为披露 UnifiedBus 上位技术研究始于 2019 年，但这不能证明 UDMA 同年已经内部立项。
• 2025 年 9 月，UnifiedBus 2.0 规范公开。Huawei UnifiedBus 主题演讲
• 2025 年 12 月，cann/shmem 首次公开上线。
• 2026 年 4 月，SHMEM v1.3 增加 AI Core 直驱能力。
• 2026 年 7 月，SHMEM v1.6 明确增强 Ascend 950 的 UDMA/MTE、RMA、Atomic 和 SIMT 数据搬运能力。CANN SHMEM README

当前公开硬件矩阵同样能说明它不是线性替代：Ascend 950 同时保留 MTE、RDMA，并增加 UDMA；A3 仍使用 MTE、SDMA、RDMA。CANN SHMEM Quick Start

时间口径

通用概念形成、Ascend 产品首次支持、官方首次公开说明、仓库首提交和首个 Release 是五个不同时间。本文只把可核验的公开节点写成事实；MTE、SDMA、IPC、UDMA 的内部立项和闭源硬件沿革仍然暂未核实。

横向比较

沿相同维度比较后，“为何没有统一”会比逐个背缩写更直观。

概念	实际类型	最适合的范围	地址与完成边界	不可替代的差异
ACL Copy	Host Runtime API	通用 H2D、D2H、D2D 复制	Device/Host 地址；同步返回或 Stream/Event	稳定接口、路径隐藏和跨硬件兼容
LD-ST	指令或同步访问模型	小粒度、随机访问、状态变量	必须先有可访问地址；依程序序、fence 与 cache 规则	避免为每个细粒度访问构造批量任务
IPC	地址和能力共享	同机或受支持共享域	key/handle、导入 VA、权限与生命周期	让不同进程看见同一资源；本身不必搬数据
MTE	AI Core DMA 流水	GM、L1、L0、UB 与映射 Peer GM	Pipeline Event 与 Kernel 内依赖	tile 搬运、双缓冲和通算重叠
SDMA	系统级 DMA 引擎	节点内 HCCS、PCIe、SIO	由 Runtime/HCOMM 建资源并报告完成	不占用 AI Core 的系统级大块搬运
RDMA	网络远程内存机制	跨节点、RoCE/InfiniBand 类网络	MR、key、QP、CQ 与网络错误状态	路由、可靠传输、远端保护和跨机故障处理
UDMA	UB 专用统一 DMA 后端	Ascend 950、UnifiedBus 域	注册内存、Token、WQE、CQ、quiet/fence	UB 内存语义、RMA/AMO 与 Device 直驱

这张表也解释了两个经常出现的组合：

• IPC + MTE：IPC 建立 Peer VA，MTE 真正搬运或消费数据。
• MTE + UDMA：MTE 可能下发描述符，UDMA 搬运大块 Payload。

组合不是重复。恰恰因为责任被拆开，系统才可以在不重写全部上层语义的情况下更换其中一段。

新仓库为什么出现

“新思想产生新代码仓”这个判断只对了一半。一个新硬件引擎的完整实现往往横跨编译器、Runtime、Driver、固件和芯片，并不会自然对应一个同名仓库。真正促成独立仓库的，通常是新的对象模型、API 契约、生命周期和发布节奏。

• **cann/runtime**管理 Device、Stream、Event、ACL Copy、IPC 与 VMM，目标是稳定应用 ABI 和资源生命周期。
• **cann/hcomm、cann/hccl**管理通信域、Endpoint、Channel、Collective 算法和通信资源。
• **cann/hixl**面向 Host 侧单边 Buffer 传输、动态建链和多链路选择。
• **cann/shmem**引入 PE、Team、对称堆、RMA、AMO、Signal、Fence 等编程模型，再把 MTE、SDMA、RDMA 和 UDMA 组织成后端。

这里的演进单位不是“多了一辆更快的搬运车”，而是上层开始需要表达新的通信对象。当旧仓库只能靠私有 flag、旁路 wrapper 和特殊生命周期不断打补丁时，新的独立抽象才有成立理由。

反过来也成立：如果变化只是在相同 API 下替换硬件实现、增加一个拓扑分支或优化 Descriptor，就没有必要仅为了新名称创建仓库。

应该统一什么

若从第一性原理重新设计，最有价值的统一发生在引擎之上：

1. 统一意图。应用表达 Copy、Read、Write、Atomic、Signal、Collective 或 tile dependency，而不是直接绑定某个硬件名字。
2. 统一能力描述。Runtime 能查询拓扑、内存类型、地址可达性、粒度、发起者和完成能力。
3. 统一生命周期。注册、映射、key、Token、in-flight 请求和资源释放具有可检查的契约。
4. 统一可观测性。性能数据能拆出地址建立、提交、Payload、完成和消费者可见，而不是只报告一个总带宽。

底层仍应保留多种后端。若强行把所有能力压成最小公共接口，Atomic、Device 直驱、tile pipeline 和网络恢复会被抹平；若把所有差异全部暴露给应用，所谓统一又只剩下一组更长的 if/else。

可能怎样演进

以下三条属于基于公开能力连接得到的推断，不是官方路线承诺。

语义入口继续收敛

应用会更多表达操作意图和完成要求，由 Runtime、HCOMM、SHMEM 或 HiXL 选择实际后端。先行信号是能力查询和自动路径选择逐渐稳定，上层项目减少按引擎名称硬编码构建开关。

引擎长期共存

MTE 继续负责计算近端流水，UDMA 承担 Ascend 950 的 UB 路径，RDMA 服务跨超节点和异构网络，旧平台继续使用 SDMA/HCCS。先行信号不是某个旧名字从文档消失，而是新硬件的默认算法和性能工具开始明确展示不同路径的适用区间。

控制路径继续下沉

细粒度 MoE、KV Cache 和通算融合会继续推动 AIV 直驱，但粗粒度 Host API 不会因此消失。成立前提是节省的提交延迟足以覆盖 AIV 资源竞争、调试难度和异常恢复成本。

怎样验证一次新演进

判断新机制是否真的改变了系统，不应只比较峰值带宽。更稳妥的第一步，是对同一个 Buffer 和同一组拓扑分别记录：

• 一次性初始化、映射和注册成本；
• 单次提交延迟与可持续并发深度；
• 小包、tile 与大块 Payload 的吞吐拐点；
• 完成通知到消费者真正可见的时间；
• Host、AICPU、AIV 和内存资源占用；
• 错误、重试、回退与资源释放语义。

只有这样，才能说清一条新路径究竟减少了公式里的哪一项，而不是根据名字里出现 Direct、Unified 或“零拷贝”就推断它全面领先。

总结

回到最初的问题：ACL Copy、LD-ST、MTE、IPC、SDMA、RDMA 与 UDMA 为什么没有统一？

因为它们原本就没有在解决同一个问题。ACL Copy 统一应用接口，LD-ST 表达细粒度访问，IPC 建立跨进程地址，MTE 服务计算流水，SDMA 服务节点内系统搬运，RDMA 跨越网络故障域，UDMA 则面向 UnifiedBus 和 Device 侧远端操作。

真正的技术演进不是后一项把前一项删除，而是作用域扩大后，把原本纠缠在一起的地址、提交、执行、完成与互联继续解耦。新代码仓也不是新缩写的纪念碑；它应当承载一种已经稳定、值得独立维护的新编程模型。

仍然不能确认的是这些机制的内部立项时间、闭源固件路径和全部芯片微架构。下一步若要判断某条新路径是否会取代旧路径，应回到同一组成本和完成语义上测量，而不是继续比较名称。

参考资料

1. Ascend Communication Stack：总体架构
2. 华为：CANN 3.0 与 AscendCL
3. CANN Runtime：数据复制
4. Ascend C：AI Core 与 MTE 架构
5. MindStudio：SDMA 与 RDMA 通信分析
6. CANN Runtime：进程间通信
7. RFC 5040：Remote Direct Memory Access Protocol
8. Huawei UnifiedBus 主题演讲
9. CANN SHMEM README
10. CANN SHMEM Quick Start