2. 边缘计算与AI基础

在工业自动化、智能家居、机器人控制等场景中，数据产生的源头往往不在云端，而在传感器、执行器和现场控制器附近。传统“采集→上传云端→推理→下发指令”的闭环路径，在网络延迟、带宽成本、数据隐私和断网可靠性等方面面临严峻挑战。边缘计算（Edge Computing）正是为解决这些问题而生——它将计算、存储和AI推理能力下沉到靠近数据源的位置，让设备具备“本地感知、本地决策、本地执行”的能力。本章将系统梳理边缘计算的定义与价值、与云计算的协同关系、Edge AI的典型架构，以及Jetson、树莓派、ESP32等主流硬件平台的选型逻辑。

上图展示了Edge AI系统的三层协同架构。设备端负责实时数据采集与闭环控制，边缘节点承担AI推理与本地决策，云端则聚焦模型训练与全局优化。三层之间通过MQTT、Modbus、HTTP等协议通信，形成“端-边-云”协同的完整链路。理解这一架构，是后续进行传感器选型、AI模型部署和控制系统设计的基础。

2.1 边缘计算定义与核心价值

边缘计算是一种分布式计算范式，它将数据处理、存储和应用运行从集中式的云端下沉到网络边缘——即靠近数据源或用户端的物理位置。在Edge AI场景中，边缘计算不仅指硬件层面的“本地计算”，更强调在数据产生地附近完成AI推理、决策和控制闭环，从而减少对云端网络的依赖。

边缘计算的核心价值可以归纳为四个维度：低延迟——工业控制场景要求毫秒级响应，云端往返通常需要50-200ms，而本地推理可压缩到5-20ms；带宽节省——工业现场每秒产生数MB的振动、图像数据，全部上传云端既不经济也不现实，边缘节点可先做特征提取和异常过滤，只上传关键数据；数据隐私与安全——医疗影像、生产工艺参数等敏感数据不出厂区，降低泄露风险；离线自治——当网络中断时，边缘节点仍能维持基本控制功能，避免产线停摆。

2.2 Edge AI典型架构：端-边-云协同

Edge AI的典型架构并非“边缘替代云端”，而是“端-边-云”各司其职、协同工作。设备端（端）负责原始数据采集和基础控制，边缘节点（边）承担实时AI推理和局部优化，云端（云）则进行模型训练、全局调度和长期数据分析。这种分层设计既保证了实时性，又保留了云端的算力优势。

在实际工程中，架构设计需要遵循以下操作流程：第一步，梳理数据流——明确哪些数据必须在本地闭环（如安全联锁信号）、哪些可以上传边缘（如设备状态特征）、哪些需要归档云端（如生产统计报表）；第二步，确定推理任务分配——将计算量小、时延敏感的任务（如振动阈值判断）放在设备端MCU，将计算量大、需要模型更新的任务（如视觉缺陷检测）放在边缘GPU；第三步，设计通信协议——设备端与边缘之间常用MQTT over Wi-Fi/以太网，边缘与云端之间则采用HTTPS或MQTT over 4G/5G；第四步，制定模型更新机制——边缘节点定期从云端拉取新模型版本，通过A/B测试逐步灰度发布。

// 边缘节点数据过滤伪代码示例
void edge_processing(sensor_data_t *raw, int len) {
    for (int i = 0; i < len; i++) {
        // 1. 本地阈值判断：异常数据立即触发控制
        if (raw[i].vibration > 12.5) {
            actuator_control(EMERGENCY_STOP);
            local_log(raw[i], "ALARM");
        }
        // 2. 特征提取：仅上传统计特征而非原始波形
        if (i % 100 == 0) {
            feature_t feat = extract_features(raw, i, 100);
            mqtt_publish("factory/line1/machine3", &feat);
        }
    }
}

2.3 主流硬件平台对比与选型

Edge AI硬件平台的选择直接影响系统性能、功耗和开发成本。目前主流平台可分为三个层级：MCU级（如ESP32、STM32）适合简单传感器采集和轻量级控制；SBC级（如树莓派）适合中等算力需求的边缘网关；GPU/NPU级（如Jetson系列）适合需要深度学习推理的视觉、语音场景。选型时需综合考虑算力、功耗、接口、生态和成本五个维度。

2.4 实战场景：基于Jetson的视觉质检系统

我们以一个真实的电子元器件产线案例来说明Edge AI架构的落地过程。某连接器生产厂需要检测端子针脚是否弯曲，产线速度要求每分钟检测120个产品，即每个产品检测时间不超过500ms。传统人工目检漏检率高达8%，且无法满足节拍要求。

初始方案设计：采用Jetson Orin Nano作为边缘推理平台，搭配500万像素工业相机和LED环形光源。相机通过MIPI-CSI接口直连Jetson，避免USB传输延迟。检测算法选用YOLOv8n模型，输入分辨率640×480，在TensorRT加速下推理时间约35ms，加上图像采集和运动控制时间，单件总耗时约180ms，满足节拍要求。

关键参数与调试过程：模型训练阶段，采集了2000张正常样品和1500张缺陷样品（含针脚左偏、右偏、后仰三类），通过数据增强（旋转±5°、亮度变化±20%）扩充至8000张。训练完成后，在Jetson上使用TensorRT进行INT8量化，模型体积从6.2MB压缩至2.1MB，推理速度从45ms提升至35ms，精度仅下降0.3%。部署时发现，产线振动导致图像模糊，通过将曝光时间从2000μs缩短至500μs，并增加机械减震支架解决。

结果与复盘：系统上线后，漏检率降至0.5%以下，误检率控制在1%以内。但项目中也遇到两个教训：一是初期直接使用云端训练模型部署到边缘，发现预处理逻辑不一致导致精度下降，后来统一了OpenCV版本和图像缩放算法；二是Jetson的散热风扇在产线粉尘环境下容易堵塞，改为工业级无风扇散热片方案后，连续运行温度稳定在65℃以内。

2.5 常见误区与设计复盘

在Edge AI系统设计中，工程师常陷入几个误区：误区一：认为边缘计算就是“在本地跑模型”，忽略了数据采集、预处理、控制输出等完整闭环；误区二：盲目追求高算力平台，导致成本超支和功耗过高，实际上很多场景用树莓派甚至ESP32就能满足需求；误区三：忽视模型更新机制，边缘设备部署后模型无法迭代，导致检测精度随产线变化而下降；误区四：将边缘节点视为“小云端”，直接照搬云端的微服务架构，造成资源浪费和运维复杂。

正确的设计思路应该是：首先明确控制闭环的实时性要求，确定哪些环节必须在设备端完成；其次评估数据量级和模型复杂度，选择匹配的硬件平台；然后设计轻量化的数据管道，避免在边缘节点上做不必要的重计算；最后建立模型版本管理和远程更新机制，确保系统可持续演进。边缘计算不是云计算的替代品，而是与云计算互补的智能延伸——让数据在正确的地方、以正确的速度、被正确地处理。