Java调用Python YOLO视频目标检测：ONNX导出与部署实战

简介：面向需要在Java服务中集成实时目标检测能力的开发者，这套方案以Java与Python协作为核心，支持YOLOv5、YOLOv7、YOLOv8主流模型导出为ONNX后直接调用。包内含68个文件，压缩包约271.96MB，包含17个Java源文件、1个Python脚本、5个ONNX模型、大量png/jpg演示截图与gif/mp4效果录屏；Java端承担视频流获取、预处理、数据传递与后处理绘图，Python端负责模型加载与推理，两者通过JNI等机制衔接，可对接RTSP/RTMP视频流，便于扩展到实时监控等场景。资源还附有XML配置、动态库等辅助文件，目录结构清晰。目前已有265人学习下载，适合有一定Java和深度学习基础、希望快速跑通跨语言目标检测管线的开发者。案例涵盖跳绳姿态计数、安全帽检测与车辆检测，展示了目标检测和姿态估计在真实场景中的落地方式，附带README文档有助于快速理解工程结构。

1. 为什么 Java 服务要绕一圈去调 Python 的 YOLO：这条技术路线解决什么问题

如果你的 Java 后端要接视频目标检测，算法同事多半会先交给你一个 YOLO 模型，而训练、验证、导出的工具链都在 Python 侧。于是任务常被描述成“Java 调用 Python YOLO ONNX 模型进行视频目标检测与识别”。我第一次做这个需求时也以为要把 Python 进程拉起来做推理，后来才发现，Python 只在导出模型时出场，生产环境里 Java 直接加载 ONNX 才是更顺手的路径。

这个方案的本质是：用 Python 生态把 YOLOv5、YOLOv7、YOLOv8 的权重转成 ONNX，Java 端借助 ONNX Runtime 在进程内做推理，检测结果直接回到业务里。ONNX 是那个跨语言黑匣子，把 PyTorch 的计算图固化下来，Java 不需要理解 Python 侧的细节。适合已经有 Java 后端、想少引入新语言服务的团队。读完你会清楚怎么选路线、怎么导出、Java 端怎么跑通，以及帧率上不去时该查哪里。

2. 三条落地路线与选型：子进程、HTTP 推理服务还是 Java 直跑 ONNX Runtime

2.1 跨语言调用的三种常见形态和各自代价

把 Python 模型在 Java 里用起来，常见做法无非三类。

第一类：Java 用 ProcessBuilder 或 Runtime.exec 直接拉起 python 脚本，把图像路径或帧数据传过去，再从标准输出读检测结果。看着最直接，但每次启动 Python 解释器都有几百毫秒的开销，而视频流是逐帧连续的，根本扛不住；跨进程传图还要经过中间文件或 stdin/stdout，数据拷贝和序列化又吃掉一部分时间。除非做离线批处理，否则不建议放进实时链路。

第二类：Python 起一个 HTTP 推理服务，比如 FastAPI 或 Flask，Java 把帧推过去，服务返回 JSON 格式的检测框。这个方案在工程上最干净，模型和业务彻底解耦，算法更新权重时只需要重启 Python 服务，Java 这边不用发版。代价是请求多一次网络往返，即使是本机回环也有序列化和反序列化的损耗；多路视频并发时，两边的线程模型叠在一起，瓶颈会很难定位。

第三类：Python 只负责把模型导出成 ONNX，Java 用 ONNX Runtime 直接加载推理，预处理、后处理全部在 Java 进程内完成。没有跨进程启动，没有网络开销，线程模型完全由 Java 控制。这也就是后面会重点展开的路线，但同时我会给你留一条第二类方案的兜底通道，毕竟有些团队的生产约束不允许这么做。

2.2 我一般怎么选型：看模型迭代频率和实时性要求

如果模型还在频繁试错阶段，算法同事每两天就换权重，我会选 HTTP 服务。模型热加载，Java 端只改配置指到新服务地址，省去反复发版。如果需求是“某一个视频文件跑一遍检测”，子进程方案反而是最快的，几分钟就出一个结果，不值得为它搭一套服务。

一旦进入“多路摄像头持续检测”这类实时链路，Java 直跑 ONNX 几乎是必然选择。选型的判断依据只有三条：单帧延迟能不能压到可控范围、模型能不能热替换、Java 侧要不要发版。把这三条想清楚，方案自然就出来了。我见过团队用子进程写 demo 挺顺利，接入真实视频流之后立刻翻车，最后都回到 ONNX Runtime 上。实时视频检测对延迟敏感，跨进程方案从架构上就先输了一步。

