2、基础知识：TinyML系统架构、配置管理在端侧AI中的角色与价值

TinyML（微型机器学习）是指在极低功耗、极小内存和有限算力的嵌入式设备上运行机器学习推理的技术体系。与云端AI不同，TinyML设备通常以电池供电，长期部署在物理环境中，承担数据采集、信号处理、特征提取和模型推理等任务。理解TinyML系统架构是配置管理的前提——只有清楚每个模块的职责、数据流向和资源约束，才能设计出合理的配置体系。本章从系统架构出发，剖析配置管理在端侧AI中的核心角色与工程价值。

2.1 TinyML系统架构的核心组成

TinyML系统架构可以划分为四个主要层次：感知层、处理层、存储层和通信层。每一层都有明确的硬件载体和软件职责，而配置管理则像一条贯穿始终的“数据总线”，将各层的运行参数统一纳管。

2.1.1 感知层：数据入口的物理约束

感知层由各类传感器组成，包括加速度计、陀螺仪、麦克风、温湿度传感器、光学传感器等。该层的核心参数包括：

• 采样率：决定时间分辨率，例如加速度计常见的 25Hz、50Hz、100Hz，高采样率带来更丰富的信息但增加功耗和计算量。
• 量程与增益：例如加速度计 ±2g、±4g、±8g、±16g 的选择，量程过大会降低分辨率，过小则导致饱和削波。
• 滤波配置：低通/高通/带通滤波器的截止频率，直接影响信号质量。
• 触发模式：连续采样、边沿触发、窗口比较等，影响系统唤醒策略。

感知层的配置错误往往是最隐蔽的——硬件本身不会报错，但采集到的数据质量会直接影响后续所有处理环节。例如，在振动监测场景中，若采样率低于信号最高频率的2倍（奈奎斯特采样定理），就会产生混叠效应，导致频谱分析结果完全失真。

2.1.2 处理层：算力与算法的匹配

处理层以MCU（如ARM Cortex-M系列）、DSP或轻量级NPU为核心，运行特征提取算法和TinyML推理引擎（如TensorFlow Lite Micro、CMSIS-NN）。处理层的配置参数包括：

• 特征提取参数：FFT点数、窗口长度、重叠率、MFCC滤波器组数量等。
• 推理频率：每秒钟执行多少次推理，例如关键词唤醒场景通常每100ms推理一次。
• 模型选择：同一设备可能部署多个模型（如活动识别模型和异常检测模型），需要配置当前激活的模型ID。
• CPU频率与电源模式：在性能与功耗之间权衡，例如运行在48MHz还是64MHz。

处理层的配置直接影响推理延迟和功耗。以电池供电的智能门锁为例，人脸识别模型若推理一次需要200ms，则系统需要保持高频运行200ms后迅速进入休眠，这期间的电源管理配置至关重要。

2.1.3 存储层：参数与权重的持久化

存储层负责保存模型权重、配置参数、日志和中间结果。常见存储介质包括内部Flash、外部SPI Flash、FRAM和SD卡。存储层的配置管理涉及：

• 分区规划：将Flash划分为引导区、应用区、配置区、日志区，防止配置写入时破坏固件。
• 配置存储格式：使用键值对（Key-Value）、JSON或二进制结构体，需权衡解析开销和灵活性。
• 磨损均衡：频繁写入配置参数会消耗Flash寿命，需要配置写入次数阈值和磨损均衡策略。

2.1.4 通信层：外部交互的通道

通信层通过BLE、Wi-Fi、UART、LoRa等接口实现设备与外部世界的交互。通信层的配置参数包括：

• 通信间隔：BLE广播间隔、连接间隔，影响功耗和响应速度。
• OTA升级策略：增量升级还是全量升级，升级包校验方式。
• 遥测上报周期：设备状态、推理结果、健康指标的上报频率。

2.2 配置管理在端侧AI中的角色

配置管理在TinyML系统中扮演着“神经中枢”的角色，具体体现在以下四个维度：

角色维度	具体职责	典型示例	失败后果
参数统一纳管	将分散在各模块的常量集中管理，避免硬编码	将采样率、阈值、模型路径统一存入配置结构体	参数散落各处，修改时遗漏导致行为不一致
动态调整能力	支持运行时修改参数，无需重新编译烧录固件	通过BLE下发新的检测阈值，设备立即生效	每次调参都需要OTA升级，效率低且风险高
版本与一致性	记录配置版本，确保配置与固件、模型版本匹配	配置文件中包含schema版本号，不匹配时拒绝加载	新旧配置混用导致推理结果异常
故障恢复	提供回滚机制，配置错误时可恢复至上次稳定版本	设备启动时校验配置CRC，失败则加载备份配置	错误配置导致设备变砖，需人工干预

