第一次把模型从另一个训练框架迁移到昇腾环境时，性能是一件让人挠头的事。某次跑一个视觉-语言多模态模型（后面就叫模型A），8卡训练，loss下降很平稳，但每个step耗时比预期多了将近20%。刚开始我怀疑是数据增强写得太重，查下来发现数据加载根本没有问题；后来装上CANN自带的性能分析工具msprof，才看到真正的问题根本不在数据侧——NPU有一大段空闲时间在干等Host下发算子。整段调优经历做下来，最大的感受是：性能优化不是靠感觉猜，而是靠一层层把时间账算清楚。
在CANN这套软件栈里，msprof扮演的角色相当于体检报告生成器：把一次训练的各个环节计时，包括CPU侧下发、NPU侧执行、数据搬运、集合通信等，输出带时间戳的轨迹。这篇博文就是用实战方式讲我如何用msprof从baseline一步步定位到具体瓶颈，并且在不改模型精度的前提下把硬件利用率提上来。适合刚接触昇腾平台、打算做性能分析和算子调优的开发同学参考，也适合已经跑通训练但总觉得“还能更快”的老手。
1. 跑msprof之前，先给性能问题分个类
先问一个问题：当我们说一个训练任务慢，慢在哪里？我常用一个比较朴素的比喻：NPU是生产流水线，Host是下生产指令的管理员。管理员的指令写得再快，只要流水线工人停下了，整条线的产出还是上不去。调优第一步，是把“时间花在哪”变成一张能翻来覆去看的账本。
1.1 昇腾异构架构下，一次算子执行分几步
一个算子从框架侧发起，到NPU真正算完，通常会经历这么几个阶段：
- 框架把算子图解析成底层能识别的任务，做内存分配和依赖分析；
- 通过AscendCL接口提交到Runtime，暂存在任务队列里；
- NPU侧调度器从队列取任务，交给AICore或AICPU执行；
- 执行过程中可能要访问HBM或DDR，产生数据搬运；
- 完成之后Host侧可能需要同步等待，确认结束再继续下一个算子。
慢可能发生在任意一个阶段。msprof干的事情，就是把每个阶段的起止时间分别记下来，方便我们确认到底哪一环最慢。
这一步看起来简单，但特别关键。很多人在一开始就掉进“单算子有多慢”的细节里，忽略了整条调用链的配合关系。实际上，昇腾这类异构设备的性能问题分布非常离散：有的瓶颈在框架侧的图解析，有的在算子分发线程，有的在内存搬运，还有的纯粹是Host和Device之间同步太频繁。不先把分类搞清楚，后面的优化大概率是乱枪打鸟。
1.2 两个先做的基础测量
在开profiling之前，先把外部指标记录好：单step时间、端到端耗时、稳定后的吞吐量、batch_size和模型结构。每改一次配置，性能指标就变一次，所以必须有一张能被反复对照的基线表。
我习惯把这类数据直接写成一张小表，方便后续所有改动都回填进去：
| 配置 | 单step耗时(ms) | 相对变化 | 备注 |
|---|---|---|---|
| baseline | 410 | - | 原始框架适配 |
| 分支A | 368 | -10.2% | 去掉逐算子同步 |
| 分支B | 360 | -12.2% | 增加task分发线程并绑核 |
之后再强调一遍：每次只改一个变量再复测，不要同时动线程数、batch_size、算子融合策略，否则出了问题根本不知道是哪一步引入的。我自己就吃过这个亏，一轮改了三个地方，结果性能没升反降，排查了一整天才发现是其中一个开关在特定shape下触发了异常分支。
2. msprof采集参数与第一手数据的打开方式
2.1 第一个采集命令怎么敲
安装好CANN toolkit后，msprof通常位于toolkit的bin目录下，基本用法是：
# 带完整应用进程采集，msprof和目标应用共用同一套环境变量 msprof --application="python train.py --epochs 1 --batch-size 64" --output=/tmp/prof_data默认会采集任务调度、算子执行等基础信息。要采集AICore内部单元利用率，比如向量单元、矩阵单元忙不忙，需要追加--aic-metric相关参数。不过我在第一轮一般不加，因为开得越细，采集本身对训练速度的拖累越大。先拿基础时间线看整体，再决定要不要深入某一层。
一个很容易被忽略的坑是采集环境。目标应用必须能正常访问昇腾设备的驱动和Runtime，否则msprof可能在启动阶段直接报错，或者产出一个空目录。我最初以为是自己命令写错了，反复检查参数，后来才意识到是先跑了个最小推理脚本验证环境，再换成正式训练命令才正常。所以建议你第一次用msprof时，也先用一段很小的推理脚本试跑，确认能生成产物目录，再上完整训练。
2.2 产物目录到底装了什么
采集完成后，输出目录里通常会有多个文件或子目录，不同CANN版本的具体文件名可能不太一样，但大致方向是稳定的。我一般第一眼会关注这几个：
| 产物（示意） | 内容 | 主要用途 |
|---|---|---|
| op_summary | 每个算子的开始结束时间、CPU耗时、Device耗时 | 找慢算子 |
| kernel_details | 各类kernel的详细执行时间、核内指标 | 定位具体算子内部瓶颈 |
| timeline json | 带时间戳的全量轨迹，时间线对齐 | 看Host与Device关系、gap分布 |
| op_statistic | 同名算子聚合统计 | 发现“小算子数量过多”问题 |
| 宿主CPU/内存计数文件 | 进程资源占用曲线 | 排除系统资源竞争 |
打开顺序建议是先op_summary按总耗时排序，再打开timeline核对。op_summary能帮你快速锁定“哪个算子最可疑”，timeline能告诉你“这个算子到底是在等什么”。
2.3 用Perfetto打开timeline：我建议的读图顺序
timeline文件一般是json格式，我习惯用Chrome浏览器的chrome://tracing或者Perfetto UI直接拖进去。读图顺序可以总结成“一纵一横三缺口”：一纵看有没有明显的设备大段空闲，一横看同一段时间内Host在不在忙，三缺口指空闲区、等待区和搬运区分别出现在哪里。
算子阶段在timeline里会分层显示，可以展开看AICore时间段和AICPU时间段。这里先不要一头扎进某个算子的细节，而是把一个train step的整个时空图缩放到合适位置，圈出几个异常区域。等改完代码，再回到同样的地方、用同一视角做前后对照，效果会非常直观。
提示：profiling本身会拖慢真实step，因为每一步都在记录额外日志。第一次采集不要直接跑全量epoch，先用几百个step取样；batch过大也容易生成超大文件，UI加载都会卡。
3. 实战案例一：把Host与Device之间的空转揪出来
3.1 现象与初判
模型A的8卡训练，单step基线约410毫秒，比理论预期高了15%左右。用npu-smi查看NPU繁忙率，看到的不是一条平稳的高位直线，而是周期性出现凹坑。我当时一度怀疑是多卡集合通信导致的，但把训练改成单卡复现，凹坑依然存在。这就排除了通信因素，问题大概率出在单机单卡的执行链路上。
于是开msprof跑500个step，得到第一份有效数据。
3.2 排查链路：从总时间账追踪到算子下发的空转
第一眼看op_summary，发现单算子本身的Device侧耗时并不离谱，就算把几个大算子全部加起来，也凑不出410毫秒的总耗时。这说明时间不是“算”掉的，而是“等”掉的。
接着打开timeline，每个step里都能看到一段段明显的“空心”区间：Device上算完一批算子和下一批算子之间，隔着几百微秒甚至2毫秒以上的空隙。而同时间Host线程处于忙碌状态，日志里不断在打印提交下一个算子的动作。结论很清晰：Device侧空闲不是因为它不想干活，而是因为Host侧投喂算子的速度跟不上。
再往下追提交路径，发现框架侧每发一个算子就调用一次阻塞等待，确保上一个算子返回之后才提交下一个。在流水线思维下，这相当于工人每做一个工件就要停下来等管理员重新发图纸，调度开销自然巨大。在这个案例里，算子本身既不慢，Device也不慢，慢的是Host和Device之间握手太频繁。
3.3 优化手段：把同步式下发改成流水线式下发
改动方向有三个：
- 取消逐算子同步等待，把没有依赖关系的算子连续入队，最后统一等待；
- 增加task分发线程数，并绑到合适的CPU核，减少调度噪声；
- 让Runtime的消息队列持续保持有任务，不要空等队列见底再去填。
简化后的伪代码如下：
# 优化前：每个算子执行完才继续 for op in op_list: exec_op(op) sync_wait() # 优化后：连续入队，批量等待 for op in op_list: exec_op(op) sync_wait()同样的思路也适用于两个互不依赖的分支：可以放到两个stream里并行执行，用事件做依赖，让设备侧在第一个算子的尾巴还没结束时就提前开始加载第二个算子的数据。
复测时，算子间的gap从最高的2.1毫秒降到了0.5毫秒附近，单step总耗时从410毫秒降到约368毫秒，提升约10%。后来再调整线程绑核，又压到了360毫秒左右。要注意的是，这里的“优化答案”并不是改两行代码这么简单，每一步都需要用msprof重新对比时间线来验证；否则很容易出现“感觉快了”但实际数据没变的假象。
4. 实战案例二：算力上去了，带宽又拖后腿
4.1 Host下发改顺以后，新的瓶颈暴露出来
第二个场景来自一个双塔召回结构的推理优化任务（模型B）。和训练不同，推理任务更在乎端到端时延。用msprof跑完一次完整推理，op_summary里显示一个大算子耗时占整个模型执行时间的30%以上。这个数字高得吓人，但当我打开AICore指标时，发现这个算子在计算单元上的占用率并不高，时间大量花在等待内存返回上。
AICore指标里能看到类似“搬运时间/计算时间”的统计项，ratio明显偏高，这就是典型的访存受限算子。它本身只做了transpose加cast，但由于输入输出都要走一遍HBM，数据量非常大，单位算力收益极低。这就像请了一位顶级厨师，却让他每天花大量时间从仓库搬菜，真正颠锅炒菜的时间反而很少。
4.2 如何定位“数据搬来搬去”的问题
把timeline聚焦到这个算子所在的区间，可以看到算子执行阶段前后穿插着大量搬运类task。再把模型的计算图拉出来，确认transpose、reshape、cast三个算子原本应该合并，但编译后没有融合，于是整张激活值在两算子之间被完整写回一次、又完整读出一遍。
内存带宽是有限资源，读和写各占一份流量。这几趟多余搬运直接把耗时拉高。尤其当数据量达到几十甚至上百MB时，在HBM上的往返开销不是“可忽略的工程细节”，而是实实在在的性能灾难。
顺带说一个理论判断框架：当“搬运次数乘单次数据量”远大于“计算量”时，优先考虑融合策略；只有当“计算量”本身是瓶颈时，才需要去提升并行度和计算单元利用率。很多人一看到算子慢就想着怎么并行，但在这个场景下并行没有意义——因为瓶颈是搬运，不是算力。
4.3 优化手段：让数据搬运变成数据绕过
我做了两套尝试：
第一套是用AOE自动算子优化工具跑一次图。命令行大概是：
AOE --job_type=1 --model_path=./model.om --output=./result不同CANN版本的参数可能略有差异，以实际手册为准。AOE会尝试多种算子实现和融合策略，选出耗时最低的一种，整个流程基本是自动的。第一次跑完，那个大算子的耗时已经有所下降，但还没有达到我的预期。
第二套就是手动改写。我把transpose加cast融合到相邻的大算子内部，让中间结果留在片上的L1/L2缓存里，而不是落到HBM再读回来。这一步需要改算子实现或者调整图结构，门槛比按钮式优化高一些，但收益也更直接。
最终结果：那个算子从占模型总耗时30%降到了12%左右，整个模型推理时延下降约12%。同时把batch_size从32调整到64，HBM读写的整体有效数据占比也提升了，因为单次搬运里真正被用到的连续数据变多了。
4.4 融合不是万能的
这里必须泼一盆冷水：不要为了融合而融合。两个算子如果本来可以并行执行，硬塞成一个反而可能增加寄存器压力，甚至造成性能回退。
在一个小实验里，我把两个本身无依赖的elementwise算子强行合并，结果单算子耗时反而增加了15%。原因是寄存器复用冲突导致编译器插入了额外的spill/reload。所以任何优化都要用msprof量化验一次，而不是凭直觉相信“融合一定好”。
5. 高频瓶颈自查清单与调优收尾建议
5.1 实测常见问题与对应分析路径
做了一段时间性能调优后，我发现大部分问题都逃不出下面这几类，整理成清单供你对照。
| 现象 | 可能的根因 | msprof看哪里 | 常见解法 |
|---|---|---|---|
| Device利用率低、Host忙 | 下发串行、同步等待过多 | 时间线gap + Host线程段 | 连续入队、批量等待、增加分发线程数 |
| 单个算子耗时长、内部计算单元不忙 | 访存带宽受限、数据布局不连续 | AICore指标 + kernel_details | 算子融合、减少HBM往返、优化数据布局 |
| 算子数量爆炸 | 框架产生大量小算子 | op_statistic同名算子计数高 | 图融合、改写为聚合算子 |
| 多卡扩展性差 | 集合通信与计算未重叠 | timeline中通信步骤出现同步空洞 | 通信与计算分stream、梯度合并、通信压缩 |
| 显存/Host内存拷贝频繁 | 数据在CPU与设备间反复倒腾 | copy类型task数量与总耗时 | pinned内存、复用buffer、延迟拷贝 |
每一条我都踩过对应的坑。尤其是“算子数量爆炸”这一类，看起来不显眼，但几千个加法、乘法小算子排在一起，光调度开销就能吃掉好几个点。op_statistic里的计数往往一翻倍就能看出来。
5.2 收尾checklist：别让profiling本身成为新坑
- profiling会拖慢性能，所以采集时用少量step取样就够了；得出优化结论后，务必在关闭profiling的环境下做全量复测。
- 每次改动只改一个变量，记录当时的日志、step耗时、机器型号；对比实验固定batch_size和锁资源。
- timeline文件很大时，用按时间片段或按step切分的方式控制体量，否则UI加载会很慢。
- 多卡调优先尝试单卡复现，能更快缩小范围；单卡环境没有任何额外变量干扰。
- 最后保留一份调优后的算子统计CSV，作为后续回归测试的参考基线。
提示：调优结束之后，我习惯把msprof采集开关彻底关掉，重新跑一次完整的end-to-end验证。因为很多时候采集状态下的性能和真实生产状态并不是一回事，开开关关之间的差异能把人绕晕。
最后再分享一个我自己的习惯：拿到一次msprof的轨迹，先不急着看慢算子列表，而要先问三个问题——空闲在哪、等待在哪、搬运在哪。这三个问题的答案往往能覆盖80%的性能问题；把这三个地方都描清楚，剩下才是针对单个算子的细节优化。按这个顺序走，你会发现“榨干硬件每一分算力”这个说法其实并没有那么玄，它就是把每一段空闲都给调度和融合填上，把每一趟多余的搬运都消灭在产物里。
