从 YOLO 到实时视频 AI：SmartMediaKit 集成实践与工程思考

从 YOLO 演进到实时视频 AI：SmartMediaKit 的集成思路与技术实践

接触目标检测的这些年，我眼看着 YOLO 从实验室里的玩具变成生产环境中的主力。很多团队一开始是在图片上跑 YOLO，跑通一张图就开心半天，但一旦需要处理视频流、对接业务系统、部署到边缘设备，才发现“能检测”和“能落地”之间隔着一整条流水线。我自己踩过不少坑，也在 RK3588、x86 服务器、树莓派上反复折腾过部署方案，最后沉淀下来一套相对成熟的集成思路，也就是这套围绕 SmartMediaKit 构建的实时视频 AI 管线。这篇文章不是 YOLO 原理课，而是一个从“单帧检测”走向“实时视频 AI”的工程实践记录，适合那些已经能跑通 YOLO 训练、正准备把模型塞进视频业务里的开发者。

先说清楚 SmartMediaKit 在这个架构里的角色。它不是一个替代 YOLO 的检测算法，也不是一个花哨的 GUI 工具，而是把视频接入、解码、推理调度、后处理、结果分发串起来的中间层。你可以把 YOLO 看成一辆性能不错的引擎，把 SmartMediaKit 看成整车底盘和传动系统——没有后者，引擎再猛也只能在台架上空转。这篇文章会从整体设计讲到核心代码，再讲到边缘部署和问题排查，全程围绕“实时视频 AI”这条主线展开。

1. 从“单帧检测器”到“视频 AI 引擎”：SmartMediaKit 的定位与整体思路

1.1 YOLO 真正解决的是什么问题

YOLO（You Only Look Once）的核心贡献在于把目标检测定义成一个端到端的回归问题。早期的两阶段检测器先做区域提议再分类，精度不错但速度太慢，难以满足视频场景的帧率要求。YOLO 把整张图划分成网格，每个网格负责预测目标中心点落在自己区域内的检测框、类别和置信度，一次前向推理就能拿到所有目标信息。这种设计天然适合视频流——每一帧都独立检测，不用跨帧缓存复杂状态。

但这里有个容易被忽略的事实：YOLO 从头到尾都是一个单帧检测器。它接收的输入是一张静止图像，输出也是针对这张图像的检测结果。所谓“视频检测”，本质上就是把视频抽帧，逐帧送入 YOLO，再把结果按时间顺序拼起来。如果你只是把视频帧丢给 YOLO 然后拿到结果就完事，那只是一个“用 YOLO 处理视频”的小工具，还称不上“实时视频 AI”。真正的视频 AI 需要考虑帧率匹配、检测结果的时间平滑、目标消失与重现的跟踪逻辑、告警事件的去重与聚合，以及如何在资源有限的情况下保证推理吞吐。

1.2 为什么单独使用 YOLO 无法构成实时视频 AI

我见过不少团队一开始的架构很简单：OpenCV 读取视频帧，预处理后送进 YOLO，拿到结果画框显示。这个 Demo 在本地视频上跑得挺好，一换到网络摄像头就崩了——解码跟不上、推理占用过高、画面延迟越来越严重，最后进程直接卡死。问题出在哪？出在缺少对整条数据链路的管理。

实时视频 AI 至少包含以下环节：

• 视频接入：处理 RTSP、RTMP、GB28181、本地文件等多种协议，还要处理网络抖动导致的断流重连。
• 解码：视频编码格式复杂（H.264/H.265），解码器的性能直接决定你能同时处理多少路流。
• 帧率控制：摄像头可能 25fps，但推理可能只能跑到 12fps，需要决策是丢帧还是降采样。
• 推理：调用 YOLO 模型进行前向计算，这里涉及模型格式、精度、加速库的选择。
• 后处理：NMS（非极大值抑制）、置信度过滤、类别映射，还有针对业务场景的规则判断（比如吸烟检测需要看手部区域是否有烟头）。
• 结果分发：检测结果要推送到告警平台、数据库、WebSocket 或者消息队列，供上层业务消费。
• 监控与恢复：推理线程崩溃、显存泄漏、解码器卡死，这些都要有守护机制。

