昇腾自定义算子性能分析：从profiling数据到瓶颈优化

1. 拿到性能需求后，先别急着写算子：定位问题的整体思路

1.1 什么情况下才需要自定义算子，而不是用现成的

先说个实际场景。我那会儿拿到一个三维重建相关的加速任务，模型里有一段预处理逻辑，在 GPU 上用 PyTorch 写起来很方便，但迁移到昇腾环境后，我第一反应是去 CANN 自带算子库里找现成实现。翻了半天，发现标准的Transpose、Reshape、Cast都有，但算法里那种“按行做归一化后再做一次查表映射”的组合逻辑，没有任何单一算子能直接覆盖。如果硬拆成一串连续算子，数据要在 HBM 和 AI Core 之间反复搬运，性能损耗非常大。这时候才真正决定：自己写一个昇腾自定义算子，把两步合并成一步，在 AI Core 内部把数据全部算完。

所谓自定义算子，简单说就是在 CANN 的算子开发框架下，用 TBE 或 Ascend C 实现一个计算逻辑，最终编译成适配昇腾处理器的二进制算子。它解决的通常是三类问题：一是算法里有独特的计算逻辑，现成算子拼不出来；二是多个算子串行导致中间结果反复读写，想融合成单个算子减少访存；三是某类算子虽然存在但性能表现不理想，想针对自己的数据规模做定制优化。判断要不要写自定义算子，标准其实很朴素：先测一下现成算子组合的性能，如果 profiling 数据显示访存占比过高或 AI Core 利用率太低，再考虑自定义。

1.2 性能分析的介入时机与分析目标拆解

我见过的比较典型的错误做法，是算子写完能跑通就开始对接业务，性能问题等到联调阶段才暴露。其实性能分析应该从算子还在原型阶段就介入，最晚也要在算子功能验证通过后立刻做一轮 profiling，拿到一套完整的性能基线数据。这套基线包括：算子单次执行时间、AI Core 计算耗时、搬运耗时、任务调度耗时、内存占用峰值。有了这些数据兜底，后面每次优化调整都能做对比，而不是凭感觉说“好像快了”。

做分析之前还有一个容易被忽略的动作：把性能目标拆清楚。比如三维重建场景里，模型前处理算子被调用的频率是每帧一次，推理耗时目标 50ms，那这个算子的 budget 可能就是 0.5ms。用实际场景反推算子性能指标，比拍脑袋定一个“要优化到多快”靠谱得多。我当时给自己定的目标是单算子执行时间压到 30us 以内，后面所有的优化动作都是围绕这个数字展开的。

注意：性能分析不是从工具开始的，是从问题定义开始的。先搞清楚“多少算快、瓶颈是谁、影响多大”，再开 profiling，否则很容易被海量数据淹没。

2. 昇腾自定义算子的开发形态与性能基线设定

2.1 Ascend C 和 TBE：开发范式选型影响后续优化空间

昇腾上写自定义算子，当前主要两条路线：一是老牌的 TBE（基于 TVM 的算子开发框架），用 Python 写计算描述，通过 TVM 的调度原语控制循环和内存；二是 Ascend C，这是 CANN 后来主推的 C++ 编程范式，可以直接操作 AI Core 上的向量寄存器、累加器、L1 buffer 等硬件资源。

两条路线我都试过。TBE 的优点是上手快，如果只是做简单的形状变换或者逐元素计算，几行 Python 就能出结果，而且 TBE 的自动调度在不少场景下已经足够好了。但 TBE 在细粒度优化上比较受限，你想手动控制数据在 L1/L2 之间怎么切分、怎么复用，需要绕很多弯子，有些底层的 buffer 同步原语甚至没暴露到 Python 层。Ascend C 写起来更繁琐，要对 AI Core 的流水线结构有概念，得自己管理 buffer、自己处理同步，但它的性能上限明显更高，而且往后续的大模型算子场景扩展也更平滑。

