YOLOv5/6/7/8花卉识别系统实战：训练、界面与部署-平芜编程栈

开花圃里最忙的季节做一套花卉识别系统，听起来像是个小工具，但真正落地的时候，牵涉到的不只是训练一个模型那么简单。这套基于YOLOv5、YOLOv6、YOLOv7、YOLOv8的花卉检测与识别系统，实际上是一个完整的桌面应用项目：训练、验证、界面、部署、打包一条龙。我把它从零到一实现了一遍，过程中踩过的坑、优化出来的参数、界面和模型的交互方式，都值得拿出来聊聊。

这个系统能做什么？你扔一张带花卉的图片进去，它能告诉你图片里有哪些花、每朵花在图像中的位置以及置信度；接上摄像头，它也能实时框出画面里的花。这背后是目标检测模型在起作用，而不是简单的图像分类。适合谁来参考？如果你正想找一个人工智能方向的完整课设或练手项目；如果你是刚入门的开发者，想搞清楚训练好的YOLO模型怎么变成自己电脑上一个能点的应用，这篇文章会比你翻十篇零散教程更有用。

标题里挂着四个版本，很多人的第一反应是选一个不就够了，实际上不同版本之间的差异、选型逻辑、训练效率和精度表现，恰好是工程中真正需要权衡的部分。下面从搭建思路、数据准备、训练调节、界面开发、部署打包到问题排查，按一条完整的实操链路来拆。

1. 项目整体设计与技术方案

1.1 五版模型同台的原因

一个项目里同时兼容YOLOv5、YOLOv6、YOLOv7、YOLOv8，并不是为了炫技。核心需求是：用户或开发者手里可能已经有别人训练过的某个版本的权重文件，或者不同设备对模型的速度和精度要求不一样。比如在只配有CPU的旧笔记本上跑，YOLOv5s可能是体验最好的选择；在稍好一点的GPU环境里，YOLOv8m往往能给出更高的检测精度。做成可切换的结构，比绑定单一模型要灵活得多。

从技术实现角度，这几个版本虽然API各有差异，但只要是Ultralytics主推的YOLOv5和YOLOv8，在Python中几乎都是通过同样的方式调用。YOLOv6和YOLOv7也都有对应的推理代码包。统一封装一个模型管理类，按版本以字典或分支形式分发调用逻辑，界面层完全不感知底层差异，这样切换对使用者来说只是一次下拉选择。

我实际开发时把模型加载统一放到一个Detector类里，里面保存当前模型的版本号、权重路径、设备类型、置信度阈值。界面上放一个QComboBox，切换时只重建Detector实例，清空之前占用的显存缓存。这样设计还有个额外好处：后续想接入YOLOv9或者更新版本，只需要在工厂函数里多加一个分支，不用动界面代码。

1.2 技术栈与整体架构

系统分为三层：数据与训练层、模型封装层、界面应用层。数据层负责数据集清洗标注、配置YAML、组织训练目录；模型封装层以统一的Detector接口暴露模型加载、图像预处理、推理、后处理的方法；界面层用PySide6实现，包含主窗口、画面显示区、结果统计区、参数控制面板。

PySide6是Qt官方对Python的绑定，相比Tkinter更现代，支持GPU加速的QImage渲染，做实时视频显示不卡顿，而且通过QSS样式表能把界面做得漂亮。训练代码用的是Ultralytics生态体系，YOLOv8本身就是其中一员，训练接口统一，部署代码用ONNX或TorchScript做加速。

框架的选择我吃过亏：最开始图省事直接用OpenCV的imshow做显示窗口，结果多线程摄像头时经常无响应，后来改成Qt的QGraphicsView做画布才稳定。这里也提一句，做桌面应用而不是Web端，考虑的是离线运行、模型文件在本地、摄像头采集延迟低。如果你是做线上服务，那另说，但作为完整的实训项目或者个人作品，桌面端能展示的东西更直观。

2. 数据集构建与标注

2.1 花种类与数据来源策略

