CANN Runtime 仓库是整个异构计算栈的核心控制面。它不仅仅是一个 API 封装层，更是一个复杂的系统软件，负责管理 NPU 硬件资源的生命周期、仲裁并发的执行流，并提供对底层驱动的高效、无缝的抽象。Runtime 的性能和健壮性直接决定了上层推理服务和训练框架的稳定性和最终吞吐量。

核心资源链接：

• CANN 组织主页： https://atomgit.com/cann
• Runtime 仓库： https://atomgit.com/cann/runtime

一、 模型生命周期管理：上下文创建、资源绑定与卸载的原子性保证

模型加载到 Runtime 不仅仅是文件的读取，而是建立一套复杂的设备端资源依赖关系。

1.1 执行上下文（Execution Context）的精细化构建

上下文是 Runtime 隔离不同模型实例或任务集的核心容器。

• 资源封装的深度： 一个 Context 实例封装了该模型实例所需的所有关键设备资源，包括：专用的 HBM 内存区域句柄池、系统级的 Stream 集合、异步同步对象（Events/Semaphores）的命名空间，以及对特定版本 ops-nn 库的引用计数。
• 图实例化（Graph Instantiation）： 加载的离线模型（OM 文件）被解析，所有静态权重和常量数据指针被绑定到该 Context 的显存空间。Runtime 确保权重访问路径的正确性，防止跨模型实例的地址冲突。

1.2 动态链接与算子库的生命周期管理

为了支持热更新或模块化部署，Runtime 必须具备对外部算子库的动态加载能力。

1. SO 文件的符号解析： 算子包（.so 文件）通过 dlopen 机制加载。Runtime 负责在加载时，通过符号查找机制（Symbol Resolution），验证所需算子的入口点（Entry Points）是否与当前 Runtime 版本兼容。
2. 原子化卸载流程： 卸载模型是一个关键的原子操作。它要求 Runtime 必须阻塞所有新的任务提交，等待所有正在执行的计算流（Streams）到达一个同步屏障（通常是等待所有正在运行的 Kernel 完成）。只有确认所有资源句柄（包括显存、流、事件）都解除引用后，才能安全地释放 HBM 内存并执行 dlclose，防止悬垂指针（Dangling Pointers）。

二、 高并发任务调度：Stream 模型与上下文驻留优化

在推理服务场景下，Runtime 必须高效地处理来自多线程、多进程的并发请求，目标是最小化上下文切换（Context Switching）的开销。

2.1 任务提交与 Stream 模型的并发粒度控制

Stream 是 Runtime 调度模型的核心，它决定了任务执行的相对顺序。

• 流的优先级分配： Runtime 内部调度器对不同 Context 关联的 Stream 赋予不同的优先级权重。低延迟（如实时推理）的流被赋予高优先级，确保它们能快速抢占执行资源。
• 核函数（Kernel）的异步分发： Runtime 将上层 GE 拆解的任务提交到对应的硬件 Command Queue。这种提交是异步的，Host 线程在提交后立即返回，CPU 资源不被阻塞，等待硬件异步完成。

2.2 批处理（Batching）对上下文驻留的优化

通过将多个小请求合并为一个大任务，可以有效摊销软件开销。

1. 请求合并策略： Runtime 调度器监控传入请求的到达时间。如果短时间内有多个请求到达，并且它们使用相同的模型 Context，调度器会将它们聚合到一个逻辑批次中。
2. Tiling 粒度的优化： 批处理允许 Runtime 将 Tiling 粒度扩展到批次维度。这意味着一次 Kernel 启动可以处理 $B$ 个独立的输入（Batch Size），从而将初始化上下文、同步屏障等待等固定开销分摊到 $B$ 个请求上，显著降低了每个请求的平均延迟。

三、 显存管理的精细化仲裁与碎片化抵抗

显存（HBM）管理是 Runtime 中最接近硬件、最复杂的模块之一，它直接影响内存的有效利用率。

3.1 内存池的动态分级与回收机制

Runtime 摒弃了操作系统的通用分配器，采用了定制化的池化方案。

