2. Edge AI基础
在讨论模型退化监测之前，必须先厘清Edge AI的运行底座。边缘计算并非云计算的简单缩小版，而是一套在物理分布、算力供给、功耗预算、网络条件上均有本质差异的体系。本章从边缘计算的分层架构出发，剖析端侧推理的独特约束，梳理模型从训练到上线的部署流程，并重点分析资源约束对模型生命周期管理（尤其是退化监测）的直接影响。理解这些基础，是后续设计退化指标、选择监测策略的前提。
2.1 边缘计算的分层架构与职责边界
边缘计算并非单一层次，而是由端侧设备层、边缘节点层、云中心层构成的三级协同体系。每一层承担不同的计算职责，且层级间存在数据流与控制流的双向交互。理解这种分层是设计模型退化监测方案的基础——因为退化监测可能发生在任何一层，且各层的监测粒度与响应时效完全不同。
核心原理：三层架构的职责划分
端侧设备层（如MCU、工业传感器、摄像头模组）负责原始数据采集与低延迟实时推理，典型算力范围在0.1~10 TOPS，内存通常小于512MB。边缘节点层（如边缘网关、工控机、5G MEC服务器）承担聚合推理、数据缓存与规则引擎，算力可达10~100 TOPS。云中心层则负责模型训练、联邦聚合与全局优化，算力不受严格限制。这种分层设计的核心动机是时延与带宽的权衡：端侧推理时延可控制在毫秒级，但模型复杂度受限；云端推理能力强，但网络往返可能引入数百毫秒延迟。
| 层级 | 典型硬件 | 算力范围 | 内存容量 | 主要职责 | 典型时延 |
|---|---|---|---|---|---|
| 端侧设备层 | MCU、NPU SoC | 0.1~10 TOPS | 64KB~512MB | 采集、实时推理、紧急响应 | 1~10ms |
| 边缘节点层 | Jetson、边缘服务器 | 10~100 TOPS | 4~32GB | 聚合推理、数据缓存、规则引擎 | 10~50ms |
| 云中心层 | GPU集群 | 1000+ TOPS | TB级 | 训练、联邦聚合、全局优化 | 100ms~数秒 |
判断方法：如何确定分层部署策略
决定监测逻辑部署在哪一层，需要评估三个关键指标：响应时效要求（若退化必须在100ms内触发保护动作，则必须端侧处理）、数据敏感性（涉及隐私的数据不应回传云端）、模型复杂度（若退化检测模型超过端侧内存容量，则需考虑边缘层或云端）。一个实用的判断流程是：先列出所有需要监测的退化类型，为每种类型标注允许的最大检测延迟，再根据延迟预算选择部署层级。
案例拆解：工业电机预测性维护的分层监测
某工厂在电机上部署振动传感器，目标是监测轴承退化。初始设计将所有振动数据回传云端分析，但发现两个问题：一是网络带宽不足以支撑多台设备的高频数据回传；二是云端检测到异常时，电机可能已损坏。重新设计后采用分层方案：端侧MCU运行轻量级异常检测模型（基于频域特征的阈值判断），实时检测突发性振动尖峰；边缘网关运行CNN模型分析振动频谱的渐进变化趋势；云端每周汇总所有设备数据，训练全局退化模型并更新端侧阈值。该方案将退化检测时延从秒级降至毫秒级，同时减少了90%的数据回传量。
2.2 端侧推理的特点与约束
端侧推理与云端推理存在本质差异。云端推理假设资源充足、网络稳定、功耗不受限，而端侧推理必须在功耗预算、内存容量、算力上限、散热条件的四重约束下运行。这些约束直接影响模型架构选择、量化策略和推理框架的选型。
核心原理：端侧推理的四大物理约束
算力约束体现在端侧芯片的TOPS/W指标上——例如，一颗1 TOPS的NPU运行MobileNetV2大约需要30ms，而运行ResNet-50则需要200ms以上。内存约束更为关键，端侧SRAM通常只有几百KB，DRAM不超过512MB，模型权重和中间特征图必须精打细算。功耗约束决定了连续推理时长，例如电池供电的传感器节点，平均功耗需控制在100mW以内。散热约束则限制了峰值算力的持续时间，无风扇设备在持续高负载下可能触发降频保护。
判断方法：评估模型是否适合端侧部署
在部署前，应通过以下清单快速评估：
- 参数量：模型权重是否小于可用内存的50%？（留出运行时内存余量）
- 计算量：单次推理的MACs（乘加运算次数）是否在芯片可承受范围内？
- 峰值内存：中间特征图的最大尺寸是否超过SRAM容量？
- 功耗预算：连续推理时的平均功耗是否在热设计功耗（TDP）以内？
- 延迟要求：端到端推理延迟是否满足业务SLA？
实战场景：智能摄像头的人形检测模型部署
某智能门铃需要实时检测门前人形。初始方案采用YOLOv5s（参数量7.2M，计算量16.5 GMACs），在树莓派4B上推理延迟为450ms，功耗达到5.8W，远超电池供电的功耗预算。经过分析后，改用MobileNetV3-SSD（参数量3.4M，计算量1.2 GMACs），并采用INT8量化，推理延迟降至120ms，功耗降至1.2W。同时将输入分辨率从640×640降至320×320，检测精度mAP从0.72降至0.68，但满足业务需求。这个案例说明，端侧部署的核心是精度-延迟-功耗的三方权衡，而非单纯追求精度。
2.3 模型部署流程与资源约束的工程实践
模型从训练完成到端侧稳定运行，需要经过压缩、转换、适配、验证、监测五个阶段。每个阶段都受到资源约束的制约，且这些约束会反向影响模型设计。理解部署流程中的资源瓶颈，是确保模型长期稳定运行的关键。
核心原理：部署流程中的资源瓶颈分析
模型压缩阶段的瓶颈在于精度损失控制——量化到INT8通常导致1%~3%的精度下降，但可减少4倍内存占用和2~3倍计算量。格式转换阶段的瓶颈在于算子兼容性——某些自定义算子可能无法映射到目标硬件。硬件适配阶段的瓶颈在于内存规划——需要为输入、输出、中间特征图分配连续内存，且要避免内存碎片。集成验证阶段的瓶颈在于测试覆盖度——需要在真实硬件上测试不同温度、电压下的稳定性。持续监测阶段的瓶颈在于监测开销——监测逻辑本身也会消耗算力和内存。
操作流程：标准部署五步法
| 阶段 | 关键操作 | 资源约束检查点 | 输出物 |
|---|---|---|---|
| ① 模型压缩 | 量化、剪枝、蒸馏 | 精度损失≤3%，模型大小≤内存50% | 压缩后模型 |
| ② 格式转换 | 转换为ONNX/TFLite | 算子覆盖率≥95% | 中间表示 |
| ③ 硬件适配 | 算子映射、内存规划 | 峰值内存≤可用内存80% | 硬件部署包 |
| ④ 集成验证 | 精度、延迟、功耗测试 | 延迟≤SLA，功耗≤TDP | 验证报告 |
| ⑤ 持续监测 | 退化指标、OTA更新 | 监测开销≤5%算力 | 监测系统 |
案例拆解：智能电表故障检测模型的部署优化
某电力公司部署智能电表，需要在电表MCU上运行窃电检测模型。初始模型为XGBoost（参数量5MB），但MCU仅有256KB Flash和64KB RAM，无法直接部署。工程团队采用以下步骤：首先将XGBoost转换为神经网络结构（2层MLP，参数量降至800KB）；然后进行INT8量化，模型大小降至200KB；接着将模型拆分为两个子模型——端侧运行轻量级异常筛查模型（50KB），边缘网关运行精确检测模型（150KB）。部署后，端侧模型推理延迟为8ms，功耗增加仅15mW，检测召回率从82%提升至89%（因为端侧筛查减少了误报，边缘模型可以更专注）。该案例展示了模型拆分与分层部署如何突破单点资源约束。