企业官网建设流程全解析

这个东西我前后折腾了小两个月，从数据清洗到模型训练，再到后端融合和前端展示，把YOLOv8、YOLOv10、YOLOv11、YOLOv12四个版本全部跑了一遍实测，最后接上千问和DeepSeek做智能分析，整套系统才算是真正能拿得出手。今天就把完整的设计思路、训练细节、工程落地方案和踩过的坑一次交代清楚，给要做密集行人检测或者类似目标检测系统的朋友一份可以直接抄作业的参考。

这套系统做的事很明确：视频流进来，后端调用YOLO系列模型做密集行人检测，检测结果交给SpringBoot编排成标准接口，前端通过Web页面实时展示画面、检测框、人数统计和密度热力图。与此同时，系统会定时把一段时间内的检测统计结果交给千问和DeepSeek做语义化分析，生成自然语言的客流报告、拥挤预警和趋势研判。适用场景非常清晰——商场客流统计、地铁站人流预警、校园安防、景区人流密度分析，凡是“人多不多、哪儿人多、趋势怎么变化”这类问题，都是这套系统的目标场景。适合正在做毕业设计、公司项目预研，或者想从纯算法往全栈系统方向转型的朋友参考。

1. 项目整体设计与技术选型思路

1.1 这个系统到底做了什么事

先掰开说清楚系统的核心链路，不然后面讲技术细节容易绕晕。整个系统大概是这么一条流水线：

视频源（摄像头RTSP流、本地视频文件、或者直接上传一段视频）进入系统，由Python推理服务负责抽帧和YOLO模型推理，每一帧先做目标检测，把行人的边界框、置信度、类别全部检测出来。检测结果不是直接甩给前端，而是先做一层后处理——统计当前帧人数、计算区域密度、对连续帧做简单的跟踪匹配（这里用到了IoU匹配和简单的轨迹关联，没有上深度的REID模型，毕竟系统重点是“密度”而不是“身份”），然后封装成JSON结构。

这份JSON结构同时做两件事。第一件是推给SpringBoot后端，后端负责落库、做时间窗口聚合统计，再通过WebSocket推给浏览器前端实时渲染；第二件是定时打包给千问和DeepSeek的大模型接口，让模型根据一段时间的统计结果生成人类读得懂的语义分析，比如“14:00到14:30期间，东侧入口客流从每分钟80人上升到每分钟150人，密度等级从中度升级为高度，建议启动限流措施”。

一句话总结：YOLO负责“看见”，SpringBoot负责“传输和存储”，前端负责“展示和交互”，大模型负责“思考和表达”。四层各司其职。

1.2 YOLOv8/v10/v11/v12，我为什么全都要

这个问题几乎每次分享都有人问——选一个版本不就行了，为什么折腾四个？真实原因是：不同版本在不同场景下优势完全不一样，密集行人这个场景恰好能把四个版本的特点都体现出来。

YOLOv8是这几代里生态最成熟、最稳的版本。Ultralytics官方维护，文档全，第三方工具链最丰富，ONNX导出、TensorRT部署、各类改进论文基本都是基于v8做的。如果在生产环境求稳，v8是底线选择。它在密集行人场景下的表现中规中矩，漏检不算严重，但检测框的重合度问题需要靠NMS参数调优来兜底。

YOLOv10最大的特点是去掉了NMS（Non-Maximum Suppression，非极大值抑制）。它在训练阶段通过双标签分配策略和一致性匹配机制，从根上解决了推理阶段NMS带来的延迟和精度损失。在密集场景下，这个特性非常值钱——因为人一多，互相遮挡，传统NMS很容易把挨得近的两个人的检测框合并成一个，导致漏检。v10从设计上规避了这个问题，推理速度也比v8快不少。但v10的缺点是生态相对新，一些第三方改进和部署工具支持得没那么及时。

YOLOv11在v8的基础上引入了C3k2模块和更深的网络结构，在精度上确实有所提升，尤其是中大型目标的检测效果更稳。但在密集行人这种小目标、强遮挡的场景里，v11的提升没有在常规检测数据集上那么惊艳，主要赢在综合能力均衡。

YOLOv12是这里面最新的，它引入了区域注意力（Area Attention）机制，把注意力计算从全局降到了局部区域，计算量更小，同时能更好地建模长距离依赖。我实测下来，v12在遮挡场景下的表现是最好的——当一个行人被其他人挡住了半边身体，v12经常能靠周围区域的上下文信息硬“猜”出来。代价是显存占用比前几个版本高，推理速度在GPU上稍慢。

