AIGC这波浪潮追到现在，模型结构越来越花，但真正决定上线体验的，往往是那些没人愿意多看的算子。前段时间集中做了一轮基于AIGC场景的大模型推理调优，把CANN这类面向AI芯片的统一编程架构，以及它上层的ops-nn算子库从头到尾翻了一遍，踩了不少坑，也总结出一些能直接用在项目里的方法。这篇文章不搞理论堆砌，就把我实际调过的算子、写过的伪代码和排查过的问题整理出来。

1. 为什么AIGC时代必须重新审视CANN与ops-nn

1.1 AIGC模型带来的三重压力

AIGC模型（大语言模型、文生图模型、多模态模型）和过去常见的图像分类模型很不一样。十年前的视觉模型算子是相对规整的，几个卷积加池化再加全连接，计算图几乎是静态的，模型一发出去，shape就固定死了。AIGC模型不一样，尤其是自回归生成式模型，推理时有循环解码过程，每一步都会动态改变序列长度，甚至还会伴随KV Cache管理、beam search这类动态分支。计算量暴增的同时，算子早已不是一个两个，而是成百上千个不同形态的内核，其中小算子又占了相当大的比例。

第一重压力来自内存带宽。AIGC模型里有大量访存密集型算子：激活函数、归一化、残差相加、embedding查表，这些算子本身计算量很低，却频繁地读写参数和中间结果。如果不做算子融合，每跑一次激活就把整个中间张量写回全局内存，再到下一个算子又读回来，带宽很快耗尽。优化AIGC模型时感受很明显，大部分时间都不是花在算数上，而是花在搬数据上。

第二重压力来自动态shape。自回归阶段每个请求的prompt长度不同，生成的token数量也不同，批大小也常常动态变化。如果不按静态图方式编译，每次都要重新推导执行计划；如果按最大shape预留资源，又会有大量算子在空转。传统图像模型几乎没有这种别扭，但AIGC模型把动态shape问题放大了好多倍。

第三重压力来自低精度与量化。为了把大模型塞进有限显存，主流方案都把权重和激活降到低比特。这要求算子库对精度格式处理得非常灵活：BF16、FP16、INT8、INT4怎么混用，scale和zero point怎么传递，反量化在哪里做，饱和截断用哪种策略。一旦某个算子不支持某个精度组合，只能回退到高精度实现，性能立刻崩掉。所以算子库本身的质量，直接决定了量化方案能不能完整落地。

1.2 CANN和ops-nn到底是什么

在展开细节之前，先把概念说清楚。在本文语境里，CANN是面向AI芯片写应用和算子时需要打交道的一层统一编程架构，它负责把上层模型翻译成芯片能执行的指令序列；ops-nn则是这层架构之上，针对神经网络专门沉淀出来的一批算子原语集合。可以理解成“工具箱”和“操作手册”的关系：工具箱里有锤子、扳手、螺丝刀，ops-nn里则有卷积、归一化、注意力、激活这些现成工具；而CANN决定你怎么使用这些工具、怎么把它们高效组装起来。

为什么要设计这样一层中间架构？原因很朴素：不同AI芯片的内部结构千差万别，指令集、存储层次、并行模型都不一样。如果每个算法工程师都直接面向底层寄存器去编程，研发效率会低到无法接受，而且很难保证可移植性。CANN这类统一编程架构的价值，就是把这些差异吸进中间层，向上提供统一接口，向下对接具体硬件。同时，它又把性能关键的细节（数据布局、张量切分、核间同步）暴露给想做深度优化的人。

ops-nn在整个体系里更像一个“标准动作库”。很多模型里的卷积、归一化、激活，都有现成的高性能版本可以调用。这样普通应用开发者不用从零开始造轮子，系统工程师也能在此基础上二次开发，针对特殊场景写自定义算子。两者配合，才构成完整的算子执行体系。