这些环节如果全部用手写胶水代码拼起来，每一路流都要处理一遍，代码量爆炸且无法复用。SmartMediaKit 的思路就是把这条链路抽象成可编排的流水线组件，让开发者只需要关心“业务逻辑”和“模型本身”，而不是每次都在解码和线程管理上重复造轮子。

1.3 SmartMediaKit 的模块划分与集成思路

我搭建 SmartMediaKit 时，按照职责边界把系统拆成了几个核心模块：

这七个模块合在一起就构成了一条可运行的实时视频分析管线。集成 YOLO 时，最核心的是 InferenceEngine 与 PostProcessor 这两个模块，因为模型本身并不关心视频协议和线程模型，它只关心输入张量。而 SmartMediaKit 做了一件关键的事：把视频帧统一包装成带时间戳的推理请求，让 YOLO 模型完全感知不到自己处理的是视频而非单张图片。

2. 核心环节拆解：推理流水线中的决定成败的细节

2.1 数据输入：帧率控制与缓存策略

视频流输入是整个链路的起点，也是问题的高发区。RTSP 流本身有网络延迟和抖动，如果解码器跟不上，帧缓冲区就会堆积，延迟指数级上升。我在 SmartMediaKit 里实现了一个可配置的帧池，默认容量是 2 秒的帧数（比如 25fps 就放 50 帧），超过容量后采取“丢弃最旧帧”的策略，保证推理端拿到的始终是较新的帧。

帧率适配是一个值得展开讲的问题。假设摄像头输出 25fps，模型推理只能处理 10fps，你该怎么办？粗暴的方案是每帧都送到推理节点，让推理积压；更好的方案是在 SourceManager 层做步长抽帧，或者根据推理时延动态调整抽帧间隔。我实测下来，简单按固定步长抽帧（比如每 2 帧取 1 帧）在多数监控场景已经够用，因为画面内容变化通常没有摄像头标称帧率那么快。

注意：抽帧不等于降低检测精度。在目标移动极快的场景（如高速出入口），不要盲目抽帧，否则会漏掉关键目标。此时优先考虑提高推理吞吐而不是降低输入帧率。

2.2 推理后端选择：PyTorch、ONNX、TensorRT 的取舍

同一个 YOLO 模型可以用不同的推理后端运行，速度差异可能是倍级的。我的经验是分阶段选型：开发调试用 PyTorch，集成测试用 ONNX Runtime，正式部署按硬件选 TensorRT 或 RKNN。

PyTorch 直接加载 .pt 权重最方便，但动态图和 Python 运行时开销大，在视频流高并发场景下容易出现 GIL 竞争和显存抖动。ONNX Runtime 是从 PyTorch 到生产环境的过渡带，导出 ONNX 时需要注意动态维度配置，我习惯把 batch 维度和宽高维度都设成动态，否则模型只能接收固定分辨率输入。TensorRT 在支持 CUDA 的 x86 平台上是性能天花板，尤其是 FP16 精度下吞吐能翻一倍多，但转换过程中的算子兼容问题需要花时间排雷。

RK3588 这类边缘设备走的是另一条路，需要用 RKNN-Toolkit 把 ONNX 模型转换成 RKNN 格式。这个转换过程踩过不少坑，后面专门讲，这里先强调一条原则：针对具体硬件做推理后端选型，不要迷信“通用万能”的部署方案。

2.3 后处理：从原始输出到业务告警的距离

很多人把 YOLO 的后处理简单理解为“跑一次 NMS”，但在实时视频 AI 场景，这远远不够。YOLO 模型的原始输出是一个巨大的张量，包含大量低置信度框，后处理需要完成以下步骤：

1. 阈值过滤：只保留置信度高于阈值的检测框。
2. NMS 去重：多个重叠框合并成一个，IoU 阈值通常取 0.45 左右。
3. 类别映射：把模型输出的 class id 映射到业务名称。
4. 坐标换算：把归一化坐标变回原始画面的像素坐标。
5. 业务规则判定：比如区域入侵检测需要判断目标中心点是否在多边形区域内，吸烟检测需要判断烟盒区域与嘴部区域是否靠近、是否持续出现。

