嵌入式AI裁剪为何反慢？算子怎么替？

剪掉参数后推理反而变慢，听起来矛盾，却很常见。嵌入式AI优化若只盯 FLOPs，不看硬件支持的算子形状，模型压缩会把规则计算改成低效搬运。

裁剪反慢最典型的原因，是非结构化稀疏没有被目标芯片真正加速。权重矩阵里零值很多，但如果 NPU 仍按密集卷积内核读取，零值只是在存储上变得难压缩，计算路径并不会自动跳过。即便运行时支持稀疏，索引表、块描述和不连续访问也会引入额外开销；当稀疏度不够高或块形状不匹配时，省下的乘加还不如损失的访存局部性多。

结构化裁剪也不能随便砍通道。很多加速器要求通道数按 8、16 或 32 对齐，剪到一个看似更小的宽度后，底层仍要补齐到硬件向量宽度，实际计算量并没有等比例下降。更麻烦的是，通道不规则会打断算子融合，原本能合并的卷积、批归一化和激活被拆开执行，中间张量重新落内存。嵌入式AI模型裁剪前，应先拿到目标运行时的内核覆盖表和对齐规则，再决定哪些层值得动。

算子替换的目标也不是把所有模块换成论文里更轻的结构。深度可分离卷积在移动端常见，但对某些低端 NPU 来说，小通道 depthwise 可能因并行度不足而跑不满；注意力模块被简化后，若引入了不支持的 reshape、transpose 或 gather，同样会把时间花在重排上。真正有效的替换通常是让计算形状更贴近硬件内核，例如保持通道对齐、减少跨维度转置、把激活和量化重标定合并进相邻算子。

替换后还要检查精度恢复路径。若为了硬件友好改掉骨干结构，蒸馏或微调需要覆盖原模型容易出错的边界样本，否则速度提升会换来新的误检。某些后处理也值得重写，例如把复杂 NMS 从 Python 风格循环改成芯片支持的批量比较，收益可能比继续压缩主干网络更大。优化顺序应先消除回退和重排，再谈裁剪比例。

还有一种常见误判，是把离线编译器的通过当成性能通过。编译器能把图转换成目标格式，并不代表每个节点都落在最快内核上；有些层会被拆成多个微算子，或者因为张量尺寸不满足 tile 规则而频繁访存。部署前应查看编译报告里的内核选择、重排节点和临时缓冲大小，确认替换后的结构没有制造新的执行断点。

评估时不要只报模型文件大小。应同时列出端到端时延、逐算子时延、外部内存读写量和回退节点数；如果参数量下降而总线访问上升，说明优化方向已经偏离硬件。还要复测不同输入尺寸和 batch 设置，因为有些内核只在特定 tile 下高效，换一个摄像头分辨率就可能失去加速路径，连带让缓存计划失效，版本升级后也要复核编译报告。只有当压缩后的图仍保持连续加速、少重排、少回退，裁剪才算真的变快。

因此，轻量化不是把网络剪得越瘦越好。先让算子形状适配执行内核，再裁掉硬件确实不会计算的部分，嵌入式AI才会同时省时省电。