CANN 组织链接 ： https://atomgit.com/cann
Runtime 仓库链接 ： https://gitcode.com/cann/runtime
1. 推理阶段的内存需求特性
推理服务（Inference Service）与训练服务在内存需求上有显著差异：推理通常是高并发、低延迟的，且中间结果的生命周期较短。
1.1 临时张量（Intermediate Tensors）的生命周期
推理执行过程中的大部分中间张量（如 Conv/MatMul 后的结果）仅在当前算子执行期间需要。
- GE 优化后的生命周期 ：由于 GE 已经通过生命周期分析消除了大部分冗余的 HBM 内存预留，Runtime 只需要管理那些在图被多次调用时需要复用的临时空间。
1.2 批处理 (Batching) 对内存的挑战
在批处理模式下，Runtime 需要同时为当前批次内的所有样本分配输入和输出空间。
- 峰值占用控制：如果 Batch Size 很大，即使单个样本内存占用不大，也可能导致 HBM 峰值占用过高。Runtime 必须根据配置的并发请求数来动态调整内存池的规模，或限制最大可接受的 Batch Size。
2. 内存池化与复用策略的精细化控制
Runtime 的内存管理器通过细粒度的池化策略来优化内存的分配和回收。
2.1 内存池的分级管理
Runtime 不仅管理 NPU 设备内存，还可能管理 Host 内存用于数据预处理。
- 分层池化：设备内存池可能进一步细分为：权重存储池（静态）、激活/中间结果存储池（动态，可复用）、通信缓冲区池（SHMEM/HCOMM 专用）。
- 复用粒度 ：Runtime 追踪每一个已释放内存块的实际大小 和对齐要求。当新的算子请求内存时，管理器会尝试找到一个满足大小和对齐要求的已释放块，而不是简单地分配一块新的内存。
2.2 临时内存的自动回收机制
对于不涉及梯度计算的推理任务，内存回收应尽可能快。
- 引用计数 (Ref Count)：虽然 SHMEM 和其他通信机制可能涉及更复杂的引用计数，但对于纯计算产生的中间结果，Runtime 在算子执行完成后，若确认该内存块无其他流依赖，会立即将其引用计数清零并回收至内存池。
3. 内存与调度流的同步耦合
内存分配和释放操作必须与执行流的同步点严格对齐。
- 分配等待：如果内存池在某一时刻无法满足请求（例如，所有 HBM 空间正在被通信流占用），Runtime 必须阻塞或暂停提交新任务到计算流，直到通信流释放出足够的 HBM 空间。
- 异步释放：最优情况下，内存释放操作应被延迟到下一个计算批次开始之前，以实现释放操作与新计算的重叠。
CANN 组织链接 ： https://atomgit.com/cann
Runtime 仓库链接 ： https://gitcode.com/cann/runtime