简介面向毕业设计、智能交通和监控场景的道路车流量检测系统基于Python与YOLOv8算法实现支持车辆识别、计数与流量统计附带的模型和数据集可直接运行省去从零搭建的繁琐。压缩包共307个文件约155.1MB主要包含Python源码、pyc编译文件、YAML配置、模型权重pt和onnx以及测试视频和图像从代码、配置到数据均完整覆盖。系统代码结构清晰、注释详尽内置训练好的YOLOv8模型和推理脚本用户无需深入了解模型训练细节即可完成部署多个测试视频与样例图片可用于验证不同交通场景下的检测效果也方便修改阈值、更换权重等二次开发。对于正在毕业设计的学生或需要快速落地车流量检测的开发者这是一份能参考完整工程流程的实用资源有利于缩短开发周期。目前已有88人学习下载值得关注。1. 道路车流量检测拿到这套YOLOV8代码后先想清楚四件事路侧摄像头装好之后最烦人的往往不是硬件而是软件。检测模型白天准、晚上漏同一辆车在连续帧里框体跳来跳去数出来的车流量一会儿多一会儿少根本不敢拿去做报表。这套基于 Python 与 YOLOV8 的道路车流量检测系统属于典型的开箱即用交付完整代码、训练好的模型权重、数据集一次给齐加载模型后对视频逐帧检测再叠加计数逻辑输出车辆数。它解决的是从“能画出目标框”到“能把车辆数数准”的最后一公里适合做交通流量统计、路口设备验证、课程设计和论文实验的人。在跑 demo 之前先想清楚四件事模型权重从哪来、检测之后怎么把目标串成轨迹、计数按线还是按区域、统计数据交给谁用。这四个问题对应着系统的四个层次也是这篇文章要拆开讲透的主线。2. 车流量系统的架构拆解检测、跟踪与计数为什么要分层一个典型的车流量检测系统不是“把 YOLO 跑起来就行”。很多人第一次拿到类似完整代码时习惯直接运行 detect.py 或 main.py看到屏幕上出现框就以为任务完成。真正跑过路侧视频的人都知道单帧检测结果和流量统计需求之间隔着一道鸿沟你要的是“每小时每个方向通过多少辆车”而检测器只在一帧一帧地告诉你“这一帧里有一辆车”。交通流量统计对连续性、方向属性、时段稳定性都很敏感这也是我把系统拆成检测、跟踪、计数三层的根本原因。每一层各管一件事哪一层掉了链子都能单独定位不至于整个系统一起翻车。2.1 检测层只看单帧YOLOV8先给出“哪里有车、是什么车”检测层负责的事只有一件输入一帧图片输出这帧里每个目标的位置和类别。YOLOV8 输出的每个结果包含矩形框坐标x1, y1, x2, y2、类别置信度、类别名称在车流量场景里通常是 car、bus、truck 这几类。这套系统里“训练好的模型”就落在这层weights 目录下的 best.pt 是验证集上表现最好的权重last.pt 是最后一次迭代的权重。我拿到交付包时习惯直接加载 best.pt因为它的泛化表现经过验证集筛选用于新视频推理时可信度更高。这里要提醒一点YOLOV8 的检测输出默认是归一化坐标还是像素坐标取决于你用的是哪个接口。用 results.boxes.xyxy 拿到的是像素坐标直接画在帧上不用换算用 results.boxes.xyxyn 拿到的才是归一化坐标。很多人在计数逻辑里把归一化坐标和像素坐标混用导致跨线判断永远不触发这是检测层最常见的低级错误。检测层本身是单帧独立的不依赖前后帧信息因此 CPU 或 GPU 都能跑。但帧率受模型尺寸、输入分辨率和推理后端制约。后面第 3 章会专门讲环境配置和参数因为同样一个 best.pt在 GTX 1660 Ti 上和在纯 CPU 机器上的表现可能是两个极端。2.2 为什么是YOLOV8而不是YOLOv5选型理由写出来车流量检测不是非得用 YOLOV8YOLOv5、YOLOX 甚至更老的 Faster R-CNN 都能做但 YOLOV8 在“落地易用性”上明显占优。第一它采用 anchor-free 结构不需要为不同车道、不同车型预设锚框尺寸训练脚本里少了一大堆调参步骤。第二主干网络换成 C2f 结构neck 沿用 FPNPAN 的路径聚合思路配合 Detect head 的 Decoupled 设计分类和回归分支互不干扰小目标回归更稳。网络上能找到非常清晰的 YOLOV8 网络结构图对照结构图去理解 head 输出张量的含义比对着黑盒调参快得多。第三ultralytics 的训练管线极为成熟数据集准备成 YOLO 格式后一个 data.yaml 就能切换数据集开始训练。这也是标题里“数据都有”含金量最高的地方拿这套数据重新训练、验证、甚至迁移到自己的路口视频成本都远低于从零开始标注。第四生态工具丰富比如可视化热力图可以直接观察模型关注的是车身还是背景要做 head 改进的话YOLOV8 的模块化设计也让替换 C2f、Attention 层变得可控。选型也有边界。YOLOV8 有 n/s/m/l/x 五个尺寸对应模型参数量和推理速度完全不同。用 GTX 1660 Ti 这种 6GB 显存级别的显卡跑 n 或 s 可以做到视频实时跑 l 或 x 就只能离线抽帧分析。系统代码里如果默认加载的是 x 版本而你只有 1660 Ti先别急着改代码建议先看权重文件名对应的模型尺寸再决定要不要换小模型重训。2.3 一个完整交付的文件布局权重、配置、脚本和数据之间的关系拿到一套完整代码先别急着运行。我一般先把项目结构过一遍确认入口文件、配置文件和权重文件各自在哪。常见布局如下vehicle-count-system/ ├── weights/ │ ├── best.pt # 验证集上精度最高的权重 │ └── last.pt # 最后一次训练迭代的权重 ├── datasets/ │ ├── images/train/ # 训练图片 │ ├── images/val/ # 验证图片 │ └── data.yaml # 类别名、路径与类别数配置 ├── config/ │ └── counting.yaml # 计数线、ROI区域、置信度阈值等参数 ├── detect.py # 单视频检测入口 ├── track.py # 带目标跟踪的计数入口 ├── train.py # 重新训练脚本 └── requirements.txt # Python 依赖清单这个布局有几处值得留意。data.yaml 里 nc 和 names 必须与模型训练时一致否则加载权重后类别对不上输出全是乱码类别名。config/counting.yaml 放的是业务参数比如计数线位置、ROI 区域、置信度阈值这些参数不应该写死在 Python 源码里否则换一个路口就要改代码重新跑。requirements.txt 则记录了依赖版本先按它装环境装完再跑省掉一半环境问题。这类系统还有一个血泪经验Python 脚本对运行路径敏感。很多人在别的目录下执行“python vehicle-count-system/detect.py”结果相对路径全部失效模型加载不成功。正确做法是先 cd 到项目根目录再运行或者脚本内部使用 Path(file).parent 定位项目根路径。这一步做好后面所有文件引用都不会因路径问题翻车。2.4 分层的收益换模型、调参数、加车道都只需要动一小块检测、跟踪、计数三段分离带来的最大收益是维护成本低。检测层只输出目标框和类别跟踪层只负责把同一辆车在时间轴上串起来计数层只关心边界线和方向判断。如果以后想换更强的小目标检测器比如切到 RT-DETR 或自有模型只需要替换检测层接口跟踪和计数代码不动。如果要加一个车道只需要在 counting.yaml 里增加一条计数线不用动检测代码。这种分层结构也方便你自己做验证先单独测检测精度再单独测跨线计数的误差来源定位问题不会像一团乱麻。3. 让YOLOV8在本地跑起来环境配置、模型加载与关键参数标题承诺“可以直接使用”但直接使用的前提是环境匹配。这一章把从零搭环境到跑通第一段视频的完整路径写清楚你照着做就能在这台机器上复现系统行为。如果你已经能跑通检测可以跳过 3.1重点看 3.3 的参数怎么影响道路场景。3.1 先搭环境Python版本、CUDA、torch与ultralytics的版本搭配YOLOV8 的运行核心是 ultralytics 库它依赖 torch 做张量计算。最常见的环境问题不是代码错而是 pip 装了 CPU 版 torch导致 GPU 完全没被利用。我常用的一套组合如下软件推荐组合说明Python3.8 或 3.103.8 兼容第三方库最多3.10 也能稳定运行CUDA11.8对应 torch 的 cu118 预编译版本显卡驱动520 及以上驱动版本决定 CUDA 运行时能否生效torch2.0.x 或 2.1.x必须先于 ultralytics 安装防止自动拉 CPU 版ultralytics8.2.x自带 YOLOV8 训练、验证、导出全套能力以下是创建环境并安装依赖的完整命令我习惯先用 conda 隔离环境避免污染系统 Python。conda create -n vehicle python3.10 -y conda activate vehicle pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics8.2.0 python -c import torch; print(torch.cuda.is_available())这段命令的逻辑顺序很关键。先装 torch 再装 ultralytics因为 ultralytics 安装时如果检测不到 torch会自动安装 CPU 版本等你跑推理时才发现 GPU 利用率一直是 0%。最后一行 python -c 的作用是验证 CUDA 版 torch 是否生效输出 True 说明 GPU 可用输出 False 就要检查显卡驱动或 conda 环境是否激活。如果这台机器没有独立显卡或者显卡显存低于 4GB建议只装 CPU 版 torch。代价是分辨率 640 的视频流推理帧率通常在 2 到 5 帧每秒只能做离线视频分析做实时车流量统计不现实。这里也顺便回答一个高频问题gtx1660ti 跑 yolov8 到底行不行答案是跑 n 和 s 模型能做到 25 到 40 帧每秒跑 m 模型勉强实时跑 l/x 模型就掉到 10 帧以下了。3.2 用训练好的模型跑第一段视频检测推理的最小代码环境就绪后最小验证代码只需几行。把权重路径和视频路径替换成你本地的实际路径下面这段源自 ultralytics 的标准调用方式可以直接单文件运行。from ultralytics import YOLO # 加载训练好的权重best.pt 是验证集效果最好的模型 model YOLO(weights/best.pt) # 对视频逐帧检测saveTrue 会把结果视频保存到 runs/detect 目录 results model.predict( sourcedata/videos/road_camera.mp4, conf0.25, # 置信度阈值低于该值的框会被丢弃 iou0.45, # NMS 的 IoU 阈值控制重叠框的合并 imgsz640, # 输入图片缩放到 640x640 device0, # 使用 GPU 0没有 GPU 改成 cpu saveTrue, viewFalse, ) # 遍历每一帧的检测结果打印类别和置信度 for frame_index, r in enumerate(results): if r.boxes is None: continue print(fframe {frame_index}: {r.boxes.cls.tolist()}, {r.boxes.conf.tolist()})这段代码里model.predict 的每个参数都会显著影响道路场景的表现。conf0.25 是通用默认值在远距离、夜间场景经常要调到 0.15 以下才不漏检iou0.45 控制 NMS 合并车流密集时如果两条车身贴得很近IoU 过高会把两辆车合并成一个框这时反而要把 iou 调低到 0.3。imgsz640 保持默认即可追求小目标召回可以把输入分辨率提高到 960 或 1280但帧率会明显下降。提示如果你只想验证模型能不能用先用一张包含多辆车的图片跑 detect 即可把 source 参数改成图片路径几秒钟就能看到检测框输出。3.3 三个影响车流量结果的关键参数conf、iou与imgsz的正确设置道路视频的检测场景和通用目标检测不一样背景是固定的路面目标是大量同类车辆因此参数调优要围绕“不漏检、不合并、不抖动”三个目标展开。下面这张参数表是我在实际路口视频上常用的调参起点参数场景推荐取值说明conf白天、近景卡口0.3 到 0.4高阈值过滤误检适合车道固定的场景conf夜间、远距离0.1 到 0.2夜间特征弱阈值太高会漏掉暗光下的车iou车流量稀疏0.5 到 0.6框重叠少可以用更高阈值保证框的完整iou车流密集团队0.3 到 0.4防止多辆车框体贴合时被 NMS 合并成一辆imgszGTX 1660 Ti 实时分析640帧率优先满足大多数场景imgsz需要看清小目标960会把远端车辆放大适合路口远端计数参数设置有一定玄学成分同一个置信度阈值在不同光线、不同相机高度下表现差异很大。我的做法是先用默认参数跑 100 帧观察统计漏检和误检各占多少再决定往哪个方向调。比如夜间漏检多优先降低 conf白天误检多优先提高 conf 并检查训练数据里是否缺少对应时段的正样本。系统运行时这些参数都应放在 counting.yaml 里改配置即可生效不必每次都改代码。4. 从检测框到车辆数虚拟线圈与目标跟踪的计数实现系统真正的业务输出是车辆数而不是检测框。这一章给出两种最常见的计数实现一是纯检测框的虚拟线圈方案适合固定车道的场景二是基于目标跟踪的跨线计数适合多车道、车辆变道频繁的场景。两种方案各有适用边界先把原理讲清再给可以直接改的参考代码。4.1 虚拟线圈计数一条计数线与中心点的跨线判断虚拟线圈是最直观的计数方式原理是在画面里画一条或多条横向计数线每次检测到车辆中心点越过这条线就计数加一。实现成本最低不引入额外的跟踪依赖适合车道固定、车辆直行比例高的卡口场景。下面这段代码展示核心逻辑实际使用时建议把参数抽到配置文件中。import cv2 from ultralytics import YOLO model YOLO(weights/best.pt) cap cv2.VideoCapture(data/videos/road_camera.mp4) LINE_Y 480 # 计数线的 y 坐标画面从上到下递增 count 0 last_center {} # 记录上一帧每个目标中心点 y 坐标 while cap.isOpened(): ret, frame cap.read() if not ret: break results model.predict(frame, conf0.25, imgsz640, device0, verboseFalse) boxes results[0].boxes for box in boxes: # 取目标框的中心点像素坐标 x1, y1, x2, y2 box.xyxy[0].tolist() cx (x1 x2) / 2 cy (y1 y2) / 2 key f{cx:.1f} # 上一帧在线上面这一帧位于线下面视为正向通过 if key in last_center and last_center[key] LINE_Y and cy LINE_Y: count 1 last_center[key] cy # 在画面上画出计数线和左上角计数结果 cv2.line(frame, (0, LINE_Y), (frame.shape[1], LINE_Y), (0, 0, 255), 2) cv2.putText(frame, fcount: {count}, (10, 30), cv2.FONT_HERSHEY_SIMPLEX, 1, (0, 255, 0), 2) cv2.imshow(vehicle count, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()这段代码的计数逻辑依赖 key 的稳定性而 key 取了中心点的 x 坐标这是一种简化处理。真实场景中车辆在画面中持续移动x 坐标每帧都在变直接照搬到生产环境会导致同一台车被重复计数或漏计。更稳妥的做法是先判断目标属于哪个车道再在车道内判断跨线。车道划分可以按 x 坐标范围预先定义比如左侧车道 x 小于 640右侧车道 x 大于等于 640然后分别维护各自的 last_center 字典。参数方面LINE_Y 的取值决定计数的时机线越靠近画面底部车辆被完整检测的概率越大但越晚计数线越靠近画面顶部响应越早但远端车辆小、检测稳定性差。常见做法是先跑一帧静止图片人工标出车道和计数线的像素坐标再写入配置。4.2 加一项目标跟踪为什么计数不容易翻倍纯虚拟线圈方案在车辆变道、两车并排、检测框抖动时计数会乱。更稳的做法是给每个检测目标分配一个稳定的 ID让同一辆车从进入画面到离开画面都维持同一编号计数时只在首次跨线或最后离开 ROI 时加一。ultralytics 内置了 ByteTrack 支持调用方式非常简洁。from ultralytics import YOLO model YOLO(weights/best.pt) cap cv2.VideoCapture(data/videos/road_camera.mp4) LINE_Y 480 track_data {} # track_id - 上一帧中心点 y counted_ids set() # 已经跨线的 track_id while cap.isOpened(): ret, frame cap.read() if not ret: break # persistTrue 表示跨帧保持 IDtracker 指定用 bytetrack 配置 results model.track(frame, persistTrue, trackerbytetrack.yaml, conf0.25, iou0.45, imgsz640, device0, verboseFalse) boxes results[0].boxes if boxes is None: continue for box in boxes: # 跟踪模式下每个目标都有唯一 ID if box.id is None: continue track_id int(box.id[0]) x1, y1, x2, y2 box.xyxy[0].tolist() cx (x1 x2) / 2 cy (y1 y2) / 2 prev track_data.get(track_id) # 只有该 ID 从未计数过且首次跨线时才加一 if prev is not None and prev LINE_Y and cy LINE_Y and track_id not in counted_ids: counted_ids.add(track_id) track_data[track_id] cy这段代码的关键在计数器集合 counted_ids。同一个 track_id 只会被计数一次即使车辆在跨线后停下来、倒车再跨一次也不会重复计数。相比纯检测框方案它天然解决了重复计数问题。tracker 参数指向 bytetrack.yaml该文件位于 ultralytics 安装目录的 cfg/trackers 下里面可以调 track_buffer 和置信度匹配阈值。ByteTrack 的处理策略值得解释一句它对低置信度检测框并不直接丢弃而是先保留并尝试与已有轨迹匹配这样车辆临时被遮挡或特征减弱时轨迹不容易断裂。车流量场景里一辆大货车挡住后方车辆是常态用 ByteTrack 的断点续跟能力比 DeepSort 更省心。如果你手里的代码没有内置 track 模式可以自己维护一个基于 IoU 的简单关联器代价是需要处理更多的 ID 切换计数精度会下降。4.3 统计结果落地CSV字段设计与方向区分计数最终要落到数据文件里供报表或下游程序使用。最常见的输出格式是 CSV每一行对应一次有效通过记录。下面是我建议的字段设计字段含义示例timestamp帧时间或 Unix 时间戳1710000000.00lane_id车道编号0track_id目标跟踪 ID12direction通过方向1 正向-1 反向1class_name车辆类别carconfidence最后一次检测的置信度0.87direction 的判定与计数线类似如果上一帧 cy 小于下一帧 cy说明目标向下移动定义为正向反之向上移动定义为反向。实现上只需要在跨线判断时同时比较前后帧 y 坐标大小。写入 CSV 的代码可以简单使用 Python 标准库的 csv 模块每条记录一行最后按时间排序做聚合统计。处理长时间视频时不建议对每一帧都执行检测和跟踪。常见做法是跳帧处理比如每 3 帧跑一次推理跨线判断仍然按处理帧计算。这样在 1660 Ti 上可以把 640 分辨率的视频推到 30 帧每秒以上的处理速度计数误差不会明显增大因为车辆从进入画面到跨线通常要经过几十帧跳两帧不会造成漏计。跳帧后要注意 track 的 persist 仍在有效只是输入帧率降低跟踪器对与运动速度的容忍度需要适当调大 track_buffer。5. 车流量检测的避坑与排查漏检、重复计数与角度问题再好的模型和代码落到真实路口都会遇到训练数据里想象不到的情况。这一章写的是我在道路视频上反复踩过的坑每一条都按“现象、原因、解决”给出经验你可以直接对照排查。5.1 现象夜间漏检严重开远光灯的车反而丢了框夜间场景是检测模型集体翻车的高发区。现象是对向车道的车开着远光灯驶近时镜头里一团白亮检测框不是贴地就是直接消失远处没有路灯的路段整车藏在暗色里置信度全部低于阈值。原因有两个层面。一是训练数据里白天图片占绝大多数模型没见过大光比环境二是夜间目标边缘模糊特征响应弱默认 conf0.25 直接把低分框过滤掉了。解决思路分三步先降置信度阈值夜间运行时 conf 调到 0.1 到 0.15把低分框保留下来再交给跟踪器去判断因为跟踪器可以利用时序信息把单帧噪声过滤掉。第二训练阶段做数据增强在训练脚本里加大 HSV 增广的亮度和饱和度扰动模拟夜间的色偏和大光比。第三如果夜间流量本身就是业务重点建议单独采集夜间数据补训一个夜间专用权重白天用 best.pt晚上切换另一个权重两个模型并行加载运行时按时间戳自动切换。5.2 现象同一台车从画面一端到另一端被计数两次重复计数是最容易被业务方质疑的问题。现象是视频里明明只有一条车流最终统计数却比实际多出 20%而且翻倍发生在车辆长直行时不是变道场景。原因往往不是检测层而是跟踪层断链车辆经过画面中某个区域时被大型车辆遮挡或正好跨过帧间运动过大的位置ByteTrack 丢失了原轨迹重新生成新 ID计数逻辑会把新 ID 当作另一辆车再计一次。解决思路是先确认断链位置在运行日志里打印每个 track_id 的生命周期找出丢失集中的区域。然后把 bytetrack.yaml 里的 track_buffer 从默认值调大比如从 30 帧调到 60 帧让目标短暂消失后仍然能匹配回原轨迹。另一个有效手段是降低跨线区域的计数阈值只在目标真正离开 ROI 时计数而不是跨线瞬间计数给跟踪器更多时间确认 ID。5.3 现象摄像头架得太高或太斜框体贴地类别也开始混路侧摄像头经常装在立杆或高楼上俯视角大车辆在画面里是顶视图或接近顶视图。现象是检测框这时看起来明显偏紧车轮被截在框外两辆车并排停着时框体重叠严重类别标签偶尔在 car 和 truck 之间跳变。原因是俯拍视图中车辆高度信息消失检测网络回归的边界框尺寸变小同时距离远的车辆像素面积不足类别特征不明显。解决方式是双管齐下。一是把 imgsz 从 640 提高到 960让远端小目标有更多像素参与计算代价是帧率下降但换来了类别稳定性。二是按车道划定 ROI 区域把计数逻辑限定在 ROI 内执行画面边角盲区和远处过小的车辆不计入统计。ROI 可以直接在配置里写成多边形顶点坐标用 cv2.pointPolygonTest 判断中心点是否在区域内。这两招配合俯拍场景的计数误差通常会下降到可接受范围。5.4 现象GTX 1660 Ti 跑视频流卡成幻灯片帧率只有个位数硬件配置不够时的表现极具欺骗性检测框能出来结果也能保存但程序一跑起来 GPU 占用率只有 30%风扇不转帧率上不去。原因基本是三类。第一模型尺寸选大了默认加载 YOLOV8m 以上权重1660 Ti 的算力撑不住。第二torch 误装成 CPU 版本模型在 CPU 上跑显卡根本没参与。第三代码在检测每个帧后立即做了 imshow 显示窗口绘制和编码占用了大量 CPU 时间。解决的第一件事是用 nvidia-smi 确认显卡驱动和 CUD A 版本是否正常再用 3.1 中的 python -c 检查 torch.cuda.is_available()。第二件事是换模型优先用 YOLOV8n 或 s 权重1660 Ti 跑 n 版在 640 分辨率下能到 40 帧每秒完全够实时统计。第三件事是把可视化从主循环里剥出去只保存结果视频而不实时弹窗或每隔几十帧才显示一次画面。如果业务要求多路视频同时分析每路视频都要单独分配模型实例显存不够就降分辨率没有捷径。6. 最后一步用损失曲线验证模型再谈RK3588边缘部署模型能跑、能计数不代表交付就结束了。我在接手这类系统时多会做两个收尾动作一是确认模型训练是否收敛二是看能否把推理链路下沉到边缘设备。这两步做扎实系统才算真正可以长期运行。6.1 先画损失曲线确认这组权重不是一份“黑匣子”训练时的指标都会写入 runs/train 目录下的 results.csv每一行对应一个 epoch 的损失和精度。最常见也最直观的验证方式是画 box_loss 和 val/box_loss 两条曲线import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(runs/detect/train/results.csv) plt.plot(df[epoch], df[train/box_loss], labeltrain box_loss) plt.plot(df[epoch], df[val/box_loss], labelval box_loss) plt.xlabel(epoch) plt.ylabel(loss) plt.legend() plt.grid(True) plt.savefig(loss_curve.png)看曲线的要点就两个训练损失和验证损失都同步下降并趋平说明模型收敛验证损失在后期翘头上升说明过拟合这组权重对未见视频的泛化能力会打折扣。如果你拿到系统后要换数据集重训画损失曲线是每轮训练后的必做动作不要只看 mAP 一个数。6.2 往RK3588上搬导出ONNX是第一步后面还有RKNN绕不过去如果你的最终目的是部署到 RK3588 这类边缘盒子ultralytics 的导出命令能直接完成第一步yolo export modelweights/best.pt formatonnx imgsz640导出文件是 best.onnx但 RK3588 的 NPU 不直接消费 ONNX还要用 RKNN Toolkit 转成 .rknn 格式。实际部署时通常需要先把模型转 ONNX再导入 RKNN 工具链做量化。量化成 int8 后模型体积会缩小到四分之一推理速度大幅提升但精度会有几个点的损失。所以在做边缘部署前最好在原有数据集上先评估一下 int8 量化后的检测效果如果漏检明显改用混合量化或保留部分浮点算子。想起一次真实教训就是我把一个 l 版模型直接丢到边缘盒子上帧率掉到 4 帧每秒后来换成 YOLOV8s 并做 INT8 量化才跑到 25 帧。从那以后做部署前我都会按目标帧率反推模型尺寸先低配测试再逐步提精度。做完整套车流量检测系统最有价值的不是某个脚本跑通了而是你建立了“检测到跟踪到计数”的完整链路认知每一层有它自己的问题也都有对应的排查手段。确认了模型收敛、参数合理、跟踪稳定系统才算真正敢用在报表和决策上。希望帮到你。本文还有配套的精品资源点击获取
