企业官网建设流程全解析

昇腾自定义算子性能分析：从定位瓶颈到调优落地的一次完整实践

做昇腾算子开发的朋友应该都有体会：模型跑通只是第一步，真正让人头疼的是性能。同样一个自定义算子，在GPU上可能随便写写就能跑满，换到昇腾NPU上，如果没摸清它的执行方式和性能特征，性能差个三五倍甚至一个数量级都是常有的事。这篇文章我想结合自己这段时间在昇腾上做自定义算子性能分析的实际经历，从思路、工具、实操到常见坑，系统地梳理一遍，希望能给正在折腾昇腾算子性能的同行一些参考。

昇腾的硬件架构和CUDA差别很大，很多经验不能直接平移。最典型的例子：GPU上习惯用shared memory做数据复用，在昇腾上对应的概念是UB（Unified Buffer），但它的容量、带宽和同步方式都不一样，如果还是按GPU的思路写，基本是事倍功半。另一个常见误区是把算子性能差直接归咎于硬件，其实很多情况下是没找准瓶颈到底在什么地方——是访存受限，还是计算受限，还是搬运和计算没有重叠，这三者的优化方向完全不同。这篇文章会重点讲讲怎么用昇腾自带的Profiling工具把这些信息扒出来，然后针对不同瓶颈类型做对症下药。

内容主要面向两类读者：一是刚接触昇腾算子开发，想建立性能分析基本方法论的开发者；二是已经在写自定义算子但性能上不去，想系统排查优化思路的同行。无论你是做AI算法还是做底层软件栈，只要涉及在昇腾上跑自定义算子，这篇文章的思路和步骤都可以直接拿来做参考。

1. 整体设计与性能分析思路拆解

1.1 为什么自定义算子的性能分析不能照搬GPU经验

昇腾NPU的硬件设计目标很明确：为AI推理和训练场景提供高吞吐的矩阵运算和向量运算能力。它不是一个通用的GPU，指令流水线、存储层次、并行模型都围绕AI计算做了特殊设计。这意味着在GPU上总结出来的性能优化经验，到了昇腾上至少要打一个问号。

最直观的差异体现在存储结构上。昇腾的每个AI Core有L0 Buffer、L0 Cache、UB、Unified L2等多级存储，其中UB是存放输入输出数据和中间结果的主战场，容量通常在192KB到256KB左右，远小于GPU的shared memory总量，而且它是一块锁步（lockstep）管理的缓冲区，由开发者明确控制数据的搬入搬出。你没法像CUDA那样写一个指针让硬件去乱序访问，所有数据都要显式地在UB和全局内存（Global Memory）之间搬运。

这就引出一个关键结论：昇腾自定义算子的性能瓶颈，绝大多数时候不在计算单元本身，而在数据搬运。在GPU上写算子，只要不是访存密度极低的场景，编译器通常能通过合并访问、缓存命中把访存压到还不错的水位；但昇腾的搬运是显式DMA（Direct Memory Access），搬运指令的开销、数据分块的粒度、搬运与计算的重叠程度，每一项都会直接体现在最终耗时时长上。如果一开始就用“计算密集型优化”的思路去调一个访存密集的算子，绕了一大圈可能收效甚微。

1.2 性能分析的三段式方法论

面对一个性能不达标的昇腾自定义算子，我倾向于分三步排查，先把问题定位清楚，再谈优化。

第一步是量化基线。不要凭感觉说“慢”或“快”，先跑一次性能profiling，拿到该算子在实测数据shape下的耗时、吞吐、占比等硬指标，同时也确认一下它是不是当前模型step时间的主要贡献者。这一步最容易被忽略，但恰恰是最重要的——很多工程问题在数据面前根本不值得优化。

第二步是判别瓶颈类型。拿到profiling数据后，看AI Core耗时里计算流水线和访存流水线的占比：如果计算时间远高于搬运时间，说明是compute bound；如果搬运时间占绝对大头，说明是memory bound；还有一种比较隐蔽的情况，搬运和计算几乎没重叠，很多时间花在等待上，这种是pipeline stall问题。三种情况的优化策略完全不同，后面我会详细展开。