我的建议是：如果你的项目场景是“人很多、遮挡严重”，优先试v12；如果追求实时性且算力有限，v10是比较理想的选择；如果是要快速上线、生态依赖多、团队对模型不太熟，v8闭眼上；v11可以作为精度和速度的平衡点。生产环境最稳的做法是四个版本都训一遍，用同一个测试集量化对比后再做决定。

1.3 SpringBoot坐镇后端的理由，以及前后端分离的价值

算法部分用Python这没什么好争议的，但整个系统后端我坚持用SpringBoot，而不是图省事直接用Flask/FastAPI把一切包了。原因有三个。

第一，生态问题。大多数企业的业务系统端是Java技术栈，SpringBoot的权限控制、数据库持久层、事务管理、消息队列接入、操作日志这些能力都是现成的。检测系统不是只在算法演示阶段就结束了，它要接入业务系统、做用户管理、做报表查询、对接已有的数据中台。用SpringBoot去承接这些需求，后续开发和维护成本远低于Python写一坨大而全的服务。

第二，稳定性考虑。Python服务做模型推理没问题，但作为业务后端承载高并发请求，尤其是在连接池管理、异常处理、内存回收这些方面，SpringBoot的成熟度更高。所以我采取的是“Python做推理引擎，SpringBoot做业务后端”的分工模式：Python只暴露一个推理接口，SpringBoot负责所有业务逻辑编排。两个服务用HTTP JSON或者gRPC通信，逻辑上完全解耦。

第三，前后端分离是这套系统天然合理的架构。检测结果的数据特点是“高频小体积”，每秒钟可能推送好几帧的检测结果，但单个帧的数据量并不大。这种数据用WebSocket从后端直接推给前端，效率远高于前端轮询REST接口。而SpringBoot对WebSocket的支持非常完善，配合STOMP协议可以很轻松地管理连接会话。前端拿到数据用Canvas或者ECharts渲染，后端完全不需要关心页面长什么样，职责清晰，联调效率也高。

2. 密集行人场景的数据准备与模型训练

2.1 数据集从哪来，密集场景的数据长什么样

做密集行人检测，数据是第一道坎，也是最容易掉坑的环节。很多人上来就拿COCO数据集里的person类去训练，但COCO里大多数图片是日常场景，单张图里的行人数量很少，遮挡也轻。换到真实密集场景——地铁车厢、商业街、演唱会现场——模型立刻水土不服。原因很简单：训练集和推理集的分布不一致。

解决思路有三个来源。

第一优先是直接用公开的密集行人数据集。CrowdHuman是目前比较经典的密集行人检测数据集，图片都来自街景和复杂场景，单张图片平均有22.6个人，遮挡和截断的比例很高。VisDrone是无人机视角，虽然以车辆为主，但行人类别对俯拍场景很有参考价值。还有MOT17，虽然它是跟踪数据集，但检测标注质量很高，可以直接提取检测标签用来训练。这些数据集都是YOLO格式转换好的，网上能找到现成的转换脚本。

第二是自建数据。如果项目有真实的现场摄像头，一定要想办法采集现场视频，抽帧之后用标注工具手工标注。这一步很苦，但价值极大。因为现场摄像头的视角、安装高度、光照条件跟公开数据集完全不同，哪怕标注一千张图，对模型在真实场景下的表现提升都远大于网上随便下载几万张图充数。

第三是数据清洗。无论从哪个渠道拿数据，都要做一轮清洗：去掉高度模糊的、人物占比过小的、过度重复的图片，检查标签是否越界——坐标超出图片边界的标注要裁掉或者删除。密集场景里很容易出现“一个行人被标了两次”“两个人重合时只标到一个人”这种低质量标注，不洗干净，模型学出来的特征就是乱的。

2.2 标注与转换：KITTI转YOLO格式、数据增强组合拳

如果你的数据源是KITTI格式，转YOLO格式的规则值得说一下，因为坐标系的换算关系很容易搞反。KITTI的标注是“类别 截断 遮挡 观察角度 bbox_left bbox_top bbox_right bbox_bottom 3D信息”，而YOLO要求的是“类别 x_center y_center width height”，并且全部归一化到0到1之间。换算公式是：

x_center = ((bbox_left + bbox_right) / 2) / image_width y_center = ((bbox_top + bbox_bottom) / 2) / image_height width = (bbox_right - bbox_left) / image_width height = (bbox_bottom - bbox_top) / image_height

