第4章算子映射基础

第1章：算子映射基础

1.1 算子映射的定义与目标

算子映射，说白了就是——把深度学习模型里的各种算子，翻译成NPU能听懂的话。

你想想看，PyTorch或者TensorFlow里写的Conv2D、ReLU、BatchNorm，这些算子都是跑在GPU或者CPU上的。但NPU的指令集完全不一样，它有自己的计算单元、数据流、存储层次。所以我们需要一个「翻译官」，把模型里的算子，映射到NPU上可执行的指令序列。

我个人习惯把算子映射分成两个层面：

逻辑映射：算子的语义是否等价。比如NPU不支持某个算子，能不能拆成几个小算子组合实现？
物理映射：算子的数据排布、计算模式是否匹配NPU的硬件特性。比如NPU的MAC阵列是16x16的，你的卷积核大小是3x3，怎么映射效率最高？

我在项目中遇到过最头疼的事——模型在GPU上跑得好好的，一上NPU就崩。查到最后发现，有个算子叫「torch.nn.functional.upsample_bilinear2d」，NPU的指令集里根本没有。这就是映射没做好。

算子映射的核心目标：

功能正确：映射后的指令序列，计算结果和原始算子完全一致（或者误差在允许范围内）
性能高效：充分利用NPU的计算资源、带宽、存储层次
内存可控：映射过程中产生的中间数据，不能超出NPU的片上存储上限

嗯，这里要注意一点——功能正确是底线，性能高效是追求。我曾经为了追求极致性能，把一个算子映射得花里胡哨，结果精度掉了0.5个点，被算法团队追着骂了一周。

1.2 One-to-One映射

One-to-One映射，是最简单、最理想的情况。

什么意思？就是模型里的一个算子，NPU刚好有一个对应的硬件指令或者微码序列，可以直接执行。不需要拆，不需要合，直接怼上去就行。

举个例子：

// 模型中的ReLU算子
output = relu(input)

// NPU指令集中有对应的ReLU指令
NPU_RELU(input_addr, output_addr, size)

这种映射的好处很明显：

开发工作量最小，几乎不需要额外的代码生成逻辑
性能损失最小，因为硬件原生支持
调试最容易，出问题直接定位到硬件指令

但现实很骨感。我做过一个统计，在常见的视觉模型里，能直接One-to-One映射的算子大概只占30%~40%。剩下的都得折腾。

我的经验：One-to-One映射虽然简单，但别掉以轻心。我记得有一次，NPU的ReLU指令要求输入数据必须是16字节对齐的，模型里传过来的数据没对齐，结果跑出来全是0。排查了整整两天。

常见的One-to-One映射算子包括：

模型算子	NPU指令	注意事项
ReLU	NPU_RELU	数据对齐要求
Add	NPU_ADD	输入shape必须一致
Mul	NPU_MUL	广播规则需预处理
Concat	NPU_CONCAT	axis参数映射

1.3 One-to-Many映射

One-to-Many映射，就是一个算子拆成多个NPU指令来执行。

为什么会这样？说白了就是NPU的指令粒度太粗，或者硬件不支持某些复杂操作。

我印象最深的是LayerNorm算子。模型里写起来就一行：

output = layer_norm(input, normalized_shape, weight, bias)

但NPU没有直接的LayerNorm指令。怎么办？拆！

// 第一步：计算均值
NPU_REDUCE_MEAN(input, mean, axis=-1)

// 第二步：计算方差
NPU_SUB(input, mean, diff)
NPU_MUL(diff, diff, sq_diff)
NPU_REDUCE_MEAN(sq_diff, var, axis=-1)

// 第三步：归一化
NPU_ADD(var, eps, var_eps)
NPU_RSQRT(var_eps, inv_std)
NPU_MUL(diff, inv_std, normalized)

// 第四步：仿射变换
NPU_MUL(normalized, weight, scaled)
NPU_ADD(scaled, bias, output)

你看，一个LayerNorm拆成了7条NPU指令。这就是典型的One-to-Many映射。

避坑指南：One-to-Many映射最怕的是中间数据爆炸。我曾经把一个GroupNorm拆成20多条指令，结果中间数据把片上SRAM撑爆了。后来不得不做分块计算，把数据切小了再处理。

