基于 CANN ops-nn 神经网络算子库的昇腾NPU深度学习算子开发实战指南

前言

在异构计算领域，华为昇腾NPU凭借强大的矩阵运算能力和高带宽片上存储，已经成为国产AI推理与训练的重要硬件基座。而在昇腾生态中，CANN（Compute Architecture for Neural Networks）作为连接上层框架与底层硬件的核心软件栈，承担着算子编译、图优化、任务调度等关键职责。ops-nn正是CANN算子生态中专注于神经网络领域的基础算子库，它提供了卷积、池化、激活函数、归一化、损失函数等深度学习核心算子的Ascend C实现，是开发者构建自定义模型和优化推理性能的必备工具。

本文将从实战角度出发，带领读者深入ops-nn的架构设计与使用方法。不同于官方文档的概览式介绍，本文聚焦于"怎么用"和"为什么这样用"，通过完整的代码示例和对比分析，帮助开发者快速掌握ops-nn的核心能力。无论你是正在将模型迁移到Atlas A2训练服务器上，还是在Ascend 950推理卡上优化端侧部署，ops-nn都将成为你绕不开的关键组件。理解ops-nn的设计理念和实现细节，不仅有助于正确使用现有算子，更为开发自定义算子提供了经过验证的参考范式。

ops-nn 在 CANN 算子生态中的定位

CANN的算子生态按照功能域划分为多个独立仓库，ops-nn与ops-math、ops-cv等并列，共同构成了CANN完整算子生态。这种按功能域拆分的组织方式有几个显著优势：每个仓库可以独立迭代和发布，不同功能域的算子可以由不同的团队并行开发，开发者只需关注自己所需的功能域而不必拉取全部代码。具体来说：

• ops-math：数学运算类算子，如矩阵乘法、向量点积、三角函数、归约运算等，是其他算子库的基础依赖
• ops-cv：计算机视觉类算子，如图像缩放、色彩转换、仿射变换、光流计算等，服务于视觉预处理和后处理场景
• ops-nn：神经网络类算子，即本文的主角，覆盖深度学习中最核心的计算原语

ops-nn内部的算子按照功能类别组织，主要包含以下几个大类：

每个算子均遵循CANN统一算子开发规范，采用Ascend C语言实现，支持动态shape输入，兼容Atlas A2、Atlas A3训练系列和Ascend 950推理系列硬件平台。动态shape支持意味着同一个算子可以处理不同尺寸的输入而无需重新编译，这对于需要处理可变长度序列的自然语言处理模型尤为重要。

算子开发规范与工程结构

ops-nn中的每个算子遵循CANN统一的工程结构规范。理解这个结构是阅读源码和开发自定义算子的前提。一个典型算子的目录布局如下：

ops-nn/ ├── op_kernel/ │ ├── conv2d/ │ │ ├── conv2d_tiling.h # Tiling数据结构定义 │ │ ├── conv2d_tiling.cpp # Tiling计算逻辑 │ │ ├── conv2d.cpp # 算子kernel实现 │ │ └── conv2d_registry.cpp # 算子注册 │ ├── max_pool/ │ └── ... ├── op_host/ │ ├── conv2d/ │ │ ├── conv2d_tiling.h │ │ ├── conv2d_tiling.cpp │ │ └── conv2d.cpp # Host侧tiling与校验 │ └── ... ├── op_plugin/ │ └── ... # 框架适配层 └── build.sh

这个结构将Host侧逻辑（tiling计算、参数校验）和Device侧逻辑（kernel实现）分离，是CANN算子开发的核心设计模式。Host侧在CPU上运行，负责根据输入shape计算tiling参数，决定数据如何分块送到AI Core上执行；Device侧在NPU的AI Core上运行，负责实际的并行计算。op_plugin目录则提供了与PyTorch、MindSpore等框架的适配代码，使得算子可以被上层框架直接调用。

Tiling机制详解

Tiling是昇腾算子开发中最重要的概念之一。由于AI Core的Unified Buffer容量有限（通常为数百KB到数MB），无法一次性容纳大规模的输入数据，因此需要将计算任务切分为多个小块（tile），逐块搬入Unified Buffer计算后再搬出。这个过程就是Tiling。

