📚 课程目录第2章 Edge AI基础

Edge AI基础：边缘计算与AI推理的架构、典型部署场景

在讨论模型监控与漂移检测之前，必须先厘清Edge AI的物理与逻辑载体。边缘计算并非简单地将模型从云端“复制”到设备端，而是围绕延迟、带宽、隐私、可靠性四个核心约束重新设计推理链路。本章将拆解边缘AI的参考架构、硬件分层、部署拓扑，并结合摄像头、传感器、移动设备三类典型场景，说明推理监控的切入点为何因架构而异。

2.1 边缘AI推理的参考架构与硬件分层

边缘AI推理并非单一设备完成全部工作，而是由端侧设备层、边缘网关层、云协同层构成的三级流水线。每一层承担不同的计算职责，也对应不同的监控粒度。

端侧设备层：直接与物理世界交互，执行轻量级推理（如物体检测、关键词唤醒）。典型硬件包括树莓派、Jetson Nano、手机NPU、MCU+加速器。该层监控重点为单次推理延迟、置信度原始值、功耗。
边缘网关层：汇聚多路端侧数据，执行更复杂的推理（如多目标跟踪、行为识别），并承担模型热更新与规则判断。监控重点为多路并发下的吞吐量、模型版本一致性、置信度分布变化。
云协同层：负责模型训练、全局调优与跨站点对比。监控重点为数据分布漂移、模型退化速率、回滚决策。

理解该分层是监控设计的前提：不同层的监控指标、采样频率、告警阈值完全不同。例如，端侧设备可能每5秒上报一次置信度摘要，而网关层需要实时计算滑动窗口内的置信度均值与方差。

  关键认知：边缘AI的“边缘”不是固定位置，而是一个连续谱。从手机（端侧）到小区机房（近边缘）再到区域数据中心（远边缘），每一跳都增加延迟但提升算力。监控系统必须适配这种弹性，不能假设所有节点具有相同的计算与存储能力。

2.2 典型部署场景与监控切入点

不同场景对推理监控的约束差异极大，以下通过三个典型场景说明架构选择如何影响监控策略。

场景一：智能摄像头（视频结构化）

摄像头通常内置AI芯片（如海思Hi3559、地平线旭日），在本地完成人脸抓拍、车辆检测。该场景的监控难点在于视频帧率与推理帧率的失配——摄像头采集30fps，但推理只能达到10fps，导致丢帧。监控系统需要同时跟踪：

推理帧率：实际处理帧数/秒，低于阈值时触发降级（如跳帧检测）。
置信度分布：连续1小时内所有检测框的置信度直方图。若分布整体右移（置信度升高），可能意味着模型过拟合到当前场景；若左移，则提示场景漂移（如光照变化、新目标类型）。
误报率代理指标：在无法实时标注的情况下，用“低置信度检测框占比”作为误报的近似指标。当占比超过15%时，触发告警。

场景二：工业传感器（振动/温度异常检测）

传感器节点通常使用MCU级芯片（如STM32+NPU扩展），模型为轻量级自编码器或孤立森林。该场景的监控核心是特征分布漂移，而非单点推理结果。由于传感器数据具有强时序性，监控系统需计算：

重构误差的EWMA（指数加权移动平均）：平滑短期波动，捕捉长期趋势。
频域特征偏移：对振动信号做FFT，比较主频分量是否从50Hz漂移到60Hz（可能暗示机械磨损）。
数据缺失率：传感器断连、通信丢包导致的输入不完整，会直接扭曲推理结果。

场景三：移动设备（手机/平板上的本地推理）

手机端推理面临最复杂的异构环境：不同SoC（高通、联发科、苹果）、不同热状态、不同后台负载。监控系统必须区分“模型漂移”与“设备状态变化”。例如，同一模型在骁龙8 Gen 1上推理延迟为30ms，但在骁龙695上为80ms，这并非模型退化。因此移动端监控需引入归一化指标：

// 归一化推理延迟 = 实际延迟 / 该设备基准延迟
// 基准延迟在模型首次部署时自动校准
normalized_latency = raw_latency / baseline_latency
if normalized_latency > 1.5:
    trigger_warning("设备性能下降或后台负载过高")

场景	典型硬件	核心监控指标	漂移信号特征
智能摄像头	海思Hi3559、Jetson Nano	推理帧率、置信度直方图、低置信度占比	置信度分布左移、检测框数量骤增
工业传感器	STM32+NPU、ESP32-S3	重构误差EWMA、频域主峰位置、数据缺失率	重构误差持续上升、主频偏移超过5%
移动设备	手机SoC（骁龙/天玑/A系列）	归一化延迟、功耗/帧、置信度方差	归一化延迟>1.5、置信度方差增大

