企业官网建设流程全解析

做密集行人检测最让人头疼的时刻，不是模型精度不够，而是模型明明能检测出目标，一到真实场景（商场扶梯口、地铁站台、景区检票口）就各种翻车——人挤人的时候互相遮挡，远处的人小到只有十几个像素，近处的人又大到超出边界框，传统的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系列远不止是版本号递增，每一代的架构改动都会直接影响密集场景下的表现。我结合源码和实测，把这四个版本的核心差异做了个对比。

YOLOv10的端到端特性值得多说一句。它通过One-to-One匹配策略替代了传统NMS，相当于从机制上绕过了"重叠框被抑制"的死结。我在CrowdHuman密集子集上测试，YOLOv10在人群高度重叠区域的召回率比v8高了约4-6个百分点，这个差距在真实监控画面里就是"少漏检好几个人"的差距。

YOLOv12引入的注意力机制则更擅长捕捉行人之间的关系，当一个人被另一个人遮挡50%以上的时候，v8和v10基本只能靠猜测，v12却可以利用周围行人的上下文信息辅助判断。当然，注意力机制也带来了更高的计算开销，实际部署时要在速度和准确率之间做权衡。

2.2 密集行人场景下的实测对比

我基于同一个数据集（约1.2万张标注图像，混合了监控视角和手持设备视角）分别训练了四个版本的YOLO模型，输入分辨率统一设置为640×640，硬件环境是单张RTX 3090。

只看这个表，YOLOv12好像全面胜出，但实际部署要考虑硬件差异。我的目标运行环境有一部分是CPU服务器，v8和v10在CPU上的推理速度能跑到300ms左右，v12直接飙到600ms以上。所以我的策略是：GPU环境用v12，CPU环境切回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(f"Unsupported 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 ApiResult<DetectionResponse> 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( source=img_bytes, conf=conf_thres, verbose=False ) 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 (Supplier<AnalysisResult> 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 Set<WebSocketSession> 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增强	h=0.015, s=0.7, v=0.4	适应不同光线环境
  随机尺度	0.5-1.5倍	应对尺度分布不均

  训练参数方面，我用的是SGD优化器，初始学习率0.01，权重衰减0.0005，batch 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 model=weights/yolov11s_crowd.pt format=onnx opset=12 imgsz=960

  导出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: 200MB

  7.2 踩坑实录：大模型调用超时、NMS漏检、并发瓶颈

  这个项目从开发到上线，踩了不少坑，挑三个最有代表性的分享。

  第一个坑是大模型API调用超时。上线第一天，检测图片功能时不时就报错，排查发现是调用DeepSeek API时没设置连接超时，默认的TCP连接超时长达数分钟。在部分网络环境下，连接会一直挂起，然后占满Tomcat线程池。解决办法是在RestTemplate或者HTTP客户端里显式设置连接和读取超时，我设的是connectTimeout=5s、readTimeout=30s，超时立刻走备选模型逻辑。

  第二个坑是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推理服务之间加一层接口日志，把每次请求的模型版本、推理耗时、检测数量、大模型响应时间全部记录下来。这些数据在调优时是判断瓶颈到底在算法侧还是在服务侧的黄金依据，比我上面提到的任何方案都更值得优先落地。