Tiling策略的好坏直接影响算子执行效率。切分粒度过大可能导致Unified Buffer溢出，切分粒度过小则增加数据搬运次数，降低计算占比。ops-nn中的算子实现都包含了经过优化的Tiling策略，开发者可以参考这些策略来设计自己的算子。一个好的Tiling策略需要在数据搬运量和计算密度之间找到平衡点，使得AI Core上的计算单元和搬运通道都能得到充分利用。

下面以Conv2D算子为例，展示其Tiling数据结构的定义方式：

// WHY: Tiling结构体需要在Host和Device之间共享，// Host侧填充参数，Device侧读取参数来指导数据搬运和计算分块。// 必须使用ALIGN_TO保证内存对齐，否则Device侧读取会触发对齐异常。structConv2dTilingData{uint32_tbatchDim=0;// batch维度切分数量uint32_tfeatureDim=0;// 特征图通道维度切分数量uint32_theightDim=0;// 高度维度切分数量uint32_twidthDim=0;// 宽度维度切分数量uint32_tkernelH=0;// 卷积核高度uint32_tkernelW=0;// 卷积核宽度uint32_tstrideH=0;// 步长高度uint32_tstrideW=0;// 步长宽度uint32_tpadH=0;// 高度方向填充uint32_tpadW=0;// 宽度方向填充uint32_tdilationH=0;// 高度方向膨胀uint32_tdilationW=0;// 宽度方向膨胀uint32_toutputH=0;// 输出高度uint32_toutputW=0;// 输出宽度}__attribute__((aligned(32)));// 32字节对齐

从上面的代码可以看到，TilingData包含了卷积运算的所有关键参数。batchDim、featureDim、heightDim、widthDim这四个字段定义了在四个维度上的切分方式，而kernelH、strideH、padH等字段则是卷积运算本身的参数，Device侧需要这些信息来正确执行im2col变换和矩阵乘法。

从零开始：使用 Conv2D 算子

Conv2D是深度学习中最核心的算子之一，也是ops-nn中实现复杂度最高的算子。它同时涉及im2col变换、矩阵乘法和数据重排，对Tiling策略的要求非常苛刻。本节通过一个完整的使用示例，展示如何在Atlas A2平台上调用ops-nn中的Conv2D算子。

Host侧Tiling实现

Host侧的主要职责是根据输入tensor的shape、数据类型以及硬件参数，计算出合理的Tiling参数，并将这些参数序列化为TilingData传递给Device侧。Tiling计算的核心逻辑是：根据Unified Buffer容量和单行数据的开销，推导出每个tile能容纳的最大行数，进而确定各维度的切分因子。

// WHY: Host侧Tiling函数在CPU上执行，需要根据输入shape动态计算切分策略。// 不同shape需要不同的切分方案，这正是ops-nn支持动态shape的关键所在。// 如果Tiling参数不合理，Device侧可能触发Unified Buffer溢出或计算结果错误。ge::graphStatusConv2dTilingFunc(gert::TilingContext*context){// 获取输入tensor的shape信息autoxShape=context->GetInputTensor(0)->GetStorageShape();autowShape=context->GetInputTensor(1)->GetStorageShape();uint32_tbatchSize=xShape.GetDim(0);uint32_tinChannels=xShape.GetDim(1);uint32_theight=xShape.GetDim(2);uint32_twidth=xShape.GetDim(3);uint32_toutChannels=wShape.GetDim(0);uint32_tkernelH=wShape.GetDim(2);uint32_tkernelW=wShape.GetDim(3);// 从平台信息获取Unified Buffer容量autoplatformInfo=context->GetPlatformInfo();uint32_tubSize=platformInfo->GetUnifiedBufferSize();// 基于UB容量和输入规模计算切分因子Conv2dTilingData tilingData;tilingData.kernelH=kernelH;tilingData.kernelW=kernelW;tilingData.strideH=1;tilingData.strideW=1;tilingData.padH=0;tilingData.padW=0;tilingData.dilationH=1;tilingData.dilationW=1;tilingData.outputH=(height+2*tilingData.padH-kernelH)/tilingData.strideH+1;tilingData.outputW=(width+2*tilingData.padW-kernelW)/tilingData.strideW+1;// 计算每个tile能容纳的最大行数uint32_telementSize=sizeof(float);uint32_tinputLineSize=inChannels*kernelH*kernelW*elementSize;uint32_toutputLineSize=outChannels*elementSize;uint32_tlineSize=inputLineSize+outputLineSize;uint32_tmaxLinesPerTile=ubSize/lineSize;if(maxLinesPerTile<1){maxLinesPerTile=1;// 至少处理一行}// 分配切分维度tilingData.heightDim=(tilingData.outputH+maxLinesPerTile-1)/maxLinesPerTile;tilingData.batchDim=batchSize;tilingData.featureDim=1;tilingData.widthDim=1;// 将TilingData写入contexttilingData.SaveToBuffer(context->GetRawTilingData(),context->GetCalculatedTilingDataSize());context->SetTilingKey(0);returnge::GRAPH_SUCCESS;}

