企业官网建设流程全解析

做昇腾方向的开发一年以后，我发现自己被问得最多的不是"算子怎么写"，而是"为什么同一个模型一到昇腾上，耗时和GPU对不上"。查来查去，问题往往不在模型结构，而在CANN这套软件栈的算子选择上。CANN神经网络算子库ops-nn，是昇腾算力真正落到每一个算子上的最后一层封装，可它又常常被误会成一本"API字典"，用哪个查哪个就行。其实它的算子实现、数据排布、tiling策略、融合规则，每一层都在悄悄改写模型最终跑出来的性能数字。

这篇文章我会把它彻底拆开：先讲ops-nn在CANN里的位置和它被误解的地方，再盘点它到底覆盖了哪些算子，跟着一个算子从API调用走到AI Core指令的完整链路，给出实测过有用的调优手段，最后列一份踩坑清单。正在做昇腾模型迁移、算子开发或者性能优化的人会从这里找到能直接抄的东西；刚准备上手昇腾、想弄清楚"这套算力到底怎么被放出来"的朋友，也能顺着这条线把整个软件栈串起来。

1. 先搞清楚定位：ops-nn在CANN软件栈里的坐标

1.1 从昇腾芯片到AI框架，中间隔了很多层

昇腾芯片的算力底座是一颗颗AI Core。每个AI Core内部有矩阵计算单元、向量计算单元和标量单元，以及围绕它们的片上存储。硬件真正能执行的是指令，而"卷积""归一化""注意力"这些数学概念，必须由软件栈翻译成硬件能跑的指令序列。

CANN自下而上大致是这样几层：芯片驱动和运行时Runtime、算子实现与算子库、图编译引擎GE、面向应用的AscendCL统一接口，再往上才是MindSpore、PyTorch这类框架的适配层。ops-nn的位置恰好在承上启下的地方：它把数学定义翻译成AI Core能高效执行的实现，同时向上层框架暴露整齐划一的算子语义。所以很多性能问题，最后都能追到这一层来。

如果把昇腾比作一支乐队，AI Core是乐手，指令集是乐谱规则，ops-nn就是乐队拿到的那份编曲总谱。同一个旋律，编曲简陋和编曲精心，现场效果天差地别。芯片的纸面算力只是上限，真正落到应用上的算力，很大程度取决于算子库这首"编曲"写得好不好。

1.2 ops-nn不是一份API文档，而是一整套"策略加实现"

新手最容易犯的错，是把ops-nn当成一个函数列表来背。你看一个Conv2D的接口说明，可能就一两页；但同样叫Conv2D，在不同shape、不同数据排布下的实际行为差异很大，因为算子背后至少还绑着三样东西：

• tiling策略：一个大矩阵不可能一次性塞进AI Core的片上缓存，要切成小块逐块计算，切法不同性能不同。
• 数据排布选择：同一个张量在内存里按NCHW排还是按NHWC排，会影响访存连续性和向量化效率。
• 融合规则：某些算子组合会被GE在编译期识别并熔成一个算子，减少搬运和启动开销。

这意味着，ops-nn里很多算子并不是一个固定不变的二进制，而是带着一堆"选择参数"。CANN版本升级后，同样的模型性能可能差出百分之二三十，原因往往就是某个算子的tiling策略或融合规则被重构了。这也是为什么只查文档、不看版本、不看profile的调优方法，在昇腾上基本行不通。

1.3 三个容易搞混的"算子"名词

查CANN资料时，"算子""算子实现""算子库"这几个词频繁出现，很多人被绕进去。以Conv2D为例：

• 算子是数学层面的概念，描述的是输入输出和计算逻辑，Open算子、PyTorch算子都是这个层面。
• 算子实现是底层kernel代码，可以用TBE写，也可以用Ascend C写，它决定指令如何生成。
• 算子库是把一系列算子的实现打包好的集合，ops-nn就是其中面向神经网络场景的那部分。

还有一个容易混的是"单算子调用"和"图模式"。单算子调用是指应用直接通过AscendCL拉起一个算子执行，适合推理服务里临时拼计算；图模式则是把整张模型图交给GE做优化合并后一次性下发。同一个算子在这两条路径里，实际执行的指令可能完全不一样。所以排查问题时，得先确认应用到底走的哪条路，否则会对着profile数据瞎猜半天。

