2、TinyML基础回顾：端侧推理的特点、常见硬件平台（MCU、DSP、NPU）与软件框架（TensorFlow Lite Micro、CMSIS-NN等）

在进入精度、延迟、内存与功耗四类指标的测试之前，必须先厘清TinyML端侧推理的基本面貌。TinyML并非简单地将深度学习模型压缩后塞进小设备，而是围绕资源极度受限的硬件环境，重新设计推理链路、算子实现与调度策略。理解端侧推理的特点、硬件平台的能力边界以及软件框架的抽象层次，是后续制定测试方案、解读测试数据的前提。本章从这三个维度展开，帮助读者建立TinyML测试的坐标系。

上图展示了TinyML端侧推理的完整技术栈。自下而上分别是硬件平台层、硬件抽象与调度层、软件框架层，以及顶层的应用场景。测试人员需要理解每一层的约束与接口，才能准确判断性能瓶颈出现在算子实现、内存带宽、调度开销还是硬件算力上。

2.1 端侧推理的核心特点

端侧推理与云端推理的本质差异不在于模型大小，而在于资源边界与实时性要求。云端推理假设算力、内存、功耗近乎无限，而端侧推理必须在几十毫瓦到几百毫瓦的功耗预算内，在几百KB到几MB的RAM中完成推理任务。这种约束催生了四个关键特点。

• 内存受限：典型MCU的SRAM只有16KB~1MB，Flash为128KB~4MB。模型权重、中间激活值、输入输出缓冲区必须精打细算，甚至需要复用内存池。
• 算力受限：Cortex-M4级别的MCU主频通常在80~200MHz，单次乘加运算需要多个时钟周期，无法直接运行浮点卷积，必须依赖量化与定点优化。
• 实时性要求：端侧推理往往嵌入控制闭环，例如电机堵转检测、语音唤醒、振动分析，推理延迟必须小于控制周期，通常要求10ms~100ms内完成。
• 功耗敏感：电池供电设备的总功耗预算可能只有10mW~100mW，推理功耗、待机功耗、通信功耗需要统一调度。

这些特点决定了端侧测试不能简单照搬云端指标。例如，云端测试关注吞吐量（QPS），而端侧测试更关注单次推理延迟的尾延迟（P99）以及峰值内存占用。再如，云端可以随意增加batch size提升利用率，而端侧通常batch=1，且必须考虑冷启动与唤醒延迟。

2.2 常见硬件平台：MCU、DSP与NPU

TinyML硬件平台并非单一架构，而是根据算力、功耗、成本形成梯度。理解不同平台的指令集特性与并行能力，是分析测试数据的基础。

平台类型	典型代表	算力范围	内存容量	功耗范围	适用算子	测试关注点
MCU	Cortex-M4/M7/M33, RISC-V	10~200 MOPS	16KB~1MB SRAM	1~100 mW	8bit定点卷积、全连接、池化	延迟抖动、栈深度、Flash占用
DSP	Cadence HiFi4/HiFi5, CEVA-XM	0.5~5 GOPS	512KB~4MB	50~500 mW	SIMD加速的卷积、FFT、MFCC	SIMD利用率、数据对齐、DMA带宽
NPU	ARM Ethos-U55/U65, 厂商微NPU	1~50 TOPS	外部共享SRAM	100mW~2W	量化卷积、深度可分离卷积	算子映射率、DMA搬运瓶颈、量化精度损失

MCU平台的优势在于生态成熟、开发简单、成本极低，适合唤醒词检测、异常振动检测等轻量任务。DSP平台提供SIMD指令集，对音频信号处理、FFT、MFCC特征提取有天然优势，但编程复杂度较高，需要手工优化数据对齐。NPU平台算力最强，但依赖编译器将模型映射到硬件加速器，实际性能高度取决于算子是否被完整支持。

在实际项目中，越来越多的设备采用异构方案：MCU负责控制与轻量任务，DSP负责信号预处理，NPU负责重计算模型。这种架构下，测试需要关注跨核通信延迟、共享内存的竞争仲裁、以及不同核之间的功耗叠加。

2.3 软件框架：TensorFlow Lite Micro与CMSIS-NN

软件框架决定了开发者如何描述模型、如何调用底层算子、如何管理内存。TinyML领域目前最主流的两个框架是TensorFlow Lite Micro（TFLM）和CMSIS-NN，此外还有Glow、TVM等编译器方案。

2.3.1 TensorFlow Lite Micro

TFLM是TensorFlow Lite针对MCU的裁剪版本，核心设计目标是极小的二进制体积与确定性的内存分配。它采用解释器模式，运行时逐层调用预注册的算子内核。TFLM的内存管理基于Arena分配器，在初始化时一次性分配所有中间张量所需的内存，推理过程中不再动态申请。

