前言

在昇腾NPU的软件栈中，CANN（Compute Architecture for Neural Networks）扮演着连接上层框架与底层硬件的关键角色，而ops-nn作为CANN算子体系中提供神经网络核心计算能力的高阶算子库，承载了从矩阵乘法到激活函数、从损失函数到量化融合等最频繁调用的计算原语。2026年3月，ops-nn仓库迎来了一次重要更新，quant_batch_matmul_v4全量化融合算子的加入使得昇腾NPU在低精度推理与训练场景下的算子表达能力和执行效率都迈上了一个新台阶。这篇文章不会泛泛地介绍ops-nn的功能清单，而是以quant_batch_matmul_v4为线索，从算子注册宏的展开、Tiling策略在UB容量约束下的数学推导、Ascend C Kernel中向量级量化计算的实现细节，到fp8/mxfp8/hifp8/mxfp4等多种低精度数据格式的差异处理，完整地走一遍ops-nn算子的开发闭环。理解了这一条路径，面对ops-nn中其他算子的开发或定制，就有了可复用的方法论。

ops-nn的算子分类与目录结构

ops-nn在CANN算子生态中定位为高阶算子层，其下层是ops-builtin提供的基础算子原语，上层则对接MindSpore、PyTorch等框架的适配层。从功能维度划分，ops-nn当前涵盖三大类算子。

matmul类算子构成了ops-nn的核心。矩阵乘法是神经网络中计算密度最高的操作，ops-nn在此类目下提供了从标准BatchMatMul到全量化融合的quant_batch_matmul_v4，以及稀疏量化融合的sparse4to2quant_matmul。这些算子并非简单的GEMM封装，而是将量化、反量化、缩放等操作融合进同一个Kernel执行体中，减少中间张量在Global Memory与Unified Buffer之间的往返搬运。sparse4to2quant_matmul更进一步，在量化融合的基础上引入4:2结构化稀疏，将权重矩阵中每4个元素只保留2个非零元素，在存储和计算上同时获得压缩收益。这种稀疏模式与NVIDIA Ampere架构的2:4稀疏方案思路相近，但昇腾NPU上的实现路径有其独特之处：稀疏索引的计算在Host侧Tiling阶段完成，Kernel侧直接按索引读取非零元素，避免了动态稀疏判断的运行时开销。

activation类算子覆盖了ReLU、GELU、Swish等常见激活函数。这类算子计算逻辑相对简单，但在ops-nn中同样需要遵循完整的注册与Tiling流程，因为激活函数经常与matmul算子融合出现，其Tiling参数的选择直接影响后续融合算子的数据排布。Swish函数涉及sigmoid与乘法两个子操作的融合，在向量级实现时需要合理安排Vector单元的指令流水，使sigmoid的查表计算与乘法的向量运算能够流水化重叠执行。

loss类算子包括CrossEntropy、BCEWithLogits等训练场景必需的损失计算。与matmul类不同，loss类算子通常涉及归约操作，Tiling策略需要考虑全归约与部分归约的分段处理。CrossEntropy在ops-nn中的实现将softmax归约与log概率计算融合在一起，避免了对中间概率矩阵的显存分配。

目录结构上，ops-nn遵循CANN算子仓库的统一规范。op_host目录包含算子Host侧逻辑，涵盖注册、Tiling与形状推导；op_kernel目录存放Ascend C Kernel实现；op_plugin目录提供框架适配层；experimental目录是社区开发者自定义算子贡献入口；cmake目录管理构建脚本。其中experimental目录为社区开发者预留了算子贡献入口，开发者可以在此目录下按照ops-nn的规范结构提交自定义算子，经过评审后合入主干。这种开放策略使得ops-nn的算子生态能够持续扩展，而不局限于华为内部团队的贡献。op_host目录中每个算子通常包含三个关键文件：以quant_batch_matmul_v4为例，会有quant_batch_matmul_v4_tiling.h负责Tiling参数计算，quant_batch_matmul_v4.cpp负责算子注册与形状推导，以及对应的配置文件声明AICore的类型与资源约束。

量化融合算子注册：REG_OP宏与OpAICoreConfig

算子注册是ops-nn算子接入CANN运行时的入口。CANN提供了REG_OP宏来声明算子的接口签名，包括输入、输出与属性。quant_batch_matmul_v4的注册片段如下：