2. 盘点ops-nn的家底：从卷积到注意力，覆盖情况一目了然

2.1 一张表看覆盖范围

我整理了ops-nn算子库里最常见的几类算子。这张表不用背，但建议收藏，后面做算子映射和迁移评估时经常要翻：

这个表最大的作用是破除一个错觉：很多人以为昇腾的算子库只覆盖CNN那一套，实际上Transformer时代要用的FlashAttention、RMSNorm这些新算子，新版CANN里也都有预置实现。真正缺的时候往往是太冷门的算子，这时候才需要自己用Ascend C写一个。

2.2 高频算子的性能语义：以Conv2D和Softmax为例

先看Conv2D。接口里最值得较真的是三个参数：strides、pads、dilations。GPU生态里很多框架用padding="same"或"valid"这种抽象，ops-nn里更常见的是直接给一组数字pads，让你显式控制上下左右补多少。这更接近底层语义，少了一层猜测，但也要求迁移代码时多一道换算。数据排布方面，Conv2D在昇腾上对输入format很敏感，NCHW和NHWC谁更优不是拍脑袋能定的，要看卷积算子的tiling实现，profile数据会给出答案。

再看Softmax。这个算子的经典问题是数值稳定性：直接算exp大数会溢出，一般实现会先减最大值再算。ops-nn里的Softmax做了这层处理，但如果你手动把softmax拆成reduce、sub、exp、div一串小算子，每个算子单独调用的开销会非常难看。这也是为什么我建议能用库算子就尽量别手拆，除非已经验证过自动融合确实没生效。

2.3 那些不显眼但关键的"搬运类"算子

Reshape、Transpose、Concat、Pad、Copy这类算子，数学上几乎不算计算，却在很多模型里成了隐性瓶颈。原因在于昇腾AI Core的数据搬运成本和GPU不完全一样。GPU上很多reshape可以做到零拷贝，因为底层只要改一下张量的metadata就行；但在昇腾的某些图优化场景里，一个不合适的Reshape可能触发实际的数据重排，把数据从DDR搬到片上再写回去，开销立刻上来了。

我在某次性能分析里遇到过一个极端的例子：模型主体推理只用了5毫秒，但前后几个Transpose和Concat加起来花了8毫秒。后来做的事很简单，调整上游算子的输出排布，让几个Transpose在GE阶段被消掉，整体耗时立刻掉下来。所以看到"这小算子能有多慢"的心态要收收，在昇腾上调优，搬运类算子往往是第一桶金。

3. 一个算子的"一生"：从API调用到AI Core指令

3.1 编译期：tiling决定性能的"切蛋糕"环节

一个算子从接口被调用到真正跑起来，第一个关键步骤是编译。ops-nn里的算子实现经过算子编译器生成指令，其中tiling参数的选择至关重要。AI Core的片上缓存有限，一个10GB的矩阵乘不可能整个塞进去，必须切成很多小分块，一批批搬进片上算完再搬出去。切块的大小、顺序、是否考虑数据复用，这些由tiling策略决定。

可以把tiling理解为切生日蛋糕：蛋糕很大，盘子很小。聪慧的切法能让每块蛋糕都带着完整的草莓，而粗糙的切法会让奶油糊得到处都是。在实际算子实现里，好的tiling会让数据在片上多复用几次，减少和DDR之间的来回搬运；差的tiling可能计算单元只用了一半，搬运单元却忙到冒烟。

这也是动态shape在昇腾上有时会变慢的原因。静态shape下，算子在第一次执行时就能确定tiling参数，甚至能缓存编译产物；动态shape下，每次shape变化都可能导致tiling策略重新选择或者重新编译，开销自然不是零。后面我会专门讲这个坑。

3.2 运行时：Host侧下发task，Device侧多核并行

编译生成的指令变成一个个task，由Runtime从Host侧下发给设备侧。昇腾的调度逻辑和GPU平台的大思路相似：应用先创建stream，把算子的task按顺序放进stream，再用事件控制依赖关系。多个AI Core并行执行，每个核负责自己的那部分数据分块。

