端侧内存预算：权重、KV 与 SRAM 的三方挤压

本实验计算：

$$M_{\text{total}} = \frac{P \times b}{8} + A + K + O$$

$P$ 是参数量，$b$ 是位宽，$A$ 是峰值激活，$K$ 是 KV 缓冲，$O$ 是栈、DMA 与对齐余量。

默认例子

2M 参数、4-bit 权重：

$$2{,}000{,}000 \times 4 / 8 = 1{,}000{,}000 \text{ B} \approx 977 \text{ KiB}$$

如果目标只有 512 KiB SRAM，仅权重就已经超出。即使权重放在外部 Flash，推理时仍需把当前层和临时块读入 SRAM，访问延迟与带宽会成为新问题。

检查顺序

1. 权重是否必须全驻留，能否流式加载？
2. 峰值激活发生在哪一层？
3. 最长上下文与并发下的 KV 是多少？
4. 栈、DMA、驱动与中断是否留足余量？
5. 量化算子是否增加临时缓冲？

打开 TinyML 内存预算 调整位宽和 SRAM。不要只把参数量乘位宽就宣布可行，尤其当模型包含注意力或动态形状时。

模型只回答“是否还值得继续”

这个实验忽略了大量真实系统细节，所以它的用途不是给出最终内存数字，而是尽早排除不可能的配置。若静态权重已经超过可用 SRAM 数倍，继续讨论 kernel 优化没有意义；若权重明显可行，也不能据此宣布部署成功。

真实嵌入式工程中，内存会按 section 被分配到不同区域：Flash 中的只读权重、SRAM 中的 .data/.bss、栈、堆、TCM、DMA 可访问缓冲，以及某些芯片特有的紧耦合内存。链接脚本可能把同一块物理 SRAM 分成多个不连续区间，模型无法仅凭总容量判断能否通过链接器。

以 512 KiB SRAM 为例，预算表至少应包含：

项目	需要确认的内容
权重	是否全驻留、是否可分层流式加载、对齐与打包损耗
激活	峰值出现在哪一层、是否与权重同时活跃
KV	最大上下文、并发与量化方式
栈	主栈、中断栈、协程栈的最坏深度
DMA	双缓冲、描述符、cache line 对齐
系统	RTOS 对象、驱动状态、日志与 OTA 预留

一个常见的误判是只计算 parameters × bits / 8。若模型使用 4-bit 打包，循环中仍可能把权重反量化到 8-bit 或 16-bit 的临时缓冲；若算子按 tile 工作，峰值激活会随 tile 数增加；若使用双缓冲，DMA 缓冲要乘以二。任何一项都可能让“刚好放下”变成运行时溢出。

权重放 Flash 不等于没有内存问题

把权重放在外部 Flash，可以显著降低对 SRAM 的静态占用，但推理时仍需要把当前 tile 读入片上缓冲区。读取延迟和带宽会进入 token 时间；若每层都重新读权重，缓存命中率决定持续吞吐。对多个并发请求，权重流式加载还会与 KV 和输入预处理争抢总线。

因此，“模型文件 1 MiB、设备 Flash 2 MiB”只是一条存储约束，不是部署证明。真正的检查是：在最坏输入下，权重 tile、激活 tile、KV、栈和 DMA 缓冲的峰值是否同时小于可用 SRAM，并保证最坏执行时间与中断抖动仍在截止期内。

四步验证法

1. 用工具链生成静态 arena 报告，核对权重、常量和只读数据的 section。
2. 用最长输入和最大 batch 跑一次内存图，记录峰值与分配次数。
3. 在真实设备上打开栈水位、堆水位和 DMA 计数，模拟传感器与通信中断。
4. 把温度、时钟和电压设置到最不利组合，检查是否发生动态降频或链接区溢出。

实验中的线性公式适合做纸面预算，真实结果必须以目标硬件和最终编译选项为准。任何“理论可放”但未经 arena 报告和实测的结论，都应保留为待验证假设。

参数如何影响结论

权重位宽从 8-bit 降到 4-bit，静态权重近似减半，但激活、KV 和运行时不一定变化。若模型从 FP16 改为 INT8，未量化层可能需要插入 cast 和反量化缓冲，峰值内存反而上升。SRAM 预算从 512 KiB 增加到 1 MiB 时，可能刚好容纳权重，却仍无法容纳最长上下文的 KV。

因此，敏感性分析应一次只改变一个变量，并记录总占用、峰值和是否溢出。最有价值的结论往往不是“能放”，而是“在哪个输入长度/上下文/位宽下第一次失败”。

外部存储与实时性

权重放在外部 Flash 能降低静态 SRAM 占用，但读取延迟和带宽可能破坏实时性。若模型需要连续解码，权重流式加载必须与计算重叠；若 Flash 读取阻塞总线，传感器中断可能延迟。设计时应测量最坏读取时间，并把 DMA 与中断优先级一起分析。

对于需要安全启动的设备，外部 Flash 还可能涉及解密和完整性校验。启动时间、密钥存储和外部总线监听都会改变端到端预算。

可观察性

一个可部署的 TinyML 系统应暴露剩余 SRAM、栈水位、KV 使用率、DMA 队列和最坏推理时间。出现异常时，日志要能定位到具体阶段：权重加载、prefill、decode、后处理。仅报告总推理时间无法区分模型层和运行时层的瓶颈。

这些指标不应依赖高开销调试工具常驻。可在开发构建中启用完整 trace，在发布构建中保留低开销计数器和错误快照。

最后，任何预算表都要标注测量口径：MiB 与 MB 是否混用，是否包含元数据，是否按最坏并发计算，是否计入双缓冲。统一口径比小数点后两位更重要，否则团队会在错误的总量上继续优化。

预算通过后，还应保留至少 20% 的安全余量。固件升级、日志和新的算子实现都可能增加峰值内存，没有余量的系统很难跨版本维护。

在评审记录中写明“当前配置在哪个输入长度或并发下首次超限”，比只写“默认配置通过”更有决策价值。