这段代码展示了Tiling计算的基本逻辑。首先获取输入和权重的shape信息，然后从平台信息中读取Unified Buffer容量，接着根据这些信息计算每个tile能容纳的最大行数，最后确定各维度的切分因子。需要特别注意的是，当输入规模较大导致单行数据就超过Unified Buffer容量时，需要进一步在通道维度上进行切分，这种场景下的Tiling策略会更加复杂，ops-nn的完整实现中对此有详细的处理逻辑。

Device侧Kernel实现

Device侧的Kernel运行在AI Core上，负责从Global Memory中按Tiling参数搬运数据到Unified Buffer，执行计算后将结果搬回Global Memory。ops-nn的Conv2D实现利用了Cube单元（矩阵乘法引擎）和Vector单元（向量运算引擎）的协同工作。Cube单元负责高吞吐的矩阵乘法运算，Vector单元负责im2col数据重排和逐元素运算。

// WHY: Device侧Kernel需要在AI Core上高效执行，// 使用Ascend C的DataCopy进行异步数据搬运可以隐藏访存延迟，// 使数据搬运与计算重叠，这是昇腾NPU性能优化的核心手段。// 同步等待（pipe_barrier）只在必须保证数据一致性时才使用。classConv2DKernel{public:__aicore__inlinevoidInit(gm::uint8_t*x,gm::uint8_t*w,gm::uint8_t*y,constConv2dTilingData*tilingData){xGm.SetGlobalBuffer((__gm__float*)x);wGm.SetGlobalBuffer((__gm__float*)w);yGm.SetGlobalBuffer((__gm__float*)y);heightDim_=tilingData->heightDim;outputH_=tilingData->outputH;outputW_=tilingData->outputW;kernelH_=tilingData->kernelH;kernelW_=tilingData->kernelW;strideH_=tilingData->strideH;strideW_=tilingData->strideW;}__aicore__inlinevoidProcess(){// 按Tiling切分逐块处理for(uint32_tb=0;b<heightDim_;b++){Compute(b);}}private:__aicore__inlinevoidCompute(uint32_tblockIdx){// 将当前tile的输入数据从Global Memory搬入Local MemoryLocalTensor<float>xLocal=xBuf.Get<float>();LocalTensor<float>wLocal=wBuf.Get<float>();LocalTensor<float>yLocal=yBuf.Get<float>();uint32_trowsPerTile=(outputH_+heightDim_-1)/heightDim_;uint32_tstartRow=blockIdx*rowsPerTile;uint32_tendRow=(startRow+rowsPerTile>outputH_)?outputH_:startRow+rowsPerTile;uint32_tactualRows=endRow-startRow;// 异步搬运输入数据DataCopy(xLocal,xGm[startRow*outputW_],actualRows*outputW_);DataCopy(wLocal,wGm[0],kernelH_*kernelW_);// 等待数据搬运完成pipe_barrier(PIPE_ALL);// 执行卷积计算（im2col + 矩阵乘法）// im2col: 将输入的局部区域展开为矩阵列// matmul: 利用Cube单元执行矩阵乘法// ... 实际计算逻辑省略，此处为示意框架 ...// 异步搬运输出结果到Global MemoryDataCopy(yGm[startRow*outputW_],yLocal,actualRows*outputW_);pipe_barrier(PIPE_ALL);}private:TPipe pipe;TBuf<QuePosition::VectorIn>xBuf;TBuf<QuePosition::VectorIn>wBuf;TBuf<QuePosition::VecOut>yBuf;GlobalTensor<float>xGm;GlobalTensor<float>wGm;GlobalTensor<float>yGm;uint32_theightDim_=0;uint32_toutputH_=0;uint32_toutputW_=0;uint32_tkernelH_=0;uint32_tkernelW_=0;uint32_tstrideH_=1;uint32_tstrideW_=1;};

