从第一次把模型跑在昇腾设备上开始，我就一直在琢磨一件事：为什么同一个网络，在 GPU 上训练得好好的，迁移到昇腾上性能就差了一大截？后来追根溯源，问题几乎都出在算子这一层。昇腾算力真正落地靠的是 CANN 这套软件栈，而 CANN 里最核心、最底层的部分，就是神经网络算子库 ops-nn。可以说，算子库决定了硬件算力能被“榨出”几分。这篇文章我想结合自己实际调模型、跑推理的经验，把 CANN 里 ops-nn 的架构逻辑、算子分类、融合机制和性能调优方法从头到尾拆一遍，给正在做昇腾适配或者准备迁移模型的开发者一份能直接用的参考。

很多人第一次接触 CANN 会有点懵，因为它的概念太多了：GE、TBE、AscendCL、CANN toolkit…… 但如果盯住“算子”这条主线，事情就清晰多了。你训练也好、推理也好，最终要做的无非就是把卷积、矩阵乘、激活这些计算放到昇腾的 AI Core 上执行，而 ops-nn 就是这些计算的“标准动作库”。理解它怎么组织、怎么优化、怎么排查问题，基本就掌握了昇腾调优的钥匙。这篇文章既适合刚入门昇腾的开发者建立整体认知，也适合已经在做算子迁移、性能优化的人对照排查，我会尽量把原理和实操揉在一起讲。

1. CANN ops-nn 到底解决什么问题：先看整体架构

先说结论：CANN 是昇腾 AI 处理器的软件栈，ops-nn 是其中的神经网络算子库，负责提供卷积、矩阵乘、池化、归一化、激活等高性能算子实现。它的地位相当于 CUDA 生态里的 cuDNN 加一部分 cuBLAS 的集合，但底层硬件架构完全不同，所以不能直接用 CUDA 的思维去理解它。

1.1 AI 框架与昇腾硬件之间的最后一公里

用一张抽象的分层图来看，AI 计算栈大概分四层：最上层是 PyTorch、MindSpore、TensorFlow 这些框架；往下是图编译与运行引擎；再往下是算子层；最底层是昇腾硬件本身。CANN 里的 GE（图引擎）负责把框架下发的计算图做优化和拆分，然后交给任务调度器把算子派发到昇腾设备上执行，而真正干活的就是算子。

我用一个比方：框架是菜谱，计算图是备好的食材清单，GE 是切菜配菜的厨师，ops-nn 就是已经做好的“半成品酱料包”。一道菜的成败，既看厨师切配的功夫，更看酱料包本身的味道。如果你拿到的酱料包是普通牌子，那厨艺再高也做不出米其林水平。

在昇腾的体系里，算子分三类：内置算子、融合算子、自定义算子。内置算子由 CANN 官方提供，ops-nn 指的就是这些已经封装好、开箱即用的算子；融合算子是框架或者 GE 图优化时把多个小算子合并成的大算子，用来减少内存搬运；自定义算子则是开发者针对特有算法自己写的算子，通常需要用到 TBE（Tensor Boost Engine）或者 AKG 这类算子开发工具。

1.2 ops-nn 在 CANN 中的角色与边界

很多人在看 CANN 文档时会混淆几个概念：AscendCL 是统一编程接口，GE 是图执行引擎，TBE 是算子开发框架，ops-nn 则是算子库本体。它们之间的关系是：AscendCL 提供 aclnn 接口（比如 aclnnConv2d、aclnnMatmul），这些接口背后会查找并调用 ops-nn 里的算子实现；GE 在计算图执行阶段也会直接引用算子库里的算子描述信息来做匹配。

ops-nn 的边界很明确：它不负责图优化，不负责内存池管理，不负责设备调度，它只负责“把算子的计算逻辑用最高效的方式映射到昇腾硬件上”。这意味着，你几乎不会直接调用 ops-nn 的底层函数，而是通过框架或者 AscendCL 间接使用。但它又是性能瓶颈最集中的地方，因为一次卷积算子的实现如果不够好，整个网络的速度都会被拖累。

从实际项目来看，我有一个挺深的体会：在昇腾上排查性能问题，90% 的情况最后都会落到某一个算子上。比如之前做一个图像分类模型的推理优化，框架层、图优化层都没问题，但总体延迟就是比 GPU 高了一倍。最后用 profiling 工具一查，发现是某个卷积算子没有走融合逻辑，数据反复在全局内存和 L2 Cache 之间搬，带宽全浪费了。所以说到底，理解 ops-nn 就等于理解昇腾性能优化的核心。