第 5 步最容易被忽视。我一开始做烟火检测时，只做普通 NMS 就上报告警，结果每几秒就触发一次误报——因为画面里一闪而过的塑料袋也被当成目标。后来我在 PostProcessor 里增加了“连续多帧确认 + 告警冷却时间”机制：同一目标至少连续 3 帧出现在告警区域才触发事件，事件发生后 5 秒内不重复上报。这个策略直接砍掉了 80% 的误报。

2.4 性能瓶颈：解码、推理、编码之间的调度关系

实时视频 AI 是 IO 密集 + 计算密集的混合体，性能瓶颈往往不在推理本身，而在解码和预处理。我在 x86 服务器上测试时发现，用 OpenCV 的cv2.VideoCapture读 RTSP 流，CPU 自动软解 1080p H.264 视频可能占到 40% 左右的 CPU 资源，留给推理的算力所剩无几。解决办法是启用硬解：Intel 平台用 VA-API，NVIDIA 平台用 NVDEC，RK3588 用 MPP。

SmartMediaKit 中的 DecodePipeline 专门处理了这个问题，设计上有几条经验：

• 解码线程和推理线程分离，用有界队列解耦，避免解码卡顿直接阻塞推理。
• 每路流一个解码器实例，不要多路流共享一个解码器，否则会产生 PTS 错乱。
• 分辨率缩放放在推理前而非推理后，YOLO 输入尺寸统一缩放到模型要求的大小，但画框要映射回原始分辨率，避免直接在小图上标注。

3. 从数据集到模型：高质量模型是一切实时应用的起点

3.1 标注工具与数据集管理

YOLO 模型的效果天花板由数据集质量决定，这是无论换什么网络结构都无法突破的。标注工作最忌讳“差不多就行”，一个边界框偏了几个像素，对大目标影响不大，但对于小目标检测（比如监控画面中的人脸、烟火点）可能是致命误检。

我和团队现在常用的标注工具是 X-AnyLabeling，支持自动预标注，可以用已有模型先跑一遍生成粗标签，人工在此基础上修正，效率能提升两三倍。管理上，所有标注数据统一放在一个目录结构下：

dataset/ images/ train/ val/ labels/ train/ val/ data.yaml

data.yaml里声明类别列表和训练验证集路径，这是 YOLO 系训练工具的通用约定。注意标注类别 ID 必须从 0 开始连续编号，中间缺一个数字都会导致训练时类别映射错乱。

3.2 格式转换：KITTI 标注转 YOLO 的实战

业界常用数据集格式不少，KITTI 用于自动驾驶目标检测，COCO 用于通用物体检测，路径规划类的还有各种自定义文本格式。做工程集成时，格式转换是躲不过的。KITTI 标注是单个 TXT 文件里写入类别、框坐标、截断、遮挡等信息，转换到 YOLO 格式需要提取关键字段并做归一化。

写转换脚本的核心逻辑是把 KITTI 的 box 坐标（左上角 x、左上角 y、右下角 x、右下角 y）换算成 YOLO 的 center_x、center_y、width、height，并除以图像宽高。这里有个常见的坑：KITTI 图像和标签中的坐标可能经过缩放，导致转换后框偏移。转换前务必确认原图尺寸，必要时先恢复原始分辨率再做归一化。我在实际脚本里还会加一个“可视化校验”步骤，把转换后的 YOLO 标签画回图片上，人工抽查几个样本，这一步能拦截 90% 的坐标错位问题。

COCO 格式转 YOLO 同样常见，思路是利用 COCO 的 annotations 字段中的 bbox 数组，它本身就是 [x, y, width, height] 格式，相对简单，但仍需注意宽高是否为负数、坐标是否超出图像边界等数据质量问题。

3.3 训练参数建议：batch size、学习率与数据增强

训练 YOLO 自己的数据集，参数设置直接影响模型收敛效果。分享几个我实测后的参数组合：

