企业官网建设流程全解析

去年我把一个八万参数的异常检测模型往一颗带 NPU 的 Cortex-M 上搬，前后折腾了三周。真正卡住我的既不是模型结构，也不是驱动，而是一张怎么都填不平的内存表：Flash 里要装固件、要留双区 OTA、还要塞模型；SRAM 里要养协议栈、要养采样缓冲，最后还得给 NPU 留一块激活区。那三周我反复在"改模型"和"改内存布局"之间横跳，改一次模型就要重算一次内存，挪一次内存又要重跑一次精度，最后才想明白一件事——NPU 进 MCU 之后，模型和内存根本不是两件事，它们是同一张预算表的两列。

这几年 NPU 的落点明显分成了三层：笔记本和 PC 上的 NPU 动辄几十 TOPS，手机上的 NPU 在几 TOPS 量级，而 MCU 上的 NPU，算力常常只有 0.1 到 1 TOPS，本地 SRAM 从几 KB 到 1 MB 出头。算力差了三个数量级，遇到的问题也完全不同——PC 上大家愁的是怎么把算子喂满，MCU 上愁的是数据根本搬不过来。所以这篇文章不聊大模型推理，只聊一件很具体的事：在一个 Flash 一两兆、SRAM 一两百 K 的 MCU 上，把 NPU 用起来，模型侧和内存侧各自会踩到什么坑，两者又怎么互相牵制。

内容适合三类人看：正在评估带 NPU 的 MCU 做端侧推理的产品和固件工程师；已经把模型训好、准备往板子上搬但被内存卡住的算法同学；以及还在纠结"要不要上 NPU"的硬件选型的人。我会把量化、算子、权重存放、激活复用、DMA 与 cache 这些环节按我实际踩坑的顺序讲一遍，中间的计算过程都写出来，你可以直接拿自己的模型套进去算。

1. 先把账算清楚：MCU 加 NPU 之后的内存模型变了什么

1.1 MCU 原本的三级存储账本

传统 MCU 的内存账其实很清爽，就三级。最上面是寄存器堆和紧耦合内存（TCM），一两个时钟周期就能访问；中间是片上 SRAM，通常跑在同频总线上，零等待或少等待；最下面是 Flash，容量大但慢，而且慢得很有讲究。

这里要专门说一下"MCU 内部的 Flash 用什么接口访问"这件事，因为它直接决定了模型能不能放在 Flash 里跑。片上 Flash 属于嵌入式闪存，读写特性跟外挂 NOR 完全不同：擦写粒度大、寿命有限，读虽然比写快得多，但仍有几十纳秒级的访问延迟。芯片内部通常有一个 Flash 控制器挂在 AHB 或 AXI 总线上，把 Flash 空间映射到统一地址空间里，CPU 取指时走的是 XIP 那条路。为了不让取指把流水线拖死，控制器一般带预取缓冲和 cache line，比如 32 字节一行、预取 2 到 4 行。命中时几乎无感，一旦跳转或者随机访问，一次 miss 就是十几个到几十个周期。

如果你把模型权重当成"只读数据"直接留在 Flash 里让 NPU 去取，那 NPU 面对的其实是同一套控制器。它比 CPU 更吃亏：CPU 取指至少有空间局部性，而 NPU 读权重虽然也是顺序的，但它的读速率要求高得多，很容易把预取缓冲和 cache 全部冲垮。

记住一个判断原则：片内 Flash 的瓶颈从来不是容量，而是"随机访问 + 高带宽并发"这两件事凑在一起。要么让访问变得极其规律，要么干脆把数据搬进 SRAM。

1.2 NPU 带来的三类新数据流

NPU 一进来，内存表就多出了三行，而且这三行的性格完全不同。

第一类是权重，只读、体量大、访问模式极其规律。一个 8 位量化的卷积网络，权重从几十 KB 到几百 KB 不等。第二类是激活，读写都有、体量中等、生命周期短，某一层的输出往往是下一层的输入，用完就该回收。第三类是指令和控制描述符，体量很小，但必须在 NPU 能快速取到的地方，否则 NPU 就处在"等指令"的状态，算力再高也白搭。

