从 YOLOv5n 到 OpenVINO INT8 ≤2MB一个课堂手机检测系统的工程化落地实践
一、为什么“课堂手机检测”不是一个简单问题？
在很多人眼里，“手机检测”似乎只是一个目标检测任务：
数据集 + YOLO → 训练 → 结束。
但当项目目标从“能跑”升级为“能部署、能交付、能在真实课堂环境稳定运行”时，问题的难度会急剧上升。
本项目的最终约束条件非常明确：
CPU 实时推理（≤25 ms / frame）
OpenVINO 推理框架
INT8 量化
模型权重文件 ≤ 2MB
适应白天 / 夜晚 / 逆光 / 遮挡等课堂环境
精度要求：
mAP@0.5 ≥ 95%
Recall ≥ 93%
False Positive ≤ 3%
这意味着：
👉算法性能、模型体积、推理速度必须同时成立，不能“只顾一头”。
二、模型选择：为什么是 YOLOv5n？
在文献调研阶段，我对比了 2020–2025 年课堂行为检测与轻量化检测方向的相关工作，统计了不同模型在以下维度的表现：
mAP
参数量
CPU 推理速度（FPS / Latency）
部署复杂度
最终确定技术路线为：
YOLOv5n + 模型压缩 + OpenVINO INT8
原因很现实：
YOLOv5n 在参数量 / 精度 / 工程成熟度之间平衡最好
模型结构清晰，利于后续压缩与部署
OpenVINO 对 YOLOv5 的支持最稳定
而不是一味追新（例如 YOLOv8 + CUDA），因为部署环境并不允许 GPU。
三、数据集与增强：小目标 + 遮挡是核心难点
数据来源
校内真实课堂环境采集
公开数据集补充
共约8000 张手机图像
面临的问题
手机目标尺寸小
经常被书本、桌面、人体部分遮挡
光照变化剧烈（逆光 / 夜晚）
数据增强策略
针对上述问题，采用了：
Mosaic：提升小目标感知能力
HSV 增强：增强光照鲁棒性
随机遮挡（Random Erasing）：模拟真实遮挡情况
通过三倍增强，有效缓解了小目标漏检与遮挡误检问题。
四、模型压缩：为什么“imgsz 解决不了体积问题”？
这是整个项目中最容易被误解的一点。
在 OpenVINO INT8 部署阶段，很多初学者会尝试：
“把输入尺寸从 640 改成 480，是不是模型就小了？”
答案是：几乎没用。
原因很简单：
.bin文件大小 ≈模型参数量imgsz影响的是特征图尺寸和推理速度不影响卷积权重的数量
真正决定.bin大小的，只有一件事：
模型结构的参数规模（通道数）
五、关键工程决策：通过 width_multiple 控制模型体积
YOLOv5 的scales机制提供了非常干净的模型缩放方式：
scales: n: [depth, width, max_channels]
在默认 YOLOv5n 中：
depth = 0.33
width = 0.25
INT8 量化后，模型.bin大小约为2.46 MB，无法满足 ≤2MB 的硬约束。
解决方案
不是 hack，不是裁权重，而是结构级压缩：
n: [0.33, 0.20, 1024]
将 width 从0.25 → 0.20，参数量下降约36%，这是：
可解释的
可复现的
工程上最稳妥的做法
六、OpenVINO INT8：真正的工程难点
INT8 不是一句参数int8=True就结束了。
实际遇到的问题包括：
OpenVINO Python API 与 NNCF 版本兼容性问题
openvino.op/Node/Input等接口差异Ultralytics 自动量化路径与自定义 PTQ 的冲突
校准数据集路径与格式要求
最终采用的稳定方案是：
FP16 OpenVINO IR → NNCF PTQ → INT8 IR
并通过真实课堂数据进行校准。
最终结果
成功生成
best_clean_int8.xml / .binINT8
.bin大小≤2MBCPU 推理速度提升约2.3×
单帧推理时间 <25 ms
七、蒸馏不是“必须项”，而是“对照项”
在实验阶段，我也进行了：
Teacher：YOLOv5s → Student：YOLOv5n
的知识蒸馏实验，用于验证精度提升空间。
但在最终部署模型中，我选择的是：
结构缩小 + INT8 量化的非蒸馏版本
原因很简单：
已满足精度与体积要求
模型结构更干净
工程复杂度更低
蒸馏被保留为对照实验与方法验证，而非部署必需步骤。
八、工程化落地：从模型到系统
系统采用模块化设计：
数据层：视频 / 图像输入
模型层：OpenVINO 推理
界面层：PyQt + OpenCV
功能包括：
图片 / 视频 / 实时摄像头检测
目标数量实时统计
告警阈值设置
自动生成 Excel 检测日志
并通过多场景（白天 / 夜晚 / 逆光 / 遮挡）测试验证鲁棒性。
九、总结：这是一个“工程完整度优先”的项目
这个项目不是追求 SOTA，而是解决一个非常现实的问题：
在资源受限的 CPU 环境下，把模型真正跑起来，并且可交付。
回顾整个过程，最重要的收获不是某个模型，而是：
对模型体积本质的理解
对INT8 工程落地难点的认知
对“算法 vs 部署”取舍关系的实践经验
这正是我认为工程类项目最有价值的地方。