前言

CANN（Compute Architecture for Neural Networks）是华为昇腾AI处理器的统一计算框架，负责将深度学习模型中的算子调度到昇腾NPU硬件上高效执行。在神经网络推理与训练场景中，矩阵乘法和激活函数是出现频率最高的两类算子，它们在昇腾NPU上的执行效率直接决定了整个网络的吞吐与延迟表现。ops-nn仓库正是CANN生态中专门针对这两类基础算子的实现库，涵盖MatMul、BatchMatMul、ReLU、GELU、SiLU等神经网络核心算子，并且提供了matmul+bias+activation融合能力。本文以ops-nn仓库为基础，从硬件架构出发，逐步拆解MatMul算子的Cube引擎加速原理、激活函数在Vector引擎上的逐元素实现，以及两者融合后的内存访问优化机制，帮助开发者理解并运用这套算子体系在昇腾NPU上获得更优的计算效率。

神经网络算子在昇腾NPU上的硬件映射——Cube引擎与Vector引擎的分工

昇腾NPU的计算单元被划分为两个核心引擎：Cube引擎和Vector引擎。Cube引擎专门处理矩阵乘法类计算任务，内部集成了多个矩阵计算单元，可以并行完成大规模矩阵乘加运算。Vector引擎则负责逐元素操作，包括激活函数、加法、乘法、类型转换等通用向量计算。

这种分工设计源自两种计算模式在数据访存模式上的差异。矩阵乘法具有高度可预测的访存模式，数据可以按tile分块从外部存储加载到片上缓存，再送入计算单元执行，其计算访存比极高，适合Cube引擎这种面向密集矩阵运算的专用硬件。逐元素操作的每个输出元素仅依赖对应位置的输入元素，访存局部性较弱，计算密度相对偏低，适合Vector引擎的流水线执行方式。

在CANN的算子调度框架中，一个神经网络算子会被映射到其中一个引擎执行。MatMul类算子走Cube引擎路径，激活函数走Vector引擎路径。当需要将两个算子融合为一个复合算子时，CANN需要协调两个引擎之间的数据流转，这也是融合优化面临的核心技术挑战。

了解这两个引擎的硬件特性，是理解ops-nn仓库中各类算子实现方式的前提。后续章节将从数据流和内存层次两个维度，分别剖析MatMul和激活函数在各自引擎上的执行过程。

Cube引擎和Vector引擎在昇腾NPU上共享同一片HBM作为Global Memory，但各自拥有独立的片上缓存层级。Cube引擎的L0A和L0B是专门为其矩阵乘法流水线设计的高速暂存器，容量和位宽都针对矩阵块操作做了优化。Vector引擎的L0寄存器则面向向量计算设计，宽度恰好匹配一条向量指令能处理的数据量。两个引擎之间的数据交换通过L1 Buffer作为桥梁完成，CANN的调度器负责协调Cube和Vector引擎的执行时序，确保数据在正确的时间点到达正确的引擎。

这种架构决定了算子融合的技术路线。如果要融合一个Cube算子和一个Vector算子，就必须让Cube的输出驻留在L1中供Vector读取，而不是像独立执行时那样直接写回GM。这要求L1中有足够的空间同时容纳Cube输出的tile和Vector计算所需的临时缓冲。当输出矩阵较大无法一次性放入L1时，融合算子需要在空间和时间两个维度上进行分块循环，每一轮循环处理输出矩阵的一个tile切片。分块循环增加了调度复杂度，减少了每个tile内部的数据复用机会，但它让融合优化在大尺寸矩阵场景下依然可行。

MatMul算子的Cube加速原理与数据流（GM→L1→L0A/L0B）

MatMul算子是全连接层、注意力机制QKV投影等网络结构的基础计算单元。在昇腾NPU上，MatMul的计算流程遵循一条清晰的四级存储路径：数据从Global Memory（GM，即HBM）加载到L1 Buffer，再从L1搬运到L0A和L0B寄存器，最终送入Cube计算单元执行乘累加。

