前言CANN的各个组件中,Runtime可能是最容易被忽略但最关键的一个,尤其在昇腾NPU上它的角色更为核心。ops-nn提供了算子、GE做了图优化、HCCL管理了通信——但这些组件最终都要通过Runtime来执行。Runtime是CANN中直接跟NPU驱动打交道的组件——它负责NPU设备的初始化、执行流的创建和管理、显存的分配和释放、以及算子在NPU上的实际调度。不理解Runtime就没法真正理解CANN。CANN Runtime的核心设计理念是轻量和显式。GPU的CUDA Runtime中有很多隐式行为——上下文自动切换、默认流、隐式同步。CANN Runtime的设计更偏向显式——每个操作都要求明确指定上下文和设备,流的管理是显式的,资源生命周期由调用方控制。这种设计让Runtime层的性能更可预测——没有隐式的同步开销,没有自动上下文切换的延迟,但代价是使用方需要管理更多细节。显式设计对边缘部署的重要性大——边缘环境资源紧张CPU算力也有限,隐式行为导致的额外开销在边缘环境中会被放大。CANN Runtime的显式设计让开发者能够精确控制每个NPU指令的执行时机和资源用量。# Runtime的基本操作设备管理和上下文 import torch_npu # 设备管理 npu_device_count torch_npu.npu.device_count() print(f可用NPU数量: {npu_device_count}) # 设置当前设备 torch_npu.npu.set_device(0) # 获取当前设备的信息 device_name torch_npu.npu.get_device_name(0) total_memory torch_npu.npu.get_device_properties(0).total_memory print(f设备: {device_name}, 显存: {total_memory / 1024**3:.1f}GB) # 创建tensor隐式使用Runtime显存管理 tensor torch.randn(4096, 4096, devicenpu)在昇腾服务器中,多个NPU共享系统电源和散热资源。隐式设备管理可能在开发者不注意时使用了一个空闲的NPU——系统功耗突然增加,散热跟不上导致NPU降频。显式设备管理明确要求开发者指定使用哪个NPU,避免了意外的资源竞争。另一个原因是NPU之间的HCCS拓扑跟PCIe拓扑不同——不同的NPU对之间有不同的通信延迟,同一个NPU上的计算任务也有不同的执行效率。显式指定设备让开发者可以主动做负载均衡。Runtime的执行流机制执行流Stream是CANN Runtime的核心调度单元。一个执行流维护了一个有序的指令队列——提交到同一个执行流中的指令按顺序执行;不同执行流之间的指令可以乱序执行。通过多个执行流,Runtime可以实现指令级的并行——当一个执行流在等数据拷贝,另一个执行流可以执行计算指令。# 执行流的创建和使用 import torch_npu # 创建多个执行流 stream1 torch_npu.npu.Stream() stream2 torch_npu.npu.Stream() stream3 torch_npu.npu.Stream() # 在默认流上执行的计算 tensor_a torch.randn(4096, 4096, devicenpu) tensor_b torch.randn(4096, 4096, devicenpu) # 在stream1上执行数据拷贝 with torch_npu.npu.stream(stream1): tensor_c tensor_a.clone() # 这个拷贝操作在stream1上执行 # 在stream2上执行矩阵乘法 with torch_npu.npu.stream(stream2): tensor_d torch.matmul(tensor_a, tensor_b) # 矩阵乘法在stream2上执行 # 在stream3上执行逐元素操作 with torch_npu.npu.stream(stream3): tensor_e torch.relu(tensor_b) # ReLU在stream3上执行 # stream1/2/3的计算可以并行执行 # stream1的数据拷贝 stream2的矩阵乘法 stream3的ReLU # 三个操作可以在NPU上同时进行在昇腾NPU上,Cube单元和Vector单元是独立的计算单元——矩阵乘法用Cube单元,逐元素运算用Vector单元。如果你把所有的计算操作都提交到同一个执行流中,Cube单元和Vector单元不能同时工作——按指令在流中的顺序一个执行完另一个才能开始。通过将不同类型操作分配到不同的流中,Cube单元可以在一个流上做矩阵乘法,Vector单元在另一个流上做激活函数——NPU的计算单元同时工作。多个执行流的调度对HBM带宽的利用率也有影响——一个流的DMA操作可以利用另一个流的计算时间的间隙,不会让HBM带宽空闲。在典型的大模型推理场景中,使用多个执行流可以让NPU的计算单元利用率从单流的40%左右提升到75%以上。执行流的同步模式不同执行流之间的同步通过事件Event来实现。当一个流中的计算完成时触发事件,等待这个事件的流在事件触发后继续执行。Runtime的事件机制是异步的——事件触发时CPU不需要等待,只有通过event.synchronize()主动等待时CPU才会阻塞。# 执行流之间的同步 import torch_npu # 创建两个执行流 compute_stream torch_npu.npu.Stream() transfer_stream torch_npu.npu.Stream() # 创建事件 compute_done torch_npu.npu.Event() transfer_done torch_npu.npu.Event() # 计算流执行推理计算 with torch_npu.npu.stream(compute_stream): output model(input_tensor) compute_done.record() # 计算完成后记录事件 # 数据传输流准备下一批数据 with torch_npu.npu.stream(transfer_stream): next_batch torch.randn(4096, 4096, devicenpu) transfer_done.record() # 主同步点等待计算和数据传输都完成 compute_done.synchronize() transfer_done.synchronize() # 两个流都完成后,可以安全地读取output和next_batch result output.cpu().numpy()如果compute_stream上的model推理需要两次同步——一次跟transfer_stream的传输同步,一次跟CPU的等待——这两次同步都会阻塞执行流。Runtime的异步同步模型允许CPU在等待NPU计算响应的同时做其他工作——比如数据预处理或者接收网络请求。只有当CPU真正需要NPU计算的结果时才调用event.synchronize()。在推理服务中,这个设计让CPU可以在NPU推理的同时处理下一个请求的输入数据——NPU计算和CPU预处理可以完全重叠。显存管理策略显存管理是Runtime中性能影响最大的环节之一。不合理的显存管理会导致显存碎片化、分配延迟高、以及OOM错误。CANN Runtime提供两种显存分配模式直接分配和缓存分配。直接分配每次向NPU驱动申请显存,分配速度慢但无碎片。缓存分配预先申请一大块显存,由内部的显存管理模块负责小块分配,速度快但需要管理内部碎片。# 显存管理配置 import torch_npu # 方式1:直接分配默认行为 tensor1 torch.randn(4096, 4096, devicenpu) # 方式2:缓存分配减少分配延迟 torch_npu.npu.set_memory_fraction(0.8) # 预留80%显存作为缓存池 tensor2 torch.randn(4096, 4096, devicenpu) # 用完后释放 del tensor2 torch_npu.npu.empty_cache() # 释放缓存池中的空闲块 # 方式3:预分配大型连续显存 large_buffer torch_npu.npu.caching_allocator_alloc(2 * 1024**3) # 2GB print(f预分配成功: {large_buffer.shape if hasattr(large_buffer, shape) else 2GB})直接分配适用于大型连续显存申请——比如模型权重加载。这种场景下显存申请一般只在初始化时发生一次,分配速度慢不是问题。缓存分配适用于小型频繁显存申请——比如推理请求的临时tensor。这种场景下分配速度直接影响推理延迟。混合使用两种策略通常最优——模型权重用直接分配,推理时的临时tensor用缓存分配。缓存的分配池大小需要根据模型规模和并发数来调整——太小会导致缓存碎片化,太大会占用太多显存影响模型加载。Runtime的Profiling工具CANN Runtime提供了Profiling工具来分析NPU上指令的执行情况。通过Profiling数据,开发者可以看到每个算子在NPU上的实际执行时间、显存带宽利用率、以及计算单元利用率。这些数据对于优化NPU程序的性能至关重要。GPU开发经验中的NVIDIA Nsight对应到CANN中的Ascend Device Monitor——前者提供详细的kernel执行时间、显存带宽、SM利用率、以及GPU执行的速度。后者提供类似的NPU信息——算子执行时间、显存带宽利用率、Cube和Vector单元利用率、以及NPU的执行效率。两个工具在Profiling能力上类似,但NPU更强调Cube和Vector单元利用率的独立统计,而GPU侧重SM和Tensor Core的混用情况。# 启用Runtime的Profiling import torch_npu import os # 通过环境变量启用Profiling os.environ[ASCEND_PROFILING] 1 os.environ[PROFILING_MODE] task_trace # task_trace或者op_trace # 或者通过Profiling API进行调用级别控制 profiler torch_npu.profiler.profile( activities[ torch_npu.profiler.ProfilerActivity.NPU, # NPU活动 torch_npu.profiler.ProfilerActivity.CPU, # CPU活动 ], scheduletorch_npu.profiler.schedule( wait5, # 前5步不记录 warmup2, # 预热2步 active10, # 记录10步 ), on_trace_readytorch_npu.profiler.tensorboard_trace_handler( ./profiling_logs ) ) # 在训练循环中使用Profiling for step, data in enumerate(train_loader): profiler.start() output model(data) loss loss_fn(output, target) loss.backward() optimizer.step() profiler.stop()task_trace模式记录每个算子的执行时间但不记录内部细节——开销小适合长时间Profiling。op_trace模式记录算子的内部细节——每个指令的执行流水线状态、显存访问模式等——开销大但定位问题更精准。开发阶段使用op_trace模式定位算子瓶颈,发现具体是哪条指令导致Cube单元利用率低也不是Vector单元未充分利用。部署前的性能验证阶段切换到task_trace模式,低开销验证整体性能。Profiling的开销在两种模式中不同——task_trace大约使计算时间增加5%到10%,op_trace增加15%到30%。在部署环境中只建议使用task_trace模式。Runtime中的算子调度模型CANN Runtime的调度模型基于任务队列和硬件调度器。算子提交到Runtime时先被封装为一个task——task包含了算子的kernel函数指针、输入输出数据的显存地址、以及算子的配置参数。这些task被放入执行流对应的任务队列中。NPU的硬件任务调度器从队列中取出task,根据task的类型分发给对应的硬件单元——Cube单元的task送到Cube单元、Vector单元的task送到Vector单元、DMA操作的task送到DMA引擎。硬件调度器的调度策略是贪心的——优先执行可以立即开始的task,如果有等待数据的task就跳过它执行下一个独立task。这种调度策略对算子执行顺序有影响——提交到同一个流中的task理论上应该按顺序执行,但硬件调度器可能在数据依赖条件不变的前提下调整task的执行顺序。比如task A写到显存地址0x1000,task B从地址0x2000读取——两者没有数据依赖关系。硬件调度器可以自由决定先执行A还是B。这种重排优化对指令吞吐有益但不应该依赖固定的执行顺序。需要严格顺序的场景——比如task C写入地址0x1000后task D读取相同地址——必须在task之间插入同步屏障或使用关联的显存依赖标记来阻止重排。Runtime还支持算子级别的异步回调。算子在NPU上执行完成后触发回调函数——回调在CPU上执行,不阻塞NPU的执行流。异步回调适合处理算子执行后的非关键操作——更新Profiling计数器、记录日志、或者触发下一个算子的加载。在推理服务中,异步回调可以在NPU解码当前token的同时在CPU上清理上一个请求的临时显存。Runtime的内存池管理Runtime的内存池Memory Pool是提升显存分配效率的核心机制。内存池在Runtime初始化时从NPU驱动申请一大块显存,之后所有算子申请的显存都在这个池中分配和回收。内存池内部维护一个空闲块列表——当算子请求显存时,池在列表中查找满足大小要求的空闲块。如果找到、标记为已用并返回给算子。如果找不到、从池尾扩展新的空闲块。内存池的空闲块合并策略决定了池的碎片化程度。当算子释放显存块时,池检查该块的前后相邻块是否是空闲状态、如果是就将它们合并为一个更大的空闲块。合并的频率决定了池的碎片程度——合并频率高碎片少但合并操作本身的CPU开销大。Runtime的默认策略是延迟合并——在释放操积累到一定阈值通常为池大小的10%后才执行一次批量合并。延迟合并减少了CPU上的开销但可能造成短时间内的显存碎片化。对于延迟敏感的场景——比如推理服务需要快速分配显存处理请求可以将合并策略调整为立即合并,牺牲少量CPU时间来换取稳定的分配延迟。Runtime版本升级的兼容性Runtime作为CANN生态中最底层的组件之一,版本升级的兼容性要求高。算子的接口规范改变时如果Runtime不兼容新的接口格式原有算子无法注册和执行。相同版本的Runtime在不同固件版本的NPU上运行也可能存在微小的行为差异——新版固件修复了旧版中某些算子的寄存器配置错误,旧版Runtime在新固件上调用这些算子时行为可能不一致。Runtime的版本兼容性检测在初始化时检查固件版本和Runtime版本的适配关系——兼容的组合允许继续初始化,不兼容的组合给出明确的版本升级建议。版本兼容矩阵在Runtime的发布说明中有明确标注——开发者升级前应该检查自己使用的算子和固件版本是否在兼容矩阵中。跨机通信的带宽无法达到理论值。Runtime的Profiling工具通过task_trace模式可以定位中转路径上的瓶颈。Runtime的用户态和内核态交互是另一个值得关注的细节。用户态的Runtime API调用通过ioctl系统调用进入NPU驱动。每次ioctl的开销在微秒级别——对于单个算子调用的延迟来说不可忽略。Runtime通过批量提交的方式减少ioctl次数——将多个算子的执行指令打包在一个ioctl请求中发送给驱动。批量提交的粒度由执行流的配置决定——在创建执行流时可以设置batch大小。对于包含串行短算子的执行流增加batch大小可以减少ioctl次数提升执行效率。batch大小过大会使驱动在处理批量请求时延迟增加,推荐batch大小在8到16之间。使用前后效率对比Runtime的优化在不同使用方式下的性能差异场景使用前单流/默认分配使用后多流缓存分配差异来源多算子执行单流串行执行,Cube和Vector交替工作,利用率约40%多流并行,Cube和Vector单元独立工作,利用率提升到75%以上执行流分离让不同类型的计算单元可以并行工作频繁显存分配直接分配每次约50微秒,碎片化随分配次数增多缓存分配一次预分配,后续分配约1微秒,无碎片化分配策略的差异在频繁分配场景中累计起来影响明显CPU-NPU同步CPU等待NPU结果,CPU空转时间浪费CPU在NPU计算时预处理下一批数据,CPU利用率提升异步事件机制让CPU不等待,NPU和CPU并行工作Profiling调试黑盒分析,定位问题靠经验猜测Profiling数据定位具体瓶颈算子或指令Profiling数据展示了每个算子的执行时间和利用率Runtime层的优化不需要改变算子的实现——不需要改Ascend C代码,不需要改GE的图优化策略。Runtime层的优化只需要改变计算任务的组织方式——使用多少个执行流,每个流上放什么类型的计算,显存怎么分配和回收。这些调整的难度不高但效果明显。如果你的NPU训练或推理中发现计算单元利用率低——Cube利用率低于50%或者Vector利用率低于40%——多流分离是第一个应该尝试的优化方向。仓库地址https://atomgit.com/cann/runtime