• 多级内存池的构建： 内存池被划分为多个层级，对应不同的对象大小（如极小对象、小张量、大权重）。这确保了小请求不会因为需要分割大内存块而产生内部碎片。
• 伙伴系统的高效合并（Coalescing）： 释放内存时，Runtime 检查相邻的空闲块是否可以合并成更大的空闲块。这个合并操作必须是线程安全的，并且执行效率必须足够高，以避免释放操作本身成为瓶颈。

3.2 地址对齐的硬件依赖与 Runtime 强制校验

所有显存分配都必须满足硬件访存器的要求。

• DMA 传输要求： 硬件搬运单元（MTE）的 DMA 传输是以固定长度（如 32 字节）进行的。Runtime 在分配内存时，必须通过地址调整确保所有分配的起点都与该粒度对齐。
• API 层的对齐保证： 当应用调用显存申请 API 时，Runtime 不仅返回一个指针，它也隐性保证了该指针满足所有后续算子所需的对齐要求，即便底层内存池的起始地址不完全对齐。

四、 维测组件（Measurement）的集成与数据闭环

Runtime 深度集成了性能测量和故障诊断的能力，这为 OAM 提供了关键的运行时反馈。

4.1 性能计数器（PMC）的硬件级读取接口

Runtime 提供了标准化接口来读取 NPU 内部的硬件性能寄存器。

1. 事件驱动的采样： 性能计数器通常不会被持续轮询，而是配置为在特定事件（如 Kernel 启动、完成或发生特定硬件状态）时触发一次采样的快照。
2. 指标的语义化： 从 PMC 读取的原始计数值（如 Cycle Count）会被 Runtime 转换成可理解的指标，例如：Cube Unit 的指令发射率、L1 缓存的未命中次数，或HBM 访问的平均延迟。

4.2 错误处理与上下文隔离

当执行流中出现非致命错误时（如输入数据超出预设范围），Runtime 扮演了容错仲裁者的角色。

• 批次级别的错误隔离： 如果错误发生在批量推理任务中的某一个样本上，Runtime 会记录该样本的错误上下文（包括执行到的算子 ID 和输入张量的句柄），并快速回滚并释放该单个样本的资源，确保其他样本的处理不受影响。
• 驱动错误上报机制： 对于驱动或固件层面的致命错误，Runtime 立即停止所有计算流，并触发全系统内存和寄存器状态的转储，将完整现场信息通过日志系统上报。

五、 运行时协同：与图引擎（GE）和驱动层的协同交互

Runtime 的有效性取决于其对上层编译计划的解释能力以及对下层驱动的有效控制力。

5.1 图执行计划的动态实例化

GE 输出的离线模型（OM）是静态的，Runtime 必须在运行时将其动态化。

• Task 描述符的解析与调度： Runtime 解析 OM 文件中的 Task 列表，将这些任务的逻辑 ID 转化为实际的硬件指令（如加载特定版本的 ops-nn 核函数）。
• 动态形状的处理机制： 当模型定义了动态维度时，Runtime 在接收到实际输入尺寸后，会动态调用 Tiling 算法（可能由 ops-cv 或 Catlass 库提供），重新计算所有中间缓冲区的大小和 MTE 搬运描述符，并更新执行计划。

5.2 驱动层同步原语的封装与加速

Runtime 对驱动层提供的原子操作进行了优化封装。

1. 同步屏障的最小化： 驱动层通常提供粗粒度的同步机制。Runtime 通过 Stream 机制，将多个串行算子打包，以减少对昂贵的全屏障同步的调用频率。
2. 内存一致性请求的加速： 对于需要 Host 端确认的内存写操作，Runtime 优先使用硬件支持的 Cache Invalidate/Flush 指令，而非通过软件轮询或系统调用来确认内存写入的可见性。

六、 总结

CANN Runtime 不仅是执行环境，更是系统性能和稳定性的基石。其深度体现在对显存的定制化池化管理、基于 Event 的高效异步调度、对硬件对齐的严格遵守，以及对性能和错误的全面可观测性。Runtime 成功地将复杂的硬件资源管理和并发控制抽象化，为上层应用提供了高性能、隔离性强的计算基础。