把模型从 GPU 迁到昇腾NPU，很多人第一反应是"硬件适配没做好"。改了几周算子调用，性能还是差一大截。最后发现根因不在硬件，在算子库——你用的那套算子，根本没有针对昇腾NPU做过融合优化。

昇腾CANN 的算子体系里，ops-nn 是神经网络类基础算子库，Conv2D、MatMul、LayerNorm、GELU 这些你每天都在调用的算子，高性能实现全在这里。它属于 CANN 五层架构的第2层（AOL 算子库），是上层框架和底层硬件之间的桥梁。

🔪 算子库就是厨师的刀具套装

打个比方：你请了一个顶级厨师（昇腾NPU），但他手里的刀是超市随便买的（通用算子库），切菜特别慢。你以为是厨师水平不行，其实是刀具不对。

换一套专业刀具（ops-nn），同样的厨师，出菜速度快了三倍。

ops-nn 就是那套专业刀具。

更关键的是，真正的专业厨师不只靠刀具——他会把几道工序合并做。切菜的时候顺手把配料也备了，省掉一趟往返冰箱的时间。这就是融合算子的思路：把 Conv2D + BatchNorm + ReLU 合成一个算子，中间结果不写回显存，直接在片上缓存里流完。

数据搬运是 NPU 上最吃性能的操作，比计算本身慢 10~100 倍。融合算子就是把这个瓶颈直接砍掉。

📦 ops-nn 里到底有什么

ops-nn 是昇腾CANN 第2层的 AOL（Ascend Operator Library）算子库，专门覆盖神经网络的基础算子。分三大类：

第一类：matmul 类算子

MatMul 是最常用的计算算子，全连接层、Transformer 的 QKV 投影、CNN 的卷积都靠它。

# 不用 ops-nn：自己写 MatMul（性能差）
import numpy as np
# 为什么不用 numpy？因为 numpy 跑在 CPU 上，根本没用到 NPU 的 Cube 单元
output = np.matmul(input, weight) # CPU 计算，慢

# 用 ops-nn 的 MatMul（高性能）
from ops_nn import MatMul
# 为什么用这个？因为底层调用了昇腾NPU的Cube单元，矩阵乘性能是CPU的50倍以上
matmul_op = MatMul()
output = matmul_op(input, weight) # NPU Cube单元加速

Conv2D 也是 matmul 类的算子，但实现方式不一样。CNN 的卷积可以展开成矩阵乘，但展开本身有开销。ops-nn 的 Conv2D 直接用昇腾NPU 的卷积加速指令，不经过矩阵乘展开，延迟更低。

第二类：activation 类算子

GELU、ReLU、Sigmoid、Tanh 这些激活函数，看似简单，但实现上有讲究。

# naive 实现 GELU（慢）
def gelu_naive(x):
 # 这个实现每个操作都要读写显存，GELU的3个操作就是3次显存搬运
 return 0.5 * x * (1.0 + torch.tanh(
 math.sqrt(2.0 / math.pi) * (x + 0.0447152 * torch.pow(x, 3.0))
 ))

# ops-nn 的 GELU（快）
from ops_nn import GELU
gelu_op = GELU()
# 为什么快？Vector单元一次性算完，中间结果留片上缓存，不回写显存
output = gelu_op(x)

GELU 在 Transformer 里每层都要调，一个 70B 模型有 80 层，每层省 0.1ms，整条推理链路省 8ms。累积起来就是每秒多跑 15 个 token 的差距。

第三类：融合算子

这是 ops-nn 里性能收益最大的部分。把多个算子合成一个，省掉中间结果的显存读写。

融合算子	合成的单个算子	性能提升
BatchNorm + ReLU	2 个独立算子	延迟降低 40%
LayerNorm + GELU	2 个独立算子	延迟降低 35%
Conv2D + BatchNorm + ReLU	3 个独立算子	延迟降低 55%

融合算子的实现用 Ascend C 编写。Ascend C 是昇腾CANN 第1层的算子编程语言，可以直接操控 Cube 和 Vector 单元，做细粒度的片上缓存管理。

