本文给出一套面向道路车辆智能追踪、车牌识别、测速、区域入侵和实时监控的可落地方案。结论基于截至2026年7月23日的官方模型、论文与部署资料。

一、先说推荐结论

对于“精度高、推理快、支持纯CPU、后续能工程化部署”这一目标，推荐采用：

最推荐的量产组合：

YOLO26n OpenVINO FP16 + ByteTrack + 车辆ROI内车牌检测 + PP-OCRv6-small-rec + 多帧OCR投票 + 道路平面Homography测速。

YOLO26是Ultralytics当前的新一代模型，采用端到端无NMS推理、轻量检测头和小目标感知训练策略。官方COCO数据中，YOLO26n为40.9 mAP、2.4M参数，CPU ONNX约38.9 ms；相较YOLO11n的56.1 ms更快。

二、为什么选择YOLO26，而不是YOLO11、YOLOv12或YOLOv13

1. CPU场景首选YOLO26n

官方模型数据：

YOLO26n比YOLO11n提高约1.4个mAP点，同时CPU ONNX延迟明显降低。YOLO26s精度更高，但对普通CPU来说，全链路实时性压力会明显增加。

YOLO26还提供P2小目标结构配置，适合远距离车辆和小车牌，但P2版本需要自行训练，没有直接发布对应的预训练权重。

2. 推荐的选择规则

普通办公CPU、低功耗设备

使用：

• YOLO26n
• 输入尺寸512或640
• OpenVINO INT8或FP16
• 只检测道路ROI
• 分析帧率控制在10～15 FPS

8核以上桌面CPU、单路1080p

使用：

• YOLO26n，640输入
• OpenVINO FP16
• 车辆检测每帧或隔帧运行
• OCR异步运行

高性能CPU、精度优先

使用：

• YOLO26s
• 640或768输入
• OpenVINO INT8
• 适合远景车辆较多、遮挡复杂的路口

不建议纯CPU直接使用YOLO26m/l/x，因为检测模型会占用过多时间，影响OCR、视频解码、报告和实时流输出。

三、完整系统架构

摄像头 / RTSP / 本地视频 │ ▼ 视频解码与帧缓冲 FFmpeg / GStreamer / OpenCV │ ▼ 道路ROI裁剪 │ ▼ YOLO26车辆检测（OpenVINO） │ ▼ ByteTrack跟踪 │ ┌───────┼───────────────┐ ▼ ▼ ▼ 轨迹管理 区域事件 测速 │ │ │ ▼ ▼ ▼ 车牌任务队列 入侵/越线事件 世界坐标轨迹 │ ▼ 车辆ROI内车牌检测 │ ▼ 车牌透视矫正、去模糊、增强 │ ▼ PaddleOCR识别＋多帧投票 │ ▼ SQLite / PostgreSQL │ ┌──┴─────────────┐ ▼ ▼ CSV/JSON导出 HTML报告 │ ▼ FastAPI / WebSocket / MJPEG / HLS

核心设计原则是：检测、跟踪、OCR、绘制和存储不能全部串行执行。

建议采用以下线程或进程：

1. 视频采集线程；
2. YOLO推理线程；
3. 跟踪与事件线程；
4. OCR工作队列；
5. 视频绘制与编码线程；
6. 数据写入线程；
7. Web服务线程。

这样OCR偶尔变慢时，不会导致视频画面卡顿。

四、车辆检测与ByteTrack方案

1. 检测类别

不要直接沿用完整COCO 80类，只保留交通相关类别：

car van truck bus motorcycle bicycle special_vehicle

如果业务需要，可以加入：

pedestrian tricycle construction_vehicle emergency_vehicle

类别越少，误检通常越容易控制，后处理也更简单。

2. ByteTrack为什么适合CPU

ByteTrack通过二阶段匹配利用高置信度和低置信度检测框，能够在遮挡时恢复部分轨迹；它不依赖额外的ReID神经网络，因此比带外观特征的BoT-SORT、DeepSORT或Deep OC-SORT更节省CPU。原论文在多个MOT基准中验证了低分检测框关联对轨迹连续性的提升。

