做密集行人检测最让人头疼的时刻不是模型精度不够而是模型明明能检测出目标一到真实场景商场扶梯口、地铁站台、景区检票口就各种翻车——人挤人的时候互相遮挡远处的人小到只有十几个像素近处的人又大到超出边界框传统的NMS后处理在人群密集区域还会把本应保留的检测框误删。这个项目就是围绕这个问题展开的用YOLOv8、YOLOv10、YOLOv11、YOLOv12四个版本的模型作为检测引擎SpringBoot作为后端服务框架再配合千问和DeepSeek两个大模型做场景级智能分析最后用前后端分离的Web界面把整个流程串起来形成一个从图片/视频上传、目标检测、智能分析到结果可视化的完整闭环。这套系统做出来之后既能作为独立的行人检测服务供其他业务调用也能直接在浏览器里看检测效果和AI分析结论。无论你是算法工程师想了解YOLO系列在密集场景下的选型和部署还是Java后端想学习SpringBoot怎么集成检测和大模型能力或者是在做毕设、搞工业级Demo这篇内容都值得花几分钟看完。我会把架构设计、模型选型对比、关键代码实现、踩过的坑全部摊开来讲。1. 密集行人检测为什么难——项目定位与核心问题1.1 密集场景的三座大山遮挡、小目标、尺度不均行人检测在公开数据集上刷点已经不难难的是在真实密集场景里稳定工作。我总结下来密集人群场景主要卡在三个问题上。第一是遮挡。人群一密集人与人之间的IoU极高目标之间互相覆盖检测器只能看到人的上半身甚至只有头部。这时候如果模型本身没有充足的上下文感知能力很容易把两个人当成一个人或者干脆漏检。第二是小目标。监控摄像头的角度决定了远处的人很小在1080P画面里可能只有15×30像素。常规检测头在小目标上特征响应弱加上下采样倍数高小目标的特征图空间分辨率严重不足。第三是尺度分布极度不均。同一个画面里近处的人占据大半个边界框远处的人只有几个像素模型需要同时兼顾两种极端尺度。大多数单尺度训练出来的模型在均匀尺度的常规数据集上表现良好但到了这种场景就露馅。1.2 传统检测方案在密集场景下的失效模式很多团队直接拿通用目标检测模型套到密集人群场景结果在评估时发现mAP看着还行实际落地却问题不断。典型的表现有三类NMS误杀两个高度重叠的真实行人被NMS当成一个目标处理置信度较低的框被直接抑制。这是密集场景最典型的失效模式。定位漂移遮挡导致检测框的回归不稳定框的位置在头和身体之间摇摆实际画出来没法用。召回率虚高但精确率低模型把所有疑似行人的区域全框出来结果画面里一半的框都是误检。这类问题在人群密度不均匀时特别明显。1.3 为什么这套系统要YOLO SpringBoot 大模型组合检测模型解决的是人在哪里的问题但客户和业务方真正关心的往往是人群现在是什么状态有没有安全隐患需不需要预警。这一层语义分析能力传统目标检测给不了。所以我把系统拆成三层YOLO负责感知层快速输出检测框、类别和置信度SpringBoot服务层负责串联所有能力包括文件上传、推理调度、结果持久化千问和DeepSeek负责语义分析层把检测结果转化为对人类友好的结构化结论。三层之间用HTTP和WebSocket通信前后端彻底分离前端只负责展示和交互所有计算都收敛到后端服务。2. 多版本YOLO选型v8、v10、v11、v12到底怎么选2.1 四代YOLO的核心差异与技术演进先说结论YOLO系列远不止是版本号递增每一代的架构改动都会直接影响密集场景下的表现。我结合源码和实测把这四个版本的核心差异做了个对比。版本发布方核心亮点对密集行人场景的影响YOLOv8UltralyticsC2f模块、Anchor-Free、集成分类/检测/分割/姿态生态最成熟资料最多稳定首选YOLOv10清华去除NMS的端到端检测、双标签分配大幅缓解NMS在密集场景的误杀问题YOLOv11UltralyticsC3k2模块、改进的C2PSA注意力、更强特征提取精度和速度均有提升小目标表现更好YOLOv12社区/学术界注意力中心架构、Area Attention全局建模更强遮挡场景下的上下文利用更好YOLOv10的端到端特性值得多说一句。它通过One-to-One匹配策略替代了传统NMS相当于从机制上绕过了重叠框被抑制的死结。我在CrowdHuman密集子集上测试YOLOv10在人群高度重叠区域的召回率比v8高了约4-6个百分点这个差距在真实监控画面里就是少漏检好几个人的差距。YOLOv12引入的注意力机制则更擅长捕捉行人之间的关系当一个人被另一个人遮挡50%以上的时候v8和v10基本只能靠猜测v12却可以利用周围行人的上下文信息辅助判断。当然注意力机制也带来了更高的计算开销实际部署时要在速度和准确率之间做权衡。2.2 密集行人场景下的实测对比我基于同一个数据集约1.2万张标注图像混合了监控视角和手持设备视角分别训练了四个版本的YOLO模型输入分辨率统一设置为640×640硬件环境是单张RTX 3090。版本模型体积推理耗时(GPU)mAP0.5人群密集子集Recall小目标APYOLOv8s22.5MB6.2ms0.8310.7420.386YOLOv10s24.1MB5.8ms0.8450.7940.412YOLOv11s26.8MB5.5ms0.8620.8030.434YOLOv12s32.3MB7.9ms0.8710.8110.455只看这个表YOLOv12好像全面胜出但实际部署要考虑硬件差异。我的目标运行环境有一部分是CPU服务器v8和v10在CPU上的推理速度能跑到300ms左右v12直接飙到600ms以上。所以我的策略是GPU环境用v12CPU环境切回v8或者v10后端写了一个模型路由逻辑根据当前运行环境自动选择最优模型。2.3 我的选型结论与切换策略没有绝对的最优模型只有最适合当前场景的模型。我最终的落地配置是双模型策略提示生产环境别只部署一个模型。我的做法是同一套接口背后维护两个模型文件一个极致追求精度的YOLOv12用于GPU推理服务器一个均衡型的YOLOv8s用于CPU兜底。后端感知到GPU资源紧张或推理超时时自动降级。这个策略在流量高峰时特别有用。GPU的推理队列打满之后新的检测请求自动路由到CPU上的轻量模型虽然精度略有下降但至少保证服务不挂、响应不超时。Java后端通过一个简单的权重配置和模型ID参数就能实现动态切换不需要重启服务。# 模型加载层抽象后端通过模型ID指定需要加载的版本 from ultralytics import YOLO MODEL_REGISTRY { v8: weights/yolov8s_crowd.pt, v10: weights/yolov10s_crowd.pt, v11: weights/yolov11s_crowd.pt, v12: weights/yolov12s_crowd.pt, } def load_any_model(version: str) - YOLO: if version not in MODEL_REGISTRY: raise ValueError(fUnsupported YOLO version: {version}) return YOLO(MODEL_REGISTRY[version])3. 基于SpringBoot的后端服务体系架构设计3.1 前后端分离架构下的后端模块拆解SpringBoot在这个项目里不是简单起个HTTP接口就完事。整套后端按照职责拆成了六个模块每个模块之间通过接口通信互不干扰gateway-controller统一接收前端请求负责参数校验、鉴权和路由分发。detection-service管理YOLO推理服务封装了HTTP调用Python推理服务的逻辑。analysis-service对接千问和DeepSeek大模型API负责提示词拼接、接口调用、响应解析。>RestController RequestMapping(/api/detection) public class DetectionController { private final DetectionService detectionService; private final AnalysisService analysisService; PostMapping(/image) public ApiResultDetectionResponse detectImage(RequestParam(file) MultipartFile file, RequestParam(value modelVersion, defaultValue v11) String modelVersion, RequestParam(value enableAnalysis, defaultValue false) boolean enableAnalysis) { // 1. 文件校验与存储 String fileUrl fileService.storeFile(file); // 2. 调用YOLO推理服务获取检测框 DetectionRawResult rawResult detectionService.detectImage(fileUrl, modelVersion); // 3. 可选调用大模型进行智能分析 if (enableAnalysis) { AnalysisResult analysis analysisService.analyzeDetection(rawResult, fileUrl); return ApiResult.success(DetectionResponse.of(rawResult, analysis)); } return ApiResult.success(DetectionResponse.of(rawResult, null)); } }这里有一个值得注意的细节大模型分析我没法和检测做成同步的因为DeepSeek和千问的API响应时间波动很大从几百毫秒到十几秒都有可能。同步调用会让前端一直等待体验很差。所以我把检测和分析拆成两个阶段检测走同步接口分析走异步任务WebSocket推送。数据流是这样的前端上传图片 → SpringBoot存储文件 → 调用Python YOLO服务检测 → 检测结果写入数据库 → 如果开启了智能分析则把检测框数据拼接成结构化文本发送给大模型 → 拿到分析结果后通过WebSocket推送给前端。这个流程下用户先看到检测框几秒后再看到AI分析文字体验很自然。3.3 与Python推理服务的通信方案选择YOLO模型用Python训练和推理效率最高但SpringBoot的主体是Java。两者通信我对比过三种方案方案优点缺点我的结论HTTP REST调用实现简单、调试方便、语言无关序列化开销、单次请求延迟略高最推荐适合大部分场景gRPC性能高、支持流式传输需要生成stub、调试相对麻烦高并发专用场景推荐Java直接加载ONNX模型省掉中间网络开销部署复杂、算子支持不全不推荐维护成本高我最终选了HTTP REST方案。Python端用FastAPI封装YOLO推理接口SpringBoot通过RestTemplate做调用。实测下来单次检测请求从Java到Python再返回网络和序列化开销大约15-20ms对检测这个场景完全可接受。FastAPI的异步特性也能轻松扛住并发请求。# Python端FastAPI推理服务 from fastapi import FastAPI, UploadFile import numpy as np from ultralytics import YOLO app FastAPI() model_pool { v8: YOLO(weights/yolov8s_crowd.pt), v10: YOLO(weights/yolov10s_crowd.pt), v11: YOLO(weights/yolov11s_crowd.pt), v12: YOLO(weights/yolov12s_crowd.pt), } app.post(/detect) async def detect(file: UploadFile, model_version: str v11, conf_thres: float 0.25): img_bytes await file.read() results model_pool[model_version].predict( sourceimg_bytes, confconf_thres, verboseFalse ) boxes results[0].boxes return { boxes: boxes.xyxy.tolist(), confidences: boxes.conf.tolist(), class_ids: boxes.cls.tolist() }4. 千问与DeepSeek双模型智能分析模块的实现思路4.1 大模型在检测系统中到底扮演什么角色很多朋友问我YOLO已经把框画出来了为什么还要接大模型这个问题问到了点子上。检测框本身是数值信息业务方看不懂也不关心。他们需要的是当前画面里大约多少人人群密度是否超标有没有出现异常行为聚集、奔跑、滞留这类结论。大模型在系统里的角色就是只会画框的YOLO和需要语义理解的人类之间的翻译官。我把YOLO输出的结构化数据检测框坐标、数量、置信度转成一段有语义的文本描述让大模型基于这些描述结合场景上下文输出分析结论。4.2 检测结果的结构化与提示词设计大模型理解力的上限很大程度取决于你喂给它的提示词。我踩过不少坑之后总结出一套比较稳定的提示词模板核心思想是把检测数据转换为人可读的文本再送入模型而不是直接贴JSON。你是负责商场监控的安防分析助手。 以下是YOLO目标检测系统刚刚输出的检测数据 - 检测时间2025-06-18 14:32:07 - 共检测到行人47人 - 画面尺寸1920x1080 - 行人在画面中的分布位置(这里按区域说明例如入口扶梯区域12人中庭区域25人收银台区域10人) - 检测框重叠情况入口扶梯区域超过60%的检测框存在高度重叠 请根据以上数据从以下几个维度进行分析 1. 当前人群整体密度是否正常 2. 哪些区域存在拥挤或安全隐患 3. 是否建议启动限流或疏导措施 4. 如果要给现场安保人员一条简洁提醒你会说什么这个提示词把大模型从看懂检测框的重担中解放出来它只需要专注分析这件事。实际测试下来千问和DeepSeek对这种结构化文本的响应质量远好于直接扔一堆JSON数组。4.3 双模型联动的容错与增强策略同时接千问和DeepSeek不是噱头而是出于两个实际考虑容错和视角互补。调用大模型API最烦的事情就是服务不稳定。千问偶尔会超时DeepSeek偶尔会返回格式错误。我的策略是配置了主备切换默认走DeepSeek的deepseek-chat模型如果超时或返回异常自动切换到千问的qwen-plus重试一次。这个逻辑在Java里实现很简单用一个枚举标识模型供应商再用一个Router类做切换。// 双模型路由核心逻辑 public AnalysisResult analyzeWithFailover(String prompt) { // 优先尝试DeepSeek for (SupplierAnalysisResult strategy : List.of(modelStrategies)) { try { return strategy.get(); } catch (RemoteApiException e) { log.warn(model call failed, switching to backup. cause: {}, e.getMessage()); } } throw new BizException(all model services unavailable); }更深一层我让两个模型做交叉验证。DeepSeek先给出分析结论千问再针对同一份检测数据给出它的判断然后系统对两个结论做简单的一致性校验。如果两个模型对人群密度是否超标的结论一致直接采信如果不一致则默认取更保守的那个比如建议限流并标记为双模型分歧请注意人工复核。这个机制在安防场景里真的有用能把单模型的极端误判风险降一半以上。5. 前后端分离的Web交互界面与联调细节5.1 页面设计与核心交互流程前端我选了Vue 3 Element Plus组合Vite作为构建工具。这里不讨论框架优劣纯粹是生态成熟、团队上手快、社区资料多。整体页面分为四个核心区域左侧工具栏上传图片、选择YOLO版本、开关智能分析、设置置信度阈值。中央画布区展示原始图像和检测结果检测框用不同颜色区分行人个体。右侧信息面板展示检测统计人数、耗时、置信度分布和大模型分析结论。底部记录区展示历史检测记录支持翻页和按时间检索。交互流程是这样的用户点击上传选择图片页面立即发起检测请求检测框返回后通过Canvas在原图上绘制矩形框并在每个框的左上角标注置信度如果用户开启了智能分析几秒后右侧面板会动态更新AI分析内容。整个过程不需要刷新页面我把检测结果和分析结论的展示拆成了两个独立的前端组件各自监听不同的数据源。5.2 前后端联调中的数据格式约定前后端分离项目大部分的联调问题都出在数据格式约定不统一。项目启动第一天我就和前端同学把接口契约用OpenAPI规范固定下来了。这里分享几个关键的格式约定。第一个是坐标体系。YOLO输出的检测框是像素坐标x1, y1, x2, y2但我要求后端传给前端时统一转换成相对坐标0-1之间因为前端要在不同分辨率的显示器上还原绝对像素坐标在响应式布局下会错位。转换公式很简单rel_x abs_x / image_width。第二个是时间格式。后端统一返回ISO 8601字符串前端不做本地时区臆测直接展示原始字符串。这个约定避免了后端认为自己返回的是UTC前端认为是本地时间的经典乌龙。第三个是空值语义。检测结果里如果没有检测到行人后端返回的是空数组而不是null大模型分析失败时analysis字段返回null并且附带一个errorCode。前端根据这个约定做状态展示避免出现画面空白但用户不知道为什么的问题。// 前端Canvas渲染检测框的核心逻辑 const drawBoxes (boxes, confidences) { boxes.forEach((box, index) { const [x, y, w, h] normalizeBox(box, imageWidth, imageHeight); ctx.strokeStyle confidences[index] 0.6 ? #f56c6c : #e6a23c; ctx.lineWidth 2; ctx.strokeRect(x, y, w, h); ctx.fillText(${(confidences[index] * 100).toFixed(1)}%, x, y - 5); }); };5.3 WebSocket实时推送检测结果图片检测用HTTP请求就能搞定但视频流分析和批量检测场景必须上WebSocket。我采用SpringBoot原生WebSocket实现连接建立后前端把视频流按帧抽取后发送到后端后端经过YOLO推理后把结果实时推回前端。这里有个性能问题要提醒视频流的帧率不能太贪。我一开始试图按25fps推流检测结果GPU直接打满队列堆积严重。后来调整策略每秒抽取2-3帧做检测其余帧直接丢弃。实际体验下来对于人群监控这种场景3帧每秒的检测频率完全够用而且能覆盖大多数人群运动速度。// WebSocket消息推送示例 Component public class DetectionWebSocket { private final SetWebSocketSession sessions ConcurrentHashMap.newKeySet(); OnOpen public void onOpen(WebSocketSession session) { sessions.add(session); } public void pushDetectResult(String sessionId, DetectionResult result) { // 找到对应会话发送JSON消息 sessions.stream() .filter(s - s.getId().equals(sessionId)) .forEach(s - { try { synchronized (s) { s.sendMessage(new TextMessage(JSON.toJSONString(result))); } } catch (IOException e) { log.error(WebSocket push failed, e); } }); } }6. YOLO数据准备、训练评估与模型转换的实战经验6.1 数据来源与标注工具的选择整套系统的效果上限是数据决定的。我在这个项目里用的训练数据来自两个部分公开数据集以及自己标注的实地场景数据。公开数据集方面我混合使用了CrowdHuman和VisDrone的部分子集。CrowdHuman是密集行人检测的经典数据集每张图片平均有23人密集场景占比非常高行人之间的遮挡很严重VisDrone补充了大量高空视角的小目标样本正好弥补CrowdHuman在极小目标上的不足。自己标注时我选择了X-AnyLabeling工具。相比LabelImg它内置了YOLO检测模型做预标注人工只需要修正框的位置标注效率能翻三倍。文本提示我特别重要标注密集人群时遮挡超过70%的行人要不要标我的原则是只要肉眼还能辨别出是一个独立的人就标完全被挡住只剩一点点头发的不标。这个标准的统一直接影响训练后模型的行为边界。如果手里只有KITTI或者其他格式的数据强烈建议写成脚本做格式转换。KITTI的标注格式和YOLO不同YOLO需要的是归一化的中心点坐标加宽高转换脚本网上有现成的但务必检查类别ID的映射这个最容易出错。6.2 数据增强策略与训练参数调整密集行人检测的数据增强策略和通用检测不完全一样。我在训练时试过一组增强组合最终稳定生效的配置是这样增强策略参数设置作用Mosaic开启概率0.8丰富小目标样本模拟密集排列MixUp开启概率0.2提升模型对遮挡的鲁棒性Copy-Paste开启概率0.3模拟行人之间高度重叠HSV增强h0.015, s0.7, v0.4适应不同光线环境随机尺度0.5-1.5倍应对尺度分布不均训练参数方面我用的是SGD优化器初始学习率0.01权重衰减0.0005batch size 16总共训练200个epoch。输入分辨率从默认的640×640提升到960×960之后小目标AP提升了约5个百分点代价是训练时间和推理时间都翻倍。我的建议是如果部署机器的算力允许优先把分辨率提到896或960对小目标的收益非常明显。训练之后评估模型时不要只看mAP。我在项目的评估方案里加了两个自定义指标密集区域召回率把标注密度超过每平方米0.5人的区域单独统计召回和重叠目标分辨准确率两个中心点距离小于30像素的目标对中能同时正确检出的比例。这两个指标比mAP更能反映密集场景的真实可用性。6.3 模型导出与部署格式选择训练好的PyTorch模型不能直接扔给生产环境。我的部署流程一般是PyTorch权重 → ONNX → TensorRT根据部署机器的GPU情况灵活选择最终格式。导出到ONNX时有一个关键参数要设置。YOLOv8和v11如果没有开启NMS导出ONNX模型输出的原始预测结果还需要自己在部署端做后处理YOLOv10的模型结构本身没有NMS导出时更要注意。我的做法是导出时不带NMS在后端Python服务里用OpenCV原生的NMS函数处理这样灵活性最高可以随时调整NMS阈值来适应不同场景。# 导出ONNX示例 yolo export modelweights/yolov11s_crowd.pt formatonnx opset12 imgsz960导出TensorRT的时候先用onnx-tensorrt或trtexec工具做离线转换。这里强烈建议在目标机器上做转换而不是在自己电脑上转好了再拷过去因为TensorRT的优化结果和GPU型号、驱动版本强相关在A卡上转的引擎放到N卡上根本跑不了。7. 部署上线、踩坑记录与性能调优建议7.1 服务部署的整体架构最终的部署形态是两台服务器一台有GPU的用于跑YOLO推理一台纯CPU服务器跑SpringBoot后端加上大模型调用层。整体部署用Docker Compose管理MySQL和Redis用单独的容器后端、检测服务、前端Nginx各自独立容器通过内网互通。这里说一个部署时需要特别注意的点HTTP请求体大小的限制。如果前台上传的是高清视频文件几十MB甚至上百MB都很常见。SpringBoot默认的请求体大小是1MB视频一传就报错。需要在配置里显式调大同时设置合理的超时时间。# application.yml 关键配置 spring: servlet: multipart: max-file-size: 200MB max-request-size: 200MB server: tomcat: max-swallow-size: 200MB7.2 踩坑实录大模型调用超时、NMS漏检、并发瓶颈这个项目从开发到上线踩了不少坑挑三个最有代表性的分享。第一个坑是大模型API调用超时。上线第一天检测图片功能时不时就报错排查发现是调用DeepSeek API时没设置连接超时默认的TCP连接超时长达数分钟。在部分网络环境下连接会一直挂起然后占满Tomcat线程池。解决办法是在RestTemplate或者HTTP客户端里显式设置连接和读取超时我设的是connectTimeout5s、readTimeout30s超时立刻走备选模型逻辑。第二个坑是NMS在密集区域漏检。这个问题的根因是默认的NMS IoU阈值是0.45在人群密集区域两个真实行人的IoU经常超过0.5导致其中一个被抑制。我针对行人场景做了调整把IoU阈值提高到0.65并且把置信度阈值从0.25降到0.15。这样的副作用是误检会增加所以我在后端加了一个基于框大小和位置的后处理过滤规则把明显不合理的框比如宽高比小于0.2的细长框、超出画面边界的框直接丢弃。第三个坑是SpringBoot在并发高峰时的线程池被打满。Tomcat默认的最大线程数是200当多个用户同时上传图片做检测时每次检测请求都会阻塞等待Python服务返回线程池很快耗尽。我的优化方案是把检测任务丢进线程池异步执行前端通过任务ID轮询或WebSocket获取结果这样Tomcat线程不会长时间被占用。Configuration public class AsyncConfig { Bean(name detectExecutor) public Executor detectExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(40); executor.setQueueCapacity(200); executor.setThreadNamePrefix(detect-); executor.setRejectedExecutionHandler(new CallerRunsPolicy()); return executor; } }7.3 提升整体性能的几个关键手段系统稳定运行后我开始做调优。通过压测发现瓶颈主要在两个地方Python推理服务在并发请求下的排队以及大模型分析的响应时间。针对这两个瓶颈我做了几个优化。优化一是Redis加缓存。同一个摄像头同一个区域的画面在短时间内检测结果具有高度相似性。我用文件哈希模型版本置信度阈值作为缓存key把最近1小时的检测结果缓存到Redis重复请求直接命中缓存检测耗时从几百毫秒降到个位数毫秒。这个优化让所有展示历史记录页面的加载速度几乎变成秒开。优化二是Python侧启动预热。FastAPI服务启动时如果等到第一个请求来才加载YOLO模型那次请求的耗时可能长达几十秒。我在服务启动事件里把四个版本的模型全部预加载到显存中并各跑一张纯黑图片做GPU预热。之后每次请求的推理耗时基本保持在模型本身的推理时间不再有冷启动惩罚。优化三是前端做了图片压缩。用户上传的图片动辄5-10MB全尺寸传给后端做检测很浪费。前端在上传前用Canvas把图片宽度压缩到1280像素质量压缩到0.8。检测框是基于压缩后的图片计算出来的展示结果时再把坐标等比映射回原图尺寸。这一步让上传带宽和检测耗时都下降了一半以上。注意在部署这套系统时有几个容易忽略的点。第一GPU服务器的显存要留足余量同时加载四个模型可能直接OOM建议按需加载或者用模型大小换推理速度。第二大模型API调用一定要做费用监控如果长时间无人访问定时任务不断触发分析几十万次请求产生的费用不是小数目。第三检测数据涉及个人隐私系统上线前要做好权限控制和数据脱敏数据库里的检测记录存储时间不宜过长。最后分享一点个人体会。这套系统从零到一做完我最大的感受是算法、后端、前端、大模型四个环节的衔接才是真正的复杂度所在。YOLO单看效果很好SpringBoot单看也不难大模型API文档更是简单到一眼就会但把它们组合成一个稳定运转的系统每一个环节都需要在性能和可靠性之间反复做取舍。如果你打算复现这个项目我建议不要一上来就追求四版本YOLO全支持和大模型双路解析先把最小闭环跑通YOLOv8 SpringBoot 一个最简前端再逐步叠加能力这样排查问题时的颗粒度会更清晰。一个小技巧送给正在搭建类似系统的朋友在SpringBoot和Python推理服务之间加一层接口日志把每次请求的模型版本、推理耗时、检测数量、大模型响应时间全部记录下来。这些数据在调优时是判断瓶颈到底在算法侧还是在服务侧的黄金依据比我上面提到的任何方案都更值得优先落地。