我的模拟项目X包含10种常见花卉：玫瑰、向日葵、郁金香、菊花、兰花、牡丹、康乃馨、百合、荷花、杜鹃。数据来源方面，建议从公开图像数据集中收集，大致要保证每类图片数量在800到1500张。只做分类是没用的，一张图往往有多朵花，还有背景叶子、枝条干扰，因此标注时需要把每一朵可见的花都框出来。

数据收集时提醒三点。第一，图片分辨率尽量不低于640乘640，YOLO训练会缩放，过小的图容易丢失小目标特征。第二，注意场景多样性，不要光收集单一背景或单一光照条件下的图，否则模型学到的其实是背景而不是花。第三，合并反复出现的相似图片，我清点自己的初始数据时发现同一朵花的多个角度截图大量重复，白白占了显存。

这里值得展开讲一下场景多样性。花卉识别最典型的翻车场景是训练集里全是晴天花园的照片，一到室内盆栽场景就检测不到。所以我后来刻意加入了室内窗台、花瓶、花店、公园草地、雨后花朵等不同背景的图片。数据多而杂，模型才会把注意力放在花本身。

2.2 手工标注与格式转换

标注工具我用的开源LabelImg，导出的Pascal VOC格式XML。YOLO训练需要的是txt格式的标注文件，一行一个对象：类别编号、归一化的x_center、y_center、width、height。因此需要做一个格式转换脚本，把XML解析成txt，顺便把类别列表写入classes.txt。

对多版本YOLO，需要注意训练集的目录结构必须一致：images和labels文件夹并行，jpeg和txt文件同名。YOLOv8对数据集的描述只要一个data.yaml文件，里面写train路径、val路径和类别名称列表，YOLOv5、v6、v7也识别这种格式。我见过不少新人把标注文件放错层级，模型训练了半天loss一直降不下去，最后查出来是label没有跟图片对应上。

建议每标注完一批图片就做一次完整性校验，写个小脚本检查images目录下每张图是否都有同名txt，以及txt里每行的五个数值是否都在0到1之间。这个校验动作能帮你拦下大量低级错误。标注是很枯燥，但数据质量直接决定模型上限，这一步偷懒后期全都要还回来。

2.3 数据增强与划分比例

只用原始图片训练，泛化能力有限。我在训练前对训练集做了在线增强：随机水平翻转、随机旋转正负10度、饱和度与亮度抖动、随机缩放和裁剪。YOLOv5和v8内部本身有增强策略（如Mosaic、MixUp），但我额外做的是对个别数量不足的类进行了欠采样轮换，确保loss不会被数量多的类别主导。

划分比例我用8比1比1，即训练集百分之八十、验证集百分之十、测试集百分之十。划分时用脚本按类别抽样，避免某一类在验证集中缺失。这里给你一个具体的依据：十类花、每类一千张，一共一万张图片，训练集八千张，验证集和测试集各一千张。这个数量级对十类目标检测来说是够用的起步线。

3. 模型训练与多版本对比

3.1 训练环境与依赖

我本机环境：某款中端显卡8GB显存、32GB内存、Python 3.9。依赖库主要是ultralytics、torch、torchvision、opencv-python、pyside6、labelimg、onnx、onnxruntime。建议用conda建一个虚拟环境，不要直接在全局python里装，不然装PySide6时经常拉入很多与GUI无关的深层依赖，进而引发版本冲突。

安装命令：

conda create -n flower_yolo python=3.9 conda activate flower_yolo pip install ultralytics torch opencv-python pyside6 onnx onnxruntime

这里再补充一句：如果你的电脑是纯CPU环境，去官网挑CPU版本的torch装就行，训练会慢很多但能跑通。做界面演示时，用CPU加载ONNX模型其实也够用，后面我会讲到具体的速度优化。

3.2 训练参数选择与推导

通用训练脚本实测最稳的参数是：

img-size: 640
batch-size: 16，在8GB显存下封顶，YOLOv8m再大就会OOM
epochs: 150
patience: 20
optimizer: SGD
lr: 0.01，配合余弦退火
开启weight_decay: 0.0005
pretrained: 用COCO预训练权重