Ultralytics当前也把ByteTrack定位为“最快、最简单、最低额外开销”的追踪起点；固定道路摄像机没有明显相机运动，正好适合ByteTrack。

推荐起始参数：

tracker_type: bytetrack track_high_thresh: 0.45 track_low_thresh: 0.10 new_track_thresh: 0.50 match_thresh: 0.80 track_buffer: 45 fuse_score: true

调整原则：

• 车辆漏跟较多：降低track_high_thresh；
• 虚假轨迹较多：提高new_track_thresh；
• 遮挡后ID容易丢失：增加track_buffer；
• 相邻车辆容易换ID：适当提高检测精度，并缩小match_thresh尝试范围；
• 摄像头晃动明显：改用BoT-SORT并启用相机运动补偿。

3. 不要按完整视频帧率分析

例如摄像头为25 FPS，可以：

• 视频显示保持25 FPS；
• 检测与追踪按12.5 FPS运行；
• 中间显示帧使用最近轨迹位置或卡尔曼预测；
• 事件时间使用真实时间戳，不使用处理帧序号。

道路监控通常不需要每秒分析25～30次，10～15次已经足以支持车辆计数、测速和区域事件。

五、车牌识别最佳方案

车牌识别不应直接对整幅画面调用PaddleOCR。最佳结构是：

车辆检测 → 车辆跟踪 → 从车辆框裁剪ROI → 在车辆ROI内检测车牌 → 透视矫正 → PaddleOCR只做文字识别 → 多帧结果融合

1. 车牌检测模型

推荐三种方式，按精度排序：

A. 四角点车牌模型，精度最佳

使用YOLO26n-pose自定义四个车牌角点：

左上、右上、右下、左下

通过四点透视变换生成标准矩形车牌，再送入OCR。它对倾斜车牌、路边斜视摄像头和大型车辆车牌效果最好。

B. YOLO26n-OBB

输出旋转框，标注成本低于四角点，能处理车牌旋转，但对严重透视变形不如四角点模型。

C. 普通YOLO26n检测框

实现最简单、速度最快，适合摄像头角度较正、车牌近似水平的停车场或收费站。

YOLO26当前原生支持检测、OBB和关键点任务，适合构建上述车牌模型。

2. PaddleOCR模型选择

最新精度方案

使用：

PP-OCRv6-small-rec

PP-OCRv6于2026年6月发布，提供tiny、small和medium三档；官方表示medium相较PP-OCRv5_server在检测和识别精度上分别提升4.6%和5.1%，并强化了端侧CPU推理。

车牌场景不需要完整的通用OCR流水线，因此建议：

• 不运行文档方向分类；
• 不运行通用文字检测；
• 不运行通用图片展开模型；
• 只使用rec识别模型；
• 根据车牌类型使用专用字符字典。

稳定低延迟方案

使用：

PP-OCRv5-mobile-rec

官方表中该模型大小约16 MB，高性能CPU识别推理约5.32 ms；适合作为当前成熟稳定的量产备用模型。

3. OCR不能每帧运行

正确做法是每个车辆轨迹维护“最佳车牌候选”：

评分可综合：

车牌检测置信度 × 图像清晰度 × 车牌像素面积 × 正视角程度 × 曝光质量

只在以下情况触发OCR：

• 新车辆轨迹出现；
• 车牌清晰度明显超过历史最佳；
• 距上次识别超过一定时间；
• 车辆即将离开识别区域；
• 识别结果置信度不足，需要补充样本。

每辆车通常识别3～8张高质量车牌图即可，不应识别几十帧。

4. 多帧车牌融合

不要简单取最高置信度单帧结果。推荐：

1. 对每帧结果做车牌格式校验；
2. 按字符位置进行加权投票；
3. 对容易混淆字符建立替换规则；
4. 保留原始结果和修正结果；
5. 至少两帧一致后确认。

常见混淆：

0 / O 1 / I 2 / Z 5 / S 8 / B

中国车牌还应加入：

• 省份简称约束；
• 新能源车牌长度规则；
• 警、学、挂、港、澳等特殊尾字符；
• 蓝牌、黄牌、绿牌对应格式；
• 双层车牌版式处理。

