昇腾NPU性能分析实战：JupyterLab下Profiling与调优

在昇腾NPU上调模型，跑通只是第一步，真正花时间的往往是“跑得慢”这件事。当训练loss正常下降、推理也没有报错，但一看算力利用率只有三四十，或者单步耗时忽高忽低，你就知道该上性能分析工具了。这篇文章我来讲讲在JupyterLab环境下，用mindstudio_insight这套昇腾性能分析工具做Profiling的完整思路和实操方法。它不是一份照搬文档的翻译稿，而是把我自己在排查性能瓶颈时总结下来的习惯、步骤和容易踩的坑一起放进来，希望能给正在折腾昇腾环境的朋友一些实实在在的参考。

如果你已经在用昇腾设备做训练或推理，并且遇到以下任一情况：NPU利用率上不去、Host侧数据加载卡顿、多卡通信拖慢整体step、某个算子在Device上耗时异常，那么这篇文章正好适合你。我会先从工具的整体定位讲起，再逐步带你走完环境准备、采集配置、结果解读和问题定位这几个环节，最后放一个我自己经常用的排查清单。对于刚接触性能分析的新手，我也会在关键地方补充一些基础概念，尽量让每个人都能跟着操作。

1. 内容整体设计与思路拆解

1.1 这个工具解决的是哪一类问题

在昇腾生态里，训练任务的性能瓶颈往往不是单一因素造成的，它可能是Host侧数据预处理太慢、AICPU算子执行阻塞、Device侧AI Core负载不均，也可能是多卡通信的同步开销太大。普通的日志和监控只能告诉你“某一项指标高不高”，但很难把时间的消耗精确到某个算子、某个通信原语、某一段数据流水线上。这就是mindstudio_insight这类Profiling工具的价值所在——它把一次训练迭代的完整时间线记录下来，你可以在时间轴上看到每一个算子的起止时间、每一块NPU内存的使用变化、每一次通信调用的耗时，甚至Host和Device之间的异步流水是否出现了空洞。

我在实际使用中最大的感受是：这个工具最能帮上忙的场景不是“程序报错”，而是“程序没报错但就是慢”。因为性能瓶颈通常藏在流水线空隙和设备空闲里，单靠经验猜往往猜不准。比如我遇到过一种典型的Host侧瓶颈，数据加载线程和计算线程之间存在明显的等待窗口，算子在Device上明明只跑了5毫秒，但整体step耗时却要15毫秒，剩下的10毫秒全卡在数据没送上来。如果没有Profiling数据，这种问题很可能要排查好几天。

1.2 JupyterLab版本的核心设计逻辑

选择在JupyterLab里集成性能分析能力，并不是把命令行工具简单套一层网页壳，它是从交互式开发的工作流出发重新设计的。传统做法是训练脚本里插入Profiling代码，跑完再导出文件，最后用本地GUI工具打开；一旦换了机器、换了环境，工作流就被打断了。反过来，JupyterLab场景下你和训练代码、输出图表就在同一个界面里，采集完数据马上就能通过可视化面板观察时间线和指标，不用来回切换工具。

另一个核心逻辑是“按需采集”。在JupyterLab里启动的训练任务通常不是一次跑完几万步，而是小步快跑、频繁调试，因此工具默认做了轻量化设计：你可以只采样几个step，也可以只开启算子级统计而不保存全量时间线，这样能大幅减少采集过程对真实训练性能的干扰。这也是我在实际使用中重点关注的选项——Profiling采样本身是有开销的，如果采集粒度太粗，看不到细节，粒度太细，又会拖慢训练本身，必须按场景需求来平衡。

1.3 方案的适用边界与选型理由

首先要明确一点，mindstudio_insight的JupyterLab插件主要面向的是“在容器或开发环境中交互式调优”的场景，适合单机调试、小规模多卡实验、以及模型迭代过程中的性能验证。它不适合直接在大型训练集群上做全量长期监控——那通常需要搭配集群监控平台使用。另外，如果你的训练任务是通过训练作业管理平台提交的，脚本跑在远端计算节点上，JupyterLab里不一定能直接关联到那个进程，这时更推荐用离线采集模式。

从工具链选型的角度看，Insight在JupyterLab的优势在于它和torch_npu的Profiler接口是打通的。也就是说，你既可以在Jupyter里导入torch_npu，用代码方式控制采集开关，也可以用插件自带的可视化界面发起任务。这种“编码式采集+可视化分析”的组合方式，比单纯的命令行工具更容易让人上手，也比单纯看Summary文件更能定位到深层次问题。我在后面的章节中会分别演示这两种方式。