这段代码看似简单，但有几个细节必须注意。第一，YOLO的x_center和y_center是边界框中心点，不是左上角，搞反了框的位置会整体偏移。第二，归一化后的值可能略大于1或者小于0，尤其是目标贴着图片边缘的时候，这时候要做截断处理，把坐标clip到0~1之间。第三，KITTI的类别编号和你的业务类别编号要对上，不要出现类别序列错位的尴尬错误。

标注工具方面，LabelImg是老牌工具，适合中规中矩画矩形框；X-AnyLabeling支持半自动标注，可以先用一个预训练模型帮你预标注，然后人工微调，效率能提升一倍以上；Roboflow在云端做标注和数据集版本管理很方便，还内置了多种增强算子。我个人的习惯是本地用X-AnyLabeling做精细标注，导出后扔到Roboflow或者自己的脚本里做增强和切分。

数据增强在密集行人场景里要特别谨慎。Mosaic增强是YOLO系模型的标配，把四张图拼成一张训练，可以有效提升小目标检测能力。CopyPaste增强对密集场景很管用——把一些行人实例复制粘贴到其他图片的空白区域，人为制造“更密集”的训练样本。但要注意别把增强参数拉得太猛，尤其是旋转角度和透视变换，在行人检测里如果增强得过头，会引入大量不符合真实行人身姿比例的畸形样本，模型精度反而下降。我实测下来，mosaic概率设0.8左右，copy_paste概率设0.3左右，综合效果最好。

2.3 训练参数与四个版本的实测对比

训练环境我用的是单张NVIDIA RTX 4090，显存24G，PyTorch 2.1，CUDA 12.1。Ultralytics官方仓库对四个版本都提供了统一训练入口，所以训练脚本基本可以共用。

yolo train \ model=yolov8m.pt \ data=crowd.yaml \ epochs=150 \ imgsz=1280 \ batch=8 \ device=0 \ lr0=0.01 \ lrf=0.01 \ momentum=0.937 \ weight_decay=0.0005 \ warmup_epochs=3 \ cos_lr=True

这里imgsz我特意提到了1280。密集行人场景里小目标多，输入分辨率太低会导致小目标在特征图上直接消失。但分辨率提高也意味着显存占用和推理时间上升，所以我自己做了个折中测试：在精度和速度之间平衡下来，1280是性价比最高的档位。如果显存吃紧，降到960也能用。

四个版本训练完后，我用同一批现场采集的难例样本做了离线评测。所谓难例样本，就是特地挑了一些超密集、强遮挡、光照复杂的帧，总共800张，手工标好Ground Truth，跑mAP和F1指标。结果如下：

这个结果基本印证了前面的分析：v12在难点样本上漏检率最低，v10在速度上有明显优势，v8和v11表现均衡但缺乏惊喜。最终我生产环境主模型选的v12，同时用v10做了一条低延迟快速分析通道，需要实时告警的时候走v10，需要精准统计的时候走v12。

另外说一嘴损失函数的事。Ultralytics默认用的是CIoU，但在密集场景下可以试一下WIoU或SIoU。WIoU对“低质量样本”的宽容度更高，不容易被一些标注得不准的边界框带偏；SIoU在框的角度回归上更顺滑，对倾斜视角下人体的框更友好。我自己试下来，把box损失换成WIoU之后，v12难例集的mAP额外涨了大概1.2个点，代价是训练收敛稍微慢一点。可以作为一个无脑提点的小技巧。

3. 检测服务封装与SpringBoot后端融合

3.1 方案选型：Java直接推理，还是Python推理服务

这是整个系统架构上最核心的一个决策点。我看到过不少项目试图在Java里直接用OpenCV的DNN模块加载YOLO的ONNX模型做推理，确实能跑通，但体验下来问题很多：OpenCV的DNN对YOLO新版本算子的兼容性经常滞后，TensorRT、半精度推理这些优化手段在Java端很难灵活使用，模型一旦要改版本，Java工程要跟着重新编译打包，调试成本很高。所以我坚定不移地选择Python推理服务方案。

Python侧我用的FastAPI框架，核心原因是它天然支持异步，配合Uvicorn可以轻松并发处理多路视频流的推理请求。FastAPI的代码量也很少，整个推理服务大概不到300行就能写得清爽明白。推理引擎在PyTorch和ONNX Runtime之间我最终选了ONNX Runtime加CUDA EP，因为在部署阶段ONNX Runtime的内存占用比PyTorch低，而且不需要把整个PyTorch环境带进Docker镜像。

