1. 算子适配概述

各位同学，咱们今天聊聊算子适配。说实话，这个概念刚入行时我也觉得挺虚的——不就是把算子从A平台搬到B平台吗？后来踩了坑才明白，这事儿远没那么简单。

1.1 什么是算子适配

算子适配，说白了就是让一个在GPU或CPU上写好的算子，能在NPU上正确、高效地跑起来。你想想看，不同芯片的指令集、内存架构、计算单元都不一样，直接拿过来用肯定不行。

我习惯把算子适配比作「翻译」：

• 源语言：PyTorch/TensorFlow 的算子定义
• 目标语言：NPU 的底层指令或计算库接口
• 翻译质量：不仅结果要对，速度还不能慢

举个例子，一个简单的 Conv2D 算子，在 GPU 上用 cuDNN 一行代码搞定。但到了 NPU 上，你得考虑数据排布是 NHWC 还是 NCHW，卷积算法是用 Winograd 还是 Im2Col，甚至要手动做算子融合。这些就是适配要干的事。

1.2 算子适配在NPU推理中的角色

NPU 推理流程里，算子适配处在什么位置？我画了张图，你看完就明白了。

从图上你能看到，算子适配夹在模型导出和NPU推理之间。它是个承上启下的环节——上面接的是框架无关的模型表示，下面接的是硬件相关的执行引擎。

我在项目中遇到过一种情况：模型在GPU上精度99.2%，一上NPU直接掉到85%。查了两天才发现，是某个LayerNorm算子的实现里用了不同的累加顺序，导致数值误差累积。这就是算子适配没做到位的典型后果。

1.3 适配流程总览

算子适配到底怎么做？我总结了一套流程，这些年一直在用，分享给你。

阶段	主要工作	产出物	常见坑
算子分析	梳理模型中的算子类型、参数、数据流	算子清单、依赖关系图	漏掉动态shape的算子
映射规划	确定每个算子的适配策略（直接映射/组合实现/自定义）	适配方案文档	高估NPU原生算子的覆盖范围
实现开发	编写算子适配代码，包括数据排布转换、计算逻辑	适配后的算子库	忽略边界条件和异常输入
精度验证	逐算子对比输出，确保误差在容忍范围内	精度对比报告	只比最终结果，不比中间层
性能调优	分析瓶颈，做算子融合、内存复用、流水线优化	性能分析报告	过早优化，没先保证正确性
集成测试	端到端跑通，验证整网精度和性能	测试报告	测试场景单一，覆盖不全

这六个阶段不是严格串行的。我个人的习惯是：先快速走一遍1-3，跑通一个最小可用的版本，然后再回头做精度和性能的迭代优化。这样能尽早发现问题，避免到最后才发现方向错了。

1.4 一个简单的适配示例

光说不练假把式。咱们看一个实际的例子——ReLU算子的适配。

在PyTorch里，ReLU就是一行：

import torch
x = torch.randn(4, 4)
y = torch.relu(x)

到了NPU上，假设我们的NPU提供底层接口 npu_eltwise_max，那适配代码大概长这样：

// NPU ReLU 适配实现
__kernel void relu_kernel(
    __global const float* input,
    __global float* output,
    int size
) {
    int idx = get_global_id(0);
    if (idx < size) {
        // 等价于 max(0, x)
        output[idx] = npu_eltwise_max(0.0f, input[idx]);
    }
}

你看，逻辑上就是取0和输入的最大值。但实际适配时，你还要考虑：

• 数据是FP32还是FP16？精度转换在哪做？
• 输入数据在NPU内存里是什么排布？需不需要重排？
• 这个算子能不能和前面的Conv融合，省掉一次内存读写？

1.5 适配的两种模式

根据适配的深度，我把它分成两种模式：

模式	做法	适用场景	优缺点
轻量适配	直接调用NPU厂商提供的算子库	常见算子（Conv、Pool、FC等）	开发快，但灵活性差
深度适配	手写NPU kernel，精细控制计算和内存	自定义算子、性能瓶颈算子	性能好，但开发周期长

实际项目中，两种模式会混合使用。我一般的原则是：80%的算子用轻量适配，剩下20%的瓶颈算子做深度适配。这样能在开发效率和最终性能之间取得平衡。

1.6 本章小结

算子适配，说白了就是让模型能在NPU上正确高效地跑起来。它处在模型导出和NPU推理之间，是个承上启下的关键环节。适配流程包括算子分析、映射规划、实现开发、精度验证、性能调优和集成测试六个阶段，每个阶段都有各自的坑要注意。

嗯，这一章先给你搭个框架。后面我们会一步步深入每个环节，到时候我会拿实际项目里的案例跟你细讲。