所以我的建议是：先评估你的算法复杂度，简单的逐元素算子用 TBE 快速交付，涉及多维度切分、多级流水或者有强融合需求的算子，直接选 Ascend C。我那个三维重建场景的融合算子需要同时处理行归一化和查表映射，还涉及跨行访问，属于典型的强融合需求，所以一早就定了 Ascend C 路线。写算子之前，建议花半天时间把《Ascend C 算子开发指南》里关于 AI Core 计算流水线的那章读一遍，理解 vector 单元和 cube 单元怎么并行，对后面分析性能瓶颈帮助巨大。

2.2 先搭好 profiling 环境：常用工具链与关键配置

昇腾生态里做性能分析，最常用的是 CANN 自带的 msprof 工具，在 MindStudio 里也有对应的 Profiler 可视化界面。msprof 的优势是能同时采集算子耗时、AI Core 利用率、数据搬运量、内存使用情况等多维信息，一条命令把 profiling 结果导出成 json 或 csv，方便二次分析。

搭 profiling 环境有一个小坑：msprof 的采集项默认有很多开关，如果全开，采集本身会引入额外开销，测出来的数据会偏慢。我推荐按需采集，核心配置大概是：

msprof --application="python train.py" \ --output=./profiling_result \ --aic-metrics=all \ --task-time=on \ --dvpp-time=off \ --host-time=on

关键参数说明：

• --aic-metrics=all：采集 AI Core 上的所有硬件计数项，包括 vector 指令数、cube 指令数、busy/idle 占比，这是判断计算单元是否吃饱的依据。
• --task-time=on：采集任务下发与执行时间，用于观察调度开销。
• --dvpp-time=off：如果模型没有图像预处理，这个可以关掉，减少采集负担。
• --host-time=on：采集 Host 侧发算子的时间，有时瓶颈不在计算而在于 CPU 下发算子太慢。

多线程场景下采集会叠加采集损失，我建议在算子单测阶段用单线程数据做第一轮分析，跑通后再用真实场景数据做验证，这样拿到的时间数据更干净。搭建好环境之后，下一步就是读数据、定位瓶颈。

3. 基于 profiling 数据的瓶颈定位与优化实操

3.1 看懂 msprof 输出：从时间占比到 AI Core 利用率

第一次跑 msprof，导出的数据文件有几十个，新人很容易懵。我一般只看三个核心文件：op_summary.csv是每个算子的执行时间汇总，task_time.csv是任务调度细节，aic_metrics开头的那组指标是 AI Core 内部硬件的运行状态。

看op_summary.csv时，几个关键列记一下：Task Duration是算子总耗时，AI Core Time是实际在 AI Core 上计算的时间，Wait Time是等待数据搬运的时间。如果Wait Time占比超过 30%，说明计算单元在等数据，瓶颈大概率是数据搬运而不是计算本身。

aic_metrics那组指标我尤其推荐多花点时间研究。Vector 单元的busy ratio和idle ratio直接反映了向量计算是否存在空闲周期。我那个融合算子第一版 profiling 结果出来后，Vector busy ratio 只有 46%，Cube 利用率几乎为零——因为算子根本没有矩阵计算，却还在等待 AI Core 的公共资源分配；另外Wait Time占到了总耗时的 40%，数据和预判一致，问题出在数据搬运和内存访问。这个结论直接决定了我后续的优化方向不是调整计算逻辑，而是压缩搬运量。

这里想强调一个容易被忽略的点：AI Core 利用率高不等于算子快。有的算子 Vector busy ratio 跑到 90%，但总耗时还是高，因为单指令效率低、循环展开不够或者流水线没有重叠。所以看数据一定要多个指标交叉着看，不能单看某一个。

3.2 一个向量算子的真实优化案例：从 56us 降到 23us

讲个具体案例。那个按行归一化再查表映射的算子，第一版实现用的是最朴素的写法：每个线程负责一行数据，先读整行到 buffer，算完再写回。单测下来耗时 56us，远超 30us 的目标。