• 输入分辨率：640x640 是通用选择，资源充足时可以上 1280 提升小目标检测能力，但推理速度会下降明显。
• batch size：单卡训练时尽量开大，但受显存限制。一般 8 或 16 比较均衡，混合精度训练可以再翻倍。
• 学习率：初始学习率推荐 0.01 或按 batch size 线性缩放。我习惯配合 warmup，前 3 个 epoch 线性上升到目标学习率，能避免初期 loss 爆炸。
• 数据增强：Mosaic 增强对密集小目标效果显著，但训练到后期建议逐步关闭，否则会抑制模型对真实尺度的学习。
• epoch 数：小数据集（几百张图）从 100 轮起步，看验证集 mAP 不再提升就早停。

3.4 什么情况下需要考虑改进模型结构

YOLO 版本迭代很快，从 v5、v8、v9、v10 到 v11 各有侧重。我在实际项目里不会盲目追新版本，而是根据任务特性选型：

• 通用目标检测：YOLOv8 / YOLOv11 是稳妥起点，前者的工程生态成熟，后者的 C3k2 模块和注意力机制有提升。
• 姿态估计：YOLOv8-pose 可以直接输出人体关键点，做吸烟、跌倒检测很合适。
• 实例分割：YOLOv9-seg / YOLOv11-seg 支持像素级分割，适合施工区域安全帽检测这类精细任务。
• 边缘部署：YOLOv5 的 ONNX / RKNN 转换链路最成熟；如果追求轻量化，可以考虑 YOLO 系列的 nano 版本，或是 NanoDet、RTMDet 等替代方案。

至于“改进模型”，我建议先想清楚要解决什么问题。是精度不够、小目标漏检，还是推理太慢？如果是精度问题，优先增加数据、调超参，而不是改网络结构。只有当你对数据增强和调参已经尽力、仍然不满意时，才考虑引入注意力机制（如 CBAM）、更换 Neck 结构（如 BiFPN）或做多模态融合。我做过的“YOLO 多模态融合”实践，是在红外和可见光双路输入时把特征在 Backbone 层做早期融合，效果确实优于单模态，但模型体积和推理开销也同步上升，部署时要仔细权衡。

4. 实操全流程：把 YOLO 接入 SmartMediaKit 并跑通实时视频分析

4.1 环境准备与依赖安装

以一台 Ubuntu 20.04 的 x86 服务器为例，需要安装以下基础组件：

• Python 3.8+，建议 3.10 或 3.11
• CUDA 11.8 + cuDNN 8.6（如果走 NVIDIA 推理）
• ONNX Runtime GPU 版或 TensorRT 8.x
• 视频处理相关：FFmpeg 4.x、OpenCV 4.x（源码编译开启 GStreamer 支持更好）
• Python 依赖：numpy、opencv-python、ultralytics、fastapi、websockets

依赖安装的坑主要在 OpenCV 上。PyPI 上默认的opencv-python不带 FFmpeg 支持，读取 RTSP 时可能报错或者异常卡顿。我的经验是直接用apt install python3-opencv搭配系统 FFmpeg，或者从源码编译开启 FFmpeg 选项，这样 RTSP 解码的稳定性好得多。

4.2 对视频流执行推理的核心代码

SmartMediaKit 的 InferenceEngine 层我封装成了一个统一的推理类。核心思路是：无论底层是 PyTorch、ONNX Runtime 还是 TensorRT，对外都暴露同一个infer(frame_batch) -> detections接口。这样业务层不关心模型具体跑在哪个后端，切换推理后端时只需要改配置。

下面是一个基于 ONNX Runtime 的推理节点简化实现，实际项目里我加上了 TensorRT 分支和 RKNN 分支，但结构保持一致：

