runtime 仓库体现的组件是 CANN 软件栈的“执行大脑”，它负责接收由图引擎（GE）编译生成的静态执行蓝图，并将其转化为高效、安全、并发的物理计算流。其核心职能不仅限于任务调度，更在于对异构资源的抽象、内存的精细化管理，以及对执行过程的全链路可观测性的保障。

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

---

1. 执行环境的构建与资源抽象的层次化设计

Runtime 的启动流程是对底层异构计算资源的初始化和抽象，为上层计算提供一致的接口。

1.1 资源句柄管理与隔离机制

• 会话（Session）的生命周期：Runtime 建立以 Session 为中心的管理模型。一个会话代表一个独立的计算上下文，封装了设备句柄、全局内存池的引用，以及用于线程安全和并发控制的同步对象。
• 异构资源抽象：它将物理计算单元（如 AI Core 集群、AICPU、MTE 引擎）抽象为逻辑执行流（Stream）。开发者或编译器通过 Stream ID 来指示任务的执行优先级和并发级别，而 Runtime 负责底层的资源分配和仲裁。

1.2 显存池的静态分配与动态复用策略

高性能推理严重依赖于对设备显存的精确控制，以应对 LLM 庞大的中间结果。

• 预分配与碎片化治理：Runtime 不依赖运行时频繁的显存申请，而是在模型初始化阶段，根据 GE 提供的内存拓扑信息，一次性申请大块连续的物理内存，并将其切分为逻辑内存池。
• 张量生命周期驱动的复用：Runtime 维护了每个临时张量的有效存活区间。只有当一个张量的生命周期结束（即所有依赖它的后续计算均已完成）后，其占用的地址空间才会被回收并标记为可供复用。

2. 异步调度引擎：Stream、Event 与依赖模型的精细化控制

Runtime 的核心调度机制是基于异步执行模型的，旨在最大化硬件的并行性。

2.1 Stream 队列的有序性与并发发射

• 序列化保障：在单个 Stream 内部，Runtime 严格保证任务的顺序执行，以维持计算图的拓扑结构。
• 跨流并发调度：调度引擎持续监控所有 Stream 的就绪状态。当多个 Stream 任务可以并行执行时，Runtime 会将它们同时提交给硬件任务调度器（Task Scheduler），实现算子级别的并行化。

2.2 Event 机制：Device-Side 同步的核心

Event 机制是实现低延迟依赖管理的关键，它将同步控制从 Host CPU 转移到了硬件侧。

• 同步令牌机制：Event 充当了硬件级的令牌。当一个计算流 A 完成其任务后，它会记录一个 Event 状态；另一个依赖于 A 的流 B 则启动一个 Event Wait 操作。
• 最小化 Host 干预：这种基于硬件事件的同步机制避免了 Host CPU 频繁轮询等待，显著降低了异构任务间的同步延迟，这对 LLM 连续解码的低延迟需求至关重要。

3. 维测（Profiling & Diagnosis）组件的底层集成

Runtime 仓库集成了深度观测组件，为性能分析和系统调试提供了最原始、最精确的数据基础。

3.1 底层硬件性能计数器（PMU）的读写

• 事件的原子采集：Runtime 在启动和完成每个算子核函数时，强制执行硬件级时间戳的记录。这些时间戳被精确关联到算子 ID、Stream ID 和执行的核心上。
• 微架构指标收集：维测组件能够直接读取 AI Core 内部的性能计数器，如 Cube Unit 的 MAC 完成次数、Cache 命中率、以及 MTE 的有效传输量，为性能瓶颈的精确定位提供了量化依据。

3.2 故障恢复与上下文快照机制

• 异常捕获与隔离：当硬件执行单元报告错误时，Runtime 会立即捕获硬件中断，并暂停所有相关的计算流，以避免错误扩散。
• 诊断信息快照：Runtime 会自动触发一个上下文转储流程。这个转储不仅包含失败的 PC（程序计数器）和寄存器状态，还会关联导致失败的算子 ID、其 MetaDef 属性，以及输入输出张量的内存地址，极大地简化了复杂模型部署中的调试工作。

4. 算子加载、参数注入与动态形状适应

Runtime 负责将 GE 编译的静态指令转化为在特定输入下可执行的实例。

4.1 算子符号查找与 MetaDef 契约校验

• 注册表索引：Runtime 使用图中的算子 ID（包含版本信息）在内部注册表中查找对应的执行入口。
• 契约校验：在实例化前，Runtime 校验当前输入张量的形状和数据类型是否与注册的算子实现（如 ops-nn 的特定版本）所声明的 MetaDef 契约相匹配。

4.2 动态形状输入的运行时适配

• Shape 驱动的执行路径：对于支持动态形状的算子，Runtime 会检查实际输入的维度。如果匹配到一个预编译的优化档位（Bucket），则直接使用该档位的优化参数；如果不匹配，则可能激活一个更通用的、性能稍低的执行路径。

5. 算子库热插拔与服务级别高可用性

Runtime 架构设计支持在服务运行时动态更新算子实现，这对于持续优化部署模型至关重要。

5.1 动态库加载与原子替换

• 动态链接（dlopen）：支持加载自定义算子（Ascend C/PyPTO 编译的 Op Package）作为动态库。
• 原子版本切换：Runtime 允许原子性地替换一个已注册算子的执行入口。这要求系统能够区分正在执行的旧版本任务和新到达的请求。只有当所有旧任务完成后，新的执行句柄才能被接管新的请求，确保了服务不停机时的平滑升级。

6. 总结

CANN Runtime 构成了异构计算的执行闭环。它通过 Stream/Event 机制实现高效的异步并发调度，通过静态内存池技术和生命周期分析实现显存的极致复用，并通过深度集成的维测组件提供了前所未有的系统可观测性。理解 Runtime 的工作原理，是确保 LLM 等复杂模型能够在异构硬件上稳定、高性能运行的根本。

---

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