REG_OP(QuantBatchMatmulV4)
    .INPUT(x, TensorType({DT_FLOAT, DT_INT8, DT_FLOAT16, DT_BF16}))
    .INPUT(w, TensorType({DT_INT8, DT_FLOAT16, DT_BF16}))
    .INPUT(scale, TensorType({DT_FLOAT, DT_BFLOAT16}))
    .OPTIONAL_INPUT(bias, TensorType({DT_FLOAT, DT_BFLOAT16, DT_INT32}))
    .OUTPUT(y, TensorType({DT_FLOAT, DT_FLOAT16, DT_BF16, DT_INT32}))
    .ATTR(quant_scale_mode, Int, 0)
    .ATTR(quant_dtype, Int, 0)
    .ATTR(compress_index, Int, 0)
    .OP_END()

REG_OP宏展开后向CANN运行时注册算子名称与签名，INPUT声明必须输入，OPTIONAL_INPUT声明可选输入（如bias），ATTR声明算子属性（如量化模式和量化数据类型），运行时据此校验调用合法性并驱动形状推导

注册之外，算子还需要声明其运行的AICore资源配置，即OpAICoreConfig。这一配置告诉CANN调度器该算子需要多少Unified Buffer、多少Vector计算单元等硬件资源。quant_batch_matmul_v4因为是融合算子，其UB需求远高于普通matmul，需要为量化参数、缩放因子、偏置等中间结果预留足够的Buffer空间。

OpAICoreConfig config;
config.SetUBSize(256 * 1024);  // 256KB UB for fused quant params
config.SetBufferNum(3);        // x, w, y三路Buffer

OpAICoreConfig声明算子对AICore硬件资源的需求，SetUBSize指定Unified Buffer上限，调度器据此判断能否在单个AICore上执行；若算子UB需求超出物理容量，调度器会拒绝实例化并报错

REGISTER_TILING_DEFAULT宏则将Tiling函数注册为默认实现。Tiling函数的职责是根据输入形状和硬件约束，将一个大的计算任务切分为多个可在单个AICore上执行的tile。这是ops-nn算子开发中技术密度最高的环节之一。

REGISTER_TILING_DEFAULT(QuantBatchMatmulV4,
    QuantBatchMatmulV4TilingFunc);

REGISTER_TILING_DEFAULT将Tiling计算函数注册到CANN运行时，调度器在执行算子前调用此函数计算切分参数，若未注册自定义Tiling函数则使用默认实现

整个注册流程形成一条清晰的链路：REG_OP声明算子身份与接口，OpAICoreConfig声明硬件资源需求，REGISTER_TILING_DEFAULT注册Tiling计算入口。三者配合，CANN运行时才能正确地完成算子实例化、资源分配与任务调度。REG_OP中的TensorType列表不仅用于输入校验，还驱动着形状推导函数的分支逻辑。当x的数据类型为DT_INT8时，形状推导函数知道这是量化路径，输出的shape推导需要考虑量化参数的广播规则；当x为DT_FLOAT16时，则走半精度矩阵乘的推导路径。这种基于类型的多路分支设计在ops-nn中非常普遍，使得单个注册入口能够覆盖多种计算模式。

Tiling策略的数学推导与UB容量约束

Tiling是CANN算子开发中最具挑战性的环节。其核心问题在于：当输入张量的规模超出单个AICore的Unified Buffer容量时，如何将计算任务切分为多个tile，使得每个tile的数据能够完整地载入UB，同时尽可能减少Global Memory的访问次数。

以quant_batch_matmul_v4处理shape为[M, K]乘[K, N]的矩阵乘法为例，Tiling需要决定沿M和N两个维度各切分多少。设tile_m和tile_n分别为沿M和N方向的切分大小，则单个tile在UB中占用的空间包括：输入x的tile占tile_m * K * sizeof(x_dtype)，权重w的tile占K * tile_n * sizeof(w_dtype)，输出y的tile占tile_m * tile_n * sizeof(y_dtype)，量化参数scale的占用根据quant_scale_mode决定，pertensor模式仅需1个标量，perchannel模式需要N个，pergroup模式需要N/group_size个。

UB容量约束可以形式化为：

tile_m * K * sx + K * tile_n * sw + tile_m * tile_n * sy + scale_size <= UB_CAPACITY

其中sx、sw、sy分别为各张量的数据类型大小。在quant_batch_matmul_v4中，x通常为int8（1字节）或float16（2字节），w通常为int8，y通常为float16或bfloat16（2字节）。这一约束是一个关于tile_m和tile_n的二元一次不等式，其可行域在tile_m-tile_n平面上是一条双曲线下方的区域。