1.3 为什么AIGC从业者也需要看过算子层

很多人会问：算子库不是硬件厂商或者底层系统团队的事吗？我直接用上层框架调用不就行了？我以前也这么想，直到实战中遇到性能问题，才发现不往下看根本排不下去。

举例来说，同一个模型在不同架构上推理速度差几倍，表面上看是硬件算力差异，实际上多数是算子层没有适配好。哪怕是同一块芯片，数据布局不一样、算子融合程度不一样，端到端延迟都能差到一半以上。如果完全不懂算子层，遇到这些问题只能盲猜，然后原地打转。反过来，如果你能看懂ops-nn里的一个算子大概映射到什么计算单元、访存模式是怎样的，很多上层优化会变得非常自然。

这也解释了为什么CANN这类架构里会留出“自定义算子”“算子调优”的开放接口。它的存在并不只为了方便芯片厂商自己写算子，而是希望上层的框架开发者、部署工程师也能参与到算子优化里来。所以，无论你是做模型部署、推理服务压测，还是想做推理框架二次开发，花点时间把CANN和ops-nn的设计逻辑过一遍，性价比非常高。

2. 整体设计思路：从算子库到硬件映射

2.1 软件栈里的位置

我习惯把整个AI软件栈分成五个层次：应用层、图编译与运行时、统一编程架构、算子原语库、芯片驱动与硬件。下面这张表能表达各层的职责：

在这个栈里，AI框架把用户的模型翻译成算子，CANN负责把这些算子排布到芯片上，而ops-nn提供最底层的算子执行版本。算子融合、常量折叠这类优化通常发生在图编译层，但最终落实到硬件，依然要借助ops-nn里的原语。我们平时优化一个模型，往往是从上往下优化，最后都会沉到算子层和数据层。

2.2 原语粒度：为什么不是每个模型动态翻译

可能会有同学问：既然有个统一编程架构，为什么不直接搞一个JIT编译器，每来一个模型现场编译呢？这样还能针对具体shape专门优化。理论上确实更理想，但实际工程里很容易失控。

动态编译路径最大的问题是不确定性。AIGC模型动态shape场景多，如果每次请求长度变化都要重新编译内核，编译耗时可能比执行时间还长，缓存也一直命中不了。再加上算子组合空间极大，编译器不一定能在合理时间内找到最优实现。所以现在更成熟的方案是“静态算子库 + 动态调度”：ops-nn把常见算子的高性能版本预先写好，CANN运行时根据实际shape、数据布局去选择合适的实现，再决定切分和调度策略。

这个设计有点像餐厅的后厨——后厨不会等客人点了菜再去种地，而是提前把常见菜品准备成半成品，客人下订单后再组合加工。ops-nn就是那些半成品，CANN是负责排菜、上菜的大堂经理。模型千变万化，但底层的数学算子就那几百种，提前打磨好，现场组合起来，效率才是最高的。

2.3 硬件映射的关键约束

AI芯片里通常有三类计算部件：标量单元、向量单元、矩阵单元。标量单元擅长处理控制流和单值计算；向量单元适合逐元素运算和规约；矩阵单元则专门对付大矩阵乘法。一个算子落到哪个单元，直接决定性能。比如矩阵乘法放到向量单元去硬算，效率极低；一个逐元素加法放到矩阵单元，反而浪费吞吐。ops-nn在实现算子时，最重要的一件事就是决定“什么算子跑什么单元”。

另一个关键约束是片上存储的容量。芯片的缓存或者SRAM很小，放不下完整的中间大矩阵。于是要把张量切分成一块块适合片上空间的tile，再依次搬运、计算、写回，这个切分动作就是tiling。

我调矩阵乘法时通常按M、N、K三个维度分别设tile大小，让每个tile的计算量刚好能填满片上存储。同时要让数据能够连续计算多步，减少片外访问。tiling太小，调度开销会淹没计算收益；tiling太大，数据放不下，缓存溢出，性能反而更差。具体数值必须结合芯片SRAM大小和矩阵单元规格来定，不能拍脑袋。