2.3 ONNX 为什么能把 PyTorch 模型固化住

这个方案成立的前提，是 ONNX 已经是一个成熟的中间表示。PyTorch 模型训练好之后还是带动态图语义的，依赖 Python 对象和运行环境；导出成 ONNX 后变成一张静态计算图，算子、权重、输入输出形状全部固化在一个文件里。Java 侧不需要任何 Python 运行时，只要 ONNX Runtime 支持这些算子就能推理。

要留意“算子支持范围”这件事。YOLOv5、YOLOv7、YOLOv8 导出时会把结构翻译成 ONNX 算子，算子版本以 opset 表示。opset 太高，Java 端的 ONNX Runtime 可能不认；太低，某些结构表达不出来。常见做法是显式指定 opset=12，下一章我会给出具体命令。这个参数在跨语言方案里最容易埋雷，先记住它是第一类排查对象。还有一点：ONNX 的输入输出都是带名字的 tensor，Java 端按名字取值。能把“名字”和“形状”这两样对齐，后面的代码就成功了一半。

3. 从 YOLOv5/v7/v8 导出 ONNX：导出命令、输出结构差异与检查方法

3.1 导出前的环境准备：不同 YOLO 版本的导出工具不一样

YOLOv5 和 YOLOv7 是源码仓库的形式，仓库里自带 export.py；YOLOv8 收敛进了 ultralytics 这个 Python 包，一行命令就能导出。所以你会同时接触两套导出习惯，这很正常，别指望一个脚本吃遍三个版本。

环境准备上，我习惯为每个模型版本单独建虚拟环境，避免 PyTorch 依赖互相打架。常见做法是 Python 3.8 以上，安装对应版本的 PyTorch、onnx、onnxruntime。YOLOv5 和 YOLOv7 进仓库后执行 pip install -r requirements.txt；YOLOv8 直接 pip install ultralytics。ultralytics 包会自带 torch，装完先导入一下 torch 确认 CUDA 可用，再去导出，免得 GPU 机器白忙一场。网上关于 ultralytics 环境配置的文章很多，核心就一条：依赖版本以官方仓库要求为准，不要混着装。

3.2 YOLOv5 与 YOLOv7：经典 export.py 的参数含义

在 YOLOv5 仓库根目录下，导出命令常见是这样：

python export.py --weights yolov5s.pt --img 640 --batch 1 --include onnx --opset 12

参数说明：

• --weights：权重文件路径。官方预训练权重可以直接用，自己训练的模型就用训练产出的 best.pt。
• --img 640：模型输入尺寸。视频检测里 640 是精度和速度之间常用的折衷值。改成 320 会更快但小目标容易丢，改成 1280 会更准但显存和耗时都上去了。
• --batch 1：导出 batch 固定为 1。视频流逐帧处理，1 足够。开动态 batch 虽然灵活，但 Java 端构造输入要多写不少代码。
• --include onnx：指定导出格式，想同时导出其他格式可以写成 onnx,engine。
• --opset 12：ONNX 算子集版本。显式固定 12，是为了避免默认值太高导致 Java 端运行时版本不认。

YOLOv7 的导出命令结构一样，python export.py --weights yolov7.pt --img 640 --batch 1 --include onnx。有些分支版本多一个 --grid 参数，决定是否在模型内部解码预测结果。建议保持默认，把后处理留在 Java 侧，这样行为最可控。

导出开关里的 normalize 方式和输入尺寸，一定要记录下来。Java 端预处理必须和导出时的约定保持一致，否则检测框一定漂。这是后处理对不上号的第一原因。

3.3 YOLOv8：ultralytics 命令与输出头的变化

YOLOv8 的导出命令变成这样：

yolo export model=yolov8n.pt format=onnx imgsz=640 opset=12 dynamic=False

参数说明：

• model：权重文件或模型名称，yolov8n.pt 是 nano 版本，体积小，适合先跑通链路。
• format=onnx：导出为 ONNX。
• imgsz=640：输入尺寸，作用和 YOLOv5 的 --img 一致。
• dynamic=False：关闭动态轴。视频检测里输入尺寸固定，关闭能减少算子复杂度。
• opset=12：同样固定算子集版本。