模型导出有一个很容易踩的坑：Ultralytics导出的ONNX模型，默认输出的张量形状是动态的（dynamic axes）。ONNX Runtime在动态形状下推理性能会打折，建议导出时固定输入尺寸：

yolo export model=yolov12m.pt format=onnx imgsz=1280 dynamic=False simplify=True

simplify=True会自动做计算图化简，删掉一些冗余节点，模型体积变小，推理速度也能快一点。

3.2 推理服务接口设计与性能调优

推理服务的接口设计成什么样，直接决定了后续系统扩展顺不顺。我的做法是提供一个统一的检测接口，输入是图片字节流或者base64字符串，输出是结构化JSON，把检测框还原成原图坐标。这里有一个前后端联调很关键的约定：所有坐标都要标注坐标体系，是相对于原图的绝对坐标，还是相对于缩放后的推理图坐标。我统一用原图绝对坐标，前端画框的时候不需要再做任何换算。

from fastapi import FastAPI, UploadFile from pydantic import BaseModel import numpy as np import cv2 import onnxruntime as ort import json app = FastAPI() session = ort.InferenceSession("yolov12m.onnx", providers=["CUDAExecutionProvider"]) class DetectResult(BaseModel): boxes: list scores: list class_ids: list target_size: list @app.post("/detect", response_model=DetectResult) async def detect(file: UploadFile): data = await file.read() image = cv2.imdecode(np.frombuffer(data, np.uint8), cv2.IMREAD_COLOR) # 预处理：letterbox + 归一化 + 转NCHW # 推理：session.run # 后处理：解码坐标、阈值过滤、NMS/去NMS # 返回原图坐标 return {"boxes": boxes, "scores": scores, "class_ids": class_ids, "target_size": [height, width]}

这个服务上线后我做了几个关键调优。第一个是开启ONNX Runtime的CUDA预分配，避免每帧推理都重新申请显存导致抖动；第二个是在服务启动时预加载模型，不要请求来了再加载；第三个是关键——用请求并发控制限制同时进入推理的请求数。如果同时来了20路视频流请求，GPU会直接被塞满，每路都变慢。用信号量把并发数限制在2到4之间，让请求排队，整体吞吐反而更稳。实际压测下来，单卡4090在并发3的情况下，平均每帧推理耗时13毫秒左右，吞吐完全够用。

3.3 SpringBoot的API编排与WebSocket实时推送

SpringBoot这边的核心工作有两个：一是把Python推理服务的结果转成业务数据落库并对外提供REST接口，二是通过WebSocket把实时检测结果推送到前端。

REST接口的设计我没有按“疯狂细粒度拆分”的方式来做，而是用了一套聚合接口策略。前端只需要调一个接口就能拿到“当前视频流的实时状态+最近5分钟的人数趋势+今日累计客流”，而不是前端调七八个接口自己拼数据。聚合的好处是前端代码简单、交互很流畅，坏处是后端要处理好多个数据源的协调和缓存。我的做法是：每N秒后端做一次预聚合，把最近一段时间窗口内的人数最大值、平均值、密度等级都算好放在Redis里，REST接口直接读缓存，减轻数据库和Python服务的压力。

WebSocket推送这边有个比较重要的细节——要控制推送频率。很多初学者会把每帧检测结果都推给前端，结果浏览器渲染跟不上，前端卡成PPT。我采用的是1秒推一次的快照模式：后端每收集1秒内的检测结果，聚合出人数、密度、平均置信度等指标，然后推给前端。前端拿到这个快照后更新图表和数字，视频流画面则单独从另一条通道拉取。

SpringBoot里的WebSocket配置有几个容易忽略的地方。第一，跨域问题在WebSocket握手阶段就会校验Origin，如果不处理，浏览器会连不上；第二，服务重启后所有WebSocket连接会断开，前端需要实现自动重连机制；第三，如果后面要水平扩展多个后端实例，原生的WebSocket Session只存在于单机内存中，需要引入Redis pub/sub或者MQ做连接信息同步。规模大的系统可以直接上STOMP协议，SpringBoot支持得非常好。

4. 千问与DeepSeek智能分析能力接入

4.1 两个大模型的分工设计

千问和DeepSeek同时接入，不是为了炫技，而是两个模型在能力侧重上各有不同。千问（通义千问）的中文语义理解能力很强，生成的文本更自然、更贴近业务人员的表达习惯，适合生成面向管理人员的客流报告；DeepSeek在逻辑推理和结构化数据分析上表现更硬核，适合做异常检测、规律挖掘和决策建议这类需要“动脑子”的任务。

