一、项目背景

我们服务于某华东精密制造企业的智能化改造项目。这家客户的主营业务是五金结构件与注塑件代工，产线节拍很快，单条线每分钟要过几十个工件。过去质检完全依赖老师傅目检，夜班疲劳、人员流动大，漏检率一直压不下来，客诉里的外观缺陷索赔逐年上升。

客户想上 AI 视觉质检，诉求很明确：第一，判定要快，得在工件到达下一工位前给出结果，最好是毫秒级；第二，车间网络不稳定，部分老厂房根本没有稳定外网，模型不能"上云就完蛋"，断网也得能用；第三，要把判定结果对接到现有的 MES 和质检系统，出缺陷能立刻告警、能追溯到批次和工位。

这个项目里我们用的是自研的 AI 私有化部署底座，把推理能力下沉到车间边缘设备（工控机与边缘盒子，搭载国产 GPU 与 x86 边缘算力）。底座的模型服务化层与算力调度监控层被裁剪后直接部署在边缘侧，中心侧只保留模型训练、版本管理与数据回流。说白了，这是一次典型的"云边协同"而非"云边替代"的落地。

二、落地场景

整套链路是这样的：产线摄像头（含工业相机+补光）实时采集工件表面图像，通过厂内局域网推送到边缘设备；边缘设备上的轻量化推理服务对图像做预处理与缺陷判定，给出"良品/缺陷+缺陷类型+置信度"的结果；判定结果通过 MQTT/HTTP 推送给 MES 与质检系统，缺陷件触发声光告警并打标隔离，同时写回质检数据库用于批次追溯。

网络正常时，边缘设备会把每帧的元数据、推理结果、抽检样本异步回传中心，中心侧做模型再训练与版本评估；网络抖动或断网时，边缘侧的规则引擎与主模型构成本地闭环，判定照常进行，结果缓存在本地队列，等链路恢复后补传。我们当时设了一条硬约束：任何一帧的判定都不能因为"连不上中心"而被丢弃或卡住，必须本地闭环给出结果。

三、关键技术挑战与解决思路

① 模型量化与蒸馏，适配边缘算力。 中心侧训练出的原始模型（Detection 类，参数规模较大）直接丢到边缘盒子跑不动，单帧延迟远超产线节拍要求。我们做了两步压缩：先用知识蒸馏把大模型"教"给一个轻量骨干网络，保留对缺陷敏感的特征通道；再对推理图做 INT8 量化（部分对精度敏感的输出头保留 FP16）。量化前用校准集做 KL 散度校准，避免激活值分布漂移导致误检率抬升。最终模型体积降到原来的约 1/4，边缘设备算力占用控制在 60% 以内。

② 推理框架轻量化与常驻预热，消除冷启动。 边缘设备开机后如果不预热，首帧推理会因为算子编译、显存分配进入"冷启动"长尾，延迟可能到几百毫秒。我们的做法是：推理服务做成 systemd 常驻进程，开机自启后立刻用一张预热图跑 N 次，把算子 kernel、KV 缓存（若有）和图编译结果都固化下来；同时用轻量化推理框架替代了中心侧那套较重的服务栈，干掉了不必要的调度开销。常驻之后，首帧与稳态帧延迟基本一致。

③ 断网/弱网下模型与规则本地闭环，结果异步回传。 这是客户最在意的一点。我们把"模型判定"和"业务规则"两部分都下沉到边缘：模型给置信度，规则引擎根据客户自定义的阈值（如某类划痕超过像素面积即判废）做最终裁决，并支持本地维护规则热更新。断网期间所有结果进本地持久化队列，恢复后按批次回传，回传失败自动重试，保证"判定不丢、追溯不漏"。

④ 边缘设备运维：OTA 模型更新、健康检查、灰度回滚。 几十台边缘设备不可能逐台 SSH 升级。我们搭了一套边缘 OTA 通道：中心侧出模型版本包（含校验和），设备按分组拉取，先灰度一小批，健康检查通过（推理延迟、显存、误检抽检达标）再全量推送。一旦灰度期间指标异常，一键回滚到上一稳定版本。设备侧心跳+推理延迟+队列积压统一上报到监控看板，运维不用去现场就能知道哪台盒子"亚健康"。

四、效果数据

脱敏示意，内部一致口径：

• 单帧推理延迟：稳态下约 18–25 ms（INT8 主模型），满足产线节拍；首帧与稳态差异 < 3 ms（常驻预热后）。
• 漏检率：相较纯人工目检，漏检率从约 1.2% 降至 0.15% 区间；误检率（过度判废）控制在约 0.4%，通过规则阈值调优进一步压低。
• 产线节拍影响：边缘部署对主线节拍几乎零侵入，仅在缺陷件打标隔离时增加约 0.5 s 分支动作，不构成瓶颈。
• 运维成本：过去每线需 2 名专职目检，改造后转为 1 名抽检复核 + 远程运维，按 12 条线测算，年度质检人力与客诉索赔综合成本下降约 38%。
• 断网可用性：模拟断网 4 小时的极端测试，本地闭环判定零中断，恢复后数据补传完整率 100%。

案例片段（已脱敏）：边缘量化部署命令片段（已做路径与模型名脱敏） ```bash

模型 INT8 量化校准与导出（边缘目标设备：边缘盒子 A 型）

python tools/quantize.py  --model ./models/defect_det_v3.onnx  --calib-data ./calib/line_07_2024Q2.bin  --dtype int8 --method kl  --out ./models/defect_det_v3_int8.engine

边缘常驻服务：开机预热，固化算子与缓存

systemctl enable edge-infer.service edge-infer --warmup 20 --model ./models/defect_det_v3_int8.engine --device gpu0 ```

案例片段（已脱敏）：边缘健康检查与延迟对比（示意） | 状态 | 首帧延迟 | 稳态帧延迟 | 显存占用 | | --- | --- | --- | --- | | 冷启动（无预热） | 312 ms | 21 ms | 1.9 GB | | 常驻预热后 | 22 ms | 19 ms | 1.7 GB |

五、可复用经验总结

1. 云边协同，而非云边替代。 边缘不是把云搬下去，而是把"确定性、低延迟、断网可用"的那部分能力下沉，中心保留训练、评估与数据沉淀。谁该干啥要分清楚。
2. 边缘只跑确定性模型。 边缘算力有限、运维链路长，只放经过充分验证、输出分布稳定的模型与规则；探索性、易变的任务留在中心。
3. 预热是边缘推理的必选项，不是优化项。 常驻 + 预热能把首帧长尾吃掉，否则再小的模型也会在开机后第一帧"卡一下"，而产线不原谅卡顿。
4. 断网不是异常，是常态。 把"本地闭环 + 异步补传 + 数据校验"当成默认设计，而不是事后补救，才能真正做到车间级可用。
5. 灰度回滚是边缘运维的底线。 几十台设备统一 OTA，没有灰度与一键回滚，一次坏模型推送就能让整厂质检停摆。

结语：边缘 AI 质检的难点从来不在模型本身，而在"把实验室的精度，稳定地跑在又脏又吵、还经常没网的车间里"。我们把底座的能力裁剪下沉，配合量化、预热、本地闭环和 OTA 运维，才让这个项目从 PoC 真正走到了产线常态化运行。