个人主页：ujainu

前言

你写了一个 ResNet，跑在昇腾 NPU 上，推理速度不如预期。打开 profiling 看——计算单元利用率不到一半。为什么？大多数人会说"模型没优化好"，但真正的原因藏在更底层：你用的那些 Conv2D、BatchNorm、ReLU，每一个都是跟硬件谈判的结果，而谈判的筹码，就是 ops-nn 这个仓库。

CANN ops-nn 是昇腾 CANN 五层架构中第 2 层 AOL 算子库的核心成员，它做的事看起来简单——实现基础神经网络算子。但"简单"这两个字掩盖了一个关键问题：同一个 Conv2D，在 GPU 上的实现逻辑跟在昇腾 NPU 上完全不同。达芬奇架构的 Cube 单元做矩阵乘、Vector 单元做逐元素运算、Scalar 单元做控制流——算子不是"把数学公式翻译成代码"，而是在这三套单元之间做最优分工。ops-nn 就是这个分工方案的统一实现层。

仓库定位：为什么需要一层"统一实现"

昇腾 CANN 的算子生态不是一个仓库搞定的。opbase 提供头文件和调度框架，ops-nn 实现基础神经网络算子，ops-transformer 实现大模型算子，ops-cv 覆盖视觉专用算子——每个仓库各管一摊。但问题来了：如果一个框架要同时用 Conv2D 和 FlashAttention，它得分别对接两个仓库，还要保证两边的 Tiling 策略、内存布局、数据格式能对得上。

ops-nn 的设计动机就在这里——它不是"又一个算子仓库"，而是基础算子域的统一收敛点。所有 CNN 和通用神经网络中反复出现的算子（卷积、归一化、激活、插值、池化），都收敛到 ops-nn 一处实现。下游的 ATB、cann-recipes、第三方框架，只需要对接 ops-nn 这一个入口，就能拿到整套基础算子能力。

# ops-nn 仓库结构概览
ops-nn/
├── op_host/          # Host 侧 Tiling 实现
│   ├── conv2d/
│   ├── batchnorm/
│   └── interpolate/
├── op_kernel/        # Device 侧 Ascend C 算子核函数
│   ├── conv2d/
│   ├── batchnorm/
│   └── interpolate/
├── opapi/            # 算子 API 对外接口层
├── CMakeLists.txt
└── build.sh          # 一键构建脚本

这种收敛策略带来一个直接好处：算子的性能优化工作不会被分散。Conv2D 在推理场景下的 Tiling 策略调优、BatchNorm 融合规则的更新、Interpolate 对不同数据格式的适配——这些改动集中在一个仓库里完成，所有下游同时受益。如果每个框架各自维护一份 Conv2D 实现，同样的优化要在 N 个地方重复做 N 遍。

算子不是"公式翻译"，是对硬件的谈判

很多人以为，Conv2D 算子就是把卷积公式用 Ascend C 写一遍。但算子不是数学公式的翻译，是对硬件的谈判结果。

打个比方：你要搬 1000 箱货从 A 仓库到 B 仓库。搬这个动作本身不变（卷积公式不变），但你用推车搬、用叉车搬、还是让传送带自动搬——效率天差地别。ops-nn 做的事就是：针对昇腾 NPU 的达芬奇架构，给每个基础算子选最快的"搬运方案"。

Conv2D：im2col 转矩阵乘

// Conv2D 在 ops-nn 中的调用示意
// 不是简单翻译公式，而是走 Cube 单元的矩阵乘路径
auto conv2d_op = op::Conv2D("conv1");
conv2d_op.set_input_x(data_tensor)         // 输入特征图 [N, C, H, W]
         .set_input_filter(weight_tensor)   // 卷积核 [K, C, R, S]
         .set_attr_strides({1, 1})
         .set_attr_pads({0, 0, 0, 0})
         .set_attr_dilations({1, 1})
         .set_attr_groups(1);