这三类数据对带宽的敏感度差别巨大。我做过一个很粗的估算：一个小型卷积模型，权重 300 KB，如果每秒推理 25 次，光是权重搬运就是 300 KB × 25 ≈ 7.5 MB/s。听起来不大？但 MCU 上外挂 QSPI Flash 在小粒度、非连续访问下的有效带宽，实测往往只有十几到二十几 MB/s。也就是说，光把权重搬一遍，就吃掉了一大半可用带宽，而这时候 NPU 的 MAC 阵列可能只忙了不到两成时间。

把这两个数字放在一起看更明显：假设 NPU 是 128 个 MAC 单元、主频 200 MHz，理论峰值就是 128 × 200M ≈ 25.6 GMAC/s，折合约 51 GOP/s。一个 6 MMAC 的模型，纯计算时间是 6M / 25.6G ≈ 0.23 ms。而 300 KB 权重以 20 MB/s 搬进来要 15 ms。计算和搬运差了六十多倍，这就是"算力过剩、带宽饥饿"的典型画面。

1.3 为什么说模型和内存是同一枚硬币

看到上面那组数字，答案其实已经出来了：真正难管的是两者之间的匹配关系。

模型决定了内存的"形状"——你有多少权重、峰值激活多大、算子之间怎么串。内存决定了模型的"上限"——Flash 放不放得下、SRAM 够不够双缓冲、总线带宽撑不撑得住目标帧率。而量化这个动作同时改写两边：它把权重体积压到四分之一，把激活也压到四分之一，但代价是引入了定点的数值语义和饱和风险。

所以我后来不再问"是模型难还是内存难"，而是改问三个更具体的问题：这个模型的权重能不能常驻在 NPU 自己的 SRAM 里？激活的峰值能不能压到剩下的空间以内？权重的搬运路径是 Flash 直取、DMA 分块还是常驻本地？这三个问题里只要有一个答不上来，方案就还不成立。

2. 模型侧的硬骨头：量化语义、算子支持度和结构选型

2.1 量化改的不是文件大小，是数值语义

很多人第一次做 int8 量化，心态是"压一压文件，反正精度掉一点能接受"。真正上板之后才发现，量化改动的是每一个乘加的计算方式，出问题的地方跟"精度掉了几个点"完全不在一个维度上。

一个标准的 int8 卷积层里，权重是 int8，激活是 int8，乘法结果是 int32 累加，偏置也用 int32 存。算完之后要重新量化回 int8，靠的是一个定点乘数加右移：

M = (Sx × Sw) / Sy

其中 Sx 是输入 scale，Sw 是权重 scale，Sy 是输出 scale。M 会被工具链拆成一个 int32 的乘数和一个移位量，在推理时做"乘法 + 舍入 + 移位 + 饱和"。这套流程本身没问题，问题出在三个地方。

第一是校准集选得不对。校准集的目的是估计每一层激活的动态范围，如果校准数据全是"正常工况"，那一上板遇到边界数据，激活就会大面积饱和，表现出来不是精度缓慢下降，而是输出直接卡在极值上不动。我一般会让校准集里至少放 10% 到 20% 的边界样本，哪怕这些样本在训练集里很稀少。

第二是 per-tensor 和 per-channel 的选择。对普通卷积，per-tensor 勉强能用；但对深度可分离卷积，per-channel 几乎是必需的。原因很直白：depthwise 卷积的每个通道都是独立卷积核，通道之间的权重动态范围可以差几十倍，用一个共享 scale 去覆盖，小通道直接被压成噪声。

第三是首尾两层的特殊照顾。第一层直接吃原始输入（比如音频 MFCC 或者传感器采样值），输入 scale 如果估得太粗，后面所有层都在为它擦屁股；最后一层输出 logits，经常是几十几百的动态范围，int8 塞不下，稳妥的做法是最后一层留在 int32 或者干脆放回 CPU 算。

2.2 算子支持度决定模型能不能落地