对于Conv2d算子，Tiling策略用tile_h和tile_w参数控制沿特征图高和宽方向的切分。Conv2d的UB占用还需要考虑卷积核的大小和通道数。假设输入特征图为[C, H, W]格式，卷积核为[C, C_out, KH, KW]，则单个tile的输入占用为C * tile_h * tile_w * sizeof(dtype)，权重占用为C * C_out * KH * KW * sizeof(dtype)，输出占用为C_out * tile_h_out * tile_w_out * sizeof(dtype)。其中tile_h_out和tile_w_out由tile_h、tile_w与stride、padding共同决定。Conv2d的Tiling比matmul多了一个维度需要搜索，可行域从二维扩展到三维，搜索空间急剧增大。ops-nn中Conv2d的Tiling实现通过固定stride和kernel_size为已知参数，将三维搜索降维为沿H和W方向的二维搜索，降低了Tiling计算的时间复杂度。

Tiling参数的选择不仅影响正确性，更直接影响性能。tile过大导致UB溢出，tile过小则增加Global Memory的重复读取次数。理想的Tiling策略应该在UB容量约束下最大化tile大小，从而最大化数据复用比。

quant_batch_matmul_v4的Tiling函数在实现中采用了贪心搜索策略：沿M方向从最大可能的tile_m开始尝试，逐步缩小直到满足UB约束；此后在固定的tile_m下沿N方向做同样的搜索。这种策略虽然不是全局最优，但在实际场景中表现稳定，因为matmul类算子的计算量与tile_m * tile_n * K成正比，而UB占用与tile_m和tile_n呈线性关系，贪心搜索倾向于优先填满计算密集维度的tile。

pergroup和perblock量化粒度的引入为Tiling带来了额外的复杂度。group_size和block_size必须整除N维度，否则量化参数的索引计算会跨tile边界，需要在Tiling函数中加入整除性约束检查。这意味着有效的tile_n不仅受UB约束，还必须是group_size的倍数，进一步缩小了搜索空间。perblock模式将N维度按block_size切分为若干块，每块拥有独立的缩放因子和零点，这些参数需要在Tiling阶段预计算好偏移量，以便Kernel侧能以O(1)复杂度访问当前tile对应的量化参数块。

Ascend C Kernel实现：向量级量化计算

Tiling确定了数据切分方案后，Kernel负责在AICore上执行具体的计算逻辑。ops-nn的Kernel基于Ascend C语言编写，这是一种面向昇腾AICore的类C编程语言，提供了向量计算和Cube矩阵计算的高层抽象。

quant_batch_matmul_v4的Kernel核心逻辑可以用以下伪代码表达其结构：

__aicore__ void QuantBatchMatmulV4Kernel(__gm__ uint8_t* x_gm,
    __gm__ uint8_t* w_gm, __gm__ uint8_t* scale_gm,
    __gm__ uint8_t* y_gm) {
  LocalTensor<int8_t> x_ub = x_gm[tile_offset];
  LocalTensor<int8_t> w_ub = w_gm[tile_offset];
  LocalTensor<float> scale_ub = scale_gm[scale_offset];
  // Cube计算: matmul
  mm_res = Matmul(x_ub, w_ub, {tile_m, K, tile_n});
  // Vector计算: 量化缩放
  out = mm_res * scale_ub;
  // 写回Global Memory
  y_gm[out_offset] = out;
}

Ascend C Kernel中__gm__标记Global Memory指针，LocalTensor映射UB上的连续空间；Matmul调用Cube矩阵计算单元执行int8矩阵乘，结果经Vector单元乘以scale完成量化缩放后写回Global Memory，这正是"融合"的含义——量化操作与矩阵乘法在同一Kernel中完成，避免中间结果的显存写回与重新读取

这里的关键设计决策在于将Matmul（Cube单元操作）与量化缩放（Vector单元操作）融合在同一个Kernel中。如果不融合，传统流程是：先执行int8 matmul得到int32结果，写回Global Memory；再启动一个独立的反量化Kernel，从Global Memory读取int32结果，乘以scale，写回float16结果。融合后，int32结果直接在UB上传递给Vector单元执行缩放，省掉了一次Global Memory写和一次Global Memory读。对于大模型推理场景中常见的[M=1, K=4096, N=4096]形状，中间int32结果的大小为1 * 4096 * 4字节 = 16KB，看似不大，但当batch维度增大或多流并发时，这些中间张量的显存分配和释放会成为调度器的负担。