单算子调用场景里，每个算子Launch一次，Host和设备之间通常需要同步等待，这种开销在一次两次时不明显，但几百个算子的图如果每个都单独Launch，累积起来就很可观。图模式的好处在于GE先把整张图做了融合、数据排布优化，再一次性下发，kernel launch次数大幅减少。这也是为什么框架侧的图模式适配做得好不好，对最终性能影响很大的原因。

我之前调试过一个推理慢的问题，模型规模不大，但单算子调用方式下延迟高得离谱。用profile看数据，发现大量时间花在算子启动和同步上，算子本身的AI Core耗时反而不高。换成图模式后，端到端延迟降了接近一半。这个案例我一直记着，做昇腾优化时，遇到性能问题先别往算子内部使劲，先确认走的是不是最优的调度路径。

3.3 存储搬运：AI Core跑得快，搬数据不见得快

昇腾AI Core的存储结构大致是：数据先从DDR搬到片上多级缓存，再进入计算单元。矩阵计算单元擅长做乘加，向量单元擅长做逐元素操作，但无论哪个计算单元，吃到的数据都必须先完成搬运。搬运带宽有限，搬运路径上的每一跳都有延迟，这就是"带宽墙"。

在GPU平台上，很多开发者习惯了显存带宽高，对数据排布不太敏感。到了昇腾上，同样的数据排布可能导致搬运量差好几倍。比如按NHWC排布的卷积输入，在某个具体实现里访存连续；换回NCHW，可能每一行数据都要跨行读取，搬运效率骤降。高效的ops-nn算子实现，本质就是尽量让数据在片上多待一会儿，多复用几次，而不是频繁进出DDR。

所以看一个算子的性能，不能只看它的计算量，计算强度、数据复用度、搬运量，这些才是真正决定最终耗时的指标。理解了这一层，再看profiling工具给出的搬运耗时、计算耗时，就能知道瓶颈到底在哪。

4. 实测可用的调优路径：融合、排布、profiling三条主线

4.1 先把能合的算子合掉：融合规则的价值

CANN的GE在编译图时，会应用一系列融合规则。最经典的是卷积、加偏置、激活函数这三件套，很多框架的图里它们是三个独立节点，在昇腾上会被融合成一个算子执行。省掉的不只是两次kernel launch，还有中间张量的读写。

但融合规则不是无限的。有些组合能融合，有些组合反而不能，具体取决于算子的实现方式和数据依赖。实战里我建议的做法是：先跑一版基准，然后用可视化工具或图dump把优化后的图拉出来看看，确认哪些节点被融合了，哪些没有。如果发现本应融合的却没融合，多半是shape动态、数据排布不匹配或者某个算子用了特殊参数导致的。

有一次我遇到Conv和BN在推理时没有被融合，排查后发现是因为前面某个节点输出了非标准排布的数据，BN算子被迫插入了一个Transpose。把上游节点的输出format改对之后，Transpose消失，Conv和BN顺利融合，整体性能立刻改善。这种问题只看代码是看不出来的，必须把图展开。

4.2 数据排布不换，性能差一倍

数据排布是昇腾调优里性价比很高的一环。同一个张量，用ND格式可以无损表达任意shape，但计算效率可能不如框架内部选择的专用格式。很多算子库实现里，卷积、矩阵乘这类计算密集型算子更喜欢某种特定排布，因为访存连续、向量化友好。

我在某个检测模型上做过对比：输入从NCHW改成NHWC后，仅CNN主干部分的耗时就降了差不多三成。这不是玄学，而是数据在片上搬运路径变短了，矩阵乘的分块加载更顺了。但注意，不要盲目把全模型的数据排布都改一遍，有些算子对排布没要求，改了反而多出转换开销。正确做法是看profile，让关键计算节点的数据排布尽量一致，必要时在图的边界位置显式插入转换，而不是在算子实现里硬扛。

4.3 profiling怎么看：数据才是一切优化的出发点

调优离不开性能数据。昇腾生态里有profiling工具，能采集AI Core耗时、搬运耗时、算子等待时间、stream占用情况等信息。拿到一份profile报告，我通常按照这个顺序看：