这段代码看着简单，但底层发生了什么？im2col 变换把卷积操作展开成矩阵乘法——输入特征图的每个感受野被展平成矩阵的一行，卷积核被展平成矩阵的一列。展开完成后，Cube 单元直接吃进这个大矩阵做乘加运算。这条路径是 ops-nn 针对达芬奇架构的 Cube 单元特化出来的，GPU 上会用不同的展开策略（比如 winograd），换一种架构同样不走这条路。

BatchNorm：推理折叠成逐元素运算

// BatchNorm 推理模式下折叠为 scale + bias
auto bn_op = op::BatchNorm("bn1");
bn_op.set_input_x(conv_output)          // 上游卷积输出
     .set_input_gamma(gamma_tensor)      // 缩放参数
     .set_input_beta(beta_tensor)        // 偏移参数
     .set_input_mean(mean_tensor)        # 训练均值
     .set_input_variance(var_tensor)     # 训练方差
     .set_attr_epsilon(1e-5)
     .set_attr_data_format("NCHW");

BatchNorm 的训练和推理走完全不同的路径。训练时需要计算均值和方差，涉及归约运算（依赖 Cube 的 reduce 能力）；推理时均值和方差已经固定，整个 BatchNorm 退化成一次逐元素的 scale + bias 操作——这就是 Vector 单元的本职工作。ops-nn 的实现会根据模式自动选择走 Cube 还是 Vector，下游调用者不需要关心这个细节。

Interpolate：双线性插值的分步执行

// 双线性插值，支持多种数据格式
auto interp_op = op::Interpolate("interp1");
interp_op.set_input_x(input_tensor)                 // 输入 [N, C, H, W]
         .set_attr_size({output_h, output_w})       // 目标尺寸
         .set_attr_mode("bilinear")                 // 插值模式
         .set_attr_align_corners(false)             // 坐标对齐方式
         .set_attr_data_format("NCHW");

Interpolate（插值）在视觉模型中频繁出现，用于特征图的上采样。以双线性插值为例：先算出目标像素在源特征图上的浮点坐标，再做四个最近邻像素的加权求和。在达芬奇架构上，浮点坐标计算走 Scalar 单元，加权求和走 Vector 单元——一个 Interpolate 算子内部就需要协调两套计算单元。ops-nn 的调度框架会自动编排这个多阶段执行过程。

统一框架：不是算子的堆积

你可能觉得 ops-nn 就是把 Conv2D、BatchNorm、ReLU、Interpolate 这些算子各自实现一遍，堆在一个仓库里。如果是这样，那它跟一个 GitHub 上的"awesome-operators"列表有什么区别？

区别在于"统一"二字。 ops-nn 不是算子的堆积，而是一套统一的实现框架——所有算子共享同一套调度机制、同一套内存管理策略、同一套融合规则。这才是它作为"层"而非"库"的本质。

// 不同算子共享的调度框架（来自 opbase）
// 所有 ops-nn 算子都走这套 Tiling 流程
struct TilingData {
    int32_t block_dim;    // Cube/Vector 并行分块数
    int32_t tile_num;     // Tiling 切分数量
    int32_t tile_length;  // 每块数据长度
    int32_t aiv_num;      // AI Vector 使用数量
};

opbase 提供了公共的头文件、结构体和调度框架，ops-nn 在此基础上实现具体的神经网络算子逻辑。这意味着 Conv2D 和 BatchNorm 虽然计算逻辑不同，但它们的数据搬运策略、Tiling 切分方式、内存分配逻辑是同一套——统一的不是算子本身，而是算子跟硬件谈判的规则。

// Host 侧 Tiling 实现示例（op_host 目录下）
// 每个算子都需要实现自己的 GetTiling 函数
ge::GraphErrCodeStatus Conv2DGetTiling(
    const ge::Operator& op,
    TilingData* tiling_data) {
    // 根据 input shape、filter shape、strides 等属性
    // 计算最优的 block_dim 和 tile_length
    auto input_shape = op.GetInputDesc(0).GetShape();
    int32_t N = input_shape.GetDim(0);
    int32_t C = input_shape.GetDim(1);
    tiling_data->block_dim = (N * C + 7) / 8;  // 示意值
    return ge::GRAPH_SUCCESS;
}