YOLOv8 导出的 ONNX 输出结构和 v5/v7 有一段关键差异，新手特别容易在这里踩坑。YOLOv5 和 YOLOv7 的输出形状一般是[1, 25200, 85]：25200 是三个尺度下所有预测位置的数量，85 维中前 5 个是 x、y、w、h 和 objectness 置信度，后面 80 维是 COCO 类别概率。而 YOLOv8 的输出形状是[1, 84, 8400]：8400 是它三个尺度特征图的总格子数，84 维包含 4 个坐标加 80 个类别概率，没有独立的 objectness 分支。原因是 YOLOv8 在损失函数设计上把目标分数和分类分数合并了。

这个差异直接决定 Java 后处理怎么解析数组，第四章会给出对应解析方式。如果你用别的模型版本，比如某些 YOLOv5 改版，输出结构可能还有细微差别，务必以实际导出的 shape 为准。

3.4 导出后用 onnxruntime 检查输入输出，顺便确认 opset

导出完不要急着扔给 Java。先用 Python 的 onnxruntime 加载一次，确认输入输出名字和形状，同时跑一次推理留下基线结果：

import onnxruntime as ort import numpy as np session = ort.InferenceSession("yolov8n.onnx", providers=["CPUExecutionProvider"]) for inp in session.get_inputs(): print("input name:", inp.name, "shape:", inp.shape, "type:", inp.type) for out in session.get_outputs(): print("output name:", out.name, "shape:", out.shape, "type:", out.type) x = np.random.randn(1, 3, 640, 640).astype(np.float32) res = session.run(None, {"images": x}) print("output sample:", res[0].shape)

这段代码的作用有三个。第一，拿到输入 tensor 的名字，YOLO 系列常见是 images，Java 端构造输入时必须用同一个名字。第二，拿到输出 tensor 的名字，常见是 output0。第三，确认输出形状，看到 [1, 84, 8400] 就知道是 v8，看到 [1, 25200, 85] 就知道是 v5/v7。

输入输出的 shape 里如果出现 None，比如[None, 3, 640, 640]，说明导出了动态 batch。视频流场景我一般建议固定 batch=1 导出，Java 端省掉一堆形状判断逻辑。

3.5 别急着量化：FP32 先跑通，int8 再考虑

看到 ONNX 文件几百 MB，很多人第一反应是量化。我的习惯是先用 FP32 把整条链路跑通，确认检测结果正确，再考虑 int8 量化。YOLO 系列的检测头对量化敏感，尤其 v8 这种输出结构，量化后容易出现小目标丢失和置信度漂移。

如果确实要压体积提帧率，常见做法是先做动态量化或 int8 量化实验，然后用同一批测试视频对比量化前后的检测框数量与置信度。没有对比数据的量化就是给自己挖坑，模型小了一半，误检翻了一倍，得不偿失。量化后的模型同样用 3.4 节的脚本检查输入输出，确认结构和 FP32 版本一致再接到 Java 端。

4. Java 端集成：加载 ONNX、读视频流、后处理画框的最小闭环

4.1 Maven 依赖：ONNX Runtime 与 JavaCV

Java 端依赖集中在两个库：onnxruntime 负责推理，JavaCV 负责视频解码和图像操作。pom.xml 核心依赖如下：

<dependency> <groupId>com.microsoft.onnxruntime</groupId> <artifactId>onnxruntime</artifactId> <version>${onnxruntime.version}</version> </dependency> <dependency> <groupId>org.bytedeco</groupId> <artifactId>javacv-platform</artifactId> <version>${javacv.version}</version> </dependency>

版本号建议按实际环境选。onnxruntime 的版本要能解析 opset 12，javacv 则挑一个较新的修复版即可。如果部署机器有 NVIDIA GPU，把第一个依赖换成 onnxruntime-gpu，推理算子会落到 GPU 上，但要确认 CUDA 驱动和运行库版本匹配，否则启动时直接报加载失败。

加载模型的代码很简单：

import ai.onnxruntime.OrtEnvironment; import ai.onnxruntime.OrtSession; OrtEnvironment env = OrtEnvironment.getEnvironment(); OrtSession session = env.createSession("yolov8n.onnx", new OrtSession.SessionOptions());

这段有一个工程要点：session 要在服务启动时创建一次并复用，不要在每帧检测时重建。ONNX Runtime 内部会维护线程池和内存分配器，频繁创建 session 就是在给自己制造卡顿。一个服务里如果有多路视频流，可以共用同一个 session，后续我会讲线程模型怎么搭。

4.2 读视频帧并完成 letterbox 预处理

视频帧来源可以是本地文件，也可以是一路 RTSP 流。用 JavaCV 的 FFmpegFrameGrabber 拉帧：