import cv2 import numpy as np import onnxruntime as ort class YOLOInference: def __init__(self, onnx_path, input_size=640, conf_thres=0.25, iou_thres=0.45): self.input_size = input_size self.conf_thres = conf_thres self.iou_thres = iou_thres so = ort.SessionOptions() so.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL self.session = ort.InferenceSession(onnx_path, so, providers=['CUDAExecutionProvider', 'CPUExecutionProvider']) self.input_name = self.session.get_inputs()[0].name def preprocess(self, frame): img = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) img, ratio, (pad_w, pad_h) = self.letterbox(img, new_shape=(self.input_size, self.input_size)) img = img.transpose(2, 0, 1).astype(np.float32) / 255.0 img = np.expand_dims(img, axis=0) return img, ratio, pad_w, pad_h def letterbox(self, img, new_shape=(640, 640), color=(114, 114, 114)): shape = img.shape[:2] r = min(new_shape[0] / shape[0], new_shape[1] / shape[1]) new_unpad = (int(round(shape[1] * r)), int(round(shape[0] * r))) dw = (new_shape[1] - new_unpad[0]) / 2 dh = (new_shape[0] - new_unpad[1]) / 2 if shape[::-1] != new_unpad: img = cv2.resize(img, new_unpad, interpolation=cv2.INTER_LINEAR) top, bottom = int(round(dh - 0.1)), int(round(dh + 0.1)) left, right = int(round(dw - 0.1)), int(round(dw + 0.1)) img = cv2.copyMakeBorder(img, top, bottom, left, right, cv2.BORDER_CONSTANT, value=color) return img, r, dw, dh def postprocess(self, output, ratio, pad_w, pad_h, orig_shape): # output shape: [1, 84, 8400] for YOLOv8, need transpose predictions = output[0].transpose((0, 2, 1)) # [1, 8400, 84] boxes = [] for pred in predictions[0]: class_scores = pred[4:] class_id = np.argmax(class_scores) confidence = class_scores[class_id] if confidence < self.conf_thres: continue cx, cy, w, h = pred[:4] x1 = (cx - w / 2 - pad_w) / ratio y1 = (cy - h / 2 - pad_h) / ratio x2 = (cx + w / 2 - pad_w) / ratio y2 = (cy + h / 2 - pad_h) / ratio x1 = max(0, min(x1, orig_shape[1])) y1 = max(0, min(y1, orig_shape[0])) x2 = max(0, min(x2, orig_shape[1])) y2 = max(0, min(y2, orig_shape[0])) boxes.append([x1, y1, x2, y2, confidence, class_id]) # NMS keep = self.nms(boxes, self.iou_thres) return [boxes[i] for i in keep] def nms(self, boxes, iou_thres): if not boxes: return [] boxes = np.array(boxes) x1, y1, x2, y2, scores = boxes[:, 0], boxes[:, 1], boxes[:, 2], boxes[:, 3], boxes[:, 4] areas = (x2 - x1) * (y2 - y1) order = scores.argsort()[::-1] keep = [] while order.size > 0: i = order[0] keep.append(i) if order.size == 1: break xx1 = np.maximum(x1[i], x1[order[1:]]) yy1 = np.maximum(y1[i], y1[order[1:]]) xx2 = np.minimum(x2[i], x2[order[1:]]) yy2 = np.minimum(y2[i], y2[order[1:]]) inter = np.maximum(0.0, xx2 - xx1) * np.maximum(0.0, yy2 - yy1) iou = inter / (areas[i] + areas[order[1:]] - inter) inds = np.where(iou <= iou_thres)[0] order = order[inds + 1] return keep def infer(self, frame): orig_shape = frame.shape[:2] img, ratio, pad_w, pad_h = self.preprocess(frame) output = self.session.run(None, {self.input_name: img}) detections = self.postprocess(output, ratio, pad_w, pad_h, orig_shape) return detections

这个类就是 SmartMediaKit 中推理节点的核心。letterbox是 YOLO 系标准的等比缩放补边操作，后处理里面的坐标换算绕过了很多教程里的错误做法——直接用缩放后的坐标画框，导致框偏移。这里的ratio和pad_w/pad_h是同步传回去的，保证标注坐标始终回回到原图尺度。

在 PostProcessor 中，我还会对detections做业务层加工。比如做区域入侵检测时，会预先输入一个多边形列表，然后判断检测框中心点是否在多边形内，并且要维护一个“目标 ID 表”来实现“连续 N 帧命中才算事件”的确认逻辑。这一步往往才是业务方真正关心的功能。

class RegionIntrusionRule: def __init__(self, polygon, min_frames=3, cooldown=5.0): self.polygon = polygon # [[x1,y1],[x2,y2],...] self.min_frames = min_frames self.cooldown = cooldown self._tracker = {} self._last_alarm_times = {} def check(self, detections, timestamp): triggered_targets = [] for det in detections: class_id = int(det[5]) cx = (det[0] + det[2]) / 2 cy = (det[1] + det[3]) / 2 if self._in_polygon(cx, cy): key = (class_id, round(cx // 20), round(cy // 20)) self._tracker[key] = self._tracker.get(key, 0) + 1 if self._tracker[key] >= self.min_frames: if timestamp - self._last_alarm_times.get(key, 0) > self.cooldown: triggered_targets.append(det) self._last_alarm_times[key] = timestamp else: self._tracker[key] = 0 return triggered_targets