2. 算子库背后的硬件逻辑：AI Core 怎么执行一个算子

想真正理解 ops-nn 的算子为什么要那么写，首先得搞清楚昇腾 NPU 里的“工人”——AI Core 是怎么干活的。这一点和 GPU 差异非常大，也是很多从 CUDA 迁移过来的开发者最不习惯的地方。

2.1 AI Core 的计算单元构成

昇腾的 AI Core 是一个高度专用的计算核心，内部大致分三个执行单元：

• 矩阵计算单元（Cube Unit）：专门负责矩阵乘和卷积运算，是昇腾算力的主力。它支持 16x16x16 的矩阵乘，一次可以算很大的数据块，效率极高。
• 向量计算单元（Vector Unit）：负责逐元素操作，比如激活函数、归一化、逐元素加乘。速度比 Cube 慢，但灵活性高。
• 标量计算单元（Scalar Unit）：负责控制流、地址计算、循环计数等辅助工作。

这里特别要强调Cube Unit。GPU 里的 Tensor Core 也是做矩阵乘的，但昇腾的 Cube Unit 在数据排布上有个独特要求：它希望矩阵在内存里是“分块连续”的。CUDA 的开发者习惯 NHWC 这种 naive 的排布，到昇腾上往往要转成 NC1HWC0（5D）或者 NZ 格式，否则算子效率会断崖式下降。ops-nn 内部其实已经帮你处理了大部分格式转换，但如果你自己写算子或做自定义融合，就必须理解这个逻辑。

2.2 从算子描述到机器指令的关键路径

一个算子从调用到真正在 AI Core 上跑起来，大概经历这几个阶段：

1. 框架下发算子或计算图。
2. GE 做图优化，可能触发算子融合。
3. 任务调度器为每个算子分配 AI Core 资源和内存。
4. 算子的tiling（切分）策略决定数据如何分块。
5. AI Core 上的微码（指令序列）执行实际计算。

其中tiling 策略是我特别想强调的概念。因为 AI Core 的片上存储（Local Memory）是有限的，比如只能装下一部分数据，所以一个大的卷积核必须把数据切成小块，一块一块地搬进来计算，再搬出去。切块的大小、搬运的时机、是否做 double buffer（双缓冲），这些直接决定了算子性能。

ops-nn 里的每个算子都内置了多套 tiling 策略，并且会根据输入形状、步长、数据格式自动选择最优方案。但在某些边界条件下，默认策略不是最优的，这时候就需要人为干预。比如我遇到过一个大 feature map 的池化算子，默认 tiling 导致 L2 Cache 命中率低，后来手动通过 profiling 分析发现是数据搬运指令过多，调整了切块参数后快了 40%。

这个例子说明，理解 AI Core 的执行模型，不仅是为了看懂 ops-nn 怎么工作，更是为了在性能调优时能跟 profiling 数据“对上话”。你看到全局内存读取量巨大时，要能立刻联想到 tiling 策略不合理；你看到向量单元利用率低时，要能意识到可能是算子没有充分利用 Cube Unit。

3. ops-nn 算子族谱：常用算子与融合黑科技

ops-nn 覆盖的算子范围非常广，我把它大致分成基础算子、融合算子和特殊算子三类来聊。理解这个分类，对模型迁移时预估性能很有帮助。

3.1 基础算子分类：卷积、矩阵乘、池化、归一化与激活

从功能上讲，ops-nn 里的算子几乎覆盖了主流神经网络需要的所有计算：

从模型迁移的角度看，最需要注意的是Reshape、Transpose、Concat这类“看似便宜实则昂贵”的算子。在 GPU 上，这些操作可能只是改了 meta data，但在昇腾上如果数据排布不对，就会触发实际的内存拷贝。比如 Transpose 从 NHWC 转 NC1HWC0，一次搬运就是整个 tensor 的大小，很容易就让推理延迟翻倍。

我做过一个对比实验：同一个语义分割模型，在 GPU 上部署时 Transpose 算子耗时占比只有 3%，迁移到昇腾后如果不对计算图做优化，Transpose 相关耗时能占到 15% 以上。这不是算子实现不好，而是硬件对数据排布的要求更苛刻。所以 GE 层会自动做很多 format 转换的优化，尽量让计算密集的算子留在 NC1HWC0 格式下执行，只在必要时才转回框架需要的格式。