GM到L1的搬运由DMA引擎完成。Cube引擎要求输入矩阵以特定的分块格式存储在L1中，因此DMA搬运过程中会同步完成数据重排，将GM中行优先或列优先的数据布局转换为Cube引擎需要的tiling格式。L1到L0A和L0B的搬运则由Cube引擎内部的加载单元驱动，这一阶段数据被拆解为更细粒度的子矩阵块，填满Cube单元的输入寄存器。

Cube计算单元一次能处理一个固定尺寸的矩阵块乘法。对于更大的矩阵尺寸，CANN的tiling策略会将整个MatMul拆分为多个子任务循环执行。tiling策略的选择直接影响L1缓存的利用率和数据复用程度——合理的tiling让中间结果在片上被充分复用，减少对GM的重复访问，这正是MatMul性能调优的核心环节。

输出结果从Cube单元写入L0C寄存器，再搬运回L1，最终写回GM。对于需要累加的场景（如批量矩阵乘），L0C中已有部分和，新计算结果会与部分和累加后再写回。

以下是MatMul基础调用的代码示例，展示了在CANN算子开发框架中如何配置MatMul算子的基本参数：

import tiling
from te import tvm
from topi.util import get_const_tuple

def matmul_basic(x_shape, y_shape, dtype="float16"):
    A = tvm.placeholder(x_shape, name="A", dtype=dtype)
    B = tvm.placeholder(y_shape, name="B", dtype=dtype)
    k = tvm.reduce_axis((0, x_shape[1]), name="k")
    C = tvm.compute(
        (x_shape[0], y_shape[1]),
        lambda i, j: tvm.sum(A[i, k] * B[k, j], axis=k),
        name="C"
    )
    schedule = tvm.create_schedule(C.op)
    return schedule, (A, B, C)

在实际部署中，MatMul算子的性能受多个因素影响。矩阵尺寸决定了tiling策略的选择空间——当K维度较大时，数据复用程度高，Cube引擎的利用率更容易达到理想水平；当K维度较小或M、N维度不规则时，tiling边界处理会引入额外的无效计算。数据类型同样关键，float16相比float32可以将L1到L0的搬运带宽需求减半，Cube引擎在float16模式下的吞吐也更高。CANN框架会根据输入shape和dtype自动选择一套默认tiling策略，开发者也可以通过tiling配置覆盖默认策略以适配特定场景。

另一个容易被忽略的要点是数据在GM中的排布格式。昇腾NPU支持多种数据布局，如ND（普通多维）、FZ（5D分块格式，专为Cube优化）等。使用FZ格式的输入可以让DMA搬运阶段省去大量重排开销，直接将数据送入L1供Cube引擎消费。ops-nn仓库中的MatMul实现会根据输入布局自动选择相应的加载路径。

激活函数ReLU/GELU/SiLU的Vector引擎实现与数值精度

激活函数对神经网络的表达能力至关重要，它们为线性变换引入非线性。在CANN框架中，ReLU、GELU、SiLU等激活函数由Vector引擎执行，因为它们的计算逻辑中每个输出值仅取决于对应位置的输入值，符合逐元素操作的特征。

Vector引擎内部包含多条向量计算流水线，支持浮点加、乘、比较、查表等基本运算。不同的激活函数在这套硬件上有着截然不同的实现方式。ReLU的实现最为直接，输入与零比较后取正值，仅需一条compare-and-select指令即可完成。GELU的数学形式包含高斯误差函数erf，Vector引擎上无法用单一指令完成全部计算，硬件层面通常采用分段多项式逼近或查表插值的方式实现。SiLU即Swish函数，可以分解为逐元素sigmoid乘以逐元素输入，Vector引擎需要先计算sigmoid，再执行一次逐元素乘法。