第三步是做定向优化和回归验证。根据瓶颈类型选择优化手段，比如调整数据分块大小、修改搬运策略、增加双缓冲（double buffer）等，每次改动只动一个变量，然后重新profiling对比。优化的过程本质上是一个“假设-验证-再假设”的循环，千万不要指望一次能调到完美。

这套三段式方法论看起来平淡无奇，但实际执行中很多人会在第一步就翻车——他们拿到的profiling数据是错的，或者根本没理解数据含义。所以下一节我会重点讲怎么正确使用工具，拿到准确且有解释力的性能视图。

2. 核心工具链与关键指标解读

2.1 性能数据从哪来：Profiling工具的正确打开方式

昇腾生态里，性能分析最常用的入口是torch_npu框架下的profiler接口，以及配套的昇腾Profiling工具链。如果在CANN环境下手写算子并用AscendCL（Ascend Computing Language）接口调测，还可以直接调用CANN的Profiling模块，通过环境变量或API控制采集范围。这里我以最常见的PyTorch + 自定义算子场景为例，先说怎么把数据采出来。

假设你已经用torch_npu跑通了一个包含自定义算子的模型，最简单的采集方式是：

import torch_npu from torch_npu.contrib import profiling # 在推理或训练循环外层包裹 profiling with profiling.profile(activities=[torch_npu.npu.profiler.ProfilerActivity.CPU, torch_npu.npu.profiler.ProfilerActivity.NPU]) as prof: output = custom_op(input_tensor) # 自定义算子执行 print(prof.key_averages().table(sort_by="npu_time_total"))

关键参数有两个：activities列表决定采集CPU侧还是NPU侧的耗时；sort_by可以按NPU耗时排序，快速找到最耗时的算子。对于单算子调优，还可以缩小profiling范围只包住目标算子，减少数据量和干扰项。

如果算子是用CANN的ACL接口单独开发并运行的，性能采集方式有所不同。一般是在运行程序前设置环境变量开启profiling，或者调用aclprofInit等接口做精细化打点。采集完成后，会生成一份包含op_summary、op_statistic、task_time等信息的profiling目录，后续可以用msprof工具（CANN自带的解析脚本）把原始数据解析成可读的csv或json格式。有一点要提醒：profiling本身会引入额外开销，采集阶段测出来的耗时和实际运行会有偏差，但用于定位相对瓶颈和对比优化前后的趋势是足够可靠的。

2.2 必看的几个指标：从数字里读出问题

拿到profiling结果后，数据表会很长，但真正需要关注的指标其实不多。我的习惯是先看四类数字：

第一是算子总耗时（npu_time_total）。看它占整个模型step时间的比例，判断优化优先级。

第二是AI Core耗时占比。昇腾的profiling会区分AI Core上的执行时间和AI CPU上的执行时间。如果算子主要逻辑跑在AI CPU上，那问题就大了——AI CPU是通用处理核心，算力远不如AI Core，自定义算子如果没被正确映射到AI Core上执行，性能基本是灾难级别的。

第三是搬运和计算的比例。昇腾的原始profiling数据里会细分搬运（MTE指令）和计算（AI Core指令）的事件。如果搬运时间长于计算时间，说明算子很可能被访存带宽限制住了。这个判断不绝对精确，但作为第一轮筛选已经够用。

第四是流水线利用率。在更细粒度的数据里，能看到任务在AI Core上的执行是否像流水线一样平滑推进。如果中间出现大量同步等待的空洞，说明搬运和计算的overlap没做好。

对这些数字，我个人的经验是：如果AI Core利用率在70%以上，算子性能已经算健康；低于50%，基本可以确定存在明显的结构性瓶颈——数据切分太碎导致调度开销大、搬运河算串行等待、或者算子图被拆得过于细碎。后面优化时方向也就有了。

2.3 从Profiling数据看瓶颈类型的一个实例

说一个我印象很深的例子。之前优化过一个自定义的LayerNorm变体算子，输入是[8, 128, 3072]的fp16张量，单算子耗时2.3ms。从op_summary里看，AI Core耗时占到了1.9ms，看起来像是计算问题。但再往下扒task_time数据后发现，真正在AI Core上的计算指令只占了0.5ms，剩下的1.4ms全部是数据搬运和等待。