FFmpegFrameGrabber grabber = new FFrameGrabber("rtsp://your-camera-stream"); grabber.start(); Frame frame; while ((frame = grabber.grab()) != null) { // 在这里处理每一帧 } grabber.stop();

拿到的 Frame 先转成 OpenCV 的 Mat，再做 letterbox 缩放。为什么不直接 resize 成 640x640？因为那样会拉伸画面，目标的长宽比失真，检测框也跟着变形。letterbox 的做法是保持长宽比缩放，短边用灰色填充，模型只看到未失真的内容。对应代码：

public static float[] preprocess(Mat src, int inputSize, float[] meta) { Mat resized = new Mat(); float scale = Math.min((float) inputSize / src.cols(), (float) inputSize / src.rows()); Size newSize = new Size(Math.round(src.cols() * scale), Math.round(src.rows() * scale)); resize(src, resized, newSize); Mat canvas = new Mat(inputSize, inputSize, CV_8UC3, new Scalar(114, 114, 114)); int dx = (inputSize - newSize.width) / 2; int dy = (inputSize - newSize.height) / 2; resized.copyTo(canvas.rowRange(dy, dy + newSize.height).colRange(dx, dx + newSize.width)); float[] tensor = new float[1 * 3 * inputSize * inputSize]; // 这里要把 canvas 的 BGR 顺序换成 RGB，再从 HWC 布局转成 CHW， // 最后把像素值除以 255.0 归一化到 0~1 区间。 // scale、dx、dy 放到 meta 数组里返回，后处理映射坐标时要用。 return tensor; }

代码里三个关键信息必须同步保存：scale 用于把检测框从 640 图还原到原图；dx、dy 是灰边填充偏移；归一化方式要和模型训练一致，YOLO 系列常见是除以 255.0。这三样任何一个和后处理对不上，框就是歪的。实际工程里我不会用返回值数组塞 meta，建议定义一个内部类同时装 tensor、scale、dx、dy，便于维护。

4.3 推理与后处理：置信度过滤、NMS、坐标映射回原图

预处理得到 float 数组后，构造 OnnxTensor 并推理：

OnnxTensor inputTensor = OnnxTensor.createTensor(env, tensor, new long[]{1, 3, inputSize, inputSize}); try (OrtSession.Result result = session.run(Collections.singletonMap("images", inputTensor))) { float[][][] output = (float[][][]) result.get(0).getValue(); // YOLOv8: output 的形状是 [1, 84, 8400] // YOLOv5/v7: output 的形状是 [1, 25200, 85] }

这里必须用 try-with-resources。OrtSession.Result 涉及堆外内存，不及时释放的话，视频流跑几分钟内存就开始涨。Java 的 GC 管不到它，这点特别容易漏。

后处理按 v8 举例：取 8400 个预测位置，每个位置 84 个 float，前 4 个是中心坐标和宽高，后 80 个是类别概率。先过滤低于置信度阈值的，再做 NMS 去重。NMS 的作用是同一个目标只保留置信度最高的框，否则一个行人会被框三条边。Java 里写一个两层循环版本够用：

public static List<float[]> nms(List<float[]> boxes, float iouThreshold) { boxes.sort((a, b) -> Float.compare(b[4], a[4])); List<float[]> keep = new ArrayList<>(); while (!boxes.isEmpty()) { float[] best = boxes.remove(0); keep.add(best); boxes.removeIf(b -> computeIou(best, b) > iouThreshold); } return keep; } private static float computeIou(float[] a, float[] b) { float aX1 = a[0] - a[2] / 2, aY1 = a[1] - a[3] / 2; float aX2 = a[0] + a[2] / 2, aY2 = a[1] + a[3] / 2; float bX1 = b[0] - b[2] / 2, bY1 = b[1] - b[3] / 2; float bX2 = b[0] + b[2] / 2, bY2 = b[1] + b[3] / 2; float interX = Math.max(0, Math.min(aX2, bX2) - Math.max(aX1, bX1)); float interY = Math.max(0, Math.min(aY2, bY2) - Math.max(aY1, bY1)); float inter = interX * interY; float union = (aX2 - aX1) * (aY2 - aY1) + (bX2 - bX1) * (bY2 - bY1) - inter; return union > 0 ? inter / union : 0; }

置信度阈值常见设在 0.25 到 0.45 之间，NMS 的 IoU 阈值常见用 0.45 到 0.5。这两个参数直接决定误检和漏检的平衡，不要照抄网上的值，要拿自己场景的测试视频调一遍。

保留下的框坐标是相对 640x640 输入图的归一化值，映射回原图：

float x1 = (cx - w / 2 - dx) / scale; float y1 = (cy - h / 2 - dy) / scale; float x2 = (cx + w / 2 - dx) / scale; float y2 = (cy + h / 2 - dy) / scale;

到这里，检测框已经从“模型看到的灰边图”还原成“原始视频分辨率里的真实坐标”。很多人的框整体往左下或右上漂，就是在这里漏了减 dx、dy，或者顺序反了。

注意：YOLOv5/v7 有独立的 objectness，要先算 objectness 乘以类别概率作为最终置信度；YOLOv8 不需要这一步，类别概率直接用。两个版本的解析循环结构不同，别想着写一套通用代码硬套。

4.4 必须保留的兜底通道：Java 用 ProcessBuilder 调常驻 Python 进程

前几节是 Java 直跑 ONNX 的主路径。但标题既然是 Java 调用 Python，我在这里留一条兜底通道：有些团队坚持把 Python 作为推理执行方，或者 Python 侧有复杂的自定义预处理逻辑，必须用它。

每次检测都启动 python 是血泪教训，视频流场景进程启动开销扛不住。可靠做法是启动一个常驻 Python 进程，用标准输入输出通信：Java 把图像字节写进 stdin，Python 用 ONNX Runtime 推理后把 JSON 写回 stdout。Java 侧骨架：

ProcessBuilder pb = new ProcessBuilder("python", "detect_server.py"); Process process = pb.start(); BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(process.getOutputStream())); BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream())); // 每帧: writer.write(frameId + "," + base64Image + "\n"); writer.flush(); // 结果: reader.readLine() 解析 JSON