这一点是我认为比量化更致命的问题。NPU 不是通用计算单元，它支持的算子集是有限的，而且每家都不一样。典型支持的是 1×1 和 3×3 卷积、stride 1 和 2、深度可分离卷积、最大池化和平均池化、全连接、逐元素加法、拼接、以及 ReLU 和 ReLU6 这类简单激活。至于 GELU、SiLU、LayerNorm、Softmax 这类带超越函数的算子，很多 MCU 级 NPU 干脆不支持，或者只支持一个查表近似版本。

不支持会怎么样？工具链会把它"切回 CPU"，也就是 fallback。这一刀下去代价常常比整个 NPU 推理还高：数据要先从 NPU 的本地缓冲搬回主 SRAM，CPU 算完再搬回去，中间还夹着 cache 维护和同步。我在一块板子上见过一个模型，NPU 算子覆盖率 92%，剩下 8% 的算子 fallback 带来的耗时占了总推理时间的六成以上。

我的做法是从"NPU 支持的积木"出发设计模型，而不是先训好再想办法适配。具体操作是先把工具链的算子支持表打印出来，然后按支持的算子搭骨架，训练精度不够就加宽而不是加花样。用 GELU 换 ReLU6、用全局平均池化换大 FC，这些改动对精度的影响通常在一两个点以内，但对能否部署是决定性的。

2.3 结构选型：Transformer 和 TCN 在 MCU 上的真实成本

热词里 Transformer、TCN 都被提到了，我来说说它们在 MCU 上的实际处境。

Transformer 的核心是自注意力，它的中间张量规模是序列长度的平方。序列长度 64 的时候还好，长度 256 的时候中间张量就是 64 倍的增长，而且 Softmax 需要指数运算，NPU 一般只能查表近似。更麻烦的是推理时的 KV 缓存，它要求把历史状态一直保留在内存里，这对一个只有一百多 KB 可用 SRAM 的 MCU 来说基本是灾难。所以我现在的判断是：MCU 上做序列建模，优先用一维卷积堆叠或者轻量 GRU，注意力机制只在序列极短、且工具链明确支持的情况下才考虑。

TCN 的问题不太一样。它靠膨胀卷积扩大感受野，膨胀系数翻倍增长，意味着你要保留越来越长的历史缓冲。比如膨胀系数 1、2、4、8 四层，最后一层的输入窗口就是前 15 个时间步，每一层的激活都得留着，内存占用随层数线性往上走。如果工具链能把中间张量及时回收，问题不大；如果它是"全图分配"策略，那 TCN 的激活峰值会明显高于同等参数量的普通卷积网络。

关于模型深度和宽度的平衡，我的经验是这样：在参数预算固定的前提下，MCU 上宁可深一点窄一点，也不要浅而宽。因为宽度直接决定单层激活张量的大小和峰值内存，而深度带来的激活增长可以通过层间复用压下去。同样是 50 万参数，一个 6 层 32 通道的网络，比一个 3 层 96 通道的网络，峰值激活常常小一半以上。

3. 内存侧的暗礁：权重放哪、激活怎么复用、DMA 和 cache 怎么相处

3.1 权重存放的三种策略与取舍

权重放哪里，是我认为整件事里最需要提前定下来的决策，因为它牵动 Flash 预算、SRAM 预算和推理耗时三个指标。

第一种是 Flash 直取，权重留在片内或片外 Flash，NPU 通过 DMA 按需读取。优点是零 SRAM 占用，模型能做得很大；缺点是依赖 Flash 控制器的预取能力，带宽受限，而且如果权重被反复读取（每次推理都要重读一遍），功耗也会明显上升。

第二种是常驻 SRAM，把全部权重在初始化时搬进 NPU 本地或者主 SRAM。优点是推理时带宽压力骤降，NPU 可以跑到接近峰值；缺点是要占用一大块 SRAM，而且这块内存从此不能被别的模块用。

第三种是分块双缓冲，把权重按层或者按块切分，DMA 后台预取下一块，NPU 计算当前块。这是最常见的折中方案，代价是需要写比较细的调度代码，还要处理对齐和依赖关系。