// TFLM典型初始化流程（伪代码）
static tflite::MicroMutableOpResolver<10> resolver;
resolver.AddConv2D();
resolver.AddFullyConnected();
resolver.AddSoftmax();

static uint8_t tensor_arena[100 * 1024]; // 100KB内存池
tflite::MicroInterpreter interpreter(
    model, resolver, tensor_arena, sizeof(tensor_arena));
TfLiteStatus init_status = interpreter.AllocateTensors();

TFLM的测试重点包括：算子覆盖范围（是否所有模型算子都有对应内核）、Arena大小设置（过小导致分配失败，过大浪费SRAM）、解释器调度开销（每层调用的函数指针跳转耗时）。

2.3.2 CMSIS-NN

CMSIS-NN是ARM提供的Cortex-M系列优化算子库，它不是独立框架，而是作为TFLM或其他推理引擎的底层内核加速库。CMSIS-NN针对Cortex-M4/M7/M33的SIMD指令（如SMLAD、SMLALD）和DSP扩展进行了深度优化，将8bit定点卷积的乘加效率提升4~6倍。

对比维度	TensorFlow Lite Micro	CMSIS-NN
定位	完整推理框架（解释器+算子）	算子内核加速库
依赖关系	可调用CMSIS-NN作为内核	不包含模型解析与调度
内存管理	Arena静态分配	由调用方管理
量化支持	int8/uint8/int16	int8/uint8（针对Cortex-M优化）
典型场景	快速部署、多模型切换	极致性能优化、定制算子

在实际工程中，TFLM与CMSIS-NN经常组合使用：TFLM负责模型解析与张量管理，CMSIS-NN提供卷积、全连接等算子的优化实现。测试时需要注意，CMSIS-NN的算子对输入数据的对齐方式（4字节对齐）和通道数（通常要求4的倍数）有隐含要求，不满足时会回退到C实现，性能骤降。

2.4 端侧推理的典型链路与测试切入点

一个完整的端侧推理链路包括：传感器数据采集 → 预处理（滤波、归一化、特征提取） → 模型推理 → 后处理（阈值判断、平滑） → 控制输出。测试人员需要明确每个环节的耗时与内存占用，才能定位瓶颈。

1. 数据采集阶段：ADC采样率、DMA搬运时间、环形缓冲区大小。测试点：采样是否丢帧、DMA与CPU竞争是否导致延迟尖峰。
2. 预处理阶段：MFCC、FFT、归一化等操作通常运行在CPU或DSP上。测试点：特征计算耗时、中间特征图的内存占用。
3. 模型推理阶段：核心卷积/全连接计算。测试点：单层延迟、层间切换开销、量化误差累积。
4. 后处理与输出：softmax、阈值比较、控制信号生成。测试点：输出抖动、控制周期是否满足。

以一个振动故障诊断设备为例：设备使用Cortex-M7 MCU，内置3轴加速度计，采样率25.6kHz，每次采集1024点进行FFT和1D卷积推理。初始测试发现，推理延迟为45ms，但控制周期要求50ms，余量仅5ms。进一步分析发现，FFT预处理耗时18ms，卷积推理耗时22ms，后处理5ms。通过将FFT从浮点改为定点（Q15格式），并利用CMSIS-DSP库的arm_rfft_q15函数，FFT耗时降至6ms；同时将卷积的输入通道从3改为4（补零对齐），触发CMSIS-NN的SIMD优化路径，卷积耗时降至14ms。最终总延迟降至25ms，余量翻倍。

2.5 常见误区与总结

在TinyML基础回顾的最后，梳理几个初学者容易犯的错误，这些误区会直接影响后续测试方案的设计。

• 误区一：认为模型越小推理越快。模型参数量减少确实降低计算量，但某些算子（如深度可分离卷积）在MCU上因内存访问不连续，实际速度反而不如普通卷积。测试应以实际硬件跑分为准。
• 误区二：忽略量化带来的精度损失。int8量化在大多数任务上精度损失小于1%，但对于回归类任务或异常检测中的小信号，可能损失5%以上。测试必须同时记录量化前后的精度对比。
• 误区三：只测平均延迟，不测最坏情况。MCU的中断处理、DMA竞争、Flash等待周期会导致延迟抖动。对于实时控制系统，必须测试P95或P99延迟。
• 误区四：认为框架自带benchmark工具足够。TFLM的benchmark工具只测量模型推理时间，不包含数据采集与预处理。实际项目需要自行编写分段计时代码。

总结而言，TinyML端侧推理是一个软硬件协同的系统工程。测试人员需要同时理解硬件指令集特性、软件框架的内存管理机制、以及应用场景的实时性约束。只有将这三者统一到测试指标体系中，才能准确评估端侧推理的性能边界，并为后续的精度、延迟、内存、功耗四类指标测试打下坚实基础。