对于perchannel和pergroup量化模式，scale的形状不同。perchannel模式下scale是长度为N的向量，在Vector计算时需要沿N方向广播；pergroup模式下scale是长度为N/group_size的向量，每group_size列共享同一个scale值，广播逻辑更复杂，需要使用Ascend C的Repeat前缀指令配合stride参数实现分组广播。具体来说，假设group_size为128，N为4096，则scale向量长度为32，Vector单元需要将这32个值各重复128次拼成4096长度的向量。Ascend C中这通过设置源stride为0（每个值不递进读取）、目标stride为1（连续写入）来实现零开销广播。

bias的融合处理也值得关注。当bias存在时，它需要在scale乘法之后加到结果上（先反量化再加bias），还是在scale乘法之前加到int32结果上（先加bias再量化缩放）？这取决于bias的数据类型：当bias为int32时，它在量化域中，应先加再缩放；当bias为float或bfloat16时，它在反量化域中，应先缩放再加。quant_batch_matmul_v4的Kernel通过编译期分支处理这两种情况，避免运行时开销。这一设计选择在REG_OP的OPTIONAL_INPUT声明中已埋下伏笔——bias的TensorType列表同时包含DT_INT32和DT_FLOAT，正是为了支持这两种计算路径。

sparse4to2quant_matmul的Kernel在quant_batch_matmul_v4的基础上增加了稀疏索引的处理。4:2稀疏模式下，权重矩阵的每4个元素中只有2个非零元素，这2个元素的位置由一个2-bit索引编码。Kernel侧在读取权重时，先从索引Buffer中读取当前tile的稀疏模式，据此从权重Buffer中只加载非零元素。这部分逻辑用Ascend C的Gather指令实现，将稀疏读取转化为向量化的条件收集操作。

Tiling的执行调度同样决定了实际性能。昇腾AICore采用Block Dim切分方式，一个tile内的数据由指定数量的AI Core并行处理。每个AI Core负责处理tile内的部分行，计算量按行数均分。tile_m参数的选取直接影响Cube矩阵计算单元的计算密度：当tile_m过小时，单次Matmul计算量不足，Cube单元的利用率下降；当tile_m增大时，计算密度提升，但UB占用量也随之增加，需要在利用率和UB容量之间取得平衡。ops-nn中quant_batch_matmul_v4的Tiling策略默认使用tile_m=32或64，这个数值是通过对不同batch_size和seq_len配置进行离线性能搜索得出的。离线搜索的核心思路是：遍历所有合法的tile_m/tile_n组合，分别在目标硬件上运行微Benchmark，选取AI Core利用率最高的配置作为默认值。对于自定义算子，开发者可以复用这套搜索框架，只需提供算子的UB占用计算公式和最小计算密度约束，即可自动生成Tiling搜索空间。

多数据类型支持：fp8/mxfp8/hifp8/mxfp4的差异

quant_batch_matmul_v4支持的量化数据格式是ops-nn中类型系统复杂度的集中体现。fp8、mxfp8、hifp8、mxfp4这四种格式虽然都被称为"低精度浮点"，但在编码方式、动态范围和精度特性上差异显著。

fp8有两种变体：E4M3和E5M2。E4M3用4位指数和3位尾数，动态范围较小但精度较高，适合前向传播；E5M2用5位指数和2位尾数，动态范围较大但精度较低，适合反向传播中的梯度表示。quant_batch_matmul_v4对fp8的支持主要通过quant_dtype属性控制，运行时根据该属性选择对应的解码路径。fp8的解码是逐元素的位操作，将8位编码拆分为符号位、指数位和尾数位后还原为float16。由于E4M3和E5M2的位宽分配不同，解码时需要使用不同的偏移量和掩码，但整体流程都是纯算术操作，可以完全向量化执行。

mxfp8（Microscaling FP8）在fp8的基础上引入了块级缩放因子。每block_size个元素共享一个缩放因子，存储格式为8位浮点尾数加块级共享指数。这种设计在保持fp8存储效率的同时，通过块级缩放缓解了动态范围不足的问题。对于包含离群值（outlier）的权重分布，mxfp8的块级缩放能有效减少量化误差。在Kernel实现中，mxfp8的解码需要先读取块级缩放因子，再对块内元素执行逐元素解码后乘以缩放因子。块级缩放因子的广播可以用向量广播指令高效实现，将缩放因子分发到块内所有元素，解码效率反而可能高于逐元素的fp8解码。