按照这个分工，我设计了两种调用场景。第一种是定时报告：每30分钟跑一次，把这段时间内的检测统计结果（总人数、平均密度、峰值时段、区域分布等）结构化JSON发给千问，让它生成一段通顺的中文汇报文案。第二种是异常预警：实时检测到某个区域密度超过阈值时，把连续几分钟的数据变化发给DeepSeek，让它判断是正常的瞬时拥堵还是值得关注的事件苗头，并给出建议动作。

这么分工之后体验确实不错。千问生成的东西拿给非技术同事看，反馈是“能看懂、像人写的”；DeepSeek的分析结果拿给运营和安保团队，反馈是“建议有针对性，不是套话”。

4.2 提示词工程：怎么把YOLO结果变成有用的话

大模型接入本身不难，难点全在提示词设计。要让模型输出真正有用的分析而不是空泛的套话，必须给模型足够好的上下文和结构化的任务描述。

我自己在用的一个提示词模板大概是这个风格：

你是一名商场客流运营分析专家。下面是一段30分钟内的客流检测统计数据，请生成一份简洁的运营分析报告： 1. 总结客流趋势变化，特别是峰值和低谷出现的时段； 2. 指出哪个区域密度最高，可能的拥堵原因； 3. 给出2-3条可执行的运营建议，建议要具体、有针对性。 统计数据的JSON格式如下：{json数据} 要求： - 总字数控制在200字以内 - 语气专业、简洁，不要使用反问和夸张修辞 - 不要编造数据中不存在的信息 - 如果数据正常，直接说明情况正常即可

这里有个关键点是“不要编造数据中不存在的信息”，这句话一定得加。大模型面对数字很容易“脑补”，比如你给它一个只有8个人的数据，它可能顺着趋势编出一段“人流明显增长”的鬼话。加了约束之后，至少能让它收敛很多。

JSON数据的结构设计也很重要。不要直接把YOLO的原始检测框发给大模型，那玩意儿太细碎，模型读不出规律。我这边是先做一层数据压缩，把检测结果转换成类似这样的统计schema：

{ "time_range": "14:00-14:30", "total_in": 2450, "total_out": 2100, "avg_density": 0.42, "max_density": 0.78, "peak_time": "14:22", "region_stats": [ {"region": "east_entrance", "avg_density": 0.68, "max_density": 0.92}, {"region": "central_square", "avg_density": 0.35, "max_density": 0.51} ], "alert_flag": "high_density_east_entrance" }

给模型吃干净、语义明确的字段，它给出的分析质量会指数级上升。这也是做AI集成类功能最重要的一句话：先想清楚让模型吃什么，再想让它吐什么。

4.3 API接入的工程细节与成本控制

接入千问和DeepSeek的API在工程上没什么大的玄学，就是标准的HTTP POST调用，用各自的SDK或直接requests都行。但要提两个务必注意的工程细节。

第一，超时和重试一定要做好。大模型接口的响应时延波动非常大，有时候几百毫秒，有时候好几秒。在SpringBoot里我用了Resilience4j做熔断降级——如果大模型接口连续失败超过阈值，系统自动切换为规则引擎兜底，用简单的阈值规则生成基础提示文案，保障系统整体可用性。这个对生产环境很重要，大模型挂了不能把整个业务拖死。

第二，成本和并发控制。调用大模型是按token计费的，如果每30分钟跑一次全量分析，一天也就48次，成本很低。但我一开始犯过错：预警场景里连续触发了好几次，每次都发一大堆token，一天下来账单有点难看。后来做了处理——相同时段内同类型预警做了去重合并，5分钟内的重复预警只调用一次分析，单日成本降了60%以上。

模型参数方面，千问我用的qwen-turbo，响应快、价格便宜，对文本总结类任务够用；DeepSeek用的deepseek-chat，逻辑推理强。temperature设置为0.2左右比较合适，太高了会引入随机性，太低则显得机械，0.2是一个安全线。

5. 前后端分离的Web交互界面实现

5.1 前端选型与页面结构

前端这套我自己用的Vue3 + TypeScript + Element Plus + ECharts的组合，技术栈保守但非常成熟。Vue的响应式机制和处理实时数据流天然合拍，ECharts的地图和热力图插件做客流分布的可视化效果很香。