第一轮优化：把数据搬运从“整行读取”改成“分块读取”，每次只搬运 L1 buffer 能放下的大小。昇腾 AI Core 的 L1 buffer 是有限的，整行读取会导致单次搬运的数据量超过缓冲容量，硬件只能分多次搬运，每次搬运还要做地址对齐和同步，开销极大。改成按 8KB 分块后，单次搬运等待时间明显下降，算子耗时从 56us 降到 38us。这个改动本身的代码量不大，但对性能的影响很直接。

第二轮优化：在分块基础上做了多级流水。简单说就是计算当前块的同时预取下一块数据到 L2 buffer，让搬运和计算时间尽量重叠。Ascend C 里提供了一组 buffer 同步机制，我利用EnQue/DeQue接口实现了类似双缓冲的效果。这一轮改动后耗时从 38us 降到 29us，已经摸到目标线附近。

第三轮优化则是微调 block dim：把算子启动时申请的 AI Core 数量从固定 8 核改成通过上下文自动计算。我的数据量是动态的，固定 8 核在数据量小的时候有核空闲，数据量大的时候又不够用。改成按总数据量和单核可承受负载动态计算 block dim 后，整体耗时稳定在 23us 左右，完成目标。这轮优化也让我意识到，多核并行度不是越大越好，而是要结合数据规模和硬件上下文来动态调整。

实操心得：性能优化很少是一步到位的，每一轮改动后重新跑 profiling，拿前后两组数据做对比，才能确认优化方向和幅度都符合预期。

4. 常见性能问题汇总与排查技巧

4.1 访存瓶颈、搬运瓶颈、算子调度开销——速查表

昇腾自定义算子跑得慢，绝大多数问题能归到三类：访存问题、搬运问题、调度问题。我整理了一张比对表，直接对着排查就行：

这张表不是万能的，但覆盖了我遇到的大部分性能问题的共性。遇到新问题先从这五个窗口里找，找不到再深入查硬件相关指标。

4.2 多核并行度与 block dim 的动态切分经验

block dim 是昇腾算子开发里被讨论最多也最容易踩坑的参数之一。简单说，它决定了一个算子 Task 启动时申请多少个 AI Core。block dim 设小了，多核优势发挥不出来；设大了，数据分配不均匀，部分核空闲，还会因为核间同步引入额外开销。

我推荐的做法是在算子实现里写一个简单的切分策略：根据输入数据总量和单核建议负载来计算 block dim。比如我用的是 1 核一次处理 64KB 数据的经验值，数据总量 8MB，理想 block dim 就是 128。但实际开发要用一个上限值约束住，因为昇腾某些型号的 AI Core 总数有限，申请超过硬件能力反而会排队等待，不如用略小一点的数值稳定。

动态切分还有一层细节是切分维度的选择。数据如果是多维的，尽可能在行方向切分，保持每行数据连续，这样能提升搬运效率。如果必须在列方向切分，要先确认硬件支持对该维度做 stride 访问，否则会出现非连续读，性能直接掉一个量级。这个点在我第一次开发时踩过坑，当时为了配合查表映射逻辑，我选错了切分维度，导致搬运次数翻倍，耗时不降反升。

关于 block dim 还有一个经验：最佳 block dim 不是固定值，它跟数据大小、算子内部 buffer 需求、AI Core 的 L1/L2 容量都有关系。所以我在算子代码里加了自适应逻辑，不同数据规模用不同 block dim，实测下来比固定配置平均提升 15% 到 20%。

4.3 排查现场实录：一次“计算时间正常但总耗时异常”的问题

再分享一个比较有代表性的排查过程。有次我把算子接进真实推理链路后，发现单算子测试性能正常，但端到端跑起来后算子耗时翻了快一倍。第一反应是优化算法，重新做 profiling 后却发现 AI Core Time 没变，变的是 Task Duration。