在这段代码中，有几个值得关注的实现细节。首先是DataCopy的使用：它是一种异步操作，调用后立即返回而不等待搬运完成，这样可以实现数据搬运与计算的重叠。其次是pipe_barrier的调用位置：它只在需要保证数据一致性时才使用，过多的同步等待会破坏流水线并行性。最后是LocalTensor的获取方式：通过TBuf模板类管理Local Memory，可以避免手动管理内存偏移带来的错误风险。

Activation 算子族的实现与选择

激活函数是神经网络中引入非线性的关键组件。ops-nn提供了丰富的激活算子族，从经典的ReLU到现代大模型广泛使用的GELU和Swish。不同激活函数在计算复杂度和数值特性上差异显著，选择合适的激活函数对模型性能和推理速度都有实际影响。

ReLU族

ReLU及其变体是最常用的激活函数族。ops-nn中实现了ReLU、LeakyReLU、PReLU、ReLU6等变体。ReLU的计算逻辑极其简单——将负值截断为零，这使得它在硬件上非常高效，几乎不占计算时间。但ReLU存在"神经元死亡"问题：当输入持续为负时，梯度恒为零，神经元永久失效。LeakyReLU通过给负区间引入一个小的斜率来缓解这个问题，在Ascend C实现中，LeakyReLU可以用一条Vector指令（Relu+Scale组合）完成，开销与ReLU几乎相同。PReLU则将负区间的斜率作为可学习参数，需要在反向传播中额外计算梯度，实现复杂度略高。

ReLU6是ReLU的截断版本，将输出限制在零到六之间，在移动端量化场景中广泛使用。固定范围的输出使得量化参数更容易确定，有利于INT8量化后的精度保持。

GELU与Swish

GELU（Gaussian Error Linear Unit）和Swish是近年来越来越受欢迎的激活函数，尤其是在Transformer架构中被广泛使用。GELU的数学表达式为：

GELU(x) = x * Φ(x)

其中Φ(x)是标准正态分布的累积分布函数。精确计算需要误差函数erf，开销较大，因此在实际部署中通常使用Tanh近似：

GELU(x) ≈ 0.5 * x * (1 + tanh(sqrt(2/π) * (x + 0.044715 * x³)))

ops-nn的GELU实现提供了精确模式和近似模式两种选择，开发者可以根据精度需求灵活切换。在大多数推理场景中，近似模式的精度差异在千分之一以内，完全可以接受。而在某些对数值精度极度敏感的训练场景中，精确模式仍然有其价值。

Swish函数的形式为：

Swish(x) = x * sigmoid(βx)

当β=1时，Swish与GELU的形状非常接近。在Ascend C实现中，Swish的计算需要一次sigmoid运算和一次逐元素乘法，计算开销介于ReLU和GELU之间。HardSwish是Swish的分段线性近似，在移动端部署中更为常用，ops-nn同样提供了HardSwish的实现。

激活算子选型考量

在实际项目中，激活函数的选择需要平衡三个维度：模型精度、计算开销和数值稳定性。ReLU计算最快，但可能导致信息丢失；GELU精度最优，但计算代价高；Swish是折中选择。在昇腾NPU上，由于Cube单元不参与激活计算，激活函数完全由Vector单元执行，因此激活函数的选择直接影响Vector单元的利用率，进而影响整体流水线的执行效率。

当模型中激活函数占比很高时（例如轻量级CNN中大量使用ReLU），选择计算更轻量的激活函数可以显著降低Vector单元的占用时间，使得Cube单元（卷积计算）和Vector单元（激活计算）的流水线更加均衡。反之，如果激活函数的计算远快于卷积计算，那么即使换成更复杂的激活函数也不会成为性能瓶颈，此时应该优先考虑模型精度。

Normalization 算子的关键实现细节

归一化算子是现代深度学习训练中不可或缺的组件。ops-nn中实现了BatchNorm、LayerNorm和GroupNorm三种主流归一化算子，它们在计算方式和适用场景上各有侧重。归一化算子的共同特征是涉及统计量计算（均值和方差），需要跨多个数据元素做规约操作，这在昇腾NPU上的实现有其独特的挑战。

BatchNorm