2. 环境准备与快速启动

2.1 硬件与软件兼容矩阵

在动手之前，先确认你的环境满足基本条件，否则后面采集出来的数据可能不完整，甚至插件直接无法启动。一般来说，需要满足以下几项：

• 处理器侧：昇腾310P、910A、910B系列AI处理器的训练/推理环境，不同型号在算子支持上略有差异，但性能分析框架是通用的。
• 驱动与固件：CANN版本与驱动版本需要匹配，驱动与固件不一致时，EvenT采集会出现字段缺失。
• PyTorch Adapter：使用torch_npu时，需要保证torch_npu版本和PyTorch版本兼容，否则无法正常hook到NPU算子。
• JupyterLab环境：一般要求JupyterLab 3.x以上，插件以Lab Extension的方式安装。

一般情况下，CANN toolkit的安装目录下已经包含了Insight组件，你需要确认ms_insight相关的Python包能够被JupyterLab所在的Python环境导入。我强烈建议把JupyterLab跑在一个独立的虚拟环境里，然后通过pip安装配套的插件包，而不是直接使用系统自带的Jupyter，这样升级和隔离都方便。

2.2 安装的具体步骤

这里我以常见的Linux容器环境为例，整个安装过程可以拆成三步。

第一步，安装JupyterLab本体，以及ipykernel等基础内核组件：

# 如果已安装可跳过，建议在虚拟环境内操作 pip install jupyterlab ipykernel

第二步，安装mindstudio_insight插件及其依赖。不同CANN版本的包名可能不同，但常见的是mindstudio_insight和mindstudio_insight_jupyterlab两个包，前者是分析引擎本体，后者是JupyterLab前端插件：

pip install mindstudio_insight_jupyterlab # 如果分析引擎没有随插件自动安装，需要单独安装 pip install mindstudio_insight

第三步，启用插件并重启JupyterLab。这里要注意的是，改完插件后不是刷新浏览器页面就生效，需要重启JupyterLab服务进程：

jupyter labextension enable mindstudio_insight_jupyterlab # 或直接重启jupyter服务

提示：如果插件安装后页面没有出现“Ascend Insight”或类似入口，最常见的两个原因分别是：JupyterLab版本和插件要求不匹配，以及插件被安装到了另一个Python环境。先用pip show确认插件安装位置，再用jupyter labextension list查看是否存在。

2.3 验证基础环境

插件安装完成后，不要急着采集数据，先做一次快速验证。在Jupyter Notebook里运行下面一段小程序，确认能够正常调用NPU算子并完成Profiler采集：

import torch import torch_npu # 确认NPU可用 print("NPU count:", torch.npu.device_count()) print("NPU name:", torch.npu.get_device_name(0)) # 简单算子验证 a = torch.randn(1024, 1024).npu() b = torch.randn(1024, 1024).npu() c = torch.matmul(a, b) torch.npu.synchronize() print("matmul ok:", c.shape)

如果这段程序能正常打印设备信息和矩阵乘法结果，说明你的环境和torch_npu是通的。之后再尝试用torch.npu.profiler开启一次小规模采样，能产出Profiling目录，就说明Insight的分析组件已经就绪。

3. JupyterLab内采集与可视化实操

3.1 数据采集的几种方式

在JupyterLab里，采集性能数据主要有三种方式，我根据实际场景分别说明。

第一种是最轻量的方式，在代码中通过上下文管理器控制采集范围。这种方式适合调试某一个性能可疑的区间，不会把整个训练过程都记录进去：

import torch import torch_npu from torch_npu import profiler # 限定采集范围，避免生成过大的Profiling文件 with profiler.profile( activities=[ profiler.ProfilerActivity.CPU, profiler.ProfilerActivity.NPU, ], schedule=profiler.schedule( wait=0, warmup=1, active=2, repeat=1 ), on_trace_ready=profiler.tensorboard_trace_handler("./profiling_dir"), record_shapes=True, profile_memory=True, ) as prof: for step in range(10): train_one_step() prof.step()

第二种方式是在命令行下通过环境变量或启动参数开启采集，适合不想改动训练代码的场景，或者训练脚本是由第三方框架封装、不方便插入代码的情况。一般做法是设置Profiling采集的开关和环境变量后重新启动训练任务。