3. 核心细节解析与实操要点

3.1 ops-nn里必须熟悉的几类算子

笼统地说，AIGC模型用到的高频算子可以分成几类，每类都有不同的优化侧重点。

第一类是矩阵运算算子，比如矩阵乘法Gemm、批量矩阵乘法。不管是Transformer里的QKV投影、注意力计算还是FFN层，本质都是矩阵乘法。这类算子的性能核心是tiling策略和是否能把计算搬到矩阵单元上。通常我会把注意力放到分块大小和数据复用上，尽量避免在同一个tile里重复读取同一块权重。

第二类是布局与数据移动算子，比如transpose、reshape、concat、split、gather。这类算子很容易被人忽略，因为看起来只是“搬数据”，但在AIGC模型里它们占比不小，而且频繁的物理拷贝非常浪费带宽。优化思路是尽量用视图或步长方式共享内存，能不改布局就不改布局，避免真正执行拷贝。

第三类是归一化与激活算子，包括LayerNorm、RMSNorm、Softmax、ReLU、GELU、SiLU/SwiGLU。它们是典型的访存密集型算子，计算量不高，却要读好几次中间结果。最有效的优化手段就是融合，把归一化、缩放、偏置、激活、残差全部拼到一个内核里。

第四类是注意力相关算子，比如FlashAttention风格的注意力内核、KV Cache管理。优化的本质是融合、分块加上online softmax，避免完整注意力矩阵落地。

第五类是量化相关算子，包括低精度转换、反量化、混合精度计算。AIGC模型几乎都要做量化，模型越大，量化算子的占比越高。这类算子的细节很多，scale怎么乘、zero point怎么减、整型卷积怎么约束范围，都需要在算子层逐一处理。

3.2 布局与内存：最容易踩坑的地方

第一次把模型从训练框架迁移到推理场景时，最容易出问题的地方通常不是算子本身，而是数据布局不匹配。操作得当，模型流畅运行；操作不当，计算图里会莫名多出一堆转置算子，每个转置都在消耗带宽。

布局这个词，通俗讲就是多维数组按照什么顺序摊到线性内存里。比如二维矩阵有行优先和列优先的差异，直接决定矩阵运算的缓存友好性。到高维张量，又有NCHW、NHWC等区分，AIGC模型里还常见shape为“批大小、序列长度、头数、维度”的四维注意力张量。一个习惯某种布局的算子，遇到另一种布局时，CANN可能会自动插入一个排列算子，性能立刻变差。所以在搭建推理服务时，应该在早期就统一整条链的数据布局。

还有一个经常被忽视的点是对齐。硬件搬运数据时，通常要求起始地址对齐到特定字节。如果某个张量维度不满足对齐条件，要么填充padding让数据对齐，要么切分成更小块来规避，这两者都会影响访存效率和执行计划。我在优化时会把每个算子的shape和元素类型拿出来算一遍，确认每个tile的步长都是硬件友好的。

片上内存复用也很重要。AIGC推理的中间结果非常密集，一块原本不大的显存，如果不做生命周期分析，很容易被中间张量塞爆。ops-nn通常会把生命周期不重叠的中间张量复用同一块缓冲区。做算子融合时，我也会把“读一次算多次”和“读多次算一次”的场景分开考虑，前者适合合并计算，后者适合空间复用。

3.3 融合算子的两种套路

算子融合是AIGC优化中最直接见效的手段。我常用的套路有两种。

第一种是以带宽为线索的兄弟融合。把连续作用于同一张量的一串逐元素算子合并成一个内核。比如SiLU激活后面的乘法、残差加法、LayerNorm后的affine变换，它们本质上是对同一份数据做一串变换。如果分开执行，中间结果就要反复写全局内存；合在一起后，整条链只需要读一次原始输入，写一次最终输出。理论目标就是把中间结果的内存访问次数压到最低。

