做YOLO系列落地有一段时间后你会发现一个规律真正让人头疼的往往不是模型精度本身而是把模型塞进一个真实的、有摄像头、有网络抖动、有夜间光线变化的现场环境里。这篇是YOLO系列落地实战的第二篇场景选在智能交通一个常见的城市路口需要同时做车流检测、行人检测和双向计数统计而且不是一台摄像头对着拍是服务器端同时拉取多路摄像头画面实时跑检测。这个需求在智慧园区、交通枢纽、城市路口、景区出入口几乎天天都能遇到。这篇文章写给两类人一类是刚接触YOLO落地、准备做交通类视觉项目的开发者可以先按这里的架构搭一套能用的原型另一类是已经在跑检测、但被计数不准和多路卡顿反复折磨的工程师后面几节的问题排查实录基本是照着现场踩坑经历写的。核心内容会覆盖算力预算、推理引擎选型、跟踪计数逻辑、多路并发调度以及几个不看现场根本想不到的坑。1. 智能交通场景需求拆解与总体架构设计1.1 这个项目到底要解决什么问题先别急着跑模型把这个场景说清楚。一个真实路口画面里同时有汽车、摩托车、行人、非机动车甚至偶尔出现动物。我们需要的不是把画面里所有东西都框出来就算完事而是要回答三个业务问题这条路上的车流量是多少、行人过街流量是多少、当前路口是不是已经拥堵了。所以需求拆下来其实是三个核心模块车辆检测从视频帧里识别出轿车、卡车、公交车等机动车输出类别和位置行人检测识别行人同样输出类别和位置流量统计在画面中的指定位置设置检测线跟踪目标统计单位时间内从A方向到B方向的车流和行人数量。如果只有一台摄像头对着单车道这个任务其实不难。难点在于“多路”假设现场有6路摄像机分别覆盖路口的四个方向和两条人行横道服务器需要同时解码、检测、跟踪、统计、入库。这时候算力、带宽、线程模型、丢帧策略每一项都会成为瓶颈。还有一个容易被忽略的点现场摄像头安装位置不固定。有的杆子高俯视角度大把整个路口都收进去了车看着很小有的杆子低平视角度只看得到近处车道。同一个模型要适应不同机位这比单纯调参更考验推理管线。所以从一开始检测、跟踪、统计这三层就要解耦方便针对单路画面做配置。1.2 为什么最终选YOLO26作为统一检测引擎我最早试过传统的背景差分法和帧差法做车流检测。白天光线好勉强能用一到傍晚树影晃动、车灯照亮地面背景模型直接就崩了一个阴影能被当成一辆车。这类方案的优点是快但鲁棒性太差放在真实路口基本没法验收。后来换了目标检测模型。两阶段的检测器精度不错但服务器端多路并发时推理速度不占优势且部署链路更重。单阶段检测器是更好的平衡点。YOLO26属于YOLO系列最新一代的检测模型之一它在结构上延续了多尺度特征融合的思路训练阶段用动态标签分配对遮挡目标、密集小目标、不同光照下的目标都有不错的适应能力。更重要的是工程生态。YOLO26导出的ONNX模型可以被转换到TensorRT加速FP16下推理速度非常可观这决定了它能扛住多路并发需求。社区里对YOLO系列的后处理代码、跟踪器适配都很成熟ByteTrack、DeepSORT都有现成实现可以对接。对做生产环境的团队来说模型怎么训是算法团队的事推理管线和业务逻辑才是真正要投入精力的地方选一个生态成熟的模型能省掉大量脏活。1.3 服务器多摄像头为什么不选边缘盒子有人可能会问现在边缘计算盒子那么多每个摄像头旁边挂一个盒子不是更简单吗这里要说清楚两种方案的取舍。对比维度边缘盒子方案服务器集中方案单路延迟较低略高但可控摄像头扩容每增加一路要单独采购和运维设备服务器加路数扩容方便模型升级需要逐个盒子刷版本麻烦服务器上同步一次即可数据汇聚每路数据分散要额外做汇总天然集中统计、告警、入库都在一处硬件故障节点多故障面大单点风险需要做冗余典型规模适合1~4路小店场景5路以上、业务逻辑复杂的场景智能交通路口这种场景摄像头数量一般不会只有一两路而且车流统计、行人统计、拥堵判断这些业务都要跨镜头做数据汇总。集中式服务器虽然把所有压力集中在一起但换来的是维护简单、迭代快。只要算力预算做得合理服务器集中方案在实际项目中更好落地。整体架构可以概括成一条流水线RTSP拉流 → 视频解码 → 帧预处理 → YOLO26推理 → 后处理NMS→ 跟踪ByteTrack→ 计数逻辑 → 结构化数据入库 → 告警/大屏展示。后面第二、三、四章就是在讲这条流水线上每个环节怎么搭。2. 服务器算力预算与推理引擎选型多路摄像头怎么不卡2.1 先算算算力账很多项目死在第一步还没搞清楚要买什么卡就动手开发开发完才发现并发跑不动。我的习惯是先做一个粗略的算力预算再拿着这个预算去做硬件选型。单路摄像头1080P、25帧每秒。实际上做交通统计不需要每帧都推理15帧每秒已经足够跟踪稳定还能省算力。如果6路摄像头按照每路15FPS来算服务器每秒需要完成90张图像的检测推理。这个数字就是整个系统的核心负载。检测输入尺寸对算力影响极大。YOLO26可以用640x640输入也可以用1280x1280甚至1536x1536。640输入下小目标漏检会明显增加而路口场景里车辆和行人往往只占画面很小一部分所以推荐用1280级别输入。但输入从640提升到1280计算量不是翻倍而是4倍甚至更高因为特征图的高和宽都放大了。做一个粗略估算在主流中高端GPU上YOLO26的FP16模型在1280x1280输入下单帧推理延迟大概在20~40毫秒之间这意味着单卡推理吞吐约30~45FPS理论上只够支撑2~3路15FPS的检测。要跑6路就需要更强算力或者降低输入分辨率。我们的做法是让用户按摄像头视角配置输入尺寸机位高、目标小的用1280近景的用640或960平均下来单路压力能降不少。算力预算建议整机留出30%余量因为解码、图像缩放、跟踪、计数都会占用CPU和内存不能把所有算力都压在GPU推理上。2.2 从PyTorch到ONNX再到TensorRT模型训练完不能直接扔给服务器用要经过一套固定的转换流程。PyTorch模型先导出成ONNX做一次静态计算图验证再由TensorRT读取ONNX生成推理引擎。如果跳过ONNX直接转有些算子的兼容问题要到真机上才暴露排查成本更高。导出ONNX时有几个参数要提前定好。opset版本建议11以上太低会导致某些算子丢失动态轴这块要谨慎关于batch维度的动态支持可以打开但输入分辨率最好固定或者只保留极少几档。TensorRT对动态shape支持虽然成熟但动态shape在运行时需要每次重新指定尺寸会引入额外的显存开销和调度复杂度。转换TensorRT引擎时FP16基本是标配精度损失对检测任务来说微乎其微。INT8则不建议一上来就做因为需要校准数据集校准集如果分布和真实场景差异太大精度会突然掉一截。有一个现实的经验先用FP16把系统跑稳再考虑INT8去压榨性能。要提醒的是显存碎片问题。TensorRT引擎加载后运行时context会占用额外显存多路并发如果每个线程创建独立context显存会迅速被吃光。解决办法是复用context或者把多路推理请求通过一个共享队列串行/并发地交给一个推理服务处理。这个在第四章会详细说。2.3 摄像头接入与视频解码管线的几个坑RTSP拉流听起来简单实际坑不少。摄像头的RTSP地址通常长这样rtsp://user:passwordip:port/Streaming/Channels/101不同厂家路径规则完全不同。项目里最好用一个统一的配置文件管理所有摄像头信息包括编号、IP、用户名、密码、流地址、安装位置描述不要把地址硬编码在代码里。解码这块OpenCV自带的VideoCapture延迟大约在500毫秒以上多路并发时还会互相阻塞。生产项目更推荐用FFmpeg的libav库做解码可以由我们自己控制解码线程数、缓存队列长度和丢帧策略。每路视频独立一个解码线程解码后的帧放到一个带锁的环形缓冲队列里推理线程从队列里取最新帧。丢帧策略值得专门说说。15FPS检测意味着每66毫秒要处理一帧但如果某次推理卡了一下超过100毫秒队列里就会积压新帧。处理方式是队列满了以后直接弹出旧帧只保留最新一帧。检测系统对每帧的处理时间是允许几帧跳过的跟踪器靠的是帧间连续性跳一两帧不会导致目标ID丢失但积压会导致延迟越来越大最终画面和实际差好几秒。掉线是另一个躲不掉的问题。现场网络有抖动摄像头偶尔会断流。解码线程要做自动重连重连间隔采用退避策略第一次断线等5秒重试之后每次翻倍最多到60秒封顶。不要用固定1秒重连否则弱网环境会把摄像头连接数打满。3. 车流/行人检测与统计的核心实现逻辑3.1 兴趣区配置不是全画面都跑检测也不是全画面都计数训练出来的模型是对全图做检测但业务统计一般只在特定区域生效。比如左转车道和直行车道的车流要分开统计人行横道的行人和马路边的行人属于不同业务线这些都要靠兴趣区配置实现。在配置界面里管理员可以用鼠标在视频画面里画多边形这个多边形就是RoI。推理完成后检测框中心点如果落在RoI之外这个目标会被过滤掉不参与跟踪和计数。这样做的好处有三个减少误检、避免统计无关区域目标、降低后处理压力。检测线的设置比RoI更精细。一条检测线由两个点定义线有两个方向正向和反向分别计一次数。比如一条东西向道路的东向西车道检测线垂直于车道走向摆放目标从线的A侧移动到B侧记为一次正计数从B侧移动到A侧记一次反向计数。这里有个关键细节不要用检测框的中心点作为跨线判断锚点而应该用检测框底部中心点也就是目标的“脚底投影”。车辆和行人都是地面目标脚底点在地面上的运动轨迹比框中心更稳定不会因为目标大小变化而产生明显的上下抖动。俯视角度下这个点基本就代表了目标真正的位置。3.2 轨迹跟踪与跨线计数计数准确的关键有了检测框直接统计每帧数量没有任何意义目标会连续出现在几十帧画面里一帧一个框不做关联就无法知道这是一辆车持续出现还是十辆车快速路过。跟踪器的任务就是把每一帧的检测框串成轨迹。项目里我优先推荐ByteTrack而不是DeepSORT。DeepSORT依赖外观特征匹配需要一个额外的ReID模型提取特征这对服务器算力又是一笔开销而且多目标场景下特征区分度并不总是可靠。ByteTrack的思路更轻量用卡尔曼滤波预测轨迹位置然后利用检测框的IoU做关联低置信度框不直接丢弃而是二次匹配。它在行人遮挡严重、车辆密集的场景下表现相当稳关键是纯几何计算、速度极快多路并发几乎无压力。跨线计数的实现需要一点简单几何计算。设检测线为线段端点分别为P1和P2计算目标锚点与P1、P2形成的向量叉积。叉积的正负号代表点在线段的哪一侧。如果目标在当前帧和上一帧的叉积符号不同就说明目标跨过了这条线。但符号变了不能立刻计数还要再加两个过滤条件一是运动方向要符合计数方向不能把倒车也算成正向车流二是目标要连续若干帧保持跨线状态避免目标在检测线上来回抖动产生重复计数。我们项目里的经验是连续3帧都满足跨线条件才记一次数并且计完数后给该轨迹加一个“已计数”标记同一轨迹即使再次触碰检测线也不再计数。这样能显著降低复计率。3.3 行人统计与排队状态估计行人的检测和车辆在模型层面共用同一个网络只是在后处理时按类别区分。车辆用底部锚点计数行人同样用脚底锚点。但行人有一个特殊问题密集状态下站在后面的人可能被前面的人完全遮挡检测框会时断时续。所以对行人的跟踪状态管理要比车辆更宽松一些轨迹丢失阈值可以放长比如车辆丢失5帧就删除行人可以放到10帧减少漏计。排队状态估计是交通场景里一个加分项。不需要复杂算法用现成的检测框做一次空间聚类就行。把同一车道RoI内所有静止或低速目标的中心点收集起来沿道路方向做一维聚类簇的长度除以单车平均车身长度就是近似排队长度。这个数据可以用来判断红灯溢出、路段拥堵非常实用。如果要做更细的密度估计可以参考分割模型的思路但对服务器负载影响较大。在6路并发场景下不建议一开始就上分割模型先用检测框聚类方案跑一段时间业务方有更细需求再迭代。4. 多路并发推理调度与性能优化踩坑4.1 推理线程模型与帧调度策略多路摄像头并发推理的架构常见的有两种。第一种是每路一个完整管线解码线程、推理线程、后处理线程全部独立。好处是互不干扰一路卡死不影响其他路坏处是GPU利用率不高推理单元可能有空闲等待。第二种是解码和后处理按路独立推理交给一个共享的推理服务。好处是GPU吞吐最大坏处是一个共享队列可能成为瓶颈而且矩阵运算上容易互相抢占资源。实际项目里我更偏向折中方案每路视频独立解码、独立后处理但推理阶段通过一个统一调度器分发到GPU上。调度器维护一个任务队列记录每帧的来源、分辨率、时间戳然后以batch的方式发给TensorRT。如果TensorRT不支持动态shape多档分辨率混批就按分辨率分组后分批发。这样能把GPU利用率从70%提到90%以上。帧调度还有一个经典问题如果多路的帧输入不均匀优先级高的路口方向应该优先推理。可以在调度器里为不同摄像头设置权重比如主干道方向权重是2次要道路是1。调度器优先处理高权重的帧保证关键方向低延迟。4.2 TensorRT性能调优的几个细节性能调优不只是开FP16那么简单。先用NVIDIA提供的profiling工具逐个算子看耗时大概率会发现瓶颈集中在几个地方Resize算子的CPU等待、输入数据H2D拷贝耗时、后处理NMS占用大量CPU。输入数据拷贝是很多人忽略的坑。PyTorch默认输入是CHW连续内存但摄像头帧是NHWC的RGB排列如果不先转为连续Tensor再拷贝就会多发一次内存中转。正确做法是在解码端直接把图像转为HWC连续内存推理前用CUDA做一次异步拷贝到GPU推理期间CPU同时处理上一帧的后处理。这样能隐藏大部分拷贝延迟。显存方面TensorRT engine加载后占一块显存推理时还会临时分配activation显存。多路并发时不同推理流如果共享同一个engine但使用不同context可能会因为显存分配竞争导致性能下降。可以把几个context的显存池预先分配好跑起来后就不再涉及动态分配延迟稳定很多。后处理NMS如果用纯Python写在90FPS的吞吐下会占掉一个CPU核心的70%。推荐用C或者预编译的TensorRT后处理插件来加速NMS。让后处理时间从10毫秒降到2毫秒整体帧率能提升10%以上。4.3 业务数据入库与告警联动检测和统计是底层能力上层业务最终要的是数据。每发生一次有效的跨线计数就生成一条结构化事件包含摄像头编号、车道方向、目标类别车/行人、跨线方向、触发时间和对应的目标轨迹ID。这些事件先写入内存队列后端定时批量写入数据库避免每秒钟产生大量小的写请求。实时性要求比较高的场景用Redis做一层短期缓存存最近10分钟的计数结果。大屏展示系统从Redis订阅增量数据通过WebSocket推给前端。历史统计数据落到数据库中做小时级和天级聚合。告警逻辑可以相对简单但也有讲究比如某方向车流量连续5分钟超过阈值或者行人过街密度异常聚集触发告警事件。这个阈值最好做成可配置的因为不同路口的正常流量差异很大写死阈值一定会被现场运营吐槽。5. 常见问题与排查实录那些只有现场才会遇到的坑5.1 误检漏检夜间车灯过曝、树影、雨天地面反光白天晴天的检测精度通常很好看一到晚上就原形毕露。车灯过曝时两个靠很近的车灯会融成一个亮斑模型把它检测成一辆车但实际上可能是一辆车的两个灯也可能是对向两辆车的灯重叠。树影在傍晚或者起风时会有频繁的明暗变化很容易和大面积黑色车辆轮廓混淆。处理这个问题的思路不是无限调模型而是做工程侧干预。第一后处理里加一个置信度阈值分时切换白天0.35夜间0.5避免低置信度误检。第二对于过曝区域可以在预处理管线里做局部自适应直方图均衡抑制高光但这个方法比较耗CPU只能按需对夜间画面启用。第三积累一段现场夜间数据做增量训练让模型见过这个路口的夜景。最笨也最有效。雨天地面反光主要是柏油路面湿润后镜面反射会把倒影里的车灯检测成目标。这个很难只靠模型解决我采取的办法是在计数逻辑里加一个位置关系过滤同一垂直位置如果出现一个真实目标和一个疑似倒影目标倒影通常位置更低直接丢弃低位置的重复目标。这个规则在现场验证效果明显基本不误伤真实目标。5.2 计数不准同样一辆车被数了两次这是所有问题里被投诉最多的。原因通常是三个检测线画得太短目标从线两端绕过去也能完成跨线判断目标在检测线附近被遮挡导致轨迹中断重新出现后被当成新目标于是被计了两次目标在线上停车又启动来回晃动触发了不止一次跨线判断。解决计数不准的方法可以组成一套组合拳。第一检测线要足够长覆盖整个可通行断面一般要延长到车道边界两侧只留出车道护栏位置的空隙。第二轨迹中断后不能立刻删除允许一定帧数的找不到匹配超过阈值再删。第三计完数后给轨迹打标记杜绝重复计数。第四保存计数事件的截图或者小段视频业务方投诉时可以人工复核也是调优数据集的来源。调试计数逻辑时可以在后台开一个可视化开关把检测框、轨迹、检测线、计数标记全部实时绘制到视频流上存成一段录像回放。肉眼对比计数器数字和实际目标数量比看日志高效得多。这个调试工具一定要在项目第一天就搭好后期能省几天排查时间。5.3 多路掉线、画面冻结、时间戳对不上多路摄像头同时跑掉线问题几乎一定会出现。画面冻结是最坑的解码线程不报错但图像不再更新。原因是摄像头端RTSP流被某些网络设备缓冲住了只发旧的I帧不发新帧。处理方法是在解码管线里做帧时间戳校验如果连续一段时间内帧的PTS没有增长就判定为流冻结主动断开重连不能傻等。时间戳对不上会直接影响统计准确性。多路摄像头各自本地时间可能差出几十秒如果计数事件都挂在摄像头本地时间上按小时聚合时不同方向的流量分布在完全错误的时间窗口里。解决方法是统一使用服务器NTP时间为准拉流解码后立刻把本地接收时间作为事件时间戳而不是用摄像头OSD上传的时间。5.4 隐私合规与数据安全路口视频涉及车牌和人脸属于敏感个人信息落地时要把合规问题当成技术问题处理。两件事必须要做一是对图像中的车牌区域和人脸区域做实时模糊处理二是数据库只保留计数结果和事件元数据不保留超过必要期限的原始视频录像。模糊处理放在检测完成之后立即执行。因为检测框已经给出了车牌和人脸的位置直接在原始帧上用矩形覆盖或者高斯模糊即可成本极低。存储层面要支持按摄像头、按时间范围设置数据保留策略超期自动清理这个功能一定在合同验收时会被问到。6. 落地过程中的几点体会与可复用经验6.1 先跑通两路再谈扩展我见过不少团队拿到项目就直接上6路结果整个调试周期都在跟多路并发问题搏斗连基础的检测精度都没验证好。我的建议是第一阶段只接两路摄像头一个视角好的主干道一个视角差些的次干道。把两路的检测、跟踪、跨线计数、入库、可视化完整跑通再去横向扩展。两路的好处是排查问题快。单路不卡不代表多路不卡但两路能把最常见的线程安全问题和显存问题暴露出来又不会让日志淹没在大量重复告警里。等两路跑稳定了再逐步增加路数每加一路做一次持续20分钟的压力观察记录延迟、显存、计数准确率三项指标确认没有劣化再继续加。这套渐进式扩展的方式能让我们在项目交付前就摸清系统的真实上限而不至于在上线当天才发现算力不够。6.2 后续可以做的扩展方向这个项目如果继续迭代有几个方向都值得做。第一是逆行检测在跨线计数的基础上如果一个目标在检测线附近沿着与主线方向相反的方向穿过就触发告警逻辑改动很小但业务价值高。第二是路口拥堵状态识别结合排队长度和历史流量曲线输出1~5级的拥堵指数这个数据对信号灯优化很有用。第三是多摄像头跨镜跟踪一个目标从A镜头进入B镜头时用时空信息做关联能还原整条通行轨迹对行人过街安全分析很有帮助。轻量化部署也是一个现实需求。如果后续要覆盖更多没有服务器资源的小路口YOLO26的量化模型配合单路外设能跑出不错的实时性能边缘轻量化方案和服务器集中方案不是互斥的可以按点位重要程度混合部署。做了几个落地项目之后我最大的体会是模型选型、算法调优只是整个系统的冰山一角真正决定项目成败的往往是检测线画得是否合理、队列调度是否平滑、断线重连是否可靠这些看起来不起眼的细节。如果让我给后来者一句最想说的话那就是先接受“现场环境永远不会按文档里的样子运行”然后在架构设计里给意外留出余地。每一条检测线的位置校准都要用真实视频回放反复验证每一次计数偏差都要通过可视化工具去看现场到底发生了什么。把这条基本功练扎实YOLO26在智能交通场景里就是一套真正能交付、能验收、能长期运行的系统。
做YOLO系列落地有一段时间后你会发现一个规律真正让人头疼的往往不是模型精度本身而是把模型塞进一个真实的、有摄像头、有网络抖动、有夜间光线变化的现场环境里。这篇是YOLO系列落地实战的第二篇场景选在智能交通一个常见的城市路口需要同时做车流检测、行人检测和双向计数统计而且不是一台摄像头对着拍是服务器端同时拉取多路摄像头画面实时跑检测。这个需求在智慧园区、交通枢纽、城市路口、景区出入口几乎天天都能遇到。这篇文章写给两类人一类是刚接触YOLO落地、准备做交通类视觉项目的开发者可以先按这里的架构搭一套能用的原型另一类是已经在跑检测、但被计数不准和多路卡顿反复折磨的工程师后面几节的问题排查实录基本是照着现场踩坑经历写的。核心内容会覆盖算力预算、推理引擎选型、跟踪计数逻辑、多路并发调度以及几个不看现场根本想不到的坑。1. 智能交通场景需求拆解与总体架构设计1.1 这个项目到底要解决什么问题先别急着跑模型把这个场景说清楚。一个真实路口画面里同时有汽车、摩托车、行人、非机动车甚至偶尔出现动物。我们需要的不是把画面里所有东西都框出来就算完事而是要回答三个业务问题这条路上的车流量是多少、行人过街流量是多少、当前路口是不是已经拥堵了。所以需求拆下来其实是三个核心模块车辆检测从视频帧里识别出轿车、卡车、公交车等机动车输出类别和位置行人检测识别行人同样输出类别和位置流量统计在画面中的指定位置设置检测线跟踪目标统计单位时间内从A方向到B方向的车流和行人数量。如果只有一台摄像头对着单车道这个任务其实不难。难点在于“多路”假设现场有6路摄像机分别覆盖路口的四个方向和两条人行横道服务器需要同时解码、检测、跟踪、统计、入库。这时候算力、带宽、线程模型、丢帧策略每一项都会成为瓶颈。还有一个容易被忽略的点现场摄像头安装位置不固定。有的杆子高俯视角度大把整个路口都收进去了车看着很小有的杆子低平视角度只看得到近处车道。同一个模型要适应不同机位这比单纯调参更考验推理管线。所以从一开始检测、跟踪、统计这三层就要解耦方便针对单路画面做配置。1.2 为什么最终选YOLO26作为统一检测引擎我最早试过传统的背景差分法和帧差法做车流检测。白天光线好勉强能用一到傍晚树影晃动、车灯照亮地面背景模型直接就崩了一个阴影能被当成一辆车。这类方案的优点是快但鲁棒性太差放在真实路口基本没法验收。后来换了目标检测模型。两阶段的检测器精度不错但服务器端多路并发时推理速度不占优势且部署链路更重。单阶段检测器是更好的平衡点。YOLO26属于YOLO系列最新一代的检测模型之一它在结构上延续了多尺度特征融合的思路训练阶段用动态标签分配对遮挡目标、密集小目标、不同光照下的目标都有不错的适应能力。更重要的是工程生态。YOLO26导出的ONNX模型可以被转换到TensorRT加速FP16下推理速度非常可观这决定了它能扛住多路并发需求。社区里对YOLO系列的后处理代码、跟踪器适配都很成熟ByteTrack、DeepSORT都有现成实现可以对接。对做生产环境的团队来说模型怎么训是算法团队的事推理管线和业务逻辑才是真正要投入精力的地方选一个生态成熟的模型能省掉大量脏活。1.3 服务器多摄像头为什么不选边缘盒子有人可能会问现在边缘计算盒子那么多每个摄像头旁边挂一个盒子不是更简单吗这里要说清楚两种方案的取舍。对比维度边缘盒子方案服务器集中方案单路延迟较低略高但可控摄像头扩容每增加一路要单独采购和运维设备服务器加路数扩容方便模型升级需要逐个盒子刷版本麻烦服务器上同步一次即可数据汇聚每路数据分散要额外做汇总天然集中统计、告警、入库都在一处硬件故障节点多故障面大单点风险需要做冗余典型规模适合1~4路小店场景5路以上、业务逻辑复杂的场景智能交通路口这种场景摄像头数量一般不会只有一两路而且车流统计、行人统计、拥堵判断这些业务都要跨镜头做数据汇总。集中式服务器虽然把所有压力集中在一起但换来的是维护简单、迭代快。只要算力预算做得合理服务器集中方案在实际项目中更好落地。整体架构可以概括成一条流水线RTSP拉流 → 视频解码 → 帧预处理 → YOLO26推理 → 后处理NMS→ 跟踪ByteTrack→ 计数逻辑 → 结构化数据入库 → 告警/大屏展示。后面第二、三、四章就是在讲这条流水线上每个环节怎么搭。2. 服务器算力预算与推理引擎选型多路摄像头怎么不卡2.1 先算算算力账很多项目死在第一步还没搞清楚要买什么卡就动手开发开发完才发现并发跑不动。我的习惯是先做一个粗略的算力预算再拿着这个预算去做硬件选型。单路摄像头1080P、25帧每秒。实际上做交通统计不需要每帧都推理15帧每秒已经足够跟踪稳定还能省算力。如果6路摄像头按照每路15FPS来算服务器每秒需要完成90张图像的检测推理。这个数字就是整个系统的核心负载。检测输入尺寸对算力影响极大。YOLO26可以用640x640输入也可以用1280x1280甚至1536x1536。640输入下小目标漏检会明显增加而路口场景里车辆和行人往往只占画面很小一部分所以推荐用1280级别输入。但输入从640提升到1280计算量不是翻倍而是4倍甚至更高因为特征图的高和宽都放大了。做一个粗略估算在主流中高端GPU上YOLO26的FP16模型在1280x1280输入下单帧推理延迟大概在20~40毫秒之间这意味着单卡推理吞吐约30~45FPS理论上只够支撑2~3路15FPS的检测。要跑6路就需要更强算力或者降低输入分辨率。我们的做法是让用户按摄像头视角配置输入尺寸机位高、目标小的用1280近景的用640或960平均下来单路压力能降不少。算力预算建议整机留出30%余量因为解码、图像缩放、跟踪、计数都会占用CPU和内存不能把所有算力都压在GPU推理上。2.2 从PyTorch到ONNX再到TensorRT模型训练完不能直接扔给服务器用要经过一套固定的转换流程。PyTorch模型先导出成ONNX做一次静态计算图验证再由TensorRT读取ONNX生成推理引擎。如果跳过ONNX直接转有些算子的兼容问题要到真机上才暴露排查成本更高。导出ONNX时有几个参数要提前定好。opset版本建议11以上太低会导致某些算子丢失动态轴这块要谨慎关于batch维度的动态支持可以打开但输入分辨率最好固定或者只保留极少几档。TensorRT对动态shape支持虽然成熟但动态shape在运行时需要每次重新指定尺寸会引入额外的显存开销和调度复杂度。转换TensorRT引擎时FP16基本是标配精度损失对检测任务来说微乎其微。INT8则不建议一上来就做因为需要校准数据集校准集如果分布和真实场景差异太大精度会突然掉一截。有一个现实的经验先用FP16把系统跑稳再考虑INT8去压榨性能。要提醒的是显存碎片问题。TensorRT引擎加载后运行时context会占用额外显存多路并发如果每个线程创建独立context显存会迅速被吃光。解决办法是复用context或者把多路推理请求通过一个共享队列串行/并发地交给一个推理服务处理。这个在第四章会详细说。2.3 摄像头接入与视频解码管线的几个坑RTSP拉流听起来简单实际坑不少。摄像头的RTSP地址通常长这样rtsp://user:passwordip:port/Streaming/Channels/101不同厂家路径规则完全不同。项目里最好用一个统一的配置文件管理所有摄像头信息包括编号、IP、用户名、密码、流地址、安装位置描述不要把地址硬编码在代码里。解码这块OpenCV自带的VideoCapture延迟大约在500毫秒以上多路并发时还会互相阻塞。生产项目更推荐用FFmpeg的libav库做解码可以由我们自己控制解码线程数、缓存队列长度和丢帧策略。每路视频独立一个解码线程解码后的帧放到一个带锁的环形缓冲队列里推理线程从队列里取最新帧。丢帧策略值得专门说说。15FPS检测意味着每66毫秒要处理一帧但如果某次推理卡了一下超过100毫秒队列里就会积压新帧。处理方式是队列满了以后直接弹出旧帧只保留最新一帧。检测系统对每帧的处理时间是允许几帧跳过的跟踪器靠的是帧间连续性跳一两帧不会导致目标ID丢失但积压会导致延迟越来越大最终画面和实际差好几秒。掉线是另一个躲不掉的问题。现场网络有抖动摄像头偶尔会断流。解码线程要做自动重连重连间隔采用退避策略第一次断线等5秒重试之后每次翻倍最多到60秒封顶。不要用固定1秒重连否则弱网环境会把摄像头连接数打满。3. 车流/行人检测与统计的核心实现逻辑3.1 兴趣区配置不是全画面都跑检测也不是全画面都计数训练出来的模型是对全图做检测但业务统计一般只在特定区域生效。比如左转车道和直行车道的车流要分开统计人行横道的行人和马路边的行人属于不同业务线这些都要靠兴趣区配置实现。在配置界面里管理员可以用鼠标在视频画面里画多边形这个多边形就是RoI。推理完成后检测框中心点如果落在RoI之外这个目标会被过滤掉不参与跟踪和计数。这样做的好处有三个减少误检、避免统计无关区域目标、降低后处理压力。检测线的设置比RoI更精细。一条检测线由两个点定义线有两个方向正向和反向分别计一次数。比如一条东西向道路的东向西车道检测线垂直于车道走向摆放目标从线的A侧移动到B侧记为一次正计数从B侧移动到A侧记一次反向计数。这里有个关键细节不要用检测框的中心点作为跨线判断锚点而应该用检测框底部中心点也就是目标的“脚底投影”。车辆和行人都是地面目标脚底点在地面上的运动轨迹比框中心更稳定不会因为目标大小变化而产生明显的上下抖动。俯视角度下这个点基本就代表了目标真正的位置。3.2 轨迹跟踪与跨线计数计数准确的关键有了检测框直接统计每帧数量没有任何意义目标会连续出现在几十帧画面里一帧一个框不做关联就无法知道这是一辆车持续出现还是十辆车快速路过。跟踪器的任务就是把每一帧的检测框串成轨迹。项目里我优先推荐ByteTrack而不是DeepSORT。DeepSORT依赖外观特征匹配需要一个额外的ReID模型提取特征这对服务器算力又是一笔开销而且多目标场景下特征区分度并不总是可靠。ByteTrack的思路更轻量用卡尔曼滤波预测轨迹位置然后利用检测框的IoU做关联低置信度框不直接丢弃而是二次匹配。它在行人遮挡严重、车辆密集的场景下表现相当稳关键是纯几何计算、速度极快多路并发几乎无压力。跨线计数的实现需要一点简单几何计算。设检测线为线段端点分别为P1和P2计算目标锚点与P1、P2形成的向量叉积。叉积的正负号代表点在线段的哪一侧。如果目标在当前帧和上一帧的叉积符号不同就说明目标跨过了这条线。但符号变了不能立刻计数还要再加两个过滤条件一是运动方向要符合计数方向不能把倒车也算成正向车流二是目标要连续若干帧保持跨线状态避免目标在检测线上来回抖动产生重复计数。我们项目里的经验是连续3帧都满足跨线条件才记一次数并且计完数后给该轨迹加一个“已计数”标记同一轨迹即使再次触碰检测线也不再计数。这样能显著降低复计率。3.3 行人统计与排队状态估计行人的检测和车辆在模型层面共用同一个网络只是在后处理时按类别区分。车辆用底部锚点计数行人同样用脚底锚点。但行人有一个特殊问题密集状态下站在后面的人可能被前面的人完全遮挡检测框会时断时续。所以对行人的跟踪状态管理要比车辆更宽松一些轨迹丢失阈值可以放长比如车辆丢失5帧就删除行人可以放到10帧减少漏计。排队状态估计是交通场景里一个加分项。不需要复杂算法用现成的检测框做一次空间聚类就行。把同一车道RoI内所有静止或低速目标的中心点收集起来沿道路方向做一维聚类簇的长度除以单车平均车身长度就是近似排队长度。这个数据可以用来判断红灯溢出、路段拥堵非常实用。如果要做更细的密度估计可以参考分割模型的思路但对服务器负载影响较大。在6路并发场景下不建议一开始就上分割模型先用检测框聚类方案跑一段时间业务方有更细需求再迭代。4. 多路并发推理调度与性能优化踩坑4.1 推理线程模型与帧调度策略多路摄像头并发推理的架构常见的有两种。第一种是每路一个完整管线解码线程、推理线程、后处理线程全部独立。好处是互不干扰一路卡死不影响其他路坏处是GPU利用率不高推理单元可能有空闲等待。第二种是解码和后处理按路独立推理交给一个共享的推理服务。好处是GPU吞吐最大坏处是一个共享队列可能成为瓶颈而且矩阵运算上容易互相抢占资源。实际项目里我更偏向折中方案每路视频独立解码、独立后处理但推理阶段通过一个统一调度器分发到GPU上。调度器维护一个任务队列记录每帧的来源、分辨率、时间戳然后以batch的方式发给TensorRT。如果TensorRT不支持动态shape多档分辨率混批就按分辨率分组后分批发。这样能把GPU利用率从70%提到90%以上。帧调度还有一个经典问题如果多路的帧输入不均匀优先级高的路口方向应该优先推理。可以在调度器里为不同摄像头设置权重比如主干道方向权重是2次要道路是1。调度器优先处理高权重的帧保证关键方向低延迟。4.2 TensorRT性能调优的几个细节性能调优不只是开FP16那么简单。先用NVIDIA提供的profiling工具逐个算子看耗时大概率会发现瓶颈集中在几个地方Resize算子的CPU等待、输入数据H2D拷贝耗时、后处理NMS占用大量CPU。输入数据拷贝是很多人忽略的坑。PyTorch默认输入是CHW连续内存但摄像头帧是NHWC的RGB排列如果不先转为连续Tensor再拷贝就会多发一次内存中转。正确做法是在解码端直接把图像转为HWC连续内存推理前用CUDA做一次异步拷贝到GPU推理期间CPU同时处理上一帧的后处理。这样能隐藏大部分拷贝延迟。显存方面TensorRT engine加载后占一块显存推理时还会临时分配activation显存。多路并发时不同推理流如果共享同一个engine但使用不同context可能会因为显存分配竞争导致性能下降。可以把几个context的显存池预先分配好跑起来后就不再涉及动态分配延迟稳定很多。后处理NMS如果用纯Python写在90FPS的吞吐下会占掉一个CPU核心的70%。推荐用C或者预编译的TensorRT后处理插件来加速NMS。让后处理时间从10毫秒降到2毫秒整体帧率能提升10%以上。4.3 业务数据入库与告警联动检测和统计是底层能力上层业务最终要的是数据。每发生一次有效的跨线计数就生成一条结构化事件包含摄像头编号、车道方向、目标类别车/行人、跨线方向、触发时间和对应的目标轨迹ID。这些事件先写入内存队列后端定时批量写入数据库避免每秒钟产生大量小的写请求。实时性要求比较高的场景用Redis做一层短期缓存存最近10分钟的计数结果。大屏展示系统从Redis订阅增量数据通过WebSocket推给前端。历史统计数据落到数据库中做小时级和天级聚合。告警逻辑可以相对简单但也有讲究比如某方向车流量连续5分钟超过阈值或者行人过街密度异常聚集触发告警事件。这个阈值最好做成可配置的因为不同路口的正常流量差异很大写死阈值一定会被现场运营吐槽。5. 常见问题与排查实录那些只有现场才会遇到的坑5.1 误检漏检夜间车灯过曝、树影、雨天地面反光白天晴天的检测精度通常很好看一到晚上就原形毕露。车灯过曝时两个靠很近的车灯会融成一个亮斑模型把它检测成一辆车但实际上可能是一辆车的两个灯也可能是对向两辆车的灯重叠。树影在傍晚或者起风时会有频繁的明暗变化很容易和大面积黑色车辆轮廓混淆。处理这个问题的思路不是无限调模型而是做工程侧干预。第一后处理里加一个置信度阈值分时切换白天0.35夜间0.5避免低置信度误检。第二对于过曝区域可以在预处理管线里做局部自适应直方图均衡抑制高光但这个方法比较耗CPU只能按需对夜间画面启用。第三积累一段现场夜间数据做增量训练让模型见过这个路口的夜景。最笨也最有效。雨天地面反光主要是柏油路面湿润后镜面反射会把倒影里的车灯检测成目标。这个很难只靠模型解决我采取的办法是在计数逻辑里加一个位置关系过滤同一垂直位置如果出现一个真实目标和一个疑似倒影目标倒影通常位置更低直接丢弃低位置的重复目标。这个规则在现场验证效果明显基本不误伤真实目标。5.2 计数不准同样一辆车被数了两次这是所有问题里被投诉最多的。原因通常是三个检测线画得太短目标从线两端绕过去也能完成跨线判断目标在检测线附近被遮挡导致轨迹中断重新出现后被当成新目标于是被计了两次目标在线上停车又启动来回晃动触发了不止一次跨线判断。解决计数不准的方法可以组成一套组合拳。第一检测线要足够长覆盖整个可通行断面一般要延长到车道边界两侧只留出车道护栏位置的空隙。第二轨迹中断后不能立刻删除允许一定帧数的找不到匹配超过阈值再删。第三计完数后给轨迹打标记杜绝重复计数。第四保存计数事件的截图或者小段视频业务方投诉时可以人工复核也是调优数据集的来源。调试计数逻辑时可以在后台开一个可视化开关把检测框、轨迹、检测线、计数标记全部实时绘制到视频流上存成一段录像回放。肉眼对比计数器数字和实际目标数量比看日志高效得多。这个调试工具一定要在项目第一天就搭好后期能省几天排查时间。5.3 多路掉线、画面冻结、时间戳对不上多路摄像头同时跑掉线问题几乎一定会出现。画面冻结是最坑的解码线程不报错但图像不再更新。原因是摄像头端RTSP流被某些网络设备缓冲住了只发旧的I帧不发新帧。处理方法是在解码管线里做帧时间戳校验如果连续一段时间内帧的PTS没有增长就判定为流冻结主动断开重连不能傻等。时间戳对不上会直接影响统计准确性。多路摄像头各自本地时间可能差出几十秒如果计数事件都挂在摄像头本地时间上按小时聚合时不同方向的流量分布在完全错误的时间窗口里。解决方法是统一使用服务器NTP时间为准拉流解码后立刻把本地接收时间作为事件时间戳而不是用摄像头OSD上传的时间。5.4 隐私合规与数据安全路口视频涉及车牌和人脸属于敏感个人信息落地时要把合规问题当成技术问题处理。两件事必须要做一是对图像中的车牌区域和人脸区域做实时模糊处理二是数据库只保留计数结果和事件元数据不保留超过必要期限的原始视频录像。模糊处理放在检测完成之后立即执行。因为检测框已经给出了车牌和人脸的位置直接在原始帧上用矩形覆盖或者高斯模糊即可成本极低。存储层面要支持按摄像头、按时间范围设置数据保留策略超期自动清理这个功能一定在合同验收时会被问到。6. 落地过程中的几点体会与可复用经验6.1 先跑通两路再谈扩展我见过不少团队拿到项目就直接上6路结果整个调试周期都在跟多路并发问题搏斗连基础的检测精度都没验证好。我的建议是第一阶段只接两路摄像头一个视角好的主干道一个视角差些的次干道。把两路的检测、跟踪、跨线计数、入库、可视化完整跑通再去横向扩展。两路的好处是排查问题快。单路不卡不代表多路不卡但两路能把最常见的线程安全问题和显存问题暴露出来又不会让日志淹没在大量重复告警里。等两路跑稳定了再逐步增加路数每加一路做一次持续20分钟的压力观察记录延迟、显存、计数准确率三项指标确认没有劣化再继续加。这套渐进式扩展的方式能让我们在项目交付前就摸清系统的真实上限而不至于在上线当天才发现算力不够。6.2 后续可以做的扩展方向这个项目如果继续迭代有几个方向都值得做。第一是逆行检测在跨线计数的基础上如果一个目标在检测线附近沿着与主线方向相反的方向穿过就触发告警逻辑改动很小但业务价值高。第二是路口拥堵状态识别结合排队长度和历史流量曲线输出1~5级的拥堵指数这个数据对信号灯优化很有用。第三是多摄像头跨镜跟踪一个目标从A镜头进入B镜头时用时空信息做关联能还原整条通行轨迹对行人过街安全分析很有帮助。轻量化部署也是一个现实需求。如果后续要覆盖更多没有服务器资源的小路口YOLO26的量化模型配合单路外设能跑出不错的实时性能边缘轻量化方案和服务器集中方案不是互斥的可以按点位重要程度混合部署。做了几个落地项目之后我最大的体会是模型选型、算法调优只是整个系统的冰山一角真正决定项目成败的往往是检测线画得是否合理、队列调度是否平滑、断线重连是否可靠这些看起来不起眼的细节。如果让我给后来者一句最想说的话那就是先接受“现场环境永远不会按文档里的样子运行”然后在架构设计里给意外留出余地。每一条检测线的位置校准都要用真实视频回放反复验证每一次计数偏差都要通过可视化工具去看现场到底发生了什么。把这条基本功练扎实YOLO26在智能交通场景里就是一套真正能交付、能验收、能长期运行的系统。
知识建站
内容驱动
阅读友好版式
SEO 精细化
线索转化