3、NPU算子栈全景：从框架层到硬件层的算子调用链路、各层职责划分
各位同学，今天我们来聊聊NPU算子栈的全景。
说实话，很多做算法的人，写了个算子，跑通了，就觉得完事了。但在我眼里，这只是万里长征第一步。你写的那个算子，从Python代码敲下去，到最终在NPU芯片上真正跑起来，中间要经过多少层？每一层都在干什么？
我个人习惯把算子栈比作一个「接力赛」。框架层是发令员，硬件层是冲刺的运动员，中间每一棒都不能掉。今天我就带大家把这个赛道从头到尾走一遍。
3.1 算子调用链路全景图
先给个宏观印象。一条完整的算子调用链路，大致长这样：
用户代码 (Python)
↓
AI框架层 (PyTorch/TensorFlow/MindSpore)
↓
框架适配层 (Adapter/Bridge)
↓
算子注册与调度层 (Operator Registry & Scheduler)
↓
算子实现层 (Kernel Implementation)
↓
运行时/驱动层 (Runtime & Driver)
↓
NPU硬件层 (Tensors/Vector/Matrix Unit)
嗯，这里要注意，不同厂商的NPU，中间层的名字可能不一样。比如华为的CANN，英伟达的CUDA，Google的TPU有自己的XLA。但本质上的分层逻辑，大同小异。
3.2 各层职责深度拆解
3.2.1 框架层：用户视角的「舒适区」
框架层，说白了就是用户最熟悉的那层。你写一句 torch.nn.Conv2d(...)，或者 tf.nn.conv2d(...)，这就是在框架层干活。
这一层的核心职责是什么？
- 提供算子API：让用户用最自然的方式表达计算意图。
- 构建计算图：把用户的操作串成一个有向无环图（DAG）。
- 做初步的图优化：比如算子融合、常量折叠、死代码消除。
我在项目中遇到过一个问题：用户用PyTorch写了一个很复杂的模型，里面有很多小算子。框架层做图优化时，把这些小算子融合成了一个大的算子。结果呢？性能提升了30%。这就是框架层干的好事。
3.2.2 框架适配层：翻译官的角色
这一层，我称之为「翻译官」。它的任务是把框架的算子描述，翻译成NPU能理解的中间表示。
举个例子，PyTorch里有个 torch.add，MindSpore里也有个 ops.Add。它们做的事情一样，但接口不同。框架适配层就要负责把这些「方言」统一成「普通话」。
我记得有一次，我们要适配一个全新的框架。框架适配层写了整整两周，因为每个算子的参数映射、数据类型转换、内存布局，都得一个一个对。稍有不慎，结果就错了。
3.2.3 算子注册与调度层：谁该上场？
这一层，是算子栈的「大脑」。它要回答三个问题：
- 这个算子有没有对应的NPU实现？ 如果没有，是报错，还是fallback到CPU？
- 如果有多个实现，选哪个？ 比如有的实现快但精度低，有的慢但精度高。
- 怎么调度？ 是同步执行，还是异步执行？要不要做内存预分配？
这里有个典型的场景：
// 伪代码：算子注册
REGISTER_OP("Conv2D")
.Input("input: float16")
.Input("filter: float16")
.Output("output: float16")
.SetShapeFn(Conv2DShape)
.SetKernelCreator(CreateConv2DKernel);
你想想看，如果没有这一层，每个算子都得硬编码到框架里，那维护成本得多高？
3.2.4 算子实现层：真正的「硬核」部分
到了这一层，才真正开始写NPU代码。这一层，我们通常用C/C++或者某种DSL（领域特定语言）来写。
算子实现层要干的事：
- 数据搬运：从DDR搬到SRAM，或者从SRAM搬到计算单元。
- 计算逻辑：用NPU的向量单元、矩阵单元、标量单元完成计算。
- 数据写回：把结果从SRAM写回DDR。
举个例子，一个简单的向量加法：
// 伪代码：NPU向量加法
void vector_add(float16* dst, float16* src1, float16* src2, int n) {
// 1. 搬运数据到SRAM
dma_load(sram_buf1, src1, n * sizeof(float16));
dma_load(sram_buf2, src2, n * sizeof(float16));
// 2. 向量计算
vec_add(sram_dst, sram_buf1, sram_buf2, n);
// 3. 写回结果
dma_store(dst, sram_dst, n * sizeof(float16));
}
看着简单吧？但实际写起来，要考虑的事情多了去了。比如：
- 数据对齐问题：NPU通常要求128字节对齐。
- 流水线问题：怎么让DMA搬运和计算重叠起来。
- 边界处理问题：数据量不是向量单元的整数倍怎么办。
3.2.5 运行时/驱动层：最后的「传令兵」
这一层，离硬件最近。它的职责是：
- 任务下发：把算子实现层编译好的二进制指令，通过驱动写入NPU的指令队列。
- 内存管理：管理NPU上的显存，做分配、回收、地址映射。
- 同步与异步：管理CPU和NPU之间的同步机制。
我刚开始做NPU开发时，总觉得这一层没什么技术含量。直到有一次，我写了一个算子，在仿真器上跑得好好的，一上板子就崩。查了三天，最后发现是驱动层的内存分配出了问题——分配的内存地址不对齐。
嗯，从那以后，我再也不敢小看驱动层了。
3.2.6 硬件层：真正的「执行者」
最后，指令到达了硬件层。NPU芯片上，通常有这几类计算单元：
| 单元类型 | 典型用途 | 数据位宽 |
|---|---|---|
| 标量单元 (Scalar Unit) | 地址计算、循环控制 | 32位 |
| 向量单元 (Vector Unit) | 逐元素运算、激活函数 | 128位~512位 |
| 矩阵单元 (Matrix Unit) | 矩阵乘法、卷积 | 16x16 ~ 128x128 |
| 数据搬运单元 (DMA) | DDR与SRAM之间的数据搬运 | 128位~512位 |
硬件层的核心逻辑，就是「取指-译码-执行-写回」。只不过，NPU的指令是VLIW（超长指令字）格式，一条指令里可以同时控制标量、向量、矩阵、DMA四个单元并行工作。
3.3 一条完整的调用链路示例
咱们用一个具体的例子串一下：
- 用户写代码：
y = torch.relu(x) - 框架层：PyTorch把这个操作加入计算图，生成一个
aten::relu的节点。 - 适配层：把
aten::relu映射到NPU的Relu算子。 - 调度层：检查有没有注册
Relu的实现。有，选一个最优的。 - 实现层：执行
vec_max(sram_dst, sram_src, 0)，把小于0的置0。 - 驱动层：把这条指令写入NPU的命令队列，触发硬件执行。
- 硬件层：向量单元并行处理所有元素，结果写回DDR。
你看，从你敲下代码到结果出来，中间经历了7层。每一层都在做自己该做的事，少一层都不行。
3.4 我的个人建议
最后，给各位同学一点个人建议：
- 不要只盯着自己那一层：写算子实现的，也要了解框架层怎么调你的；做框架适配的，也要知道硬件层能干什么。
- 学会看日志：算子出问题了，先看是哪一层报的错。框架层报错，多半是API用错了；驱动层报错，多半是内存或地址问题；硬件层报错，那就要看波形了。
- 多做端到端测试：我习惯每写完一个算子，就从框架层开始，一路测到硬件层。确保每一层的输出都是对的。
好了，算子栈全景就讲到这里。下一章，咱们开始动手写第一个自定义算子。到时候，你会更深刻地理解今天讲的这些内容。