第二种是以计算为线索的重计算融合。典型代表是FlashAttention。标准注意力需要先算QK的乘积，写完整注意力矩阵，再算softmax，再与V相乘，内存占用是序列长度的平方，对长序列非常不友好。融合思路是分块计算，每一个分块内完成局部QK计算，再更新局部softmax状态，再更新输出。这样完整注意力矩阵永远不用落地，复杂度从二次方变成线性，又快又省显存。

下面给一个兄弟融合的伪代码示例，逻辑就是把SiLU激活和乘加合并到一起：

# 分离版本 mid1 = silu(a) mid2 = mid1 * w out = mid2 + bias # 融合版本 def fused_silu_mul_add(a, w, bias): for i in range(total): val = a[i] * w[i] tmp = val / (1 + exp(-val)) out[i] = tmp + bias[i] return out

真实芯片上这段循环会变成并行的向量指令，但是核心逻辑不复杂：中间张量全程留在片上，不写回全局内存。这一点微小的差别，在几十亿元素的大模型里，能省下极高的带宽开销。

不过也不是所有连续算子都适合融合。如果两个算子计算量都很大，且数据复用性不高，硬合在一起可能让片上空间吃紧，并行度反而下降。所以融合前我会先估算：合并后需要多少临时空间，能省多少内存访问，再决定要不要动手。

4. 实操过程：一整套算子优化的步骤

4.1 第一步：用profile工具找到热点

优化第一件事不是写代码，而是测量。我在AIGC推理服务上做优化，一般会抓两轮数据：第一轮看算子级耗时排行，第二轮看内存访问量统计。

算子级耗时排行榜通常直接输出每个算子平均执行时间和占比。内存访问量统计主要看全局内存读写字节数，因为AIGC模型经常出现“计算占比很低但带宽已经耗尽”的情况。

有一次优化一个文生图模型的推理流程，发现LayerNorm算子明明计算量不大，却排进了耗时前五。一开始很疑惑，后来看内存统计才明白，模型在每个Block里反复做“输入+残差→归一化→非线性激活→进下一层”，中间结果在全局内存被反复写读，几十个Block叠加起来，带宽压力巨大。这就是典型的访存密集加算子碎片化问题。

4.2 第二步：按热点算子写高性能版本

定位到热点之后，我决定把“残差+归一化+SiLU+乘法”整条链路合进一个算子。设计思路看起来简单，但实际实现有很多细节。

输入是当前层特征x和残差r，第一步先算y=x+r，然后对y做归一化。归一化需要先在channel维度上求均值和方差，这个统计量通常很小，可以留在片上。第一遍循环用来算mean和var，第二遍再进行归一化、缩放、偏置和激活。下面是精简后的逻辑示意：

def fused_residual_groupnorm_silu_mul(x, res, gamma, beta, eps): N, C, H, W = x.shape for c in range(C): mean = 0 for idx in range(N * H * W): val = x[idx, c] + res[idx, c] mean += val mean /= N * H * W var = 0 for idx in range(N * H * W): val = x[idx, c] + res[idx, c] var += (val - mean) ** 2 var /= N * H * W for idx in range(N * H * W): val = x[idx, c] + res[idx, c] norm = (val - mean) / sqrt(var + eps) out[idx, c] = silu(norm * gamma[c] + beta[c]) return out

实际写到芯片上时，要用多核并行，把channel分给不同核心处理，核心内部再对HW做向量化循环。还要让mean、var这种小量留在寄存器或局部缓存中，不要动不动就搬全局内存。需要注意的一点是，两遍循环里都重复读了x和res，如果计算单元的临时存储足够，可以把每个tile的数据先加载到片上再做两遍计算，避免从全局内存读两遍。

