2、TinyML基础与性能指标：掌握延迟、吞吐量、能耗、内存占用、精度等关键性能指标，理解其在资源受限设备上的意义
TinyML 的核心挑战在于：在功耗、算力、存储均极度受限的微控制器（MCU）或极低功耗处理器上，部署机器学习模型并使其稳定运行。与云端或移动端 AI 不同，TinyML 的性能评估不能简单套用“跑分”逻辑，而必须围绕资源受限这一根本约束展开。理解延迟、吞吐量、能耗、内存占用与精度这五项关键指标，是进行瓶颈分析、系统拆分与优化设计的前提。本章将逐一剖析这些指标的定义、测量方法、相互制约关系，并结合实际场景说明其在工程决策中的意义。
2.1 核心原理：为什么传统性能指标在 TinyML 中需要重新定义
在服务器或移动端，性能评估通常关注峰值算力（TOPS）、模型参数量或 FLOPs。但在 TinyML 场景中，这些指标往往具有误导性。一颗主频 80MHz 的 Cortex-M4 内核，其峰值算力远低于任何 GPU，但若模型经过量化与剪枝，仍可在几十毫秒内完成一次关键词唤醒或异常检测。因此，TinyML 的性能指标必须围绕“端侧实时处理”与“长期电池供电”两个核心诉求展开。
延迟（Latency）指从输入数据到达（如传感器采样完成）到输出结果产生（如分类标签或异常分数）所经过的时间。它直接决定了系统能否满足实时性要求，例如语音唤醒必须在 100ms 内响应。吞吐量（Throughput）则衡量系统在单位时间内能处理的样本数量，对于连续监测类应用（如振动分析、心电监测）尤为重要。能耗（Energy）是 TinyML 区别于其他 AI 领域的标志性指标，通常以“每次推理消耗的焦耳数”或“平均功耗（mW）”来衡量。内存占用（Memory Footprint）包括模型权重、中间激活值、运行时栈和堆的总和，直接受限于 MCU 的 Flash 与 SRAM 容量。精度（Accuracy）则代表模型输出与真实标签的吻合程度，但在 TinyML 中，精度往往需要与模型大小、推理延迟进行联合优化。
这五项指标并非孤立存在，它们构成了一个相互制约的“性能四面体”。例如，将模型从 FP32 量化为 INT8，内存占用可减少 75%，推理延迟可能降低 2-4 倍，但精度可能下降 0.5%-2%。反之，若追求更高精度而引入更大的模型，则可能导致内存溢出或延迟超标。理解这些权衡关系，是进行系统级优化的基础。
2.2 判断方法与操作流程：如何测量与评估各项指标
在 TinyML 工程中，指标的测量必须结合硬件平台与工具链。以下是各项指标的标准测量方法：
| 指标 | 测量工具/方法 | 关键参数 | 工程意义 |
|---|---|---|---|
| 延迟 | 硬件定时器（DWT->CYCCNT）、GPIO 翻转 + 逻辑分析仪 | 单次推理周期数、端到端延迟（含采集） | 判断是否满足实时性硬约束 |
| 吞吐量 | 连续运行 N 次推理，统计总耗时 | 样本数/秒（SPS） | 评估连续数据流处理能力 |
| 能耗 | 电流探头 + 示波器、或板载采样电阻 | 平均电流、峰值电流、单次推理能量（mJ） | 估算电池寿命（mAh / 平均电流） |
| 内存占用 | 编译工具链报告（.map 文件）、静态分析 | Flash 占用、RAM 静态/动态占用 | 防止链接失败或运行时堆栈溢出 |
| 精度 | 验证集评估（混淆矩阵、F1-Score） | Top-1 Accuracy、AUC | 确保模型输出满足业务需求 |
操作流程建议遵循以下步骤：第一步，在 PC 端使用 TensorFlow Lite Micro 或 CMSIS-NN 模拟器进行初步评估，获取基线数据；第二步，将模型部署到目标开发板（如 STM32F746、ESP32-S3），使用硬件定时器精确测量延迟；第三步，通过功耗分析仪（如 Joulescope、Nordic PPK2）记录不同运行阶段的电流波形，分离出“采集-处理-通信”各环节的能耗占比；第四步，检查编译生成的 .map 文件，确认 Flash 与 RAM 占用是否在预算内；第五步，在真实传感器数据上验证精度，并记录量化带来的精度损失。
2.3 案例拆解：工业振动监测节点的性能指标权衡
我们以一个实际的工业电机振动监测项目为例。设备使用 STM32L4 系列 MCU（80MHz，512KB Flash，160KB SRAM），通过 I2S 接口连接三轴加速度计（ADXL345），每 10ms 采集一组 64 点 FFT 频谱数据，需要判断电机是否处于异常状态。
初始目标与约束：要求单次推理延迟小于 50ms，平均功耗低于 5mW（使用 CR2032 纽扣电池供电，目标工作 6 个月），模型精度（F1-Score）不低于 0.90。初始方案采用一个 4 层卷积神经网络（CNN），FP32 权重，模型大小 480KB，RAM 占用 120KB。
测量与分析过程：通过 DWT 定时器测得单次推理延迟为 68ms，超出预算 36%。使用 Joulescope 测量平均电流为 2.8mA（3.3V 供电），对应功耗 9.24mW，远超 5mW 限制。进一步分析发现，FP32 模型在 Cortex-M4 上无法使用硬件浮点加速（该内核无 FPU），导致计算效率低下。同时，480KB 的模型已接近 Flash 上限，无法再增加功能。
优化操作步骤：第一步，将模型进行 INT8 量化，使用 TensorFlow Lite Micro 的量化工具，模型大小降至 120KB，RAM 占用降至 48KB。第二步，利用 CMSIS-NN 库优化卷积算子，延迟从 68ms 降至 22ms。第三步，调整采样策略：将 FFT 点数从 64 降至 32（频率分辨率降低但足以检测主要故障特征），采集时间减半，传感器功耗降低。第四步，在空闲状态进入 STOP 模式，仅保留 RTC 唤醒，待机电流降至 2μA。
结果对比：优化后，单次推理延迟 22ms（满足 <50ms），平均功耗 3.2mW（满足 <5mW），模型 F1-Score 从 0.93 降至 0.91（仍在可接受范围）。电池寿命估算从原来的 1.2 个月延长至 7.8 个月。代价是频率分辨率降低，对早期微弱故障的检测灵敏度有所下降，但通过增加时域特征（峰值、RMS）作为补充输入，最终整体性能保持稳定。
复盘经验：该案例表明，性能指标之间存在强耦合。单纯优化模型结构而不考虑硬件特性（如 FPU 缺失）效果有限；量化与算子库优化是 TinyML 性能提升的两大杠杆；同时，系统级优化（采样策略、电源管理）往往比模型级优化带来更显著的收益。
2.4 常见误区与总结复盘
在评估 TinyML 性能时，工程师常陷入以下误区：
- 误区一：只关注模型 FLOPs 而忽略内存带宽。在 MCU 上，数据搬运（从 Flash 读权重、从 RAM 读激活值）的耗时往往超过计算本身。一个 FLOPs 很低但权重频繁访问的模型，实际延迟可能很高。
- 误区二：将 PC 端推理延迟等同于嵌入式延迟。PC 端使用 x86 指令集与大量缓存，而 MCU 通常无缓存或仅有极小缓存，且指令集不同，延迟差异可达 10-100 倍。
- 误区三：忽略“采集”与“后处理”的耗时。本章课程的核心在于拆分流程。传感器读取（如 I2C 通信）、数据预处理（如归一化、滤波）和后处理（如阈值判断、通信打包）可能占据端到端延迟的 50% 以上。只优化推理部分，整体性能提升有限。
- 误区四：精度评估脱离实际部署环境。在实验室干净数据上评估的精度，在真实噪声环境下可能大幅下降。TinyML 模型必须在目标硬件上、使用真实传感器数据重新验证精度。
总结复盘：掌握 TinyML 性能指标的核心，在于建立“系统视角”。延迟、吞吐量、能耗、内存与精度不是五个独立的数字，而是一个需要在设计初期就进行联合权衡的约束集。建议团队在项目启动时，先明确五项指标的硬性上限与软性目标，并建立可重复的测量基准。后续章节将深入探讨采集、前处理、推理与后处理各阶段的瓶颈定位方法，而本章所定义的指标框架，将是贯穿全课程的分析语言。