具体怎么选，我给你一个可以直接套的判断流程：先算出模型权重总量 W，再算出 SRAM 里除权重之外必须留出的空间 R（协议栈、采样缓冲、显示缓冲、堆栈等），再算出芯片可用 SRAM 总量 S。如果 W + R + 激活峰值 × 1.5 < S，那就大胆常驻，这是最省心的方案。如果差得不多，考虑只把访问最频繁的那几层（通常是深层的 1×1 卷积和全连接）常驻，其余走 Flash。如果 W 本身就超过 S 的三分之一，那基本只能走分块流式方案。

还有一个容易被忽略的算术强度问题。全连接层是典型的"每字节权重只换来一次乘加"，属于带宽杀手；而 3×3 卷积的权重复用率是输出空间尺寸的平方，动辄几百倍，对带宽非常不敏感。所以如果你的模型里塞了几个大 FC 层，把它们砍掉换成全局平均池化 + 小 FC，往往是同时改善精度、体积和带宽的一刀。

3.2 激活内存：做一张张量生命周期表再谈优化

激活内存的优化不能靠感觉，必须做张量生命周期分析。方法很土但非常有效：把模型的每一层输入输出列成一张表，标出每个张量的"出生层"和"死亡层"，然后找出在任意时刻同时存活的张量集合，其中占用之和最大的那一刻就是峰值激活。

举个具体的例子。假设一个四层卷积网络，每层的输出张量分别是 A、B、C、D，再加最后的输出 E，并且有两条跨层连接（比如残差），那么 A 的存活期会被拉长到 D 之后。这时候如果工具链按顺序分配内存，就会白白浪费前面已经可以回收的空间。手工调整的方法是把跨层连接的两端尽量安排得近一些，或者在残差分支上做通道压缩。

我实际用过的一个优化手段是把输入缓冲和中间缓冲复用。输入张量在第一次卷积之后就没用了，而它的尺寸又比较大（比如 49×40 的 MFCC 特征），如果内存分配器能识别出"输入张量已死、第一个中间张量可以覆盖它"，就能省下几 KB 到几十 KB。很多工具链默认不做这个优化，需要你在模型转换时开启内存复用选项，或者手动指定。

还有一个细节是对齐。DMA 一般要求缓冲区按 4、16 或者 32 字节对齐，cache line 通常是 32 字节。如果你把张量紧密排布，每个张量的起始地址都不对齐，DMA 就要做拆包处理，效率掉得很厉害。稳妥做法是所有张量按 32 字节对齐，虽然浪费了一点空间，但换来的是可预测的性能。

3.3 DMA、cache 与总线争用：三个最容易翻车的地方

第一是 cache 一致性。如果 NPU 通过 DMA 往一块 CPU 也访问的 SRAM 写数据，而那块地址区间又是可缓存的，那么 CPU 读到的可能是 cache 里的旧值。正确做法是：DMA 写之前 clean 掉 CPU 可能留下的脏行，DMA 写完之后 invalidate 掉对应的 cache 行，让 CPU 下次读的时候真的去内存取。

/* NPU 通过 DMA 往 act_buf 写结果前后的标准动作 */ SCB_CleanDCache_by_Addr((uint32_t *)act_buf, ACT_BUF_BYTES); /* 清脏行，防止 DMA 覆盖后被 cache 回写冲掉 */ NPU_SubmitJob(&job); NPU_WaitDone(&job); SCB_InvalidateDCache_by_Addr((uint32_t *)act_buf, ACT_BUF_BYTES); /* 作废旧行，强制 CPU 从 SRAM 重读 */

这段代码看着很简单，但实际项目里我见过太多次"数据偶尔错一次"，最后都是漏了这两行或者地址没对齐。