也就是说，计算单元实际只忙碌了26%。这就是典型的memory bound，而且很大概率是搬运和计算没有重叠导致的。后来做的主要优化就是把原来的单次大块搬运改成多级分块搬运，引入双缓冲让下一次数据搬运和当前计算重叠，最终算子耗时降到了0.65ms。这个案例后面我还会展开讲细节，这里先记住结论：数字里藏着真相，只看表面指标很容易误判。

3. 实操过程：从基线采集到优化落地

3.1 第一步：搭建稳定的性能测试环境

做性能分析前，环境稳定性是第一位的。昇腾板卡对温度、频率、多任务抢占都很敏感，如果你的机器上还有其他进程在跑，或者NPU在高温降频，测出来的数据起伏会很大，根本无法做前后对比。我的经验是：性能测试前至少保证以下几点。

• 使用独立的NPU卡或通过环境变量指定单卡，确保没有其他任务抢占AI Core资源。
• 关闭影响性能的动态电源管理（如果机器支持），或者至少记录当前NPU频率和温度，确保对比测试在接近一致的硬件状态下进行。
• 每个shape或配置测5次以上，取中位数或最小值，而不是平均值。平均值容易被偶发抖动带偏。
• 基准测试脚本里固定算子输入shape和dtype，不要用随机shape跑多次混在一起统计。

这些准备看着琐碎，但能帮你后面节省大量排查问题的时间。曾经有同事因为没固定NPU频率，跑同一个算子的耗时在1.1ms到1.8ms之间跳来跳去，性能优化做完以为是负优化，回滚版本后才发现是频率抖动，非常耽误事。

3.2 第二步：采集基线并定位瓶颈

以一个类似上面提到的LayerNorm自定义算子为例，我用torch_npu的profiler做单算子采集，流程如下：

import torch import torch_npu from torch_npu.contrib import profiling x = torch.randn(8, 128, 3072, dtype=torch.float16).npu() w = torch.randn(3072, dtype=torch.float16).npu() b = torch.randn(3072, dtype=torch.float16).npu() # 先做几次warmup，排除初始化、shape推导等一次性开销 for _ in range(10): out = custom_layernorm(x, w, b) with profiling.profile(activities=[ torch_npu.npu.profiler.ProfilerActivity.CPU, torch_npu.npu.profiler.ProfilerActivity.NPU ]) as prof: for _ in range(20): out = custom_layernorm(x, w, b) torch_npu.npu.synchronize() print(prof.key_averages().table(sort_by="npu_time_total"))

输出表格里能看到算子名称、CPU耗时、NPU耗时、占比等信息。我比较关注两个位置：其一，这个自定义算子是否真的被当做一个独立kernel在NPU上执行，如果profiling里根本没出现，说明可能被融合优化掉了，那性能问题的归属就完全变了；其二，NPU耗时是否远大于类似功能的原生算子，如果大于3倍以上，值得深入排查。

基线采集下来，如果单算子耗时2.3ms，而一个PyTorch原生的LayerNorm在相同shape下只要0.4ms左右，那就说明自定义算子性能确实有问题，值得花时间优化。

3.3 第三步：细分时间构成，找到真正的瓶颈

profiling的聚合表只能看到总耗时，要细分到搬运和计算，需要用更细粒度的Profiling数据。在CANN环境下，我一般是用msprof工具解析原始profiling目录，重点看task_time维度的数据。它会列出每个task在AI Core上执行时各类指令的耗时，比如AI Core计算指令、MTE指令（数据搬运）、同步等待等。

如果你的运行环境不方便直接解析原始profiling目录，还有一个偏经验的替代方法：把算子的核心计算逻辑分别做“空跑”和“全跑”两组实验。比如LayerNorm的核心计算是reduce求均值和方差、然后是归一化和仿射变换，你可以先注释掉搬运部分只保留计算逻辑，然后反过来注释掉计算只保留搬运逻辑，对比两组耗时，大致判断是计算慢还是搬运河。

在实际项目里，我更推荐直接用profiling原始数据，因为经验法容易受人尝试局限影响，数据说话永远最可靠。通过task_time数据，假设我们看到AI Core计算耗时0.5ms、MTE搬运耗时1.4ms、同步等待0.4ms，瓶颈结论非常明确：访存和搬运主导了整个算子的耗时，需要从数据搬运策略和流水线重叠上做文章。

3.4 第四步：针对访存瓶颈做分块和双缓冲优化

