2. 边缘AI基础
在工业设备状态监测、产线质量检测、能源管理与智慧城市等场景中，数据产生的源头往往远离中心机房。若将所有传感器数据回传云端处理，不仅消耗大量带宽，还会引入不可控的网络延迟，难以满足毫秒级响应需求。边缘AI正是为解决这一矛盾而生——它将人工智能推理能力下沉到数据产生的物理位置附近，在设备端直接完成数据采集、预处理、特征提取与模型推理。本章将系统梳理边缘计算与边缘AI的核心定义、分层架构、主流硬件平台，并结合设备端漂移监测的实际需求，分析边缘AI带来的工程价值与选型要点。
2.1 边缘计算与边缘AI的定义及核心原理
边缘计算（Edge Computing）是一种分布式计算范式，它将数据处理、存储和应用运行从中心化的云端下沉到网络边缘——即数据源附近。边缘并非特指某一类设备，而是一个相对概念：在工厂车间里，边缘可以是PLC或工控机；在变电站中，边缘可以是智能网关；在移动设备上，边缘就是手机SoC中的NPU模块。边缘计算的核心思想是"在靠近数据产生的地方完成计算"，从而减少数据传输距离和往返时间。
边缘AI（Edge AI）则是边缘计算与人工智能的深度融合，指在边缘设备上直接运行机器学习或深度学习模型，完成推理任务。与云端AI相比，边缘AI强调三点：本地推理（模型不依赖云端即可运行）、实时响应（推理延迟可控在毫秒级）、数据隐私（原始数据不出设备）。在设备端漂移监测场景中，边缘AI通常承担振动信号的特征提取、异常分类、趋势预测等任务。
理解边缘AI需要把握三个关键原理：
- 模型压缩与轻量化：边缘设备的算力、内存和功耗受限，无法直接运行云端的大规模深度网络。因此需要采用模型剪枝、权重量化（如INT8）、知识蒸馏等技术，将模型压缩到几MB甚至几百KB级别，同时保持可接受的精度。
- 异构计算调度：现代边缘SoC通常集成CPU、GPU、NPU（神经网络处理单元）或DSP等多种计算单元。合理的任务调度——例如将卷积操作分配给NPU、将控制逻辑保留在CPU——可以显著提升能效比。
- 端云协同：边缘AI并非完全脱离云端。典型的协同模式是：云端负责模型训练和版本更新，边缘负责实时推理和快速响应；边缘定期将模型漂移指标、异常样本摘要上传云端，云端据此优化模型并下发新版本。
2.2 边缘AI的分层架构与数据流
一个完整的边缘AI系统通常包含四个层次，各层职责明确、协同工作。理解分层架构有助于在项目初期合理规划软硬件资源。
| 层次 | 核心组件 | 主要职责 | 典型实现 |
|---|---|---|---|
| 感知层 | 传感器、信号调理电路 | 采集原始物理量（振动、温度、电流），完成滤波、放大、模数转换 | MEMS加速度计、ICP传感器、热电偶、CT传感器 |
| 边缘计算层 | MCU、CPU、FPGA | 数据预处理（去直流、加窗）、特征提取（RMS、峰值、FFT）、协议转换 | STM32、ARM Cortex-A系列、Zynq FPGA |
| 边缘AI推理层 | NPU、GPU、VPU | 运行神经网络模型，输出异常概率、故障类别、健康度评分 | Jetson Orin、树莓派+TPU、手机NPU（骁龙/天玑） |
| 应用与协同层 | 网关、边缘服务器、云端 | 本地告警、数据缓存、模型更新、云端同步 | MQTT Broker、Docker容器、K8s Edge |
在设备端漂移监测的典型数据流中，振动传感器以25.6kHz采样率连续采集信号，边缘计算层每秒钟计算一次时域特征（RMS、峰值因子、峭度）和频域特征（1X、2X幅值、边频带能量）。边缘AI推理层将最近1秒的频谱特征输入轻量级卷积神经网络（CNN）或长短期记忆网络（LSTM），输出轴承健康度评分（0-100）。当评分低于设定阈值时，边缘节点立即触发本地告警，同时将特征摘要和告警事件通过MQTT协议上报云端。整个过程端到端延迟控制在10ms以内，而如果依赖云端推理，仅网络往返就需要50-100ms，且面临带宽成本。
2.3 典型硬件平台对比与选型
边缘AI硬件平台的选择直接影响项目的性能上限、开发复杂度和单位成本。目前主流的平台包括NVIDIA Jetson系列、树莓派（Raspberry Pi）以及手机SoC中的NPU。三者定位差异明显，适用于不同的监测场景。
| 维度 | NVIDIA Jetson（Orin Nano/NX） | 树莓派 5 + Hailo/TPU | 手机NPU（骁龙/天玑） |
|---|---|---|---|
| AI算力 | 20-100 TOPS（INT8） | 13 TOPS（Hailo-8L） | 10-30 TOPS |
| 功耗 | 7-25W | 5-10W（含协处理器） | 2-5W（NPU独立功耗） |
| 开发框架 | TensorRT、PyTorch、Jetson SDK | TensorFlow Lite、ONNX Runtime | Qualcomm SNPE、MediaPipe、TFLite |
| 接口丰富度 | GPIO、CSI、PCIe、USB 3.2 | GPIO、CSI、USB 3.0、PoE | 有限（需扩展坞） |
| 适合场景 | 多通道振动分析、复杂CNN模型 | 原型验证、单通道监测、教学 | 便携监测、消费级设备 |
| 成本 | ¥1500-5000 | ¥800-2000 | 集成在手机中 |
选型建议：对于工业旋转机械的漂移监测，如果监测点数在4-8个通道且需要运行2D-CNN或Transformer轻量模型，Jetson Orin Nano是性价比最高的选择——它提供充足的CUDA核心和TensorRT加速，且支持工业级宽温版本。如果项目处于原型验证阶段，或者监测点数少（1-2通道）、模型为全连接网络或小型决策树，树莓派配合USB加速棒即可满足需求。手机NPU则更适合消费级场景，例如手持点检仪、便携式振动分析仪，利用手机已有的屏幕、电池和通信模块，可以快速构建移动监测应用。
2.4 边缘AI在实时监测中的核心优势
将AI推理下沉到设备端，为漂移监测带来了四个维度的显著优势，这些优势在传统云端方案中难以兼得。
第一，超低延迟与确定性响应。设备端推理消除了网络传输和云端排队的时间，使得从数据采集到告警输出的端到端延迟可以稳定控制在10ms以内。对于高速旋转机械（如离心压缩机转速30000rpm），轴承故障的特征频率可能高达数千赫兹，早期故障的瞬态冲击信号持续时间极短。边缘AI能够在一个采样周期内完成检测并触发保护动作，而云端方案即使延迟100ms，也可能错过关键冲击特征。
第二，带宽成本大幅降低。以一台振动监测设备为例，若以25.6kHz采样率、16位精度连续采集三轴振动数据，每小时产生的原始数据量约为：25600 × 2字节 × 3轴 × 3600秒 ≈ 553MB。如果100台设备同时在线，每小时需要上传55GB数据，这对工厂网络和云存储都是巨大负担。采用边缘AI后，设备端只上传特征值（每10秒一条，每条约200字节）和告警事件，每小时数据量降至约72KB，压缩比接近8000:1。
第三，数据隐私与安全性增强。在许多制造业场景中，设备运行数据涉及工艺参数、产能信息等商业机密。边缘AI确保原始振动波形和频谱数据不出厂区，云端仅接收脱敏后的特征统计和告警事件，降低了数据泄露风险。同时，边缘节点可以部署本地防火墙和访问控制策略，即使云端通信中断，本地监测和告警功能依然正常运行。
第四，高可用性与离线自治。工厂网络环境并不总是稳定，断网、抖动、防火墙策略变更都可能影响云端通信。边缘AI系统具备离线自治能力：在断网期间，设备端继续执行采集、推理、本地存储和声光告警；网络恢复后，自动将缓存的数据补传云端。这种设计保证了监测系统的连续性，避免因网络故障导致监测盲区。
2.5 边缘AI落地的常见误区与复盘
在边缘AI项目的实际推进中，团队常陷入几个典型误区，导致项目延期或效果不达预期。
误区一：忽视数据预处理的一致性。边缘设备上的数据预处理（如去直流、抗混叠滤波、窗函数选择）必须与训练数据时的预处理流程完全一致。很多团队在云端训练时使用Python的SciPy库进行滤波，部署到边缘时却用C语言手写滤波器，两者系数或边界处理稍有差异，就会导致推理精度下降。解决方案是在训练阶段就使用与部署环境相同的预处理代码库，或通过单元测试验证两端输出的一致性。
误区二：模型量化后未做充分验证。将FP32模型量化为INT8后，精度通常会有1-3%的下降，但在某些敏感频段可能出现较大偏差。建议在量化后使用真实采集的故障样本进行回放测试，而不仅仅使用训练集验证。同时要关注量化感知训练（QAT）与训练后量化（PTQ）的差异，对于小模型，QAT往往能获得更好的效果。
误区三：忽略边缘设备的散热与供电约束。Jetson系列在满载推理时功耗可达25W，若安装在密闭的配电柜内，可能导致热降频，推理延迟从3ms飙升至15ms。在项目设计阶段就要考虑散热方案（散热片、风扇、空调柜）和供电冗余（工业级DC-DC电源模块），并在现场进行长时间压力测试。
误区四：将边缘AI视为"黑盒"。设备端漂移监测涉及设备安全，不能完全依赖模型输出。建议在边缘节点同时部署轻量级规则引擎（如振动速度有效值超过ISO 10816标准阈值）作为兜底保护，与AI模型输出形成"双通道"判断。当AI模型与规则引擎结论冲突时，以更保守的结果为准，并记录日志供后续分析。