2.3 配置管理的工程价值

配置管理的价值在TinyML场景中尤为突出，原因在于端侧设备的特殊性：

2.3.1 降低部署与运维成本

在传统嵌入式开发中，修改一个阈值意味着重新编译、烧录、测试整个固件。而通过配置管理，现场运维人员可以通过通信接口远程调整参数，无需物理接触设备。以一个部署在偏远地区的农业环境监测节点为例，若需要根据季节变化调整土壤湿度报警阈值，通过远程配置下发即可完成，避免了每次派员前往现场的成本。

2.3.2 支持模型迭代与A/B测试

TinyML设备的模型更新通常通过OTA完成，但配置管理允许更细粒度的实验。例如，在智能音箱的唤醒词检测场景中，可以配置不同设备使用不同版本的声学模型，并采集各版本的唤醒率和误唤醒率数据，从而在真实环境中进行A/B测试。这种能力依赖于配置管理中的“模型选择”参数。

2.3.3 提升系统鲁棒性与自适应性

端侧AI设备往往部署在复杂多变的物理环境中。配置管理使设备能够根据环境变化自适应调整参数。例如，工业设备振动监测系统可以根据设备运行状态（启动、稳定运行、停机）自动切换不同的阈值配置。这种自适应能力是静态固件无法实现的。

2.4 小型场景化说明：智能照明系统的配置管理

为了更直观地理解配置管理的角色，我们以一个智能照明系统为例进行说明。该系统使用环境光传感器和人体红外传感器，通过TinyML模型判断是否需要调整灯光亮度。

初始配置（硬编码方式）：

// 硬编码参数示例
#define LIGHT_THRESHOLD_DAY   300   // 白天光照阈值
#define LIGHT_THRESHOLD_NIGHT 50    // 夜间光照阈值
#define SAMPLE_RATE_HZ        10    // 采样率
#define INFERENCE_INTERVAL_MS 500   // 推理间隔
#define HYSTERESIS            20    // 迟滞区间

这种方式的弊端显而易见：如果现场环境光照条件与预期不符（例如办公室朝北，自然光较弱），就需要修改代码并重新烧录固件。而且，不同楼层的办公室可能需要不同的阈值，硬编码方式无法灵活适配。

引入配置管理后：

// 配置结构体定义
typedef struct {
    uint16_t light_threshold_day;
    uint16_t light_threshold_night;
    uint8_t  sample_rate_hz;
    uint16_t inference_interval_ms;
    uint8_t  hysteresis;
    uint8_t  config_version;
    uint32_t crc32;
} app_config_t;

// 默认配置
const app_config_t default_config = {
    .light_threshold_day = 300,
    .light_threshold_night = 50,
    .sample_rate_hz = 10,
    .inference_interval_ms = 500,
    .hysteresis = 20,
    .config_version = 1,
    .crc32 = 0
};

通过配置管理，运维人员可以通过BLE下发新的阈值参数，设备在收到配置后校验CRC并写入Flash，下次启动时自动加载新配置。如果新配置导致灯光频繁闪烁（例如阈值设置不合理），可以通过回滚命令恢复至上一版本。

效果对比：

维度	硬编码方式	配置管理方式
调参耗时	修改代码+编译+烧录+重启，约30分钟	远程下发配置，约10秒
多设备差异化	需要为每栋楼编译不同固件	同一固件，不同配置
错误恢复	需现场重新烧录	远程回滚至备份配置
可追溯性	无版本记录	配置版本号+CRC校验

2.5 常见误区与总结复盘

在TinyML配置管理的实践中，以下误区值得警惕：

2.6 本章小结

TinyML系统架构由感知层、处理层、存储层和通信层构成，配置管理贯穿其中，承担参数统一纳管、动态调整、版本一致性和故障恢复四大角色。其工程价值体现在降低运维成本、支持模型迭代和增强系统自适应性。理解这些基础概念，是后续学习配置存储设计、动态更新机制和参数校验策略的前提。在实际项目中，应根据设备资源约束（Flash容量、RAM大小、CPU算力）选择适合的配置管理方案，避免过度设计或功能缺失。