1. Runtime 在 CANN 异构计算架构中的核心定义

在异构计算软件栈中，运行时（Runtime）组件处于承上启下的关键位置。它向下衔接驱动程序（Driver），直接操作昇腾 AI 处理器的底层资源；向上承接图引擎（GE）生成的执行计划，将逻辑上的计算图转化为物理硬件上的任务序列。runtime 仓库提供的组件负责管理算子的加载、内存的动态分配、任务的分发调度以及系统级的维度观测与性能测量。

Runtime 的存在确保了应用层在不需要介入硬件细节的情况下，能够以异步、高效的方式调用 NPU 算力。其设计目标是在高并发任务环境下，通过优化调度策略和减少软件开销，最大化 NPU 硬件的占空比。

2. 任务调度机制：Stream、Event 与异步执行模型

CANN Runtime 采用基于 Stream 和 Event 的异步编程模型，这是实现异构并行计算的核心。

2.1 Stream 的逻辑编排与硬件流映射

Stream（流）是 Runtime 管理任务执行的基本单位。

• 指令队列化： 开发者将一系列算子执行任务或数据搬运任务下发到一个 Stream 中。Runtime 保证在同一个 Stream 内部，任务按照下发的先后顺序严格执行。
• 多流并行（Concurrent Streams）： 系统支持创建多个独立的 Stream。Runtime 调度器负责将这些逻辑流映射到 NPU 内部的物理执行流。不同 Stream 之间的任务可以实现硬件级的并行执行，从而有效掩盖单算子启动的延迟，提升系统的整体吞吐量。

2.2 Event 同步原语与任务依赖管理

在复杂的计算任务中，不同流之间往往存在依赖关系。Runtime 通过 Event 组件实现了跨流同步。

• 信号量机制： Event 充当了硬件级的信号量。当 Stream A 的某个任务完成后，会触发一个 Event 的标记操作。Stream B 则通过等待该 Event 信号来启动其后续任务。
• 流水线气泡消除： Runtime 内部的任务调度引擎会实时监控 Event 的状态。一旦依赖满足，任务立即进入执行队列，这种基于硬件信号的闭环反馈机制减少了 Host 侧 CPU 参与轮询的开销。

3. 异构存储管理策略：地址空间、显存池与零拷贝

高效的显存管理是高性能 AI 计算的前提。Runtime 组件实现了对高带宽内存（HBM）的精细化调度。

3.1 虚拟地址空间与内存对齐

Runtime 负责维护一个与 Host 侧隔离的设备侧虚拟地址空间。

• 内存申请（aclrtMalloc）： 当应用请求显存时，Runtime 会在物理显存池中分配连续的空间。
• 对齐约束： 为了匹配 NPU 搬运单元（MTE）的 32 字节或 64 字节访存位宽，Runtime 在分配内存时会自动执行地址对齐。这种设计确保了数据在参与计算或进行 DMA 传输时，能够获得最高效的总线吞吐能力。

3.2 显存池化管理与碎片治理

频繁的显存申请和释放会产生严重的系统调用开销和内存碎片。

• 预分配机制： Runtime 内部集成了一个内存池管理器。在模型初始化阶段，它会根据图引擎提供的静态规划，预先申请大块连续显存。
• 生命周期监测： Runtime 实时追踪每个内存块的生命周期。当某个中间张量不再被后续算子使用时，其占用的地址空间被标记为可用，由 Runtime 立即重新分配给后续任务，实现了存储资源的高效流转。

4. 维测功能组件（Maintenance & Measurement）的体系架构

为了保障系统在复杂生产环境下的可维护性，runtime 仓库集成了完备的维测功能组件。这些组件负责采集 NPU 执行过程中的各类动态指标。

4.1 性能分析（Profiling）的数据采集路径

Profiling 组件通过侵入式或非侵入式的方式记录任务执行的时间戳。

• 算子级耗时统计： Runtime 捕获每个算子下发（Launch）到完成（Finish）的精确时刻。这些数据被收集并聚合，生成算子执行的时间线。
• 硬件计数器（Hardware Counters）： 维测组件能够读取芯片内部的硬件寄存器，获取 Cube 单元利用率、Vector 单元占用率以及总线带宽利用率等量化指标。这为性能调优提供了最直接的物理证据。

4.2 异常诊断与故障定位（Debugging & Logging）

当任务执行失败时，维测组件负责保留“第一现场”。

• 错误码透传： Runtime 将底层的硬件异常（如 AI Core Error）转换为标准化的错误码，并通过日志系统输出。
• Dump 机制： 组件支持将故障时刻的内存数据、算子输入输出以及硬件寄存器状态转储至磁盘。结合故障处理工具，开发者可以还原故障发生时的逻辑状态，实现算子逻辑错误或显存溢出问题的快速定位。

5. Runtime 与上层图引擎及底层驱动的协同逻辑

Runtime 的执行逻辑并非孤立存在，它必须与 CANN 软件栈的其他层级高度协同。

5.1 图编译产物的解析与执行

图引擎（GE）生成的离线模型（OM）包含了一系列的 Task 描述符。

• 任务下沉（Task Sinking）： Runtime 读取这些描述符，将其加载到内存中，并根据图中定义的依赖关系，配置硬件的任务调度器。
• 静态与动态的平衡： 对于静态形状模型，Runtime 直接执行预定义的任务序列；对于动态形状模型，Runtime 会在运行时调用 Tiling 逻辑，重新配置算子的执行参数。

5.2 驱动层接口的标准化封装

Runtime 屏蔽了驱动层（Driver）复杂的内核态调用。

• IOCTL 封装： Runtime 将用户态的算子执行请求封装为驱动可识别的 IO 控制指令。
• 多进程/多线程安全： 组件内部实现了完善的资源加锁和隔离机制，确保在多应用并发访问同一张 NPU 卡时，内存空间和计算任务互不干扰。

6. 环境部署与集成验证

利用 runtime 组件进行开发和运行，需要确保环境的完备性。

6.1 运行时环境变量的配置

开发者必须通过 set_env.sh 脚本正确配置 LD_LIBRARY_PATH。Runtime 的核心动态库（如 libascendcl.so）必须处于系统搜寻路径中，否则应用将无法初始化 NPU 资源。

6.2 硬件健康状态的实时反馈

通过维测组件，Runtime 可以与 npu-smi 等运维工具交互。

• 实时遥测： 上报芯片温度、功耗和内存健康状态。
• 过热保护： 当驱动层检测到温度异常时，Runtime 会配合触发降频或任务挂起，防止硬件损坏。

7. 总结

CANN Runtime 运行时组件与维测功能组件共同构成了异构计算系统的“执行大脑”与“监控系统”。它通过 Stream/Event 机制解决了任务的有序异步调度问题，通过精细的内存规划解决了存储效率问题，并通过 Profiling 和 Dump 机制解决了异构系统的黑盒调试问题。深入理解 Runtime 的底层运作逻辑，是实现深度学习模型极致性能优化和保障生产环境稳定性的核心前提。

---

CANN 组织链接： https://atomgit.com/cann
runtime 仓库链接： https://gitcode.com/cann/runtime