第二是总线争用。NPU 和 CPU 通常共享一条 SRAM 总线，NPU 一旦开始大流量搬运，CPU 的取指和数据访问就会被挤。表现出来就是"NPU 跑起来了，但主循环变慢了"。解决办法是把 CPU 的关键代码和数据放进 TCM（紧耦合内存），那是独立的通道，不受 NPU 影响。如果芯片支持把 SRAM 分 bank 并做交织，也尽量让 NPU 和 CPU 落在不同的 bank 上。

第三是中断与同步开销。如果推理结果通过中断通知 CPU，每帧一次中断还好；如果按层触发中断让 CPU 介入，这个上下文切换的开销在几百 MHz 的 MCU 上是相当可观的。我的建议是把整个推理做成一次提交、一次等待，中间不要插 CPU 干预。

3.4 双区 OTA：最容易被忽略的那一刀

这一刀我单独拎出来说，因为它砍掉的往往是整个方案。很多产品要求支持固件回滚，也就是 A/B 双分区 OTA。这意味着 Flash 要按两份固件来算。一颗 2 MB Flash 的 MCU，固件本身 700 KB，双区就是 1.4 MB，剩下 600 KB 要放模型、配置、日志和文件系统。而你那个 900 KB 的模型，根本没地方放。

低估这个约束的人非常多，我当年就是其中之一。后来总结了几个应对思路：一是把模型从固件区独立出来，模型分区只保留一份，OTA 时只更新固件不动模型；二是模型也走增量更新，只下发变化的那部分权重；三是大模型放外挂 Flash，用 QSPI 挂一颗 8 MB 或 16 MB 的 NOR，虽然带宽受限，但至少放得下；四是接受"单区 OTA + 外部看门狗兜底"的方案，用产品流程而不是存储冗余来保证可靠性。

4. 一套可复现的部署流程：从训练到上板的内存预算方法

4.1 训练到导出的关键参数

量化感知训练不是必须的，但对小模型来说收益明显。我的流程一般是：先用浮点训练到收敛，然后开量化感知训练微调 10% 到 20% 的步数，导出 int8 模型，最后用一套独立的验证集在 PC 上和板子上各跑一遍，比对输出误差。

import tensorflow as tf # 校准集：200~500 条样本足够，但必须包含边界工况，否则激活动态范围估不准 def rep_dataset(): for x in calib_samples: yield [x.astype("float32")] conv = tf.lite.TFLiteConverter.from_saved_model("saved_model") conv.optimizations = [tf.lite.Optimize.DEFAULT] conv.representative_dataset = rep_dataset conv.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8] conv.inference_input_type = tf.int8 # 输入也走 int8，避免板子上再做一次浮点转换 conv.inference_output_type = tf.int8 tflite_int8 = conv.convert() open("model_int8.tflite", "wb").write(tflite_int8) print("flatbuffer bytes:", len(tflite_int8)) # 先看这个数，再决定内存方案

导出之后的第一件事不是上板，而是用工具链的离线分析报告看清楚三件事：权重总量、峰值激活、以及不支持的算子清单。这三项直接决定了后面的内存布局。

4.2 内存预算表怎么做

我的做法是列一张表，每一项都填具体的字节数，绝不写"大概"。下面是我最近一个项目的真实预算，你可以照着这个结构套。

这张表里有几个数字值得展开说。权重 340 KB 是 int8 之后的大小，原始浮点模型是 1.3 MB 左右，压到了四分之一出头。激活峰值 46 KB 是按张量生命周期分析算出来的最大并发值，如果没有做复用优化，实际峰值会到 90 KB 以上，直接超预算。预留 20% 是硬性要求，我吃过一次亏：上线前加了个日志功能，堆栈多了 8 KB，结果激活缓冲被挤到边界外，表现是"偶发输出全零"，查了两天才定位到。

链接脚本上也要把分区写死，别指望编译器自动摆放：

MEMORY { FLASH_APP (rx) : ORIGIN = 0x08020000, LENGTH = 760K FLASH_OTA (rx) : ORIGIN = 0x080E0000, LENGTH = 760K SRAM_CPU (rwx) : ORIGIN = 0x20000000, LENGTH = 320K SRAM_NPU (rwx) : ORIGIN = 0x20050000, LENGTH = 160K } SECTIONS { .npu_activations (NOLOAD) : ALIGN(32) { *(.npu_act) } > SRAM_NPU }