这种min_frames加cooldown的组合，是我在生产环境里调出误报率最低、漏报率可接受的一套方案。直接把检测结果上抛的业务系统，上线第一周就会被告警轰炸到关停。

4.3 边缘设备部署：RK3588 场景的专项适配

RK3588 是边缘部署的常见芯片，8 核 ARM + NPU 6 TOPS 算力。把 YOLO 模型跑在这个平台上，最大的工作量在模型转换。我用 RKNN-Toolkit2 的经验是：

1. 转换前置操作：先把 PyTorch 模型导出为 ONNX，尽量用 opset 12，避免过高版本导致 RKNN 不支持。
2. 量化：RK3588 上的 NPU 通常优先走 INT8 量化，量化需要准备一张校准数据集，建议选 100~200 张有代表性的图，覆盖各种光照和目标形态。
3. 输出格式：部分 RKNN 模型转换后输出格式和原始 YOLO 不完全一致，需要在后处理层做适配。比如 YOLOv8 的 ONNX 本来就带了后处理部分，导出时可以选择不带后处理的原始输出，交给 RKNN 的 Python/C 接口做 NMS。
4. 输入格式：RKNN 推理默认输入是 NHWC 布局，而 PyTorch 习惯是 NCHW，转换后推理前必须正确转换字节顺序，否则检测结果直接错乱。

我实际在 RK3588 上跑 YOLOv8n 的经验数据是：输入 640x640，INT8 量化后单路推理大约 30ms，加上前后处理，跑实时 25fps 的输入流没问题，可以同时接 4 路摄像头。

4.4 事件回调与告警输出

推理结果只有发给业务系统才会产生价值。SmartMediaKit 的 EventDispatcher 组件统一处理事件分发，我常用的订阅方式有两种：

• WebSocket 推送：适合实时展示面板，前端拿到检测结果后直接在画面上叠加框。心跳机制要单独做，否则断线后客户端完全无感知。
• HTTP 回调：适合对接告警平台。发送 JSON 数据包，包含事件 ID、时间戳、摄像头 ID、检测框坐标、置信度、截图的 Base64 编码。

回调失败是最常见的生产问题之一。业务接口可能超时或拒绝，如果回调线程是阻塞式的，整个事件队列会越积越多。我的做法是引入独立的回调 Worker，失败后重试 3 次，仍失败则写入本地磁盘队列，供运维侧拉取补推。

class EventDispatcher: def __init__(self, webhook_url=None, max_retry=3): self.webhook_url = webhook_url self.max_retry = max_retry self._queue = queue.Queue(maxsize=1000) self._worker = threading.Thread(target=self._run, daemon=True) self._worker.start() def publish(self, event): try: self._queue.put_nowait(event) except queue.Full: # 队列满时丢弃非关键事件，或者落盘 logger.warning("event queue full, drop event") def _run(self): while True: event = self._queue.get() for attempt in range(self.max_retry): try: requests.post(self.webhook_url, json=event, timeout=2) break except Exception: time.sleep(0.5 * (attempt + 1))

这段代码看起来简单，但把“异步化”“重试”“熔断”三个关键点都覆盖了。生产环境里千万别在推理线程里直接发 HTTP 请求，一个慢接口就能拖垮整条视频链路。

5. 常见问题排查与调优实录

5.1 帧率上不去，问题到底在哪

遇到帧率低，我一般按以下顺序排查：

1. 解码是否成为瓶颈：观察 CPU 使用率和解码线程的队列积压。如果解码线程积压持续增长，说明解码跟不上，优先开启硬解。
2. 预处理是否拖慢：多次cv2.resize和颜色转换很耗时。用profile找到耗时函数，必要时把图像缩放从 Python 层移到 C++ 扩展或 GPU 上。
3. 推理后端是否生效：确认 ONNX Runtime 真的使用了 CUDA provider，而不是静默回退到 CPU。打印session.get_providers()查看一下。
4. 后处理是否过度：如果单帧检测到 200 个目标，纯 Python 的 NMS 循环会吃掉大量时间。可以用向量化的 numpy 实现，或者用 C++ 编排的 NMS 算子。