hifp8（Hybrid Index FP8）是华为在昇腾NPU上提出的一种混合索引浮点格式。其核心思想是将权重矩阵中绝对值最大的少量元素用高精度格式存储，其余元素用标准fp8存储。hifp8的编解码逻辑比mxfp8更复杂，需要额外的索引表来记录离群值的位置，但它在权重量化精度上的提升也更为明显，尤其适用于大语言模型中常见的长尾权重分布。hifp8的解码最为复杂，需要先查索引表判断当前元素是否为离群值，若是则从高精度表中读取，否则走标准fp8解码路径。索引查表引入了条件分支，需要用mask操作将分支转换为向量级的条件选择，避免标量分支导致的流水线气泡。具体实现中，hifp8将索引表预加载到UB的一个专用Buffer中，Kernel主循环中对每个元素先计算索引哈希，用向量比较指令生成mask，再通过Select指令根据mask从高精度表或标准fp8路径选择结果。

mxfp4将压缩推向极致，每个元素仅用4位存储。4位浮点格式的指数和尾数分配非常紧张，通常采用E2M1（2位指数、1位尾数）加上块级缩放因子的方案。mxfp4的存储密度是fp8的两倍，但精度损失也更大，通常只用于对精度不敏感的推理场景。在Kernel层面，mxfp4的解码策略是将两个4位元素打包为一个8位字读取，再用位操作拆分为两个独立值。这种打包策略使得mxfp4的读取带宽效率与int8相同，但解码步骤多了一层拆分操作。解码后的值同样需要乘以块级缩放因子，这部分逻辑与mxfp8共享相同的实现。

从开发者的视角看，这四种格式的差异意味着quant_batch_matmul_v4的Kernel需要维护四条解码路径，每条路径对应不同的指令序列和寄存器分配策略。ops-nn通过在Tiling阶段将quant_dtype属性映射为枚举值，Kernel侧用编译期常量分支选择对应的解码路径。这种设计避免了运行时分支判断，保证了每条路径都能获得最优的指令调度。代价是Kernel二进制的体积增大，因为四条路径的代码都被编译进了同一个Kernel对象中，但昇腾NPU的指令缓存容量足以容纳这一增量。

实际选型时，判断依据是权重或激活值分布中是否存在离群值。如果分布相对均匀，int8或fp8（E4M3）即可满足精度需求；如果存在少量极大或极小的离群值，mxfp8的块级缩放能在不过度牺牲压缩率的前提下保持精度；如果离群值数量极多且集中，hifp8的高精度索引机制是最优选择；mxfp4则只适用于对精度完全不敏感的后处理阶段或极端显存受限的推理场景。ops-nn的量化接口默认不做自动格式选择，这个决策由开发者根据模型特性做出。

效率对比

维度	使用前（独立matmul+量化Kernel）	使用后（quant_batch_matmul_v4融合算子）	改善来源
Global Memory读写次数	matmul结果写回+量化读取，两次完整搬运	中间结果在UB直传，零额外搬运	Cube-Vector融合消除中间张量的显存往返
Kernel Launch开销	两个独立Kernel分别调度，各有一次上下文切换	单次Launch完成全部计算	调度器只需一次任务下发与完成回调
量化精度损失	中间int32结果经截断写回Global时可能溢出	int32结果在UB内直接缩放，避免截断	全精度中间结果保留至缩放完成
算子开发维护成本	需分别维护matmul与量化两个算子的Tiling和Kernel	单一算子统一Tiling与Kernel，接口一致	注册、Tiling、Kernel三端代码合一

结尾

从REG_OP宏的接口声明到OpAICoreConfig的资源约束声明，从UB容量约束下的Tiling数学推导到Ascend C Kernel中Cube与Vector的融合计算路径，再到fp8/mxfp8/hifp8/mxfp4四种低精度格式的解码差异，quant_batch_matmul_v4完整地呈现了ops-nn算子从注册到执行的全链路。这条链路中的每个环节都不是孤立的：Tiling参数的选择受制于量化粒度对齐约束，Kernel中的解码路径受制于数据格式的编码方式，而OpAICoreConfig中的UB声明必须覆盖所有Tiling场景下的峰值占用。理解这些环节之间的耦合关系，比单独掌握任何一项技术都重要。当开发者需要为ops-nn贡献新的融合算子时，这条链路提供了可复用的骨架：确定算子的输入输出签名与属性集合，声明硬件资源需求，推导Tiling可行域并实现搜索策略，编写融合Kernel并处理多类型分支。ops-nn中其他算子的开发遵循同样的链路和约束，差异仅在于计算逻辑的复杂度和Tiling维度有所不同。sparse4to2quant_matmul在Tiling阶段多了一步稀疏索引的预计算，index_fill和scatter算子的Tiling维度从二维扩展到多维索引空间，但核心理路一脉相承。

---

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