工业智能毕设入门实战：从零搭建一个可落地的边缘推理系统

工业智能毕设入门实战：从零搭建一个可落地的边缘推理系统

做毕设最怕什么？
“算法跑通那一刻以为自己要优秀毕业生了，结果到现场演示，模型加载三分钟、风扇狂转、画面卡成PPT。”
别笑，这就是工业智能选题的常态：论文里精度 99%，现场连 9.9 帧都跑不到。
我把去年带学弟踩过的坑打包成一份“新手也能复现”的笔记，目标只有一个——让评委老师看到“它真的在转”。

1. 工业智能毕设三大“见光死”痛点

1. 有算法无系统
   Jupyter 里调好的.pth文件，拖到树莓派上报错十连，缺库、缺算子、缺驱动，最后只能放视频“演示效果”。
2. 有模型无实时
   好不容易跑起来，一张图推理 3 s，产线都走 6 米了，结果还没算出缺陷位置。
3. 有 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）。

结论：

• 如果 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, cost

app.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 条

1. 模型版本管理
   把defect_v1.onnx、defect_v2.onnx丢进model/目录，接口加?version=v1，回滚只需改 URL，别让老师看到“玄学更新”。
2. 输入异常兜底
   有人上传 8 K PNG，树莓派直接 OOM。预处理里强制 resize + 通道检查，异常返回 415，服务就不会崩。
3. 设备时钟同步
   树莓派没电池，断电后时间回到 1970，日志顺序全乱。开机加一条ntpdate ntp.aliyun.com，排障时才找得到线索。
4. TF 卡写穿
   默认日志写文件，压测一夜把 32 G 卡干废。用logrotate或直接把日志走stdout，journald自动滚储。
5. 供电不足
   官方 5 V 3 A 头最稳；USB 口接相机再加延长线，电压掉到 4.6 V 就会随机重启。
6. 演示画面
   写个 30 行的小网页，调接口回显框选，老师一点“拍照”按钮就能看到结果，比curl直观一百倍。

6. 拓展思考：从单节点到多设备协同

单台树莓派只能守一个工位，如果整条产线有 6 台相机，怎么办？

1. 把推理服务容器化，用 Docker-Compose 一键下发；
2. 中心工控机跑 MQTT/NATS，各节点推结果上去，统一归档；
3. 模型热更新：节点监听“模型仓库”的 Webhook，下载→校验→软链接切换，零停机；
4. 边缘-云分层：简单筛选本地做，复杂训练放 GPU 服务器，晚上闲时回传数据，白天只传异常帧，省流量 90 %；
5. 毕设第二章就可以写“分布式边缘节点协同框架”，老师看你格局直接 A+。

7. 一句话总结

论文写算法，现场拼工程；先把 ONNX+Flask 这条最小闭环跑通，再去谈精度、谈分布式、谈工业 4.0。
当你能在树莓派上稳定跑出 7 QPS，日志整齐、版本可控、异常不崩，就已经领先 80 % 的“纯算法”选手。
下一步，不妨想想：如果给每个边缘节点加上“自汇报健康分数”，你的毕设故事是不是又多了一章？