这样的融合算子设计听起来不难，但真正坑人的是在边界条件上。比如channel数为0怎么办，方差出现负的浮点误差怎么办，归一化后数据分布极度偏离时精度怎么保证。这些问题不提前想清楚，跑起来会有一堆莫名其妙的NaN。

4.3 第三步：验证正确性与收益

算子改完之后，我必做两件事。第一是数值验证，用同一个随机输入，在参考实现和融合实现上各跑一遍，计算逐元素误差。对FP16模型，我一般要求相对误差在1e-2到1e-3量级，且不能出现明显的离群值。如果出现NaN或inf，优先检查归一化里的方差和epsilon，多数情况下把epsilon调大一点能稳定不少。

第二是性能收益确认。优化后的算子耗时、端到端推理延迟、显存峰值占用都要记录。这里贴一个我实际调过但数据脱敏后的对比：

表格只是示例，每个场景数字都会不同，但这个对比方法很值得保留。因为只有把收益量化下来，才知道哪个优化动作性价比最高，也为后续调优积累了基线。

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

5.1 从“能跑”到“跑得快”的问题清单

做算子优化时有一个错觉：只要算子能跑通，性能自然没问题。实际上很多性能问题都是隐性的，我整理了一张常见问题清单：

这些问题的共同点在于，都不是通过看理论峰值能发现的，必须靠实际profile数据来定位。不要盲目相信“这个算子计算密度够高”，AIGC模型里的瓶颈往往在数据移动。

5.2 容易被忽视的三个细节

第一，不要被FLOPs迷惑。一个算子的计算量只要很可观，就很容易让人忽略它的访存代价。我有一段时间优化矩阵乘法，一直盯着矩阵单元利用率，结果瓶颈卡在输入数据搬运上。后来改成“让一个tile加载的数据能被多次复用”的策略，收益立刻翻倍。这就是常说的：算得快不如搬得少。

第二，调参时要一次只动一个变量。算子优化牵涉tile大小、并行度、数据布局、指令调度等一堆参数。如果同时改三个变量，出了问题根本无法定位是谁导致的。我用脚本批量跑参数组合，每次只改一个维度，把结果记录成表格，再通过对比找规律。这种方法很土，但非常有用。

第三，正确性校验要覆盖边界shape和精度类型。很多算子在小shape下没问题，到了大shape下并行边界处理出错；或者在FP16下正常，BF16下数值漂移。我通常准备一组常规shape、最大shape、最小shape以及多精度测试用例，每次改动后一键回归。AIGC模型里shape变化范围大，尤其要重视这一点。

5.3 调优过程中的实操建议

最后整理几条工程习惯：写自定义算子时，先写CPU参考算子，再写设备端版本，两边输出一致再谈优化。日志等级设成错误、警告、信息三档，优化过程中把每个关键阶段的耗时和误差打印出来。不要小看这些看似普通的做法，它们能帮你少走很多弯路。

工具链方面，不用追求一次把所有性能分析工具都学会。我会优先把三个指标弄明白：算子平均耗时、内存访问量、并行单元利用率。拿到这三个数，再决定是融合算子还是改布局还是调tiling，方向基本不会跑偏。在CANN这类架构上调试时，也尽量先用自带的示例程序跑通，再修改自己的算子，环境问题最少。

我个人最大的体会是，算子优化更像是一门“数据流动”的功课，而不是纯计算优化。AIGC模型的算力需求固然高，但绝大多数可观的性能提升，都来自让数据尽量少搬、让中间结果尽量留在片上、让每个计算单元的利用率尽量高。把CANN和ops-nn当成一套工程系统来用，别把它当黑盒，很多问题会迎刃而解。

踩过几次坑之后，我的流程已经固定下来：先profile，再画数据流图，算带宽需求，最后才动手改算子。如果你正被某个AIGC模型的推理性能卡住，不妨也按这个顺序走一遍，多半能找到比预期更明显的提升空间。