Host 侧的 Tiling 计算是整个调度链路的关键一步。它负责把输入数据切成适合达芬奇架构处理的小块（tile），决定每个 AI Core 处理多少数据、用 Cube 还是 Vector 执行。这套 Tiling 逻辑对每个算子都不一样——Conv2D 要考虑感受野重叠，BatchNorm 要考虑归约维度——但调度框架本身是共享的。

# 下游框架通过 Ascend C API 调用 ops-nn 算子
import torch_npu  # PyTorch 昇腾插件

model = torch_npu.npu(device="npu:0")
x = torch.randn(1, 64, 56, 56).npu()
conv = torch.nn.Conv2d(64, 128, 3, padding=1).npu()

# 框架自动匹配 ops-nn 中的 Conv2D 实现
output = conv(x)  # 底层走 ops-nn → Cube 矩阵乘路径

架构位置：算子层的"地基"

CANN 五层架构里，ops-nn 住在第 2 层——昇腾计算服务层的 AOL 算子库。这个位置很讲究：往上，ATB 和 cann-recipes 调用它的算子做推理和训练；往下，它依赖 opbase 的基础设施和 ascend-boost-comm 的公共平台中间件。

        ┌─────────────────────┐
        │   应用层 (MindSpore)  │  第 3 层
        ├─────────────────────┤
        │ ATB / cann-recipes   │  第 2 层（调度编排）
        ├─────────────────────┤
        │ ops-nn ops-transformer ops-cv │  AOL 算子库
        ├─────────────────────┤
        │ opbase / ascend-boost-comm │  基础设施层
        ├─────────────────────┤
        │   昇腾 NPU (达芬奇)   │  硬件
        └─────────────────────┘

“它不直接面向模型，但模型跑得快不快，它说了算一半。” 上层框架再怎么优化调度，如果底层算子执行效率拉胯，一切都是白搭。

算子域划分：nn / transformer / cv 各管一摊

ops-nn 和 ops-transformer、ops-cv 经常被拿来比较，但它们不是竞争关系——它们覆盖不同的算子域，各自收敛一类算子的全部实现。

• ops-nn：通用神经网络基础算子——Conv2D、ConvTranspose、BatchNorm、LayerNorm、ReLU、GELU、Interpolate、MatMul、Softmax、Dropout。这些算子在 CNN、ViT、甚至 Transformer 中都会出现，是跨模型类型的公共依赖。
• ops-transformer：大模型专用算子——FlashAttention、MoE（Mixture of Experts）、GMM（Grouped Matrix Multiply）、RMSNorm。这些算子的实现深度依赖 Transformer 的注意力机制和混合专家架构，跟 CNN 基础算子的计算模式完全不同。
• ops-cv：计算机视觉专用算子——Resize、Crop、Rotate、ColorConvert、NMS（非极大值抑制）。这些算子通常出现在预处理和后处理阶段，不走达芬奇的 Cube 单元，以 Vector 逐像素运算为主。

// ops-nn 的算子域：跨模型的基础算子
auto relu_op = op::Relu("relu1");
auto gelu_op = op::GELU("gelu1");
auto softmax_op = op::Softmax("softmax1");
auto matmul_op = op::MatMul("matmul1");
auto interp_op = op::Interpolate("interp1");

// ops-transformer 的算子域：大模型进阶算子
// FlashAttention、MoE、GMM、RMSNorm 等——另一个仓库

// ops-cv 的算子域：视觉预处理/后处理算子
// Resize、NMS、ColorConvert 等——又一个仓库