5. 训练数据

中国车牌建议使用：

• CCPD作为基础；
• CRPD补充道路监控、多车牌和复杂视角；
• 自己摄像机采集的数据作为最终微调集。

CCPD包含大量不同距离、旋转、倾斜、模糊和天气场景；CRPD则更接近实际电子监控和多车辆场景。

六、车速计算正确方案

1. 只知道相机高度和俯仰角并不够

要把像素位移转换为实际米数，至少还需要：

• 相机内参：焦距、光心；
• 镜头畸变参数；
• 相机外参或相机姿态；
• 道路平面；
• 世界尺度参考。

OpenCV的相机标定用于估计内参、外参和畸变参数；平面单应矩阵用于在图像平面与道路平面之间映射。

因此，推荐优先采用道路平面单应性标定，不要直接使用“像素距离×固定比例”。

2. 标定方法

在道路上选择至少4个已知世界坐标点，例如：

• 车道线角点；
• 停止线两端；
• 斑马线角点；
• 已知长度的车道标线；
• 路面测量点。

建立：

图像坐标 (u, v) ↓ H⁻¹ 道路坐标 (X, Y)，单位为米

车辆位置使用检测框的底边中心点：

p = ((x1+x2)/2, y2)

而不是矩形中心点。底边中心更接近车辆轮胎与地面接触位置。

3. 速度公式

设轨迹在道路平面中的位置为：

Pₜ = (Xₜ, Yₜ)

则：

v = 3.6 × ‖Pₜ - Pₜ₋ₘ‖ / (tₜ - tₜ₋ₘ)

结果单位为km/h。

不要使用相邻两帧直接计算，因为检测框会抖动。建议使用：

• 最近0.5～1.0秒轨迹；
• 中位数速度；
• 线性回归斜率；
• 卡尔曼滤波；
• Savitzky–Golay平滑；
• 异常加速度剔除。

Ultralytics也明确指出视觉测速精度依赖跟踪质量、分辨率、帧率和环境因素，属于估计结果。

4. 测速精度提高措施

• 使用视频PTS或单调时钟时间戳；
• 摄像头固定后禁止自动变焦；
• 先进行镜头畸变校正；
• 测速区域放在画面中下部；
• 车辆远端区域不测速；
• 不在弯道直接使用单平面模型；
• 分车道建立独立标定矩阵；
• 使用雷达测速仪或已知速度车辆做现场校准；
• 报告中显示“估计速度”，除非系统通过法定计量认证。

七、区域入侵与道路事件检测

区域检测使用多边形：

zone = [(x1, y1), (x2, y2), ..., (xn, yn)]

每个轨迹维护状态：

OUTSIDE ENTERING INSIDE LEAVING

建议使用车辆底边中心点判定，而不是检测框与区域是否相交。

事件规则：

加入连续帧确认和冷却时间，防止在多边形边界附近反复报警。

八、纯CPU部署优化

1. Intel CPU：OpenVINO首选

YOLO26可直接导出OpenVINO。官方资料显示OpenVINO在Intel CPU上可大幅降低YOLO推理时间。

部分官方参考数据：

这些数据是模型基准，不包括视频解码、预处理、ByteTrack、OCR、绘制、数据库和视频编码，因此不能直接视为完整系统FPS。

导出示例：

from ultralytics import YOLO model = YOLO("best_vehicle.pt") model.export( format="openvino", imgsz=640, int8=True, data="traffic.yaml", dynamic=False, batch=1, )

INT8校准集应包含：

• 白天；
• 夜间；
• 雨雪雾；
• 逆光；
• 不同道路；
• 远近车辆；
• 拥堵遮挡；
• 不同摄像机型号。

建议至少准备数百到数千张代表性图片，并在自有验证集上比较量化前后：

mAP50-95 Recall 小目标Recall 车牌漏检率 最终整牌识别率

2. AMD或通用x86 CPU

采用：

ONNX Runtime CPU Execution Provider

INT8优先使用QDQ格式的S8S8量化。ONNX Runtime官方把S8S8 QDQ作为x86 CPU平衡速度和精度的优先选择。

3. ARM CPU

