做端侧语音的同行大概都遇到过同一个尴尬算法同事在服务器上训好的卷积模型指标漂亮得能贴墙上一放到小智音箱这种 128KB 内存、百来兆主频的板子上跑一次要小半天实时性直接崩盘。我这次要聊的就是小智音箱加速卷积层特征提取这件事——具体点说是把一段 16kHz 的麦克风音频在端侧先变成 64 维的梅尔对数谱再送进一个小型卷积网络做特征提取和分类整个过程从原来的 100 毫秒压到 8.7 毫秒让这颗核从几乎被吃满回到只占一成。这里的关键词是定点化、卷积层、特征提取、SIMD 打包、访存优化。这篇内容适合三类人手上正被端侧推理性能卡住固件工程师、想把模型塞进低端硬件的算法同学以及刚接触嵌入式神经网络、想知道书上那些优化手段在真实板子上到底值几个毫秒的新手。我会把坑一个一个摊开讲包括我算错参数重训一次的教训。1. 先把问题摆清楚音箱端跑卷积到底卡在哪1.1 小智这个项目的时间预算有多紧小智音箱是我们内部给一个语音交互原型起的代号主控是一颗主频 120MHz 的 32 位音频 SoC带一块 128KB 的片上 SRAM没有独立 NPU也没有硬件浮点单元音频前端有一路 16kHz/16bit 的 I2S 麦克风输入。功能上要做的是本地关键词与声音事件识别主人喊小智小智要能唤醒厨房里玻璃碎裂、水流、油烟机这类声音也要能分辨出来一共 12 个类别。推理节奏是每 100 毫秒出一次结果也就是 10Hz。这个节奏不是随便定的——唤醒词要跟手超过 200 毫秒用户就会觉得这音箱有点傻而 100 毫秒的窗口配上 640 毫秒的滑动上下文误唤醒率能压得住。问题就出在这基线版本跑一帧要100.4 毫秒推理周期也是 100 毫秒等于这颗核 100% 被卷积吃掉。一旦播放器线程要解码 MP3或者蓝牙链路要收包立刻就丢帧表现为喊三声才应一声。这就是我要加速卷积层特征提取最原始的动机不是什么技术洁癖是产品真的不能用。1.2 算力、内存、带宽这三本账做端侧优化我习惯动手之前先把三本账算清楚否则容易在错误的方向上使劲。算力账120MHz 意味着每毫秒只有 12 万次时钟周期。如果按标量指令一次做一次乘加算一帧模型的 174 万次乘加需要 14.5 毫秒还没算循环开销和访存如果走软件浮点一次浮点乘法就要十来个周期直接爆到 100 毫秒以上——我们实测的基线就是这么来的。内存账128KB SRAM 里音频 DMA 双缓冲要 6.4KBFFT 工作区要 4KBlog-mel 特征环形缓冲要 4KB剩下的才轮到卷积用。最大的中间特征图是 64×32×16 的 int8正好 32KB两块乒乓就是 64KB加上 15KB 常驻权重勉强塞得下但余量只有不到 20KB。这个数字决定了后面所有的优化手段选择——任何会把特征图放大的方案比如标准 im2col直接出局。带宽账这颗核没有 cache所有数据都在 SRAM 里跑一次 32 位读要 1 个周期一次 32 位写要 1 个周期。也就是说理论上一个读权重、读激活、乘加、写累加的最优循环是 2 读 1 算瓶颈在取指和访存而不是 ALU。这解释了为什么后来我把循环顺序和寄存器分块调了一遍收益比单纯换 int8 还大。1.3 为什么选深度可分离卷积而不是直接搬骨干网选型阶段我们试过两套结构。一套是直接把移动端常用的瓶颈残差结构裁剪到 32 通道参数量 21 万实测乘加 6.8M另一套是纯深度可分离的堆叠结构参数量 1.5 万乘加 1.74M。前者准确率大概高 1.2 个百分点但耗时是后者的近四倍在 100 毫秒预算里根本放不下。我最终选后者还有一个容易被忽略的理由深度可分离结构的层数多、但每层的数据量小天然适合分块塞进小 SRAM也方便做逐层打点。如果是一整块大卷积你只能整体优化出了问题很难定位是哪一段慢。分成九层之后我能拿着计时器一层一层看哪个慢改哪个这个可观测性在资源紧张的板子上比理论效率更值钱。提醒一句深度可分离卷积在训练侧有个副作用3×3 深度卷积的权重初始化对最终精度影响比普通卷积大得多。我们第一版直接用默认初始化收敛后掉了 2.8 个点后来改成先训 pointwise 再解冻深度卷积的两段式训练才补回来。2. 整体设计把卷积前端拆成一条能跑满的流水线2.1 四段式切分与定点化的边界整条链路我切成四段采集与预加重 → 分帧加窗与 FFT → 梅尔滤波与对数 → 卷积特征提取与分类。切分的原则不是按算法模块而是按数据形态——前两段是流式实时数据每 10 毫秒必到一次必须做成中断驱动后两段是块式数据攒够 64 帧才触发一次可以放在主循环里跑。定点化的边界就落在第三段和第四段之间。前面全用 Q15 定点16 位1 位符号15 位小数后面的卷积全用 int8。为什么不统一因为 FFT 的衰减特性需要比较高的动态范围Q15 下信噪比损耗不到 0.3dB可以接受而卷积层的权重动态范围小、对量化更宽容用 int8 能把存储和带宽都砍到四分之一。这条边界我试过两种划法另一条是在 log-mel 输出后再转 int8结果因为 log 值域跨度太大0 到 8.9 左右简单线性量化掉点明显最后还是选了现在这样log-mel 出来后先做一次均值方差归一化压到约 [-4, 4]再乘 16 转 int8正好用满 -128 到 127 的范围。2.2 量化方案对称与非对称的取舍权重用对称量化激活用非对称量化——这是端侧最常规的搭配但它背后有具体原因。权重分布基本以 0 为中心、近似对称对称量化不需要零点zero point卷积累加时省掉一次零点补偿内核实现简单不少。激活不一样经过 ReLU 之后分布明显偏向正值如果硬用对称量化整个正半轴只能用掉 128 个量化级里的一半白白损失一位精度。真正麻烦的是**重量化requantization**这一步。int32 的累加结果要变回 int8中间要做一次acc × scale的乘法而 scale 是个小于 1 的浮点数。板子上跑浮点太贵标准做法是把它转成定点乘加移位/* mult 为 Q31 定点乘数shift 为右移位数zp 为输出零点 */ static inline int8_t requant(int32_t acc, int32_t mult, int shift, int32_t zp) { int64_t t (int64_t)acc * mult; /* 64 位中间量防溢出 */ int32_t r (int32_t)((t (1LL (shift - 1))) shift); /* 加半再移四舍五入 */ r zp; if (r -128) r -128; if (r 127) r 127; return (int8_t)r; }这里的mult和shift是怎么定的给定输入 scales_in、权重 scales_w、输出 scales_out真实比例是s_in * s_w / s_out把它写成M / 2^shift的形式让 M 落在[0.5, 1)区间再乘2^31取整。计算时先在主机侧用 Python 算好跟权重一起烧进 flash板上不做任何浮点运算。有一点必须注意shift最大可能到 31如果直接写1 shift在 32 位机上会溢出所以上面用了1LL。我就在这上面浪费过半天——精度莫名其妙掉了 0.4 个点最后发现是舍入项算错了。2.3 内存规划128KB 里怎么塞下三层特征图内存这张表是反复推倒重来的最后定下来是这样缓冲区大小放置位置备注音频 DMA 乒乓2 × 3.2KBSRAM160 点 × 2 字节 × 10 帧窗函数表 旋转因子3.2KBFlash 常驻只读走常量总线FFT 工作区4KBSRAM256 点复数Q15log-mel 环形缓冲64 × 64 4KBSRAM64 帧 × 64 维int8特征图 A最大64 × 32 × 16 32KBSRAMConv1 输出特征图 B32 × 16 × 32 16KBSRAMPW3 输出权重与偏置15KBSRAM 常驻从 flash 拷一次之后不再读栈与外设约 12KBSRAM留足中断嵌套余量合计约 91KB余量 37KB表里有两个决定值得说说。第一权重一定要搬到 SRAM。我一开始图省事直接让内核从 flash 里读权重结果同样的代码慢了 34%。原因是 flash 控制器和 SRAM 共享同一条总线CPU 取指、取权重、取激活三者抢带宽流水线几乎每三个周期就停一次。把 15KB 权重在初始化时整体拷进 SRAM这 15KB 换来的性能提升是整轮优化里性价比最高的单项。第二特征图只做两级乒乓不做全缓存。深度可分离网络是严格串行的第 N 层的输出就是第 N1 层的输入所以只需要当前输出和上一级输出两块层与层之间通过指针交换来复用内存。我最初想给每层分配独立缓冲算下来要 180KB直接超了。用内存池 指针交换的思路峰值直接压到 48KB。3. 卷积层加速的四个着力点3.1 先看 MAC 分布71% 的算力花在 1×1 卷积上动手之前我做了一件事把每一层的乘加次数打印出来按降序排。层类型输入尺寸输出通道乘加次数占比PW71×116×8×6464524,28830.1%PW31×132×16×1632262,14415.0%PW51×116×8×3264262,14415.0%Conv13×364×32×116294,91216.9%PW91×18×4×6496196,60811.3%DW2/DW63×3 深度——各 73,728各 4.2%DW43×3 深度——36,8642.1%DW83×3 深度——18,4321.1%四个 1×1 卷积加起来占了71.4%。这个数字非常关键它直接推翻了我原本的优化计划——我本来打算花两周做 Winograd因为教科书上都说 3×3 卷积用 Winograd 能省 2.25 倍乘法。可这张表告诉我3×3 深度卷积总共才占 11.6%就算把它优化到零整帧也只快 1 毫秒而 1×1 卷积占了七成那里才是金矿。这一点我希望你记住优化之前先做剖面别信经验信数据。3.2 通道方向的 SIMD 打包与内核写法1×1 卷积在数学上就是每一个像素位置做一次通道向量内积天然适合在通道方向打包。这颗核有一条打包乘加指令一次能把 4 个 int8 和另外 4 个 int8 做点积再累加到 int32相当于一个周期吃 4 次乘加。前提是数据布局必须是通道在最低维也就是常说的 NHWC。我们训练侧的模型默认是 NCHW导出时必须转。转换的时候顺手把输出通道补齐到 4 的倍数把输入通道也补齐补的位置填 0填 0 对卷积没有影响因为权重对应的那一栏也是 0。补零这件事看起来简单但它是后面所有内核能无条件按 4 对齐跑的前提省掉了内核里一大堆边界判断分支。我们的层通道数是 16、32、64、96全是 4 的倍数只有 Conv1 的输入是单通道单独走一条标量路径。内核的写法才是真正的重头戏。最朴素的写法是对每个输出像素、每个输出通道遍历输入通道做点积这样每个输入值要被读out_c次访存开销爆炸。真正跑得动的是寄存器分块一次算 4 个输出通道 × 4 个像素把 4 个像素的输入值4 个 32 位寄存器和 4 个输出通道的权重4 个 32 位寄存器全压在寄存器里中间做 16 次打包乘加每个 32 位输入值被复用了 4 次。这一招让访存次数从O(in_c × out_c)降到O(in_c out_c)。/* 1x1 卷积4 输出通道 x 4 像素寄存器分块 * in : [pix][in_c] int8in_c 已补齐到 4 的倍数 * w : [out_c][in_c] int8out_c 已补齐到 4 的倍数 * acc : [pix][out_c] int32 */ static void pw1x1_s8(const int8_t *in, const int8_t *w, int32_t *acc, int in_c, int out_c, int pix) { for (int p 0; p pix; p 4) { for (int oc 0; oc out_c; oc 4) { int32_t s000,s010,s020,s030; /* 像素 p0 的 4 个通道 */ int32_t s100,s110,s120,s130; /* 像素 p1 */ int32_t s200,s210,s220,s230; /* 像素 p2 */ int32_t s300,s310,s320,s330; /* 像素 p3 */ for (int ic 0; ic in_c; ic 4) { int32_t v0 load4(in (p0)*in_c ic); int32_t v1 load4(in (p1)*in_c ic); int32_t v2 load4(in (p2)*in_c ic); int32_t v3 load4(in (p3)*in_c ic); int32_t k0 load4(w (oc0)*in_c ic); int32_t k1 load4(w (oc1)*in_c ic); int32_t k2 load4(w (oc2)*in_c ic); int32_t k3 load4(w (oc3)*in_c ic); s00 mac4(v0, k0, s00); s01 mac4(v0, k1, s01); s02 mac4(v0, k2, s02); s03 mac4(v0, k3, s03); s10 mac4(v1, k0, s10); s11 mac4(v1, k1, s11); s12 mac4(v1, k2, s12); s13 mac4(v1, k3, s13); s20 mac4(v2, k0, s20); s21 mac4(v2, k1, s21); s22 mac4(v2, k2, s22); s23 mac4(v2, k3, s23); s30 mac4(v3, k0, s30); s31 mac4(v3, k1, s31); s32 mac4(v3, k2, s32); s33 mac4(v3, k3, s33); } /* 每个输出通道的重量化参数不同必须分开做 */ store4(acc (p0)*out_c oc, requant4(s00,s01,s02,s03, oc)); store4(acc (p1)*out_c oc, requant4(s10,s11,s12,s13, oc)); store4(acc (p2)*out_c oc, requant4(s20,s21,s22,s23, oc)); store4(acc (p3)*out_c oc, requant4(s30,s31,s32,s33, oc)); } } }注意requant4里每个输出通道用不同的乘数和移位数这意味着每层需要准备一组mult[out_c]和shift[out_c]。我见过有人图省事用同一个参数量化整层结果分类准确率掉了 3 个点以上尤其是最后那层只有 96 个通道、通道间动态范围差异大的地方。3.3 访存优化为什么坚决不上 im2colim2col 是把卷积展开成大矩阵乘的经典做法在 PC 上很好用因为内存不要钱。但在 128KB SRAM 上它是灾难把 64×32×1 的输入按 3×3 展开成 9 倍光这一层就要 18KB而且每一层都要重做一次数据搬运。我实测过一版 im2col 实现卷积计算本身只要 1.1 毫秒但搬运花了 2.6 毫秒加速比为负。最后我把 3×3 卷积全部改成直接卷积 输入复用。核心思路是3×3 卷积里相邻输出像素共享 6 个输入横向滑窗的时候把已经读进来的 3 列数据留着只新读 1 列这样输入读取量从每像素 9 次降到约 3 次。再叠加 4 输出通道的寄存器分块实测 3×3 卷积的有效乘加效率从 0.9 MAC/周期 提到 2.2 MAC/周期。深度卷积depthwise是另一套逻辑。它每个通道独立卷积通道之间没有复用SIMD 打包在这里没用武之地。我用了另一种办法把 2 个通道的 int8 拼成 1 个 int16用 16 位乘法一次算两个通道。
做端侧语音的同行大概都遇到过同一个尴尬算法同事在服务器上训好的卷积模型指标漂亮得能贴墙上一放到小智音箱这种 128KB 内存、百来兆主频的板子上跑一次要小半天实时性直接崩盘。我这次要聊的就是小智音箱加速卷积层特征提取这件事——具体点说是把一段 16kHz 的麦克风音频在端侧先变成 64 维的梅尔对数谱再送进一个小型卷积网络做特征提取和分类整个过程从原来的 100 毫秒压到 8.7 毫秒让这颗核从几乎被吃满回到只占一成。这里的关键词是定点化、卷积层、特征提取、SIMD 打包、访存优化。这篇内容适合三类人手上正被端侧推理性能卡住固件工程师、想把模型塞进低端硬件的算法同学以及刚接触嵌入式神经网络、想知道书上那些优化手段在真实板子上到底值几个毫秒的新手。我会把坑一个一个摊开讲包括我算错参数重训一次的教训。1. 先把问题摆清楚音箱端跑卷积到底卡在哪1.1 小智这个项目的时间预算有多紧小智音箱是我们内部给一个语音交互原型起的代号主控是一颗主频 120MHz 的 32 位音频 SoC带一块 128KB 的片上 SRAM没有独立 NPU也没有硬件浮点单元音频前端有一路 16kHz/16bit 的 I2S 麦克风输入。功能上要做的是本地关键词与声音事件识别主人喊小智小智要能唤醒厨房里玻璃碎裂、水流、油烟机这类声音也要能分辨出来一共 12 个类别。推理节奏是每 100 毫秒出一次结果也就是 10Hz。这个节奏不是随便定的——唤醒词要跟手超过 200 毫秒用户就会觉得这音箱有点傻而 100 毫秒的窗口配上 640 毫秒的滑动上下文误唤醒率能压得住。问题就出在这基线版本跑一帧要100.4 毫秒推理周期也是 100 毫秒等于这颗核 100% 被卷积吃掉。一旦播放器线程要解码 MP3或者蓝牙链路要收包立刻就丢帧表现为喊三声才应一声。这就是我要加速卷积层特征提取最原始的动机不是什么技术洁癖是产品真的不能用。1.2 算力、内存、带宽这三本账做端侧优化我习惯动手之前先把三本账算清楚否则容易在错误的方向上使劲。算力账120MHz 意味着每毫秒只有 12 万次时钟周期。如果按标量指令一次做一次乘加算一帧模型的 174 万次乘加需要 14.5 毫秒还没算循环开销和访存如果走软件浮点一次浮点乘法就要十来个周期直接爆到 100 毫秒以上——我们实测的基线就是这么来的。内存账128KB SRAM 里音频 DMA 双缓冲要 6.4KBFFT 工作区要 4KBlog-mel 特征环形缓冲要 4KB剩下的才轮到卷积用。最大的中间特征图是 64×32×16 的 int8正好 32KB两块乒乓就是 64KB加上 15KB 常驻权重勉强塞得下但余量只有不到 20KB。这个数字决定了后面所有的优化手段选择——任何会把特征图放大的方案比如标准 im2col直接出局。带宽账这颗核没有 cache所有数据都在 SRAM 里跑一次 32 位读要 1 个周期一次 32 位写要 1 个周期。也就是说理论上一个读权重、读激活、乘加、写累加的最优循环是 2 读 1 算瓶颈在取指和访存而不是 ALU。这解释了为什么后来我把循环顺序和寄存器分块调了一遍收益比单纯换 int8 还大。1.3 为什么选深度可分离卷积而不是直接搬骨干网选型阶段我们试过两套结构。一套是直接把移动端常用的瓶颈残差结构裁剪到 32 通道参数量 21 万实测乘加 6.8M另一套是纯深度可分离的堆叠结构参数量 1.5 万乘加 1.74M。前者准确率大概高 1.2 个百分点但耗时是后者的近四倍在 100 毫秒预算里根本放不下。我最终选后者还有一个容易被忽略的理由深度可分离结构的层数多、但每层的数据量小天然适合分块塞进小 SRAM也方便做逐层打点。如果是一整块大卷积你只能整体优化出了问题很难定位是哪一段慢。分成九层之后我能拿着计时器一层一层看哪个慢改哪个这个可观测性在资源紧张的板子上比理论效率更值钱。提醒一句深度可分离卷积在训练侧有个副作用3×3 深度卷积的权重初始化对最终精度影响比普通卷积大得多。我们第一版直接用默认初始化收敛后掉了 2.8 个点后来改成先训 pointwise 再解冻深度卷积的两段式训练才补回来。2. 整体设计把卷积前端拆成一条能跑满的流水线2.1 四段式切分与定点化的边界整条链路我切成四段采集与预加重 → 分帧加窗与 FFT → 梅尔滤波与对数 → 卷积特征提取与分类。切分的原则不是按算法模块而是按数据形态——前两段是流式实时数据每 10 毫秒必到一次必须做成中断驱动后两段是块式数据攒够 64 帧才触发一次可以放在主循环里跑。定点化的边界就落在第三段和第四段之间。前面全用 Q15 定点16 位1 位符号15 位小数后面的卷积全用 int8。为什么不统一因为 FFT 的衰减特性需要比较高的动态范围Q15 下信噪比损耗不到 0.3dB可以接受而卷积层的权重动态范围小、对量化更宽容用 int8 能把存储和带宽都砍到四分之一。这条边界我试过两种划法另一条是在 log-mel 输出后再转 int8结果因为 log 值域跨度太大0 到 8.9 左右简单线性量化掉点明显最后还是选了现在这样log-mel 出来后先做一次均值方差归一化压到约 [-4, 4]再乘 16 转 int8正好用满 -128 到 127 的范围。2.2 量化方案对称与非对称的取舍权重用对称量化激活用非对称量化——这是端侧最常规的搭配但它背后有具体原因。权重分布基本以 0 为中心、近似对称对称量化不需要零点zero point卷积累加时省掉一次零点补偿内核实现简单不少。激活不一样经过 ReLU 之后分布明显偏向正值如果硬用对称量化整个正半轴只能用掉 128 个量化级里的一半白白损失一位精度。真正麻烦的是**重量化requantization**这一步。int32 的累加结果要变回 int8中间要做一次acc × scale的乘法而 scale 是个小于 1 的浮点数。板子上跑浮点太贵标准做法是把它转成定点乘加移位/* mult 为 Q31 定点乘数shift 为右移位数zp 为输出零点 */ static inline int8_t requant(int32_t acc, int32_t mult, int shift, int32_t zp) { int64_t t (int64_t)acc * mult; /* 64 位中间量防溢出 */ int32_t r (int32_t)((t (1LL (shift - 1))) shift); /* 加半再移四舍五入 */ r zp; if (r -128) r -128; if (r 127) r 127; return (int8_t)r; }这里的mult和shift是怎么定的给定输入 scales_in、权重 scales_w、输出 scales_out真实比例是s_in * s_w / s_out把它写成M / 2^shift的形式让 M 落在[0.5, 1)区间再乘2^31取整。计算时先在主机侧用 Python 算好跟权重一起烧进 flash板上不做任何浮点运算。有一点必须注意shift最大可能到 31如果直接写1 shift在 32 位机上会溢出所以上面用了1LL。我就在这上面浪费过半天——精度莫名其妙掉了 0.4 个点最后发现是舍入项算错了。2.3 内存规划128KB 里怎么塞下三层特征图内存这张表是反复推倒重来的最后定下来是这样缓冲区大小放置位置备注音频 DMA 乒乓2 × 3.2KBSRAM160 点 × 2 字节 × 10 帧窗函数表 旋转因子3.2KBFlash 常驻只读走常量总线FFT 工作区4KBSRAM256 点复数Q15log-mel 环形缓冲64 × 64 4KBSRAM64 帧 × 64 维int8特征图 A最大64 × 32 × 16 32KBSRAMConv1 输出特征图 B32 × 16 × 32 16KBSRAMPW3 输出权重与偏置15KBSRAM 常驻从 flash 拷一次之后不再读栈与外设约 12KBSRAM留足中断嵌套余量合计约 91KB余量 37KB表里有两个决定值得说说。第一权重一定要搬到 SRAM。我一开始图省事直接让内核从 flash 里读权重结果同样的代码慢了 34%。原因是 flash 控制器和 SRAM 共享同一条总线CPU 取指、取权重、取激活三者抢带宽流水线几乎每三个周期就停一次。把 15KB 权重在初始化时整体拷进 SRAM这 15KB 换来的性能提升是整轮优化里性价比最高的单项。第二特征图只做两级乒乓不做全缓存。深度可分离网络是严格串行的第 N 层的输出就是第 N1 层的输入所以只需要当前输出和上一级输出两块层与层之间通过指针交换来复用内存。我最初想给每层分配独立缓冲算下来要 180KB直接超了。用内存池 指针交换的思路峰值直接压到 48KB。3. 卷积层加速的四个着力点3.1 先看 MAC 分布71% 的算力花在 1×1 卷积上动手之前我做了一件事把每一层的乘加次数打印出来按降序排。层类型输入尺寸输出通道乘加次数占比PW71×116×8×6464524,28830.1%PW31×132×16×1632262,14415.0%PW51×116×8×3264262,14415.0%Conv13×364×32×116294,91216.9%PW91×18×4×6496196,60811.3%DW2/DW63×3 深度——各 73,728各 4.2%DW43×3 深度——36,8642.1%DW83×3 深度——18,4321.1%四个 1×1 卷积加起来占了71.4%。这个数字非常关键它直接推翻了我原本的优化计划——我本来打算花两周做 Winograd因为教科书上都说 3×3 卷积用 Winograd 能省 2.25 倍乘法。可这张表告诉我3×3 深度卷积总共才占 11.6%就算把它优化到零整帧也只快 1 毫秒而 1×1 卷积占了七成那里才是金矿。这一点我希望你记住优化之前先做剖面别信经验信数据。3.2 通道方向的 SIMD 打包与内核写法1×1 卷积在数学上就是每一个像素位置做一次通道向量内积天然适合在通道方向打包。这颗核有一条打包乘加指令一次能把 4 个 int8 和另外 4 个 int8 做点积再累加到 int32相当于一个周期吃 4 次乘加。前提是数据布局必须是通道在最低维也就是常说的 NHWC。我们训练侧的模型默认是 NCHW导出时必须转。转换的时候顺手把输出通道补齐到 4 的倍数把输入通道也补齐补的位置填 0填 0 对卷积没有影响因为权重对应的那一栏也是 0。补零这件事看起来简单但它是后面所有内核能无条件按 4 对齐跑的前提省掉了内核里一大堆边界判断分支。我们的层通道数是 16、32、64、96全是 4 的倍数只有 Conv1 的输入是单通道单独走一条标量路径。内核的写法才是真正的重头戏。最朴素的写法是对每个输出像素、每个输出通道遍历输入通道做点积这样每个输入值要被读out_c次访存开销爆炸。真正跑得动的是寄存器分块一次算 4 个输出通道 × 4 个像素把 4 个像素的输入值4 个 32 位寄存器和 4 个输出通道的权重4 个 32 位寄存器全压在寄存器里中间做 16 次打包乘加每个 32 位输入值被复用了 4 次。这一招让访存次数从O(in_c × out_c)降到O(in_c out_c)。/* 1x1 卷积4 输出通道 x 4 像素寄存器分块 * in : [pix][in_c] int8in_c 已补齐到 4 的倍数 * w : [out_c][in_c] int8out_c 已补齐到 4 的倍数 * acc : [pix][out_c] int32 */ static void pw1x1_s8(const int8_t *in, const int8_t *w, int32_t *acc, int in_c, int out_c, int pix) { for (int p 0; p pix; p 4) { for (int oc 0; oc out_c; oc 4) { int32_t s000,s010,s020,s030; /* 像素 p0 的 4 个通道 */ int32_t s100,s110,s120,s130; /* 像素 p1 */ int32_t s200,s210,s220,s230; /* 像素 p2 */ int32_t s300,s310,s320,s330; /* 像素 p3 */ for (int ic 0; ic in_c; ic 4) { int32_t v0 load4(in (p0)*in_c ic); int32_t v1 load4(in (p1)*in_c ic); int32_t v2 load4(in (p2)*in_c ic); int32_t v3 load4(in (p3)*in_c ic); int32_t k0 load4(w (oc0)*in_c ic); int32_t k1 load4(w (oc1)*in_c ic); int32_t k2 load4(w (oc2)*in_c ic); int32_t k3 load4(w (oc3)*in_c ic); s00 mac4(v0, k0, s00); s01 mac4(v0, k1, s01); s02 mac4(v0, k2, s02); s03 mac4(v0, k3, s03); s10 mac4(v1, k0, s10); s11 mac4(v1, k1, s11); s12 mac4(v1, k2, s12); s13 mac4(v1, k3, s13); s20 mac4(v2, k0, s20); s21 mac4(v2, k1, s21); s22 mac4(v2, k2, s22); s23 mac4(v2, k3, s23); s30 mac4(v3, k0, s30); s31 mac4(v3, k1, s31); s32 mac4(v3, k2, s32); s33 mac4(v3, k3, s33); } /* 每个输出通道的重量化参数不同必须分开做 */ store4(acc (p0)*out_c oc, requant4(s00,s01,s02,s03, oc)); store4(acc (p1)*out_c oc, requant4(s10,s11,s12,s13, oc)); store4(acc (p2)*out_c oc, requant4(s20,s21,s22,s23, oc)); store4(acc (p3)*out_c oc, requant4(s30,s31,s32,s33, oc)); } } }注意requant4里每个输出通道用不同的乘数和移位数这意味着每层需要准备一组mult[out_c]和shift[out_c]。我见过有人图省事用同一个参数量化整层结果分类准确率掉了 3 个点以上尤其是最后那层只有 96 个通道、通道间动态范围差异大的地方。3.3 访存优化为什么坚决不上 im2colim2col 是把卷积展开成大矩阵乘的经典做法在 PC 上很好用因为内存不要钱。但在 128KB SRAM 上它是灾难把 64×32×1 的输入按 3×3 展开成 9 倍光这一层就要 18KB而且每一层都要重做一次数据搬运。我实测过一版 im2col 实现卷积计算本身只要 1.1 毫秒但搬运花了 2.6 毫秒加速比为负。最后我把 3×3 卷积全部改成直接卷积 输入复用。核心思路是3×3 卷积里相邻输出像素共享 6 个输入横向滑窗的时候把已经读进来的 3 列数据留着只新读 1 列这样输入读取量从每像素 9 次降到约 3 次。再叠加 4 输出通道的寄存器分块实测 3×3 卷积的有效乘加效率从 0.9 MAC/周期 提到 2.2 MAC/周期。深度卷积depthwise是另一套逻辑。它每个通道独立卷积通道之间没有复用SIMD 打包在这里没用武之地。我用了另一种办法把 2 个通道的 int8 拼成 1 个 int16用 16 位乘法一次算两个通道。