我在一次客户现场排查时，发现对方“已经用了 TensorRT”，但实际推理耗时高达 120ms。最后定位到问题：他们加载的是 FP32 引擎，而不是 FP16。换成 FP16 后，推理时间直接降到 35ms。这个案例让我养成了检查推理引擎精度的习惯。

5.2 检测框乱跳与漏检，是模型问题还是后处理问题

检测框在视频流里前后帧抖动，可能是两个原因：

• 单帧检测本身的随机性：阈值临界的目标容易被丢弃，导致同一目标时而出现时而消失。
• 没有做时间平滑：即使目标一直在画面里，检测框也在小幅漂移，直接画在视频上会显得非常不稳定。

我的处理方案是将检测结果接入一个轻量级的轨迹平滑模块，不一定要上 ByteTrack 或 SORT 这类完整追踪器，简单用“最近邻匹配 + 指数移动平均”就能消除 80% 的视觉抖动。核心代码并不复杂，为每个检测框记录历史坐标，然后用平滑系数更新当前输出坐标。

漏检则大多与输入和模型有关。首先检查是否开启了合理的置信度阈值，我默认用 0.25，业务上想减少漏报可以降到 0.15，但误报会略升。其次检查图像缩放方式，如果直接用cv2.resize拉伸到模型输入尺寸，目标比例失真会影响检测，换成letterbox基本可以解决。

5.3 显存和内存泄漏排查

长时间跑视频分析，最怕的就是内存/显存一路上涨，最后进程被系统杀掉。这类问题通常来自：

• OpenCV Mat 对象未释放：Python 的cv2对象有 GC 管理，但如果你在循环里保留了帧引用，还是会造成内存增长。
• 图模式切换：PyTorch 中每次推理都重新计算图会导致显存碎片化，尽量用torch.no_grad()和torch.inference_mode()，并把模型切换到 eval 模式。
• ONNX Runtime 的 IO 绑定：如果每帧调用都新建输入输出张量，会造成显存碎片。建议用预分配的 OrtValue 做 IO Binding。

排查工具方面，我通常用nvidia-smi实时查看显存、用psutil记录进程内存曲线。进一步可以开启torch.cuda.memory_summary()打印显存分配详情，找到泄漏的具体张量。

5.4 多路视频并发的性能分配

同时处理多路视频时，不能简单地为每路流启一个进程。更好的做法是采用共享推理引擎的方式：多路视频帧统一进入一个较大的 batch 进行推理。这充分利用了 GPU 并行能力，避免了多路推理时频繁切换带来的开销。

SmartMediaKit 中实现了一个动态 Batch 机制，思路是：

• 多个 SourceManager 线程把自己的帧投递到 BatchingQueue。
• BatchingQueue 每隔 8ms（可配）收集一次队列中的视频帧，凑成一个 batch 送入推理引擎。
• 推理完成后，按 batch 索引拆回各路流的检测结果。

这个方案在 8 路视频场景下实测，GPU 利用率可以从单路推理的 30% 提升到 80% 以上，可以说是多路场景下性价比最高的优化手段。需要注意的是，如果各路流的输入分辨率不一致，动态 Batch 需要预处理成统一尺寸，否则无法拼成一个张量。

在做这套实时视频 AI 集成的过程中，我最大的体会是：YOLO 模型本身只占整个系统的一小部分，真正的工程量在视频链路、并发调度、事件管理和部署适配这些“看不见”的地方。如果你也在搭类似的平台，我建议先别急着堆功能，把视频接入、推理抽象、结果分发这三层骨架搭稳，再往里面填模型和业务规则。最后再分享一个小技巧：所有实时视频分析系统，上线之前一定要做 7x24 小时的稳定性测试，很多人死在长时间运行的隐性泄漏和线程异常上，而不是死在模型精度上。把日志和监控指标留好，后续调优会轻松非常多。