CANN 组织链接 ： https://atomgit.com/cann
Runtime 仓库链接 ： https://gitcode.com/cann/runtime
1. 计算上下文（Context）的定义与必要性
Runtime 需要维护一个计算上下文对象，用于管理特定执行会话的所有资源和状态，包括内存句柄、流（Stream）以及算子缓存。
1.1 上下文的生命周期
计算上下文通常在图加载或会话初始化时创建，并在推理/训练任务完成后销毁。
- 静态上下文：对于静态图（如 MindSpore 编译的图），上下文在图加载时被初始化，包含了所有权重和 ops-nn 算子的引用。
- 动态上下文：对于动态图（如 PyTorch eager 模式），上下文可能需要更频繁地创建和销毁，或者维持一个常驻状态以缓存动态形状信息和 Tiling 数据。
1.2 上下文切换的性能成本
上下文的切换（Context Switching）是 Runtime 的开销之一。当服务需要从处理一个模型实例切换到处理另一个模型实例时，或者当一个线程从一个计算流切换到另一个计算流时，都会发生上下文切换。
- 开销来源：上下文切换需要保存和恢复 NPU 核心的状态（寄存器、控制寄存器），并可能涉及 Local Memory 数据的刷新或保留。
- 优化目标 ：Runtime 致力于最小化上下文切换的频率和耗时，通常通过批量处理 （Batching）或流管理来实现，以最大化单个上下文内的执行效率。
2. 流（Stream）管理与异步并发控制
Runtime 使用执行流（Streams）来管理并发任务，这是实现高性能计算的关键抽象。
2.1 计算流与通信流的解耦
为了实现计算与通信的重叠，Runtime 将任务划分到不同的流中：
- 计算流：负责调度 ops-nn 或自定义核函数在 AI Core 上的执行。
- 通信流：负责提交 HCCL/SHMEM 任务，并在硬件 DMA 引擎上异步执行数据传输。
Runtime 保证这两个流之间的同步是通过精确的硬件同步点（Fence）实现的，避免了 CPU 级别的忙等待。
2.2 资源绑定与上下文隔离
在多租户或多线程推理场景中，Runtime 必须隔离不同线程对 NPU 资源的竞争。
- 上下文绑定：每个执行线程或异步任务被绑定到一个特定的 Runtime Context 或 NPU Core 组。这确保了不同任务的 Local Memory 不会相互干扰，即使是使用共享内存的 SHMEM 机制，其访问也需通过上下文句柄进行仲裁和安全检查。
3. 总结
Runtime 的上下文管理机制是实现高性能、高并发推理服务的基础。通过精心设计的上下文生命周期、流的解耦以及对内存资源的严格隔离，Runtime 确保了上层图的执行计划能够高效、安全地转化为 NPU 的并行操作，从而最小化延迟并最大化吞吐量。
CANN 组织链接 ： https://atomgit.com/cann
Runtime 仓库链接 ： https://gitcode.com/cann/runtime