工业智能毕设入门实战：从零搭建一个可落地的边缘推理系统
做毕设最怕什么？
“算法跑通那一刻以为自己要优秀毕业生了，结果到现场演示，模型加载三分钟、风扇狂转、画面卡成PPT。”
别笑，这就是工业智能选题的常态：论文里精度 99%，现场连 9.9 帧都跑不到。
我把去年带学弟踩过的坑打包成一份“新手也能复现”的笔记，目标只有一个——让评委老师看到“它真的在转”。
1. 工业智能毕设三大“见光死”痛点
- 有算法无系统
Jupyter 里调好的.pth文件，拖到树莓派上报错十连，缺库、缺算子、缺驱动，最后只能放视频“演示效果”。 - 有模型无实时
好不容易跑起来，一张图推理 3 s，产线都走 6 米了，结果还没算出缺陷位置。 - 有 demo 无硬件
工控机 12 V 供电一插，USB 口掉线；相机 1080 p 一流，TF 卡直接写爆；现场灯光一变，白平衡漂移，模型全错。
一句话：论文讲精度，现场拼延迟、拼鲁棒、拼工程化。
下面给出一条“能跑、能测、能写进论文”的最小闭环路线。
2. 技术选型：把 3 个轻量推理框架拉到树莓派上跑分
实验平台：Raspberry Pi 4B 4 GB、64 位 Raspberry Pi OS、CPU 1.5 GHz。
模型：MobileNetV2-SSD 输入 320×320，输出 20 类缺陷检测。
指标：单帧推理延迟（ms）、峰值内存（MB）、首次冷启动时间（s）。
| 框架 | 延迟 | 内存 | 冷启动 | 备注 |
|---|---|---|---|---|
| TensorFlow Lite 2.11 | 142 ms | 210 MB | 4.8 s | 需要libedgetpu才能进 100 ms |
| ONNX Runtime 1.15 (CPU) | 118 ms | 180 MB | 2.1 s | 直接pip install即可 |
| OpenVINO 2023.1 | 105 ms | 160 MB | 3.3 s | 需要 ARM 插件，编译 40 min |
结论：
- 如果 CPU -only、最快落地→ONNX Runtime；
- 后续想上 NPU→TFLite；
- 团队有 Intel 边缘盒→OpenVINO。
毕设阶段先保“能跑”，选 ONNX Runtime 最稳。
3. 核心实现：用 Flask 包一层“工业风格”的 HTTP 服务
功能清单：
/predict支持单次/批量 jpg 上传；- 返回 JSON：框、置信度、耗时、模型版本；
- 限流 10 QPS，超了直接 503，防止老师一激动狂点；
- 日志带时间戳、设备序列号，方便答辩甩锅。
3.1 项目骨架
edge_infer/ ├── app.py # Flask 入口 ├── model/ │ └── defect.onnx ├── runtime/ │ ├── __predict.py # ONNX 封装 │ ├── pre_post.py # 图像预处理/后处理 │ └── logger.py # 统一日志 └── test/ └── bench.sh # 压测脚本3.2 关键代码（节选，可直接跑）
runtime/_predict.py
import onnxruntime as ort import numpy as np import time from pathlib import Path class OnnxEngine: def __init__(self, path: str, providers=None): # 冷启动一次性加载 providers = providers or ['CPUExecutionProvider'] self.session = ort.InferenceSession(path, providers=providers) self.input_name = self.session.get_inputs()[0].name self.version = Path(path).stem # 用文件名当版本号 def __call__(self, x: np.ndarray): t0 = time.time() outputs = self.session.run(None, {self.input_name: x}) cost = time.time() - t0 return outputs, costapp.py（限流+日志）
from flask import Flask, request, jsonify from runtime._predict import OnnxEngine from runtime.logger import logger from runtime.pre_post import preprocess, postprocess from flask_limiter import Limiter from flask_limiter.util import get_remote_address app = Flask(__name__) limiter = Limiter(app, key_func=get_remote_address) engine = OnnxEngine("model/defect.onnx") @app.route("/predict", methods=["POST"]) @limiter.limit("10 per second") def predict(): try: files = request.files.getlist("images") if not files: return jsonify(code="empty"), 400 results = [] for f in files: img = preprocess(f.read()) preds, cost = engine(img) boxes = postprocess(preds) results.append({"boxes": boxes, "latency_ms": round(cost*1000, 2), "model": engine.version}) logger.info("predict", extra={"count": len(files)}) return jsonify(results=results) except Exception as e: logger.exception("predict error") return jsonify(error=str(e)), 500 if __name__ == "__main__": app.run(host="0.0.0.0", port=8080, threaded=True)3.3 打包镜像
写个 200 MB 的“迷你镜像”给评委：docker build -t edge_infer_arm .
Dockerfile 里用arm64v8/python:3.9-slim，把 ONNX Runtime 官方 wheel 提前 COPY 进去，现场无网也能跑。
4. 性能实测：Raspberry Pi 4 能扛多少 QPS？
测试脚本：locust -f bench.py --host=http://pi4:8080 -u 20 -r 5 -t 60s
结果：
- 单帧 118 ms，8 帧并行 → 峰值 QPS ≈ 7.8；
- CPU 占用 380 %（四核全开）；
- 内存稳定 185 MB；
- 冷启动 2.1 s，演示前记得“热身”：
curl -X POST http://localhost:8080/warmup -d '{}'把空请求打一次，让 ONNX 建缓存，现场就不会尴尬卡 2 秒。
5. 生产环境（答辩现场也算）避坑 6 条
- 模型版本管理
把defect_v1.onnx、defect_v2.onnx丢进model/目录，接口加?version=v1，回滚只需改 URL，别让老师看到“玄学更新”。 - 输入异常兜底
有人上传 8 K PNG，树莓派直接 OOM。预处理里强制 resize + 通道检查，异常返回 415，服务就不会崩。 - 设备时钟同步
树莓派没电池，断电后时间回到 1970，日志顺序全乱。开机加一条ntpdate ntp.aliyun.com，排障时才找得到线索。 - TF 卡写穿
默认日志写文件，压测一夜把 32 G 卡干废。用logrotate或直接把日志走stdout，journald自动滚储。 - 供电不足
官方 5 V 3 A 头最稳；USB 口接相机再加延长线，电压掉到 4.6 V 就会随机重启。 - 演示画面
写个 30 行的小网页，调接口回显框选，老师一点“拍照”按钮就能看到结果，比curl直观一百倍。
6. 拓展思考：从单节点到多设备协同
单台树莓派只能守一个工位，如果整条产线有 6 台相机，怎么办？
- 把推理服务容器化，用 Docker-Compose 一键下发；
- 中心工控机跑 MQTT/NATS，各节点推结果上去，统一归档；
- 模型热更新：节点监听“模型仓库”的 Webhook，下载→校验→软链接切换，零停机；
- 边缘-云分层：简单筛选本地做，复杂训练放 GPU 服务器，晚上闲时回传数据，白天只传异常帧，省流量 90 %；
- 毕设第二章就可以写“分布式边缘节点协同框架”，老师看你格局直接 A+。
7. 一句话总结
论文写算法，现场拼工程；先把 ONNX+Flask 这条最小闭环跑通，再去谈精度、谈分布式、谈工业 4.0。
当你能在树莓派上稳定跑出 7 QPS，日志整齐、版本可控、异常不崩，就已经领先 80 % 的“纯算法”选手。
下一步，不妨想想：如果给每个边缘节点加上“自汇报健康分数”，你的毕设故事是不是又多了一章？