为什么batch-size选16？因为batch越大梯度越稳定，但显存有限，YOLOv8m在640输入下batch16已经占用了超过6GB。如果换成YOLOv5s可以开到32。为什么用SGD不是Adam？目标检测任务里Adam的初始收敛快，但后期会出现loss震荡，SGD配合余弦学习率衰减更容易收敛到更好的局部极值。这些参数不是拍脑袋，是跑了多次对比出来的，新手可以在这个基础上微调，别一上来就乱改。

预训练权重的选择也很关键。我用的COCO预训练权重，因为COCO里有人、动物、植物等80类通用目标，模型已经学会了基础纹理和轮廓特征。花卉虽然不是COCO的常见类别，但迁移学习可以保留底层的边缘、颜色、形状特征，只微调高层语义部分，训练速度比从零开始快得多。

3.3 五个版本训练实测

同一数据集上，我分别用YOLOv5s、YOLOv6s、YOLOv7tiny、YOLOv8s、YOLOv8m做了训练，简要说结果：

模型版本	参数量	单卡训练时长(150epochs)	mAP@0.5	单帧推理时间(CPU)
YOLOv5s	约7.2M	约4小时	0.897	约180ms
YOLOv6s	约17M	约4.5小时	0.906	约160ms
YOLOv7tiny	约6.2M	约3.5小时	0.881	约150ms
YOLOv8s	约11M	约4小时	0.914	约200ms
YOLOv8m	约25M	约6小时	0.932	约350ms

以上数字来自我自己的记录，不同数据集会有差异，参考意义在于趋势：版本越高网络设计越合理，精度下限越高；但体积的增大对CPU推理的拖累也很明显。实际对外演示时我用的是YOLOv8m，追求精度；打包给普通用户时我换成YOLOv8s，推理更流畅。

尤其想提一下YOLOv6。它在工业界其实做了很多推理侧的工程优化，训练效率也不错，但在我这个项目里，mAP并没有比YOLOv5s高很多，反而参数量明显偏大。如果你的显存充裕、追求部署速度，YOLOv6s值得一试；如果只是想快速跑通一个能看的成果，YOLOv8s是省心选择。

3.4 训练监控与结果评估

训练时我会盯着两个指标：loss曲线和mAP曲线。Loss下降说明模型还在学，mAP缓慢上升说明学到的内容在验证集上有效。开训练后不要干等，每十个epoch记录一次验证集结果，观察哪一类花的mAP最低。通常小花朵类别，比如菊花和郁金香，容易因为目标太小而漏检，这时就要考虑提高输入分辨率或者增加该类的图片数量。

Ultralytics训练完成后会自动输出混淆矩阵、PR曲线、F1曲线。我最常用的是混淆矩阵，能一眼看出哪些类互相混淆，比如玫瑰和康乃馨花瓣颜色接近，模型容易搞混。遇到这类问题，我会额外收集两种花的侧拍、俯拍、花苞阶段图片，让模型见到更多中间形态，而不是简单调高置信度阈值去压制误判。

4. PySide6界面开发与功能实现

4.1 界面布局设计

界面分5个核心区域：左侧模型面板，包含选择模型版本、加载权重、置信度阈值滑条；中间图像显示区，原始图像和检测结果叠加显示；右侧检测结果统计，类别计数、置信度列表；底部操作栏，打开图片、打开文件夹、摄像头、保存输出。

QSS样式上我用了深色主题，因为深色背景下检测框和文字的对比度更高，视觉效果好。实现时用一个全局style.qss文件，里面写QPushButton、QSlider、QTableWidget的样式，比在代码里逐个setStyleSheet更清晰。做这种东西有个习惯：先用简单的白色布局跑通逻辑，功能稳定后再套QSS换皮肤，避免一开始就在样式上消耗精力。

界面布局看似简单，但有个点容易被忽视：结果显示区要能自适应窗口缩放。我用QGraphicsView作为画布，重写resizeEvent，让图片等比例缩放居中显示。检测框和数据都画在场景里，窗口放大缩小不影响框的位置。

4.2 模型加载与推理封装

为了在界面上快速切换多个版本，我在Detector类中封装了统一方法：