• 先看总耗时都花在哪些算子上，找出top N耗时算子。
• 再看每个算子的AI Core耗时和搬运耗时占比，判断是计算密集还是搬运密集。
• 最后看算子的等待时间，比如是否频繁同步、是否因前序算子没做完而空等。

有次排查一个文本分类模型，从profile里发现耗时第一的不是矩阵乘，而是一个Gather算子。顺着依赖链查下去，发现上游做了多次数据变换，导致Gather的索引访问很不规则。最后把几个算子组合成一个自定义Ascend C算子，搬运量和耗时一起降下来。这类优化靠猜是猜不出来的，只有profile能告诉你真相。

5. 从GPU迁移到昇腾，我遇过的ops-nn三大坑

5.1 参数语义的坑：pads与padding不是一回事

迁移代码时最隐蔽的问题，是API长得像但语义不一样。Conv2D的padding参数就是这样：GPU生态里习惯用padding="same"或"valid"，昇腾算子常常要求显式给出pads数组，指明上、下、左、右各补多少。如果你照搬相同语义，有时会自动换算成功，但遇上奇数kernel、stride大于1的情况，换算结果可能和原框架不一致，导致输出shape都对不上。

我的建议是迁移时别急着保留原框架的抽象层，先把padding参数换算成pads数字，然后跑一两个小shape用例，逐层比对输出shape。这个工作虽然琐碎，但能省下后面排查精度对不上的大量时间。数据format同理，NCHW、NHWC、ND混用是迁移期最容易出问题的地方，一旦数据排布选错，轻则性能下降，重则直接报错。

5.2 精度与数据类型的坑：FP16不是万金油

昇腾AI Core的矩阵计算单元在FP16下效率最高，ops-nn里很多高性能路径默认倾向FP16。但直接一刀切把整个模型切到FP16，容易踩两个雷：一是梯度或中间值溢出，尤其是有大数值范围的归一化或损失计算；二是一些库算子对FP16的精度损失比预想大，导致最终精度验收不通过。

我的做法是先跑一版纯FP32作为基线，再逐步切FP16，同时配合loss scaling和精度对比脚本。如果某个算子在FP32和FP16下结果差异明显，优先检查是否该算子内部有降低精度的中间计算。不要一上来就全模型FP16，更不要因为单算子模式看着没问题，就忽略整图链路里的累积误差。

5.3 动态shape的坑：图模式为什么会"慢如龟"

动态shape在GPU生态里很方便，但到了昇腾上要格外小心。模型输入shape频繁变化，会让算子tiling策略反复调整，甚至触发重新编译。更麻烦的是，图模式下动态shape会限制很多融合优化，因为GE无法在编译期确定张量的具体大小，很多规则不敢轻易应用。结果就是，同一个模型，动态shape版本的推理延迟可能比固定shape版本高一截。

如果业务允许，尽量把输入固定到某个max长度，不足的部分做padding。这不光是为了算子性能，也是为了能充分利用预编译和缓存优化。做LLM推理时，有些团队把序列长度固定成若干档位，每一档一个静态图，效果往往比一个动态图好得多。这个思路在昇腾上尤其值得借鉴。

5.4 一份"照着做"的迁移自查清单

最后给一份我每次做算子迁移都会过的自查清单：

这张表不是万能药，但它能帮你把迁移问题从"玄学"变成"可以逐项排查的清单"。很多看起来诡异的性能问题，最后都能归到表里的一行。

我在实际团队里还留着一个小习惯：接手昇腾优化任务时，先建一张"算子性能基准表"，把模型每个算子在固定shape下的耗时、是否被融合、数据排布都记下来。调优过程中不断更新这张表，比翻任何文档都直接。某次大模型推理优化，我就是靠这张表发现两个本可以融合的算子被中间节点隔开，改了一处数据排布后，p99延迟降低了差不多20%。ops-nn这套东西，说到底是用来"喂"算力给模型的，别把它当字典，要把它当成一个可以反复调整的编排方案。每改一处参数，用profile验证一次，慢慢就能摸清昇腾的脾气了。