2. 算子映射基础：什么是算子映射？映射流程与关键挑战
好，咱们直接进入正题。算子映射这个词，听起来挺唬人的。说白了，它就是一道“翻译题”。
你想想看，我们平时写神经网络，用的是PyTorch、TensorFlow这些框架。框架里定义的卷积、池化、全连接，这些都是“算子”。但存算一体芯片不认识这些啊。芯片只认自己的指令集、数据流、存储阵列怎么摆。算子映射，就是把这些高层算子，翻译成芯片能执行的底层操作。
我个人习惯把这件事比作“把中文菜谱翻译成英文厨房操作”。菜谱上写“爆炒”，翻译成英文可能就是“high heat, quick stir-fry, 30 seconds”。算子映射也是类似——把抽象的数学运算，拆解成具体的硬件动作。
2.1 算子映射到底在做什么？
我举个例子你就明白了。假设我们要在存算一体芯片上跑一个3x3的卷积，输入是32x32的特征图。
在框架里，你只需要一行代码：
output = F.conv2d(input, weight, stride=1, padding=1)但在存算一体芯片上，你得考虑：
- 权重存在哪个存储阵列里？
- 输入数据怎么送到阵列的行线上？
- 卷积窗口滑动时，数据怎么复用？
- 累加结果怎么读出？
这些，就是算子映射要解决的问题。
核心定义：算子映射是将深度学习框架中的算子（如Conv2D、MatMul、ReLU），转化为存算一体芯片上可执行的硬件指令序列、数据流调度方案和存储布局策略的过程。
2.2 映射流程：三步走
我在项目中总结了一套流程，分三步。嗯，其实很多团队也这么干，但细节上各有各的坑。
第一步：算子分解
先把大算子拆成小算子。比如一个卷积，可以拆成：
- 输入数据加载
- 权重加载
- 乘累加运算（MAC）
- 偏置加法
- 激活函数（ReLU）
- 输出数据写回
为什么要拆？因为存算一体芯片的存储阵列，一次只能做“向量-矩阵乘法”这种基本操作。卷积这种带滑动窗口的，得先拆成多个矩阵乘法。
我的经验：拆的时候要注意粒度。拆太细，调度开销大；拆太粗，硬件资源利用率低。我曾经在一个项目里把卷积拆成了128个小块，结果调度器忙得团团转，性能反而下降了。后来改成64块，刚刚好。
第二步：数据流规划
这一步决定数据怎么在芯片里流动。核心问题有三个：
- 数据复用策略：权重是固定的，输入数据怎么复用？是行广播还是列广播？
- 数据分块：特征图太大，一次放不进存储阵列怎么办？得切块。
- 流水线安排：上一层的输出，怎么直接喂给下一层？能不能避免写回DRAM？
我举个例子。假设你的存储阵列是256x256的，但你的权重是512x512。那你就得把权重切成4块，分4次加载。每次加载一块，算一部分结果，最后累加。
这听起来简单，但切块的方式直接影响性能。我见过有人按行切，有人按列切，还有人按对角线切。不同的切法，数据复用的效率完全不同。
第三步：指令生成
最后一步，把规划好的数据流，翻译成芯片的指令序列。这一步很机械，但容易出错。
比如，你要生成一条“加载权重”的指令，得指定：
- 权重存在哪个存储阵列的哪一行？
- 是从片外DRAM加载，还是从片内SRAM加载？
- 加载完成后，要不要触发计算？
这些细节，一个不对，芯片就跑飞了。
避坑指南：我曾经在指令生成时，把权重地址算错了1个偏移量。结果整个卷积结果全是错的，排查了整整两天。后来我写了个自动化脚本，每次生成指令后自动校验地址范围。嗯，从此再没出过这类问题。
2.3 关键挑战：为什么这事不简单？
算子映射听起来就是三步走，但实际做起来，挑战一个接一个。我挑三个最头疼的说说。
挑战一：计算精度与数据类型的博弈
存算一体芯片常用INT8甚至更低精度。但训练好的模型往往是FP32的。怎么把FP32的权重映射到INT8的存储阵列上？
直接截断？精度损失太大。做量化？量化方法选哪个？对称量化还是非对称量化？每层单独量化还是全局量化？
我见过一个团队，为了省事，全局统一量化。结果模型精度掉了5个点，根本没法用。后来改成每层单独量化，精度只掉了0.3个点。
| 量化方式 | 精度损失 | 实现复杂度 |
|---|---|---|
| 全局统一量化 | 3%-8% | 低 |
| 每层单独量化 | 0.1%-0.5% | 中 |
| 每通道量化 | <0.1% | 高 |
挑战二：存储阵列的物理约束
存算一体芯片的存储阵列，不是你想怎么用就怎么用的。它有物理限制：
- 阵列大小固定（比如128x128、256x256）
- 读写端口有限
- 模拟计算的动态范围有限
- 不同阵列之间的通信带宽有限
这些约束，直接决定了你的算子映射方案。比如，你的卷积核是5x5的，但阵列只能做4x4的矩阵乘法。怎么办？
一种做法是把5x5的卷积核拆成4x4和1x4两块，分两次计算。另一种做法是把5x5补零成8x8，用更大的阵列一次算完。哪种好？看你的硬件支持哪种。
核心观点：算子映射不是纯软件问题，它必须和硬件架构深度耦合。你设计的映射方案，必须“知道”芯片的物理限制在哪里。
挑战三：动态形状与静态编译的矛盾
很多现代模型有动态形状。比如，输入图片大小不固定，或者有循环结构。但存算一体芯片的指令，通常是静态编译的——编译时就得确定好所有数据的大小和位置。
这就尴尬了。你编译时不知道输入多大，怎么生成指令？
一种解法是做“动态映射”，运行时根据实际输入大小，实时生成指令。但这要求芯片有很强的控制能力，而且实时编译的开销不小。
另一种解法是“多版本编译”，把可能出现的输入大小都编译好，运行时选一个。但这样编译出来的指令集很大，存储开销高。
我个人的建议是：如果你的模型输入大小变化不大，用多版本编译。如果变化很大，还是上动态映射吧，虽然麻烦，但更灵活。
2.4 一个完整的映射示例
说了这么多，咱们看个具体的例子。假设我们要映射一个3x3卷积，输入是8x8，输出是6x6（stride=1, padding=0）。
第一步，算子分解：
- 拆成9个1x1的乘累加操作（因为3x3卷积核有9个权重）
- 每个乘累加操作对应一个输入像素和一个权重
第二步，数据流规划：
- 把9个权重存在同一个存储阵列的不同行
- 输入数据按滑动窗口顺序送入
- 每个窗口的9个乘累加结果累加，得到1个输出像素
第三步，指令生成：
- LOAD_WEIGHT: 地址0x00-0x08, 存入阵列行0-8
- LOAD_INPUT: 地址0x10-0x18, 送入阵列列线
- COMPUTE: 执行向量-矩阵乘法
- READ_ACCUM: 读取累加结果
- STORE_OUTPUT: 写回输出缓冲区
重复LOAD_INPUT到STORE_OUTPUT，直到36个输出像素全部算完。
一个小技巧：实际做的时候，我会把LOAD_INPUT和COMPUTE指令合并成一条。这样能减少指令数量，提高流水线效率。但前提是你的芯片支持这种“加载即计算”的模式。
2.5 映射优化的核心思想
最后，我想说一个核心思想。算子映射优化，本质上是在做三件事的权衡：
- 计算效率：让存储阵列尽可能满负荷运转
- 数据复用：减少数据搬运，降低能耗
- 存储占用：别把片内存储撑爆了
这三件事经常互相矛盾。你想提高计算效率，就得让阵列满负荷，但可能数据复用就差了。你想提高数据复用，就得把数据多存几份，但存储占用就上去了。
我见过最极端的例子，有人为了追求100%的阵列利用率，把数据复制了8份。结果存储爆了，不得不频繁从片外搬数据，最终性能反而下降了30%。
所以，映射优化没有银弹。你得根据具体的芯片架构、模型结构、性能目标，找到那个平衡点。嗯，这就是这门课后面要讲的内容。
好了，算子映射的基础就讲到这里。记住，映射不是一次性的工作。你可能会反复调整，直到找到那个“黄金方案”。