页面结构上我分成了四个核心模块。第一个是实时监控区：正中大屏展示实时视频流，视频上叠加YOLO的检测框，右侧是当前人数、密度等级、每秒平均置信度这些实时指标，做成大数字卡片，一眼扫过去就知道当前状态。第二个是客流趋势图：底部一个24小时的时间轴，用折线图展示每个时间窗口的进出人流量和密度变化，鼠标悬停可以看到任意时刻的详细数据。第三个是区域热力图：在地图或者平面图上用热力图方式展示各区域的人员密集程度，颜色从蓝到红渐变，密度越高颜色越红。第四个是智能分析报告区：展示千问和DeepSeek生成的历史报告，按时间倒序排列，并且支持人工备注和导出。

5.2 视频流与检测结果实时展示方案

实时视频流的展示方式需要认真选择，方案直接决定了带宽消耗和渲染性能。开发初期我试过把每一帧的检测结果图片通过WebSocket以base64字符串推给前端，虽然实现简单，但很快发现大问题：一帧720P的JPEG图片base64之后大约100KB左右，一秒推10帧就是1MB，单路视频还能扛，多路同时看直接卡死。

后来我改用双通道方案：视频流本身走HTTP的MJPEG或者转成HLS/RTMP由前端播放器拉流，检测结果的“框”坐标则通过WebSocket独立推送。前端拿到坐标，在视频画面的Canvas层动态绘制矩形框和标签，不再传输图片数据。这个方案的好处是带宽占用低了两个数量级，检测框可以精准叠加在原始视频画面上，而且即使前端得到的是历史视频流，检测框也一样能对齐时间轴叠加显示。

前端使用WebSocket的时候有个细节需要提醒：消息体里一定要带时间戳和帧号。因为视频流和检测结果走的是两条通道，天然存在网络延迟差异。如果不做时间对齐，画面上会出现“框和人不对位置”的诡异效果。我在后端WebSocket消息里加了video_frame_id字段，前端通过这个字段与视频流的当前帧做软同步，实际体验下误差在200毫秒以内，完全可接受。

5.3 分析报告模块与交互细节

分析报告模块呈现的是大模型生成的内容，这里有一个很重要的人机交互设计：报告内容必须允许人工确认和修正，并且要把“模型生成”和“人工确认”状态明显区分开。我在实现上给每条报告挂了status字段，取值是pending、confirmed、rejected三种。运营人员可以点赞确认一份报告，也可以标记为不准确并填备注。这些反馈数据我都落库了，后面可以用来做提示词调优和模型效果评估。

这个模块里我还加了一个很实用的功能：一键导出PDF日报。每天凌晨定时生成前一天的日客流报告，把ECharts的图表通过Canvas转成图片，加上千问生成的总结文案，用itext库组装成PDF，自动发送到运营团队邮箱。这个功能上线后比预想的受欢迎得多，很多人根本不会天天打开系统看页面，但一封日报邮件大家都会看。

前端交互还有个容易被忽视的点是权限。不同角色看到的页面模块应该不同：安保人员看实时监控和告警，运营人员看客流趋势和分析报告，管理员才能看参数配置和模型切换。我前端用vue-router的守卫结合后端的RBAC权限模型做路由拦截，菜单按权限动态渲染，后端每个接口也做了角色校验，双保险。

6. 系统部署实战与性能调优

6.1 服务器环境与CUDA/显卡那些坑

部署环节先讲一个很多人问过的问题：AMD显卡能不能跑YOLO训练和推理。答案是：能跑，但很不省心。PyTorch的AMD支持走的是ROCm分支，目前只支持部分Linux发行版，Windows下基本没有官方支持，而且很多CUDA生态的预编译库在ROCm下都不可用。我自己在AMD的RX 580上踩过很多坑，动不动就环境冲突、算子不支持。所以，如果你要长期做深度学习项目，老老实实上NVIDIA显卡，CUDA生态的省心程度不是一星半点。RX 580这类老A卡说实话只适合跑一些ONNX Runtime CPU推理的轻量任务，跑YOLOv8训练基本属于找罪受。

CUDA环境的版本匹配是部署期最容易出问题的地方。PyTorch、CUDA、cuDNN、显卡驱动四者之间的版本关系必须严格对齐。我用的组合是：NVIDIA驱动535.104.05，CUDA 12.1（用conda安装的cudatoolkit），cuDNN 8.9.2，PyTorch 2.1.0。这里有个理念要建立：系统全局安装的CUDA版本跟PyTorch内部依赖的CUDA版本不一定要一致，只要PyTorch通过conda装好自己带的那一份CUDA runtime，驱动版本足够新就行。不要傻乎乎地为了PyTorch去改系统全局的CUDA软链接，改坏了整个环境就是灾难。

