去年秋天我们在一个路侧视觉项目里调试夜间的十字路口视频流。白天的检测效果已经调到验收线以上了可一到晚上YOLOv26之前的模型就开始“装瞎”远处一辆没有开灯的黑色轿车或者被路边灯光拉出长影的行人经常整帧漏掉。白天指标再好到了真实交通场景里漏检就是事故隐患系统没人敢用。YOLOv26在智能交通系统中的应用要解决的核心问题不是榜单上多刷一个百分点而是怎么让模型在夜间、逆光、遮挡、小雨和低分辨率这些真实条件下稳定工作。这篇文章我从选型思路、结构改进、多路视频落地、难例处理、踩坑排查到边缘量化部署完整讲一遍。1. 交通场景不是目标检测的普通考场为什么测试了一圈我选了YOLOv261.1 智能交通系统里模型真正要面对的问题很多人以为目标检测在交通场景里就是“找到车和行人”实际上这可能是所有视觉任务里最不友好的场景组合。路口的摄像机动辄装在十几米高的横臂上一辆普通轿车在画面里只有几十个像素高早晚高峰的斑马线附近人、电动车、自行车、三轮车叠在一起互相遮挡逆光时车辆轮廓完全融进背景夜间又有路灯、车灯、广告牌产生的各种眩光。这些都不是标准数据集里能充分覆盖的情况。我在项目里体会最深的一点是交通检测的难点从来不是“能不能检出”而是“在什么条件下还能不能稳定检出”。一个模型如果只在晴天白天的测试集上跑得漂亮那它在真实路口的价值几乎是零。因为真正决定系统可用性的是小目标、遮挡目标和低照度目标在极端条件下的漏检率。我们把候选模型拖到私有场景视频上做批量回放很多模型在高分测试集上mAP很高一旦切到雨天夜间的连续帧漏检就像筛子一样止不住。1.2 从系列前代模型到YOLOv26选型对比中看到的几个关键变化我们在做选型对比时不是只看公开榜单而是拿YOLOv26和几个旧版本直接放到同一个私有测试集上跑。这个测试集专门抽了不同时段、不同天气、不同摄像头的真实录像标注了超过两万帧。表格里是我们在相同训练数据、相同输入分辨率1280x1280下的实测数据对比项前代系列模型基线YOLOv26小目标小于32x32像素AP44.151.6夜间时段漏检率21.4%12.2%遮挡严重的密集场景漏检率17.8%10.5%单路1080P视频推理延迟13.2ms9.1ms连续帧目标ID跳变次数每千帧约32次每千帧约11次这不是说YOLOv26是单点刷分刷出来的而是它在结构设计上确实把交通场景里的几个痛处都照顾到了。后面我会拆开讲。最直观的感受是小目标和夜间场景的提升不是靠“把模型调大”换来的它的推理速度反而更快这才是我们愿意往边缘设备上搬的原因。1.3 “环境考”比“模拟考”重要选型时最容易忽略的隐性指标选型最容易踩的坑是只看精度不看稳定性。模型在实际视频流里是连续跑的不是像学术评测那样一张一张看所以有几个指标比mAP更值得关注帧间稳定性同样的目标在相邻帧里是不是都被检出。漏一帧就会导致跟踪轨迹断裂下游的事件判断直接错乱。尾延迟长时间运行之后推理速度会不会因为缓存、持久对象等原因逐渐变慢。在8路、16路并发场景这个问题尤其明显。内存占用边缘盒子内存有限模型再准、塞不进去就没有意义。我们的结论是YOLOv26值得用不是因为它是“新版本”三个字而是它在这些关乎系统稳定性的隐性指标上确实压住了旧模型。选型的时候别急着看榜先把部署约束、视频帧率、硬件算力这些前置条件列清楚再回头挑模型才不会走弯路。2. YOLOv26的结构改进最值得关注的地方小目标、动态分配与时序上下文2.1 多尺度特征融合不是堆FPN而是跨层交叉注意力YOLOv26在特征融合上的改动不是简单地把更多层接到特征金字塔上。它用了一个跨层交叉注意力机制让深层的语义信息能够反向去增强浅层的细节特征。通俗一点讲以前是“高层信息往下传低层细节往上拼”现在两边在融合的时候会做一次“互相看重点”的操作浅层知道该关注哪个区域深层也会保留更细的边缘信息。这个改动对交通场景特别重要。因为交通目标尺度跨度实在太大一个路口的全景画面里既有覆盖几十个像素的轿车也有占满半个画面的公交车还有只露半张脸的骑手。如果浅层细节和深层语义只是简单相加小目标的轮廓特征很容易被大目标的响应淹没。交叉注意力相当于把融合权重交给网络自己学而不是人为固定比例小目标的细小特征在融合后更容易保留下来。实测中我们对比过光这一项改动小目标AP就有接近4个百分点的提升。2.2 动态标签分配与解耦头训练稳定性与漏检之间的平衡交通数据集的标签天生就带着噪声。远处的车到底是一辆还是一个“像素块”晴天能看清的人到了雨夜可能连人都分不出来。YOLOv26在标签分配上改成了动态策略不是提前把锚框和真实框匹配关系定死而是在训练中根据当前模型的预测动态选择正样本。这带来的直接好处是训练更稳。以前训练时如果某个小目标的IoU本来就低用固定阈值匹配可能直接把它当成背景模型根本学不到“这里有个目标”这件事。动态分配会在早期训练阶段给这些小目标更多机会。配合解耦头设计分类和回归两个分支分别优化也能避免“类别分对了但框完全贴不准”的问题。在交通项目里框准不准比类别准不准更影响下游。违章停车判断要依赖框在画面里的稳定位置框抖一次停留时长的计算就会出错。解耦头让框的回归更稳定我们跑连续帧验证的时候检测框的抖动幅度明显比旧模型小了一截。2.3 时序上下文信息从静态图到视频序列的“作弊”YOLOv26另一个很实用的改动是引入轻量级的时序上下文模块。它会在推理时参考前几帧的特征而不是孤零零地对当前单帧做检测。这有点像一个经验丰富的路况观看者看到一辆车的尾灯在上一帧已经亮起这一帧哪怕它被广告牌挡了一下也能判断它还在原位置。这个机制给系统带来的提升是实打实的。夜间场景中车辆会被路灯杆短暂遮挡单帧模型很容易在这几帧里丢失目标但有时序上下文加持后模型能基于前后帧信息预测目标仍然存在检测框不会突然消失。我们的测试里连续帧的ID跳变次数大幅下降跟踪稳定性也跟着上来了。使用这个模块时有一点要注意它会额外增加一点显存占用因为它需要缓存前几帧的特征。边缘设备上如果显存吃紧可以把缓存帧数从默认值调小或者仅在夜间模式开启。我用下来的经验是交通场景宁可稍微降一点帧率也要把时序上下文开着它对遮挡和闪烁场景的收益远大于那点性能损失。2.4 我训练时用的核心配置表模型结构只是基础训练配置同样关键。以下是我在一个典型的交通数据集上用的配置可以直接抄作业但要根据自己的数据和硬件调整配置项我的设置说明输入分辨率1280x1280交通小目标多没必要用640去省算力小目标掉点非常明显训练轮数300 epoch交通数据量普遍不大短训容易欠拟合Batch Size32单卡显存不够就对半减同时把学习率同步调低优化器AdamW收敛比SGD快配合warmup更稳Mosaic增强前250轮开启最后50轮关闭最后阶段关闭Mosaic让模型适应真实分布精度更稳类别损失权重按类别样本频率反比设置平衡“轿车”和“三轮车”这种长尾差异3. 从单帧检测到多路实时视频流一条真实的落地链路3.1 视频接入与帧同步先解决系统肚子里的数据流模型再强接不进视频流也白搭。实际项目里摄像头通常通过RTSP或类似协议把视频流传进来平台侧要做拉流、解码、抽帧。这里最容易被忽略的是帧同步多路视频不能各跑各的推理服务必须用一个统一的帧调度器来管理各路视频的解码和推理请求。我们采用的做法是为每路视频开一个解码线程解码出来的帧带时间戳进队列推理侧维护一个批次队列把不同路在同一时间窗口内的帧凑成一个batch统一交给GPU推理。这样做的好处是把GPU利用率拉满避免单路视频帧率波动导致GPU空闲。代价是队列管理复杂了一些如果某一帧处理超时必须有丢帧策略不能无限堆积导致延迟越来越大。3.2 检测到跟踪不要只做目标检测要做目标保持智能交通下游系统需要的是“目标的连续轨迹”而不是一串孤立的检测框。所以检测模型输出之后还要接跟踪器。我们在项目里用的是ByteTrack方案。它和传统跟踪器的核心区别是每一帧的检测框不仅仅是高分框那些低分框比如被遮挡到只剩半截的自行车也会参与轨迹匹配。YOLOv26本身帧间稳定性已经不错加上ByteTrack之后效果更稳。在遮挡严重的路口很多目标会在某几帧“消失”单纯靠IoU匹配很容易把目标ID丢掉。ByteTrack会保留一个缓冲机制短时间丢失的目标允许重新匹配回去保持同一个ID。我们最后测试的ID跳变率从每千帧32次降到了11次这个提升对整个系统的体验是决定性的。3.3 事件识别与业务联动从“看到什么”到“发生了什么”检测加跟踪解决了“看到什么”但智能交通系统最终要回答的是“发生了什么”。我们把跟踪器输出的轨迹交给业务规则引擎由轨迹数据计算各种事件逆行目标运动方向与车道方向相反且连续保持N帧违停目标在禁停区域停留超过设定时间拥堵区域内车辆平均速度低于阈值且持续一定时间抛洒物在无目标轨迹的情况下背景区域出现新目标且原地不动这些业务规则看起来简单实际调试时却很讲究。比如违停事件不能直接用“停止不动”判断因为车辆在排队等红灯也会停止必须结合车道区域是否属于禁停区来判断。我们做了一个可配置的事件规则表不同路口可以单独调参数模型换版本时业务规则层完全不用动。3.4 系统分层架构速览我们最终跑通的系统可以分成四层接入层负责视频解码、抽帧、时间戳管理承载多路摄像头并发接入推理层YOLOv26模型推理、跟踪器更新、后处理逻辑核心是保证低延迟和高稳定性业务层事件规则引擎、区域判断、指标统计把轨迹变成业务语义存储与展示层结构化事件数据、截图证据、实时告警推送每一层之间通过队列解耦哪一层出问题都不会直接拖垮其他层。这个架构部署到现在整体跑得很稳。4. 夜雨、逆光、遮挡与低分辨率我们把交通难例变成了训练资产4.1 数据侧不要只加样本要加“失败模式”很多团队在遇到模型漏检时第一反应是“再去标一万张图”。但真正有效的做法是分析模型在什么场景下失败按“失败模式”去补数据。我们把历史视频按天气、时段、光照、目标大小分了层每层都单独统计漏检率。结果很有启发夜间小目标车辆是最大的漏检来源其次是逆光时段的二轮车再然后是被大树阴影挡住的行人。针对每个失败模式去定向采集和标注效率比盲目加数据高得多。我们后来训练集的增速不算快但每次补的都是“模型最不会的那类样本”模型迭代起来肉眼可见地变好。4.2 图像增强与相机模拟让模型提前“见鬼”为了让模型在白天训练时也能学会夜间特征我们大量使用了图像增强模拟。这不是简单的亮度降低而是很多贴近相机物理特性的模拟眩光模拟把高亮光源周围叠加星芒和光晕扩散效果模拟车灯和路灯的散射低照度模拟降低亮度并加入随机噪声模拟昏暗场景下的传感器噪声雨滴和雾气模拟在画面上叠加透明条纹和局部模糊模拟镜头上的水渍运动模糊模拟对快速移动的目标做方向性模糊模拟长曝光拖影这些增强手段在公开数据上可能“不讨喜”但在交通场景里非常有效。夜晚图像本来就难以大量采集通过白天图像做物理模拟能让模型提前见过各种极端效果。我们实验对比过加了物理模拟增强之后夜间漏检率又降了3个百分点左右。4.3 难例挖掘与自训练把易错样本筛进训练集除了增强我们还会从真实视频流里做难例挖掘。做法是让推理服务在线上跑一段时间把置信度在一定区间内的检测框截图保存下来比如置信度在0.3到0.7之间的预测框。这些框大概率是模型“认得不彻底”的目标筛出来存到待复核队列里由标注员快速判断是漏检、误检还是标签边界问题。这里有个细节难例挖掘一定要覆盖不同时段不能只挖白天。我们的复核队列特意按“夜间抽帧比例翻倍”来采样因为夜间的难例是模型最需要学习的内容。经过几轮难例回流模型在长尾目标上的表现提升非常明显。4.4 长尾类别平衡三轮车和警示桶不该被淹没交通场景的类别分布非常不均。轿车、公交车的样本量可能是三轮车的几十倍但三轮车在城郊结合部的路口恰恰是高频目标。如果不做平衡训练时模型很容易“学会”忽略小样本类别。我的做法比较传统但很有效给每个类别设定一个目标样本量低于这个量就从历史视频里定向挖帧补标同时给损失函数里低频类别的权重调高。另一个实用技巧是把相似类别合并比如“三轮车”和“电动三轮车”如果不做严格细分就合成一类先把检出率做上去类别细分等样本够了再拆。5. 踩坑实录周期性漏检、夜间误报与跟踪跳变的完整排查链路5.1 排查链路一八路视频同时跑为什么每分钟固定漏检一次现象很诡异八路视频同时推理每分钟左右会有一整帧的漏检单独跑四路就没有这个问题。一开始我们怀疑是模型问题但单帧输入时模型输出完全正常。排查过程是这样的先看推理日志发现漏检发生时整批推理时间突然飙高像是某一路视频帧的解码延迟把整个batch卡住了。再去看系统资源监控GPU利用率并没有打满反而是CPU和GPU之间的内存拷贝曲线出现规律性尖峰。最后定位到根因解码线程没有做好同步某一路视频在拷贝帧数据时独占内存总线导致其他路的帧同步等待。修复方案是给解码器加帧队列缓冲并在拷贝阶段做锁控制让各路的帧数据小批量地、分时地拷贝到GPU。改完以后周期性漏检彻底消失。这个坑给我的教训是多路并发场景绝对不能只看模型指标数据链路的同步机制比模型更影响稳定性。5.2 排查链路二夜间灯光的星芒导致“车”凭空出现夜间误报比漏检更难缠。有一段时间系统会在路口灯光正下方凭空报“车辆出现”而且在长曝光或镜头有轻微脏污时尤其严重。我们把截图调出来看画面中心是一团非常亮的灯光灯光周围有星芒状散射模型把星芒的一个亮点当成了车顶。一开始我们想通过后处理规则把这类误报过滤掉比如限制检测框的最小置信度调高之后确实能压住星芒误报但真实的小目标车辆也被压没了。最后把问题交回给训练我们专门做了一批“灯光负样本”把各种路灯、车灯、广告牌眩光截图作为背景类样本强行让模型学会区分“高亮区域的灯光散射”和“灯光下的车辆轮廓”。加上这批样本后夜间误报率下降了一半以上。灯光的负样本要注意多样性不能只找同一种路灯不同色温、不同角度、不同镜头的污渍形态都要覆盖。模型对这类高亮区块的学习能力很强只要负样本足够充分它是能学会“不要对灯光敏感”的。5.3 排查链路三同一辆车ID反复横跳检测稳定了之后跟踪又出问题。一辆车在穿过路口时ID经常从A变成B再变回A。用户反馈说“这辆车好像瞬移了”其实是ID跳变导致的轨迹混乱。我们排查后发现根因是目标在过路灯杆时被遮挡了两三帧检测框消失后跟踪器只能靠预测位置外推而外推的位置和重新出现时的实际位置偏差太大IoU匹配不上于是生成了新ID。解决办法是把纯IoU匹配改成ByteTrack的低分框复用机制同时还叠加了简单的运动预测。遮挡期间跟踪器不只看IoU还会结合目标上一段运动速度来预测新位置重新出现时优先匹配预测位置附近的检测框。这个改动让ID跳变率大幅下降而且是在不牺牲实时性的前提下。5.4 小经验每一个“玄学”问题最后都会落到一个确定性环节连续踩了几天坑之后我养成一个习惯任何看起来“偶尔发生、没法复现”的问题都不要先怀疑模型随机性。把视频回放、日志、资源监控三个数据源对齐到同一时刻绝大多数问题最后都能落到一个确定性的根因上要么是资源竞争要么是后处理逻辑边界要么是负样本缺失。6. 让系统越用越准数据闭环与模型持续迭代6.1 难例回流与人工复核模型上线不是终点。我们维护了一个从线上到训练集的闭环通道线上推理服务每天把难例截图导出到待复核列表标注员按优先级复核确认后的样本进入训练集定期增量训练再灰度放回线上。这个闭环的关键是“节奏要短”。我们最初按月迭代后来改成两周一次。交通场景的季节变化、道路施工、灯杆安装位置变动都会让数据分布漂移迭代周期太长模型会慢慢“过时”。两周一次的节奏刚好能跟上环境变化又不会给标注团队太大压力。6.2 主动学习用置信度做初筛海量视频流里不可能每帧都让人工看我们靠置信度区间来做初筛。规则很简单置信度在0.3到0.7之间的检测框既不像高置信度的“已确认目标”也不像低置信度的“纯噪声”大概率是模型没把握的区域值得我们人工复核。采样的比例也很重要。我们让审核列表按“夜间帧占60%、白天帧占40%”分配特意偏重夜间因为夜间难例的边际价值远高于白天。注意不要让主动学习变成变相增加误报的来源通常是一定采样比例回流叠加不确认的样本四周后评估效果再决定是否扩大采样。6.3 灰度发布与评估指标不能只看mAP模型能不能上线的最终判断靠的是一套业务向的评估指标不是单一mAP。我们内部跑这样几个维度漏报率按真值标签统计漏检数除以真值总数分时段、分天气统计误报率每万帧里的虚假告警数事件识别准确率违停、逆行这些业务事件判断得准不准这个指标用户最能感知单路延迟从视频解码到事件输出的端到端延迟超时会直接毙掉方案灰度发布时先切5%的路口跑一周对比这五个指标。如果都达标再逐步放大到全量。阶段发布不仅降低风险也能让我们在中间发现原本样本量没覆盖到的新场景。7. 边缘部署与量化我们最终在项目里保留的方案7.1 推理引擎、FP16/INT8与动态batch训练出的模型要真正在边缘端跑起来还需要一步格式转换和优化。我们用推理引擎把模型转换为优化的中间表示并开启FP16精度。实测对比FP16在精度几乎不掉的情况下推理速度比FP32快约40%。如果对性能还不满意再考虑INT8量化。INT8量化一定要用真实的校正数据集不能随便拿几张图。我们把白天、夜晚、阴雨三种场景的图像混合起来做校正集跑出来的量化模型精度损失控制在了1个点左右。如果某个检测头对量化特别敏感可以单独给该层保留FP16其他层用INT8这就是混合量化的思路。边缘部署不是一锤子买卖量化后一定要在真实视频流回放验证过再上线。7.2 硬件选型与部署形态我们尝试过几种部署形态最终形成了这样一个选型经验部署形态适合场景单路延迟参考值部署成本中心GPU工作站机房统一处理多路视频8-10ms较高边缘GPU盒子路口本地化部署回传事件结果9-12ms中专用NPU板卡极限低功耗、受限环境12-18ms低在选择边缘盒子时不要只看算力TOPS数字还要看视频解码能力。很多小目标漏检问题根源不是模型算不动而是解码器在高帧率、多路并发时跟不上导致丢帧。我们在两套不同盒子上测试过同样的模型解码能力和芯片匹配好的那台整体端到端延迟明显更稳。7.3 最后留下的一套工程经验讲讲从这轮项目里沉淀的几条经验比较啰嗦但都是用钱买来的教训第一不是模型越快越好视频链路里的解码、拷贝、跟踪器后处理任何一环都可能成为瓶颈。优化时不要只盯推理时间要把端到端链路的每一段都量化出来。第二置信度阈值是最后的手段不是第一手段。夜间漏检率高了先看的是数据和增强而不是把阈值调低导致误报满天飞。后处理规则越少模型越干净系统的可维护性越好。第三数据闭环比模型版本更重要。用了几轮迭代之后我最深的感受是真正让系统越跑越准的不是换结构、换版本的那一下提升而是每周都在持续进化的数据回流和评估节奏。如果让我重新做一遍这个项目第一天就会先把难例回流的链路搭好而不是等模型上线出了问题才开始补数据。