1. 为什么要在昇腾上做训练性能分析1.1 从一次真实的性能困惑说起前阵子帮一个团队看他们基于昇腾NPU的训练任务现象很典型模型能跑通loss也在降但每个step的耗时比预期高了将近一倍。团队第一反应是“算力不够”准备加卡。我拦了一下让他们先别急着堆硬件因为在昇腾上做训练性能问题十有八九不是算力不够而是没吃透数据采集和算子执行的真实情况。这个判断不是拍脑袋。昇腾NPU和GPU在编程模型上有本质差异GPU生态里大家习惯了nvidia-smi看利用率、nsys抓时间线而昇腾对应的工具链是另一套体系——torch_npu提供的profiler接口、CANN底层的AiCMetrics、以及最终落地的kernel_details.csv。很多从GPU迁移过来的同学第一反应是找“昇腾版的nvidia-smi”结果发现工具名字、采集方式、数据格式全变了于是干脆放弃分析靠调batch size和换优化器硬扛。这篇文章要解决的就是这条链路怎么用torch_npu的profiler把训练过程的数据采下来怎么读懂kernel_details里的每一列怎么从这些数据里定位到真正的性能瓶颈。适合两类人一是刚把训练脚本迁到昇腾、发现性能不对劲的算法工程师二是需要给团队做性能调优、但苦于没有系统方法的工程同学。不需要你懂CANN底层但需要你能跑通一个训练脚本并且愿意花时间看数据。1.2 昇腾性能分析工具链的全景在动手之前先把工具链的层次理清楚不然很容易在“该用哪个工具”上绕圈。昇腾的性能分析大致分三层。最底层是CANN提供的AiCMetrics和底层采集能力它负责从硬件和驱动层拿到算子执行时间、内存占用、AI Core利用率这些原始数据。中间层是框架适配层也就是torch_npu里的profiler模块它把PyTorch的训练过程前向、反向、优化器更新和底层采集打通让你能用类似PyTorch原生torch.profiler的写法来采集昇腾数据。最上层是数据解析和可视化采集出来的是原始数据目录需要解析成kernel_details.csv、operator_details.csv这类结构化文件再配合msprof或MindStudio Insight做可视化。这里有个关键认知torch_npu.profiler不是独立工具它是PyTorch profiler在昇腾后端的实现。所以你写采集代码时API风格和torch.profiler几乎一致但导出的数据格式是昇腾特有的。理解了这一点你就不会去纠结“为什么没有昇腾版的nsys”因为采集入口本来就在框架层。提示如果你的环境里出现npu is selected as device, but torch_npu is not available这类报错说明torch_npu没装好或者版本和PyTorch不匹配。这是采集前的第一道坎后面会专门讲排查方法。2. 采集前的环境准备与版本对齐2.1 torch_npu与PyTorch的版本匹配逻辑昇腾上做性能分析第一步不是写采集代码而是确认版本。torch_npu是PyTorch的昇腾适配插件它对PyTorch主版本、CANN版本、Python版本都有严格要求。我见过太多人卡在“代码写对了但采集报错”最后发现是torch_npu和PyTorch版本差了一个小版本。版本匹配的核心逻辑是torch_npu的每个release都对应一个特定的PyTorch版本和CANN版本。比如某个torch_npu版本可能要求PyTorch 2.1.0加CANN 8.0你装了PyTorch 2.2就会出问题。这不是兼容性做得差而是因为profiler要hook PyTorch的调度器版本差异会导致hook点对不上。实操上我建议用官方提供的镜像或者conda环境别自己手动pip install一堆包。如果必须手动装先查清楚三件事当前PyTorch版本、当前CANN版本、目标torch_npu版本。可以用下面这段代码快速确认环境import torch import torch_npu print(PyTorch version:, torch.__version__) print(torch_npu version:, torch_npu.__version__) print(NPU available:, torch.npu.is_available()) print(NPU device count:, torch.npu.device_count()) print(Current device:, torch.npu.current_device())如果torch.npu.is_available()返回False或者报npu is selected as device, but torch_npu is not available那采集根本无从谈起。这个报错的常见原因有三个一是torch_npu没装二是装了但和PyTorch版本不匹配三是环境变量没配好比如ASCEND_HOME_PATH没设置。排查顺序就是先看包在不在再看版本对不对最后看环境变量。2.2 采集前的环境变量与权限检查版本对了之后还有几个容易被忽略的准备工作。第一是环境变量。昇腾的采集依赖CANN的一些运行时配置比如ASCEND_HOME_PATH要指向CANN安装目录LD_LIBRARY_PATH要包含CANN的lib。这些通常在安装CANN时已经配好但如果你用的是容器环境可能需要手动source一下set_env.sh。第二是权限。profiler采集底层数据时可能需要访问一些设备节点或者性能计数器。如果是在容器里跑要确认容器有足够的权限否则采集会静默失败——注意是静默失败不报错但数据是空的这个坑很隐蔽。第三是磁盘空间。profiler采集的数据量比想象中大尤其是开了AiCMetrics之后一个几百step的训练可能产生几百MB甚至上GB的数据。采集前先确认输出目录所在磁盘有足够空间不然采到一半磁盘满了数据不完整还得重来。注意采集目录不要放在网络文件系统上比如NFS挂载的盘。profiler写数据是高频小文件写入网络盘会拖慢采集甚至导致数据丢失。用本地SSD最稳。3. torch_npu profiler采集实战3.1 采集代码的最小可用模板先给一个能直接跑的最小模板然后再逐项解释每个参数。这个模板我用了很多次覆盖了大部分训练场景import torch import torch_npu # 准备模型和数据这里用最简单的示例 model torch.nn.Linear(1024, 1024).npu() optimizer torch.optim.SGD(model.parameters(), lr0.01) input_data torch.randn(64, 1024).npu() # 定义采集配置 experimental_config torch_npu.profiler._ExperimentalConfig( aic_metricstorch_npu.profiler.AiCMetrics.PipeUtilization, profiler_leveltorch_npu.profiler.ProfilerLevel.Level1, l2_cacheFalse, data_simplificationFalse ) # 启动profiler with torch_npu.profiler.profile( activities[ torch_npu.profiler.ProfilerActivity.CPU, torch_npu.profiler.ProfilerActivity.NPU ], scheduletorch_npu.profiler.schedule( wait1, warmup1, active3, repeat1 ), on_trace_readytorch_npu.profiler.tensorboard_trace_handler(./prof_result), experimental_configexperimental_config ) as prof: for step in range(10): optimizer.zero_grad() output model(input_data) loss output.sum() loss.backward() optimizer.step() prof.step()这段代码跑完会在./prof_result目录下生成采集数据。核心是schedule参数和experimental_config下面分别讲。3.2 schedule参数为什么不能全程采集schedule(wait1, warmup1, active3, repeat1)这四个参数决定了采集的节奏理解它们能帮你避免“采了一堆无用数据”的问题。wait是启动后先等几个step不采集。为什么要等因为第一个step通常包含算子编译、内存分配这些一次性开销采进来会污染数据。warmup是预热step会跑但不记录让硬件进入稳定状态。active是真正采集的step数一般3到5个就够因为稳定状态下每个step的行为高度相似采太多只是重复。repeat是重复几轮一般设1。我见过有人把active设成100觉得数据越多越好结果采集文件巨大解析要半小时而且里面99%是重复信息。性能分析要的是稳定状态下的代表性数据不是全量数据。3到5个active step足够看出问题。3.3 AiCMetrics采集哪些硬件指标experimental_config里的aic_metrics决定了采集哪些AI Core指标这是昇腾profiler区别于普通PyTorch profiler的关键。常用的几个值指标含义适用场景PipeUtilization各流水线利用率判断计算单元是否打满ArithmeticUtilization算术单元利用率分析计算密集型算子Memory内存带宽相关排查访存瓶颈MemoryL0L0缓存相关细粒度缓存分析profiler_level控制采集粒度Level1是算子级Level2会更细但开销更大。日常调优用Level1就够除非你要分析单个算子的内部流水线。这里有个经验aic_metrics不是采得越多越好。每多采一个指标采集开销就增加可能反过来影响训练性能导致采到的数据失真。我一般先只开PipeUtilization定位到某类算子有问题后再针对性地开更细的指标重采。3.4 采集过程中的性能开销控制profiler本身有开销这是无法完全避免的。但可以通过几个手段把开销压到可接受范围。第一是缩短采集窗口前面说的active3就是这个思路。第二是关闭不必要的activity如果只关心NPU算子可以只留ProfilerActivity.NPU去掉CPU采集。第三是用data_simplificationTrue它会简化数据减少文件大小和解析时间代价是丢失一些细节。实测下来在稳定状态下开启Level1采集对单step耗时的影响大概在5%到15%之间。如果你的训练本身step耗时很短比如几十毫秒采集开销占比会更明显这时候更要控制采集窗口。4. kernel_details解读从数据到瓶颈定位4.1 kernel_details.csv的字段含义采集完成后解析出来的kernel_details.csv是性能分析的核心文件。它的每一行是一个算子在NPU上的执行记录关键列包括Name算子名称比如MatMul、Conv2D、LayerNorm。这是定位问题的第一入口。Duration(us)算子执行耗时单位微秒。这是最直观的性能指标。Start Time(us)/End Time(us)算子的起止时间用来分析算子之间的串并行关系。Accelerator Core执行该算子的核心类型比如AI Core、AI CPU。AI Core是主力AI CPU通常处理不适合并行的逻辑。Wait Time(us)算子等待执行的时间。这个值高说明算子被阻塞了可能是依赖没就绪或者资源竞争。看这个文件第一步是按Duration排序找出耗时最长的Top算子。通常前10个算子会占据总耗时的60%以上这就是优化的重点。4.2 用耗时占比定位热点算子光看绝对耗时不够要看占比。假设一个step总耗时100ms某个MatMul占了40ms那它就是绝对热点。但如果总耗时是500ms这个MatMul占40ms占比只有8%那可能不是首要问题。我习惯先算一个总耗时然后对每个算子算Duration / Total。占比超过10%的算子要重点看超过20%的基本就是瓶颈。这里要注意总耗时不是简单把所有算子Duration加起来因为算子之间可能有并行。更准确的做法是看时间线上的实际跨度或者用profiler给出的step总耗时。定位到热点算子后要问三个问题这个算子该不该这么慢它的理论耗时是多少它慢是因为计算量大还是因为访存、调度、或者精度问题4.3 结合AiCMetrics判断计算还是访存瓶颈这是昇腾性能分析的精髓所在。同样一个MatMul慢可能是计算单元打满了计算瓶颈也可能是数据喂不上访存瓶颈还可能是流水线没排好调度问题。AiCMetrics就是用来区分这些情况的。如果PipeUtilization显示某个流水线利用率接近100%说明计算单元在满负荷工作这时候优化方向是减少计算量或者换更高效的算子实现。如果利用率很低但耗时很长说明算子在等数据优化方向是改善数据布局或者提高缓存命中率。举个实际例子我曾经遇到一个LayerNorm算子耗时异常。看PipeUtilization发现向量流水线利用率只有30%但耗时很长。进一步看Memory指标发现访存带宽接近饱和。结论是这个LayerNorm的输入数据布局不友好导致频繁的跨步访存。把输入改成连续内存后耗时降了一半。提示kernel_details里的Wait Time如果很高往往说明算子之间有依赖等待。这时候要回到时间线看是不是某个前置算子太慢拖累了后续算子。4.4 时间线视角算子串并行与气泡分析单看kernel_details的汇总数据会丢失时间维度的信息。真正的问题往往藏在时间线里——比如两个本该并行的算子被串行执行了或者算子之间有大段空闲气泡。分析时间线的方法是把Start Time和End Time画成甘特图用MindStudio Insight或者自己写脚本看算子的排列。如果发现大量算子首尾相接、没有重叠说明并行度不够。如果发现算子之间有明显空隙说明有等待或者调度开销。昇腾上的气泡常见来源有三个一是算子下发延迟CPU侧下发算子的速度跟不上NPU执行速度二是依赖等待后一个算子要等前一个算子的结果三是同步点比如loss计算、梯度allreduce这些需要跨设备同步的操作。5. 常见问题与排查技巧实录5.1 采集报错与数据为空的排查问题一npu is selected as device, but torch_npu is not available这个报错前面提过排查顺序是确认torch_npu已安装、确认版本匹配、确认环境变量正确。可以用pip list | grep torch看装了哪些相关包用python -c import torch_npu看能否导入。问题二采集目录生成了但里面是空的最常见的原因是采集窗口没对上。schedule的wait warmup active要小于等于你的训练step数。如果你只跑5个step但wait1, warmup1, active3那实际采集的只有第3到第5个step勉强够。如果step数更少就采不到数据。另一个原因是权限问题前面说过容器环境里采集底层数据可能需要额外权限。问题三解析kernel_details.csv时报错通常是采集数据不完整导致的。检查采集目录里是否有profiler_info.json和原始数据文件如果只有部分文件说明采集被中断了。重新采集时确保磁盘空间充足、训练正常结束。5.2 数据解读中的典型误判误判一把第一个step的耗时当成稳定性能第一个step包含算子编译、内存池初始化这些一次性开销耗时往往是稳定状态的几倍。分析时一定要用warmup之后的step数据。误判二只看算子耗时不看等待时间一个算子耗时短但如果它前面等了很久整体性能还是差。要把Duration和Wait Time结合起来看。误判三忽略AI CPU算子AI Core是主力但有些算子会落到AI CPU上执行比如一些控制流、动态shape处理。AI CPU的算力远低于AI Core如果热点算子里有AI CPU算子那基本就是瓶颈。在kernel_details里看Accelerator Core列就能识别。5.3 采集开销过大导致的数据失真如果发现采集时训练明显变慢采到的数据可能已经失真。这时候要降低采集粒度把profiler_level降到Level1只开必要的aic_metrics缩短active窗口。宁可少采一点也要保证数据反映真实性能。还有一个技巧先不采集跑一遍记录正常step耗时作为基线再采集跑一遍对比。如果两者差异超过20%说明采集开销太大数据参考价值有限。5.4 常见问题速查表现象可能原因排查方向采集目录为空采集窗口未覆盖、权限不足检查schedule参数、容器权限算子耗时异常高计算瓶颈、访存瓶颈、精度问题结合AiCMetrics看流水线利用率大量AI CPU算子动态shape、控制流检查模型是否有动态逻辑算子间气泡多下发延迟、依赖等待看时间线分析串并行采集后训练变慢采集开销过大降低采集粒度、缩短窗口6. 从数据到优化的闭环6.1 定位瓶颈后的优化方向选择拿到kernel_details和AiCMetrics数据后优化方向大致分四类。计算优化如果热点算子是计算密集型且流水线打满考虑换更高效的算子实现、降低计算精度比如从FP32降到FP16但要注意昇腾310P3这类设备的精度支持情况、或者用算子融合减少计算量。访存优化如果流水线利用率低但访存带宽高考虑改善数据布局、提高缓存命中率、减少不必要的数据搬运。并行优化如果时间线显示并行度不够考虑调整算子执行顺序、增加流水线并行、或者优化通信和计算的overlap。调度优化如果气泡多、下发延迟高考虑减少CPU侧逻辑、用图模式减少下发次数、或者调整batch size让NPU更饱和。6.2 优化效果的验证方法优化之后一定要重新采集对比优化前后的kernel_details。重点看三个指标热点算子的耗时是否下降、总step耗时是否下降、AiCMetrics的利用率是否更合理。这里要注意优化可能引入新的瓶颈。比如你把计算优化了结果访存成了新瓶颈。所以每次优化后都要重新做完整的性能分析而不是只看单个指标。6.3 把性能分析变成日常习惯最后说个心态问题。很多团队把性能分析当成“出问题了才做的事”其实应该反过来——在训练脚本稳定后就定期采集一次性能数据建立性能基线。这样一旦性能退化能快速定位是哪个改动引入的。我自己的习惯是每次模型结构或者训练配置有较大改动就跑一次profiler把kernel_details的Top算子存下来。时间长了你会对“这个模型在这个硬件上应该是什么性能”有直觉出了问题一眼就能看出异常。昇腾的性能分析工具链还在快速迭代torch_npu的profiler接口和kernel_details的字段可能会有变化。但核心方法论是不变的采集稳定状态的数据、区分计算和访存瓶颈、结合时间线看并行度、用数据验证优化效果。把这套方法跑通换什么硬件、换什么模型你都能快速上手。