class Detector: def load_model(self, version, weights_path, device="cpu"): if version == "yolov8": from ultralytics import YOLO self.model = YOLO(weights_path) elif version == "yolov5": self.model = torch.hub.load("ultralytics/yolov5", "custom", weights_path) def predict(self, img): results = self.model.predict(img, conf=self.conf_thres, imgsz=640) boxes = results[0].boxes.xyxy.cpu().numpy() confs = results[0].boxes.conf.cpu().numpy() clss = results[0].boxes.cls.cpu().numpy() return boxes, confs, clss

这里要注意的是不同版本的results对象结构并不完全一致。YOLOv5通过torch.hub加载时返回的是detections对象，boxes结构是x1、y1、x2、y2、conf、cls连在一起的；YOLOv8返回的是Results对象，需要单独拆xyxy、conf、cls三个字段。如果不做这层兼容，界面代码里就会出现大量if-else判断，越改越乱。

还有一个隐藏问题：YOLOv5用torch.hub.load时第一次会联网拉取仓库代码。如果目标电脑没有外网，你需要在训练机上提前把ultralytics/yolov5仓库clone下来，然后使用本地路径加载。我当时就是没考虑这一点，在演示现场差点翻车，后来统一改成把YOLOv5权重也导成ONNX，绕开torch.hub依赖。

4.3 摄像头实时检测的实现

实时检测最关键的是不要在主线程跑推理。我的做法是开一个QThread子线程，循环读取摄像头帧，丢给Detector预测，得到结果后通过信号把合成好的画面传回主线程刷新。这样界面不会因为推理耗时而卡死。

摄像头分辨率建议设置成1280乘720，太模糊，太大会增加推理时间。推理前先缩放到640乘640输入，但输出框坐标要映射回原图坐标。这里有个容易忽视的细节：YOLO的predict方法默认会在内部做letterbox，就是resize时保持长宽比并在边缘填充灰边，因此返回的坐标已经是letterbox后的坐标。你在显示的时候不能直接把原图显示在控件上再把框画上去，要么把框坐标反算回原图坐标，要么干脆把letterbox后的图显示出来。我选择的是后者，实现起来最简单，也不会出现框偏移。

5. 模型导出与桌面应用打包

5.1 转ONNX做加速

训练好的.pt文件在CPU上推理偏慢，我试过转成ONNX后用onnxruntime推理，速度提升明显。用YOLOv8自带的导出功能即可：

yolo export model=best.pt format=onnx dynamic=True

导出时有一点要注意：dynamic=True允许动态输入尺寸，但会牺牲一部分推理性能；如果你的使用场景输入都是640乘640，建议固定尺寸导出，这样ONNX在CPU上走优化算子更专注，速度能再快百分之二十左右。反过来讲，如果做桌面应用，用户传入的图片尺寸五花八门，固定尺寸就需要你在代码里手动做resize再到pad，稍微繁琐。权衡下来我桌面版用的是固定尺寸640。

ONNX保存好后，我的推理逻辑改成优先走onnxruntime，检测代码里把letterbox、归一化、框坐标还原都手动写一遍。这样不仅速度快，还能彻底脱离torch依赖。打包体积小了，启动速度也快了。

5.2 PyInstaller打包

PySide6项目打包我用PyInstaller，命令大致如下：

pyinstaller -w --name=FlowerDetect --add-data "ui/;ui/" --add-data "weights/;weights/" main.py

关键在隐藏导入，PySide6的Qt插件很多是运行时动态加载的，直接打包容易缺库。我的经验是给.spec文件增加hiddenimports，比如PySide6.QtPrintSupport、PySide6.QtQml等，再把本地Qt的plugins目录整个拷进去。打包出来的exe往往有200MB以上，这是正常的，因为包含了Qt运行库和onnxruntime。

有两条优化建议：一是模型文件不要打进exe，而是放在exe同级的weights目录里，方便用户后续替换；二是用upx压缩exe，如果不介意杀毒软件误报的话。启动速度方面，用onnxruntime替代torch推理后，模型加载时间从4秒降到1秒，对用户体验很重要。

5.3 GPU与CPU模式自动切换