找到访存瓶颈后，核心优化思路就清晰了：减少搬运的数据量。昇腾上做reduce类算子，常规方案是让每个AI Core负责一部分行数据的reduce计算，最后再做跨核reduce。这个方案本身没问题，但很多人实现时直接把整块输入从Global Memory搬到UB，算完再整体搬回，一次搬运的数据量非常大，而且所有AI Core同时搬运会造成带宽争抢。

更优的做法是分块（tiling）加双缓冲。以[8, 128, 3072]的LayerNorm为例，可以按最后一维3072来切分任务：每个AI Core处理一行里的连续3072个元素，因为reduce本身就要求完整的一行才能算均值方差，所以这里的分块粒度是batch和行维度，比如每个AI Core处理8行到16行不等，根据AI Core数量和总行数动态决定。

实现层面的核心伪代码如下，示意在Ascend C中如何实现分块搬运：

// 伪代码示意，省略头文件和上下文 void LayerNormKernel(GM_ADDR x, GM_ADDR y, GM_ADDR w, GM_ADDR b, GM_ADDR mean, GM_ADDR var) { // 获取当前块对应的行范围 uint32_t row_begin = block_idx * block_row_num; uint32_t row_end = row_begin + block_row_num; // 循环内做双缓冲：当前块搬运和上一块计算重叠 for (uint32_t row = row_begin; row < row_end; row++) { // DataCopy：把row行的3072个元素从GM搬到UB DataCopy(ubBuf, gm + row * 3072, 3072); // 当前块数据到位后，启动Reduce计算 // 这里和下一行的DataCopy构成pipeline重叠的关键 ReduceMeanVar(ubBuf, ubMean, ubVar, 3072); // 利用均值方差对归一化，然后做仿射变换 NormalizeAndAffine(ubBuf, ubMean, ubVar, w, b, 3072); // 把结果搬回GM DataCopy(gm + row * 3072, ubBuf, 3072); } }

上面代码里最关键的是DataCopy和计算指令之间的调度顺序：理想状态下，当前row的Reduce在计算时，下一row的数据已经通过DMA搬到另一块UB缓冲区，这样搬运延迟被计算掩盖掉。要实现这一点，比较直接的办法是交替使用两块UB buffer，当前buffer计算时下一buffer已经在搬运，这就是所谓的双缓冲。

双缓冲的收益在这个LayerNorm例子里是巨大的。优化前单次搬运2.3ms，优化后的实测耗时0.65ms，其中一个核心原因就是DMA搬运和AI Core计算从串行变成了流水线重叠。但要注意，双缓冲会增加UB空间的占用，你的算子如果本身就重度依赖UB空间存中间结果，可能要先压缩单块的数据粒度，否则会放不下。

3.5 第五步：优化效果回归与稳定性验证

优化完成后，不能只看一两次测试结果就宣称“优化成功”。正确的做法是回到同一套性能测试脚本，用完全相同的shape、dtype、warmup次数和统计方式，重新采集至少5轮数据，取中位数对比优化前基线。同时记录NPU频率和温度，避免硬件状态不同造成的偏差。

我习惯用一张表来追踪优化前后各项指标的变化，包括算子耗时、AI Core利用率、搬运时间占比、端到端模型step时间。这样不仅自己心里有数，汇报时给同事或者领导看也一目了然。

以LayerNorm这个case为例，优化前后的数据如下表：

可以看到，单算子的优化效果在端到端模型上也有体现，虽然因为其他算子的存在没有完全等比例下降，但从2.3ms降到0.65ms，对整体step时间的影响还是很明显的。

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

4.1 为什么profiling里找不到我的自定义算子

这个问题我见过不少次。检查一下你的自定义算子是否被后端做了算子融合（fusion）或重写。昇腾的图编译阶段有算子融合优化，比如小算子合并成一个大算子，这时候你原来写的自定义算子可能只是融合大算子里的一个部分，单独的名字就不会出现在profiling里。判断方法很简单：看输出表里的kernel name是不是和你注册的算子名一致，如果不一致，去检查图编译阶段的融合配置，必要时通过算子属性或在特定条件下关闭融合，再进行单算子性能对比。