排查链路是这样的：先看 msprof 的 task 时间线，发现算子在 Host 侧等待了大约 20us 才被下发到设备侧，说明问题出在调度链路而不是计算单元。接着看之前的算子是不是有未完成的异步操作，结果发现我前一个算子开启了异步执行，但没做同步等待，当前算子启动时还在等前一个算子的结果回传，所以白白多等了很久。

这个问题的解法其实很简单：在算子边界做一次流同步，或者在异步算子执行完后就立即把结果回调。但当时因为没意识到上一个算子会拖慢当前算子，浪费了大半天排查时间。从那以后我在做算子性能分析时，都会把“前序算子是否还在执行”“Host 下发是否延迟”这两个因素纳入常规检查项。

注意：算子边界问题经常伪装成算子内部性能问题。看到 Task Duration 明显高于 AI Core Time 加搬运时间时，先检查上下游算子的流同步关系。

5. 性能分析中的几个关键心得

5.1 工具数据不能全信，结合场景做二次验证

前面一直在讲怎么读 profiling 数据，但作为经验分享，我必须提醒一句：工具数据本身需要做交叉验证。msprof 采集到的数据总体来说可靠性很高，但开启采集动作本身会影响程序执行时序，尤其对微秒级的小算子，采集引起的开销可能占到总耗时的 10% 以上。最简单的验证办法是把同一个算子连跑 100 次，取 P50 和 P99 分别记录，再关掉采集跑一次，对比差距。如果差距太大，说明采集本身影响了程序行为，需要减少采集项或者改用手动埋点的方式。

另一个容易误导人的数据是平均耗时。平均耗时被少数极端值拉高的情况很常见，比如某个算子第一次被调用时会触发初始化、内存分配或者 JIT 编译，这条耗时会显著高于后续调用。我看性能数据时习惯分三段看：第一次调用的冷启动耗时、连续调用的稳态耗时、以及最长和最短之间的抖动范围。只有稳态耗时才是优化真正要关注的指标。

5.2 保留一份可复现的调优基线

做算子性能分析，很容易陷入重复劳动：每次优化都重新做一轮 profiling，每次的对比基准还不一样，最后说不清楚到底是哪一次改动起的效果。我在项目里给自己定了一个规矩：每次做性能改动之前，先把当前版本跑出一个基线报告，记录算子版本号、profiling 时间和关键指标；优化后又生成一个新报告，两层之间做 diff。

这一步看起来繁琐，但真到后面做多版本对比或者要回溯问题时，价值非常大。有一次我优化某版算子时顺序调换了两个计算段的次序，功能测试通过，性能也提升了，但存了基线才知道原来的版本在某种数据分布下更稳。没有基线就只能凭记忆，有了基线就能快速定位问题并回退。

5.3 性能分析工具链路，建议沉淀成团队脚本

如果你不是一个人在做算子开发，而是团队协作，强烈建议把性能分析的流程固化成一两条命令或脚本。比如我会在工程仓库里放一个perf_analyze.sh，里面把 msprof 启动、结果导出、关键指标提取、生成对比报告这几个步骤全部串联起来。团队成员有新算子要分析，直接跑脚本拿结果，不用每个人重新搭环境和研究参数。这个沉淀下来的东西，可能是性能分析项目里最值得长期复用的产出。

另外一个小技巧：把常见的指标提取逻辑写成 Python 脚本，直接解析 msprof 生成的 csv，输出一张简化的“性能体检报告”，标红超过阈值的指标。这样连读原始数据的时间都省了，肉眼扫一遍就知道问题在哪。我在昇腾自定义算子性能分析这件事上，真正的效率提升就是从这一步开始的。

最后再分享一点个人感受。昇腾自定义算子性能分析这件事，本质上不是“跑个工具看数据”，而是通过数据反向理解硬件的工作原理。我踩过的坑，多半是对底层搬运机制、buffer 结构、调度流程理解不够透彻。写这篇内容，也是希望后来的人在分析算子性能时，少走一些我当时走过的弯路，尽快从“看数据”进入“调数据”的正循环。