1. 从零拆解一块 TinyML 开发板的硬件构成1.1 为什么 TinyML 开发板不是“缩小版树莓派”很多人第一次接触 TinyML 开发板脑子里浮现的画面就是“把树莓派做小一点”。这个理解偏差非常大也是我在选型阶段踩过的第一个坑。TinyML 的核心目标是在毫瓦级功耗、KB 级内存、几块钱成本的约束下跑通推理任务。它和 Linux 单板电脑走的是两条完全不同的技术路线。树莓派这类设备依赖操作系统、DDR 内存、多核 CPU功耗动辄几瓦。而 TinyML 开发板通常是一颗 MCU 加一堆传感器没有操作系统程序直接跑在裸机或 RTOS 上。它的“AI 能力”不是靠算力堆出来的而是靠模型压缩、定点量化、算子裁剪这些手段把原本几百 MB 的模型压到几十 KB再塞进 SRAM 里跑。所以讨论 TinyML 开发板的硬件本质上是在讨论一颗什么样的 MCU、配多少内存、接哪些传感器、怎么供电、怎么调试才能让一个已经量化好的小模型稳定跑起来。这个问题的答案直接决定了你能不能把 demo 变成产品。1.2 一块典型 TinyML 开发板的硬件全景我先把一块典型 TinyML 开发板的硬件模块拆开列一遍后面每个部分再展开讲主控 MCU带 DSP 指令或 NPU 加速的微控制器是整块板子的核心存储Flash 存固件和模型权重SRAM 存运行时张量和中间结果传感器麦克风、IMU、摄像头、环境传感器等负责采集原始数据供电与电源管理电池接口、LDO 或 DC-DC、低功耗模式控制调试与烧录接口SWD/JTAG、串口、USB 转串口芯片扩展接口GPIO、I2C、SPI、UART用于外接模块时钟与复位晶振、复位电路保证时序稳定这七块里主控和存储决定了“能不能跑”传感器决定了“跑什么”供电决定了“能跑多久”调试接口决定了“好不好开发”。选型时如果只盯着主控算力忽略其他部分最后大概率会在功耗或数据采集环节翻车。1.3 本文适合谁看如果你正在做这几个方向的事情这篇内容应该能帮上忙想入门 TinyML但面对一堆开发板不知道从哪块下手已经跑通了官方 demo想自己画一块板子或做产品选型做嵌入式开发被要求“加个 AI 功能”需要评估硬件可行性做算法出身模型训好了但不知道怎么落到硬件上我会尽量把每个硬件模块的选型逻辑、参数计算、实操注意事项讲清楚让你看完能直接对照着做决策而不是停留在“知道有这么个东西”的层面。2. 主控 MCUTinyML 开发板的心脏2.1 普通 MCU 和 AI 加速 MCU 的本质区别普通 MCU 比如常见的 Cortex-M0/M3 系列跑控制逻辑没问题但拿来做神经网络推理会非常吃力。原因在于神经网络的核心运算——矩阵乘加——需要大量并行的乘法和累加操作。普通 MCU 一个时钟周期只能做一次乘加算一个几万次乘加的卷积层就要几万个周期。AI 加速 MCU 的差异体现在三个层面第一是 DSP 指令扩展。像 Cortex-M4/M7/M55 这些内核带 SIMD 和 MAC 指令一个周期能完成多次乘加。比如 M4 的 SMLAD 指令一次能做两个 16 位乘加。别小看这个提升实测下来推理速度能差 3 到 5 倍。第二是 FPU 浮点单元。虽然 TinyML 主流用 int8 量化但训练后量化过程中难免涉及浮点运算有 FPU 会舒服很多。不过要注意带 FPU 的 M4F 和 M7F 功耗也更高如果全程用 int8 推理FPU 其实用不上。第三是 NPU 或专用加速器。这是近几年新出的方向比如某些 MCU 内置了卷积加速单元能把推理功耗再降一个数量级。但代价是工具链复杂、算子支持有限模型稍微改一下就可能跑不了。我的建议是入门阶段选带 DSP 指令的 M4/M7 就够了别一上来就追 NPU。NPU 的生态还在成熟过程中调试成本高容易劝退。2.2 算力、内存、功耗的三角权衡选 MCU 本质上是在算力、内存、功耗这三个维度里做取舍三者不可能同时拉满。维度关键参数对 TinyML 的影响常见取舍算力主频、DSP 指令、NPU决定推理延迟主频越高功耗越大内存Flash 容量、SRAM 容量决定模型大小上限SRAM 越大芯片越贵功耗运行电流、休眠电流决定电池续航高性能模式功耗高举个具体的例子。假设你要跑一个关键词唤醒模型模型大小约 20KB输入是 1 秒的音频采样率 16kHz。推理一次需要的中间张量大概在 50KB 到 100KB 之间。那么你的 MCU 至少需要 128KB SRAM 才能比较从容地跑起来Flash 至少 256KB 存固件和模型。如果换成图像分类模型输入 96x96 的灰度图模型大小可能到 100KB 以上中间张量轻松超过 200KB。这时候就得选 SRAM 512KB 以上的芯片或者用外部 PSRAM 扩展。功耗方面一个经验值是Cortex-M4 跑 80MHz 时运行电流约 10mA 到 20mA休眠电流可以做到微安级。如果你的设备要求一颗纽扣电池跑一年那平均电流必须控制在几十微安意味着 MCU 绝大部分时间在休眠只有传感器触发时才唤醒推理。2.3 主流 MCU 选型对照与实操建议市面上适合 TinyML 的 MCU 大致分几个梯队我按实际使用体验说一下入门友好型带 M4 内核、SRAM 128KB 到 256KB 的芯片。这类芯片资料多、社区活跃、工具链成熟跑官方 TinyML 示例基本无障碍。缺点是算力有限复杂模型跑不动。进阶性能型M7 内核或双核架构主频 200MHz 以上SRAM 512KB 起。能跑稍大的模型但功耗和成本都上去了。适合对推理延迟有要求的场景。专用加速型内置 NPU 或卷积加速器。推理能效比很高但开发门槛也高适合已经有明确产品目标的团队。实操建议先用入门型芯片把整个流程跑通包括数据采集、模型量化、部署、功耗测量。等你对每个环节的瓶颈有感觉了再根据实际需求升级芯片。我见过太多人一上来就买最贵的开发板结果卡在工具链配置上连点灯都没跑通。注意选 MCU 时一定要确认厂商提供了完整的 TinyML 支持包包括推理引擎移植、算子库、示例代码。有些芯片硬件参数很漂亮但软件生态几乎是空白自己从零移植推理引擎的工作量会大到怀疑人生。3. 存储配置模型能不能塞进去的关键3.1 Flash 和 SRAM 的分工不能搞混Flash 和 SRAM 在 TinyML 里的角色完全不同搞混了会导致模型加载失败或者运行崩溃。Flash 是仓库用来存固件代码、模型权重、常量数据。它的特点是掉电不丢数据但读写速度慢写入寿命有限。模型权重在训练量化完成后就是固定的放在 Flash 里正合适。SRAM 是工作台用来存运行时变量、输入输出张量、中间计算结果。它的特点是读写快但掉电就丢而且容量小、价格贵。推理过程中每一层的输入输出都要在 SRAM 里倒腾。关键问题是模型权重虽然存在 Flash 里但推理时往往需要搬到 SRAM 里参与计算。如果 SRAM 不够大就得用“原地计算”或者“分块加载”的方式把模型切成几段轮流加载。这会增加代码复杂度也会拖慢推理速度。3.2 模型大小和内存占用的估算方法很多人不知道自己的模型到底需要多少内存这里给一个粗略但实用的估算方法。模型文件大小主要取决于参数量和量化位宽。一个 int8 量化的模型参数量乘以 1 字节就是权重大小。比如 50000 个参数的模型权重大约 50KB。但运行时内存占用远不止权重。推理过程中每一层的输入输出张量都要占内存。峰值内存通常出现在某几个大层比如第一个卷积层或者全连接层。估算公式大致是峰值 SRAM 需求 ≈ 最大单层输入张量 最大单层输出张量 权重缓存 栈空间栈空间容易被忽略但递归调用或者大数组局部变量会吃掉不少。我一般会预留 20% 到 30% 的余量。举个实际例子。一个用于手势识别的 IMU 模型输入是 128 个时间步、3 轴加速度共 384 个 float量化成 int8 后是 384 字节。经过几层一维卷积和全连接最大中间张量大概 8KB。权重 30KB。那么 SRAM 需求大约 8KB 8KB 30KB 栈空间总共 60KB 左右。选 128KB SRAM 的芯片就很稳。3.3 外部存储扩展的取舍当片上 Flash 和 SRAM 不够用时可以考虑外扩。常见方案有外部 SPI Flash成本低容量大适合存模型权重。但读取速度慢需要缓存机制外部 PSRAM容量比 SRAM 大速度比 Flash 快适合做张量缓存。但接口复杂功耗也高SD 卡容量巨大但功耗和体积都不适合 TinyML 场景我的经验是能用片上资源解决就别外扩。外扩存储会带来额外的功耗、布线复杂度和软件适配工作。如果模型实在太大优先考虑模型压缩而不是加内存。剪枝、量化、知识蒸馏这些手段往往能把模型缩小一半以上比加一颗存储芯片划算得多。提示有些 MCU 支持 XIP 模式就是代码直接在 Flash 里执行不用搬到 SRAM。但神经网络推理涉及大量数据读写XIP 的延迟会成为瓶颈。权重可以放 Flash但计算过程还是要在 SRAM 里进行。4. 传感器决定 TinyML 开发板能做什么4.1 传感器选型直接决定应用场景TinyML 开发板能做什么不取决于 MCU 多强而取决于板子上有什么传感器。传感器是数据的源头没有合适的数据再强的算力也没用。常见的传感器类型和对应场景传感器类型采集数据典型 TinyML 应用关键参数MEMS 麦克风音频波形关键词唤醒、异常声音检测采样率、信噪比IMU加速度、角速度手势识别、姿态检测量程、采样率、噪声密度图像传感器图像帧人脸检测、物体分类分辨率、帧率、接口环境传感器温湿度、气压环境监测、预测维护精度、响应时间生物传感器心率、血氧健康监测精度、功耗选传感器时采样率和精度要匹配模型需求。比如关键词唤醒模型通常需要 16kHz 采样率如果你选的麦克风最高只支持 8kHz那模型根本没法用。再比如手势识别IMU 的采样率至少要 50Hz 才能捕捉到完整动作低了会丢信息。4.2 数据采集链路中的硬件细节传感器到 MCU 之间的数据链路有几个容易被忽略的硬件细节。接口选择I2C 简单但速度慢适合低速传感器SPI 速度快适合 IMU 和图像传感器I2S 是音频专用接口麦克风基本都用它。选错接口会导致数据吞吐不够采样丢帧。时钟同步多传感器融合时如果各传感器时钟不同步数据时间戳对不齐模型效果会大打折扣。有些 MCU 支持传感器硬件触发能保证同步采集。模拟前端模拟传感器需要 ADC 采样ADC 的位数和采样率直接影响数据质量。12 位 ADC 是基本要求低于这个精度量化后的数据噪声会很大。抗混叠滤波采样之前必须做抗混叠滤波否则高频信号会混叠到低频污染数据。很多开发板为了省成本省略了这个环节导致采集的数据质量差模型训出来效果不好。4.3 传感器数据预处理对硬件的要求传感器采集的原始数据通常不能直接喂给模型需要预处理。预处理对硬件也有要求。以音频为例关键词唤醒模型通常输入的是 MFCC 特征而不是原始波形。MFCC 计算涉及 FFT、滤波器组、对数运算这些都需要算力。如果 MCU 没有 FPU 和 DSP 指令光算 MFCC 就能把 CPU 占满。再以 IMU 为例手势识别模型输入的是滑动窗口内的加速度序列。窗口切分、归一化、滤波这些操作都需要在 MCU 上实时完成。如果 MCU 主频太低预处理就会成为瓶颈。所以选 MCU 时不能只看推理算力还要看预处理算力。一个实用的判断方法是把预处理和推理的运算量加起来再对比 MCU 的算力余量。如果余量不足 30%实际运行时就容易出问题。注意有些开发板把传感器和 MCU 集成在一起但传感器数据要经过很长的排线才能到 MCU容易引入噪声。如果对数据质量要求高优先选传感器靠近 MCU 的板子或者自己画板时注意布局。5. 供电与电源管理决定能不能产品化5.1 功耗预算怎么算TinyML 开发板如果只是插着 USB 跑 demo功耗不是问题。但一旦要电池供电功耗就成了核心指标。算功耗预算的基本方法是平均电流 (运行电流 × 运行时间 休眠电流 × 休眠时间) / 总时间假设你的设备每 10 秒唤醒一次每次推理耗时 100ms运行电流 15mA休眠电流 5uA。那么运行阶段15mA × 0.1s 1.5mA·s休眠阶段0.005mA × 9.9s 0.0495mA·s平均电流(1.5 0.0495) / 10 ≈ 0.155mA如果用一个 200mAh 的纽扣电池理论续航约 200 / 0.155 ≈ 1290 小时约 54 天。这个结果说明休眠电流和唤醒频率对续航影响极大。把休眠电流从 5uA 降到 1uA或者把唤醒间隔从 10 秒延长到 60 秒续航都能翻好几倍。5.2 LDO 和 DC-DC 的选型逻辑电源转换芯片主要有两种LDO 和 DC-DC。LDO的优点是输出纹波小、电路简单、成本低。缺点是效率低输入输出压差越大损耗越大。比如输入 3.7V 电池输出 3.3V效率大约 89%。如果输出 1.8V效率就降到 48% 左右。DC-DC的优点是效率高通常能到 85% 到 95%而且压差大时优势更明显。缺点是输出纹波大、电路复杂、成本高而且轻载效率可能下降。选型建议如果 MCU 核心电压和电池电压接近用 LDO 就够了。如果压差大或者对续航要求极高用 DC-DC。有些设计会混合使用比如 DC-DC 降到中间电压再用 LDO 给模拟部分供电兼顾效率和噪声。5.3 低功耗模式的硬件配合MCU 的低功耗模式要发挥作用硬件设计必须配合。外设供电控制传感器、Flash、LED 这些外设在不使用时应该断电。可以用 MOS 管做电源开关由 MCU 的 GPIO 控制。如果外设一直通电休眠电流就降不下来。上拉下拉电阻悬空的引脚会漏电尤其是输入引脚。该上拉的加上拉该下拉的加下拉不用的引脚配置成模拟输入或输出低电平。晶振选择高速晶振功耗高低速晶振功耗低。如果低功耗模式下还需要计时用 32.768kHz 的低速晶振比用高速晶振分频省电得多。唤醒源设计传感器触发唤醒是最常见的低功耗方案。比如麦克风检测到声音超过阈值通过中断引脚唤醒 MCU。这样 MCU 可以长时间休眠只在有事件时才工作。我实测过一块设计良好的 TinyML 板子深度休眠电流可以做到 2uA 以下。而设计粗糙的板子休眠电流可能到几百微安续航差两个数量级。电源管理是 TinyML 产品化的分水岭demo 阶段可以不管产品阶段必须死磕。6. 调试接口与扩展能力开发效率的隐形推手6.1 调试接口为什么不能省调试接口是开发阶段的生命线。没有好的调试接口排查问题就像盲人摸象。SWD是最常用的调试接口两根线就能实现烧录、单步调试、断点、变量查看。相比 JTAGSWD 引脚少、速度快适合小封装 MCU。串口是打印日志的主要通道。推理过程中的中间结果、耗时统计、错误信息都靠串口输出。没有串口你只能靠点灯来判断程序状态效率极低。USB 转串口芯片是开发板的标配。选型时注意驱动兼容性有些芯片在特定操作系统上驱动难装会浪费大量时间。我的建议是开发板一定要留出完整的调试接口最好还能留出测试点。量产板可以省掉调试接口降成本但开发板省这个就是给自己找麻烦。6.2 扩展接口的布局考量扩展接口决定了开发板能接多少外设布局合理与否影响使用体验。GPIO 排针最通用的扩展方式但要注意引脚复用冲突。有些引脚默认是调试接口有些是晶振接口用之前要查清楚。I2C/SPI 接口建议单独引出并且标注清楚引脚定义。I2C 需要上拉电阻有些板子没焊接外设时才发现用不了。电源引脚扩展接口旁边最好有 3.3V 和 GND方便给外设供电。如果外设功耗大还要考虑是否单独供电。接口间距2.54mm 排针最通用1.27mm 适合紧凑设计。如果要做产品接口间距要和外壳设计一起考虑。6.3 从开发板到产品板的硬件裁剪开发板跑通之后下一步往往是做产品板。这时候需要做硬件裁剪去掉开发阶段用不到的部分。可以裁掉的调试接口、USB 转串口芯片、多余的 LED 和按键、扩展排针。不能裁掉的电源管理、传感器接口、必要的测试点。需要增加的外壳安装孔、电池连接器、防水防尘设计、EMC 滤波。裁剪时要重新评估功耗和成本。去掉调试芯片能省几毛钱去掉 LDO 换成 DC-DC 可能省更多。但每次改动都要重新测试确保功能不受影响。提示产品板最好保留几个测试点方便量产测试和售后维修。测试点可以做成焊盘不占空间但关键时刻能救命。7. 常见问题与排查技巧实录7.1 模型跑不起来的内存问题排查问题现象模型加载后运行崩溃或者输出结果全是乱码。排查思路先看编译后的内存占用报告确认 Flash 和 SRAM 是否超限检查模型权重是否正确加载到预期地址用调试器查看崩溃时的调用栈定位到具体函数如果是栈溢出增大栈空间或者减少局部变量常见原因SRAM 不够中间张量溢出覆盖了其他数据模型权重地址对齐问题某些 MCU 要求 4 字节对齐栈空间太小深层函数调用或大数组导致溢出解决技巧在推理引擎里加内存检查点每层计算前后打印剩余内存。这样能快速定位是哪一层吃掉了内存。7.2 推理结果不准的硬件排查问题现象模型在 PC 上跑结果正常部署到开发板后结果偏差大。排查思路对比 PC 和开发板的输入数据是否一致检查量化参数是否正确应用查看是否有未初始化的变量或内存越界确认传感器数据预处理是否和训练时一致常见原因传感器采样率或量程和训练数据不匹配预处理代码有 bug比如归一化系数写错量化过程中某些层精度损失过大硬件浮点运算和 PC 有差异解决技巧把开发板上的中间结果通过串口打印出来和 PC 上的逐层对比。哪一层开始出现偏差问题就在那一层附近。7.3 功耗异常的排查方法问题现象休眠电流远高于预期电池续航不达标。排查思路用电流表测量不同模式下的电流逐个断开外设看电流变化检查 GPIO 配置是否有悬空引脚查看是否有外设时钟未关闭常见原因外设未断电持续耗电GPIO 配置不当输入引脚悬空时钟未关闭某些外设仍在运行电源芯片静态电流大解决技巧用热成像仪看板子哪里发热发热的地方就是耗电的地方。没有热成像仪的话用手指摸也能大致判断。7.4 常见问题速查表问题类型典型现象优先排查项解决方向内存不足运行崩溃、结果乱码内存占用报告压缩模型、优化内存推理不准结果偏差大输入数据一致性对齐预处理、检查量化功耗过高续航短、发热休眠电流外设断电、GPIO 配置采集异常数据丢帧、噪声大接口速率、时钟换接口、加滤波调试连不上无法烧录调试接口配置检查接线、复位8. 硬件选型的实操决策流程8.1 从应用场景反推硬件需求硬件选型不应该从芯片参数出发而应该从应用场景出发。我一般按这个顺序反推第一步明确任务类型。是音频、图像还是时序信号这决定了传感器类型和数据处理链路。第二步确定模型规模。在 PC 上训好模型量化后看模型大小和峰值内存需求。这决定了 MCU 的内存下限。第三步确定延迟要求。实时性要求高就选高主频或带加速器的芯片要求低就可以选低功耗芯片。第四步确定功耗预算。电池供电还是有线供电续航要求多久这决定了电源管理方案。第五步确定成本上限。量产成本能接受多少这决定了最终的芯片和外围器件选型。这个顺序不能乱。先选芯片再想应用很容易选到不合适的方案。8.2 开发板选型的检查清单拿到一块开发板我一般按这个清单过一遍MCU 内核和主频是否满足算力需求SRAM 和 Flash 是否满足模型内存需求传感器类型和参数是否匹配应用场景调试接口是否完整工具链是否成熟功耗指标是否满足续航要求扩展接口是否够用引脚定义是否清晰社区资料和示例代码是否丰富价格是否在预算范围内这份清单里工具链成熟度和社区资料丰富度是最容易被低估的。一块参数漂亮但资料稀少的板子学习成本可能是资料丰富板子的好几倍。8.3 从 demo 到产品的硬件迭代路径最后说一下从 demo 到产品的迭代路径这是很多人关心的问题。阶段一官方开发板跑通 demo。用厂商提供的开发板和示例代码把整个流程走一遍。目标是理解每个环节不追求性能。阶段二换传感器或改模型。在开发板上接自己的传感器或者部署自己训练的模型。目标是验证方案可行性。阶段三画自己的板子。根据前两个阶段的经验设计符合产品需求的硬件。目标是优化功耗、成本、体积。阶段四小批量试产和测试。做几块到几十块样机做完整的功能和可靠性测试。目标是发现设计缺陷。阶段五量产优化。根据试产反馈修改设计做 EMC 认证准备量产。每个阶段都有坑但最大的坑是跳过阶段一和阶段二直接画板子。没有充分验证的方案画出来的板子大概率要改版浪费的时间和金钱远超预期。我个人在实际操作中的体会是TinyML 硬件选型最忌讳的就是“参数党”。盯着主频和内存参数选出来的板子往往在实际使用中因为工具链、功耗、传感器匹配度等问题翻车。真正靠谱的做法是先用成熟开发板把流程跑通对每个环节的瓶颈有切身感受之后再根据实际需求做硬件决策。这个过程中积累的经验比任何参数表都有价值。