数值精度是激活函数实现中需要关注的维度。float16的数据范围有限，GELU和SiLU中间计算步骤如果使用float16，可能在输入绝对值较大时出现精度损失。CANN框架中，部分激活函数实现会在Vector引擎内部将中间计算提升到float32精度，完成后再截断回float16。这种精度提升策略会消耗更多的Vector计算资源，开发者在延迟敏感场景中需要在精度与速度之间做出权衡。ops-nn仓库中的激活函数算子默认在float16精度下执行，提供了可选的高精度模式供开发者按需启用。高精度模式适用于对数值精度要求严格的场景，例如金融风控模型、科学计算类模型等，这些模型对微小数值差异敏感，float16的精度损失可能影响最终输出的准确性。

下面的代码展示了在CANN框架中调用激活函数算子的典型方式：

from te import tvm
from topi import nn

def activation_compute(x_shape, act_type="relu", dtype="float16"):
    x = tvm.placeholder(x_shape, name="x", dtype=dtype)
    if act_type == "relu":
        y = nn.relu(x)
    elif act_type == "gelu":
        y = nn.gelu(x)
    elif act_type == "silu":
        y = nn.silu(x)
    else:
        raise ValueError("Unsupported activation type")
    schedule = tvm.create_schedule(y.op)
    return schedule, (x, y)

关于GELU的具体实现细节：标准的GELU公式中erf函数无法在硬件上直接计算，ops-nn仓库采用的近似方案是将输入区间划分为若干段，每段用不同阶数的多项式拟合。这种分段逼近的好处是多项式计算完全由Vector引擎的乘加指令完成，避免了昂贵的超越函数运算。代价是在分段边界附近存在微小误差，不过对于神经网络训练和推理而言，这种误差级别通常在可接受范围内。

SiLU函数的计算分为两个阶段。阶段一计算sigmoid值，Vector引擎对输入取负、指数运算、求倒数得到sigmoid输出。阶段二将sigmoid结果与原始输入逐元素相乘。两个阶段共享同一个Vector流水线，数据从GM加载一次、经过两次向量运算后写回GM。整个过程的数据流是GM到Vector到GM的直通路径，不需要经过L1/L0的额外缓存层级，这也是Vector引擎运算访存比较低的根本原因。

ReLU作为最简单的激活函数，在Vector引擎上的执行几乎不产生额外开销。当网络结构中大量使用ReLU时，单独将其作为一个算子执行会导致额外的GM读写：MatMul输出写回GM后，ReLU再从GM读取、计算、写回GM，整个过程产生一次冗余的完整往返。这正是融合优化的切入点。

在Transformer架构的推理场景中，GELU是前馈网络层和注意力输出层中使用最频繁的激活函数。一个典型的Transformer层包含两个MatMul+bias+GELU组合（MLP部分）和一个Softmax组合（Attention部分），其中MLP部分的融合优化空间最大。SiLU在某些版本的视觉Transformer和扩散模型中也被广泛采用，它的计算复杂度高于ReLU但低于GELU，融合收益与GELU相近。开发者应当根据网络结构中激活函数的分布来确定融合优化的优先级，优先对出现频率最高、矩阵尺寸最敏感的层进行融合处理。

matmul+bias+activation融合算子的内存访问优化

当MatMul、bias加法和激活函数作为三个独立算子依次执行时，数据需要在GM中经历多次完整读写：MatMul的输出写回GM，bias加法从GM读取MatMul输出并写回GM，激活函数再从GM读取bias加法结果最终写回GM。这条路径中存在两段冗余的GM访问，每段冗余访问都消耗HBM带宽并增加端到端延迟。

ops-nn仓库提供的融合算子将这三步合并为单一算子执行。融合后的数据流变为：MatMul在Cube引擎完成矩阵乘后，其输出不写回GM，直接留在L1中；bias加法在Vector引擎上从L1读取中间结果，加上bias后写回L1；激活函数继续在Vector引擎上对L1中的数据执行逐元素计算，最终将结果写回GM。整条路径中，中间结果始终留在片上存储中，消除了两段GM往返。