这个方案的价值是 Python 侧保留预处理逻辑，Java 侧改动少；代价是字节流协议要自己设计，Python 进程崩溃要能自动拉起，还要处理背压。如果你接手的是存量系统、短期内没机会迁到 Java 直跑 ONNX，这是最快能跑的方案。

4.5 画框与视频落盘：结果如何回到业务里

检测完的框不能只存在内存里，通常要画到帧上。用 OpenCV 的 rectangle 和 putText 在 Mat 上画出类别名和置信度，再把 Mat 写回视频文件或推流。JavaCV 的 FFmpegFrameRecorder 可以直接复用 FrameGrabber 的分辨率和帧率录 mp4；要推 RTMP 时，在 recorder 里设置 format 为 flv 并指定推流地址就行。

画框这一步经常被“性能优化”砍掉。我一般会保留两种模式：实时检测时只画框抽样截图，不落盘；离线分析时全量画框存视频。这样多路流同时跑时可以避免磁盘 IO 打满。排查线上问题时，再临时打开画框录制，定位完现场就关掉。

5. 常见问题排查：跨语言目标检测最容易翻车的 5 个坑

跨语言方案里，模型本身很少出问题，出问题的几乎都在边界约定上。下面 5 个坑是我在类似项目里反复遇到的，按“现象、原因、解决”写，你可以把这一章当排查手册用。

5.1 检测框坐标整体偏移，但尺寸看起来是对的

现象：框的长宽基本符合目标，但位置整体往右下或左上偏，画面边缘的目标偏移更明显。

原因：letterbox 预处理时记录了 scale 和 dx、dy，后处理时漏了减 dx、dy，或者只除了 scale。边缘目标离填充区更近，偏移看起来更扎眼，所以它比均匀偏移更容易被注意到。

解决：把预处理返回的 scale、dx、dy 作为后处理参数，先做“减填充”再做“除缩放”。我在 4.3 给过对应公式，建议写一个独立的后处理函数，不要散落在业务代码里。调试时准备一张目标位置已知的测试图，打印映射前后的坐标值，对不上立刻能看出是哪一步漏了。

5.2 Java 端结果和 Python 端对不上：预处理顺序不一致

现象：同一张图在 Python 里检测正常，Java 端要么少检，要么置信度明显偏低，框的数量对不上。

原因：三处最容易不一致。通道顺序，OpenCV 读进来是 BGR，YOLO 训练通常用 RGB；归一化方式，除以 255 还是 255.0 在浮点精度上有差异；数据布局，HWC 和 CHW 的索引换算一旦写错，输入就是乱序像素。

