简介面向计算机视觉与智能交通领域的实战型资源基于YOLOv8完成车牌检测和字符识别全流程适配交通监控、电子收费、车辆管理等场景既适合初学者从零搭建系统也支持研究者与工程师部署优化。压缩包共55个文件约32.93MB包含Jupyter Notebook代码、pt模型权重、yaml配置、PB模型、mp4演示视频、jpg/png测试图片及requirements依赖清单覆盖训练、推理、展示所需的核心文件。教程部分完整拆解数据集准备、模型训练、性能评估等环节并对光照变化、拍摄角度、遮挡等复杂条件下的识别处理做了说明可帮助理解多尺度特征融合与字符分割识别等关键技术提升系统鲁棒性和识别率。当前已有298人学习整体是一份可直接运行、便于按需调整的完整车牌识别项目跟随教程既能掌握从数据准备到模型部署的完整链路也能将方法迁移到其他检测识别任务中。1. 从车牌检测到车牌识别这个实战项目到底在解决什么问题拿到车牌识别-基于YOLOv8实现车牌检测车牌识别算法-附项目源码详细流程教程这个标题首先要厘清一个最常见的认知偏差车牌识别不是一步到位的。你在停车场看到道闸抬杆那一刻背后其实是两个独立模型在串联工作——先用YOLOv8把画面里的车牌框出来再把框出来的那块小图送去字符识别模型最终输出粤B12345这样的文本。这个项目标所以叫优质项目实战核心价值就是把这两步拆开、跑通、调好而不是给你一个黑匣子直接吐结果。做这件事的人通常有两类一类是要交毕设/课设的学生需要一套能演示、能讲清楚原理的完整链路另一类是搞安防、智慧停车、门禁系统的工程师想拿YOLOv8替换掉老旧的传统图像处理方案。无论哪类你都需要自己标注数据、训练检测模型、再关联识别模型最后串成一条能跑的推理管线——这正是这个项目的全部内容。接下来我会按实际动手的顺序把检测、识别、避坑、部署逐层拆开讲。2. 让 YOLOv8 学会找车牌选型理由、数据集准备与三行命令开训2.1 为什么是 YOLOv8 而不是 YOLOv5 或传统图像处理先回答最实际的问题做车牌检测用YOLOv8到底图什么。早年间做车牌检测主流方案是颜色分割加形态学操作——蓝色的车牌在HSV空间里找色块再根据宽高比、面积筛候选区。这套方法在固定角度、固定光照的道闸口还能用一旦遇到夜间大灯直射、车身颜色和车牌接近、或者车牌倾斜超过15度检测率掉得让你怀疑人生。YOLOv8把这件事变成了一个回归问题输入整张图输出框的位置、大小和置信度并且天生就是端到端训练不需要你手工设计特征。和YOLOv5相比YOLOv8的改进在于C2f模块替换了C3模块特征融合和梯度流动更顺检测头换成了Decoupled Head分类和回归分支分开收敛更稳。对车牌这种目标小、长宽比固定、密集出现在画面中下部的场景v8的召回率普遍比v5高两到三个点——这不是玄学是结构变化带来的实打实收益尤其是蓝牌这种强纹理目标。选型上还有一个实际考量ultralytics这个库生态完整度太高了。从数据划分、训练参数到模型导出ONNX/TensorRT/OpenVINO全用Python API和命令行搞定比起YOLOv5那套需要手动改一堆yaml的流程对新手友好得多。后面你做rk3588或jetson部署时直接用官方导出的engine文件就完事。2.2 数据集怎么来CCPD 下载、自标数据的目录结构要求检测模型再强没有数据也是空中楼阁。车牌检测的公开数据集首推CCPDChinese City Parking Dataset它收集了国内各大城市的停车场实拍图包含蓝牌、黄牌、绿牌新能源以及不同光照、角度、模糊程度。这些图带的是JSON格式的标注框但ultralytics训练要的是YOLO格式的txt文件——每行一个目标格式为class x_center y_center width height坐标全部归一化到0到1。如果你是自己拿手机去停车场拍或者用行车记录仪截帧那就要用到LabelImg或Labelme做手工标注。这里有个很多人第一次会踩的坑LabelImg保存的VOC XML格式不能直接喂给YOLOv8得写脚本转换成txt。转换脚本逻辑很简单核心就四步读XML里的object标签→拿bndbox里的xmin,ymin,xmax,ymax→算出中心坐标和宽高→除以图片宽高做归一化。我给个现成的转换脚本这是整个项目里第一个抄了就能跑的代码块。import xml.etree.ElementTree as ET import os def voc_to_yolo(xml_path, out_dir, class_names): tree ET.parse(xml_path) root tree.getroot() img_w int(root.find(size).find(width).text) img_h int(root.find(size).find(height).text) lines [] for obj in root.iter(object): cls_name obj.find(name).text if cls_name not in class_names: continue # 跳过未定义的类别 cls_id class_names.index(cls_name) box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) x_center (xmin xmax) / 2.0 / img_w y_center (ymin ymax) / 2.0 / img_h width (xmax - xmin) / img_w height (ymax - ymin) / img_h lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) if lines: txt_name os.path.splitext(os.path.basename(xml_path))[0] .txt with open(os.path.join(out_dir, txt_name), w) as f: f.write(\n.join(lines)) class_names [plate] # 你标注的类别名 xml_folder annotations/ out_folder labels/ os.makedirs(out_folder, exist_okTrue) for xml_file in os.listdir(xml_folder): if xml_file.endswith(.xml): voc_to_yolo(os.path.join(xml_folder, xml_file), out_folder, class_names)这段脚本有个关键参数是class_names你标注的时候类别叫什么这里就必须对应什么否则训练时类别索引错位模型会学到一堆垃圾特征。输出目录的txt文件必须和图片同名放在同一级目录下ultralytics才认。我一般还会在转换后随机抽查三五张图把txt的归一化坐标乘以图宽高画回图上看一眼框是否贴合车牌——这一步能筛掉90%的标注坐标错乱问题。数据准备好后目录结构严格按这样摆dataset/ ├── images/ │ ├── train/ # 训练集图片 │ └── val/ # 验证集图片 ├── labels/ │ ├── train/ # 对应的yolo格式txt │ └── val/注意训练集和验证集的图片、标注文件要一一对应图片和txt必须同名。CCPD原始数据是JSON标注如果你直接下CCPD还需要解析JSON格式转成上述结构建议优先找已经转好YOLO格式的版本省得在数据清洗上消耗掉大半天——这些脏活占比不低但收益和投入完全不成正比。2.3 训练命令、关键超参和第一次收敛怎么看数据就位后训练本身在ultralytics里被压缩成了三行命令。我不推荐直接敲yolo predict或yolo train这种魔法指令而不去了解参数含义至少第一次跑要认真看一眼控制台输出。以下是我常用的训练启动方式在项目根目录执行yolo train dataplate.yaml modelyolov8n.pt epochs100 imgsz640 batch16 patience20 projectruns/detect nameplate_exp1这条命令里modelyolov8n.pt是加载COCO预训练权重做迁移学习对车牌这种单一类别目标用nano版本就够了推理速度快且精度损失不大dataplate.yaml是你的数据配置格式很简单就三行path: dataset/、train: images/train、val: images/val再加一个names列表patience20是早停轮数超过20个epoch验证集mAP不再提升就自动停imgsz设640是因为CCPD原始图分辨率普遍在720p以上640做训练尺寸既能保留车牌细节又不至于把显存撑爆。我一般会在训练日志里盯两个指标一个是mAP50-95对车牌检测来说因为目标小且纹理单一mAP50涨得很快但mAP50-95如果卡在0.8上不去说明框的定位精度不够稳定常见原因是大角度倾斜车牌没标好另一个是box_loss它应该在前30个epoch快速下降之后缓慢波动如果box_loss一直高位震荡且val曲线跟着乱跳先去看是不是标注框边界超出了图片范围——这是YOLO格式最典型的异常归一化坐标大于1或小于0训练不会报错但模型永远学不好。2.4 检测效果评估别只看mAP要看错误样例图训练结束后很多人看一眼mAP就宣布完工这是个坏习惯。mAP是全局指标它掩盖了雨雾天气、逆光、车牌与车身同色这三类典型失败案例。评估阶段我建议直接把验证集里置信度最高但预测错误的图片翻出来看yolo val跑完会生成val_batch0_pred.jpg这种拼接图我不用它我在验证集里挑了三张最难识别、极端角度或严重反光的图单独跑预测检查框的偏移方向和大小。出错集中在横向偏移说明特征图分辨率或anchor设置有问题出错集中在漏检说明样本多样性不够需要再去补充夜间图像。这一步虽然花不了多少时间但在后续接识别模型时能省下大量排查时间——如果你检测框本身就偏了半个字符宽度后面车牌字符识别无论多精准也会跟着错绝大多数端到端准确率上不去的问题根子都在检测这一环。3. 车牌识别模型串联字符分割与整图识别两条路怎么选3.1 常见方案对比LPRNet、PaddleOCR 与字符分割的取舍车牌检测把车牌从大图里抠出来之后接下来要把苏A·D12345这串字符读出来。这一步有三个主流的落地做法。第一条路是字符分割加单字符分类也就是传统的切字-认字方案。先通过二值化和连通域分析把车牌切成七个字符区域再逐一送进一个七类分类器。这个方案最大的问题是受边缘、铆钉、边框干扰严重蓝牌的白色字体和车牌底色对比度高还能切新能源绿牌的字符间距更近、还有渐变底色切字时频繁翻车。除非你处理的都是国标蓝牌且现场相机安装位置固定否则我不推荐这条路。第二条路是LPRNet这类免分割的轻量识别网络。它用CNN加CTC loss直接对整张车牌图输出字符序列不需要切字符训练数据只需要标注车牌字符串是什么不要框。LPRNet在CPU上跑一张车牌图耗时在5毫秒内工业界用得相当广泛。第三条路是直接上PaddleOCR这类通用OCR模型用PP-OCRv4的文本识别模型来认车牌。好处是省去自己训练识别模型的功夫PaddleOCR自带车牌识别方向分类器对倾斜车牌鲁棒性很好坏处是通用OCR字典里车牌字符有限遇到使领馆港澳这类特殊牌照可能会出现字典里没有的字输出乱码。对这个项目来说我倾向推荐LPRNet或PaddleOCR——具体选哪个取决于你对依赖库的容忍度LPRNet是自包含的一套PyTorch推理代码就能跑通适合毕设展示PaddleOCR胜在开箱即用但部署包体积偏大。下面我把LPRNet的核心结构和一个可跑的推理脚本放出来帮助你把注意力集中在如何把检测结果接进来这件事上。3.2 LPRNet 的模型怎么搭定义网络、加载权重与把车牌图转成字符LPRNet本质上是一个轻量化CNN加双向LSTM加CTC decode的组合。CNN部分负责提特征把输入的高度归一化到24像素的车牌图变成序列特征LSTM对序列做建模输出每个时间步的字符概率分布最后CTC解码把概率分布变成最终字符串。它的实现不做逐字符分割这是它抗干扰强的根本原因。import torch import torch.nn as nn class LPRNet(nn.Module): def __init__(self, class_num, dropout_prob0.5): super(LPRNet, self).__init__() self.backbone nn.Sequential( nn.Conv2d(3, 64, kernel_size3, stride1, padding1), nn.BatchNorm2d(64), nn.ReLU(inplaceTrue), nn.MaxPool2d(kernel_size3, stride1, padding1), # 保持尺寸 nn.Conv2d(64, 128, kernel_size3, stride1, padding1), nn.BatchNorm2d(128), nn.ReLU(inplaceTrue), nn.MaxPool2d(kernel_size3, stride2, padding1), nn.Conv2d(128, 256, kernel_size3, stride1, padding1), nn.BatchNorm2d(256), nn.ReLU(inplaceTrue), nn.Conv2d(256, 256, kernel_size3, stride1, padding1), nn.BatchNorm2d(256), nn.ReLU(inplaceTrue), nn.MaxPool2d(kernel_size3, stride2, padding1), ) self.sequence_layer nn.LSTM(256*3, 128, bidirectionalTrue, num_layers2, batch_firstTrue) self.fc nn.Linear(256, class_num) self.dropout nn.Dropout(dropout_prob) def forward(self, x): x self.backbone(x) # [B, 256, 3, W] B, C, H, W x.size() x x.view(B, C*H, W) # 把高和通道合并变成序列 x x.permute(0, 2, 1) # [B, W, C*H] x, _ self.sequence_layer(x) # [B, W, 256] x self.fc(x) # [B, W, class_num] return x跑推理时你需要加载训练好的权重或者从release仓库里直接下载LPRNet在合成数据上预训练好的模型做一次前向就能拿到字符串。关键的预处理细节有三个输入图必须灰度化还是保留RGB高度统一resize到24宽度按比例缩放保持宽高比不被破坏通常取94像素左右。下面是推理脚本的核心逻辑。import cv2 import numpy as np import torch CHARS 0123456789ABCDEFGHJKLMNPQRSTUVWXYZ # 车牌字符表注意无IO def preprocess_plate(plate_img): h, w plate_img.shape[:2] target_h 24 target_w int(w * target_h / h) resized cv2.resize(plate_img, (target_w, target_h)) # 归一化并转成CHW加batch维度 img resized.astype(np.float32) / 255.0 img torch.from_numpy(img).permute(2, 0, 1).unsqueeze(0) return img def decode_ctc(output): # output: [1, W, num_classes] pred torch.argmax(output, dim2) # 每个时间步取最大概率类别 pred pred.squeeze(0).cpu().numpy() result [] prev -1 for p in pred: if p ! prev and p ! len(CHARS): # 跳过重复和blank if p len(CHARS): result.append(CHARS[p]) prev p return .join(result) model LPRNet(class_numlen(CHARS) 1) # 1是CTC blank model.load_state_dict(torch.load(lprnet_weights.pth, map_locationcpu)) model.eval() plate cv2.imread(cropped_plate.jpg) # yolov8检测结果裁剪出的车牌图 input_tensor preprocess_plate(plate) with torch.no_grad(): logits model(input_tensor) plate_number decode_ctc(logits) print(f识别结果: {plate_number})decode_ctc函数里最重要的逻辑是去掉连续重复字符——CTC算法天然会输出BB22222这种重复串中间如果有blank隔开则说明是真实重复否则合并成一个字符。这个去重规则几乎是新手最容易搞错的地方去掉所有重复会误伤京A·A1234这类合法的重复字符正确做法只用blank分割。判断标准就是看预测序列里相同字符之间是否有blank间隔。3.3 端到端方案检测框裁剪尺寸对识别准确率的影响不管是LPRNet还是PaddleOCR识别模型的输入都是检测框裁剪出来的图片。有些人训练完检测模型直接把原始框的坐标裁剪出来送去识别结果准确率掉到85%以下。原因不在识别模型而在检测框的裁剪质量。车牌识别模型对字符边缘的完整性极度敏感检测框如果紧贴字符边缘哪怕差两三个像素字符就会被切掉一个边模型立刻误判。我的做法是在服务YOLOv8检测结果给识别模型之前对检测框坐标做一次padding扩展。常见做法是宽高各向外扩10%到15%具体扩多少取决于检测框本身是否紧贴车牌边缘如果检测框压得比较紧就多扩一点然后再做一次透视矫正把倾斜的车牌拉直。YOLOv8检测框本身是轴对齐矩形遇到倾斜车牌框内依然有大量背景和邻车区域硬裁剪会直接把识别模型的精度拉低。标准做法是检测模型再跟一个车牌角点回归或者直接做一次四角定位但更偷懒的做法是用OpenCV的minAreaRect对检测框内的二值图找最小外接矩形利用最小外接矩形的角度做仿射变换矫正到水平。这两个细节做完识别准确率能提升五个点以上而且是那种看得见的稳定提升——但绝大多数项目根本没有这层处理而是让识别模型硬扛旋转效果自然差。我们把这一步做到位后面的优化空间才谈得上。4. 完整推理管线打通与 4 个高频踩坑点排查4.1 从图片到车牌号的完整串联检测、裁剪、识别、后处理一段代码走通前面两章分别处理了检测和识别这一章把它们接成一条真正的流水线解决工程上能不能稳定跑的问题。import cv2 import torch from ultralytics import YOLO class PlateRecognizer: def __init__(self, det_weights, rec_weights, devicecpu): self.det_model YOLO(det_weights) # 加载yolov8检测模型 self.rec_model LPRNet(len(CHARS)1) # 你的识别模型 self.rec_model.load_state_dict(torch.load(rec_weights, map_locationdevice)) self.rec_model.eval() self.device device def recognize(self, img): results self.det_model(img, conf0.45, iou0.5)[0] plates [] for box in results.boxes.xyxy.cpu().numpy(): x1, y1, x2, y2 [int(v) for v in box] pad_x int((x2 - x1) * 0.12) # 外扩12%避免切字符 pad_y int((y2 - y1) * 0.12) x1 max(0, x1 - pad_x) y1 max(0, y1 - pad_y) x2 min(img.shape[1], x2 pad_x) y2 min(img.shape[0], y2 pad_y) plate_img img[y1:y2, x1:x2] plate_img self._deskew(plate_img) # 矫正倾斜 plate_num self._recognize_plate(plate_img) plates.append((box, plate_num)) return plates def _deskew(self, plate_img): gray cv2.cvtColor(plate_img, cv2.COLOR_BGR2GRAY) _, thresh cv2.threshold(gray, 0, 255, cv2.THRESH_BINARY cv2.THRESH_OTSU) contours, _ cv2.findContours(thresh, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) if not contours: return plate_img rect cv2.minAreaRect(max(contours, keycv2.contourArea)) angle rect[-1] if angle -45: # 修正角度方向 angle 90 angle if abs(angle) 5: # 只有角度大于5度才矫正 h, w plate_img.shape[:2] matrix cv2.getRotationMatrix2D((w//2, h//2), angle, 1.0) plate_img cv2.warpAffine(plate_img, matrix, (w, h)) return plate_img def _recognize_plate(self, plate_img): input_tensor preprocess_plate(plate_img) with torch.no_grad(): logits self.rec_model(input_tensor) return decode_ctc(logits)这段管线代码里有两个调参重点。第一个是conf0.45这个检测置信度阈值设太高会漏检模糊车牌设太低会把车身上的某品牌logo误检成车牌建议在你自己验证集上扫一遍0.35到0.6之间的阈值画出准确率召回率曲线再定。第二个是pad_x和pad_y的扩展比例检测框本身比较松的时候扩10%比较紧的时候扩15%以上具体数值看你的检测框泄露情况如果扩得太多邻近车牌的字符会被带进识别图反而造成误识别。4.2 避坑4 个拉低准确率的高频问题与定位方法第一个高频问题识别结果是乱码或固定输出同一串字符。现象很明显——不管送什么车牌进去输出永远一样。这大概率是OCR网络没有正确加载或模型权重与字符表不匹配先去检查CHARS字典顺序和训练阶段是否一致尤其是训练时用了增强的字符集而推理时只用了部分典例是0和O、1和I的处理。定位方法很简单单独用几张测试车牌图直接输入到识别模型绕开检测环节看是否复现同样问题。第二个高频问题单张图有多个车牌的漏检尤其远小目标。CCPD数据里很多停车场入口的图片远处有七八辆车近处一辆大车占了半个画面。此时YOLOv8默认anchors能覆盖小目标但在640分辨率下远处的车牌只有20像素见方特征传到深层已经丢失大半。解决思路是先用完整大图跑一次检测再对置信度低于阈值的区域做一次放大重检——即在原图中把检测框扩展2倍后resize至640再送一次模型。这个两阶段检测虽然耗时翻倍但对停车场卡口这种多车同时出现的场景召回率提升非常明显。第三个高频问题蓝牌和绿牌混淆。新能源车牌识别成蓝牌原因通常有两个——标注数据里绿牌占比太少模型本质上没见过绿牌或者识别模型训练的字符表里没有区分。解决方法是统计你的训练集里蓝绿牌数量如果比例超过5比1最简单的办法是先用颜色直方图判定车牌底色直接走分支处理而不是指望检测模型自己学会区分。第四个高频问题推理速度慢得没法上线。很多新手把det_model初始化为YOLOv8m或YOLOv8lCPU上单帧要200到300毫秒叠加识别就掉到1帧以内。我先解释规划思路如果目标是实时视频流至少10帧每秒以上油箱里燃油不够要留出优化余量。先量化瓶颈在检测还是识别再对症下药。检测部分换YOLOv8n或做TensorRT导出识别部分用ONNX Runtime替换PyTorch原生推理通常这两步就能快4倍以上。注意TensorRT第一次运行要花一两分钟构建engine文件这个耗时只有一次属正常损耗。5. 环境配置并不玄学CPU 和 GPU 两条路线的最省心搭法5.1 CPU 路线Ubuntu 20.04 无 NVIDIA 显卡怎么把环境一次装对标题对应的项目场景里有大量读者是笔记本用户手里只有CPU。网上很多教程直接跳过CPU适配导致新手卡在环境搭建这一步就放弃了。其实YOLOv8在CPU上跑迁移学习训练完全可行只是速度慢一些——用YOLOv8n在四核CPU上训练100个epoch的CCPD子集大概耗时三到五小时这完全可以接受。推理时CPU单帧检测耗时在100毫秒左右对图片和离线视频完全够用实时视频流的话得配合跳帧或降低分辨率处理。CPU版环境搭建就这么几条命令不需要装CUDA和cuDNN省掉最容易出问题的环节conda create -n plate python3.9 -y conda activate plate pip install ultralytics opencv-python torch torchvision --index-url https://download.pytorch.org/whl/cpu--index-url指定的是纯CPU版PyTorch的下载源实测能比默认源省下3GB多余下载。装完后用import torch; print(torch.cuda.is_available())验证输出False是正常的——说明你走的是CPU通道千万别以为装错了。推理时如果遇到torch.backends.cudnn相关的报错是因为某些库默认按GPU环境初始化用torch.device(cpu)显式指定设备即可绕开。5.2 GPU 路线GTX 1660 Ti 这一档显卡的显存与训练建议GPU用户中GTX 1660 Ti是相当有代表性的一块卡6GB显存比上不足比下有余。用这块卡训练YOLOv8nbatch size设置16没问题但如果盲目上到32几乎必然报CUDA out of memory。做法很简单显存不够时优先降batch其次是降imgsz到480再其次考虑梯度累积。这里有个隐性问题——在6GB显存下跑batch设小会导致BN层统计量波动训练震荡比大batch更明显。解决手段是让batch最低不低于8如果8还爆显存就用nano模型加冻结前10层迁移学习而不是硬扛更大的模型。推理阶段1660 Ti跑YOLOv8n单帧耗时约8到10毫秒加识别模型总共不超过15毫秒30帧视频毫无压力。这个性能段位也决定了部署策略你在1660 Ti上调好的参数迁移到rk3588或jetson设备时模型不用变只需把推理引擎换成各自的加速格式。反过来如果你一开始就用volov8l训练在边缘设备上铁定跑不动。选nano还是small不是看训练时准确率多高而是看你目标部署设备的算力天花板在哪。常见做法是训练用nanomAP50达标后直接项目交付追求更高精度时切small或medium但升档后要复测推理耗时不能拍脑袋。6. 从模型到产品用 OpenVINO 给 CPU 推理提速三倍的方法前面把检测和识别都跑通了最后一个环节是让这个管线能真正用到实际场景里——不管是实时的道闸系统还是离线视频批量处理。对CPU用户来说最实用、改动最小的加速方案是OpenVINO。它能把PyTorch模型转换成一个中间表示利用CPU的AVX指令集和内部优化把推理速度提升三倍左右。在CPU上YOLOv8n用纯PyTorch跑是100毫秒一帧导出到OpenVINO后能压到30到40毫秒识别部分同样受益LPRNet这种小模型更是接近零成本加速。做法分两步第一步把YOLOv8导出为OpenVINO格式yolo export modelbest.pt formatopenvino imgsz640导出成功后目录里会出现best_openvino_model/里面有.xml和.bin两个文件这就是OpenVINO的模型文件。推理时把ultralytics的加载路径从.pt换成这个目录即可代码几乎不用动from ultralytics import YOLO # 加载OpenVINO格式模型推理接口和之前完全一致 det_model YOLO(best_openvino_model/) results det_model(test.jpg, conf0.45)LPRNet的转换稍微繁琐一点需要先把PyTorch模型转成ONNX再用OpenVINO的模型优化器转成IR格式。这个转换过程中的一个隐藏大坑是动态维度——ONNX导出时如果不固定输入尺寸OpenVINO会为每个不同尺寸重新编译一次模型反而更慢。最佳做法是在torch.onnx.export时把输入宽度固定到一个你实际用到的值比如94或120这样OpenVINO只用编译一次模型推理延迟最稳。就我实际操作的经验用OpenVINO后的Pipeline最爽的地方不是单纯快而是CPU占用率曲线变得平稳——纯PyTorch推理时CPU占用会周期性飙到满负荷OpenVINO则始终在一个较低且稳定的水位对同时跑着Web服务的设备来说友好得多。这个项目的收尾工作到此也就做完了。回想我自己第一次做车牌识别把大把时间耗在调LPRNet字符表的顺序上因为字符索引对不上训练出来的模型永远输出乱码当时不懂把模型输出的参数和训练时的字典逐项对齐直到第二天才意识到是推理脚本里少了加blank的那一位。这段经历让我养成了习惯接任何OCR或序列识别模型时第一件事先把字符表和CTC解码器打出来核对看一眼解码输出的中间结果是不是符合预期再谈准确率优化。把这条经验也分享给你——检测模型的坑是数据质量识别模型的坑是字符字典错位把这两道坎迈过去车牌识别这个项目就算真正落地了。希望帮到你。本文还有配套的精品资源点击获取