这种优化在带宽受限场景下效果尤为明显。当矩阵尺寸较大、计算密度足够时，Cube引擎本身的计算时间占主导，消除GM往返带来的收益在整体延迟中占比较小。矩阵尺寸较小或批量维度较小时，算子的计算访存比降低，带宽成为瓶颈，融合优化消除的GM访问在总耗时中的占比大幅上升，此时融合收益最为可观。

以下代码展示了融合算子的调用方式，将MatMul、bias和激活函数的配置集中在一个算子中：

from te import tvm
from topi import nn
from topi.util import get_const_tuple

def matmul_bias_act_fused(x_shape, w_shape, bias_shape,
                          act_type="relu", dtype="float16"):
    x = tvm.placeholder(x_shape, name="x", dtype=dtype)
    w = tvm.placeholder(w_shape, name="w", dtype=dtype)
    bias = tvm.placeholder(bias_shape, name="bias", dtype=dtype)
    # MatMul: x(M,K) * w(K,N)
    matmul_out = tvm.compute(
        (x_shape[0], w_shape[1]),
        lambda i, j: tvm.sum(x[i, tvm.reduce_axis((0, x_shape[1]), "k")]
                             * w[tvm.reduce_axis((0, x_shape[1]), "k"), j]),
        name="matmul_out"
    )
    # BiasAdd: broadcast along batch dimension
    bias_out = tvm.compute(
        (x_shape[0], w_shape[1]),
        lambda i, j: matmul_out[i, j] + bias[j],
        name="bias_out"
    )
    # Activation
    if act_type == "relu":
        y = tvm.compute(
            (x_shape[0], w_shape[1]),
            lambda i, j: tvm.max(bias_out[i, j], tvm.const(0, dtype)),
            name="relu_out"
        )
    elif act_type == "gelu":
        y = nn.gelu(bias_out)
    elif act_type == "silu":
        y = nn.silu(bias_out)
    schedule = tvm.create_schedule(y.op)
    return schedule, (x, w, bias, y)

融合算子的配置中有一个容易被忽视的参数是buffer空间的分配策略。L1需要同时容纳MatMul的输出tile和bias数据，Tile尺寸的选取必须确保这两部分数据加上必要的临时空间不超过L1的总容量。如果tile选得过大，L1溢出会导致运行时报错；tile选得过小，又会增加循环次数，降低Cube引擎的有效利用率。CANN框架提供了tiling配置接口，开发者可以根据目标NPU型号的L1容量手动设置tile参数。

对于激活函数为GELU或SiLU的情况，Vector引擎上的计算量相比ReLU更大。GELU的分段多项式逼近涉及多次乘加运算，SiLU需要先计算sigmoid再执行乘法。在融合算子中，这些额外的Vector计算紧跟在Cube输出之后执行，不会引入额外的GM访问，但会增加Vector引擎的占用时间。在Cube和Vector串行执行的模式下，Vector计算时间会成为Cube引擎空闲等待的原因之一。

以下是融合算子的性能调优配置示例，展示如何通过tiling参数和buffer配置优化执行效率：

from te import platform
from tiling import register_tiling_handler

def matmul_bias_act_tiling_config():
    config = {
        "block_dim": 1,
        "tile_size": {
            "M": 128,
            "N": 256,
            "K": 128
        },
        "buffer_space": {
            "L1": "auto",
            "L0A": "auto",
            "L0B": "auto",
            "L0C": "auto"
        },
        "double_buffer": True,
        "a_transpose": False,
        "b_transpose": False
    }
    return config