3.2 融合算子的性能红利：不只是“少跑几个函数”

ops-nn 里性能最关键的部分其实是融合算子。所谓融合，就是把多个算子的计算合并成一个算子，减少中间结果的写入和读取。这个优化在昇腾上效果尤其明显，原因有两层：

第一，减少全局内存读写。不融合的情况下，Conv 的输出要写回全局内存，ReLU 要把这个输出读进来再算一遍，又写回去。融合后，Conv 的结果直接留在片上寄存器或 Local Memory 里，ReLU 紧接着就算完，只写一次结果。对于带宽受限的模型，这个优化往往是几倍的差距。

第二，避免格式转换。很多算子对数据格式有不同要求，如果分开算，中间可能要转格式；融合后可以统一处理，省掉转换开销。

常见的融合模式有：

• Conv + BN + ReLU 的融合：推理时把 BN 的均值和方差折算进 Conv 的权重里，再跟 ReLU 合并成一个算子。
• Conv + Add + ReLU：对应残差结构，把残差相加和激活都合进卷积里。
• MatMul + Softmax + MatMul：对应 Attention 结构，可以融合成 FlashAttention 风格的算子，大幅减少中间矩阵的读写。
• LayerNorm 内部的各类逐元素操作融合：把 mean、var、normalize 等步骤合并。

CANN 的图编译器（GE）会在构图阶段自动做这些融合，但自动融合不是万能的。比如一些奇怪的子图结构、不支持的数据类型、动态 shape，都可能导致融合失效。所以当你发现某段模型性能异常时，第一步就是去 profiling 报告里看是不是融合没有生效。

我自己踩过一个坑：一个基于 Transformer 的模型，在昇腾上跑时 Attention 部分特别慢，profiling 显示 MatMul 之后有个单独的 Softmax 算子，说明融合没触发。查了老半天，发现是因为模型里有个动态的 mask 形状，导致 GE 无法在构图时静态推断出融合条件。后来把 mask 处理改成静态 padding，融合就生效了，端到端速度提升了近 30%。

4. 实操：从算子调用到性能调优的关键路径

讲了这么多原理，最终还是要在实际项目里落地。这一节我梳理一套我自己常用的“算子维度调优”方法，从环境准备、算子调用、性能分析到优化手段，尽量给出可直接复现的操作步骤。

4.1 环境准备：确认 CANN 版本与算子支持情况

动手之前，先确认环境。CANN 的版本迭代很快，每个版本支持的算子列表和性能特性都不太一样。我的建议是：

1. 查看 CANN 版本号，确保算子和框架版本匹配。
2. 查询算子支持矩阵，确认目标模型里的每个算子都在支持范围内。
3. 跑一遍算子“冒烟”测试，确认基础路径可用。

环境上常见的一个坑是：框架版本和 CANN 版本不匹配，导致算子无法注册。我遇到过 MindSpore 升级后，旧 CANN 的某些算子接口失效，编译能过，一运行就报算子不存在的错误，最后升级 CANN 并重新安装配套的框架插件才解决。所以我的经验是：昇腾适配别追新，优先用官方文档里写了“已验证组合”的版本对。

4.2 用 profiling 定位算子的真实瓶颈

性能调优必须用数据说话，不要靠猜。昇腾的 profiling 工具能给出每个算子的执行时间、AI Core 利用率、读写带宽、指令数等关键指标。我把它分成三步：

第一步，看总耗时分布，找到 Top 10 耗时的算子。通常 80% 的耗时集中在少数几个算子上，先把它们列为优化对象。

第二步，看 AI Core 利用率。如果某个算子利用率很低，说明计算单元没吃满，大概率是数据搬运卡住了。这时候要关注读写量、L2 Cache 命中率这些指标。

第三步，看算子间是否有异常中断。比如两个算子的衔接处出现了大量同步等待，或者频繁的格式转换，这些都会在时间轴上呈现明显的空洞，值得重点排查。

我印象最深的一次调优是在一个检测模型里，profiling 发现一个很小的 Add 算子耗时排进前三。一开始大家都觉得奇怪，后来才发现这个 Add 的其中一个输入是刚从 NC1HWC0 转回 NHWC 的中间结果，格式转换本身就占了大量时间。根本原因不是 Add 慢，而是前面的算子把格式搞复杂了。这个案例告诉我们，算子耗时只是一个表象，要顺藤摸瓜看数据和格式流动。

