前言在异构计算领域华为昇腾NPU凭借强大的矩阵运算能力和高带宽片上存储已经成为国产AI推理与训练的重要硬件基座。而在昇腾生态中CANNCompute 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内部的算子按照功能类别组织主要包含以下几个大类类别代表算子典型应用场景ConvConv2D, Conv3D, ConvTranspose, DepthwiseConv2D图像特征提取、语义分割、目标检测PoolMaxPool, AvgPool, AdaptiveAvgPool, MaxPoolWithArgmax特征降维、全局聚合、检测头ActivationReLU, Sigmoid, GELU, Swish, HardSwish, PReLU非线性变换、门控机制、注意力权重NormalizationBatchNorm, LayerNorm, GroupNorm, InstanceNorm训练稳定性、特征归一化、风格迁移LossCrossEntropy, NLLLoss, MSELoss, SmoothL1Loss模型训练目标函数、回归损失PaddingPad, ReflectionPad, ReplicationPad, ZeroPad特征图尺寸调整、边缘处理每个算子均遵循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_tbatchDim0;// batch维度切分数量uint32_tfeatureDim0;// 特征图通道维度切分数量uint32_theightDim0;// 高度维度切分数量uint32_twidthDim0;// 宽度维度切分数量uint32_tkernelH0;// 卷积核高度uint32_tkernelW0;// 卷积核宽度uint32_tstrideH0;// 步长高度uint32_tstrideW0;// 步长宽度uint32_tpadH0;// 高度方向填充uint32_tpadW0;// 宽度方向填充uint32_tdilationH0;// 高度方向膨胀uint32_tdilationW0;// 宽度方向膨胀uint32_toutputH0;// 输出高度uint32_toutputW0;// 输出宽度}__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信息autoxShapecontext-GetInputTensor(0)-GetStorageShape();autowShapecontext-GetInputTensor(1)-GetStorageShape();uint32_tbatchSizexShape.GetDim(0);uint32_tinChannelsxShape.GetDim(1);uint32_theightxShape.GetDim(2);uint32_twidthxShape.GetDim(3);uint32_toutChannelswShape.GetDim(0);uint32_tkernelHwShape.GetDim(2);uint32_tkernelWwShape.GetDim(3);// 从平台信息获取Unified Buffer容量autoplatformInfocontext-GetPlatformInfo();uint32_tubSizeplatformInfo-GetUnifiedBufferSize();// 基于UB容量和输入规模计算切分因子Conv2dTilingData tilingData;tilingData.kernelHkernelH;tilingData.kernelWkernelW;tilingData.strideH1;tilingData.strideW1;tilingData.padH0;tilingData.padW0;tilingData.dilationH1;tilingData.dilationW1;tilingData.outputH(height2*tilingData.padH-kernelH)/tilingData.strideH1;tilingData.outputW(width2*tilingData.padW-kernelW)/tilingData.strideW1;// 计算每个tile能容纳的最大行数uint32_telementSizesizeof(float);uint32_tinputLineSizeinChannels*kernelH*kernelW*elementSize;uint32_toutputLineSizeoutChannels*elementSize;uint32_tlineSizeinputLineSizeoutputLineSize;uint32_tmaxLinesPerTileubSize/lineSize;if(maxLinesPerTile1){maxLinesPerTile1;// 至少处理一行}// 分配切分维度tilingData.heightDim(tilingData.outputHmaxLinesPerTile-1)/maxLinesPerTile;tilingData.batchDimbatchSize;tilingData.featureDim1;tilingData.widthDim1;// 将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_tb0;bheightDim_;b){Compute(b);}}private:__aicore__inlinevoidCompute(uint32_tblockIdx){// 将当前tile的输入数据从Global Memory搬入Local MemoryLocalTensorfloatxLocalxBuf.Getfloat();LocalTensorfloatwLocalwBuf.Getfloat();LocalTensorfloatyLocalyBuf.Getfloat();uint32_trowsPerTile(outputH_heightDim_-1)/heightDim_;uint32_tstartRowblockIdx*rowsPerTile;uint32_tendRow(startRowrowsPerTileoutputH_)?outputH_:startRowrowsPerTile;uint32_tactualRowsendRow-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;TBufQuePosition::VectorInxBuf;TBufQuePosition::VectorInwBuf;TBufQuePosition::VecOutyBuf;GlobalTensorfloatxGm;GlobalTensorfloatwGm;GlobalTensorfloatyGm;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指令ReluScale组合完成开销与ReLU几乎相同。PReLU则将负区间的斜率作为可学习参数需要在反向传播中额外计算梯度实现复杂度略高。ReLU6是ReLU的截断版本将输出限制在零到六之间在移动端量化场景中广泛使用。固定范围的输出使得量化参数更容易确定有利于INT8量化后的精度保持。GELU与SwishGELUGaussian 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上的实现有其独特的挑战。BatchNormBatchNorm沿batch维度计算均值和方差在训练阶段使用当前batch的统计量在推理阶段使用训练时累积的全局统计量。这种训练/推理行为差异是BatchNorm实现中的一个关键细节。在ops-nn的实现中训练模式和推理模式分别对应不同的kernel实现路径训练模式需要计算当前batch的均值和方差并更新移动平均统计量。涉及两次全局规约操作求和、求平方和计算量较大。移动平均的更新采用指数滑动平均衰减系数通常设为零点一。推理模式直接使用预存的均值和方差进行归一化无需规约操作计算量显著降低。推理模式下BatchNorm可以与前一层的卷积算子融合将归一化参数吸收到卷积权重中从而完全消除BatchNorm的计算开销。BatchNorm的一个实现难点是在训练模式下均值和方差的计算需要跨整个batch做规约这意味着所有AI Core需要协同完成统计量计算。ops-nn利用了昇腾NPU的Cross Core通信机制来实现多Core间的规约操作通过树形规约算法将通信轮次从线性降低到对数级。LayerNormLayerNorm沿特征维度计算均值和方差与batch大小无关因此在batch较小时比BatchNorm更稳定也是Transformer架构中的标配归一化方式。ops-nn的LayerNorm实现中均值和方差的计算在同一趟遍历中完成Welford算法避免了两次全局访存。Welford算法的核心思想是维护一个在线更新的均值和方差估计每处理一个新数据点就更新当前的统计量。这种单趟算法比传统的两趟算法先求均值再求方差更适合昇腾NPU的流式计算模式因为它只需要遍历一次数据减少了Global Memory的访问次数。LayerNorm的另一个实现细节是权重和偏置的可学习参数。归一化后的数据需要经过仿射变换乘以gamma加上beta这两个参数是模型训练过程中学习的。在ops-nn的LayerNorm实现中仿射变换与归一化计算融合在同一个kernel中中间结果不需要写回Global Memory。GroupNormGroupNorm将通道分组后归一化是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 的 GEGraph Engine支持自动融合相邻的算子比如 ConvBNReLU 可以融合成一个算子执行省去中间结果的显存读写。ops-nn 的算子已经支持与常见的后处理算子如 ReLU、Add融合但融合规则需要在模型编译时通过配置文件指定。对比维度使用 ops-nn 前使用 ops-nn 后改善幅度算子开发周期手写 Ascend C 内核复用 ops-nn 模板开发周期缩短 70%Conv 算子性能未优化实现针对 Cube 单元优化算力利用率提升 40-60%内存排布适配手动处理 5D 转换算子内部自动适配代码复杂度降低 50%动态 shape 支持需要多个固定 shape 版本单个算子支持动态 shape维护成本大幅降低算子生态覆盖仅基础算子Conv/Pool/Norm/Activation/Loss 全覆盖功能完整度显著提升仓库地址https://atomgit.com/cann/ops-nn