前阵子做模拟项目X的时候我需要一个能自动识别车辆类型的模块用在停车场的出入口道闸车来了不仅要判断“有没有车”还要认出这是小轿车、SUV、面包车、卡车还是公交车。这套需求听起来简单真做起来牵扯的东西不少数据要从头整理模型要反复调最后还得给使用者一个能点按钮的界面。最后我选的是YOLOv10深度学习方案训练了一个车辆类型识别检测模型配了一套Python写的UI界面整个项目源码和模型都能直接拿去做二次开发。这篇文章就把整个过程的思路、参数和踩过的坑完整写一遍给要搭车辆检测系统的同学一个参考。先说明一下这里说的车辆类型识别本质上是一个目标检测任务而不是单纯的目标分类。因为在实际场景里车辆在画面里的位置是变化的我们必须先“框出”车的位置再判断它是哪一类。YOLOv10这类检测网络天然适合这个场景一次推理同时输出位置框和类别不需要额外接分类网络。下面我从方案选型、数据处理、训练、模型导出、UI集成和实测调优六个部分来展开。1. 从项目需求到方案选型为什么车辆类型识别用YOLOv101.1 先想清楚要识别的车辆类型不少人在项目一开始就容易犯一个毛病类别还没定清楚就急着下载模型跑demo。车辆类型识别看起来只有“车辆”两个字但细分方式可以差很多。我这次按停车和道闸场景的需求把类别定为小轿车car包括两厢、三厢轿车车身高度相对较低。SUVsuv包括城市SUV、越野车比轿车高、体量大。面包车van车头短、箱体方正常见于货运和客运。卡车truck包括轻卡、重卡车身长货斗明显。公交车bus车体明显比面包车大车窗线条平直。摩托车motorcycle两轮车辆目标小但必须单独归一类。这里有个经验类别别一上来就分太多比如把“货车”“半挂”“厢式货”“皮卡”全部拆开会导致样本量不够模型反而学不好。我最初只定了5类后面根据反馈又加了摩托车效果比较稳。如果你做的系统是用于高速卡口的可能还需要把“客车”和“货车”按座位数/轴数再细分那就是另一套标注逻辑了。1.2 YOLOv10相对前代模型的几个关键变化为什么选YOLOv10而不是直接沿用YOLOv8或者更老的一代我当时的判断主要基于部署成本。YOLOv10最大的一点改进是去掉了NMS非极大值抑制后处理。传统检测模型在输出时会生成大量重叠框必须用NMS把多余的框去掉而YOLOv10通过一致匹配策略在训练阶段就解决了这个问题推理时直接输出最终结果。这带来的直接好处是推理链更短延迟更低代码也更简单。另一个变化是模型结构上的优化。YOLOv10采用了更高效的梯度流传递方式在保持精度的前提下减少了计算量对小模型版本尤其友好。我比较了几种模型的体积和速度模型版本参数量约COCO精度约推理速度倾向YOLOv10n2.3M中等极快适合边缘设备YOLOv10s7.2M较好快适合普通CPU/核显YOLOv10m15.4M好中等适合消费级GPUYOLOv10l24.4M更好较慢适合服务器YOLOv10x29.5M最好慢适合高算力场景我最终用的是YOLOv10m。原因很简单我们场景里需要对摄像头画面做实时推理一张普通消费级显卡能跑到几十毫秒一帧精度又比小模型高不少属于均衡选择。如果你的目标平台是嵌入式设备比如树莓派或者工控机建议走YOLOv10n或者YOLOv10s路线。1.3 系统整体架构设计这个系统不是只训练一个模型就完事我把它拆成了五块数据准备收集车辆图片、清洗、标注、划分训练验证集。模型训练基于预训练权重做迁移学习得到车辆类型识别专用权重。模型导出把PyTorch权重导出成部署友好的格式方便用推理引擎加载。推理封装写一个统一的检测函数输入图片或帧输出类别、置信度和坐标框。UI界面用Python搭一个桌面界面让非技术使用者能选择图片、视频或摄像头画面直接看到检测结果和统计数据。这里我想强调一个容易被忽略的点模型训练和推理部署最好是分开的。训练阶段依赖完整的深度学习框架而实际交付给使用者时尽量把模型转换成轻量格式UI界面只负责调用推理接口这样整个系统不会因为训练环境缺失而跑不起来。2. 车辆数据集的收集、清洗与标注2.1 原始图片怎么收集和筛选模型是“吃数据”的车辆类型识别系统的效果上限很大程度上由数据集决定。我这次整理的数据包含大约1.2万张有效图片每类样本量尽量保持在2000张以上。图片来源主要有两个公开的车辆图像数据网上有不少开放下载的高速公路监控、停车场、交通场景数据集选那些带自然光变化、角度多样化的图片。实地拍摄补充我在模拟场地附近蹲了几次点用手机和普通摄像头拍不同时间段的车流专门补充夜间、逆光和雨天场景。这里要特别强调清洗流程。原始图片里经常混着大量废图完全模糊的、车辆占画面比例极小的、被栏杆/树木遮挡超过一半的、以及同一辆车连续几十帧的高度重复图。这些图片放进训练集只会浪费算力甚至拉低精度。我清洗之后直接删掉了大约15%的原始图片宁可少而精不要多而杂。2.2 标注与YOLO格式转换标注用的图形标注工具比较常规打开图片给每一辆车画一个尽量贴合车身的矩形框然后给框指定类别。矩形框最好贴着车的外轮廓不要把背景大片框进去也不要切掉车灯或后视镜那种“差不多就行”的框会让模型训练时反复纠结边界。标注完成后要转换成YOLO训练使用的txt格式。YOLO格式每一行代表一个目标class_id center_x center_y width height其中center_x、center_y、width、height都是相对图片宽高的归一化值。举个例子一张1920x1080的图片里某辆车的框左上角是(960, 200)右下角是(1200, 700)那么框宽是240高是500中心点是(1080, 450)转换后就是0 0.5625 0.4167 0.125 0.4630类别id从0开始编号对应我在配置文件里写的names顺序。标注完成后图片和txt文件要存放在同一目录下并且保持同名这样训练框架才能正确匹配。2.3 训练/验证集划分与数据增强数据集的目录结构我建议按下面的方式组织这是训练框架约定的常见结构datasets/vehicle/ ├── images/ │ ├── train/ │ └── val/ └── labels/ ├── train/ └── val/我按9:1的比例划分训练集和验证集没有单独设测试集因为验证集的指标已经足够反映模型真实表现。划分的时候要按“图片组”切而不是把所有图片随机打乱后一张一张分否则同一辆车在不同帧出现时会被同时分进训练和验证集造成数据泄漏验证精度虚高。数据增强方面我自己保留了几个常用组合水平翻转、亮度/饱和度微调、马赛克增强和随机缩放裁剪。马赛克增强对提高小目标检测能力很有帮助因为它把四张不同的图片拼在一起相当于让模型在更复杂的背景中学习。但这类增强在训练后期要适当减弱避免目标被拼得太过“抽象”导致模型在真实场景下适应不良。3. 训练阶段参数怎么定坑怎么躲3.1 环境准备与预训练权重训练环境方面我用的是Python 3.10配了一张普通消费级显卡显存12GB。安装深度学习框架的时候要留意版本匹配具体就不展开了。YOLOv10的源码包解压到工作目录后先安装依赖库再确认torch和cuda版本能够正常调用GPU用一个小推理demo验证环境通了再开始训练。权重文件建议直接用官方发布的预训练模型作为起点我用的是yolov10m.pt。这个权重在通用目标检测任务上已经学过大量基础特征我们只需要在其基础上做微调让模型学会区分车辆细分类别。从零开始训练不是不行但需要的数据量和训练时间都会成倍增加一般人没必要这么折磨自己。3.2 数据配置文件怎么写训练前需要写一个数据配置文件告诉训练框架数据集在哪里、有哪些类别。我的vehicle.yaml大概长这样path: /path/to/datasets/vehicle train: images/train val: images/val names: 0: car 1: suv 2: van 3: truck 4: bus 5: motorcycle有几个细节容易踩坑path一定写绝对路径或相对训练命令运行位置的正确路径写错的话训练启动后会提示图片加载不到。names里的类别顺序必须和标注txt里的class_id完全一致否则训练出来的模型预测结果会张冠李戴。不要忘了检查labels/train和images/train下的文件数量是否一致漏标的那部分图片虽然不会报错但会影响训练稳定性。3.3 训练参数这样设置更稳训练命令我用的是类似下面的写法yolo detect train datavehicle.yaml modelyolov10m.pt epochs300 imgsz640 batch16 patience50各参数的具体选择逻辑说一下imgsz640YOLO系列默认训练尺寸边长640x640。如果目标车辆在画面里普遍偏小可以试试896甚至1280显存够的话能明显提高小目标召回率。epochs300训练轮数。我实际训练时没有跑满300轮因为框架会自动判断模型不再提升时提前停止。patience50如果连续50轮验证集指标不再提升训练会提前结束这个机制能省下大量时间。batch16显存12GB时跑yolov10m比较稳。如果训练时显存溢出不要硬开大batch先把batch降到8或者把cache关掉。optimizerAdamW微调阶段我用AdamW比较多前期loss下降更快。如果你更想要稳定收敛可以用带动量的SGD学习率设置成0.01左右。3.4 训练过程盯住哪些指标训练过程中不要只看loss曲线更要关注验证集上的mAP50和mAP50-95。mAP50是预测框与真实框交并比超过0.5时算出的平均精度mAP50-95则在0.5到0.95之间取多个IoU阈值再平均后者更严格差距更容易反映模型的真实泛化能力。我习惯这样判断模型状态如果训练loss在降但验证mAP逐渐下降说明过拟合了优先减少训练轮数、增加增强力度或降低模型复杂度。如果训练loss和验证loss都比较高并且整体精度低先怀疑数据标注有问题而不是急着调参。如果某个类别的精度明显低于其他类别去检查这个类别的样本量和标注质量一般情况下是“摩托车”这类小目标样本不够或者框太大。我这边的结果比较理想训练到大概180轮时mAP50稳定在了93%左右mAP50-95在70%上下。对于车辆类型识别这种粗分类任务来说已经足够用了。4. 模型推理与导出把模型变成能用的服务4.1 用训练好的权重做一次推理训练完成后模型权重文件是PyTorch格式我把它单独放在weights/vehicle_type.pt路径下。推理脚本的调用方式非常直观# 以你使用的YOLO工具库为准通常是通过 YOLO(权重路径) 创建模型对象 model YOLO(weights/vehicle_type.pt) results model.predict(test_car.jpg, conf0.4, verboseFalse) for result in results: for box in result.boxes: cls_id int(box.cls[0]) conf float(box.conf[0]) xyxy [round(x, 2) for x in box.xyxy[0].tolist()] print(f类别: {names[cls_id]}, 置信度: {conf:.2f}, 坐标: {xyxy})这里的conf0.4是置信度阈值。默认的0.25在车辆场景下偏松经常出现把路牌、垃圾桶误判成车的情况。我实测调成0.4之后误检明显减少召回也没有明显下降。4.2 导出ONNX格式方便部署训练好的PyTorch权重直接交付给使用方有一个问题对方必须装一个带GPU依赖的深度学习环境这对很多人来说是劝退级别的要求。我的做法是导出成ONNX格式这样后续可以用轻量推理引擎去加载模型CPU也能跑流畅。导出很简单一行命令yolo detect export modelweights/vehicle_type.pt formatonnx imgsz640导出后你会在同目录下看到vehicle_type.onnx文件。ONNX的好处是模型结构固化了不依赖原始训练代码同时推理引擎做了大量算子优化。实测同一张图片在同样硬件条件下ONNX格式推理速度比原始PyTorch格式快大概20%-30%。使用ONNX格式时输入要做标准化预处理把图像缩放到640x640像素归一化到0到1然后按照模型要求的通道顺序送入。输出是一个二维数组每一行对应一个检测框包含类别id、置信度和框坐标。虽然手写后处理麻烦一点但终端部署的可控性更强。4.3 检测结果的后处理与车辆统计在实际业务里单纯把框画出来还不够系统需要知道“进来一辆什么车”。我在推理封装层里加了一个统计逻辑对每一帧图片执行检测。遍历所有检测框过滤置信度小于阈值的框。按类别进行数量统计同时用跟踪算法对目标ID去重避免同一辆车在视频连续帧里被反复计数。去重这个点特别重要。如果只是对单张图统计那叫“画面内车辆计数”如果想要“车流量计数”就必须跟踪同一辆车跨帧移动。我用的方案是在检测结果基础上接了一个轻量跟踪器用检测框中心点和框尺寸做匹配。更复杂的场景还可以接ByteTrack这类跟踪算法让车辆在遮挡后仍能保持同一个ID。统计结果用一个字典保存vehicle_count {car: 0, suv: 0, van: 0, truck: 0, bus: 0, motorcycle: 0}每次确认有新目标出现时对应类别加一。UI界面上能实时看到各类型车辆的累计数量。5. UI界面集成让非技术用户也能操作5.1 界面技术怎么选模型跑通了但整个系统不能只停留在脚本层面。项目交付时使用方最关心的不是模型精度而是界面好不好用能不能选一张图就看出来是什么车能不能打开摄像头实时识别数据统计能不能看清楚。界面技术路线我对比过几种技术路线优点缺点适合场景Qt的Python绑定桌面端体验好支持复杂布局打包方便开发量稍大界面样式需要调交付给固定客户使用的桌面工具Tkinter零额外依赖上手快界面简陋视频刷新体验一般内部小工具、演示demoStreamlitWeb端展示方便交互组件丰富实时视频流支持较弱并发处理麻烦快速原型、远程查看Gradio极简代码生成交互界面定制能力有限算法验证、临时演示我最终选了Qt的Python绑定来搭桌面界面。原因是我们需要在界面上同时展示原始画面和检测结果画布还要支持图片、视频、摄像头三种输入Qt的布局管理和信号槽机制比较顺手。5.2 核心界面代码界面整体结构分成两块左侧是操作按钮和类别统计信息右侧是检测结果展示区域。核心逻辑用一个MainWindow类封装。import cv2 from PyQt5.QtWidgets import (QMainWindow, QFileDialog, QLabel, QPushButton, QVBoxLayout, QWidget) from PyQt5.QtGui import QImage, QPixmap class MainWindow(QMainWindow): def __init__(self, model_path): super().__init__() self.model load_model(model_path) self.setWindowTitle(车辆类型识别检测系统) self.resize(960, 640) self.label QLabel(请选择图片或视频, self) self.btn_image QPushButton(选择图片, self) self.btn_video QPushButton(选择视频, self) self.btn_camera QPushButton(打开摄像头, self) self.btn_image.clicked.connect(self.select_image) self.btn_video.clicked.connect(self.select_video) self.btn_camera.clicked.connect(self.open_camera) layout QVBoxLayout() layout.addWidget(self.btn_image) layout.addWidget(self.btn_video) layout.addWidget(self.btn_camera) layout.addWidget(self.label) container QWidget() container.setLayout(layout) self.setCentralWidget(container) def select_image(self): path, _ QFileDialog.getOpenFileName( self, 选择图片, , Images (*.jpg *.png *.bmp) ) if not path: return frame cv2.imread(path) annotated self.run_detect(frame) self.show_frame(annotated)实际项目里按钮的样式、字体大小、画面自适应缩放这些细节都要花时间调。别小看这部分工作使用方看到的第一眼就是界面一个干净专业的界面能省掉大量沟通成本。5.3 图片、视频、摄像头三种输入的统一处理为了让界面代码不随着输入源不同而疯狂膨胀我把检测逻辑统一封装成一个函数def run_detect(self, frame): results self.model.predict(frame, conf0.4, verboseFalse) annotated frame.copy() for result in results: annotated result.plot(line_width2, labelsTrue) return annotated图片和视频调用过程的区别只在于“帧从哪来”图片读一次视频循环读。这里要注意视频逐帧推理时不能直接在UI线程里跑否则画面会卡到没法看。我用QTimer定时从视频里取帧把推理放到工作线程里推理完成后再通过信号回到主线程刷新UI。摄像头输入同理。打开摄像头后循环读取画面、推理、显示。因为实时性要求高我建议把输入分辨率控制在640x640以内并且对画面做适当裁剪或缩放让每帧推理耗时稳定在50毫秒以内体验才跟得上。6. 实测效果与后续升级思路6.1 不同场景下的实测表现系统做完后我拿了一批真实场景的视频做压力测试结果如下场景表现情况说明白天正常光照很好几乎无漏检车辆轮廓清晰类别区分稳定夜间有路灯尚可小目标易漏摩托车和远处轿车容易搜不到雨天玻璃反光中等误检率上升车窗反光会形成类似车身的特征逆光场景中等部分车辆发黑阴影区域对比度低需要预处理增强车辆密集拥堵较好但帧间ID易跳变检测能出框统计计数需要跟踪配合夜间是一个绕不开的痛点单纯调模型效果有限。我后面在推理前加了一个自适应直方图均衡化预处理对夜间低对比度画面有明显改善代价是每帧增加了大约两三毫秒处理时间可以接受。6.2 踩过的坑与排查过程这里写几个我印象比较深的坑。第一个坑是标注框不贴合的问题。有段时间模型在验证集上表现不错但一上真实场景就疯狂乱框。后来查了上百张图发现不少标注框把后视镜切了一半还有的把相邻两辆车框在一个矩形里。这类问题不会让训练报错只会让模型学得“模棱两可”。解决方法是删掉这些坏标注重新校准一遍所有类别的框精度立刻上升了几个点。第二个坑是训练后期小目标丢失。在拥堵场景里摩托车和远处的轿车经常检测不到。排查时发现训练框架在最后的epochs会关闭马赛克增强而我的摩托车样本又偏少导致模型对这类小目标学得不到位。解决办法是补充了摩托车夜间样本同时适当降低置信度阈值到0.3召回率上来了。第三个坑是视频推理卡顿。最早我是直接在主线程里做逐帧推理界面像幻灯片一样。后来改成双线程方案主线程负责UI响应工作线程负责取帧和推理再用队列缓冲界面立刻流畅。6.3 后续可扩展的方向这套系统现在还只是完成了“是什么车”这一层判断。我后续已经在计划做几个扩展方向加入车辆轨迹跟踪和进出口匹配实现真正的“驶入驶出”统计。增加车牌识别模块把车型信息和车牌绑定形成一条完整的车辆通行记录。按颜色细分比如同时识别车身颜色和车型在找车场景下很有价值。把模型量化到更低精度再换成更轻量的部署方式让系统可以在不带GPU的工控机上跑。做这个项目最深的体会是车辆类型识别系统真正的难点往往不在模型本身而在数据质量、前后处理和工程化交付。YOLOv10让检测模型的门槛降得很低但要把一个demo变成别人也能上手的系统需要花的心思一点都不会少。如果你也在做类似项目建议先用小模型把整条链路跑通再回来优化精度这样至少能避免“模型还没训好、工程也写不下去”的尴尬局面。