runtime 运行时昇腾NPU的“操作系统内核”刚接触 CANN 那会我以为 runtime 就是个“运行时库”调几个 API 就完事。后来帮一个朋友排查 FlashAttention 算子执行慢的问题发现 runtime 才是真正的“幕后黑手”——算子再快runtime 调度不当NPU 算力也跑不满。昇腾NPU 上跑模型runtime 是绕不开的基础设施。CANN 把 runtime 放在第五层架构的“执行层”负责把编译好的算子真正扔到 NPU 硬件上跑。这次把 runtime 的架构拆清楚以后排查性能问题就不会再迷路。环境准备理解 runtime 在 CANN 中的位置在开始拆解 runtime 架构之前先得搞清楚它跟其他组件的关系。runtime 的定位CANN 五层架构中的第4层昇腾计算执行层它位于图编译器之下驱动之上。上层对接Graph Compiler图编译器、BiSheng/ATC编译器。下层对接Driver驱动、NPU 硬件达芬奇架构。依赖关系你的 PyTorch 模型 ↓ (框架适配层) Graph Compiler图编译 ↓ (编译成执行计划) runtime运行时 ↓ (调用底层接口) driver驱动 ↓ (真正干活) 昇腾NPU 达芬奇架构硬件FlashAttention 的执行链路ops-transformer的 FlashAttention 算子→\rightarrow→调用 Ascend C 编程接口→\rightarrow→runtime 把算子调度到 AI Core→\rightarrow→在 NPU 上执行矩阵分块计算。如果 runtime 调度不当比如任务分配不均、数据搬运没重叠FlashAttention 的延迟就会上去。逐步推进runtime 的核心模块拆解runtime 不是单一模块而是一组协同工作的子系统。结合CANN 8.0当前时间 2026 年 5 月的主流版本的特性核心模块有 5 个1. Runtime 运行时核心调度器这是 runtime 的“大脑”负责设备管理检测 NPU 设备、分配设备上下文。任务调度把算子任务分配给多个 AI Core 并行执行。内存管理管理 NPU 上的 GM全局内存、L1、L0。关键 APIAscendCL 接口importacl# 初始化运行时acl.init()# 申请 NPU 设备device_id0acl.rt.set_device(device_id)# 分配内存GM 上data_size1024*1024# 1MBdata_ptr,_acl.rt.malloc(data_size,acl.rt.MemType.MEM_TYPE_NORMAL)# 释放设备acl.rt.reset_device(device_id)acl.finalize()⚠️踩坑预警acl.rt.malloc申请的是 NPU 的 GM 内存不是主机内存。如果你把主机指针传给 NPU 算子会报“非法内存访问”错误。正确做法是先用acl.rt.malloc申请 NPU 内存再用acl.rt.memcpy把数据从主机拷到 NPU。2. Graph Executor图执行器如果你的模型是用 CANN 的图开发接口构建的比如用了 GE 图引擎Graph Executor 负责图解析把编译好的图.om 文件解析成执行计划。节点调度按拓扑顺序执行图中的算子节点。数据流转管理算子之间的中间数据不写回主机直接在 NPU 上传递。FlashAttention 如果跑在图模式下Graph Executor 会把 Q、K、V 的算子融合成一个子图减少数据搬运次数。验证 Graph Executor 是否工作# 检查图执行日志cat/var/log/npu/log/runtime.log|grepGraphExecutor如果看到 “GraphExecutor: Load graph success”说明图加载成功。3. HCCL集合通信库如果你做的是分布式训练/推理比如 Megatron 昇腾NPUHCCL 负责集合通信AllReduce、AllGather、ReduceScatter 等。多卡协同多个 NPU 之间的数据同步。FlashAttention 在分布式场景下需要 HCCL 做Ring Attention把序列维度切分到多个 NPU 上并行算。⚠️踩坑预警HCCL 的初始化很慢第一次要建通信组。如果你在测试用例里频繁初始化/销毁 HCCL性能会很差。正确做法是进程启动时初始化一次整个生命周期复用。4. DVPP数字视觉预处理如果你的模型输入是图像/视频DVPP 负责图像解码JPEG/PNG 解码成 YUV/RGB。预处理Resize、Crop、Color Space Conversion。零拷贝预处理完直接扔给 NPU 算子不写回主机。FlashAttention 本身不调 DVPP但如果你的模型是 Vision TransformerViT输入图像就得先过 DVPP 做预处理。验证 DVPP 是否工作# 检查 DVPP 占用率npu-smi info-tdvpp如果 DVPP 占用率是 0%说明预处理没走 NPU而是在 CPU 上做的性能会差很多。5. AIPPAI 预处理AIPP 是 DVPP 的补充负责图像归一化Mean/Std 归一化。格式转换RGB → BGR、YUV → RGB。融合到算子AIPP 的配置可以融合到算子执行计划里不单独跑。⚠️踩坑预警AIPP 和 DVPP 都能做图像预处理但 AIPP 更轻量不占 DVPP 硬件单元。如果你的模型只需要做归一化用 AIPP 就够了别浪费 DVPP 资源。踩坑实录runtime 使用中的常见错误踩坑 1内存泄漏——忘了释放 NPU 内存# 错误写法会泄漏data_ptr,_acl.rt.malloc(size,acl.rt.MemType.MEM_TYPE_NORMAL)# ... 用完没释放 ...# 正确写法data_ptr,_acl.rt.malloc(size,acl.rt.MemType.MEM_TYPE_NORMAL)try:# ... 使用 data_ptr ...passfinally:acl.rt.free(data_ptr)# 确保释放踩坑 2设备上下文没设置——算子执行失败# 错误写法没设置设备上下文acl.init()# ... 直接调算子 ... # 会报设备未初始化错误# 正确写法acl.init()acl.rt.set_device(0)# 先设置设备上下文# ... 调算子 ...acl.rt.reset_device(0)acl.finalize()踩坑 3Host→Device 数据搬运没同步——数据没搬完就开始算# 错误写法没同步acl.rt.memcpy(dev_ptr,host_data,size,acl.rt.MemcpyKind.MEMCPY_HOST_TO_DEVICE)# ... 立刻调算子 ... # 数据可能还没搬完# 正确写法加同步acl.rt.memcpy(dev_ptr,host_data,size,acl.rt.MemcpyKind.MEMCPY_HOST_TO_DEVICE)acl.rt.synchronize()# 等数据搬运完成# ... 再调算子 ...验证环节runtime 是否正常工作1. 检查 NPU 设备状态# 查看 NPU 设备列表npu-smi info# 查看运行时日志cat/var/log/npu/log/runtime.log|tail-50如果 runtime 初始化成功日志里会有 “Runtime initialized successfully”。2. 跑一个最简单的算子验证 runtime 调度你可以参考cann-samples仓库中的示例代码。importaclimportnumpyasnp# 初始化acl.init()acl.rt.set_device(0)# 申请内存size1024host_datanp.random.randn(size).astype(np.float32)dev_ptr,_acl.rt.malloc(size*4,acl.rt.MemType.MEM_TYPE_NORMAL)# 数据搬运Host → Deviceacl.rt.memcpy(dev_ptr,host_data.tobytes(),size*4,acl.rt.MemcpyKind.MEMCPY_HOST_TO_DEVICE)acl.rt.synchronize()# ... 这里调你的算子 ...# 数据搬运Device → Hostoutput_hostnp.zeros(size,dtypenp.float32)acl.rt.memcpy(output_host.tobytes(),dev_ptr,size*4,acl.rt.MemcpyKind.MEMCPY_DEVICE_TO_HOST)acl.rt.synchronize()# 释放acl.rt.free(dev_ptr)acl.rt.reset_device(0)acl.finalize()如果这个流程能跑通说明 runtime 基本正常工作。3. 性能验证runtime 调度是否跑满 NPU# 跑模型时实时监控 NPU 利用率npu-smi info-taicore-i0-c0如果 AI Core 利用率长期低于 60%说明 runtime 调度有问题任务分配不均、数据搬运没重叠。这时候得去查算子是不是没切分好大算子占满一个 AI Core其他 AI Core 闲着。数据搬运是不是同步的没用异步搬运计算和数据搬运串行。实践要点读 runtime 源码从acl.rt接口看起理解内存管理/任务调度的实现。跑 CANN 的 runtime 示例cann-samples仓库里有现成的调用代码。用 npu-smi 监控 runtime 状态学会看 AI Core 利用率、内存占用、通信带宽。排查 FlashAttention 性能问题如果 FlashAttention 跑不满 NPU先查 runtime 调度再查算子实现。参考仓库cann-samples运行时调用示例https://atomgit.com/cann/cann-samplesdriver运行时下层对接的驱动https://atomgit.com/cann/driver
runtime 运行时：昇腾NPU的“操作系统内核”
发布时间：2026/5/22 8:59:43
runtime 运行时昇腾NPU的“操作系统内核”刚接触 CANN 那会我以为 runtime 就是个“运行时库”调几个 API 就完事。后来帮一个朋友排查 FlashAttention 算子执行慢的问题发现 runtime 才是真正的“幕后黑手”——算子再快runtime 调度不当NPU 算力也跑不满。昇腾NPU 上跑模型runtime 是绕不开的基础设施。CANN 把 runtime 放在第五层架构的“执行层”负责把编译好的算子真正扔到 NPU 硬件上跑。这次把 runtime 的架构拆清楚以后排查性能问题就不会再迷路。环境准备理解 runtime 在 CANN 中的位置在开始拆解 runtime 架构之前先得搞清楚它跟其他组件的关系。runtime 的定位CANN 五层架构中的第4层昇腾计算执行层它位于图编译器之下驱动之上。上层对接Graph Compiler图编译器、BiSheng/ATC编译器。下层对接Driver驱动、NPU 硬件达芬奇架构。依赖关系你的 PyTorch 模型 ↓ (框架适配层) Graph Compiler图编译 ↓ (编译成执行计划) runtime运行时 ↓ (调用底层接口) driver驱动 ↓ (真正干活) 昇腾NPU 达芬奇架构硬件FlashAttention 的执行链路ops-transformer的 FlashAttention 算子→\rightarrow→调用 Ascend C 编程接口→\rightarrow→runtime 把算子调度到 AI Core→\rightarrow→在 NPU 上执行矩阵分块计算。如果 runtime 调度不当比如任务分配不均、数据搬运没重叠FlashAttention 的延迟就会上去。逐步推进runtime 的核心模块拆解runtime 不是单一模块而是一组协同工作的子系统。结合CANN 8.0当前时间 2026 年 5 月的主流版本的特性核心模块有 5 个1. Runtime 运行时核心调度器这是 runtime 的“大脑”负责设备管理检测 NPU 设备、分配设备上下文。任务调度把算子任务分配给多个 AI Core 并行执行。内存管理管理 NPU 上的 GM全局内存、L1、L0。关键 APIAscendCL 接口importacl# 初始化运行时acl.init()# 申请 NPU 设备device_id0acl.rt.set_device(device_id)# 分配内存GM 上data_size1024*1024# 1MBdata_ptr,_acl.rt.malloc(data_size,acl.rt.MemType.MEM_TYPE_NORMAL)# 释放设备acl.rt.reset_device(device_id)acl.finalize()⚠️踩坑预警acl.rt.malloc申请的是 NPU 的 GM 内存不是主机内存。如果你把主机指针传给 NPU 算子会报“非法内存访问”错误。正确做法是先用acl.rt.malloc申请 NPU 内存再用acl.rt.memcpy把数据从主机拷到 NPU。2. Graph Executor图执行器如果你的模型是用 CANN 的图开发接口构建的比如用了 GE 图引擎Graph Executor 负责图解析把编译好的图.om 文件解析成执行计划。节点调度按拓扑顺序执行图中的算子节点。数据流转管理算子之间的中间数据不写回主机直接在 NPU 上传递。FlashAttention 如果跑在图模式下Graph Executor 会把 Q、K、V 的算子融合成一个子图减少数据搬运次数。验证 Graph Executor 是否工作# 检查图执行日志cat/var/log/npu/log/runtime.log|grepGraphExecutor如果看到 “GraphExecutor: Load graph success”说明图加载成功。3. HCCL集合通信库如果你做的是分布式训练/推理比如 Megatron 昇腾NPUHCCL 负责集合通信AllReduce、AllGather、ReduceScatter 等。多卡协同多个 NPU 之间的数据同步。FlashAttention 在分布式场景下需要 HCCL 做Ring Attention把序列维度切分到多个 NPU 上并行算。⚠️踩坑预警HCCL 的初始化很慢第一次要建通信组。如果你在测试用例里频繁初始化/销毁 HCCL性能会很差。正确做法是进程启动时初始化一次整个生命周期复用。4. DVPP数字视觉预处理如果你的模型输入是图像/视频DVPP 负责图像解码JPEG/PNG 解码成 YUV/RGB。预处理Resize、Crop、Color Space Conversion。零拷贝预处理完直接扔给 NPU 算子不写回主机。FlashAttention 本身不调 DVPP但如果你的模型是 Vision TransformerViT输入图像就得先过 DVPP 做预处理。验证 DVPP 是否工作# 检查 DVPP 占用率npu-smi info-tdvpp如果 DVPP 占用率是 0%说明预处理没走 NPU而是在 CPU 上做的性能会差很多。5. AIPPAI 预处理AIPP 是 DVPP 的补充负责图像归一化Mean/Std 归一化。格式转换RGB → BGR、YUV → RGB。融合到算子AIPP 的配置可以融合到算子执行计划里不单独跑。⚠️踩坑预警AIPP 和 DVPP 都能做图像预处理但 AIPP 更轻量不占 DVPP 硬件单元。如果你的模型只需要做归一化用 AIPP 就够了别浪费 DVPP 资源。踩坑实录runtime 使用中的常见错误踩坑 1内存泄漏——忘了释放 NPU 内存# 错误写法会泄漏data_ptr,_acl.rt.malloc(size,acl.rt.MemType.MEM_TYPE_NORMAL)# ... 用完没释放 ...# 正确写法data_ptr,_acl.rt.malloc(size,acl.rt.MemType.MEM_TYPE_NORMAL)try:# ... 使用 data_ptr ...passfinally:acl.rt.free(data_ptr)# 确保释放踩坑 2设备上下文没设置——算子执行失败# 错误写法没设置设备上下文acl.init()# ... 直接调算子 ... # 会报设备未初始化错误# 正确写法acl.init()acl.rt.set_device(0)# 先设置设备上下文# ... 调算子 ...acl.rt.reset_device(0)acl.finalize()踩坑 3Host→Device 数据搬运没同步——数据没搬完就开始算# 错误写法没同步acl.rt.memcpy(dev_ptr,host_data,size,acl.rt.MemcpyKind.MEMCPY_HOST_TO_DEVICE)# ... 立刻调算子 ... # 数据可能还没搬完# 正确写法加同步acl.rt.memcpy(dev_ptr,host_data,size,acl.rt.MemcpyKind.MEMCPY_HOST_TO_DEVICE)acl.rt.synchronize()# 等数据搬运完成# ... 再调算子 ...验证环节runtime 是否正常工作1. 检查 NPU 设备状态# 查看 NPU 设备列表npu-smi info# 查看运行时日志cat/var/log/npu/log/runtime.log|tail-50如果 runtime 初始化成功日志里会有 “Runtime initialized successfully”。2. 跑一个最简单的算子验证 runtime 调度你可以参考cann-samples仓库中的示例代码。importaclimportnumpyasnp# 初始化acl.init()acl.rt.set_device(0)# 申请内存size1024host_datanp.random.randn(size).astype(np.float32)dev_ptr,_acl.rt.malloc(size*4,acl.rt.MemType.MEM_TYPE_NORMAL)# 数据搬运Host → Deviceacl.rt.memcpy(dev_ptr,host_data.tobytes(),size*4,acl.rt.MemcpyKind.MEMCPY_HOST_TO_DEVICE)acl.rt.synchronize()# ... 这里调你的算子 ...# 数据搬运Device → Hostoutput_hostnp.zeros(size,dtypenp.float32)acl.rt.memcpy(output_host.tobytes(),dev_ptr,size*4,acl.rt.MemcpyKind.MEMCPY_DEVICE_TO_HOST)acl.rt.synchronize()# 释放acl.rt.free(dev_ptr)acl.rt.reset_device(0)acl.finalize()如果这个流程能跑通说明 runtime 基本正常工作。3. 性能验证runtime 调度是否跑满 NPU# 跑模型时实时监控 NPU 利用率npu-smi info-taicore-i0-c0如果 AI Core 利用率长期低于 60%说明 runtime 调度有问题任务分配不均、数据搬运没重叠。这时候得去查算子是不是没切分好大算子占满一个 AI Core其他 AI Core 闲着。数据搬运是不是同步的没用异步搬运计算和数据搬运串行。实践要点读 runtime 源码从acl.rt接口看起理解内存管理/任务调度的实现。跑 CANN 的 runtime 示例cann-samples仓库里有现成的调用代码。用 npu-smi 监控 runtime 状态学会看 AI Core 利用率、内存占用、通信带宽。排查 FlashAttention 性能问题如果 FlashAttention 跑不满 NPU先查 runtime 调度再查算子实现。参考仓库cann-samples运行时调用示例https://atomgit.com/cann/cann-samplesdriver运行时下层对接的驱动https://atomgit.com/cann/driver