训练是在GPU上跑的，但最终用户电脑可能只有核显，所以应用启动时我做了一次设备探测。用torch.cuda.is_available()判断，如果是GPU环境就把onnxruntime的ExecutionMode设置为CUDA，否则用CPU默认执行。

这个判断极其重要。我见过有人把代码包给同学后，对方一运行就报显存不足，实际是代码里固定写了cuda:0，而对方电脑根本没有NVIDIA显卡或者只有核显。自动适应设备后，同一份程序在不同配置的机器上都能跑，只是速度有差异，可用性大大提升。

6. 常见问题排查与避坑手册

6.1 训练阶段问题

Q1：loss正常下降但mAP一直为0。排查后发现类别编号从1开始而不是0。YOLO的cls_id必须从0开始，我的classes.txt写成了从1排列，训练的时候类别一直错位，检测结果自然全错。

Q2：batch-size=16时显存溢出。解决办法是开启梯度累积，或者把img-size降到480，或者换成更小的模型。如果你想先看效果，最快的是把batch-size降到4，然后一步步往上加，找到当前显存能承受的最大值。

Q3：过拟合明显，训练集mAP很高但验证集低。我加了早停patience=20，同时开启weight_decay=0.0005。早停的意思是验证集mAP连续20个epoch不提升就自动结束训练，既省时间又防止模型在最后阶段死记训练集。

6.2 界面与推理问题

Q1：关闭摄像头线程后程序卡死。原因是我在closeEvent里直接调用了线程的terminate，导致锁未释放。正确做法是设置一个停止标志位，让线程自然退出循环后再join。这是多线程GUI应用最常见的坑。

Q2：界面显示检测框非常慢。排查后是inference时默认用了GPU，但在CPU环境没有写device="cpu"，每次都在几秒超时后才回退。

Q3：图片拖拽进窗口无效。PySide6需要重写dragEnterEvent和dropEvent，用setAcceptDrops(True)开启。拖拽进来的是文件路径字符串，需要单独转换成QImage再去推理。

我把这些排查点整理成一个速查表，放在项目根目录的FAQ文件里，方便后来者直接查。实际交付给别人时，这个文档比代码注释有用得多。

6.3 提升检测精度的进一步手段

如果你嫌当前mAP不够高，最快见效的几点：第一，增加每类的图片数量，十类花最好每类超过2000张；第二，使用模型集成测试，把YOLOv8s和YOLOv8m的预测结果做NMS融合，mAP能提高两到三个点；第三，针对小花朵，把推理的img-size从640升到960，小目标召回率有明显提升，代价是推理时间翻倍。

模型集成听起来高级，其实实现不难。两个模型各自输出框和置信度，合并后做一次NMS，把置信度低的重复框去掉就行。我做下来，这种方案适合离线分析不追求实时性的场景。

7. 实际落地心得与后续扩展

做完整套系统后，我最大的体会是：目标检测项目真正的难点不在训练这一步，而在数据是否干净、界面与推理的耦合是否合理、部署环境是否一致。之前有个A同学拿着代码去自己电脑上跑，怎么都报错，后来发现是他电脑上装的是CPU版torch而代码里写了.cuda()。这类环境不一致问题在交付应用时几乎天天遇到，所以我的做法是应用首次启动时自动检测设备，并弹窗提示当前运行模式。

最后分享一个细节技巧：把PySide6的界面刷新和推理分离后，我还给摄像头预览加了一个轻量模式开关。打开之后每三帧只推理一帧，其余帧直接显示原画面。这样低配笔记本上也能实时跑，观众肉眼基本看不出延迟。像这种小的交互优化，往往比换大模型更能提升实际使用体验。

后续如果想扩展，可以往两个方向走：一是模型层面，加入更高精度的YOLOv8x或训练时引入更多数据增强，让复杂背景下的花也能检出来；二是应用层面，加上按花种类生成统计报表、识别结果导出Excel，做一个完整的智能花卉普查工具。这个项目麻雀虽小，但刚好覆盖了从数据集、训练、GUI、部署到打包的完整链路，很适合作为AI入门的综合性实战项目。