2.3 边缘推理的部署模式：端-边-云协同策略

实际工程中，推理任务不会固定在某层，而是根据时延要求、数据量、模型复杂度动态路由。常见的三种协同模式：

端侧为主，云侧兜底：端侧执行90%的简单推理，仅将低置信度样本（如置信度<0.6）上传云端复判。该模式监控重点为上传率——若上传率超过30%，说明端侧模型已无法适应当前场景。
边侧聚合，端侧轻量：端侧只做特征提取（如MobileNet的embedding层），边缘网关完成分类。监控重点为特征向量分布，可用PCA投影可视化漂移。
云侧训练，边侧增量：云端定期训练新模型，边缘网关做增量学习（如只更新全连接层）。监控重点为新旧模型输出一致性——切换后前1000次推理的置信度差异不应超过5%。

常见误区：许多团队将“模型漂移监控”等同于“监控准确率”。但在边缘场景，真实标签往往不可得（摄像头画面无法实时人工标注）。因此必须使用代理指标：置信度分布、特征空间距离、预测类别熵、重建误差等。这些指标虽不完美，但能在无标签情况下提供早期预警。

2.4 案例拆解：某园区智能摄像头系统的置信度漂移发现

背景与约束：某园区部署了50路摄像头，用于车辆违停检测。模型为YOLOv5s，部署在Jetson Nano上，初始mAP@0.5为0.82。监控系统每10分钟上报一次置信度直方图（分20个桶）。

初始现象：部署第3天，监控面板显示“低置信度桶（0.3-0.4）”占比从5%升至18%，同时“高置信度桶（0.8-0.9）”从40%降至28%。但业务方反馈“看起来一切正常”，因为误报率尚未显著上升。

分析过程：

检查原始日志，发现低置信度检测框集中在傍晚时段（17:00-19:00），且多位于画面边缘。
对比天气数据，发现该时段有逆光现象，导致车辆轮廓对比度下降。
进一步分析特征图激活值，发现模型对“阴影区域”的敏感度异常升高。

操作步骤：

# 1. 临时调整告警阈值：将低置信度占比告警从15%放宽至20%（避免误报）
# 2. 触发数据回传：将置信度在0.3-0.5之间的图像裁剪后上传云端（每天约200张）
# 3. 云端标注后增量训练：使用回传数据微调模型，仅训练最后2层
# 4. 灰度发布：先在5路摄像头上部署新模型，观察48小时置信度分布

结果对比：新模型部署后，低置信度占比回落至7%，但高置信度桶（0.9-1.0）从28%升至35%——说明模型对逆光场景的判别更自信了。同时误报率从每百帧2.1次降至1.3次。

风险与代价：增量训练引入了灾难性遗忘风险——模型对正常光照场景的检测能力可能下降。因此保留了旧模型版本，并设置自动回滚机制：若新模型在正常光照下的置信度均值低于旧模型3%，则自动切换。

复盘经验：

置信度分布漂移比准确率下降早2-3天出现，是有效的早期信号。
监控必须结合时间戳与场景元数据（光照、天气、时段），否则无法定位根因。
边缘场景的模型更新必须支持灰度与回滚，不能直接全量替换。

2.5 常见误区与设计要点

经验提醒：边缘AI监控不是“部署后加一个看板”那么简单。它需要在架构设计阶段就预留监控接口——例如在推理引擎中嵌入置信度输出钩子、在数据管道中保留原始特征缓冲。如果模型已经量化部署，再想提取中间层特征就非常困难。

以下是边缘AI推理监控的五个常见误区：

监控粒度太粗：只监控“平均置信度”，忽略了分布形态变化。两个模型的平均置信度可能相同，但一个分布集中（稳定），另一个双峰（不稳定）。
忽略设备异构性：将不同硬件上的推理延迟直接对比，得出错误结论。必须使用归一化指标。
采样频率不当：端侧设备若每帧都上报监控数据，会消耗大量带宽与电量。应采用自适应采样——正常时每100帧采样1次，检测到漂移时加密至每10帧1次。
阈值静态化：固定阈值（如置信度<0.5为低）无法适应场景变化。应使用动态基线——基于过去7天的滑动窗口计算阈值。
忽略数据生命周期：边缘设备存储有限，监控数据需要定期清理或压缩。设计时需明确“原始数据保留7天，聚合数据保留30天，统计摘要保留1年”的策略。