3. 硬件平台概览
TinyML 的落地效果，往往在选型阶段就已经被决定了一半。模型再精巧，如果 MCU 的 SRAM 装不下中间张量，或者无线模块的峰值电流超出纽扣电池的承受能力，系统就无法真正跑起来。本节从算力、内存、功耗、成本四个约束出发，梳理 MCU、NPU、DSP、传感器与无线模块的选型逻辑。
一、核心原理：四类计算单元的分工
嵌入式端侧推理的硬件通常由四类角色构成，它们并不是互相替代，而是按任务特征分工：
- MCU（微控制器）：负责系统控制、任务调度、外设驱动和轻量推理。典型内核为 Cortex-M0+/M4/M33/M55，主频 24～480 MHz，SRAM 从几十 KB 到 1 MB 以上。它是 TinyML 的“主脑”，也是功耗预算的主要消耗者。
- NPU（神经网络加速器）：面向卷积、矩阵乘等算子做定点加速，能效比可达 MCU 软件推理的 10～100 倍。常见形态是 MCU 厂商集成的微型 NPU（如 Ethos-U55/U65、CMSIS-NN 加速扩展），算力从 0.1 TOPS 到数 TOPS。
- DSP（数字信号处理器）：擅长 FIR/IIR 滤波、FFT、MFCC 等信号前端处理，常与 MCU 同核或异构集成（如 Cortex-M4 的 DSP 扩展、HiFi DSP）。语音、振动、雷达类应用几乎离不开它。
- 传感器与无线模块：传感器决定输入数据质量与采样功耗，无线模块（BLE、LoRa、Wi-Fi、NB-IoT）决定通信功耗与系统架构。二者常是整机功耗的大头。
选型的本质是：让模型的计算图与硬件的存储层次、算子能力、功耗曲线三者匹配。任何一项错配，都会导致“能跑但跑不久”或“省电但算不动”。
二、四维约束：内存、算力、功耗与成本
四个约束相互牵制，需要同时评估：
- 内存约束：Flash 决定模型权重能否放下，SRAM 决定激活值与中间张量能否驻留。经验上，int8 量化模型的权重约占 Flash 的 1 字节/参数，而激活峰值常是权重的 1～3 倍。若 SRAM 不足，需要算子分块（tiling）或外部 PSRAM，但会带来延迟与功耗上升。
- 算力约束：以 MAC（乘加）数估算。MCU 软件推理约 1～10 MAC/cycle，NPU 可达数百 MAC/cycle。若模型为 5 MMAC、目标 10 fps，则需 50 MMAC/s，MCU 在 100 MHz 下已接近上限，此时应引入 NPU 或降低模型规模。
- 功耗约束：关注工作电流、睡眠电流与占空比。纽扣电池（CR2032，约 220 mAh）若要求 1 年寿命，平均电流需低于 25 µA。这意味着 MCU 大部分时间处于 STOP/STANDBY，传感器与无线模块必须间歇工作。
- 成本约束：BOM 成本、PCB 面积、开发工具链授权、认证费用都需计入。NPU 与无线模块往往是成本增量最大的两项，需按量产规模权衡。
三、选型流程与参数对照
建议按“任务画像 → 资源估算 → 候选筛选 → 实测验证”四步推进。先明确推理频率、输入维度、精度要求与供电方式，再估算 Flash/SRAM/MAC/平均电流，最后用开发板实测推理延迟与功耗曲线。
| 平台类型 | 典型算力 | 内存规模 | 功耗特征 | 适用场景 |
|---|---|---|---|---|
| 低端 MCU（M0+） | < 1 MMAC/s | 16～64 KB SRAM | µA 级睡眠，mA 级运行 | 关键词唤醒、简单阈值分类 |
| 中端 MCU（M4/M33） | 1～50 MMAC/s | 128～512 KB SRAM | STOP 模式 < 5 µA | 振动异常检测、手势识别 |
| MCU + 微型 NPU | 0.1～1 TOPS | 512 KB～2 MB | NPU 能效比高，需管理唤醒 | 视觉关键词、语音命令词 |
| MCU + DSP | 10～100 MMAC/s | 256 KB～1 MB | FFT 功耗低于软件实现 | 音频前端、雷达信号处理 |
| 无线 SoC（BLE/LoRa） | 视集成内核而定 | 64～256 KB | 收发峰值 5～50 mA | 低功耗传感节点、远程上报 |
四、案例：电池供电的语音唤醒节点
需求：纽扣电池供电，1 年寿命，本地唤醒词识别，唤醒后通过 BLE 上报。选型过程如下：
任务画像：
推理频率：连续监听，唤醒事件 < 10 次/天
输入：16 kHz 单声道音频，MFCC 特征
模型：DS-CNN Small，约 0.5 MMAC/帧，int8 量化
权重：约 40 KB Flash，激活峰值约 60 KB SRAM
资源估算：
MCU：Cortex-M33 @ 64 MHz，256 KB Flash / 128 KB SRAM
DSP：使用 CMSIS-DSP 做 MFCC，降低 CPU 占用
无线：BLE 5.0，广播间隔 1 s，连接时峰值 8 mA
平均电流目标：< 25 µA
实测验证：
推理延迟：12 ms/帧，CPU 占用约 18%
监听平均电流：9 µA（MCU STOP + 传感器间歇采样）
BLE 上报平均电流：3 µA（按 10 次/天折算）
合计约 12 µA，满足 1 年寿命
该案例说明：唤醒词识别并不一定需要 NPU，合理使用 DSP 与低功耗 MCU 即可满足；真正的功耗瓶颈往往在无线模块的占空比管理，而非推理本身。
五、常见误区与复盘
- 只看峰值算力，忽略内存带宽：NPU 算力再高，若 SRAM 不足导致频繁搬运权重，实际延迟可能反而高于 MCU。
- 低估传感器功耗：MEMS 麦克风、IMU 的连续采样电流常达数百 µA，需用间歇采样或硬件 FIFO 降低占空比。
- 忽略无线模块的启动电流：BLE 连接建立瞬间电流可达数十 mA，若电源设计余量不足，会导致复位或丢包。
- 过早锁定 NPU：许多 TinyML 任务用 MCU + CMSIS-NN 即可完成，NPU 会增加成本与工具链复杂度，应按实测数据决策。
- 忽视工具链成熟度：NPU 的编译器、算子支持、量化流程是否完善，直接决定开发周期，选型时应优先验证模型能否顺利部署。
选型复盘时，建议记录“模型规模—内存占用—推理延迟—平均电流”四组实测数据，形成团队内部的选型基线，后续项目可直接复用，减少重复试错。
综上，硬件平台选型不是追求单项指标最高，而是在内存、算力、功耗、成本之间找到与任务匹配的平衡点。先用任务画像约束候选范围，再用实测数据验证，才能让 TinyML 系统真正稳定、持久地运行。