另外，如果自定义算子是用TBE DSL或者Ascend C写的并通过framework注册，但profiling里看不到它，还有一个可能是算子被执行在了AI CPU上而不是AI Core上。AI CPU模式下profiling也会显示不同的task类型，而且耗时通常偏高。遇到这种情况，优先检查算子的调度类型和输入数据格式是否满足AI Core的执行条件。

4.2 AI Core利用率低，但搬运也少，问题出在哪

有时候profiling数据显示计算不多、搬运也不多，但总耗时很高。这种情况我遇到过几次，原因一般是：任务切分太碎，启动调度开销大；或者算子内部有大量同步等待指令，比如同步整颗NPU的Global Memory Barrier。

AI Core执行task时，如果每个task处理的数据量很小，task数量就会非常多，而task的创建、下发、同步本身是有固定开销的。比如一个大矩阵的elementwise算子，如果你把每个元素作为一个task处理，性能一定惨不忍睹。解决办法是合理设置tiling参数，让每个task处理尽量多的数据，充分利用AI Core的并行能力。

同步等待问题则多出现在多核协作场景，比如reduce跨核通信时，每个核算完部分结果后要等所有核都完成才能进入下一阶段。这种等待是无法完全消除的，但可以通过减少同步次数、做大粒度数据交换把等待时间摊薄。

4.3 数据从Global Memory到UB后计算还是很慢

还有一种隐蔽的坑：数据已经搬到UB了，但计算效率仍然很低。这时候要检查数据在UB里的排布是否满足昇腾向量指令的访问对齐要求。昇腾的向量计算单元对数据的对齐很敏感，推荐按32字节甚至更高的对齐粒度搬运和处理。如果你的输入张量是[8, 128, 3072]这种形状，最后维3072恰好是32的倍数，一般没问题；但如果是类似[8, 128, 3000]这种不友好的shape，很多人会忘记做padding。

我的习惯是在算子内部把不规则的维度pad到对齐边界再做搬运计算。虽然多搬运几个字节，但计算效率的提升远大于那一点点带宽浪费。还有一种情况是dtype问题：昇腾对fp16的数据搬运和计算效率通常高于fp32，能转成fp16计算的尽量用fp16，很多时候性能差距能到一倍以上。

4.4 算子间的调度开销对单算子性能的影响

做单算子性能分析时，还有一个容易忽略的问题：当前算子在一次完整的模型执行里，前后是否有其他算子抢占AI Core资源导致测量波动。最简单的方式是单算子测试环境只执行目标算子，不做模型级联调。但这又带来一个新问题——单算子环境测出的最优性能，在真实模型里未必能复现，因为相邻算子可能改变了缓存状态和搬运流水线的衔接方式。

所以我的建议是：单算子调优以“去掉外部干扰”为主，优化完成后一定要放进真实模型里做回归验证。如果优化在单算子环境下提升明显、端到端提升不明显，不要急着否定优化效果，先看看端到端链路里是否存在其他瓶颈掩盖了优化收益。这种现象在深层模型中很常见，算子的收益被下一个算子的瓶颈吸收掉了，需要继续做全链路profiling才能看清全貌。

4.5 一个很容易被忽略的问题：缓存冷启动效应

最后分享一个比较细的坑。昇腾NPU的L2缓存对算子性能影响很大，尤其是访存密集的算子。如果被测算子在profiling前没被充分执行过，缓存处于冷启动状态，首次执行的耗时可能比后续稳定态高不少。这也是为什么性能测试前必须先做warmup的原因。

我见过一个case，自定义卷积算子在第一次调用时耗时1.8ms，warmup到第10次之后稳定在1.1ms。如果在没有warmup的情况下做前后对比，性能提升数值会被明显低估。所以无论用哪种profiling方式，warmup都是必须做的，而且warmup的次数要足够，一般建议10次以上。

5. 不同计算场景下的性能优化侧重点

5.1 访存密集型算子与计算密集型算子的差异化调优

昇腾自定义算子按工作负载特征大致可以分成两类，它们的优化侧重完全是两个方向。

访存密集型算子，典型如elementwise、reduce、transpose、reshape等，优化的核心目标是减少Global Memory访问量、增加片上数据复用、让搬运与计算充分重叠。常见手段包括分块提高cache命中率、合并多次小搬运为一次大搬运、压缩数据类型减少传输字节数、用双缓冲掩盖搬运延迟等。

