我的《AI+嵌入式：让单片机学会思考》课程开课以来，接触了非常多的学员，学员们在认可【AI+嵌入式】的前景外，更多的是一些没有接触过TinyML学员，所以会问一下偏基础的问题"我的xxxMCU上能不能运行TinyML？"。
今天，小编再整理一篇科普文章，重点讲清楚两点：
（1）TinyML适合在哪些MCU上运行？
（2）怎么评估我们的MCU能不能运行TinyML？
一、TinyML 是什么
TinyML 不是某一颗"专用芯片"，也不是某一个"固定框架"。它更像是一类工程做法：把机器学习模型的推理（必要时含少量特征提取）放到微控制器（MCU）上本地运行，让设备在端侧完成识别、检测、分类、回归等任务。
以 Google 的 LiteRT for Microcontrollers（原 TensorFlow Lite Micro）为例：它面向"只有几 KB 内存"的微控制器，核心运行时在 Arm Cortex-M3 上可压到约 16KB 量级，并且不依赖操作系统、标准 C/C++ 库或动态内存分配。
这段话很重要：TinyML 能不能跑，首先看"推理运行时 + 我们模型 + 模型的输入/预处理"整体能否在 MCU 的 Flash/RAM/算力/功耗预算内闭环。
二、哪些 MCU 已经"被定义/被验证"可以运行 TinyML？
下面我们通过一些"官方"的文章/资料来了解清楚已经被定义或者验证可运行TinyML的MCU
1、Google LiteRT for Microcontrollers（TFLM）
Google 在官方文档里明确给了"Supported platforms / Supported boards"，如下面截图所示：
从上面的网页内容可以总结下面几点：
平台要求 ：C++17，且要求 32 位平台；大量在 Arm Cortex-M 系列上做过广泛测试，并移植到了 ESP32 等架构；可作为 Arduino 库使用，也可生成 Mbed 等开发环境工程。
支持的开发板：Arduino Nano 33 BLE Sense、SparkFun Edge、STM32F746 Discovery、Adafruit EdgeBadge、ESP32-DevKitC、ESP-EYE、Wio Terminal（ATSAMD51）、Himax WE-I Plus、Synopsys ARC EM 平台、Sony Spresense 等
上面这些开发板背后的MCU架构是：Cortex-M4/M7、Cortex-M0+（ATSAMD51 实际是 M4F）、ESP32（Xtensa）、ARC DSP 等。
2、ARM CMSIS-NN
CMSIS-NN 是ARM针对 Cortex-M 的神经网络算子优化库。它的用户手册明确说明：目标是在 ARM Cortex-M 处理器上最大化性能、最小化内存占用。
并且它按指令能力把 Cortex-M 分成三类实现路径：
-
无 SIMD（例如 Cortex-M0）
-
带 DSP 扩展（例如 Cortex-M4）
-
带 MVE/Helium（例如 Cortex-M55）
这等于给了我们一条非常清晰的结论：同样跑 TinyML，Cortex-M4/M33(带DSP)/M7/M55 这类"有 DSP/向量能力"的 MCU，通常更合适、更省时延、更省能耗。
3、STM32Cube.AI
ST 的 STM32Cube.AI 页面明确说：它可以把训练好的神经网络模型优化并部署到任意 STM32 微控制器上，并且提供模型分析信息（参数量、复杂度、以及 RAM/Flash 需求等），还能做板级验证与内外存权衡优化。
此外，在 STM32Cube.AI 用户手册（UM2526）的描述中，也给出了明确的系列覆盖举例：STM32F3/F4/F7/H7/L4/L5/G4/G0/C0/WB/WL/U0/U5 等，并说明这些开发板可以作为验证平台。
4.综上
综上，针对可以哪些MCU可以运行TinyML进行总结：
-
Google 给出通用 TinyML 运行时的平台要求 + 已验证板卡；
-
Arm 给出 Cortex-M 上跑 NN 的优化路径与适配分层；
-
ST 给出 STM32 生态内的部署工具与可量化评估手段。
三、从实际工程落地的层面分析TinyML 适合哪些 MCU？
综合上面的"官方定义/验证来源"，我们可以把"可以运行TinyML"分成三层来讲：
第一层：能跑起来（验证型/入门型 TinyML）
典型目标：Hello World（正弦回归）、简单阈值替代的二分类、小型异常检测等
这类能跑通TInyML对MCU要求的特征是：
-
32 位 MCU，能编译 C++（最好 C++17），有基本串口/定时器用于测量与输出。
-
即便是 Cortex-M3，官方也明确"核心运行时可放进 16KB"，可以跑不少基础模型。
特殊提醒：这里"能跑TinyML"还并不能代表"能跑我们的业务模型"。很多项目失败不是运行时装不下，而是特征提取缓存 + 中间激活张量能模型运行中操作导致RAM不够用。
第二层：跑得合理（量产常用型 TinyML）
第二层应用的典型目标包括传感器时序分类（振动/电流/姿态）、关键词唤醒、小分辨率图像粗分类等。
针对第二层级比较常见的"合适"架构：
-
Cortex-M4/M7/M33（尤其 M4 带 DSP、M7 高频、M33 带 DSP/FPU 的配置）
-
选择理由：CMSIS-NN 在这些核心上有更强的优化实现路径（DSP/向量化），单位时延与能耗表现更可控。
如果你追求"同一颗 MCU 上同时跑外设实时任务 + AI 推理"，这层最常见，也是课程/量产项目最值得投入的区间。
第三层：跑得更大/更快（视觉/多模态/更复杂网络）
这一层应用的典型目标包括：更高分辨率视觉、多人/多类检测、更复杂的时序模型、端侧多任务。
针对第三层级，比较常见的MCU方案为：
-
Cortex-M55/M85 +（可选）NPU（Ethos-U、Neural-ART 等）
-
或MCU + 外部 RAM/Flash（QSPI/SDRAM）做权重与缓存扩展
-
从 Edge Impulse 的硬件列表就能看到：带加速器的 MCU 平台已经成为一类独立分组（"MCU + AI Accelerators"）。
这层的关键不再只是"能不能放下模型"，而是"吞吐、功耗、内存带宽、数据搬运"是否成为系统瓶颈。
四：怎么评估"我们的 MCU 能不能运行 TinyML"？
当我们评估"我们的 MCU 能不能运行 TinyML"的时候，我们的评估对象不是"MCU + TinyML"这两个名词，而是"某个业务模型 + 某套输入/预处理 + 某个 MCU + 某个运行时/工具链"组合是否闭环。
下面我提供一套从0到结论的评估流程，我们直接跟着照做就即可。
Step 0：先把问题定清楚
当我们需要开始评估我们的MCU能否运行TInyML之前，至少整理了解清楚下面这 6 个量，它们直接决定了所需要的RAM/算力/功耗等等参数。
（1）传感器类型（IMU/麦克风/电流/图像），这里其实决定了我们要做什么样的系统、使用到什么样的数据进行模型训练。
（2）采样率与采样位宽（例如 16kHz/16bit 音频）：直接决定单位时间的数据吞吐量（缓冲区大小、DMA/中断压力）与可用信息带宽。因此会拉动 RAM 需求、CPU 占用和整体功耗的下限。
（3）窗口长度与滑窗步长（例如 1s 窗、100ms 步）：决定一次推理需要累积的数据量与输出频率，进而确定输入张量规模、实时性节拍，以及"预处理+推理"必须满足的时间预算。
（4）预处理方法（FFT/MFCC/滤波/归一化/特征拼接）：决定端侧额外的计算与缓存开销，并且决定模型的输入形态（波形/特征图/统计特征），从而影响是否需要 DSP/FPU、以及我们的RAM峰值是否会被预处理缓冲顶爆。
（5）模型类型与输入维度（1D CNN/DS-CNN/LSTM/小型 MobileNet 等）：决定模型权重大小（Flash）与中间激活峰值（RAM），同时决定推理算力/时延以及算子是否容易被 TFLM/CMSIS-NN 等端侧库支持与加速。
（6）端侧输出策略（触发事件/概率分布/回归值）：决定后处理复杂度与系统闭环方式（阈值、投票、滤波等），并影响上报数据量与功耗策略（只上报事件还是持续上报结果）。
这一步的作用：让你后续的"RAM/Flash/Latency"估算有边界。
Step 1：用"官方工具"先得到第一版数字
这一步不是为了最终结论，而是为了快速排除"不可能"。
-
如果用Edge Impulse ：Studio 里可以直接 Profiling 估算 内存、Flash、时延。
-
如果STM32Cube.AI ：在它的分析界面会给出参数量、复杂度（MACC）、以及详细的 RAM/Flash 需求，并支持在板上验证与内外存权衡。
经验上，这一步就能筛掉大量方案：例如"模型本体不大，但预处理缓存很大"的情况，会立刻暴露。
在这一步，我们会经常遇到的一种情况：模型已经设计好了，但是由于MCU不支持的算子，导致cube AI解析模型不成功。
Step 2：Flash 评估
Flash 不是只有一个 .tflite 文件那么简单，至少包含：模型权重（常量区）、推理运行时与算子实现（TFLM/LiteRT Micro、CMSIS-NN、你启用的 op kernel）、预处理代码（FFT/MFCC/DSP 库）、外设驱动与系统代码（日志、协议栈、RTOS 可选）等等内容。
一种比较常用的工程做法是：
-
先用最小 demo（如当前我们已经验证的Hello World正弦波模型）在目标工程里编译一次，得到"运行时 + 工程骨架"的基本大小；
-
再把模型与预处理接入，观察增量；
-
用 map 文件把 Flash 大头定位出来（通常是：某些算子实现 + DSP 预处理 + 权重常量区）。
Step 3：RAM 评估，这一点是TinyML 最常见的失败点
MCU 上的 RAM 主要会下面几块内容占用：
-
Tensor Arena（激活张量 + scratch buffer）
-
模型输入/输出 buffer（含量化/反量化缓冲）
-
预处理 buffer（音频环形缓冲、FFT 输入输出、特征图缓存等）
-
任务栈、协议栈 buffer、DMA buffer、双缓冲等系统开销
关键点在于：
LiteRT Micro明确强调其不使用动态内存分配、需要手工管理内存；同时也提醒"支持的算子子集有限"。
这意味着你很容易遇到两类问题：
-
**Arena 够不够：**不够就直接 AllocateTensors 失败或运行崩溃
-
**算子是否支持：**不支持就算内存足够也跑不通
在这一步中，比较常用的真实做法是：
（1）先让模型在 MCU 上能跑通一次推理，然后把 arena 使用量打印出来/记录下来（TFLM/LiteRT Micro 的示例通常会提供类似统计口径）；
（2）再逐项加上你的预处理与系统任务，看 RAM 峰值是否超过可用 RAM；
如果我们用 STM32Cube.AI，可直接看到它按层给出的 RAM 分配与外/内存策略建议。
Step 4：算力/时延评估
这一点决定了决定我们的模型运行"能不能实时"。最核心的判断是：在我们的滑窗节拍下，推理和预处理能否在时间预算内完成。
（1）建议从两端测试时延
-
预处理耗时（FFT/MFCC/滤波/归一化）
-
推理耗时（Invoke）
（2）对照我们的节拍：
例如我们每 100ms 做一次推理，那么"预处理 + 推理 + 余量"必须显著小于 100ms（通常至少留 30% 以上余量给系统与抖动）。
这里，提供一条加速路径：
-
Cortex-M 上优先使用 CMSIS-NN 路径（M4/M55 等有明显收益）。
-
如果我们选择了"带 NPU"的 MCU（例如我们课程中配套硬件STM32N6 的 Neural-ART）上评估，则要把"数据搬运/量化格式/内存布局"作为时延的一部分考虑。
Step 5：功耗评估（针对需要电池供电的设备）
针对电池供电的设备来说，MCU 跑 TinyML 是否"合适"，最终通常是由功耗决定的。如果我们是电池供电，关键不是"单次推理多耗电"，而是"推理频率 + 预处理占空比 + 无线传输策略"叠加后的平均电流。
TinyML 的常见优势之一是：在端侧完成判断后，只上传"事件/摘要"，减少无线通信的长期耗电与延迟风险。
比较常用的工程做法：
-
先测"空闲功耗基线"（MCU + 传感器 + 低功耗模式）
-
再测"推理占空比下的平均功耗"（例如每秒推理 10 次）
如果平均功耗不达标，再回到模型与节拍做折中：降低推理频率、改特征提取方式、换更合适的模型结构、或选择带加速器的平台。
Step 6：算子支持与工程集成
最后这一点决定我们的项目"能不能顺利落地"
两条硬约束必须在评估早期确认：
算子子集：LiteRT Micro 明确说明只支持 TensorFlow 的"有限子集算子"，不支持端侧训练，并且 API 偏底层，需要手工内存管理。
工具链与生态：我们是否能在现有工程里稳定集成（编译器/RTOS/驱动/调试），并具备持续迭代的路径（模型更新、版本回滚、日志与诊断）。