部署服务器上还要规划GPU的显存分配策略。推理进程、训练进程如果跑在同一台机器上，要设置CUDA_VISIBLE_DEVICES环境变量把不同的任务绑定到不同GPU，或者用显存限制参数（比如onnxruntime的arena_extend_strategy）控制显存占用上限。我的生产机上有一块RTX 4090和一块RTX A2000，推理服务固定在4090上运行，A2000留作模型调优和实验，互不干扰。

6.2 Docker化部署与Nginx代理

整套系统的部署我用Docker Compose编排的，一共四个容器：python推理服务、SpringBoot后端、MySQL数据库、Nginx前端。Docker化在这里的价值不仅仅是一键部署，更重要的是能保证开发环境和生产环境的完全一致——尤其是Python推理服务，模型文件、CUDA依赖、ONNX Runtime版本全都冻死在镜像里，再也不会出现“本地跑得好好的，服务器上起不来”的经典问题。

Python推理服务的Dockerfile有一个需要注意的点：基础镜像要选带CUDA的版本。直接用python:3.10-slim会没有GPU支持，需要用nvidia/cuda:12.1.1-runtime-ubuntu22.04这类镜像打底，再在里面装Python和依赖。ONNX Runtime的GPU版本也要在pip install的时候指定extra index源，或者直接装onnxruntime-gpu包。

Nginx在这里身兼数职：托管前端静态资源、反向代理SpringBoot接口、代理Python推理服务的HTTP接口。跨域问题在这个架构里基本消失了，因为浏览器所有请求都打到Nginx同源地址上，由Nginx按路径分发给不同后端。一个典型的Nginx配置片段长这样：

