做智能售货柜项目最绕不开的就是一条链路IPC 摄像头拉流、视频抽帧、YOLO 识别。不管是做商品识别、取放判断还是防损预警这一套流程都是地基。我最早接手这个方向时踩了不少坑特别是“视频流怎么取出来”“抽帧会不会把画面搞卡”“检测模型推理跟不上”这三件事几乎每一个都能让项目从顺利Demo瞬间变成待排查魔改现场。这篇文章就把我在实际售货柜项目里跑通的一套完整流水线拆开讲清楚。从 RTSP 拉流协议怎么选、IPC 模拟器怎么用、抽帧策略怎么定到 YOLO 模型的训练数据、推理部署、后处理逻辑再到延迟高、丢帧、误检漏检这些高频问题的排查思路全部按真实项目里的处理顺序来讲。适合刚接触视觉售货柜的开发者、正在做边缘端视觉方案的工程同学以及想把手头“能跑模型”的Demo改成“能落地商用”的从业者参考。内容不追求大而全重点讲真正影响结果的地方。1. 先想清楚整条链路怎么搭1.1 为什么售货柜一定要用 IPC 而不是普通摄像头很多第一次做售货柜识别的朋友会问我柜子里空间也不大用 USB 摄像头是不是更简单成本还低这个问题的答案做上两三个样机就能体会出来。首先是部署距离和走线。售货柜的摄像头不一定装在柜门正中间有的装在顶部、有的装在层板前端、有的装在柜体侧边和主板之间的距离往往超过 USB 线缆的稳定传输距离。USB 摄像头超过 3 到 5 米就需要考虑延长线和信号衰减问题而 IPC 走网线五类线六类线跑个 50 米、100 米都没压力布线成本也低。其次是可靠性和并发路数。一个售货柜通常要装 2 到 4 路摄像头才能覆盖所有层板USB 摄像头的数量一旦多了主板的 USB 控制器、供电、驱动兼容性全是问题。IPC 通过以太网接入每路摄像头是一个独立的 IP 地址、一路 RTSP 流系统层面就是“拉 4 路流”和“同时插 4 个 UVC 设备”的区别稳定性和可维护性完全不是一个量级。然后是画面质量可控性。售货柜内部环境复杂有玻璃反光、层板遮挡、暗光环境。IPC 一般支持调节码率、帧率、分辨率、亮度、对比度、白平衡部分还支持宽动态。这些参数在视觉识别里非常重要尤其是玻璃柜门的大光比场景没有宽动态的摄像头拍出来就是一团黑或者一片白YOLO 再强也救不回来。最后是工程化生态。IPC 用的是标准化 RTSP/ONVIF 协议不管是海康、大华、雄迈还是各种白牌模组只要支持 RTSP 就能和自研算法平台对接。这一点对做设备方案的团队来说太重要了你不需要绑定某一家摄像头厂商的 SDK算法侧只需要和标准 RTSP 流打交道。1.2 RTSP 拉流方案选型的核心推断选型这一步很多教程只告诉你“用 OpenCV 的 VideoCapture 拉流”但这种方案在售货柜场景里最多只能算“能跑通”离“能上线”还有很大距离。先说 OpenCV 的 VideoCapture。它的底层调的是 FFmpeg 的解封装和解码库好处是代码极简几行就能从 RTSP 流里读出一帧 Mat。但它有两个痛点一是延迟不可控VideoCapture 内部有缓冲队列默认情况下拉出来的画面可能比真实时间滞后几百毫秒甚至一两秒对售货柜这种“顾客伸手拿商品”的实时交互场景来说体验很差二是错误恢复能力弱网络稍微抖动导致丢包断流VideoCapture 可能一直卡在读取状态不重建 capture 对象就拉不回来。我现在的项目里拉流端更推荐直接走 FFmpeg。无论你是用 C 直接调用 libavformat/libavcodec还是用 Python 的 PyAV 封装都比 VideoCapture 可控得多。原因很简单FFmpeg 能让你明确控制解封装、解码、丢帧策略、缓冲队列深度、重连机制。虽然代码量多一点但每一个参数都是你能调度的而不是被库的黑盒逻辑牵着走。那 GStreamer 呢GStreamer 的 pipeline 模型对实时流处理确实很强尤其是硬件加速这块配合 NVIDIA 的 DeepStream、瑞芯微的 mpp能做出非常漂亮的方案。但学习曲线陡峭调试起来也相对复杂如果你团队里没人熟悉 GStreamer后期维护成本会比较高。我的建议是如果你用的是 Jetson、RK3588 这类边缘盒子且对延迟和吞吐要求极高值得上 GStreamer如果是在普通 x86 工控机上做第一版方案验证FFmpeg 路线就够用了。解码方式上也要提前想清楚。软解FFmpeg 自带的软件解码器胜在兼容性好什么设备都能跑但 CPU 占用高硬解Intel QSV、NVIDIA NVDEC、RK3588 的 VPU能把 CPU 释放给 YOLO 推理和其他业务逻辑但在某些弱鸡平台上驱动和固件问题会让人头大。稳妥做法是先用软解把整条链路跑通确认业务模型没问题后再针对目标硬件做硬解适配。1.3 YOLO 模型与推理框架怎么选YOLO 现在版本迭代很快从 v5 到 v8、v9、v10、v11超参、结构、训练工具链都有差异。售货柜商品识别场景选模型的核心原则不是追新而是平衡精度、速度、模型体积和部署难度。Ultralytics 团队的 YOLOv8 和 YOLO11 目前生态是最完整的。提供统一的训练、验证、导出接口能导出 ONNX、TensorRT、OpenVINO 等格式适合快速验证和迁移部署。YOLOv8n 或 YOLOv8s 这种轻量型号在 640x640 输入下Jetson Orin Nano 或 RK3588 上跑实时完全没有压力哪怕是在低功耗的 CPU 设备上配合 OpenVINO 或 ONNX Runtime 也能达到可用的帧率。如果你对延迟有极致要求可以在导出模型后用 TensorRT 做 FP16 或 INT8 量化推理速度还能再上一个台阶。但量化有可能掉精度尤其是有大量小目标商品比如小瓶装饮料、口香糖盒子的场景INT8 量化后漏检会变明显。实操中我一般优先跑 FP16精度损失小速度提升也明显只有在硬件资源实在紧张时才考虑 INT8。还有一个偏经验性的建议零售商品识别场景与其追 YOLO 最新版本不如把时间和精力放在数据质量和后处理逻辑上。很多时候识别不准不是模型不够强而是训练数据和真实柜内环境的差异太大或者后处理没有把“检测框”转换成“拿取/放回事件”的逻辑做对。2. 拉流实操模拟器、真实设备与带宽账2.1 用 hiksimulator 搭一个永远不坏的测试环境项目前期最烦的事情是算法还没跑通硬件先罢工。真实 IPC 要么在工厂里没拉过来要么柜子装好了但网络环境不对算法工程师只能干等。所以我强烈建议团队备一套 RTSP 模拟源而 hiksimulator 就是干这个的。hiksimulator 是 HIKVISION 出的摄像头模拟工具可以在没有真实硬件的情况下把本地视频文件或标准测试画面通过 RTSP 协议推送出去模拟一台海康 IPC 的工作行为。编码格式支持 H.264 和 H.265分辨率、帧率、码率都可以手动设置关键是它推出来的流是标准 RTSP 流和真实摄像头对算法侧完全透明。换句话说你在代码里写好rtsp://192.168.1.200:554/...后面接模拟器还是接真机业务代码一行都不用改。这个工具对测试的价值特别大。你想测画面花屏、断流重连、低帧率、低分辨率这些极端情况真实相机很难现场制造但模拟器可以随意配置。我一般在拉流模块的开发阶段会专门准备三段视频素材一段商用货柜的静态画面、一段有人手伸入伸出的动作画面、一段高动态场景分别模拟不同的识别场景。另外需要说明白一件事模拟器是辅助最终一定要回到真实设备上验证。真实画面里的噪声、暗角、玻璃反光、运动模糊模拟器是模拟不出来的。但用模拟器把链路的工程问题先排干净再真机联调时你只需要关注算法效果本身效率会高很多。2.2 RTSP 地址格式与主码流子码流的区别RTSP 拉流的第一步是拿到正确的 URL。以海康设备为例常见的 URL 格式是rtsp://username:passwordip:port/Streaming/Channels/101注意最后一节的数字101 表示通道 1 主码流102 表示通道 1 子码流。201 就是通道 2 的主码流以此类推。大华设备通常是rtsp://username:passwordip:port/cam/realmonitor?channel1subtype0subtype0 是主码流subtype1 是子码流。不同品牌格式有差异接入前查一下对应型号的 SDK 文档是最稳妥的。主码流和子码流的区别要特别拎出来讲。主码流分辨率高、码率高、画质好适合做人脸识别、商品识别这种需要细节的算法子码流分辨率低、码率低、带宽占用小适合做人形检测、区域入侵这类粗粒度判断或者用来做预览。在售货柜场景里如果整条识别链路带宽有限或 GPU 算力紧张常见的做法是用子码流做目标预检比如层板上有没有人手出现确认有动作后再切换到主码流做精细识别。这个策略能大幅降低持续推理的算力消耗但需要考虑码流切换耗时和不同码流画面之间的时间对齐问题。2.3 带宽和码率怎么估算很多人在设备现场才想起算带宽结果发现一路摄像头就把交换机打满了。这里的核心公式很简单网络占用 码率 / 8。举个例子一台 400 万像素的 IPC在 H.265 编码、20 帧每秒、中等画质下码率通常在 4 Mbps 左右真实网络占用大概 0.5 MB/s。如果柜子里有 4 路这样的摄像头同时拉流总下行带宽就是 2 MB/s约 16 Mbps。普通百兆交换机理论上够用但实际吞吐要打折而且网络里还有其他广播和业务流量建议至少用千兆交换机并留 30% 以上的余量。H.264 编码在同画质下码率大约是 H.265 的 1.5 到 2 倍如果设备只支持 H.264成本会明显上升。还要注意一个容易忽略的点流量方向。售货柜如果通过 4G/5G 模块上云上行带宽往往比下行小得多。你把摄像头画面推到云端做识别和你在本地边缘盒子做识别对带宽的要求完全不同。我见过不少团队把“本地识别”想当然地做成了“云端识别”结果现场一张 SIM 卡根本扛不住多路高清流上传项目直接返工。所以方案设计阶段就要定清楚识别是本地做还是云端做。售货柜这种低延迟、高隐私、带宽有限的场景边缘本地推理是绕不开的选项。2.4 拉流代码的实现框架这里给一个基于 PyAV 的拉流解帧最小示例。PyAV 在接口设计上比直接调 FFmpeg CLI 可控又比用 C 开发效率高适合算法团队快速验证。import av def read_frames(rtsp_url, interval2): container av.open(rtsp_url, options{ rtsp_transport: tcp, stimeout: 5000000, max_delay: 500000, buffer_size: 1024000, }) stream container.streams.video[0] frame_count 0 for frame in container.decode(stream): if frame_count % interval 0: img frame.to_ndarray(formatbgr24) yield img frame_count 1rtsp_transport设为 tcp 是很关键的。UDP 传输延迟更低但在弱网环境丢包严重会导致画面花屏、花帧解码失败。TCP 用重传换稳定在局域网内其额外延迟通常可以忽略。stimeout是套接字超时时间避免了断流后程序一直阻塞等死。max_delay控制缓冲区的最大时长如果这个值设得太大延迟会变高设得太小网络抖动时又会频繁卡顿需要现场微调。提示拉流参数没有“万能配置”。在同一个项目里局域网环境、4G 环境、跨公网环境下的最优参数是不同 的。我通常是先用 TCP 默认参数把流拉通再根据实际延迟和卡顿情况去调 max_delay 和缓冲区大小。2.5 断线重连机制必须自己写RTSP 拉流不可能永远不中断。网络抖动、设备重启、交换机端口震荡都会导致推流中断。我的经验是拉流端必须自带重连机制而且重连要带退避和状态恢复。简单做法是每读一帧时记录最近一次成功解码的时间如果连续超过 5 秒没有新帧进来就主动关闭当前 container 并重新av.open。重连次数过多时应该指数退避避免在设备侧频繁重启的情况下客户端每秒钟发起几十次连接把设备搞挂。更高级一点的做法是维护一个“流状态机”把拉流状态分为正常、缓冲、断流、重连四个状态并且把状态上报给主控程序。这样算法侧的告警、业务端的事件暂停、以及日志排查都有据可循。最忌讳的是整个拉流循环因为断流直接抛异常退出然后进程 supervisor 反复重启看起来又正常又崩溃。3. 抽帧核心难点不在怎么抽在于怎么不丢关键画面3.1 为什么要抽帧而不是每帧都做检测IPC 一般配置为 15 到 25 帧每秒但 YOLO 推理如果跑在边缘设备上能做到 10 FPS 已经算不错了。这时候你不可能每一帧都做检测必须做抽帧。但售货柜场景比较特殊“拿取商品”这个行为本身是快速动作。人手伸进柜子、抓住商品、缩回手整个过程可能只有 1 到 2 秒。如果抽帧间隔太大、或者抽帧时机和动作错开了就会出现“人在柜前伸了手但没有一帧拍到商品被拿走”的尴尬情况。所以抽帧不是简单的“每秒抽几帧”它要和识别策略、触发机制配合。3.2 三种抽帧策略的适用范围第一种是按时间抽帧每 100 毫秒或 200 毫秒取一帧。实现最简单但对应动作速度较快时容易漏关键帧。第二种是按解码帧序号抽帧每 N 帧取一帧比如每 5 帧取 1 帧。这种方式要求解码器持续工作CPU 开销比按时间抽取略高但抽帧时机更均匀和视频帧率直接挂钩。第三种是事件驱动抽帧先用一个轻量级模型或传感器做触发比如检测到“画面中有手出现”或“红外感应到人体靠近”才触发连续抽帧并进行 YOLO 检测。平时只以极低频率轮询不做全帧推理。这种方案最适合售货柜既省算力又能保证关键动作不漏。我实际项目里用的是“事件驱动 按时间兜底”的组合。具体来说一级触发用 IPC 自身的移动侦测或一个轻量的目标检测模型比如只检测手和人触发后把抽帧间隔从 500 毫秒临时调到 100 到 150 毫秒持续 3 到 5 秒确保把完整的拿取/放回动作抓下来没有事件时则以低频率抽帧做背景建模和库存看护。3.3 优化抽帧时的画面卡顿问题很多人误以为“抽帧 跳帧处理”只要解码后丢弃一部分帧就行。但实际上抽帧造成的画面卡顿往往不是因为跳帧而是因为解码和取帧过程存在阻塞。在 Python 的 PyAV 或 OpenCV 里如果你在一个单线程里边解码边做业务处理一旦业务处理变慢解码就会阻塞缓冲区越积越大最终出现延迟越来越高、画面看着像幻灯片的情况。解决办法是解耦独立的解码线程只负责读取和缓存最新的几帧业务线程从缓存中取取到哪一帧算哪一帧逻辑上完全分离。这里有个“保留最新帧”而不是“按队列顺序消费”的小技巧。实时识别场景下如果业务处理速度跟不上解码速度你宁愿拿到最新的画面去做判断也不愿把时间浪费在排队处理旧帧上。所以我们一般用一个只保留最近 1 到 2 帧的环形缓存新帧来了直接覆盖旧帧业务线程永远取最新的。代价是如果处理一帧耗时过长中间过渡画面会丢但对售货柜的取放物识别来说逻辑上完全可接受。3.4 时间戳抽帧画面和业务事件对不上的根源抽帧流水线里最容易被忽视的是时间戳。摄像头是独立设备它的帧率由自己的晶振决定算法板卡的时钟是另一个时钟源业务系统记录事件又是第三个时钟源。如果不对齐就会出现“画面里拿商品的时间”和“重力传感器记录变重的时间”差了半秒甚至几秒融合逻辑根本没法做。对齐思路要分两层一是摄像头网络流内部的时间戳RTSP 的 RTP 包里本身带有时间戳可以通过 RTCP SR 报文的 NTP 时间戳和 RTP 时间戳换算出当前帧对应的绝对时间。二是在应用层做同步标记每抽出一帧时用本地系统时间打一个标签同时记录这帧是从哪个摄像头、哪个时间点拉出来的。最终做多传感器融合时统一以一个时钟源通常是边缘盒子本地时间为基准把所有数据映射到同一时间轴上。这个细节看起来比较底层但在做“视觉识别 称重联动”“视觉识别 开门信号联动”这类复合功能时特别关键。前期不把时间戳规范好后期融合逻辑会越写越乱。4. YOLO 识别与业务联动4.1 模型训练前的数据准备注意事项很多团队拿到售货柜项目第一反应是搜“商品识别数据集”但公开数据集和真实场景的差距很大。无论是超市货架、自动售货机里的饮料、零食、盒饭还是不同柜体层板材质、灯光颜色、玻璃反光都会直接影响模型效果。我总结下来训练数据要包含三维度类别维度、姿态维度、环境维度。类别维度要覆盖柜内实际售卖的商品并且注意同类商品不同包装版本要均衡姿态维度要考虑商品正放、倒放、侧放、堆叠、被手半遮挡的情况环境维度要考虑灯光变化、层板反光、玻璃反光、镜头角度变化。采集数据时不要只在理想光照下拍建议在不同时间段、不同柜门开闭状态下各采一部分。标注格式方面YOLO 使用的 txt 标注格式是class x_center y_center width height所有值都归一化到 0 到 1。如果数据是从一些公开数据集转过来的注意检查坐标是否正确归一化很多坑都出在格式转换时坐标除错。如果是从 KITTI、COCO 这类数据集转换还需要注意类别 ID 的映射关系别把“人”映射成“商品”的 ID这种错误在训练阶段很难发现上线后才会暴露。4.2 训练与推理时的“为什么”细节模型输入尺寸选多大售货柜商品通常是小目标层板纵深大同一个商品在不同层板上的像素尺寸差异很大。一个比较稳妥的做法是不要直接上 640x640可以先用 800 或 960 的训练尺寸看效果。代价是推理时间变长但小目标检测率会明显提升。具体尺寸要在“识别精度”和“推理帧率”之间做实验权衡。增强策略上除了常规的随机翻转、色域抖动还要针对柜内环境做“玻璃反光增强”——通过随机叠加半透明蒙版、模糊遮挡来模拟反光。这一步看着很 hack但在真实项目里能显著减少误检。如果数据里有大量手部遮挡的画面也可以对标注框做随机擦除模拟部分遮挡的情况。锚框、损失函数这些细节用 Ultralytics 的默认配置基本不会出大问题。我一般不推荐一开始就调 YOLO 的损失函数和网络结构先把数据、增强、输入尺寸这三块做到位模型效果通常已经能到可用的水平。真正需要自己调后处理时往往才是瓶颈所在。4.3 后处理不是只有 NMS很多人把“YOLO 识别”理解成“模型输出检测框 结果”实际上模型输出的 raw output 要经过解码、置信度过滤、NMS 去重才能变成稳定的检测结果。但在售货柜场景里这还不够更要命的是如何把“一帧画面的检测框”翻译成“一次拿取行为的判断”。NMS 的 IoU 阈值不建议直接套默认值。商品框通常比行人框更密集且存在大量小目标堆叠的排列IoU 阈值设得太高会压掉密集目标的框设得太低又会输出大量重叠框。我通常从 0.45 开始调观察误检和漏检两个方向的平衡。置信度阈值也一样。当前一版模型比较乐观、误检多就把置信度从 0.25 提到 0.4反之则降到 0.2 左右。每次调完要去真实柜内回放几段历史录像别只盯着测试集指标。4.4 拿取与放回事件的判断逻辑售货柜识别业务的最终输出通常是一个 SKU 级别的事件顾客拿了哪个商品、数量是多少、有没有放回。YOLO 检测框只是中间产物真正的事件判断要依赖跟踪和差分。一个被验证过可行的做法是在时间轴上做“检测框序列匹配”。让同一商品在不同帧里的检测框通过 IoU 或 Deep SORT 之类的方法关联起来形成一个 track。当 track 从画面中出现到消失记录这个商品在出现时和消失时是否还在柜内再结合运动轨迹方向来判断是被拿走还是放回。例如“商品框从柜内层板位置向外移动直到消失”是拿取“商品框从手部区域出现并移动到层板位置后静止”是放回。这里有个特别容易犯的经验错误直接用“商品从画面中消失”判断“商品被拿走”。因为手部可能在一段时间内遮住了商品某些姿态变化、柜门反光也会导致短暂的检测中断。直接丢弃轨迹会让一次动作被拆成“消失再出现”两段事件判断就不稳定。我的做法是保留一个“轨迹预死亡”状态允许跟踪框在 3 到 5 帧内丢失确认不再出现时才关闭轨迹。4.5 联动快门和重量传感器时的逻辑分层现在不少售货柜是“视觉 重力”双模识别。视觉识别速度通常快于重力稳定读数而且重力只能感知“柜内总重量变化”无法区分具体拿的是哪个商品视觉能区分具体 SKU但受遮挡、反光影响。两者是天然的互补关系需要的是一个分层仲裁逻辑。我的实际策略是视觉先输出候选事件拿取了哪个 SKU、置信度多少重量传感器随后输出总重量变化值。两者都进入一个仲裁模块如果视觉候选事件和重量变化匹配拿走的商品理论重量 ≈ 实际重量变化误差在允许范围内则直接确认事件如果不匹配则通知视觉模块回溯该时间窗口内的视频数据做二次识别或标记为“待人工审核”事件。这个仲裁层模仿了人类多感官融合的机制能显著降低单一传感器的错误率。仲裁层里最容易被忽略的是时间窗对齐。视觉事件有视频时间戳重量事件有传感器时间戳必须在同一时间轴上比较。我之前说过时间戳规范的重要性在这里就会体现得淋漓尽致。重量传感器稳定读数通常有 300 到 800 毫秒延迟仲裁窗口至少给 1 到 1.5 秒否则会因为时间错位把匹配不上误判成异常事件。5. 常见问题与排查技巧实录5.1 高延迟从“画面看起来慢人半拍”说起现象摄像头画面在识别端的延迟肉眼可见触发判断的时机总是比真实动作慢体验上像“慢动作”。排查顺序一般是这样的先确认是解码延迟还是预览播放延迟。如果是用 VLC 预览VLC 自带缓冲会多出几百毫秒延迟这不代表拉流环节有问题要用自己的程序打印每帧的到达时间来看真实延迟。然后是传输协议问题。优先切换rtsp_transport到 udp如果网络稳定延迟通常能降低 100 到 300 毫秒。接着检查解封装缓冲参数max_delay把它从默认值向小调。最后确认是不是解码积压导致帧排队可以通过打印解码队列长度判断。还有一种比较隐蔽的情况硬件平台本身没有硬件解码软件解码耗费过高导致实际解码帧率低于推流帧率帧队列越积越多。此时要么关闭 D2D 显示等额外开销要么上硬解。5.2 画面花屏或马赛克不一定是摄像头坏了现象识别端画面偶尔出现花屏、马赛克、绿屏但用摄像头自带 Web 页面看不明显。RTSP 走 UDP 时丢包是花屏最常见的原因。局域网里交换机的广播风暴、网线质量差、水晶头松动都会导致 RTP 包丢失I 帧丢了还会影响后续一长串画面的正常解码。解决思路是切换 TCP 传输代价是延迟略高同时对网络物理链路做检查更换质量好的网线和交换机端口。另一种花屏原因是解码器对不完整关键帧的处理太激进。H.264 画面组以 I 帧为关键帧如果刚开始拉流时碰上的第一个 I 帧数据不完整某些解码器会直接输出花屏画面。这种情况通常等待下一个 I 帧到达后会自动恢复。如果一直花屏就要判断是不是推流端本身有问题比如摄像头码流异常。5.3 抽帧“丢帧”但解码队列又没有积压现象程序明明设置了每 N 帧抽一帧但最终有效处理帧数远低于期望看起来像“丢帧”。这大概率不是真丢帧而是“取帧时机不对”。如果你的抽帧代码是从解码器的输出帧里去取但解码器在弱网环境下会自动跳帧以保持实时性那么有些帧你根本不会在解码端看到。要区分是“解码前网络丢帧”还是“抽帧策略丢弃的帧”可以在拉流端统计 RTP 序号或者在解码端同时输出每帧的时间戳做对比。如果 RTP 序列本身就有空洞说明问题出在网络链路抽帧策略再怎么优化也没用。这里也提醒一下不要盲目通过“降低抽帧间隔来弥补丢帧”。如果瓶颈是网络或解码减少抽帧间隔只会增加无效解码压力让系统更不稳定。正确方向是把网络和解码链路修稳再谈抽帧密度。5.4 小目标商品漏检一个不自知的“反光陷阱”现象整箱饮料、大瓶装商品都能识别但小瓶装、小包装零食总是漏检或检出置信度很低。售货柜里的小商品往往处于层板深处、灯光照射面积小、还可能被层板前缘遮挡。更隐蔽的是玻璃柜门的反光会让某些小目标的纹理变得很奇怪训练集里没有这种反光样本模型只能给低置信度。我的处理方法是“输入尺寸 采集增强”同步改。先把训练和推理的分辨率从 640 提到 960小目标的像素数变多了模型更容易提取特征。然后把采集素材里加入不同角度的玻璃反光和手部遮挡样本做随机反光增强。另外一个偏门但效果不错的技巧是分区域建模把柜内层板按物理位置划分成多个 ROI 区域分别做亮度归一化再送入模型能减少不同层板光照差异对检测的干扰。5.5 检测结果抖个不停置信度阈值和 NMS 的平衡现象同一个商品相邻两帧的类别标签不一致或者检测框在商品和背景之间反复横跳。这种问题通常不是单点造成的。先检查置信度阈值是否过低过低会把背景噪声框也放进结果导致输出序列不稳定再检查 NMS 阈值是否过高过高会让同一个目标的多余候选框同时存活叠加后产生抖动最后看模型本身如果训练的类别太多且相似商品外观接近比如不同品牌的白瓶饮料特征空间分不开也会导致帧间跳动。如果是后者单纯调阈值治标不治本需要在类别定义里合并外观相似但没有业务区分意义的类别或者在业务逻辑上引入时序平滑比如连续 3 帧类别一致才输出事件。5.6 模型推理占用过高导致整机卡顿现象跑起来后 CPU/GPU 占用接近满载业务接口延迟变大甚至系统日志出现 watchdog 超时。优先检查是不是“每条流一个推理线程”的写法。多路摄像头同时识别时如果每路都开一个独立的 YOLO 推理线程GPU 或 CPU 会频繁切换上下文效率极低。建议把多路的画面汇总到一个 batch 里做推理一次处理多张图吞吐量会有成倍提升。Ultralytics 的模型接口天然支持 batch 推理只需要把多帧拼成 tensor 输入。还要检查是否有人误把推理放到解码线程里同步执行导致解码被迫等待推理结束“拉流卡顿 看门狗超时”连环爆。务必保证解码线程绝对不跑模型推理只做取帧缓存。写在最后几个实际体会整条售货柜识别流水线跑下来我最深的一个感受是这活儿不像训练个模型跑个 Demo 那么简单真正的难点全在“工程链路的稳定性”和“多模块之间的协作逻辑”上。IPC 拉流断了要能自己恢复抽帧不能只看帧率而要看处理时延YOLO 模型的调优要结合柜内真实环境而不是死磕公开数据集指标拿取放回事件的判断要耐得住性子设计好跟踪与仲裁。另一个比较实用的心得是一定要从第一天起就给所有模块加统一的日志和时间戳标准。哪一帧是从哪路流出来的、什么时间到达、推理用了多久、输出事件在什么时间点确认这些日志是后期排查线上问题的唯一依赖。你可以没有很豪华的监控系统但关键节点打点一定要打全。如果你正在做类似的边缘视觉项目我建议按文章里的顺序来先把模拟器拉流跑通再把抽帧缓冲队列和时间戳做对然后才是模型训练和业务逻辑。前两步地基不打好后面每一步都有可能推倒重来。