为什么要边缘 AI

把 AI 模型部署到产线边上，而不是全部上传云端，核心原因有三个：时延、带宽和隐私。视觉质检要求毫秒级出结果，上传云端一来一回可能几十毫秒甚至更久，还会受网络波动影响；一个质检工位每秒产生几帧高清图像，全量上云对带宽是沉重负担；工艺数据和缺陷图像更是工厂的核心资产，不能随便出境。

边缘 AI 的思路是"能本地算的绝不外送"：在靠近摄像机和设备的边缘节点完成推理，只把判定结果和少量异常样本回传平台。这样既拿到 AI 的能力，又保住响应速度和数据主权。

本文核心知识点
  • 边缘硬件GPU、NPU 与 ASIC 三类算力。
  • 模型转换训练框架导出 ONNX 再转目标格式。
  • 推理部署推理引擎加推理服务封装。
  • 模型更新边云协同的版本与灰度。

边缘 AI 不是把云端的模型原样搬下来，而是一整套工程：硬件选型、模型裁剪、格式转换、推理优化、版本管理、失败降级，任何一环不到位，产线都会出问题。

工业边缘 AI 配图：深蓝渐变背景上左侧工厂厂房轮廓，中间云朵图标，右侧带发光芯片的方形算力盒体，电路光线连成一体的扁平科技插画
算力下沉到产线边上，AI 才真正"即时可用"。

边缘 AI 硬件选型

边缘 AI 硬件的算力形态大致分三类：通用 GPU、集成 NPU 的 SoC、专用 ASIC 加速卡。GPU 生态成熟、开发最快，适合多路视觉和复杂模型；NPU 功耗低、性价比高，适合嵌入式工控机和相机盒子；ASIC 性能最强但定制化高，适合单一算法大批量场景。

  • 算力指标：看 TOPS 数值的同时，更要看有效算力和功耗，标称算力往往跑不满。
  • 接口能力：工业场景要确认支持 GigE 相机、RTSP 拉流、数字 IO 触发。
  • 环境适配：产线环境要考虑无风扇散热、宽温、防尘防震。
  • 生态成熟度：推理框架、SDK、示例代码是否齐全，直接决定开发周期。

选型先算需求：检测节拍、图像分辨率、模型复杂度决定了最低算力；再算余量，预留 30% 到 50% 的算力给算法迭代和并发路数增长。

模型训练与转换

模型在 GPU 上用 PyTorch 或 TensorFlow 训练，但边缘设备不认识这些框架的格式。业界通用的中间交换格式是 ONNX：训练好的模型导出成 ONNX，再转换成目标硬件专属的推理格式，比如 OpenVINO 的 IR 或 NPU 的量化模型。

# 导出 ONNX 示例
import torch
import torchvision.models as models

model = models.resnet18(weights=models.ResNet18_Weights.DEFAULT)
model.eval()

dummy = torch.randn(1, 3, 224, 224)
torch.onnx.export(
    model, dummy, "defect.onnx",
    input_names=["input"], output_names=["output"],
    dynamic_axes={"input": {0: "batch"}}
)
print("ONNX 导出完成")

转换后一定要做精度对齐：用同一批真实图片对比原模型和转换模型的输出，记录精度损失。常见的损失来源包括算子不支持被替换、动态 shape 被固定、量化精度损失。损失超过阈值就要回源模型做量化感知训练。

推理框架与部署

推理框架负责把模型跑起来，并针对硬件做算子加速。常见的组合是 OpenVINO 配 Intel 平台、TensorRT 配 NVIDIA 平台、各家的 NPU SDK 配自家芯片。部署时要把推理封装成服务，对外提供稳定接口。

// 推理服务伪代码：接收图像，返回缺陷判定
class InferService {
  InferenceEngine engine;
  Result infer(cv::Mat image) {
    preprocess(image);                 // 缩放、归一化
    auto out = engine.run(input);      // 执行推理
    return decode(out);                // 解析分类/检测框
  }
};

部署不只是把模型拷进去：要处理模型加载失败、内存不足、推理超时等异常；要支持多路相机并发；要记录每帧推理耗时用于监控。推理服务建议做成独立进程，与业务主程序隔离，模型崩溃不影响整条产线。