server { listen 80; server_name your-domain.com; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://springboot-app:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } location /detect/ { proxy_pass http://yolo-service:8000; proxy_set_header Host $host; proxy_read_timeout 60s; } }

需要注意，/api/和/detect/这两个location都加了WebSocket升级相关的header。如果你只用HTTP访问，这两行可以不加；但一旦前端要连WebSocket，不加这几行就会连接失败。这是Nginx代理WebSocket最经典的坑。

6.3 压测与性能瓶颈调优记录

系统上线前我做了两轮压测，过程值得记录下来。第一轮压测用的工具是JMeter，重点压POST /api/v1/detect这个聚合接口，模拟100个用户同时查看监控页面的场景。压测结果暴露出了一个问题：当并发请求打到80以上时，SpringBoot的响应时间从300毫秒直线飙升到3秒以上。查了半天，瓶颈不在SpringBoot本身，而是线程池被打满后，后端线程都在等待Python推理服务的响应，导致Tomcat工作线程耗尽。

解决方案分两步走。第一步，给Python推理服务加了一层简单的函数级缓存：同一个视频源、相同时间段内的检测结果直接复用，不去重复调用模型。第二步，给SpringBoot配置了异步接口模式，REST接口的返回值用CompletableFuture包装，业务逻辑放到线程池中执行。这样Tomcat线程被立即释放，请求排队逻辑交给我们自己控制的线程池管理。调优后并发100的情况下，P95响应时间稳定在800毫秒以内，扛住了压测。

第二轮压测测的是WebSocket的推送能力。当检测频率调到每秒1帧、同时在线客户端50个时，后端的推送线程压力很大。我的解法是引入一个消息聚合器：所有待推送的消息先进阻塞队列，由一个独立的推送线程批量取出，对50个会话做群发。这样无论在线客户端有多少，后端只维持一个广播线程，压力完全可控。实测在线1000客户端时CPU占用率也就增加了8%左右，效果很明显。

7. 常见问题与排查技巧实录

7.1 高频问题速查表

把我在整个开发和部署过程中遇到过、也帮朋友排查过的问题整理成了一张速查表，按日志表现和解决方案归类。

7.2 几个让我印象深刻的排查过程

有个问题值得单独讲讲：YOLOv10导出的ONNX模型在ONNX Runtime上推理，检测框经常少一半。当时我一度以为是模型导出出了问题，来回重导了好几次都没解决。后来翻了ONNX Runtime的GitHub issue才发现，v10在训练阶段用了双标签分配策略，推理输出里天然包含两种head的输出。导出ONNX时如果没有做正确的输出裁剪，模型返回的张量维度会比预期多一维，后处理解析错位，导致部分检测框“丢失”。解决办法是在Ultralytics的导出接口里指定opset=12并且用官方推荐的end2end参数导出，如果还不行就干脆在推理代码里对输出做维度自适应处理。这件事给我的教训是：换模型版本不能只换权重文件，后续的推理解析逻辑一定要配套检查。

另一个印象很深的是部署上线后遇到的“第一次请求特别慢”问题。用户反馈点击页面后要等好几秒才有反应，但之后就正常了。排查下来发现是Python推理服务在第一次收到请求时才真正加载ONNX模型并初始化CUDA上下文，这个过程要花3到5秒。解决方式简单粗暴有效：服务启动后立刻发一个空请求做预热，把模型和显存都“烫”起来，再对外提供正常服务。Docker容器的healthcheck脚本里加一条预热命令，这个问题就彻底消失了。

还有一个和前端相关的坑：ECharts热力图在数据量大的时候渲染卡顿。排查后发现是因为每次都全量重绘热力图图层，而不是增量更新。改成只在数据变化时用setOption的notMerge模式，并且把热力图的数据做抽稀处理（相邻网格合并），渲染帧率直接从8FPS拉到了50FPS以上。这个优化对前端体验提升非常明显，属于花小钱办大事的典型。

8. 经验总结与后续扩展方向

8.1 这套系统最值得复用的架构经验

如果只让我说一条经验，那就是：把算法服务和业务服务彻底解耦。Python推理服务只干一件事——输入图片，输出检测结果。所有跟业务相关的逻辑，不管是对接数据库、推送消息、权限校验还是生成报告，全部放到SpringBoot里。这个边界画清楚之后，整个团队的协作效率高了很多：算法工程师只管调模型、优化推理性能，Java工程师只管SpringBoot的业务编排，两个人不需要理解对方的所有细节，只需要把接口契约定好就完事。

接口契约的制定也有讲究。我在项目一开始就花了半天时间，把检测接口的请求参数、响应字段、错误码、版本号全部写成Markdown文档，作为双方共同遵守的“合同”。后来证明这个投入非常值——正因为契约清晰，后面无论模型怎么换版本、前端怎么改交互，后端接口一直保持一致，系统迭代成本大幅降低。

另一个值得复用的经验是：数据链路中加一层“语义中间层”。检测结果是最底层的坐标数字，业务前端不可能直接消费这些数字。我在中间加了一层语义聚合层，把坐标转换成“某区域此刻多少人”“密度等级是多少”这类业务语义，再对外提供服务和喂给大模型。这层设计让系统的可扩展性增强了很多，后续要加新的业务指标，只需要在聚合层加一个字段，不需要动底层模型和前端展示。

8.2 可以继续扩展的几个方向

这套系统目前已经把核心链路跑通，但值得扩展的空间其实还很大。

第一个方向是做跨摄像头的密集人群分析。当前系统是单路视频流独立分析，如果一个大区域内分布着几十个摄像头，跨镜头的目标关联和全局密度图就需要更复杂的方案。可以把每路视频的检测结果合并到统一的时空坐标系里，结合楼层的平面图做全局热力展示，用消息队列把各路的检测结果汇聚到统一分析引擎中。

第二个方向是把简单的IoU匹配升级成真正的多目标跟踪。现在系统能统计“这个时刻有多少人”，但还不能回答“这5分钟进来了哪些人、他们在场内停留了多久”。引入ByteTrack或者DeepSORT之后，可以输出轨迹数据，进而做停留时长分析、常驻区域识别、热力轨迹回放。这些信息对商场运营来说价值极高——转化分析、动线优化、异常聚集预警全都建立在真实的轨迹数据之上。

第三个方向是模型轻量化部署到边缘设备。现在的推理服务跑在服务器GPU上，如果你需要把检测能力下放到现场的小盒子（比如Jetson Orin或者RK3588），模型要转成TensorRT或RKNN格式，并且对模型做剪枝量化。模型精度会有一定损失，但换来的好处是单台边缘设备离线就能完成检测和预警，不需要依赖中心服务器，这对网络条件不好的场景非常实用。

我自己接下来的计划是在现有系统上补上ByteTrack做轨迹跟踪，然后尝试把v12模型导出成TensorRT的engine格式，看看推理延迟能不能压到5毫秒以内。如果这些做成了，再来跟大家分享第二轮实战经验。