double_buffer机制是另一个值得关注的调优手段。启用后，DMA引擎在Cube计算当前tile的同时，将下一个tile的数据从L1预取到L0A和L0B。这样Cube引擎完成当前tile计算后可以无缝切换到下一个tile，无需等待DMA搬运。代价是L0A和L0B各需要一份额外的空间存放预取数据，总的L0占用翻倍。在小tile场景下L0空间充裕，double_buffer几乎总是有益的；在大tile场景下空间紧张，启用double_buffer可能导致tile尺寸被迫缩小，反而得不偿失。

数据转置标志a_transpose和b_transpose影响输入矩阵在L1中的布局和DMA搬运策略。当输入矩阵的布局恰好适合直接分块加载时，关闭转置可以避免额外的数据重排开销。某些场景下（例如注意力机制中的K^T矩阵），输入本身已处于转置友好布局，设置b_transpose=True可以让DMA引擎直接搬运而无需运行时转置。

融合前后性能对比与最佳实践

将MatMul、bias加法和激活函数从独立算子变为融合算子后，性能变化的维度包括GM带宽消耗、端到端延迟和片上存储利用率。下表列出了各维度的对比情况：

维度	使用前（独立算子）	使用后（融合算子）	差异来源
GM带宽消耗	MatMul写回GM+bias读GM写GM+activation读GM写回GM	仅最终结果写回GM	消除了两段GM中间结果往返
端到端延迟	受GM带宽瓶颈限制，延迟较高	中间结果留在片上，延迟降低	HBM带宽节省直接转化为延迟缩短
L1缓冲占用	各算子独立使用L1，峰值占用低	需要同时容纳输出tile和bias数据，占用较高	融合要求更大的连续L1空间
Vector计算延迟	激活函数单独调度，开销独立	融合后Vector紧随Cube执行，开销不变	Vector计算量未变，无法减少

从上表可以看出，GM带宽消耗和端到端延迟在融合后获得明显改善，这是消除中间GM访问的直接效果。L1缓冲占用的增加是融合的代价——更大的tile意味着更少的循环迭代和更高的Cube利用率，也要求更多的L1空间。Vector计算延迟一行标注为"开销不变"，说明融合本身并不能减少激活函数的计算量，当网络结构中GELU或SiLU占比较高时，Vector引擎上的计算开销不会因为融合而减少，这一点需要开发者有合理的性能预期。

在实际部署融合算子时，需要根据场景特征选择合适的配置策略。对于批量较小、矩阵尺寸适中的推理场景（如在线推理服务中的单次请求），融合优化的收益最为显著，因为此时带宽瓶颈最为突出。对于大批量离线推理或训练场景，计算密度已经很高，融合带来的额外L1空间需求可能需要缩小tile尺寸，部分抵消了带宽节省的收益。在实际的NPU性能profiling中，开发者可以通过CANN提供的profiling工具获取算子级别的HBM带宽利用率和计算单元利用率，据此判断当前场景是计算受限还是带宽受限。计算受限场景下融合优化的优先级可以降低，带宽受限场景则应当优先尝试融合策略。

ops-nn仓库的融合算子实现已经封装了Cube-Vector协同调度的底层细节，开发者只需指定输入shape、dtype和激活函数类型即可调用。仓库提供的tiling配置接口允许对tile尺寸、double_buffer、转置策略等参数进行微调。建议在首次部署时使用默认配置完成功能验证，再根据性能profiling结果逐步调整tiling参数。

结尾

本文从昇腾NPU的Cube和Vector双引擎架构出发，拆解了ops-nn仓库中MatMul算子的四级存储数据流、激活函数的Vector引擎实现机制，以及matmul+bias+activation融合算子消除中间GM访问的优化原理。通过代码示例和硬件约束分析，展示了CANN框架下神经网络算子的执行路径与调优方法。融合优化的核心价值在于将中间结果留在片上存储中，减少HBM带宽消耗，开发者需要根据实际shape和dtype特征合理评估融合收益，在tile尺寸、double_buffer和精度策略之间找到平衡点。

---

仓库链接：https://atomgit.com/cann/ops-nn