划分逻辑很清晰：一个算子如果在大模型中才有意义（FlashAttention），归 ops-transformer；如果只在视觉处理流水线中用到（NMS），归 ops-cv；如果 ResNet 和 GPT 都会用到（MatMul、Softmax），归 ops-nn。

仓库关系：opbase、ascend-boost-comm、ATB、asnumpy

ops-nn 不是孤立存在的。它的上下游依赖形成了一个清晰的协作链路。

依赖 opbase：共享头文件和调度框架

opbase 是所有算子仓库的公共基座。它定义了 TilingData 结构体、Host 侧调度接口、Device 侧核函数注册规范。ops-nn 的每一个算子实现都必须遵循 opbase 定义的接口契约，这样才能被上层框架统一调度。

# ops-nn 的 CMakeLists.txt 依赖 opbase
find_package(opbase REQUIRED)
target_link_libraries(conv2d_kernel PRIVATE opbase::tiling opbase::kernel)

对接 ascend-boost-comm：M×N 算子复用

ascend-boost-comm 是昇腾 CANN 的公共平台中间件，它实现了一套算子注册和发现机制。ops-nn 的算子通过 ascend-boost-comm 注册到系统中，ATB、asnumpy、cann-recipes 等下游组件不需要直接链接 ops-nn 的库——它们通过 ascend-boost-comm 的接口按名称查找和调用算子。

# ascend-boost-comm 中的算子注册配置（示意）
# ops-nn 构建时自动生成注册信息
cat ops-nn/opapi/op_host_conv2d_tiling.h
# → 包含算子类型名称 "Conv2D"、输入输出规格、支持的属性列表

被 ATB 调用：推理/训练的编排层

ATB（Ascend Transformer Boost）是昇腾 CANN 的算子编排引擎。它负责把多个算子串联成计算图，处理算子间的数据搬运和同步。ATB 在构建计算图时会从 ascend-boost-comm 中查找需要的算子——如果图中有 Conv2D，ATB 就拉取 ops-nn 提供的 Conv2D 实现。

# 构建并安装 ops-nn
cd ops-nn
bash build.sh            # 编译所有算子
bash build.sh install    # 安装到系统路径，供 ATB 调用

与 asnumpy：跨框架的数据桥梁

asnumpy 是昇腾 CANN 的数据转换层，负责在 Device Tensor 和 NumPy 数组之间做搬运。当你用 Python 调用 ops-nn 的算子并需要把结果转回 CPU 做后处理时，asnumpy 就在中间完成数据搬移。它同样通过 ascend-boost-comm 对接 ops-nn 的算子，保证数据格式和内存布局的一致性。

# asnumpy 桥接 ops-nn 算子输出与 NumPy 生态
import torch
import torch_npu
import numpy as np

x = torch.randn(1, 3, 224, 224).npu()
model = resnet50().npu()
output = model(x)          # 底层走 ops-nn 的 Conv2D/BatchNorm/ReLU

# asnumpy 完成设备到主机的数据搬运
result_np = output.cpu().numpy()  # 交给 NumPy 做后处理

写在最后

ops-nn 看起来只是"一堆 CNN 算子的实现"，但它的价值不在于算子数量的堆砌，而在于统一了所有基础算子跟昇腾 NPU 的谈判规则。Conv2D 不是简单的卷积翻译，BatchNorm 也不是简单的归一化——每一个算子都是对达芬奇架构 Cube/Vector/Scalar 三套计算单元的最优分工方案。这种统一性，才是 ops-nn 作为"层"而非"库"的核心。

如果你想动手试试，直接去仓库克隆代码跑起来：

https://atomgit.com/cann/ops-nn

仓库里包含了完整的算子实现和构建脚本，bash build.sh 即可开始。先从一个 Conv2D 跑通，再去看 BatchNorm 和 ReLU 的实现——你会发现，它们走的是同一套 Tiling 和调度逻辑。理解了这套统一框架，你就理解了 ops-nn 为什么要作为"层"存在。