3. 边缘计算与低延迟架构
工业视觉缺陷检测对延迟的敏感度极高：一条以每分钟 120 件产品速度运行的产线，单件检测时间预算仅为 500ms，而一旦出现漏检或误检，停机确认与返工成本往往远超设备本身价值。传统“相机采集—上传云端—GPU 推理—返回结果”的架构在网络抖动或带宽受限时，单次往返延迟可能达到 200-800ms，且数据出园区面临合规风险。边缘计算将推理能力下沉到产线侧，使端到端延迟压缩至 30-80ms 量级，同时保留云端训练与全局调度的能力。本章聚焦边缘端硬件选型、边缘计算的核心优势，以及端-边-云三层协同设计的工程方法论。
3.1 边缘端硬件选型：从 Jetson Nano 到 Orin 的工程决策
边缘硬件的选型不是“算力越大越好”，而是要在算力、功耗、接口、环境适应性和成本之间找到平衡点。NVIDIA Jetson 系列是目前工业视觉边缘部署的主流平台，其统一的 CUDA 生态使得 TensorRT 优化后的模型可以无缝迁移。选型时需关注四个核心维度：AI 算力（TOPS）、内存带宽与容量、I/O 接口（尤其相机接口与 GPIO）、工作温度与供电方式。
| 型号 | AI 算力 | 内存 | 典型功耗 | 相机接口 | 适用场景 |
|---|---|---|---|---|---|
| Jetson Nano 2GB | 0.5 TOPS | 2GB LPDDR4 | 5-10W | USB3.0 / CSI | 低分辨率、单相机、原型验证 |
| Jetson Xavier NX | 21 TOPS | 8GB / 16GB | 10-25W | GigE / USB3.0 / CSI | 主流工业检测、多相机 |
| Jetson AGX Orin 64GB | 275 TOPS | 64GB LPDDR5 | 15-60W | GigE / 10G / PCIe | 高分辨率、多相机、深度学习大模型 |
| Jetson Orin NX 16GB | 100 TOPS | 16GB | 10-25W | GigE / USB3.0 | 平衡性能与功耗的优选 |
在实际选型中，建议遵循“三步法”：第一步，根据产线节拍计算所需推理帧率与分辨率，确定最低算力需求；第二步，统计相机数量与接口类型，确认边缘设备是否具备足够的 PCIe 通道或 USB 控制器；第三步，评估现场供电与散热条件，工业环境往往需要无风扇设计，此时 Orin NX 的 25W 模式比 AGX Orin 的 60W 模式更具部署优势。
3.2 边缘计算的核心优势：不仅仅是延迟
边缘计算在工业视觉中的价值常被简化为“降低延迟”，但实际收益远不止于此。从系统架构角度看，边缘计算带来了四个层面的优势：确定性延迟、数据主权与安全、带宽节省、离线可用性。
确定性延迟是工业场景的刚需。云端推理的延迟是统计分布的，P99 延迟可能达到平均值的 3-5 倍，而产线 PLC 需要的是硬实时响应。边缘推理的延迟通常在 10-50ms 内，且波动极小，可以满足 PLC 的硬触发要求。数据主权方面，许多制造企业对产品图像数据有严格的保密要求，不允许图像出园区。边缘计算使得原始图像在本地处理，仅回传脱敏后的特征向量或低分辨率缩略图，从而满足合规要求。
带宽节省在视觉检测中尤为明显。以 500 万像素、8bit 灰度图像为例，单张原始图像约 25MB，若产线每秒检测 2 件产品，持续运行 8 小时，产生的数据量高达 1.4TB。通过边缘侧完成推理后，仅回传异常样本（通常占比 1%-5%），数据量可压缩至 10-70GB，降低 95% 以上。离线可用性则保障了在工厂网络维护或云端故障期间，产线检测不中断，避免因网络问题导致整线停机的风险。
3.3 端-边-云协同设计：三层架构的职责划分与数据流
端-边-云协同不是简单地把模型部署到边缘，而是需要重新设计数据流与职责边界。一个成熟的工业视觉系统通常分为三层：端侧负责图像采集与信号触发，边侧负责实时推理与产线联动，云侧负责模型训练、数据挖掘与全局运维。
端侧的关键设计在于同步与触发。工业相机应支持硬件触发模式（如 GPIO 触发或光源控制器触发），确保拍摄时刻与产品位置严格同步。边缘设备通过 PCIe 或 USB3.0 接收图像，并使用 PTP（Precision Time Protocol）与 PLC 进行时钟同步，保证图像时间戳与产线事件时间戳一致。
边侧是协同架构的核心。它运行 TensorRT 优化后的推理引擎，同时承担三类任务：实时判定（输出 OK/NG 信号给 PLC）、数据筛选（仅保留异常样本与特征向量）、本地缓存（断网时暂存数据，恢复后自动续传）。边侧还应部署一个轻量级的模型版本管理模块，支持从云端拉取新模型并热替换，替换过程不影响正在运行的推理任务。
云侧则聚焦于非实时任务：基于回传的异常样本进行模型迭代训练、跨厂区模型聚合、以及可视化监控大屏。云侧通过 MQTT 或 gRPC 与边侧通信，下发模型更新指令与阈值配置。需要特别注意的是，云侧下发的模型必须经过 TensorRT 转换并量化，且需在云端使用与边侧相同的 TensorRT 版本进行验证，避免版本不兼容导致推理失败。
3.4 实战案例：某汽车零部件厂表面缺陷检测的边缘化改造
某汽车零部件制造商生产铝合金压铸件，需要在冲压完成后对每个工件进行表面缺陷检测，检测内容包括划痕、气孔、毛刺三类缺陷。原方案采用云端推理，但由于工厂网络带宽有限（上行 20Mbps），且车间存在金属粉尘导致网络信号不稳定，实际检测延迟波动在 300ms-1.2s 之间，无法满足 600ms 的节拍要求，且经常出现因网络超时导致的漏检。
改造方案采用 Jetson Xavier NX 作为边缘计算节点，搭配 2 台 500 万像素 GigE 工业相机，使用硬件触发模式与 PLC 联动。模型方面，将原先的 YOLOv5s 模型转换为 TensorRT FP16 引擎，推理延迟从 GPU 服务器上的 45ms 降至 22ms。图像预处理（包括 ROI 裁剪、灰度化、直方图均衡）在边缘设备上通过 CUDA 加速完成，耗时 8ms。整体端到端延迟（从相机触发到 PLC 收到结果）稳定在 35-40ms，满足产线要求。
数据流设计上，正常样本的图像在边缘侧直接丢弃，仅保留检测结果计数；异常样本则裁剪缺陷区域并压缩为 JPEG 后回传云端。回传数据量从原来的每天 1.2TB 降至 40GB。云端每周基于新增异常样本进行模型微调，并通过 MQTT 下发更新后的 TensorRT 引擎。在实施过程中遇到的一个关键问题是：Xavier NX 的散热在夏季车间温度达到 40°C 时出现降频，导致推理延迟从 22ms 升至 35ms。解决方案是增加主动散热风扇，并将设备安装在远离热源的机柜中，同时将功耗模式从 20W 调整为 25W 以保证性能。
3.5 常见误区与总结复盘
在边缘计算架构的落地过程中，工程师常陷入以下误区：误区一：认为边缘计算就是“把模型放到小盒子里跑”，忽略了与 PLC 的硬接线联动设计，导致推理结果无法及时触发剔除机构；误区二：过度追求 INT8 量化，虽然推理速度提升，但精度损失超过 1% 导致误检率上升，反而增加了人工复检成本；误区三：忽视边缘设备的运维通道，当现场出现模型异常时，无法远程登录排查，只能停机处理。