树莓派、RK系列等纯ARM设备可使用：

NCNN

但车牌OCR和1080p视频解码可能成为瓶颈。低端ARM建议：

• 输入512；
• 只分析道路ROI；
• 检测5～10 FPS；
• OCR仅在车辆进入指定识别线时触发；
• 使用YOLO26n INT8或更轻量模型。

4. 最重要的CPU优化项

按收益排序：

1. 不在整幅图上运行PaddleOCR文字检测；
2. OCR按轨迹触发，不逐帧识别；
3. 车辆检测只处理道路ROI；
4. 模型只保留所需类别；
5. 使用OpenVINO或ONNX Runtime，不使用PyTorch作为量产推理后端；
6. batch size固定为1；
7. 固定输入尺寸，关闭动态shape；
8. 检测、OCR和编码异步执行；
9. 限制绘制刷新频率；
10. 禁止将每一帧检测结果同步写入磁盘；
11. 视频帧使用有界队列，发生拥塞时丢弃旧帧而不是无限堆积；
12. 每辆车只保存最佳车牌图和事件证据图。

九、训练方案

1. 车辆模型

预训练权重：

yolo26n.pt

建议数据组成：

• 50%～70%自有道路摄像机数据；
• BDD100K等公开道路数据用于扩充；
• 夜间、雨雾和强逆光必须单独覆盖；
• 对远端小车辆进行重点标注。

BDD100K提供多样化道路、天气、时间和驾驶环境，可作为车辆检测和跟踪预训练补充，但最终精度仍主要依赖目标摄像机数据。

训练建议：

imgsz: 640 epochs: 150-250 batch: 根据训练GPU显存 close_mosaic: 15 cos_lr: true patience: 40 cache: disk

增强需要控制力度：

适合：

• HSV亮度和色彩变化；
• 轻度模糊；
• 雨雾模拟；
• 曝光变化；
• 轻度透视；
• Mosaic；
• Copy-Paste远端车辆。

慎用：

• 大幅上下翻转；
• 过强旋转；
• 不符合道路视角的随机透视；
• 导致车牌文字变形的强增强。

2. 车牌模型

建议单独训练，类别可只有一个：

license_plate

如果使用四角点模型，则每个车牌标注：

bbox + 4 keypoints

训练图像优先来自车辆ROI，而不是原始完整1080p画面。这样车牌在输入图中占比更大，模型更容易学习。

3. OCR模型

在PP-OCRv6-small-rec或PP-OCRv5-mobile-rec基础上微调：

• 缩小字符字典；
• 使用本地车牌字体；
• 增加模糊、压缩、反光、污损；
• 加入双层车牌；
• 加入新能源和特殊车牌；
• 使用真实摄像机裁剪样本；
• 训练时保持车牌标准化高度一致。

最终指标应使用：

整牌准确率 字符准确率 有效车牌召回率 误读率 未知车牌拒识率

不能只看通用OCR字符准确率。

十、数据记录和导出设计

推荐数据库结构：

cameras sessions tracks track_observations plates events zones exports

核心记录字段：

{ "camera_id": "CAM_001", "track_id": 1824, "vehicle_class": "car", "first_seen": "2026-07-23T10:21:15.231", "last_seen": "2026-07-23T10:21:21.892", "plate_text": "京A12345", "plate_confidence": 0.962, "speed_avg_kmh": 48.3, "speed_max_kmh": 52.1, "zone": "north_lane_restricted", "event_type": "zone_intrusion", "snapshot_path": "events/20260723/1824.jpg" }

不要每帧存一张图。建议只保存：

• 轨迹首次出现图；
• 最佳车牌图；
• 入侵发生前后证据图；
• 超速或逆行关键帧；
• 必要时保存5～10秒事件视频片段。

CSV适合统计，JSON适合接口和归档，数据库保留完整关系。

十一、HTML报告内容

报告建议包含：

1. 摄像机和分析时间；
2. 总车辆数；
3. 车型分布；
4. 分时段流量；
5. 平均速度和速度分布；
6. 超速车辆；
7. 区域入侵事件；
8. 逆行或违停事件；
9. 车牌识别列表；
10. OCR低置信度记录；
11. 事件证据图片；
12. 模型版本和配置；
13. CPU、内存和平均处理FPS；
14. 数据导出下载入口。