// Ascend C 实现 Conv2D + BatchNorm + ReLU 融合算子（简化）
class ConvBnReluFusion {
 __aicore__ void Compute(int32_t block_idx) {
 // 1. 从显存搬入输入特征图（只搬一次）
 LocalTensor input = QEMU::GetTensor(input_gm, block_idx);
 // 2. Cube单元算卷积，结果留片上
 LocalTensor conv_out = CubeConv2D(input, weight);
 // 3. Vector单元算BatchNorm，直接读conv_out（不写回显存）
 LocalTensor bn_out = VectorBatchNorm(conv_out, bn_param);
 // 4. Vector单元算ReLU，直接读bn_out（还是不写回显存）
 LocalTensor relu_out = VectorRelu(bn_out);
 // 5. 只有最终结果写回显存
 QEMU::SetTensor(output_gm, relu_out, block_idx);
 }
};

关键一句：中间结果全留片上，只有最终结果写回显存。3 个算子合成 1 个，显存读写从 6 次降到 2 次（读输入 + 写输出）。

🔗 ops-nn 在生态里的位置

ops-nn 不是孤立的仓库，它嵌在 CANN 算子生态的依赖链里。

上游依赖：opbase。opbase 是所有算子仓库的基础公共组件，提供内存管理、设备管理、调试工具这些通用能力。ops-nn 编译之前必须先编译 opbase，否则链接阶段会报 undefined reference to opbase symbols。

下游调用方：

• catlass：昇腾算子模板库，用模板生成 matmul 类算子的高性能实现。catlass 依赖 ops-nn 的 matmul 基础能力，再在上面做模板化封装。
• ATB（ascend-transformer-boost）：Transformer 加速库，调用 ops-nn 的基础算子做高层封装。你用 ATB 跑大模型推理，底层很多算子调用最终落到 ops-nn。

和 ops-transformer 的分工：ops-nn 管基础神经网络算子（Conv2D、MatMul、LayerNorm、激活函数），ops-transformer 管大模型进阶算子（FlashAttention、MoE 路由、MC2 通信）。简单说：基础 NN 找 ops-nn，大模型进阶找 ops-transformer。

🚀 为什么你应该用 ops-nn

直接写 Ascend C 做算子开发，灵活度最高，但门槛也最高。一个中等复杂度的算子，从写代码到调通性能，要 2~4 周。

ops-nn 提供的是开箱即用的高性能实现——你不用自己写，直接调。性能是经过昇腾官方优化的，一般比自己写的 Ascend C 实现快 20~40%。

适合用 ops-nn 的场景：

• 做 CNN 模型推理部署（Conv2D + BN + ReLU 融合）
• 做 Transformer 模型的前处理后处理（LayerNorm + GELU）
• 做框架适配（PyTorch/MindSpore 的 NPU 版本底层调用 ops-nn）

不适合用 ops-nn 的场景：

• 做 MoE 大模型推理（用 ops-transformer + ATB）
• 写全新的自定义算子（用 Ascend C 从零写，或基于 opbase 扩展）

🧪 一个完整的调用示例

用 ops-nn 的融合算子替换模型中的逐算子调用，改动量很小，但性能收益明显。

# 原始代码：逐算子调用（3次显存读写）
import torch_npu # PyTorch 的 NPU 版本

x = torch.randn(batch, channels, height, width).npu()
# 三次独立算子调用，中间结果x1、x2都写回显存再读出来
x1 = torch.nn.functional.conv2d(x, weight, bias)
x2 = torch.nn.functional.batchnorm(x1, running_mean, running_var)
output = torch.nn.functional.relu(x2)

# 优化后：用 ops-nn 融合算子（1次显存读写）
from ops_nn import ConvBnReluFusion
fusion_op = ConvBnReluFusion(weight, bias, bn_param)
# 为什么只调一次？因为Conv2D+BN+ReLU在片上合成完了才写回显存
output = fusion_op(x)

性能对比，昇腾NPU，ResNet-50 推理，batch=16：

配置	单张图片延迟(ms)	吞吐(images/s)
逐算子调用	8.2	1950
融合算子	3.7	4320

延迟降低 55%，吞吐提升 121%。这个差距在批量推理场景会被进一步放大。

结尾

ops-nn 是昇腾CANN 算子体系里最基础但也最常用的一部分。模型在 NPU 上跑得慢，先查是不是没用融合算子，再查是不是算子库版本太老。

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

opbase 基础依赖：https://atomgit.com/cann/opbase