BatchNorm沿batch维度计算均值和方差，在训练阶段使用当前batch的统计量，在推理阶段使用训练时累积的全局统计量。这种训练/推理行为差异是BatchNorm实现中的一个关键细节。在ops-nn的实现中，训练模式和推理模式分别对应不同的kernel实现路径：

• 训练模式：需要计算当前batch的均值和方差，并更新移动平均统计量。涉及两次全局规约操作（求和、求平方和），计算量较大。移动平均的更新采用指数滑动平均，衰减系数通常设为零点一。
• 推理模式：直接使用预存的均值和方差进行归一化，无需规约操作，计算量显著降低。推理模式下BatchNorm可以与前一层的卷积算子融合，将归一化参数吸收到卷积权重中，从而完全消除BatchNorm的计算开销。

BatchNorm的一个实现难点是：在训练模式下，均值和方差的计算需要跨整个batch做规约，这意味着所有AI Core需要协同完成统计量计算。ops-nn利用了昇腾NPU的Cross Core通信机制来实现多Core间的规约操作，通过树形规约算法将通信轮次从线性降低到对数级。

LayerNorm

LayerNorm沿特征维度计算均值和方差，与batch大小无关，因此在batch较小时比BatchNorm更稳定，也是Transformer架构中的标配归一化方式。ops-nn的LayerNorm实现中，均值和方差的计算在同一趟遍历中完成（Welford算法），避免了两次全局访存。

Welford算法的核心思想是维护一个在线更新的均值和方差估计，每处理一个新数据点就更新当前的统计量。这种单趟算法比传统的两趟算法（先求均值再求方差）更适合昇腾NPU的流式计算模式，因为它只需要遍历一次数据，减少了Global Memory的访问次数。

LayerNorm的另一个实现细节是权重和偏置的可学习参数。归一化后的数据需要经过仿射变换（乘以gamma，加上beta），这两个参数是模型训练过程中学习的。在ops-nn的LayerNorm实现中，仿射变换与归一化计算融合在同一个kernel中，中间结果不需要写回Global Memory。

GroupNorm

GroupNorm将通道分组后归一化，是BatchNorm和LayerNorm的折中方案，在目标检测和图像分割等batch受限场景中表现出色。ops-nn的GroupNorm实现需要处理分组与通道维度的映射关系，Tiling策略需要同时考虑空间维度和通道维度的切分。

GroupNorm的分组数量是一个重要的超参数。当分组数为一时，GroupNorm退化为LayerNorm；当分组数等于通道数时，GroupNorm退化为InstanceNorm。ops-nn的GroupNorm实现可以处理任意的分组数，Tiling策略会根据分组数自动调整切分方式。

归一化算子的精度陷阱

在FP16精度下，归一化算子容易出现数值问题。方差计算中的平方和操作会放大FP16的舍入误差，尤其在特征维度较大时，可能导致方差为零或负数，进而引发除零错误。ops-nn的实现中采用了以下策略来规避这个问题：

• 方差计算在FP32精度下进行，最后再转回目标精度。昇腾NPU的Vector单元支持混合精度运算，可以在FP16输入上执行FP32计算，无需显式的精度转换。
• 添加小的epsilon值防止除零，默认值通常为1e-5。
• 使用Welford在线算法代替两趟计算，减少数值波动。Welford算法在数值稳定性上优于两趟算法，特别是在处理大数值范围的数据时。

这些实现细节在官方文档中往往一笔带过，但在实际部署中却是决定模型能否稳定运行的关键因素。笔者在实际项目中曾多次遇到FP16精度下BatchNorm输出NaN的问题，最终都是通过将方差计算提升到FP32精度来解决的。

Pool 算子族的切分策略

池化算子是特征降维的核心手段。ops-nn中实现了MaxPool、AvgPool和AdaptiveAvgPool等池化算子。与卷积算子不同，池化算子的计算密度较低（不需要矩阵乘法），属于访存密集型算子，其性能瓶颈在于数据搬运而非计算本身。

MaxPool的实现要点

MaxPool需要在每个池化窗口内找到最大值。在Ascend C实现中，利用Vector单元的ReduceMax指令可以高效完成窗口内的最大值计算。关键挑战在于Tiling策略：池化窗口可能跨越多个tile的边界，需要处理跨tile的数据依赖。