计算密集型算子，典型如矩阵乘、卷积、各种attention变体，优化核心则是如何充分利用AI Core上的矩阵计算单元和向量计算单元。这时数据分块不仅仅是为了搬运，更是为了让每个AI Core承载足够的计算密度，避免计算单元空转。矩阵乘里常用的tiling策略，比如将大矩阵切分为若干小矩阵块做分块矩阵乘，目的就是平衡UB容量、搬运量和计算密度的关系。

判断一个算子属于哪类，我的经验是在profiling数据里看AI Core计算指令耗时与MTE搬运耗时的比值。比值远大于1，按计算密集优化；比值远小于1，按访存密集优化；比值接近1，两者都要考虑，但优先优化搬运，因为带宽往往是更稀缺的资源。

5.2 多算子融合视角下的性能优化思路

有时候单个算子怎么调都调不到理想的性能，这时候退一步想想：是不是算子划分本身就不合理？昇腾图编译阶段提供了算子融合能力，把多个连续算子融合成一个粗粒度算子执行，可以减少中间张量的搬运和算子切换的开销。

比如LayerNorm内部实际包含reduce求均值、reduce求方差、归一化、仿射变换等多个子步骤。如果你把它们拆成多个独立算子串行执行，每个算子都要独立搬运输入输出，中间结果还得写回Global Memory再读出来，性能自然很差。写自定义算子的一个核心价值，就是能把这样一串高频小算子融合为一个kernel，在UB内完成中间结果传递，省掉大量Global Memory往返。

从性能分析角度来看，如果你发现模型里一个完整功能被拆成了很多细碎小算子，即使每个单算子profiling数据看起来正常，整体效率也会被中间搬运拖垮。这种结构性问题不是单算子优化能解决的，要回到算子融合或者自定义粗粒度算子的思路上来。

5.3 从单算子性能到端到端模型性能的延伸

单算子性能分析做到一定程度后，一定要回到端到端视角。昇腾上跑模型时，算子的执行顺序、stream调度、内存复用策略都会影响最终性能。一个算子优化得再好，如果它在模型的关键路径上只占5%的耗时，对整体收益也不会很明显。

反过来，有些算子单看不显眼，但它大量被调用，比如每层都有一个小算子，累计耗时占比可能达到30%以上，这种才是优化的重点目标。我一般会先跑一次全模型profiling，按npu耗时排序取Top 10的算子，逐个确认它们的瓶颈类型，再决定是否要做自定义算子优化或者算子融合。这样用有限的精力撬动最大的整体收益，比盲目优化某个看起来“不顺眼”的算子要高效得多。

6. 工具链与调优技巧的实战总结

6.1 用好CANN工具链里的Tiling和调试能力

性能调优离不开对tiling参数的理解。昇腾的自定义算子开发中，tiling是决定性能的关键一环，它负责把大张量切分成适合AI Core处理的数据块。tiling的参数直接决定了每个AI Core处理多少数据、UB空间怎么用、搬运多少轮。实际开发中，我建议先用一个相对保守的tiling策略跑通功能，再做一轮tiling扫描，找到当前算子在目标shape下的最优分块。

一个比较实用的做法是写一个tiling参数扫描脚本，在合法范围内遍历不同分块大小，每个配置测若干次取中位耗时。这种自动化扫描虽然耗时，但能帮你找到tiling参数的“甜点区”。相比之下，靠经验拍脑袋定参数，经常会出现这个shape下性能很好、换个shape性能就崩了的问题。好的tiling策略应该在一定范围内有鲁棒性，而不是只对一个具体shape有效。

CANN的调试工具也值得留意。比如通过环境变量开启dump功能，可以查看算子实际输入输出数据和中间buffer内容，定位计算结果不对、显存访问越界等问题。性能分析和功能调试交替进行，才能在优化过程中及时排除新引入的功能性错误。

6.2 双缓冲与多缓冲：从原理到实践

双缓冲的思路在昇腾算子优化里太常用了，值得单独聊聊。它的本质是用空间换时间：在UB中分配两块buffer，一块用于当前计算，另一块用于数据预取。计算单元处理buffer A时，DMA搬运引擎已经往buffer B里填下一段数据，两者并行执行，最终把原本串行的“搬运-计算-搬运-计算”变成“搬运的同时计算”。