第三种方式就是直接用JupyterLab的Insight界面发起采集。你可以在界面上指定训练进程或指定工作目录，工具会自动注入采集参数并启动一个独立的Profiling任务。

从我的使用习惯来看，日常调优最常用的是第一种方式，因为它能精准控制采样的step区间。比如我只想分析训练前几个step或者某一个特定阶段的性能，就在那段代码外面包一层with profiler.profile(...)，完全不干扰其他阶段的训练流程。

3.2 采集参数如何选

很多人第一次用Profiling工具时喜欢把能开的开关全开，结果采集出来的数据文件动辄几个GB，分析半天也没找到关键问题。我根据自己的实践，建议你按照“先宏观再微观”的顺序配置参数。

如果只是想看整体性能概况，采集参数可以这样设置：profile_memory=False、record_shapes=False、activities只开NPU侧，schedule选择wait=0, warmup=1, active=2。这样采集到的是NPU算子级时间线和两级流水线概览，开销很小。

如果已经定位到某个具体算子或者通信环节异常，再开启record_shapes=True和profile_memory=True，这时候可以分析算子输入shape对耗时的影响，以及NPU内存是否存在大量碎片化分配。

参数选择方面有一个重要原则：采样step数不宜过多。我一般选择采集3到5个step，因为性能分析关注的是稳定的耗时分布和流水线行为，而不是某一次偶然抖动。采集过多step会增加解析时间，尤其在JupyterLab交互式场景里，等待时间太长会打断你的分析思路。

3.3 可视化面板怎么看

采集完成后，在Insight面板里会生成几个核心视图，我逐个说一下它们的作用和我自己的读法。

第一个是训练轨迹视图，也就是Training Trace。它展示的是Host侧和Device侧随时间的执行序列，你能看到每个step里的算子如何排列、Host下发指令和Device执行是否衔接紧密。我拿到这个视图后，第一个动作是找“空洞”——如果两个算子之间有一大段空白时间，说明流水线存在等待，要么是Host下发太慢，要么是同步等待事件阻塞了执行。

第二个是算子耗时统计视图。它会把所有算子的总耗时、平均耗时、执行次数列成表格，并且可以按Device侧或Host侧分别排序。这个视图适合快速找出“耗时大户”。不过这里有个陷阱：总耗时最大的算子不一定就是主要瓶颈，因为有些算子虽然单次耗时不长，但调用次数极多，累积起来占比很高，这个时候需要结合“占比”而不是“单次耗时”来判断。

第三个是通信视图。在多卡训练场景下，通信耗时往往占据一个step的三分之一甚至更多。这个视图会画出集合通信算子的时间线，比如AllReduce、AllGather等，你能看到通信是否与计算重叠，是否存在大量等待。我遇到过一种情况是梯度量化没开，导致通信数据量偏大，通信视图一眼就能看出Collective通信占据了每个step的尾部大块时间。

3.4 进阶：与torch_npu代码级联动

Insight JupyterLab插件还支持通过环境变量配置一些高级项，比如与TensorBoard的联动。你可以把on_trace_ready指向torch_npu.profiler.tensorboard_trace_handler，这样采集结果同时可以被TensorBoard插件加载，用自己熟悉的方式查看计算图视图和算子信息。

另外，如果你的训练循环里有自定义的标记点，比如数据加载完成、梯度更新完成之类的时点，可以用torch.profiler.record_function把自定义事件包起来：

from torch.profiler import record_function with record_function("data_load_and_transform"): batch = load_and_transform_data() with record_function("forward_backward"): loss = model(batch) loss.backward()

这样在你最终的时间线视图里就能看到“数据加载”和“前后向计算”各自占用的时间区间，很好用。我自己在排查数据加载瓶颈时全靠这个功能区分到底慢在Dataloader还是慢在模型计算。

4. 核心指标解读与调优实战

4.1 关键指标的作用与判定标准

Insight采集完成后，有几个核心指标需要优先关注，它们决定了后续调优的方向。

• NPU利用率（Device Utilization）：这是最直观的指标，但不是越高越好。对于单算子来说，高利用率意味着计算单元被充分利用；但对于整个训练step来说，NPU利用率不高也可能是Host侧喂数太慢导致的，需要结合时间线确认。
• AI Core平均利用率（AI Core Utilization）：反映NPU计算核心的忙闲程度。如果这个值长期低于60%，说明计算单元没有被充分填充，通常指向小算子过多、数据搬运开销大或并行度不足。
• HBM带宽利用率（Memory Bandwidth Utilization）：元素级算子（如激活、加偏置、LayerNorm）密集的任务，瓶颈往往是带宽而不是算力。当AI Core利用率不高但HBM带宽利用率很高时，说明任务属于访存密集型，优化方向不是减少算子，而是算子融合。
• Host侧CPU利用率与下发时延：Host侧如果出现单核打满或者指令下发间隙，说明数据预处理或Python调度机制拖了后腿。
• 通信时长占比（Communication Overhead）：多卡训练时，通信时长在step总耗时中的占比如果超过30%，就要考虑梯度压缩、梯度分桶、或者通信与计算重叠的策略。

