本讲目标与路线

• 判断什么时候需要自定义算子
• 理解 TBE DSL 与 Ascend C 的分工
• 写出算子接口合同与最小验证骨架
• 区分编译、运行与硬件执行证据

本讲主线：算子合同 → TBE 原型 → Ascend C 证据

什么时候需要自定义算子

• CANN 算子库没有模型所需的算子。
• ATC 转换遇到不支持的算子或组合。
• 已有算子成为明确性能瓶颈。
• 后处理需要下沉到设备侧执行。

典型路径是先用 TBE DSL 快速验证功能，再决定是否用 Ascend C 重写热点。

310B 的计算单元与存储层次

• Cube Unit 承担矩阵乘法、卷积等高密度计算。
• Vector Unit 承担激活、归一化、池化和格式转换。
• Scalar Unit 负责控制流、地址计算与调度。
• Global Memory 经 L1 或 Unified Buffer 进入计算单元。
• MTE 负责多级缓冲之间的搬运、对齐与格式重排。

TBE DSL 与 Ascend C 的分工

两条路线不是互斥关系。本次双板记录只完成了第一条路线的功能验证。

算子首先是一份接口合同

原型或 .ini 写错时，计算代码可能正确，但图引擎仍无法找到或正确调用算子。

TBE DSL 的加法主线

1. 用 placeholder 描述输入张量与 dtype。
2. 用 broadcast 对齐输入 shape。
3. 用 vadd 描述逐元素加法。
4. 用 auto_schedule 生成调度。
5. 用 build 与 run 进入验证路径。

Ascend C 把数据流显式写出来

• Host 端准备输入、Tiling 参数并调用 Kernel。
• Device 端 Kernel 在 AI Core 上执行。
• SPMD 让各 Core 运行同一份代码、处理不同区间。
• 每个 Tile 执行 CopyIn、Compute、CopyOut。
• 多核偏移、双缓冲和 UB 容量由开发者管理。

Tiling 把大数据切进片上缓冲

Tiling 不只是按大小切分，还要同时考虑搬运次数、并行度、对齐和边界尾部。

矩阵加法 PASSED 仍是 TBE 等价验证

mat_add_tiling/run.py 的输出包含：

• Matrix add verification: PASSED
• 输入形状 (128, 256)，共 32768 个元素。
• 128KB 数据超过 UB，日志说明由 TBE DSL 自动处理 Tiling。
• 日志同时提示 Ascend C 手工 Tiling 源码是 mat_add_custom.cpp。

因此这次 PASSED 验证的是 TBE DSL 的等价矩阵加法与自动调度，不是手工 Tiling Kernel 的 NPU 执行。

双板证据表：只记通过到哪一层

双板环境均记录 Health: Alarm，只作诊断背景。本记录没有运行 msopgen，也没有生成或安装自定义算子包。

补齐 Ascend C 硬件证据的五步

1. 用 msopgen 生成算子工程与注册骨架。
2. 对齐算子原型、.ini 信息库和 Kernel 实现。
3. 编译并安装自定义算子包，记录 .o、.json、.so 与安装位置。
4. 在真实板卡用 AscendCL 加载和执行，保存退出码与原始日志。
5. 对同一输入比较 CPU 参考值、NPU 输出与边界 shape。

课堂任务：三层证据逐项勾选

课堂报告中必须分别写三行结论，禁止把三行合并成一句“算子已在 NPU 上通过”。