多缓冲是双缓冲的推广，适合搬运量大且计算时间长的场景。UB空间允许的话，用多级流水线可以把搬运延迟完全隐藏起来。但要注意，buffer数量不是越多越好，UB空间有限，buffer多了单块buffer就小，每轮处理的数据量就会下降，可能反而增加循环次数和调度开销。我实际使用下来，大多数算子双缓冲就够了，只有部分搬运数据特别大的场景会用到三缓冲。

实现双缓冲时的关键点是确保计算回调不会访问正在被覆盖的buffer。常见做法是用同步信号量或事件机制等待DMA完成再触发计算，或者在循环中交替索引两个buffer。如果写得不严谨，会出现数据覆盖导致的计算结果错误，这类bug在性能调优中很难排查，因为错误时有时无，和时序有关。

6.3 从profiling数据中提炼可复用的优化清单

通过几次项目的积累，我自己会维护一份昇腾算子性能优化的checklist。每次拿到一个慢算子，按清单快速过筛：

• 算子在AI Core上执行吗？还是落在了AI CPU？
• 搬运时间占比是多少？有没有做双缓冲？
• 数据分块大小是否匹配UB容量和AI Core数量？
• 数据排布是否满足对齐要求？有没有padding？
• 是否存在过多同步等待？能否通过减少同步次数或调整切分粒度来缓解？
• tiling参数对动态shape是否鲁棒？极端shape下有没有退化风险？
• 算子是否可以被前后算子融合，省掉不必要的中间搬运？

这份清单不是万能的，但能保证面对一个性能问题时，不会只凭直觉瞎调。很多时候，慢算子的原因就藏在清单里某一项，照着查一遍，比反复改代码试效果好得多。

6.4 不同shape下的性能波动排查

昇腾算子在动态shape下的性能波动是个常见问题。固定shape下tiling参数调优到最优的算子，遇到动态shape时，每次shape变化都要重新计算tiling参数。如果tiling计算逻辑写得不好，比如某些shape下分块极不均匀，某些AI Core负载远高于其他核，性能就会明显退化。

检查动态shape性能问题的方法是在一组有代表性的shape上分别跑profiling，观察不同shape下AI Core利用率和耗时变化。如果发现在某些shape下利用率骤降，多半是tiling策略对shape的适配不够好，需要优化tiling的切分算法，让分块大小尽量稳定在一个高效区间。

还有一个细节：Ascend C开发环境下，不同shape对应的kernel编译和调度也可能不同。有些算子实现里包含多个分支，比如小shape走单核逻辑、大shape走多核逻辑，这个分支分支条件的边界值设置对性能影响很大。调优时要特别关注这类分支切换点，结合实测数据确定最优阈值。

7. 写在最后：性能分析中我坚持的几点工作习惯

做了不少昇腾自定义算子性能分析后，我最大的感受是：性能问题没有银弹，但一定有迹可循。只要数据采集准确、瓶颈定位清晰、优化手段对症，绝大多数算子都能获得量级上的提升。相比之下，最怕的不是算子本身难优化，而是方向错了还在拼命用力——比如明明是访存瓶颈，却花了一两周去抠计算指令的细节，收益自然很低。

根据我个人在实际操作中的体会，有几件事是值得长期坚持的。一是建立性能基线库，把每个优化案例的算子、shape、tiling参数、耗时和profiling截图记录下来，积累得越多，后续遇到相似问题就越快能定位。二是保持“一次只改一个变量”的原则，无论是调tiling、改缓冲策略还是改数据排布，混合改动时如果性能变了，很难归因到具体哪一项改动起了作用。三是优化完一定要回归端到端，单算子的收益最终要体现在模型整体耗时上才有实际价值。

最后再分享一个小技巧：在做单算子性能对比实验时，别只记平均耗时，最好同时记录p50、p95甚至最大值。昇腾NPU在高负载场景下，算子耗时的抖动比GPU更明显，只看平均值很容易被偶然抖动误导。多记录几个分位数，能更真实地反映算子性能的稳定性，也方便判断优化措施是否真的可靠。

昇腾自定义算子的性能分析是一个需要耐心和细心的过程，把方法论、工具链和实操经验结合起来，踩坑的次数会越来越少。希望这篇文章能帮到正在和昇腾算子性能“死磕”的同行们。