训练营简介
2025年昇腾CANN训练营第二季，基于CANN开源开放全场景，推出0基础入门系列、码力全开特辑、开发者案例等专题课程，助力不同阶段开发者快速提升算子开发技能。获得Ascend C算子中级认证，即可领取精美证书，完成社区任务更有机会赢取华为手机，平板、开发板等大奖。

报名链接：https://www.hiascend.com/developer/activities/cann20252#cann-camp-2502-intro

前言

在高性能计算领域，有一个著名的公式：计算密度 = FLOPs / Bytes。 AI Core 的算力（Vector/Cube）增长速度远超内存带宽（HBM/DDR）的增长速度。对于大多数 Element-wise（逐元素）操作，如 Add、Relu、Cast，瓶颈通常不在计算，而在IO（输入输出）。

传统的深度学习框架执行模式是“单算子单调度”： Op1(Read -> Compute -> Write) -> Op2(Read -> Compute -> Write)

这意味着中间结果被反复写入 GM（Global Memory）又读出。这就像做饭，切完菜把菜放回冰箱，炒菜时再去冰箱拿，效率极低。

融合算子（Kernel Fusion） 的核心思想就是：切完菜直接扔锅里。 即：FusedOp(Read -> Compute1 -> Compute2 -> Write)。

本期文章将深度解析如何在 Ascend C 中实现算子融合，并通过一个 AddRelu 的实战案例，展示如何打破内存墙，实现极致性能。

一、 融合算子的核心架构与收益

在 Ascend C 的编程模型中，UB（Unified Buffer）是算子融合的天然温床。

1.1 收益模型分析

假设我们需要计算 $Z = \text{Relu}(X + Y)$。

• 非融合模式：

  1. Add 算子：读 X, Y (GM->UB) -> 加法 -> 写 Tmp (UB->GM)。

  2. Relu 算子：读 Tmp (GM->UB) -> 激活 -> 写 Z (UB->GM)。

  • 总 IO：4 读 2 写。

  • 总调度：2 次启动开销。

• 融合模式：

  1. AddRelu 算子：读 X, Y (GM->UB) -> 加法 (Result在UB) -> 激活 (Result在UB) -> 写 Z (UB->GM)。

  • 总 IO：2 读 1 写。

  • 总调度：1 次启动开销。

结论：融合后，IO 数据量减少了 50%，理论带宽性能提升一倍。

二、 实战：编写 AddRelu 融合算子

在 Ascend C 中实现融合非常自然，本质上就是在一个 Compute 函数中连续调用多个计算接口，而不进行中间数据的 CopyOut。

2.1 算子原型定义

首先定义一个新的算子 AddRelu。

[
    {
        "op": "AddRelu",
        "input_desc": [
            {"name": "x", "type": ["fp16"], "format": ["ND"]},
            {"name": "y", "type": ["fp16"], "format": ["ND"]}
        ],
        "output_desc": [
            {"name": "z", "type": ["fp16"], "format": ["ND"]}
        ]
    }
]

2.2 Kernel 实现 (核心逻辑)

代码结构与之前的 AddCustom 高度相似，区别在于 Compute 阶段。

#include "kernel_operator.h"
using namespace AscendC;

class KernelAddRelu {
public:
    __aicore__ inline void Init(GM_ADDR x, GM_ADDR y, GM_ADDR z, uint32_t totalLength, uint32_t tileLength) {
        // ... 初始化逻辑略，参考 AddCustom ...
        // 注意：UB 空间规划可能需要调整，因为可能需要更多 Tensor
    }

    __aicore__ inline void Process() {
        // ... Tiling 循环 ...
        CopyIn(i);
        Compute(i);
        CopyOut(i);
    }

private:
    __aicore__ inline void Compute(int32_t i) {
        // 1. 从队列获取输入
        LocalTensor<half> xLocal = inQueueX.DeQue<half>();
        LocalTensor<half> yLocal = inQueueY.DeQue<half>();
        LocalTensor<half> zLocal = outQueueZ.AllocTensor<half>();

        // 2. 执行 Add 计算 (结果暂存在 zLocal 中)
        // 注意：此时数据还在 UB 里，没有出去
        Add(zLocal, xLocal, yLocal, tileLength);

        // 3. 执行 Relu 计算 (原地操作 In-place)
        // 直接对 zLocal 进行激活，覆盖原值，无需申请新 Tensor
        Relu(zLocal, zLocal, tileLength);

        // 4. 释放输入，入队输出
        inQueueX.FreeTensor(xLocal);
        inQueueY.FreeTensor(yLocal);
        outQueueZ.EnQue(zLocal);
    }
    // ... CopyIn/CopyOut 逻辑保持不变 ...
};

关键技术点：

• In-place Computation（原地计算）：在步骤 3 中，Relu 的输入和输出都是 zLocal。Ascend C 的许多 Vector 指令支持输入输出地址重叠，这极大节省了 UB 空间。

• 中间变量消除：我们不需要为 Add 的结果专门申请一个 tmpTensor，直接用输出 Tensor zLocal 承接即可。

三、 融合算子的挑战与边界

虽然融合看起来很美，但并不是所有算子都能无脑融合。

3.1 UB 容量瓶颈

融合的算子越多，往往意味着输入的 Tensor 越多。 例如 A + B + C + D，你需要同时把 4 个 Tensor 的分块搬进 UB。如果 UB 只有 192KB，分配给每个 Tensor 的 TileLength 就会变得很小。 后果：Tile 越小，搬运次数越多，MTE 单元的启动开销占比越大，反而可能导致性能下降。

优化策略：

• 流水线重排：如果算子间存在依赖链（如 (A+B)*C），可以先搬 A 和 B，算完释放空间后再搬 C。

• 算子拆分：如果融合链太长导致 Tile 过小，不如拆成两个中等规模的融合算子。

3.2 寄存器压力 (Register Pressure)

一个 Kernel 函数里的逻辑越复杂，占用的标量寄存器和向量寄存器就越多。当寄存器不够用时，编译器会发生 Spill（溢出），把数据暂时存到内存中，这会导致严重的性能回退。

3.3 精度累积

如第五期所述，长链路融合计算容易导致 FP16 精度累积误差。在融合算子中，更容易忽视中间步骤的精度修饰。建议关键节点强转 FP32。

四、 进阶：UB 融合 vs L1 融合

我们今天讲的是最基础的 UB 融合（UB Fusion），主要针对 Vector 单元。 在昇腾架构中，还有一种更高级的 L1 融合，主要针对 Cube 单元的矩阵运算。

• UB 融合：数据在 Unified Buffer 停留，适合 Vector-Vector 级联。

• L1 融合：数据在 L1 Buffer（Cube 单元的输入缓存）或 L0 Buffer（累加缓存）停留，适合 MatMul-Bias-Relu 这种“大算子”级联。

对于 Ascend C 开发者，Vector 融合是基本功，而 L1 融合则更多依赖 Matmul 高阶 API 的内部优化。

五、 总结

算子融合是提升 NPU 性能的“免费午餐”。通过简单的代码重构，将多次 IO 合并为一次，我们能轻松获得倍数级的性能提升。

融合心法口诀：

1. 能融则融：只要 UB 放得下，尽量把连续的 Vector 算子写在一个 Kernel 里。

2. 原地操作：善用 In-place 计算节省 UB 空间。

3. 量力而行：监控 Tiling 大小，别让 UB 碎片化导致 Tile 过小。