One-to-Many映射的关键点：

中间数据管理：拆出来的每条指令都会产生中间结果，这些数据放哪里？片上还是片外？
计算顺序优化：有些指令可以并行执行，有些必须串行。怎么调度效率最高？
精度控制：拆得越细，浮点误差累积越多。我见过一个模型，拆完以后精度掉了2个点，最后发现是中间数据截断导致的。

1.4 Many-to-One映射

Many-to-One映射，就是多个算子合并成一个NPU指令或者一个计算核。

你可能会问：为什么要合并？

原因很简单——减少数据搬运。NPU最怕的就是数据在片上片外来回倒腾。如果能一次把多个算子算完，中间数据留在片上，性能能翻好几倍。

经典的例子是Conv-BN-ReLU融合：

// 模型中的三个算子
conv_out = conv2d(input, weight, bias)
bn_out = batch_norm(conv_out, running_mean, running_var, gamma, beta)
output = relu(bn_out)

// 融合成一个NPU指令
NPU_CONV_BN_RELU(input, weight, bias, running_mean, running_var, gamma, beta, output)

我在项目中做过一个统计，Conv-BN-ReLU融合以后，性能提升了大概40%。因为省掉了两次数据写回片外和两次读入的时间。

常见的Many-to-One融合模式：

Conv + BN + ReLU（最经典）
Conv + Add + ReLU（残差结构常用）
MatMul + Add + Softmax（Attention结构）
Gemm + ReLU（全连接层）

但融合不是万能的。我记得有一次，想把Conv + BN + ReLU + MaxPool四个算子融合在一起，结果NPU的指令长度有限制，塞不下那么多参数。最后只能退而求其次，融合前三个，Pool单独算。

1.5 映射表的构建与维护

映射表，就是算子映射的「字典」。模型里的每个算子，都能在映射表里查到对应的NPU指令序列。

映射表长什么样？我一般用这样的结构：

// 映射表条目结构
struct OpMapping {
    string op_type;          // 算子类型，如 "Conv2D"
    string op_version;       // 算子版本，如 "v1.0"
    string npu_kernel;       // NPU核函数名
    int num_instructions;    // 指令条数
    bool is_fused;           // 是否融合算子
    float estimated_cost;    // 预估计算代价
    vector<string> constraints; // 约束条件
};

构建映射表的过程，我习惯分三步走：

算子注册：把模型框架（PyTorch/TensorFlow/ONNX）里所有可能出现的算子，都注册到映射表里
映射规则编写：为每个算子编写映射规则，包括参数转换、数据排布转换、指令序列生成
验证与迭代：跑测试用例，验证映射结果的正确性和性能，不满足就回炉重造

映射表的维护，说实话，是编译器开发里最烦人的活。因为模型框架在更新，NPU硬件也在迭代，映射表得跟着变。

我的习惯：映射表一定要版本化管理。我见过一个团队，映射表放在一个Excel里，谁改了什么都不知道。后来出了线上事故，查了三天才发现是映射表被覆盖了。从那以后，我坚持用代码生成映射表，并且每个版本都打tag。

映射表维护的几个要点：

自动化测试：每次修改映射表，都要跑全量算子测试，确保没有回归
性能基线：记录每个算子的性能基线，映射表改了以后对比性能变化
兼容性管理：旧模型用的算子映射，新版本NPU还能不能用？需要做向前兼容

最后，我画了一张算子映射的整体流程图，帮你理清思路：

这张图展示了算子映射的完整流程。模型算子先查映射表，匹配成功就直接生成NPU指令；匹配失败就做分解或组合，再重新查表。最后所有指令都要经过正确性和性能验证。

嗯，映射表这块内容其实挺多的，今天先讲到这里。后面几章我们会深入每个映射模式的具体实现，包括参数转换、数据排布优化、指令调度等等。

📚 课程目录

第1章：算子映射基础

1.1 算子映射的定义与目标

1.2 One-to-One映射

1.3 One-to-Many映射

1.4 Many-to-One映射

1.5 映射表的构建与维护