4.3 算子性能优化三板斧：融合、改排布、调 tiling

定位到瓶颈算子后，优化的手段无非三板斧。

第一板斧是确认融合策略。看看 GE 是否把可以融合的算子都融合了。如果没融合，分析原因。常见解决办法包括修正动态 shape、统一数据类型、调整网络结构避免特殊分支。这一步能解决大量问题，也是成本最低的手段。

第二板斧是调整数据排布。如果算子在 NC1HWC0 下执行最高效，但模型某个环节非要 NHWC，那就考虑用 GE 的格式优化，尽可能把格式转换集中到少数节点，而不是每个算子都转一次。必要时可以在框架层面调整输入输出的维度顺序，让整张图尽量在一种“友好”的格式下计算。

第三板斧是手动调 tiling 参数。这是最后的手段，因为需要比较深的硬件理解。通常先用 profiling 确定是搬运受限还是计算受限，然后通过修改算子的 tiling 相关配置（比如调整分块大小、开关 double buffer）来做实验。CANN 的自定义算子开发接口也允许你写更精细的切分逻辑，但一般用户不需要走到这一步。

这里要特别提醒：别一上来就“手动优化算子”。算子层面微调的效果一定不如图层面的结构优化来得大，而且复杂度高、维护成本高。我的习惯是：先保证融合和格式没有问题，再考虑 tiling。

5. 常见问题排查实录：算子报错与性能异常的应对方法

最后一部分，直接上干货：把我在昇腾算子相关问题上积累的排查经验整理成清单，遇到类似问题可以按图索骥。

5.1 算子不支持或执行报错怎么办

这是迁移模型时最高频的问题，报错信息通常类似于“The operator X is not supported”。先别慌，按顺序排查：

• 确认算子名称拼写和参数是否完整，有些算子因为参数组合不同，会走不同的底层实现，可能一个分支支持、另一个分支不支持。
• 确认 CANN 版本是否过老，升级到新版很可以解决。
• 确认是否因为动态 shape 导致算子进入不支持的路径，尝试把输入 shape 固定。
• 检查是否有官方文档说明该算子有特定限制，比如某些算子不支持半精度。

如果这些都不行，就考虑用几个小算子组合替代，或者自己写一个自定义算子。写自定义算子的技术路线一般是 TBE 或者 AKG，工作量确实不小，但如果算子本身很关键，收益也大。

5.2 模型整体跑得慢，但看不出是哪个算子问题

这种情况常见于图结构复杂、算子数量多的时候。我建议做“减法”：先把模型切成几个子图分别测耗时，定位到某一段后再往细分。如果整体都慢，优先怀疑数据搬运和格式转换过多，可以看看 profiling 里各段之间是否频繁出现 Transpose、Copy 类算子。

还有一个容易被忽略的点：内存池配置。昇腾设备的内存分配模式会影响算子的执行效率，如果频繁申请释放，会产生额外开销。通过环境变量或配置调整内存池策略，有时能带来意外惊喜。

5.3 算子性能忽高忽低，不稳定

如果同一个模型多次运行，耗时差异很大，多半不是算子本身的问题，而是资源竞争或缓存命中率不稳定。先看有没有其他任务占着设备资源，再看输入数据的 shape 是否动态变化导致 tiling 策略频繁切换。动态 shape 场景下，建议尽量做 shape 对齐或设置 shape 范围，让算子能复用同一套优化策略。

我在一个视频理解模型上就遇过这种问题，同一个 batch 的推理延迟忽高忽低。排查到深度学习是输入视频分辨率有轻微变化，算子每次都要重新选 tiling 策略。后来把视频预处理统一成固定分辨率并做 padding，延迟曲线立刻变得平滑。

我个人在实际操作中最大的体会是：昇腾的性能调优，本质上是“数据排布与搬运”的调优，而不是“计算指令”的调优。绝大多数性能问题的根源，都是数据没有待在它该在的地方。所以碰到问题别急着怀疑算子实现，先去看 profiling 里的数据流。另一个小建议是：把官方算子支持矩阵的变更记录当成常读文档，每次昇腾版本升级后先跑一遍冒烟测试，能省掉非常多排查时间。掌握了 ops-nn 这套体系之后，你会发现昇腾的算力其实远比表面看起来的要凶悍，只是需要你用对的方式去解锁它。