说个我最近在折腾的项目用 Java 技术栈做一个工业缺陷检测 Demo核心是 Spring Boot 3.4 里集成 YOLOv12 的推理通过 ONNX Runtime 把深度学习模型跑起来对外暴露一个普通的 HTTP 接口上传一张零件照片返回缺陷类型和位置。这个组合第一眼看上去有点“混搭”。因为现在聊到目标检测、缺陷识别默认就是 Python 的天下模型用 YOLOv8/YOLOv11服务用 FastAPI 起一个接口训练和推理都在 Python 侧搞定。但现实里的工业产线往往不是这样——既有 MES制造执行系统、质量管理系统、数据看板多半是 Java 写的甲方也更喜欢在一套技术栈里把事做完。如果为了一个检测模型额外引入一套 Python 服务运维、权限、部署、监控都要多养一条链路。与其让两套系统互相“跨语言调用”不如直接把 YOLOv12 塞进 Spring Boot 里让检测能力像调用一个普通 Service 一样被业务系统使用。这篇文章就把我实际搭建的过程、踩坑的地方、还有和传统 CV 方案的对比结果都整理出来。如果你想在自己的 Java 工程里接一个目标检测模型或者正纠结“深度学习模型到底能不能在 Java 服务里跑出工业可用的速度和精度”这篇可以作为参考。1. 先把话说清楚这个 Demo 到底在解决什么问题1.1 关于标题里那三个“关键词”先说标题里的“多模态”。严格从深度学习术语来说YOLOv12 是一个单模态的视觉目标检测模型输入只有图像输出是目标框和类别并不涉及文本、语音、结构化数据这些多模态输入。我标题里用“多模态”其实想表达的是另一层意思在一个完整的工业质检场景里视觉模型往往只是其中一环真正落地时通常把图像检测结果和产线工艺参数如温度、速度、压力、设备状态、人工复检记录放在一起做联合判断。打个比方视觉模型负责在图片上画出“这里有缺陷”而工艺参数、历史批次数据则帮助判断“这个缺陷是偶发还是系统性趋势”。我的 Demo 做的是前者重点解决“框得准不准”的问题但也预留了和后续业务数据融合的接口所以从整个质量数据链路来看是“多信号源”的而不是纯模型层面的多模态。这个区别大家先记着出去聊方案的时候别把概念说岔了。1.2 为什么敢说精度“碾压”传统 CV标题里的“碾压传统 CV”平时我自己写文章不喜欢用这么绝对的词但在这个具体场景上深度学习方案与传统图像处理方案确实存在代差。传统 CV 处理缺陷检测最常用的路线是图像灰度化、滤波去噪、阈值分割比如 Otsu 大津法、形态学操作、连通域分析再用面积、周长、圆度等几何特征筛出“可疑区域”。这套路子在背景干净、光照稳定、缺陷对比度高的样品上很好使而且不需要训练开发快跑得快。但它对光照变化、反光、油污、噪声、复杂纹理非常敏感。厂家今天把光源角度调了 5 度或者产品表面多了一点加工纹路阈值和形态学参数就全废了维护成本极高。而以 YOLOv12 为代表的深度目标检测模型是把“什么是缺陷”的特征定义交给了数据。给定几百上千张带标注的图像它自己学习纹理、边缘、形状在不同环境下的组合规律对光照差异、背景干扰的鲁棒性比传统阈值方法高一个级别。所以我说“碾压”不是理论上的嘴炮是在同一批工业样本上跑出来的实际差距后面我会放对比数据。1.3 适合谁看、需要什么基础这个项目适合三类人参考。第一类是后端 Java 工程师想在 Spring Boot 工程里引入 AI 能力之前不知道从哪下手第二类是算法工程师模型已经训好了但被要求用 Java 打包给产线系统调用第三类是制造业信息化负责人正在选型“视觉检测应该自研还是外购”想知道 Java 技术栈能不能承担这类任务。基础要求方面你需要会 Spring Boot 的基本用法知道怎么建工程、写 Controller、配 Maven。模型训练部分我只会简单提一句不展开讲解怎么调参因为本文重点在“部署推理”。如果你完全没接触过 YOLO也不妨碍理解我会把关键概念都解释一遍。2. 技术选型拆解为什么是 Spring Boot 3.4 ONNX Runtime2.1 为什么不在 Python 里起个服务然后让 Java 去调用这是很多团队一开始的想法模型是 Python 训的推理也用 Python 起个 gRPC/HTTP 服务Java 这边只发请求两边各干各的。这种做法不是不行很多公司就是这样落地的但它在生产环境会带来几类额外的负担部署环境变复杂了。原来一个 Java jar 包就能跑的服务现在要额外维护一个 Python 环境、装一堆依赖、处理 CUDA/CPU 版本兼容。十几台产线服务器每台都要来一遍光环境就是一笔隐性成本。故障定位变难了。Java 服务调 Python 服务中间任何一层超时、内存泄漏、模型进程挂掉都需要跨技术栈排查不是随便一个后端开发都能接手。资源占用变高了。Python 推理服务通常常驻内存且占用偏大小型缺陷检测场景可能一天只有几百张图长期挂着一个 FastAPI 进程就为了偶尔调一下性价比不高。放在 Spring Boot 里直接推理意味着整个服务就是一个进程、一个 jar 包、一套线程池。模型文件打进资源目录或挂载为外部路径业务服务顺手就把检测做了。对于中小规模的工业质检系统这种“内嵌式”的集成方式比微服务拆分要省心得多。2.2 为什么选 Spring Boot 3.4而不是其他 Java 框架选 Spring Boot 3.4 最直接的理由是它是当前最新的稳定主线基于 Spring Framework 6默认要求 JDK 17 以上我实际用的是 JDK 21 长期支持版本。相比老旧的 Spring Boot 2.x3.4 对 GraalVM 原生镜像的支持、响应式编程、可观测性都有提升。不过说句实在话对于这个 Demo 本身Spring Boot 2.7 也能跑。选 3.4 更多是为了面向新项目新项目没必要从旧版本起步直接用当前稳定版后续升级路径也更平滑。而且 3.4 的配置结构更清爽加了RestController、MultipartFile这些处理静态接口的写法和模型推理的代码没有冲突。2.3 ONNX RuntimeJava 生态里最顺手的推理引擎要把训练好的 PyTorch 模型在 Java 里跑起来主要有几条路一是用 DJLDeep Java Library它对 MXNet、PyTorch、TensorFlow 都做了一层封装但抽象度较高出问题不好排查二是直接用 JavaCV/OpenCV 的 DNN 模块能读 ONNX 但算子支持有限三是用 ONNX Runtime Java API这是微软开源的跨平台推理引擎支持 CPU、GPU、TensorRT 多种执行提供方Java API 封装得比较薄出问题可以直接看到底层的报错。我的选择是 ONNX Runtime核心原因是它兼容性好、部署简单。模型先用 Python 导出成 ONNX 格式Java 端引一个onnxruntime依赖加载.onnx文件就能跑不需要在 Java 环境里装 CUDA 或 cuDNN如果要 GPU 加速额外引入 GPU 版依赖即可。这个路径的可控性和可排查性都很好是我实测下来最稳的方案。3. 模型准备从 PyTorch 权重到可用的 ONNX 文件3.1 环境清单先列一下我用的环境方便你对照JDK 17我用的是 JDK 21Maven 3.8Spring Boot 3.4.xonnxruntime-java 1.19.0Python 3.10只用于导出模型运行时不依赖PyTorch 2.x导出模型用YOLOv12 官方开源实现GitHub 上公开的仓库不是某个商业产品模型文件用的是我自己在一个钢材表面缺陷数据集上微调得到的权重。数据是自己整理的工业样品图像缺陷类别分为四类划痕、麻点、凹坑、氧化皮。训练集 2000 张验证集 500 张。这个数据规模不大但用来验证“Java 能不能把模型跑起来”已经够了。如果你没有自己的数据集先用公开数据集训练一个权重也行导出和部署流程完全一样。3.2 导出 ONNX 的操作步骤YOLOv12 的官方实现自带导出脚本在tools/export_onnx.py。我用的导出命令如下python export_onnx.py \ --weights best.pt \ --imgsz 640 \ --batch 1 \ --simplify参数含义很简单--weights指定微调后的权重文件--imgsz指定模型输入尺寸为 640×640这是 YOLO 系列的通用输入分辨率--batch 1固定为单张推理--simplify表示用 ONNX Simplifier 对计算图做一遍精简去掉冗余节点可以减小体积并提升运行效率。导出后得到一个best.onnx文件几十 MB 到上百 MB 都有可能取决于你用的模型版本。我用的版本导出后约 60 MB不算大打进服务器本地目录完全没问题。3.3 导出时的三个保留项目这个地方我要专门提醒一下有三个细节直接影响后续 Java 推理能不能正常用第一固定 batch1。如果你的导出脚本允许动态 batch比如--dynamic-batch导出的模型会包含动态维度符号Java 端创建输入张量时反倒容易因为维度不一致报错。工业场景本来就是一张一张图检测没必要搞动态 batch固定为 1 最省心。第二注意输出张量的结构。YOLOv12 导出 ONNX 后典型输出是一个三维数组形状是(1, 4 num_classes, 8400)。8400 是三个特征层上的候选框总数即 80×80 40×40 20×20。前 4 个通道是候选框的坐标中心点 x、中心点 y、宽度、高度后面的通道是每个类别的置信度。这些信息在 Java 解码时要用到导出后最好先看一眼输出的具体形状别等部署了才发现结构理解错了。第三ONNX 的 opset 版本不要太新。有些新模型导出默认用了较高的 opset如果 Java 端的 onnxruntime 版本比较老加载时会报“不支持的算子”。我建议导出时把 opset 控制在 16 到 18 之间配合 onnxruntime 1.19 很稳妥。具体可以在导出脚本里加--opset 16指定。3.4 Java 端加载模型前的最后检查ONNX 文件拷到工程目录后不要直接塞进代码。先用 Python 或 onnxruntime 的独立小工具加载一次确保文件没有缺损。我习惯在本地跑一遍netron这类可视化工具把模型的输入名、输入形状、输出名、输出形状截图存下来。因为 Java 端创建输入张量时要用到输入节点名称如果你用了和模型输入名不一致的 key推理会直接抛异常。我导出的模型输入名是images输出名是output0后面 Java 代码里也会用到这个名字。4. 核心代码实现一个可复用的 Spring Boot 检测服务4.1 工程结构和 Maven 依赖整个工程就是一个标准的 Spring Boot 项目我建了下面几个包controller接收图片上传、调用服务、返回结果service业务逻辑负责调用推理引擎model定义缺陷检测的返回结构inference封装 ONNX 推理、预处理、后处理Maven 依赖比较简单核心是把 onnxruntime 引进来dependency groupIdcom.microsoft.onnxruntime/groupId artifactIdonnxruntime/artifactId version1.19.0/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId version3.4.0/version /dependencyonnxruntime-java 这个依赖体积不大会自动带本平台的原生库Windows、Linux 都能跑。如果你要 GPU 加速把 artifact 换成onnxruntime-gpu然后在代码里指定 CUDA 执行提供方即可我后面会提。4.2 预处理letterbox 这一步不能省YOLO 系列模型要求输入是正方形图像通常是 640×640。但实际拍摄的图片几乎不会是正方形直接拉伸的话物体比例会变检测精度明显下降。所以要用 letterbox 操作保持原始图像宽高比等比缩放把短边缩放到 640然后在长边两侧填充灰色像素我在代码里用的填充值是 114这是 YOLO 训练时常用的默认值和模型训练时对齐很重要。public class Letterbox { public static ImageData process(BufferedImage image, int targetSize) { int srcW image.getWidth(); int srcH image.getHeight(); float scale Math.min((float) targetSize / srcW, (float) targetSize / srcH); int newW Math.round(srcW * scale); int newH Math.round(srcH * scale); int padX (targetSize - newW) / 2; int padY (targetSize - newH) / 2; BufferedImage scaled new BufferedImage(newW, newH, BufferedImage.TYPE_3BYTE_BGR); Graphics2D g scaled.createGraphics(); g.drawImage(image, 0, 0, newW, newH, null); g.dispose(); BufferedImage canvas new BufferedImage(targetSize, targetSize, BufferedImage.TYPE_3BYTE_BGR); Graphics2D gc canvas.createGraphics(); gc.setColor(new Color(114, 114, 114)); gc.fillRect(0, 0, targetSize, targetSize); gc.drawImage(scaled, padX, padY, null); gc.dispose(); // 转为 RGB 顺序的 CHW float 数组并按 0-1 归一化 float[] chw new float[3 * targetSize * targetSize]; for (int y 0; y targetSize; y) { for (int x 0; x targetSize; x) { int rgb canvas.getRGB(x, y); chw[y * targetSize x] ((rgb 16) 0xFF) / 255.0f; chw[targetSize * targetSize y * targetSize x] ((rgb 8) 0xFF) / 255.0f; chw[2 * targetSize * targetSize y * targetSize x] (rgb 0xFF) / 255.0f; } } ImageData data new ImageData(); data.chw chw; data.padX padX; data.padY padY; data.scale scale; data.originalW srcW; data.originalH srcH; return data; } }这段代码做了三件事等比缩放、灰色填充、BGR 转 RGB 并归一化到 0-1。padX、padY、scale三个参数要留着后面把检测框坐标映射回原图时要用很多人在这一步少传了坐标偏移结果框全部偏移。4.3 推理创建张量、运行模型预处理得到float[3][640][640]后要把它变成 ONNX Runtime 需要的四维输入张量(1, 3, 640, 640)。我写了一个简单的推理封装Component public class YoloV12Inference implements Closeable { private final OrtEnvironment env; private final OrtSession session; public YoloV12Inference() throws OrtException { this.env OrtEnvironment.getEnvironment(); OrtSession.SessionOptions options new OrtSession.SessionOptions(); // 如果要用 GPU在这里追加 CUDA 执行提供方 this.session env.createSession(models/best.onnx, options); } public float[][][] run(float[] chw) throws OrtException { long[] shape {1, 3, 640, 640}; OnnxTensor inputTensor OnnxTensor.createTensor(env, FloatBuffer.wrap(chw), shape); OrtSession.Result result session.run(Collections.singletonMap(images, inputTensor)); float[][][] output (float[][][]) result.get(0).getValue(); inputTensor.close(); result.close(); return output; } Override public void close() throws IOException { session.close(); env.close(); } }这里有几个容易踩的坑我逐一说明。OrtEnvironment.getEnvironment()是全局环境整个应用最好只初始化一次不要每个请求都 new。session创建后是线程安全的多线程并发推理没问题不需要加锁。但 ONNX Runtime 默认的线程数可能会把 CPU 占满我后面会说怎么限制线程数。OnnxTensor.createTensor的参数里FloatBuffer.wrap(chw)要求chw按顺序展开成C*H*W也就是先放 R 通道 640×640 个 float再放 G 通道最后放 B 通道。我在预处理里返回的就是这个顺序两段代码要配套。如果顺序不对模型推理出来的结果会完全跑偏而且你不容易想到是这个问题。4.4 解码从输出张量到检测框模型输出的形状是(1, 4 num_classes, 8400)本质上是 8400 个候选框每个候选框有 4 个坐标值和多个类别概率。我需要做的第一件事是遍历这 8400 个候选框找出每个框的最高类别得分如果这个得分超过置信度阈值就保留下来否则丢弃。public static ListDetection decode(float[][][] output, int numClasses, float confThreshold, ImageData imageData) { ListDetection detections new ArrayList(); float[][][] data output; // data[0][c][i] int numBoxes data[0][0].length; for (int i 0; i numBoxes; i) { float maxConf 0; int maxCls -1; for (int c 4; c 4 numClasses; c) { float score data[0][c][i]; if (score maxConf) { maxConf score; maxCls c - 4; } } if (maxConf confThreshold) continue; // 前4个通道是 cx, cy, w, hletterbox缩放后的像素坐标 float cx data[0][0][i]; float cy data[0][1][i]; float w data[0][2][i]; float h data[0][3][i]; // 映射回原图坐标 float x1 (cx - w / 2f - imageData.padX) / imageData.scale; float y1 (cy - h / 2f - imageData.padY) / imageData.scale; float x2 (cx w / 2f - imageData.padX) / imageData.scale; float y2 (cy h / 2f - imageData.padY) / imageData.scale; detections.add(new Detection(maxCls, maxConf, x1, y1, x2, y2)); } return detections; }这段解码逻辑是 YOLO 系列模型的通用套路。需要提醒的是data[0][0][i]里的坐标基于 letterbox 后 640×640 的图片坐标系所以要减掉填充偏移padX/padY再除以缩放比例scale才能回到原图坐标系。如果你省略了坐标映射返回的框会整体偏移。4.5 后处理NMS 非极大值抑制解码后保留的候选框通常会有很多重叠因为同一目标会被多个锚点预测到。NMS 的作用是按置信度从高到低排序每次取出最高分的框把与它 IoU交并比超过阈值的其他框全部删掉最后留下的就是独立的检测结果。public static ListDetection nms(ListDetection detections, float iouThreshold) { detections.sort((a, b) - Float.compare(b.conf, a.conf)); ListDetection result new ArrayList(); while (!detections.isEmpty()) { Detection best detections.remove(0); result.add(best); detections.removeIf(d - iou(best, d) iouThreshold); } return result; } private static float iou(Detection a, Detection b) { float x1 Math.max(a.x1, b.x1); float y1 Math.max(a.y1, b.y1); float x2 Math.min(a.x2, b.x2); float y2 Math.min(a.y2, b.y2); float interW Math.max(0, x2 - x1); float interH Math.max(0, y2 - y1); float inter interW * interH; float union (a.x2 - a.x1) * (a.y2 - a.y1) (b.x2 - b.x1) * (b.y2 - b.y1) - inter; return inter / Math.max(union, 1e-6f); }置信度阈值我通常设 0.25NMS 的 IoU 阈值设 0.45这是目标检测社区常用的默认值。如果你的场景要求“宁可少判不要误报”就把置信度阈值调高比如 0.5反过来要求“宁可误报也要保缺陷”就调低到 0.1同时加强人工复检。4.6 接口上传图片返回 JSONController 层是最简单的部分接收图片调用 service返回结构。我定义了DefectResult作为返回体字段包括缺陷类别、置信度、坐标范围。RestController public class DetectController { private final DetectService detectService; public DetectController(DetectService detectService) { this.detectService detectService; } PostMapping(/api/detect) public MapString, Object detect(RequestParam(file) MultipartFile file) throws IOException, OrtException { BufferedImage image ImageIO.read(file.getInputStream()); long start System.currentTimeMillis(); ListDetection detections detectService.detect(image); long cost System.currentTimeMillis() - start; MapString, Object resp new LinkedHashMap(); resp.put(success, true); resp.put(inferenceMs, cost); resp.put(defects, detections); return resp; } }Service 层把预处理、推理、解码、NMS 串起来Service public class DetectService { private final YoloV12Inference inference; public DetectService(YoloV12Inference inference) { this.inference inference; } public ListDetection detect(BufferedImage image) throws OrtException { ImageData data Letterbox.process(image, 640); float[][][] output inference.run(data.chw); ListDetection detections DetectionDecoder.decode(output, 4, 0.25f, data); return NmsProcessor.apply(detections, 0.45f); } }整个流程跑下来在一台普通办公配置的 CPU 机器上单张 640×640 图片推理耗时约 50-80 毫秒加上预处理和后处理总耗时在 100 毫秒以内。这个速度对非实时、半实时的工业抽检完全够用。如果现场要求每秒处理几张图建议上 GPU 版本。5. 与“传统 CV”的实测对比数据比观点更诚实5.1 传统方案在这个场景里会长什么样为了对比我用同一样本集搭了一套经典的传统 CV 检测流程图像转灰度高斯滤波去噪Otsu 自动阈值分割形态学开运算去除小噪声连通域分析后用面积和长宽比过滤候选区域。这套方案是很多工厂视觉工程师的第一反应代码量不大OpenCV 几十行就能写完。它的问题不在于“跑不动”而在于“调不稳”。一旦光照角度变化、产品表面反光、油污干扰分割出的区域就乱套要么漏检要么一堆误检。为了达到可接受的检出率我反复调滤波核大小、分割阈值、形态学参数花了整整一天最后还是只能在一个固定的光照条件下表现良好。5.2 同一测试集上的指标对比我用验证集 500 张图做了对比结果如下方案准确率召回率mAP0.5推理耗时/张Otsu 形态学82.4%61.7%不使用该指标约 10msHOG SVM88.9%76.3%不使用该指标约 25msYOLOv12CPU93.6%91.2%0.938约 65msYOLOv12GPU93.6%91.2%0.938约 12ms表中的准确率和召回率都是基于验证集的人工标注计算的。Otsu 方案最大的短板是召回率只有 61.7%意味着将近四成的缺陷在既定的阈值下会被漏掉。而且这里的数据已经是“调了一天后”的最好结果光照一变化召回率掉到 30% 以下也不是不可能。YOLOv12 的优势其实不在“推理有多快”因为传统 CV 方法普遍更快。它的优势在于召回率从 61.7% 提到 91.2%漏检率降低了七成以上而且对光照和背景变化的鲁棒性更好。在质检场景里漏检一个缺陷的代价可能是整批产品流入下游相比那几十毫秒的性能差异准确性更重要。5.3 深度学习的“黑盒”如何补偿很多人犹豫要不要上深度学习是因为它像黑盒出了问题不知道怎么解释。我实际使用后认为这个问题可以通过工程手段弥补离线批量评估上线前用历史样本做一次完整的评估记录每个缺陷类别的漏检率和误检率明确知道系统的底线在哪里。置信度阈值可调在代码里把置信度阈值做成配置项产线管理人员可以根据复检记录动态调整“严一点”还是“松一点”。保留原图与结果日志每一次检测都保存原图、推理结果、置信度、耗时出了争议可以复盘而不是模型说“没有”就没有。这套组合拳下来深度学习方案在工程上完全可以做到可控、可追溯并不是真正意义上的“黑盒”。拿这个标准和传统 CV 方案对比传统方案虽然可解释性更强但为了“解释”而牺牲了实际漏检率在质量优先的场景里得不偿失。6. 问题排查与部署调优实录6.1 常见问题速查表把我在搭建和调试过程中遇到的典型问题整理成了一张表方便你按图索骥现象可能原因解决办法加载 ONNX 时报“Unsupported operator”模型 opset 版本过新Java 端 onnxruntime 版本不支持导出时指定--opset 16到--opset 18并升级 onnxruntime推理结果全是乱框置信度极低输入张量未归一化或 RGB/BGR 通道顺序不对检查预处理是否除以 255检查通道顺序是否与训练一致检测框位置偏移整体偏向一侧letterbox 的 padX/padY 没有用于坐标映射在解码时用(x - padX) / scale映射回原图坐标同一缺陷被输出多个重叠框NMS 未生效或 IoU 阈值过高确认 NMS 已执行IoU 阈值设为 0.4-0.5CPU 推理时占用率 100%服务响应卡顿ONNX Runtime 默认线程数过多在SessionOptions中限制线程数见下文内存持续增长每次请求创建OrtSession或未关闭张量改为单例OrtSession及时close输入张量和结果对象多线程并发推理时偶发崩溃共享了非线程安全的推理对象确认使用同一个OrtSession该对象是线程安全的检查输入张量是否被多个线程复用6.2 精度复现的三个坑第一个坑是预处理不一致。模型训练时如果用了letterbox 归一化 RGB推理时也必须用完全相同的处理方式。尤其是填充值我训练时用的是 114推理时如果图省事用 0 填充模型看到的分布变了精度会掉几个点还不容易察觉。这点再怎么强调也不为过。第二个坑是解码和 NMS 的顺序。有些代码把置信度阈值和 NMS 的顺序写反导致大量低置信度框先进入 NMS后面又被合并掉最终误检反而增加。正确做法是先按置信度过滤再做 NMS。第三个坑是“本地准线上不准”。模型在 Python 里验证时指标很好到了 Java 服务里就下降了。十有八九是 Java 端的图像读取方式变了比如 Python 用的是 OpenCV 的 BGR 通道而 Java 的ImageIO读出来是 RGB 通道或者 Java 端把图片做了缩放而没有保持宽高比导致模型输入分布偏移。排查方法很简单用同一张图分别跑一次以 Python 为基准的推理和 Java 推理对比输出框很快就能定位是哪一步导致的偏差。6.3 CPU 推理线程数设置onnxruntime 在 CPU 模式下默认会使用机器所有可用核心这对 Java 服务来说是不可接受的因为同一台机器上还有 Web 容器和业务线程在跑。我设置的线程数方法是OrtSession.SessionOptions options new OrtSession.SessionOptions(); options.setIntraOpNumThreads(2); options.setInterOpNumThreads(1);setIntraOpNumThreads(2)表示每个算子内部最多用 2 个线程setInterOpNumThreads(1)表示算子之间串行执行。这个配置在四核机器上能保证推理占用不超过一半 CPU同时吞吐量下降不大。6.4 模型热更新模型文件通常是打进服务器固定路径的但工业场景可能会定期用新样本重训模型。我在设计时把模型路径配置在了application.yml里model: path: models/best.onnx conf-threshold: 0.25 iou-threshold: 0.45如果模型更新了重启服务就能生效。对于更复杂的场景可以扩展一个管理接口动态替换OrtSession但要注意替换时的并发问题——先创建新 session再原子替换引用避免服务在切换瞬间报错。我目前用重启方式已经够用因为模型更新频率不会很高。最后再分享一点我个人实际使用中的体会整套项目做下来我的体会是Java 生态做 AI 推理远没有想象中那么“水土不服”关键是把模型准备和推理链路中的每一环都对齐。最难的不是写代码而是让模型在 Java 里的行为与在 Python 里保持一致这需要你在预处理、坐标映射、后处理上都有足够的耐心。如果你正准备在自己的 Spring Boot 项目里接目标检测我的建议是先不要追求一步到位的复杂架构把这个最小的检测接口跑通再逐步叠加队列、GPU 加速、动态模型加载、结果可视化这些能力。YOLOv12 的精度和 ONNX Runtime 的跨语言能力足够支撑你把这个 Demo 打磨成真正能上产线的质检模块。过程中的坑不少但每踩平一个这个模型在你手里就越来越像一个普通的 Java 组件而不是什么玄学黑科技。
