基于YOLOv8模型的行人车辆多目标检测计数与跟踪系统这个项目我断断续续做了两个多月从最初的数据集标注到最终在嵌入式设备上跑起来踩了不少坑也积累了一些值得记录的经验。这篇文章就拿它当案例把整个技术链路拆开揉碎从模型选型、数据准备、训练调参到跟踪算法选型、计数逻辑设计再到最后的部署优化和问题排查完整捋一遍。无论你是刚接触目标检测的学生还是要在实际业务场景落地这套方案的工程师这篇内容都能给你一些实在的参考。尤其是那些官方文档里没写清楚、只有自己跑过才知道的细节我会重点讲。1. 项目需求拆解与整体技术选型1.1 核心需求到底在解决什么问题很多人一上来就急着跑模型但我建议先把需求拆清楚。这个项目标题拆开其实是三件事检测、计数、跟踪。这三件事看起来是一条流水线实际上每个环节的难点完全不在一处。以我做的这个场景为例需求是对园区出入口的监控视频进行实时分析分别统计行人和车辆的数量同时输出每个目标的运动轨迹。业务方要的不是“画面里有没有人”而是“这条路在这段时间里经过了多少人、多少车”以及“每个人/每辆车从哪边进、从哪边出”。这就引出了几个关键问题单纯做检测每一帧的检测结果都是独立的同一辆车在25帧视频里会被数25次所以必须有跟踪模块把跨帧的同一个目标关联起来。计数的口径是什么是“画面中出现过的总数”还是“穿过某条虚拟线的数量”不同口径对应完全不同的工程实现。场景中行人和车辆同时存在行人小、车辆大尺寸差异明显对小目标的召回率要求很高。1.2 技术链路选型与理由整体方案我选用了YOLOv8 作为检测底座 ByteTrack 作为跟踪器 自定义计数逻辑的组合。这个选型不是拍脑袋而是综合考虑了精度、速度、工程难度和社区生态之后的取舍。先看检测部分。YOLOv8 是当前工业界应用最广泛的实时目标检测模型之一相比前代版本有几处结构上的关键升级主干网络采用C2f 模块替代原有的 C3 模块梯度流更丰富特征提取能力更强尤其对遮挡目标和小目标的特征表达更充分。检测头改为Decoupled Head解耦头分类和回归分支分开收敛速度和精度上限都有提升。全面转向Anchor-Free省去了锚框聚类和调参过程对新手更友好。跟踪部分选用 ByteTrack原因很简单它不需要重识别特征提取网络纯靠运动关联和检测框的IoU关系就能把多目标跟踪做得很好而且实现极简部署生态好。后来我也试过 DeepSORT 系列但对这个场景来说ByteTrack 的性价比更高后面我会专门对比。计数逻辑我最终采用的是“区域进入判定法”在画面中划定一个检测区域目标从区域外进入并满足一定停留帧数后计为一次进入。这个方案兼容行人和车辆两种运动特征比物理虚拟线更灵活。1.3 业务场景适配的特殊考量实际场景里有个很头疼的点人车交叉遮挡。行人和车辆在画面中经常重叠而且车辆体积大会把行人完全挡住这对检测和跟踪都是严峻考验。针对这一点我在方案设计时定下了几个原则检测类别只保留person、car、truck、bus、motorcycle、bicycle六个类别多分类虽然炫技但类别越多类间混淆越严重在实际场景中会明显拉低精度。跟踪策略上对检测框置信度阈值做分层处理高置信度框直接参与关联低置信度框0.1~0.5之间在 ByteTrack 的第二轮关联中参与匹配用于召回被遮挡的目标。计数逻辑与跟踪ID绑定而不是与单帧检测绑定从机制上规避重复计数。这些看起来都是很小的细节但恰恰决定了系统能不能从“实验室demo”变成“能用的工具”。2. 数据集准备与标注细节2.1 自建数据集还是用公开数据集很多人在这一步会纠结直接用 COCO 预训练权重做迁移学习行不行我的答案是可以但效果天花板很低。COCO 数据集里虽然有 person 和 car但它的场景分布和你的监控视角差异很大——COCO 里大多是平视视角的近景大目标而监控场景是俯视、中远距离、目标偏小。直接拿预训练模型去跑监控视频小目标漏检会非常严重。我的做法是在开源数据集基础上叠加自采场景数据做微调。具体来说底料用了 COCO 和 BDD100K 的部分图像然后我自己从监控视频里抽帧标注了约 18000 张图像测试场景里大概 80% 的准确率提升来自这批自采数据。这里要强调一件事踩坑最多的不是模型结构而是数据标注的质量。我第一版训练的模型在白天场景表现不错一到傍晚就开始疯狂漏检。排查了半天发现是自采数据里傍晚时段的图像占比太少训练时模型根本没见过足够的弱光特征。2.2 标注规范与质量管控多类别目标检测的标注规范直接影响模型的收敛上限。我把我的标注规范贴出来供参考项目要求类别定义person行人、car轿车/SUV、truck卡车、bus客车/公交车、motorcycle摩托车/电动车、bicycle自行车标注框类型水平矩形框紧贴目标轮廓不包含非目标物遮挡处理目标可见面积大于30%必须标注小于30%不标注遮挡目标分为“被车挡”和“被树挡”都标同一类别极小目标策略像素边长小于12px的单帧目标不标注但连续多帧可辨识的目标必须标交叠目标策略两个目标重叠时各自框按照各自的真实边界标不裁剪不合并标注质量怎么量化我用了两个指标卡控标注框贴合度直接标注人员抽检框与目标边缘的贴合度低于85%打回重标类别一致性随机抽100张图做交叉验证意见不一致超过5个框就要重新统一标注口径。2.3 数据增强策略的坑与解法YOLOv8 自带了 Mosaic、MixUp、HSV 抖动、随机翻转等一系列数据增强默认配置下效果不错但有几个参数我调过之后才发现收益很大HSV 亮度增强默认的 hsv_v 是 0.4户外监控场景我调到了 0.7模拟一天中不同时段的曝光差异。Mosaic 概率默认训练后期 Mosaic 会自动关闭但我因为小目标多手动把 Mosaic 关闭的 epoch 从默认的 20 延后到了 30强制模型在前30轮持续见到拼接多样性的场景。随机翻转对于对称目标人、车来说水平翻转没问题但监控场景里如果画面有固定的文字标识或者车牌信息翻转会让模型学偏。我在数据增强里关闭了水平翻转宁可用增加多角度数据来弥补方向多样性。关于小目标问题我额外做了一层切图增强把原始大图切成四块每块单独参与训练这样小目标在切图之后就变成了大目标模型学到的特征更充分。这个操作在YOLOv8里写个简单的预处理脚本就能实现收益非常直接。3. 模型训练与关键参数调优3.1 训练配置与超参数选择YOLOv8 的训练入口是yolo train命令行但超参数的选择才是一切的核心。我的实验基线配置如下# train.yaml 核心配置 task: detect mode: train model: yolov8m.pt data: dataset.yaml epochs: 150 batch: 8 imgsz: 1280 patience: 15 device: 0 workers: 4 optimizer: AdamW lr0: 0.001 lrf: 0.01 warmup_epochs: 3.0 weight_decay: 0.0005 close_mosaic: 30几个重点参数的选择逻辑解释一下imgsz输入图像尺寸这是我最想强调的一个参数。很多教程默写用 640但对监控场景来说640 的分辨率会让远处的行人只有十几像素宽模型根本认不出来。我把输入尺寸从 640 提升到 1280小目标召回率提升了接近 20%代价是训练显存变大、推理变慢。业务方给的 GPU 是单卡显存24Gbatch设为8刚好能跑动。batch size 的选择在显存允许的范围内尽量大。小的 batch size 会带来较大的梯度噪声在小目标密集的场景下收敛不稳定。如果显存不够优先减小 imgsz而不是减小 batch。优化器和学习率YOLOv8 官方默认是 SGD实测用 AdamW 收敛更快、泛化更好尤其是自建数据规模不算大的时候AdamW 的自适应学习率能减少很多调参的痛苦。学习率初始化 0.001余弦退火到 0.001×0.01。3.2 训练曲线怎么看、怎么判断是否收敛训练过程中我看四个指标train/box_loss、train/cls_loss、val/box_loss、val/cls_loss。很多人只会看 mAP但损失曲线能提前暴露很多问题训练损失降、验证损失不降过拟合信号此时应该考虑增强数据多样性、加大 dropout、提前停止。训练损失和验证损失同步但不降学习率过大或模型容量不足先试试降低 lr0 再考虑换大模型。验证损失波动剧烈batch size 太小、学习率太高或者数据集里某个类别样本太少导致梯度更新方向不稳定。我遇到的一个实际问题是前 30 个 epoch 损失下降非常快但 mAP 一直徘徊在 0.6 左右上不去。后来检查发现是数据集里motorcycle类的样本只有 300 张而其他类都有几千张类别严重不均衡。于是单独对摩托车类做了过采样和 Mosaic 增强mAP 才从 0.61 涨到 0.74。3.3 模型精度评估的多维度分析YOLOv8 训练结束后会输出各类别的 mAP50 和 mAP50-95但单看这两项还不够。我做了一个按目标尺度分层的评估目标尺度像素面积范围模型召回率小目标32×320.43中目标32×32 ~ 96×960.78大目标96×960.91这个表格一出来问题非常直观小目标严重拖后腿。这也是我后来下决心把 imgsz 从 640 拉到 1280 的直接原因。评估的时候我额外做了一次按时间段白天/傍晚/夜间的切片测试因为业务场景对全时段覆盖有要求。测试结果再次印证了数据分布的重要性——傍晚数据的 mAP 只有 0.58我在标注规范里增加了曝光差异大的样本后这个数字提升到了 0.69。3.4 模型导出与精度保持训练完成后要把 PyTorch 模型导出为推理引擎格式。我导出了两种ONNX和TensorRT。ONNX 用于服务端 CPU/GPU 推理的兜底方案TensorRT 用于部署在嵌入式设备上的高性能方案。导出命令很常规但有个细节值得注意yolo export modelruns/detect/train/weights/best.pt formatonnx dynamicTrue opset13 yolo export modelruns/detect/train/weights/best.pt formatengine device0 halfTrue导出 TensorRT 引擎时我踩过一个坑默认情况下imgsz参数会和训练时保持一致但推理端如果画面尺寸比训练尺寸小很多模型会冗余计算反而变慢。我最终把推理 imgsz 和训练 imgsz 保持了一致同时在预处理里做 letterbox 填充确保输入比例恒定。4. 多目标跟踪与计数逻辑的实现4.1 为什么检测做完了还要再做跟踪检测模型解决的是“这一帧画面里有哪些目标、位置在哪儿”但业务要的是“这条路上经过了多少目标”这就需要跨帧关联。举个例子一辆车从画面左侧驶入到右侧驶出总共在画面里出现了 60 帧。没有跟踪的话系统每帧都会报告检测到一辆车60 帧就是 60 次检测结果但实际业务只关心这个目标出现了 1 次。跟踪器的作用就是给每个目标分配一个唯一ID并且持续更新ID对应的目标位置框直到目标离开画面。这样系统就能以ID为单位做计数和轨迹统计。4.2 ByteTrack与DeepSORT的实测对比我在项目中先后跑了两个跟踪方案这里给出实践层面的对比对比维度ByteTrackDeepSORT核心原理纯运动关联IoU卡尔曼滤波运动关联外观特征重识别是否需要ReID模型不需要需要额外加载ReID权重遮挡恢复能力中等靠低分框二次匹配较强靠外观特征找回推理开销低几乎可忽略中ReID推理占额外资源工程复杂度简单纯Python实现复杂需要维护两个模型ID切换率中目标长时间遮挡时易切换低外观特征可区分听起来 DeepSORT 的 ID 稳定性更好为什么我还是选了 ByteTrack核心原因是监控场景中大部分“遮挡”是短暂的行人和车辆交错经过不会超过1秒ByteTrack 的低分框二次匹配机制足以应对这种短时遮挡。而 DeepSORT 的外观特征在行人侧身、背对镜头、车辆同色同款时会失效还会引入额外的 ReID 模型部署开销。工程上ByteTrack 更轻量排查问题也更方便。如果你要处理的目标有长时间交互遮挡人群聚集、货物堆叠那是另一个需求建议认真上 DeepSORT 或更重型的跟踪器但我这个场景确实没必要。4.3 计数逻辑设计虚拟区域法跟踪器输出了每个目标的ID和连续轨迹之后计数逻辑就有点“画龙点睛”的意思了。我最初用的是虚拟线法——在画面中画一条线目标ID的中心点跨过这条线且方向一致时计数加一。虚拟线法很经典但在实际场景中有两个致命问题行人的运动轨迹不是直线中心点可能在线附近来回“蹭”导致重复计数。车辆在画面中可能因为减速停下来停在线附近时中心点剧烈抖动一次转弯就触发了多次跨线判定。后来我改用区域进入判定法在画面中划定一个多边形检测区域目标必须满足“轨迹从区域外进入区域内且持续在区域内停留超过N帧”才会触发计数。这个N我设定为5帧通过连续帧确认来过滤抖动和瞬时误检测。代码层面计数逻辑维护了一个字典以跟踪ID为键、进入状态为值# 核心计数逻辑伪代码 counted_ids set() # 已计数ID集合 entry_buffer {} # 待确认ID缓存 for track_id, bbox in track_results.items(): center get_center(bbox) in_zone point_in_polygon(center, zone_polygon) if track_id not in entry_buffer: entry_buffer[track_id] 0 if in_zone: entry_buffer[track_id] 1 if entry_buffer[track_id] 5 and track_id not in counted_ids: counted_ids.add(track_id) total_count 1 else: entry_buffer[track_id] max(0, entry_buffer[track_id] - 2)这个entry_buffer的加减逻辑是经验调出来的进入区域后连续5帧确认离开区域时保留2帧的缓冲避免目标在边界来回抖动导致计数状态反复。4.4 车道方向统计和分类统计进阶需求是统计“进/出”方向和“各类型目标”的数量。方向判断利用轨迹的方向矢量——取目标最新位置的最近5帧轨迹点计算平均运动方向和区域进入方向比对进入方向属于设定范围则判定为“进”否则判定为“出”。类别计数更简单跟踪器关联的是检测框检测框自带类别标签同一个ID在所有帧中取出现频率最高的类别作为最终归类。不过这里要处理一个细节行人和摩托车在跟踪过程中偶尔会互相误检我加了一个“ID类别一致性”约束同一个ID的类别切换超过3次就强制锁定为历史占比最高的类别。5. 系统部署与实时性优化5.1 端到端系统架构整个系统跑通之后我把它组织成了四层架构采集层视频流/本地文件 → 推理层检测跟踪 → 分析层计数轨迹统计 → 展示层Web可视化/告警采集层用 OpenCV 的 VideoCapture 接口统一接入RTSP流和本地视频文件实测24路1080p视频并行接入有些吃力所以做了一级抽帧策略——只对业务关心的时段保持全帧率分析其他时段降低采样率到5fpsCPU占用直接降了一半。推理层是核心。检测模型用 TensorRT 加速推理引擎在单张显卡上实测 1280×1280 输入可达 20ms 一帧。跟踪器是纯 CPU 逻辑开销极小主要耗时在卡尔曼滤波的矩阵运算上但对于同时跟踪超过50个目标的密集场景也最好放到单独的线程里跑。5.2 多线程流水线的设计经验视频流处理不能是简单的“取帧→推理→跟踪→画框→输出”串行循环因为取帧的 IO 等待会白白浪费 GPU 算力。我采用了经典的双队列流水线一个生产者线程取帧一个消费者线程做推理和跟踪中间用带容量的队列缓冲。# 双队列流水线核心示意 def frame_producer(rtsp_url, frame_queue, stop_event): cap cv2.VideoCapture(rtsp_url) while not stop_event.is_set(): ret, frame cap.read() if not ret: continue if frame_queue.qsize() 30: # 丢弃积压帧 frame_queue.put(frame) # 用qsize做背压控制防止内存暴涨 def inference_consumer(frame_queue, result_queue, model): while not stop_event.is_set(): frame frame_queue.get() results model(frame) # 检测跟踪 result_queue.put((frame, results))这里最关键的工程细节是背压控制。如果视频源偶发卡顿生产者不要疯狂向队列里塞帧否则推理线程来不及消费延迟会越来越大。我的策略是队列容量限制为30帧溢出的旧帧直接丢弃。实际测试中在24路业务压力下端到端延迟保持在300ms以内。5.3 嵌入式设备部署的优化手段如果要在边缘设备上跑比如 Jetson 系列核心优化路径是TensorRT FP16 → 裁剪小模型 → 动态只测关键区域。我实测了一台算力约50TOPS的边缘设备YOLOv8m 模型 FP16 推理速度约 25ms/帧勉强跑实时。但如果换上 YOLOv8s 并用 TensorRT 的 INT8 量化推理速度能到 8ms/帧精度损失在可接受范围内mAP下降约3%。INT8量化最大的坑是校准集选择。如果你用默认的随机图像校准经常会出现某个类别精度崩坏的情况。我的做法是从训练集中挑出包含所有类别的各类各500张图像作为校准集并关闭动态形状固定输入尺寸为 1280×1280。另外还有一个部署细节从 1080p 视频流到模型输入尺寸的缩放我采用 letterbox 保持宽高比不足的部分填充灰边。跟踪器的目标框输出时需要把坐标从模型输入坐标系映射回原图坐标系这里容易出坐标偏移的bug建议单独封装一个scale_coords函数统一处理避免在多个地方重复进行坐标变换。6. 常见问题与调试实录6.1 高频问题速查表多目标检测跟踪项目做到最后遇到的问题基本都会集中在下面这张表里。我按“现象→原因→解法”的结构整理好了实战排查时可以直接对照。现象描述根本原因解决措施与操作细节小目标频繁漏检输入分辨率不足小目标像素过少imgsz 从640提升至1280增加切图增强夜间漏检严重训练数据中弱光样本占比不足增加夜间/黄昏样本提高HSV亮度增强强度行人被车辆遮挡时ID跳变纯IoU跟踪无法恢复长时遮挡降低低分检测框阈值参与ByteTrack二次匹配车辆停在画面中反复计数虚拟线法对静止目标抖动敏感改为区域进入判定增加连续帧确认机制推理延迟越来越高视频流处理是串行阻塞的改双队列流水线带回退控制的容量部署端INT8量化后精度崩坏校准集不具代表性用覆盖全类别的图像做校准集固定输入尺寸两点导致计数多计路线折返同一ID离开了又进入区域对已计数ID设置冷却时间规定时间内不重复计数6.2 一次典型的漏检问题排查实录一个典型的故障排查过程是这样的某天业务方反馈下午三点到五点这段时间计数器统计到的人流量比人工蹲点数少了12%。排查路径如下第一步先确认是检测丢了还是跟踪丢了。我把同时间段录制的视频用模型逐帧跑了一遍画框后直接看检测结果——确认是检测阶段漏检不是跟踪阶段丢ID。第二步分析漏检目标的特征。逐帧找漏检画面发现漏检的几乎都是画面远端的行人像素高度在20~30px之间属于小目标同时背景是浅色地砖行人穿的浅色衣服与背景对比度极低。第三步针对性定位。查了当天的光线条件下午三点到五点阳光斜射行人拉出长影子检测框和背景纹理变得复杂。原训练数据里下午时段的样本占比只有12%模型对“低对比度斜射光”的特征表达不充分。第四步补数据重训。从一周的监控录像中抽取下午时段的图像3000张和原有数据合并训练后同场景的召回率从0.79提升到了0.88。这个排查过程想强调的是遇到精度问题不要急着调参先分清是数据问题还是模型问题再定位是检测问题还是跟踪问题。大多数人上来就调学习率、换网络结构反而绕了远路。6.3 高频坑点坐标变换与画框偏移部署时最容易出错的不是模型本身而是坐标系的来回换算。YOLOv8 检测框输出的是模型输入坐标系的坐标但画面显示、跟踪器输入、计数判定都依赖于原图坐标系。我在早期版本中跟踪框总是比检测框偏上几个像素排查后发现是 letterbox 填充时灰边的偏移量没加回去导致所有坐标在原图坐标系里都有固定的像素平移。这个问题的解决方法很朴素测试时自己造一幅图案特殊的图像四个角放上醒目标记检测画框后检查框是否和标记准确对齐。如果四个角都偏了同一个方向那就是坐标偏移问题如果偏差不一致再考虑缩放比例问题。7. 思考这套方案能复用到哪些场景去这套“检测跟踪计数”的框架本身不绑定具体场景换数据集就能迁移。我试过把它迁移到两个新场景一是仓库出入口的叉车和人员统计只改了两个类别和检测区域精度起步就有0.85以上。二是商铺门口的客流统计把行人这一类拆成“进店”和“出店”两类计数核心逻辑完全不用动。这个项目给我留下的最大经验是目标检测不只是模型训练那一步搞明白业务要什么把数据、训练、跟踪、计数、部署串成一条完整链路远比单独调高某个指标更重要。如果你也打算做类似的多目标检测计数系统我最后建议三件事第一先把需求拆清楚“检测到”和“数清楚”之间隔着一整个工程第二数据质量比模型结构更值得花时间第三任何开源方案都只是起点你的场景特征才是决定性能上限的关键。