把 NPU 的激活缓冲单独放在一个 NOLOAD 段里，好处是它不参与固件镜像的生成，也不怕被初始化数据污染，同时能通过链接脚本强制 32 字节对齐。

4.3 上板之后怎么判断是模型问题还是内存问题

这一步是很多人卡住的地方，因为两类问题的表象很像——都是"结果不对"或者"跑不到帧率"。我一般用三个对照实验来切分。

第一个实验是把权重全部复制到 SRAM 再跑一遍。如果推理时间大幅下降，说明瓶颈在权重带宽，方案要往"常驻"或者"分块预取"方向改。如果时间几乎不变，说明瓶颈在计算或者激活搬运。

第二个实验是把推理频率降到十分之一。如果单次耗时没变但系统整体变流畅了，说明是总线争用或者功耗限制在起作用，而不是单次推理本身慢。

第三个实验是只跑 NPU 部分，把前后处理全部去掉，用 NPU 的 cycle counter 计时。这个数字和 PC 上工具链报告的估计值对比，能直接看出是 NPU 利用率不足，还是前后处理的搬运把时间吃掉了。

5. 常见问题与排查技巧实录

5.1 我踩过的几个具体坑

第一个坑是"模型能跑但偶尔出错"。现象是连续跑几千次推理，会出现一两次输出异常。查了很久发现是 DMA 缓冲区和堆栈共用了同一段地址空间，链接脚本里两个段有重叠而编译器没有报错。教训是：所有涉及 DMA 的缓冲区必须显式指定地址段，并且用编译期断言检查段边界不重叠。

第二个坑是"量化后精度掉得离谱"。原因是我用了训练集的最后 200 条做校准，而这 200 条恰好都是同一种工况，激活动态范围严重低估。换成跨工况随机抽样的校准集之后，精度从掉 8 个点变成掉 1.2 个点。

第三个坑是"NPU 用上了反而更慢"。原因是模型里有三个不小心的全连接层，参数占了总量的六成，而这三层的算术强度极低，全是带宽在拖。把其中一个 FC 换成全局平均池化，参数量掉了一半，推理时间掉了四成。

第四个坑是"内存压缩相关的思路用错地方"。有人看到 PC 上关闭内存压缩能降占用，就以为 MCU 上也该这么想。MCU 没有虚拟内存也没有压缩那一套，它的优化空间只有两个：让数据别同时存在，让搬运别重复发生。

一条我反复验证过的经验：量化之后的模型，第一件事是看权重总量的绝对值，第二件事是看峰值激活的绝对值，第三件事才是看精度。顺序反过来的项目，基本都会返工。

5.2 关于选型的几句实话

如果你的模型权重在 200 KB 以内、激活峰值在 50 KB 以内，那么带 NPU 的中高端 MCU 已经足够，甚至不需要 NPU，堆一点 DSP 指令或者向量扩展也能跑。这个量级下上 NPU 的收益主要是功耗和 CPU 占用率，而不是绝对速度。

如果权重在 200 KB 到 1 MB 之间，NPU 的价值就明显了，但你会立刻撞上 Flash 预算和 OTA 的墙。这时候我建议优先考虑带外部 QSPI 存储、并且 NPU 支持直接从外部存储流式读权重的方案。

如果权重超过 1 MB，说实话 MCU 这条路就开始别扭了。你要么做更激进的量化（4 位权重、稀疏化），要么把模型切成多段分时加载，要么承认这件事应该交给带 DDR 的 SoC 去做。硬上不是不行，但每一分优化都要靠工程师手工堆出来，维护成本会很高。

最后分享一个我一直在用的习惯：在写第一行固件代码之前，先把那张内存预算表填满，把每一个数字都算出来，哪怕估算得不准也要写。项目做到一半再去算内存，代价通常是要推翻已经完成的模型设计或者内存布局。这张表不花什么时间，但它能提前告诉你这个方案到底成不成立。