2、TinyML基础与运行时架构：TinyML定义、典型硬件约束、运行时组件（调度器、内存管理器、算子执行器）概览
TinyML（微型机器学习）是指在极低功耗、极小存储和有限计算能力的嵌入式设备上运行机器学习推理任务的技术体系。它并非简单地将深度学习模型“压缩”后塞进单片机，而是一套从模型设计、量化压缩、编译优化到运行时调度的系统工程。理解TinyML的运行时架构，是掌握buffer生命周期与复用策略的前提——因为内存管理的所有规则，本质上都是围绕运行时各组件的协作方式展开的。本章将首先厘清TinyML的定义边界与硬件约束，再剖析运行时三大核心组件（调度器、内存管理器、算子执行器）的职责与交互关系，为后续章节的buffer分配、生命周期追踪和复用策略打下坚实的架构基础。
上图展示了TinyML运行时架构的全景：底层是硬件约束，中间是三大运行时组件，顶部是贯穿始终的buffer生命周期管理。这张图将作为贯穿全章的“地图”，后续所有关于内存分配、算子执行和调度策略的讨论，都可以在这张图上找到对应的位置。
2.1 TinyML的定义与边界
核心原理：TinyML并非一个严格的学术术语，而是一个工程实践领域的统称。它涵盖了在资源极度受限的嵌入式设备上部署机器学习模型的所有技术手段。与云端AI或移动端AI（如Android Neural Networks API）不同，TinyML设备通常没有操作系统，或者仅运行一个极简的实时操作系统（RTOS），且不具备完整的文件系统。其典型特征是：毫瓦级功耗、KB级内存、MHz级主频。这意味着，任何在TinyML设备上运行的模型，都必须经过精心设计，以适配这种“贫瘠”的资源环境。
判断方法：如何判断一个项目是否属于TinyML范畴？可以从三个维度进行界定：
- 功耗维度：设备是否依赖电池供电，且目标续航时间以月或年为单位？典型TinyML设备的平均功耗在1mW~100mW之间。
- 内存维度：可用RAM是否小于512KB？这决定了模型权重和中间激活值必须被极致压缩。
- 计算维度：是否没有GPU、没有NPU（或仅有极简的硬件加速器），依赖CPU完成所有计算？
如果以上三个问题的答案都是肯定的，那么该场景就属于TinyML的典型应用范围。例如，一个使用Cortex-M4芯片、配备64KB SRAM的智能传感器节点，需要运行一个关键词唤醒模型，这就是一个标准的TinyML场景。
2.2 典型硬件约束对运行时设计的影响
核心原理：硬件约束不是“背景板”，而是决定运行时架构设计的“第一性原理”。TinyML的三大硬件约束——SRAM容量、Flash容量和CPU算力——分别对运行时组件提出了不同的设计要求。
| 硬件资源 | 典型范围 | 对运行时的影响 | 设计对策 |
|---|---|---|---|
| SRAM（运行时内存） | 16KB ~ 512KB | 无法容纳完整的深度学习框架；所有中间张量必须精打细算 | 静态内存规划、buffer复用、in-place计算 |
| Flash（存储） | 128KB ~ 2MB | 模型权重存储受限；代码段大小直接影响可用Flash | 权重量化（int8/int4）、算子融合减少代码量 |
| CPU（计算） | 几十MHz ~ 几百MHz | 无法执行复杂指令；浮点运算代价极高 | 定点运算、查表法、SIMD优化（如Cortex-M4的DSP指令） |
| 外设（传感器/DMA） | 数量有限 | 数据采集方式影响调度器的触发模式 | DMA直传、中断驱动、双缓冲机制 |
操作流程：在进行运行时架构设计前，建议按以下步骤完成硬件约束评估：
- 列出目标芯片的SRAM总量，并扣除RTOS内核、任务栈、全局变量占用的固定开销，得到“可用内存预算”。
- 估算模型推理所需的峰值内存（权重+最大中间张量），与预算对比。
- 评估CPU的算力是否满足实时性要求（例如，每100ms完成一次推理）。
- 根据评估结果，决定是否需要采用内存复用策略，以及复用的激进程度。
2.3 运行时三大组件：调度器、内存管理器、算子执行器
核心原理：TinyML运行时可以抽象为三个职责清晰、协作紧密的组件。理解它们各自的职责边界和交互方式，是掌握buffer生命周期管理的关键。
2.3.1 调度器（Scheduler）
调度器负责决定“何时执行什么任务”。在TinyML场景中，调度器通常比通用OS的调度器更简单，但更强调可预测性和低开销。它需要处理以下几类任务：
- 推理任务触发：由定时器、传感器中断或外部事件触发模型推理。
- 任务优先级管理：例如，处理传感器数据的中断服务程序（ISR）优先级高于普通的推理任务。
- 低功耗调度：在无任务时进入睡眠模式，仅在需要时唤醒。
调度器与buffer生命周期管理的关联在于：调度策略直接决定了buffer的存活时间。例如，如果采用“单次推理完成即释放所有内存”的调度策略，那么buffer的分配和释放就非常频繁；如果采用“常驻内存池”策略，则buffer的分配是一次性的，后续推理只是复用。
2.3.2 内存管理器（Memory Manager）
内存管理器是本章的核心关注点。在TinyML中，内存管理器通常不采用通用OS的malloc/free机制（因为碎片化和不可预测性），而是采用静态分配、内存池或Arena分配策略。其核心职责包括：
- 内存规划：在编译期或启动时，为所有算子预先分配好内存块。
- 生命周期追踪：记录每个buffer的创建、使用和销毁时机。
- 复用决策：当两个buffer的生命周期不重叠时，将它们映射到同一块物理内存。
内存管理器的设计质量，直接决定了模型能否在有限的SRAM中运行。例如，一个包含10个算子的模型，如果每个算子都独立分配内存，峰值内存可能是所有中间张量之和；而通过生命周期分析和复用，峰值内存可以降低到最大单个中间张量的大小。
2.3.3 算子执行器（Operator Executor）
算子执行器是实际执行计算的组件。它接收内存管理器分配的buffer，执行卷积、全连接、激活函数等操作。算子执行器对buffer生命周期的影响体现在：
- 输入/输出buffer的访问模式：某些算子（如卷积）需要同时访问输入和输出buffer，且访问模式是“滑动窗口”式的，这对buffer的对齐和连续性提出了要求。
- in-place操作支持：某些激活函数（如ReLU）可以在输入buffer上直接修改，无需额外分配输出buffer，这可以显著节省内存。
- 临时buffer需求：某些算子（如im2col变换）需要额外的临时buffer，这些buffer的生命周期仅限于该算子执行期间。
2.4 三大组件的协作流程与Buffer生命周期
操作流程：一个完整的TinyML推理任务，其运行时协作流程如下：
- 初始化阶段：调度器启动，内存管理器完成静态内存规划，为所有算子分配好buffer（或建立内存池）。
- 触发阶段：传感器中断到达，调度器唤醒推理任务。
- 执行阶段：算子执行器按顺序执行各算子。每个算子从内存管理器获取输入buffer，执行计算，将结果写入输出buffer。
- 完成阶段：推理结果写入指定输出位置，调度器将设备切换至低功耗模式，等待下一次触发。
在这个过程中，buffer的生命周期可以划分为四个阶段：分配（Allocate）→ 使用（Access）→ 释放（Free）→ 复用（Reuse）。其中，“复用”是TinyML内存优化的核心手段，也是后续章节将要深入展开的主题。
| 生命周期阶段 | 负责组件 | 关键操作 | 常见问题 |
|---|---|---|---|
| 分配 | 内存管理器 | 从内存池中划出指定大小的连续区域 | 内存碎片、对齐不满足要求 |
| 使用 | 算子执行器 | 读写buffer中的数据 | 越界访问、未初始化数据 |
| 释放 | 内存管理器 | 将buffer标记为可复用 | 提前释放导致数据被覆盖 |
| 复用 | 内存管理器+调度器 | 将不同生命周期的buffer映射到同一物理地址 | 生命周期分析错误导致数据冲突 |
2.5 常见误区与总结复盘
误区一：认为TinyML运行时必须包含一个完整的操作系统。实际上，大多数TinyML设备运行的是裸机程序或极简RTOS（如FreeRTOS的裁剪版），运行时组件直接与硬件交互，没有进程/线程的概念。
误区二：将内存管理器等同于malloc/free。在TinyML中，动态内存分配是“禁忌”，因为malloc会导致不可预测的碎片化和执行时间抖动。正确的做法是采用静态分配或内存池。
误区三：忽视调度器对内存的影响。调度策略（如是否支持多任务并发）直接决定了buffer的生命周期重叠情况，进而影响内存复用的可能性。
误区四：认为算子执行器只是“计算单元”。实际上，算子执行器的实现方式（如是否支持in-place操作、是否需要临时buffer）对内存占用有重大影响。