ops-nn的MaxPool实现采用了"冗余搬运"策略：当池化窗口跨越tile边界时，将重叠区域的数据也搬入当前tile的Local Memory，避免跨tile的数据依赖。这种方式虽然增加了少量的冗余数据搬运，但消除了tile间的同步开销，在大多数场景下是更优的选择。冗余搬运的额外开销取决于池化核大小和步长的比例关系——核越大、步长越小，重叠区域占比越高，冗余搬运的开销也越大。

AvgPool的实现特点

AvgPool与MaxPool的计算模式类似，区别在于将窗口内的最大值替换为均值。在Ascend C实现中，AvgPool可以使用Vector单元的ReduceSum指令来计算窗口内的总和，然后除以窗口元素数量得到均值。

AvgPool的一个实现细节是：当使用padding时，padding区域不应计入均值的分母。ops-nn的AvgPool实现提供了两种模式——count_include_pad和count_exclude_pad，分别控制是否将padding区域纳入均值计算。这个细节在模型迁移时经常被忽略，但可能导致精度差异。

AdaptiveAvgPool的特殊之处

AdaptiveAvgPool与普通AvgPool的区别在于：AdaptiveAvgPool指定输出尺寸而非池化核大小，池化核的大小由输入尺寸和输出尺寸动态计算。这意味着不同空间位置的池化窗口大小和步长可能不同，无法使用统一的Tiling策略。

ops-nn的AdaptiveAvgPool实现通过在Host侧预先计算每个输出位置对应的输入区间，将区间信息编码到TilingData中传递给Device侧。Device侧根据这些区间信息逐位置搬运数据并计算均值，虽然代码复杂度更高，但保证了任意输入输出尺寸组合下的正确性。

AdaptiveAvgPool在目标检测的ROI Pooling和语义分割的全局平均池化中广泛使用。特别是当输入尺寸不固定时（例如不同分辨率的图像），AdaptiveAvgPool能够自动适配，避免了手动计算池化参数的麻烦。

Loss 算子的梯度融合优化

损失函数算子位于计算图的末端，其实现效率直接影响反向传播的启动延迟。ops-nn中实现了CrossEntropy、NLLLoss和MSELoss等常用损失函数。

CrossEntropy的实现

CrossEntropy是分类任务中最常用的损失函数，其计算过程可以分解为三个步骤：

• 对logits做Softmax归一化，得到概率分布
• 对概率分布取对数，得到log概率
• 根据标签选取对应位置的log概率，取负值

在朴素实现中，这三个步骤分别对应三次kernel启动，引入两次中间结果的Global Memory写入和读取。ops-nn的CrossEntropy实现将

工程实践中的性能调优要点

在实际部署 ops-nn 算子时，有几个性能调优要点值得特别关注。

Tiling 策略是影响算子性能的第一要素。昇腾 NPU 的 Cube 单元和 Vector 单元都有固定的数据处理宽度，Tiling 参数决定了每次送入计算单元的数据块大小。如果 Tiling 不合理，会导致片上缓存利用率低、数据搬运次数增多，直接影响算子执行效率。CANN 提供了自动 Tiling 机制，大多数情况下可以自动选择较优的 Tiling 参数。但对于非标准 shape（如非对齐的通道数或空间维度），自动 Tiling 可能不够精确，此时需要通过 op_tiling 工具手动指定 Tiling 参数。

内存排布（Data Format）是第二个需要关注的要素。昇腾 NPU 上最常用的内存排布是 5D 格式（NCHW 到 NC1HWC0），其中 C0 等于 16，表示 Cube 单元一次处理的元素数。使用 5D 格式可以让 Cube 单元连续读取数据，提高缓存命中率。ops-nn 的算子内部已经默认使用 5D 格式，但如果输入数据是 NCHW 格式，需要先做格式转换，这个转换本身也有开销。建议在模型构图阶段就统一使用 5D 格式，避免运行时的格式转换开销。

算子融合是第三个重要的优化手段。CANN 的 GE（Graph Engine）支持自动融合相邻的算子，比如 Conv+BN+ReLU 可以融合成一个算子执行，省去中间结果的显存读写。ops-nn 的算子已经支持与常见的后处理算子（如 ReLU、Add）融合，但融合规则需要在模型编译时通过配置文件指定。

仓库地址：https://atomgit.com/cann/ops-nn