这些指标不是割裂的，它们之间有关联。我的读法通常是：先看整体step耗时曲线是否平稳，再对照NPU利用率和通信占比，看是“算不动”“等数据”还是“等通信”。

4.2 定位瓶颈的逻辑链路

拿到一次完整的Profiling结果后，我一般按下面的逻辑链路来排查问题，而不是东看一个指标西看一个视图：

1. 先看整体step耗时分布，判断瓶颈在Host侧还是Device侧。如果Host侧下发时间线长时间空闲，而NPU端时间线紧凑，说明是Host侧的调度或数据问题；如果Host侧持续繁忙但Device侧仍有间隙，需要看是不是同步等待事件过多。
2. 再看算子耗时统计表，找出累计耗时排名前五的算子，观察它们的输入shape和所在模块。这里要看“执行次数”列——有些API调用次数很多但单次很小，累计起来也很可观。
3. 打开时间线视图，围绕排名靠前的算子，观察它们前后的算子排列，判断是否存在频繁的Device同步（例如频繁调用npu_synchronize或.item()）。
4. 结合内存视图，排查是否存在显著的NPU内存分配峰值。频繁的大块内存申请与释放不仅影响耗时，还可能引发OOM。
5. 最后回到训练代码，针对确认的瓶颈点做修改，再次采集对比。

这个链路的好处是层层收敛，每一步都用数据支撑下一步动作，而不是靠猜。我在带团队的时候，也推荐新人按这个顺序去看，避免被某一个突出指标带偏方向。

4.3 典型调优案例一：Host侧数据加载成为瓶颈

有一次我在JupyterLab里调试某个图像分类模型，单step耗时一直在22毫秒左右，但我从时间线上看到Device侧实际只忙了9毫秒，剩余时间全是空洞。打开Host进程时间线后，发现data_load_and_transform这个自定义事件占了8毫秒多，几乎和算子执行时间持平。

我当时的处理方法是：

• 在代码里把数据加载从同步加载改成异步预取，并增大num_workers，让数据在计算进行时提前准备好。
• 把图像解码和归一化操作从Python侧移到数据加载进程里，用torchvision的transforms在子进程中完成，而不是在主进程的collate_fn里做。
• 同时开启pin_memory，减少从CPU到NPU的拷贝开销。

改完后再采集，单step耗时降到了13毫秒，NPU利用率和时间线空洞明显改善。整个过程依靠的就是时间线视图里自定义标记和Device侧气泡图的对照，这是纯指标表格给不了的信息。

4.4 典型调优案例二：多卡通信耗时占比过高

另一个案例涉及到多卡训练，4卡环境下AllReduce耗时占每个step的40%，导致算力再高也跑不快。通信视图显示，通信调用方式是同步的，所有梯度规约都安排在反向传播结束之后，计算和通信完全没有重叠。

我的处理策略是：

• 开启梯度分桶通信，让梯度在反向传播过程中边算边通信，而不是全部算完再统一通信。
• 在优化器配置里开启通信重叠优化，把AllReduce和反向计算放到同一个流上交错执行。
• 对梯度做FP16压缩通信，在不影响收敛的前提下降低通信数据量。

调优后通信耗时从40%降到了18%，整体训练吞吐提升了接近一倍。这种问题单纯靠看算子耗时表是发现不了的，必须在通信视图里观察集合通信算子的时间分布和重叠情况。

4.5 典型调优案例三：小算子过多导致的AI Core利用率低下

还有一种很常见的情况：模型里大量使用逐元素操作和自定义Python算子，每个算子都很轻量，但调度开销巨大。Insight的算子统计里能看到大量耗时极短但调用次数突破几千次的算子，比如Add、Mul、Transpose。

处理思路是把这些算子合并或改写成融合算子，减少Device端调度次数。

