2. 基础知识
TinyML视觉项目验收并非简单的“跑通演示”，而是对模型、运行时环境和硬件约束的综合评估。在进入精度、延迟和鲁棒性等具体指标之前，必须先建立一套统一的概念框架——理解模型量化如何压缩体积、推理引擎如何调度计算、板端部署流程如何衔接开发与生产，以及三个核心验收维度（精度、延迟、鲁棒性）各自的定义与测量边界。本章将围绕这四个基础模块展开，为后续章节的验收操作打下坚实的认知基础。
2.1 模型量化：从浮点到整数的压缩与代价
核心原理：模型量化是将神经网络中的权重和激活值从32位浮点数（FP32）映射到更低比特位（如INT8、INT16）的过程。在TinyML视觉场景中，量化不仅是体积压缩手段，更是让模型能够在MCU（微控制器）上运行的必要条件——大多数MCU没有FPU（浮点运算单元）或FPU性能极弱，整数运算可以快数倍到数十倍。量化的本质是建立浮点值域到整数码值的映射关系，通常采用线性量化：q = round(r / scale) + zero_point，其中scale是缩放因子，zero_point是零点偏移。
量化类型与选择：
| 量化方式 | 精度损失 | 硬件要求 | 适用场景 |
|---|---|---|---|
| 训练后动态量化 | 低（仅权重量化） | 支持INT8激活计算 | 快速原型验证 |
| 训练后全整数量化 | 中（权重+激活） | 需要校准数据集 | 大多数MCU部署 |
| 量化感知训练（QAT） | 低（微调恢复） | 需要重新训练 | 精度敏感型项目 |
操作流程：在验收项目中，量化环节通常已完成，但验收人员需要验证量化配置是否合理。具体步骤包括：①检查量化校准数据集是否覆盖了实际场景的光照分布；②对比量化前后模型的权重分布直方图，确认没有严重截断；③在开发板上运行量化模型，观察是否有异常输出（如全零输出或NaN）。
2.2 推理引擎：运行时环境与算子调度
核心原理：推理引擎是模型在板端执行的“操作系统”。它负责将量化后的模型文件解析为可执行的算子序列，管理内存分配，并调度硬件资源（CPU、NPU、DSP）。常见的TinyML推理引擎包括TensorFlow Lite for Microcontrollers（TFLM）、ONNX Runtime Micro、CMSIS-NN（ARM Cortex-M优化库）等。推理引擎的选择直接影响延迟和内存占用——同一模型在不同引擎上的推理时间可能相差2-5倍。
引擎关键特性对比：
| 特性 | TFLM | ONNX Runtime Micro | CMSIS-NN |
|---|---|---|---|
| 算子覆盖 | 丰富（视觉算子全） | 中等 | 仅卷积/全连接等基础算子 |
| 内存优化 | arena机制，静态分配 | arena机制 | 依赖CMSIS-DSP |
| 硬件加速 | Delegate（如Ethos-U） | 支持NPU | ARM Cortex-M优化 |
| 调试工具 | Profiler + 日志 | 较少 | 无内置调试 |
验收关注点：在验收时，需要确认推理引擎的版本、算子支持列表以及是否启用了硬件加速。一个常见问题是：模型在PC端仿真正常，但板端某些算子（如ResizeBilinear）未实现，导致推理失败或回退到CPU慢速路径。验收时应检查引擎日志中的算子映射信息，确保所有算子都运行在预期硬件上。
2.3 板端部署流程：从模型文件到可运行固件
核心原理：板端部署不是简单的文件拷贝，而是一个涉及交叉编译、链接、内存布局和硬件初始化的系统工程。典型流程为：模型转换（.tflite/.onnx）→ 量化 → C++源码生成或静态库编译 → 与主程序链接 → 固件烧录。在MCU上，模型通常以C数组形式嵌入固件，运行时加载到RAM或Flash映射区。
部署流程清单：
- 模型转换：使用官方转换器将训练好的模型转为目标格式，同时设置量化参数。
- 算子兼容性检查：确认所有算子都被目标推理引擎支持，必要时替换或重写自定义算子。
- 内存规划：估算模型权重、激活缓冲区、中间张量所需RAM，检查是否超出MCU可用内存。
- 交叉编译：使用板卡SDK的交叉编译器生成目标固件，注意优化级别（-O2/-O3）对延迟的影响。
- 烧录与启动：通过JTAG/SWD或UART烧录，验证上电后模型加载是否成功。
- 运行时验证：使用测试图像输入，比对输出与PC端结果，确认数值一致性。
案例拆解：某工业视觉项目部署在STM32H743（Cortex-M7，480MHz）上，模型为MobileNetV2-0.25（INT8量化）。初始部署时，推理延迟为320ms/帧，远超150ms的验收标准。通过分析发现：①模型转换时未启用fully_quantize参数，导致部分算子仍以浮点运行；②CMSIS-NN优化库未正确链接，卷积算子回退到TFLM默认实现。修复后延迟降至95ms/帧，满足要求。此案例说明部署流程中每个环节的配置错误都会显著影响最终性能。
2.4 精度、延迟与鲁棒性的定义与测量边界
核心原理：三个验收维度构成了TinyML视觉项目的“铁三角”，但它们的定义在板端场景下与云端有显著差异。
- 精度（Accuracy）：在板端，精度不仅指模型在标准测试集上的mAP或Top-1准确率，更关注量化后精度损失和实际部署环境下的精度。验收时应使用与训练集分布一致但独立采集的测试集，且测试集应包含板端摄像头实际拍摄的图像。
- 延迟（Latency）：延迟分为单帧推理延迟（从输入张量就绪到输出张量完成）和端到端延迟（从图像采集到结果输出，包括预处理、推理、后处理和通信）。验收时需明确测量的是哪种延迟，并统一测量方法（如使用GPIO翻转或时间戳）。
- 鲁棒性（Robustness）：指模型在光照变化、遮挡、运动模糊、噪声干扰等非理想条件下的性能保持能力。鲁棒性测试需要设计压力测试集，覆盖极端光照（如逆光、夜间）、部分遮挡、不同角度等场景。
测量方法对比：
| 维度 | 测量工具 | 关键指标 | 常见陷阱 |
|---|---|---|---|
| 精度 | 测试集 + 标注工具 | mAP@0.5, F1-score | 测试集与训练集重叠 |
| 延迟 | 示波器/逻辑分析仪/计时器 | P50/P95延迟, FPS | 未排除日志打印时间 |
| 鲁棒性 | 光照箱/遮挡物/图像增强 | 精度下降率, 失败模式分布 | 测试场景过于理想化 |
案例拆解：一个智能门锁项目在验收时，实验室环境下精度达到98.2%，但安装到实际楼道后，夜间红外补光场景下精度骤降至71%。分析发现：①训练数据中夜间样本仅占5%，且均为室内灯光环境；②量化校准数据未包含红外图像，导致INT8量化在红外通道上产生较大误差。解决方案是重新采集包含红外场景的数据集，并加入量化校准集，同时将夜间图像做数据增强。最终夜间精度恢复至89%。此案例说明，鲁棒性测试必须基于真实部署环境，而非仅依赖实验室标准。