技术组合：

Jinja2 Plotly或ECharts Bootstrap 嵌入式Base64小图或相对图片路径

生成报告时从数据库读取汇总数据，不应直接扫描运行日志。

十二、推荐项目技术栈

Python 3.11 OpenCV OpenVINO 2026.x Ultralytics YOLO26 ByteTrack PaddleOCR 3.7 NumPy Shapely或cv2.pointPolygonTest FastAPI Uvicorn WebSocket SQLAlchemy SQLite / PostgreSQL Pandas Jinja2 Plotly / ECharts FFmpeg / GStreamer

量产阶段建议逐渐把以下模块转为C++：

• 视频解码；
• OpenVINO推理；
• ByteTrack；
• 坐标变换；
• 视频绘制和编码。

Python保留用于：

• Web API；
• 数据管理；
• 报告；
• 配置；
• 模型管理。

十三、三套可选配置

方案A：纯CPU实时优先

YOLO26n，512或640 OpenVINO INT8 ByteTrack 普通车牌检测框模型 PP-OCRv5-mobile-rec 分析10～15 FPS OCR每

方案B：精度与速度平衡，最推荐

YOLO26n，640 OpenVINO FP16 ByteTrack YOLO26n四角点车牌模型 PP-OCRv6-small-rec 分析12～20 FPS 多帧车牌融合 Homography测速

适合：

• 城市道路；
• 路口；
• 厂区；
• 单路1080p；
• 需要车牌、速度和入侵检测的完整系统。

方案C：精度优先

YOLO26s，640或768 OpenVINO INT8/FP16 ByteTrack YOLO26s-P2或四角点车牌模型 PP-OCRv6-medium-rec 分析8～15 FPS

适合：

• 远距离车辆；
• 拥堵；
• 夜间；
• 遮挡复杂；
• 高性能12核以上CPU。

十四、一个重要的许可证问题

Ultralytics官方当前提供AGPL-3.0与Enterprise两种授权。其官方说明中，使用Ultralytics代码、模型、架构、训练流程或训练得到的模型构建闭源商业系统，通常需要遵守AGPL开源要求或购买Enterprise许可证。正式商用前应进行许可证和法务确认。

如果项目必须保持闭源且不购买Ultralytics商业授权，可考虑：

PaddleDetection PP-YOLOE / PicoDet + ByteTrack + PaddleOCR

PaddleDetection项目采用Apache-2.0许可证，并包含PP-YOLOE、PicoDet和ByteTrack等模块；不过模型代际、生态便利性和当前YOLO26的CPU精度速度组合有所不同，需要重新实测。

最终建议

直接采用以下路线启动项目最稳妥：

车辆：自定义YOLO26n，640输入，OpenVINO FP16 追踪：ByteTrack 车牌：车辆ROI内YOLO26n四角点检测 OCR：PP-OCRv6-small-rec，PP-OCRv5-mobile-rec备用 测速：相机内外参＋道路平面Homography 事件：底边中心点＋区域状态机 存储：SQLite起步，PostgreSQL量产 服务：FastAPI＋WebSocket＋MJPEG/HLS 优化：OCR异步、多帧投票、道路ROI、固定输入、批量数据库写入

这套架构比“单个YOLO直接检测车辆和车牌，再对每帧运行OCR”的方案更快、更稳定，也更容易在纯CPU上达到实时效果。

互动交流

最近组建了一个
AI技术学习交流群，主要分享人工智能、计算机视觉、深度学习、项目实战与部署经验，也欢迎大家交流学习中遇到的问题。感兴趣的朋友可以添加微信：hhhxy666666，备注
“AI”，即可申请进群

如有项目开发、技术咨询、系统定制或其他商务合作需求，也欢迎私信联系。

本文相关项目已开源： https://github.com/5758703/CV_PythonVue_TigerPro

如果项目对你有所帮助，欢迎在 GitHub 点一个Star
支持一下，也可以请作者喝杯咖啡。你的关注与支持，是项目持续更新和完善的动力！