解决：用 3.4 节的 Python 脚本对同一张测试图跑一遍基线推理，打印输出数组前几位；Java 端也打印同样位置的值，逐位对比。两边前几位一致，预处理就一致了。这步能在集成期省掉一整天排查时间，不要跳过。

5.3 视频流跑几分钟内存就涨：结果对象没有释放

现象：单路视频检测，JVM 堆内存看着正常，但系统内存稳步上升，几分钟后 GC 频繁，最后 OOM。

原因：OrtSession.Result、OnnxTensor 和 JavaCV 的 Mat 都涉及堆外内存，它们不是普通 Java 对象，不能只靠 GC。每帧 new 出来的 Result 不 close，堆外内存会越积越多。Mat 如果不手动 release，底层 buffer 同样堆积。

解决：推理结果用 try-with-resources 包裹，Mat 用完调用 release()。压测时定期打印 onnxruntime 的内存计数和系统内存占用，持续不回落就说明有对象泄漏。这个检查要做在压测阶段，别等上了生产再观察。

5.4 第一次推理慢得出奇，后面正常：缺少会话预热

现象：服务刚启动，第一帧检测耗时 2 到 3 秒，之后回落到几十毫秒，看起来像偶发抖动。

原因：ONNX Runtime 的算子内核选择、线程池初始化、内存分配器创建都发生在首次推理时，加上 CPU 指令分派，首帧开销远大于均值。这不是随机问题，是确定的启动行为。

解决：服务启动后、拉流之前，用一张全零图跑 3 到 5 次推理完成预热，再开始业务。预热时间单独打日志。否则后续定位性能问题时，会把启动耗时当成业务代码问题来查。

5.5 ONNX 算子不兼容：opset 和运行时版本打架

现象：Java 端创建 session 时报 “Op type not registered” 或 “Unsupported opset version”，同一个文件在 Python 端却能正常跑。

原因：导出时 opset 默认值太高，Java 端的 onnxruntime 版本对不上算子表。YOLO 系列导出脚本的默认 opset 会随版本走高，跨语言方案里这个差异常常在最忙的时候冒出来。

解决：导出命令显式加 --opset 12，同时把 Java 端 onnxruntime 升级到兼容版本。如果已有模型文件出了问题，不用改 Java 代码，回 Python 端重新导一次就能解决。我习惯把导出命令、opset、运行时版本写进模型目录下的 README，三个月后自己回来看，这份备注能省很多事。

6. 从单路到多路：用线程池把检测服务撑起来并验证帧率

单路视频检测时，拉流、预处理、推理、后处理串在一起就能跑。多路摄像头接入后，一路 1080p 25fps 的画面还没算完，下一帧已经到了，串行模型必然丢帧。

解法是拆成生产者消费者模式。拉流线程只负责抓帧和预处理，放进有界队列；推理线程池从队列取数据并行推理；后处理线程画框和回传结果。核心结构是这样：

ExecutorService capturePool = Executors.newFixedThreadPool(cameraCount); ExecutorService inferencePool = Executors.newFixedThreadPool(inferenceThreads); BlockingQueue<FrameTask> queue = new ArrayBlockingQueue<>(capacity); capturePool.execute(() -> { while (running) { FrameTask task = grabAndPreprocess(grabber); queue.offer(task, 1, TimeUnit.SECONDS); } }); inferencePool.execute(() -> { FrameTask task = queue.poll(1, TimeUnit.SECONDS); if (task != null) { float[][] boxes = detect(task.tensor); task.setResult(boxes); } });

队列长度要设一个上限，比如 8 或 16。队列满时主动丢帧，而不是让拉流线程阻塞，这样才能保证画面是“最新的”，而不是堆积一分钟前的旧帧。推理线程数从 2 开始压测，逐步往上加，直到帧率不再提升。

验证方法：用同一段本地视频模拟多路流，记录每路的处理帧率和单帧平均耗时，观察队列深度是否持续增长。如果队列总是满的，说明预处理速度大于推理速度，需要增加推理线程或降低输入分辨率。T4 上 1080p 25fps 640 分辨率能带多少路这种问题，答案不在模型，而在你的线程模型和解码能力，只信压测数据。帧率和显存分配之间的平衡有点像玄学，但队列深度的变化曲线是实打实的。

我自己最早做多路检测时，把推理直接塞在拉流线程里，一路流就把 CPU 打满。后来拆成生产者消费者模型才顺畅，监控也提前做好。做这个方向，先把队列长度和帧率监控搭起来，再谈优化。希望帮到你。

本文还有配套的精品资源，点击获取