• 如果是简单逐元素操作组合，使用PyTorch的torch.compile或者自定义融合内核进行算子融合。
• 如果是连续几个Shape变换，尽量合并成一次view或permute操作，避免中间产生额外内存拷贝。
• 如果自定义算子逻辑复杂，考虑用自定义算子内核一次完成多步计算。

这种优化往往能把AI Core利用率从50%左右提升到80%以上，整体训练时间也能有显著下降。它的依据直接在算子耗时统计和AI Core利用率两个视图的对比中体现。

5. 常见问题与排查技巧实录

5.1 常见报错与处理办法

在JupyterLab环境使用mindstudio_insight过程中，我遇到过不少问题，把它们整理成一个速查表，方便大家对照查找：

我在实际中遇到最多的是第一个和第三个问题。尤其是Profiling目录为空，通常不是因为工具坏了，而是采集的step区间里没有实际算子执行，比如wait阶段太长，或者训练代码在采样步骤里正好处于纯CPU阶段。

5.2 如何减小Profiling对训练的影响

Profiling本质上是在训练过程上“加装探针”，探针本身不可能是零开销的。对性能分析来说，我们追求的是“在可控干扰下反映真实性能”。有几点经验值得分享：

• 不要对每一步都做全量采集。使用schedule里的wait、warmup、active参数，先跳过任务启动阶段，等Warmup完成后再正式采样两到三个step。
• 关闭不必要的采集项。如果只关心算子耗时，profile_memory=False能显著减小内存分配记录开销。
• 大批量训练时，可以每间隔固定步数做一次采样，而不是集中采集连续step。
• 如果已经定位到问题，及时关闭采集开关，让训练跑回正常速度，避免长时间带着探针运行。

另外有一点值得注意，Device侧使用率指标和真实生产环境有一定的差异。在JupyterLab这种交互式环境里，可能存在其他任务共享NPU的情况，导致AI Core利用率看起来偏低。出现这种情况时，可以检查是否有其他进程占用NPU，用npu-smi info查看设备占用。

5.3 采集结果解析失败时的高效处理思路

偶尔会遇到采集完成后分析界面报错，比如“Cannot parse profiling event file”之类。我的排查思路是按由简到繁的顺序排查：

1. 确认Profiling目录完整，目录下的profiler_*.json和昇腾格式的tracing文件都存在。
2. 检查磁盘空间是否充足，尤其是容器挂载的持久化目录。
3. 尝试把采集模式从“异步Dump”调整为“同步采集”，排除文件写入时序问题。
4. 用命令行方式重新解析一次Profiling文件，看是否能正常导出Summary，排除前端插件问题。
5. 升级或回退CANN和插件版本，特别是一些旧版本对长任务采集支持不完善。

如果在JupyterLab里解析失败，但命令行工具可以正常解析，那基本可以确定是前端插件或者进程通信的问题，优先排查插件版本。

5.4 实战排查技巧：从一张时间线图到改完代码

最后分享一个我在实战中反复使用的“五步速查”流程，它结合了上面的所有内容，适合日常快速定位问题：

1. 固定基准：采集一次优化前的完整Profiling数据，记录step耗时、NPU利用率、通信占比三个核心数字。
2. 分类瓶颈：打开时间线视图，先判断是Host侧空闲还是Device侧空闲，再用算子统计表辅助确认瓶颈类型。
3. 单点修改：每次只改一个变量，比如只改num_workers，或者只改通信策略，不要同时动多个地方，否则无法判断哪个改动生效。
4. 对比验证：立即重新采集，把各项指标和基准数据做对比，看数值变化方向是否符合预期。
5. 记录结论：把每个瓶颈的分析结论、改动内容和验证结果记录下来，形成自己的性能问题排查库，下次遇到类似问题可以直接检索。

这套流程看起来朴素，但确实是我在多个项目里验证过最有效率的做法。性能调优不是一次性的魔法修改，而是一个反复测量、假设验证的过程。Insight JupyterLab插件真正便利的地方在于它把这个过程的所有环节都放在同一个界面里完成，不需要在多个工具之间来回跳转，这能让你的分析节奏保持连贯。

在我自己用下来的体验里，刚开始接触这个工具的时候，确实容易被各种视图和参数绕晕，但只要固定一个排查流程，把每次采集当作一次受控实验，慢慢地就会形成自己的判断直觉。尤其是那些看似不起眼的“等待间隙”，在时间线里被放大之后，往往就是性能提升空间最大的地方。希望这篇文章能帮你在昇腾设备上的性能调试少走一些弯路，你踩过的坑比我少一点，就是它最大的价值了。