车牌识别在视觉项目里属于那种“看起来简单做起来全是细节”的活儿。这篇是这个系列的第三篇主题是用OpenVION做一套车牌识别系统的训练与部署从数据准备、检测模型、字符识别模型训练到模型转换、端侧推理和后处理我会把整个链路完整过一遍重点讲实际项目中那些文档里不写、但是真正决定最终效果的关键点。先解释一个容易卡住新手的问题OpenVION是一套面向视觉推理场景的开源优化工具链不同版本的教程里叫法不统一有的写作OpenVINO有的直接叫视觉推理SDK。名字不影响核心流程关键是它能把训练好的模型做算子融合、低精度量化、计算图优化让模型在普通CPU或集成GPU上跑得更快。这套东西特别适合停车场闸机、园区门禁这类没有独立显卡、又要求低延迟推理的端侧场景。标题里统一用OpenVION这个叫法我下面所有步骤也按这个来。1. 内容整体设计与思路拆解1.1 车牌识别到底选端到端还是检测识别很多人第一次做车牌识别第一反应是找一个大一统的模型输入一张图直接把车牌号和位置一起吐出来。这种端到端方案看着省事实际上坑很多。车牌在整张图片里通常只占很小一块区域让一个网络同时学会找目标、定边界、读字符序列训练数据的构造和正负样本平衡都会变得非常麻烦稍微换个拍摄角度、换个光照环境精度就崩。我这次采用的是“检测识别”两阶段方案先用一个轻量目标检测网络把车牌区域框出来再用一个字符序列识别网络对裁剪后的车牌做文字识别。两个模型各自负责一件事检测模型只关心“车牌在哪”识别模型只关心“这块图里的字符是什么”问题定位清晰训练快迭代也快。工程上前者比端到端多一跳但对边缘设备来说这个取舍非常划算靠后处理优化和流水线并行完全可以吃掉多出来的那点延迟。从实际部署表现看两阶段方案在停车场这类场景里明显更稳。识别网络看到的永远是检测网络送来的、已经归一化好的车牌特写而不是光照混乱的全景图字符准确率自然会高不少。1.2 模型训练只是第一步OpenVION才是落地的关键训练一个能在测试集上跑到99%准确率的车牌识别模型在今天并不难难的是让它在客户那台只有CPU的小盒子上稳定跑起来。深度学习模型训练好之后直接拿原始框架的推理接口去跑性能往往没法看一个几十层的检测网络在通用框架里跑一帧可能要几百毫秒资源占用还高。OpenVION的核心价值就是把训练好的模型重新编译和优化。它会把计算图里的冗余节点干掉把多个小算子融合成一个大算子还能把算法精度从FP32压到FP16甚至INT8。打个比方模型训练好就像厨师做出一道好菜OpenVION做的是配餐和送餐的活——把菜装进保温盒、规划好路线、快速送到客户手里。菜本身不变但交付效率完全不同。这个优化对车牌识别尤其重要。停车场闸机、园区门禁这些地方设备算力有限有时候连独立GPU都没有全靠CPU硬算。没有OpenVION这层优化60帧的视频流根本处理不过来有优化之后单帧检测加识别能做到几十毫秒级别真正具备落地能力。1.3 整体技术链路设计整个项目我分成七个环节每一个环节踩坑点都不一样数据准备与标注收集不同光线、角度、车牌类型的图片标注车牌边界框和车牌字符串。检测模型训练用轻量目标检测模型微调出车牌检测器输出候选框。识别模型训练用LPRNet或CRNN训练字符序列识别器输入是裁剪好的车牌小图。模型导出把训练好的模型先转成ONNX统一计算图表达。OpenVION转换对ONNX模型做静态shape固定、算子适配生成优化后的中间表示。推理工程用OpenVION运行时加载模型完成预处理、推理、NMS后处理、CTC解码。业务联动把识别结果按置信度策略输出给道闸或门禁系统加确认机制。这套链路最关键的思维转变是不要训练完才考虑部署而要从数据标注阶段就想清楚“最终模型会跑在什么设备上”。比如网络输入尺寸、字符集、精度档位这些在后面改起来都伤筋动骨在前面定下来就非常便宜。2. 核心细节解析与实操要点2.1 检测模型别一上来就上大模型车牌检测本质是一个特定类别的小目标检测任务类别只有一类目标尺寸还不大。我用的是轻量检测模型路线从YOLOX-Nano、NanoDet这些轻量级网络里选一个做底座再拿自己的车牌数据微调。为什么不推荐用大号检测模型因为边缘设备部署时要考虑延迟和内存占用检测模型越大后面优化压力越大而车牌检测这类任务本身并不需要多强大的特征表达轻量模型做到百分之九十几的召回率完全够用。输入分辨率这里要特别讲一下。很多新手贪图快直接把输入压到320x320结果视频里稍远一点的车牌根本检不出来。车牌在整幅画面里属于小目标输入分辨率太小会把它的特征洗掉。我这次用640x640做检测输入推理时间和精度最平衡。如果你的现场相机离车道特别远甚至要提高到768或1024但每档提升都会让CPU推理时间明显上涨要自己权衡。标注规则也很有讲究。标注车牌框时不要把边界压得太紧稍微外扩一点让识别模型能看到车牌周围的一圈车身纹理这样裁出来的图不会把边缘字符切掉。我一般会让矩形框比车牌实际区域向外扩10%到15%。另外一张图里如果没有车牌干万不要硬标一个小框凑数负样本对检测模型的稳定性非常重要。2.2 识别模型LPRNet和CRNN怎么选识别模型我主要比较过LPRNet和CRNN。LPRNet是专门为轻量车牌识别设计的网络输入尺寸很固定比如高24像素、宽94像素输出的是字符序列概率配合CTC损失函数训练时不需要手动分割字符。CRNN则是通用文字识别的经典方案收敛更稳但参数和计算量都更大。在OpenVION转换这一步LPRNet有一个很明显的优势它结构简单算子种类少导出ONNX和后面的转换很少碰到不支持的算子。CRNN里面有双向循环网络导出时经常遇到动态shape和循环展开的问题转换链路上要多花不少力气。对于车牌识别这种字符数量固定的任务我最后选了LPRNet作为主力方案。字符集的设计直接决定识别上限。国内常见车牌的结构是“省份汉字字母数字”省份汉字有30多个字母加数字有34个左右整个类别数量大概70多类。实际训练时我会把容易混淆的字符做合并去重比如字母O和数字0、字母I和数字1在车牌里几乎没有区分的必要合并掉之后字符类别少了模型学起来更容易最终效果反而更好。2.3 转换、量化、端侧推理的参数选择模型训练好真正开始对接OpenVION时有几个参数是一定要提前想清楚的。第一个是静态shape。不要把模型导出成动态输入尺寸动态shape在OpenVION里虽然支持但性能和兼容性都会打折。车牌检测输入固定为640x640识别输入固定为24x94把batch固定为1转换时最省心。第二个是图像预处理对齐。这一步看起来不起眼却是最容易翻车的环节。训练时如果用的是OpenCV读图默认是BGR通道顺序归一化用的是某个mean和scale那么推理阶段也必须原样照做。很多人训练精度很高一上OpenVION就变成“什么都识别不出来”十有八九是RGB和BGR反了或者归一化参数没对上。第三个是精度档位。FP32是默认基准精度最稳FP16在绝大多数CPU平台上速度比FP32快精度基本无感INT8则需要额外的校准数据集用来统计激活值分布精度损失通常在1到2个百分点之间但速度提升非常明显。我的习惯是先跑FP32验证整条链路正确再上FP16最后才考虑INT8每一步都单独看准确率别一口气跳到INT8然后无从排查。3. 实操过程与核心环节实现3.1 环境准备我这次统一在Python环境下操作依赖很简单核心就几个包。如果你之前已经装过深度学习框架直接从现有环境开始也可以我不建议为了这个项目单独搞一个大而全的环境。# 创建虚拟环境避免包冲突 python -m venv lpr_env source lpr_env/bin/activate # 基础依赖 pip install opencv-python numpy # 训练用框架以PyTorch为例 pip install torch # OpenVION运行时注意不同版本导入名可能不同按实际安装为准 pip install openvion环境装好后先跑一个最简单的读取图片、打印张量shape的脚本确认运行时正常。这一步虽然简单但能提前暴露OpenCV版本、Python版本不兼容的问题不要跳过。3.2 数据准备与加载数据集我按标准结构组织一张图对应一行标注标注内容包括图片路径、车牌左上角坐标、右下角坐标、车牌字符串。这里我直接讲我自己用的目录组织方式非常简单实用dataset/ images/ img_0001.jpg img_0002.jpg labels.txtlabels.txt每行格式如下images/img_0001.jpg 120,340,420,510 某省A·D12345坐标对应车牌框的xmin, ymin, xmax, ymax车牌字符串里面省份部分用中文汉字表示。下面这段代码负责把标注文件读进来同时做基本的格式校验import os def load_labels(label_path): samples [] with open(label_path, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue parts line.split( ) img_path parts[0] box [int(float(x)) for x in parts[1].split(,)] plate_str parts[2] if len(plate_str) 6: # 车牌字符串一般7到8个字符太短大概率标注错了 continue samples.append((img_path, box, plate_str)) return samples数据增强这里要舍得花功夫。车牌识别面对的真实场景五花八门逆光、夜晚、倾斜、雨雾、运动模糊。我在训练检测模型和识别模型时都用了同一套增强策略包括随机仿射变换模拟车牌倾斜、亮度对比度抖动模拟不同光线、轻微高斯模糊模拟运动模糊、随机cutout模拟遮挡。增强的目的是让模型见过足够多的“脏”样本而不是只在干净图上自嗨。3.3 检测模型微调检测模型我不建议从零开始训练。直接在轻量检测网络的预训练权重上做微调几十分钟就能收敛。训练时输入尺寸640batch size取8到16初始学习率0.001用余弦退火调度。loss方面轻量检测网络自带框回归和分类loss不需要自己写。训练过程中我只看三个指标召回率、误检率和检测框的IoU质量。把测试集按场景拆成白天、夜晚、强光、雨天几组分别统计召回率如果某个场景明显偏低多半是训练样本里该场景不够需要补数据加再多的epoch也解决不了。3.4 车牌识别模型训练识别模型我用LPRNet结构输入固定为24x94的灰度图输出是字符序列概率。这里给出一个能跑的简化训练循环方便你理解整个数据的流转。字符集编码部分我做了简化处理实际项目中可以直接用列表映射。import torch import torch.nn as nn # 字符集省份汉字 大写字母 数字 # 注意这里省去了具体省份汉字列表实际按项目需要补齐 CHARS [_] [chr(i) for i in range(ord(A), ord(Z)1)] [str(i) for i in range(10)] char_to_idx {c: i for i, c in enumerate(CHARS)} idx_to_char {i: c for i, c in enumerate(CHARS)} def encode_label(text): return [char_to_idx[c] for c in text if c in char_to_idx] def train_one_epoch(model, dataloader, optimizer, criterion): model.train() total_loss 0 for images, texts in dataloader: # images: [B, 1, 24, 94]已经做好归一化 # 标签转成CTC格式CTC需要输入 [B, T] 和每个样本的真实字符长度 targets [encode_label(t) for t in texts] target_lengths torch.tensor([len(t) for t in targets], dtypetorch.long) targets_tensor torch.cat([torch.tensor(t) for t in targets]) logits model(images) # 输出 [T, B, num_classes] log_probs logits.log_softmax(2) loss criterion(log_probs, targets_tensor, torch.full((images.size(0),), logits.size(0), dtypetorch.long), target_lengths) optimizer.zero_grad() loss.backward() optimizer.step() total_loss loss.item() return total_loss / len(dataloader)CTC解码是另一个容易出错的地方。CTC输出序列会比真实字符长解码要做两步先把连续重复的字符合并再删掉blank占位符。def ctc_decode(pred): pred pred.argmax(-1) result [] prev None for p in pred: if p ! prev and p ! 0: # 0 为 blank result.append(idx_to_char.get(int(p), )) prev p return .join(result)训练LPRNet时我一般设置epoch为50到80学习率0.001AdamW优化器batch size 64。发现过拟合就把数据增强加重一点别急着加正则。3.5 模型转换与OpenVION部署实战模型训练完之后先导出ONNX。导出的时候要把所有动态轴都固定下来这是为了后面转换顺滑。检测模型固定输入为1x3x640x640识别模型固定输入为1x1x24x94。识别模型导出时如果用到了LSTM或GRU一定要把序列长度固定避免输出动态shape。import torch # 以识别模型为例假输入固定为 1x1x24x94 dummy_input torch.randn(1, 1, 24, 94) torch.onnx.export( model, dummy_input, lprnet.onnx, input_names[input], output_names[output], dynamic_axesNone # 固定所有维度不设动态 )拿到ONNX后进入OpenVION转换环节。命令行转换方式在所有平台基本一致openvion_convert --input lprnet.onnx --output lprnet_ir --input_shape [1,1,24,94] --data_type FP16转换成OpenVION中间格式后就可以写推理代码了。整个推理流程包含四步读取图片、预处理、跑两个模型、后处理。from openvion import Core core Core() det_model core.read_model(det_ir.xml) lpr_model core.read_model(lprnet_ir.xml) compiled_det core.compile_model(det_model, CPU) compiled_lpr core.compile_model(lpr_model, CPU) def infer_plate(frame): # 1. 检测车牌区域 det_out compiled_det([frame]) # 返回检测框 boxes nms(det_out) # 后处理NMS代码略 if not boxes: return None # 2. 取第一个车牌的裁剪图 x1, y1, x2, y2 boxes[0] plate_crop frame[y1:y2, x1:x2] plate_input preprocess_lpr(plate_crop) lpr_out compiled_lpr([plate_input])[0] # 3. CTC解码 plate_text ctc_decode(lpr_out) return plate_text我在实机上跑过一版某款四核CPU小板子上640x640检测加24x94识别单帧总耗时大概在70到90毫秒。这个速度已经能支撑每秒10帧左右的稳定处理如果后续做视频流再配合跳帧和流水线能扛住更多路并发。4. 常见问题与排查技巧实录4.1 检测框总是框不准这个问题我见过太多次。框偏大偏小、左右晃动、偶尔漏检原因基本集中在三个地方训练数据里车牌框标注太紧或太松导致模型对边界位置不敏感。解决办法是检查标注质量统一外扩比例重新标注。输入分辨率太低远处的车牌特征太弱。把检测输入从416提到640召回率通常立竿见影。NMS阈值设置不当候选框互相覆盖。车牌这类目标比较规整IoU阈值设0.45到0.5一般最稳太高容易出重复框太低会漏掉真车牌。如果检测框位置总是轻微偏移还有一个技巧训练时把车牌框做一点向外扩张比如5%到10%这样识别阶段裁剪得更宽松字符不容易被切到。4.2 车牌字符经常识别错识别模型字符错最常见的不是模型太弱而是输入到识别模型的图有问题。我排查的顺序是先看裁剪图里车牌本身是否清晰再看预处理有没有做错最后才怀疑模型容量。如果裁剪图里车牌被拉伸得比例失衡LPRNet这种固定尺寸输入的网络很容易懵。处理办法是等比缩放车牌图到目标高度剩余部分用灰色像素填充而不是直接强行拉伸到24x94。另一个高频原因是字符集里没有某些字符。比如新能源绿牌比蓝牌多一位字符如果训练时字符集和数据分布没覆盖绿牌识别结果就会错乱。所以数据准备阶段一定要把蓝牌、绿牌、黄牌按合理比例混在一起训练。字符混淆问题也要正视。字母O和数字0、字母I和数字1在图像上几乎一样如果训练集里这些字符都有模型的概率输出会在它们之间来回横跳。我的做法是直接合并类别把容易混淆的字符统一映射成同一个类别解码时再根据业务规则还原成合理结果。4.3 模型转换时直接报错OpenVION转换报错绝大多数原因是ONNX里有不支持的算子或者动态shape没处理干净。比如LPRNet如果用了双向LSTM导出ONNX时经常出现Sequence相关算子转换工具不一定支持。我的建议是干脆放弃循环网络那层改成卷积加全连接直接把序列长度方向拉平精度损失很小但转换稳定度大幅提升。另一个常见问题是用了一些第三方库里的自定义算子这类东西在训练时很爽一旦导出就露馅最好提前换成标准卷积、标准全连接实现。还有一个看起来像玄学、实际上是常识的错误转换时报内存错误。大模型转IR时如果中间表示文件特别大需要确保磁盘空间充足。我遇到过因为临时目录空间不够转换中途静默失败的情况排查了很久才发现是磁盘满了。4.4 推理速度慢CPU占用爆表模型部署之后速度不达标先从预处理开始查。很多人只盯着模型推理时间实际上OpenCV的缩放、颜色转换、归一化这些操作也非常耗时尤其是大分辨率原图直接resize到640每一步都可能吃掉几毫秒。优化手段我按投入产出比排序第一检测输入从640降到416如果场景里车牌不需要特别远距离识别速度立刻快30%以上第二把预处理从纯Python改成NumPy向量化操作避免逐像素循环第三做INT8量化前提是量化校准集要覆盖真实场景第四如果是多路视频流开多线程时注意设置CPU线程数OpenVION默认可能吃掉所有核心反而导致帧率不稳。实测下来一个四核CPU设备上FP16模型比FP32快大约15%到20%INT8比FP32快50%以上精度损失在一个百分点上下。这个收益基本决定了端侧项目必须上INT8或至少FP16。5. 从单图识别到视频流落地的几点取舍单张图识别跑通之后很多人会以为接视频流就是循环调接口那么简单实际上工程细节还有不少坑。车牌识别系统一旦接视频流我强烈建议不要每一帧都同时跑检测和识别。我的做法是先让检测模型以每秒5到10帧的频率跑只有检测到车牌的区域才裁剪下来交给识别模型。大部分场景里车是在移动的但车牌出现在画面中后往往会持续几十帧识别模型没必要每帧都跑跳帧处理能节省大量算力。多线程流水线也是必须的。相机采图线程、检测线程、识别线程、结果输出线程四个线程独立跑中间用队列解耦。采图线程只负责把帧塞进队列检测线程按固定频率消费识别线程只处理包含车牌的裁剪图。这样不会出现一个环节慢了整个系统卡死的情况。输出结果要加确认机制尤其是无人值守场景。我的经验是连续5帧识别出同一个车牌号且置信度都超过0.7才认为是稳定结果再控制道闸抬杆。单帧结果直接动作百分之百会遇到误报一套完善的确认机制能挡住绝大多数假阳性和偶然错字。这里也顺便说一下置信度的阈值。检测置信度和识别置信度要分开设。检测阈值设低一点比如0.3宁可多检出几个候选框也别漏掉真车牌。识别的置信度阈值设高一点比如0.7因为识别结果是直接对外服务的关键数据错一个字都可能引起投诉。我个人在实际项目里还有一个小习惯把OpenVION部署后的识别日志全部落盘车牌号、置信度、裁剪图、时间戳都记录下来。一旦现场反馈识别错了直接去日志里翻那一帧的裁剪图一秒定位问题是出在检测、识别还是业务规则的哪一层。没有这套记录出了问题基本靠猜非常痛苦。