企业官网建设流程全解析

1. 项目缘起与整体架构设计

森林野外火灾的早期发现，说白了就是跟时间赛跑。烟一起、火一冒，前十分钟能不能报警，直接决定了后面是烧掉几亩林子还是几百亩。传统方案要么靠人工瞭望塔，要么靠卫星遥感，前者费人、后者延迟大，都不太适合做分钟级的实时预警。这套系统的出发点很直接：用无人机或固定摄像头采集林区画面，边缘端跑YOLO做火焰烟雾检测，检测到疑似目标后把画面和坐标推给后端，后端再调用大模型做二次研判和自然语言描述，最后在Web端集中展示和告警。

整套架构我拆成四层来看，这样后面讲细节的时候不容易乱：

• 感知层：无人机图传、固定枪机、红外热成像，负责出图。
• 推理层：Flask + YOLO，跑在边缘盒子或就近服务器上，负责逐帧检测。
• 业务层：Spring Boot，负责设备管理、告警流转、任务调度、数据落库。
• 交互层：Vue前端 + DeepSeek/千问大模型，负责可视化展示和智能问答。

为什么推理层用Flask而不是直接塞进Spring Boot？这是很多人问我的第一个问题。Java生态里做深度学习推理，要么走ONNX Runtime的Java binding，要么走DJL，能用但坑多，尤其是YOLO这种版本迭代极快的模型，Python侧的ultralytics库几乎是一行代码就能切换v8到v12，Java侧每次换模型都要重新折腾预处理和后处理。所以我的选择是：Python专注推理，Java专注业务，两边用HTTP + JSON通信，边界清晰，谁挂了都不至于拖垮对方。

提示：边缘设备和业务服务器之间建议走内网或专线，检测结果用轻量JSON推送，原始图片按需回传，不要每帧都传原图，带宽扛不住。

1.1 为什么是YOLO而不是两阶段检测器

火焰和烟雾这两个目标有个共同特点：形态极度不固定。火焰可能是跳跃的小火苗，也可能是连成一片的火线；烟雾更是从一缕青烟到遮天蔽日的浓烟都有。Faster R-CNN这类两阶段检测器精度是好，但推理速度在边缘设备上很难做到实时，而且林区监控往往是多路视频并发，算力预算非常紧张。

YOLO系列是单阶段检测，一次前向就出框，速度优势明显。从v8开始，ultralytics把训练、验证、导出、推理全流程都封装得很顺手，v10引入了无NMS的设计思路，v11在精度和速度的平衡上又往前走了一步，v12开始往注意力机制和更高效的骨干网络方向演进。这套系统之所以要支持v8/v10/v11/v12多个版本，核心目的就是做横向对比——不同林区、不同硬件、不同天气条件下，哪个版本的综合表现最好，得用数据说话，不能拍脑袋。

1.2 大模型在这里到底干什么

很多人觉得检测就检测，加个大模型是不是噱头。我一开始也这么想，但实际跑下来发现大模型解决了一个很实际的问题：误报的二次过滤和语义化描述。

YOLO检测到"疑似烟雾"的框，可能只是晨雾、云影、扬尘。这时候把检测框裁剪出来，连同周边画面一起丢给DeepSeek或千问，让模型判断"这是否为真实火灾烟雾"，同时生成一句人话描述，比如"画面左下角出现灰白色絮状烟雾，疑似地表火初期，建议立即核查"。值班人员看到的不再是一个冷冰冰的框，而是一句能直接指导行动的判断。这个环节把误报率压下来不少，也让非专业的值班人员能快速理解情况。

2. 核心细节解析与实操要点

2.1 数据集准备：林火数据的坑比想象中多

林火检测的数据集，公开的有，但直接拿来用往往效果一般。原因在于场景差异太大：你拿平原秸秆焚烧的数据去训山区林火，模型学到的特征根本对不上。我的做法是公开数据集打底 + 自采数据微调。

标注用LabelImg，导出YOLO格式的txt。这里有个细节很多人忽略：火焰和烟雾的标注边界怎么定。烟雾边缘是渐变的，标太紧会漏特征，标太松会把背景框进去。我的经验是烟雾标注到"肉眼可辨识的明显烟雾区域"外扩约10%即可，火焰则贴着火焰轮廓标，因为火焰边界相对清晰。

类别就设两类：fire和smoke。不要设"大火""小火""白烟""黑烟"这种细分，林区场景下细分意义不大，反而增加标注难度和类别不平衡风险。

数据增强这块，除了常规的翻转、缩放、色彩抖动，我强烈建议加上雾天模拟和低照度模拟。林区清晨起雾、傍晚光线暗是常态，不加这两类增强，模型一到实际场景就抓瞎。Mosaic增强在v8之后是默认开的，对小火苗这种小目标提升明显，但要注意Mosaic比例别开太高，否则容易出现"拼接痕迹"被模型当成特征。

注意：标注完成后一定要做一次数据清洗，把空标注文件、损坏图片、重复图片筛掉。我踩过一次坑，训练loss一直不降，查了半天发现是有一批图片的标注坐标全是0，模型在学"什么都没有"。

2.2 模型训练：从v8到v12的参数差异

训练脚本本身不复杂，ultralytics的接口很统一，但不同版本在超参上有些微妙差异，直接套用同一套参数效果会打折扣。

以v8为基准，我的起始配置大致是这样：

from ultralytics import YOLO model = YOLO("yolov8s.pt") model.train( data="forest_fire.yaml", epochs=150, imgsz=640, batch=16, lr0=0.01, lrf=0.01, momentum=0.937, weight_decay=0.0005, warmup_epochs=3, mosaic=1.0, mixup=0.1, copy_paste=0.1, device=0 )

v10和v11的骨干网络变了，学习率可以适当调低一点，我一般用0.008起步。v12如果用了带注意力的结构，warmup要拉长到5个epoch，否则前期容易震荡。batch size受显存限制，如果只有单张消费级显卡，batch=8配合梯度累积也能跑，但训练时间会拉长。

模型尺寸选择上，林火检测我推荐s或m，nano太小精度不够，l和x在边缘设备上跑不动。如果边缘盒子算力实在有限，nano版本配合更高分辨率输入（比如imgsz=960）也能凑合，但延迟会上去。

训练过程中重点盯三个指标：mAP50、mAP50-95和recall。林火场景下recall比precision更重要，宁可多报几个假警，也不能漏掉真火。所以如果发现recall偏低，优先调低置信度阈值，或者增加正样本权重。

2.3 Flask推理服务的接口设计

Flask这边我设计得尽量轻，核心就两个接口：一个接收图片做检测，一个做健康检查。

from flask import Flask, request, jsonify from ultralytics import YOLO import cv2 import numpy as np app = Flask(__name__) model = YOLO("best.pt") @app.route("/detect", methods=["POST"]) def detect(): file = request.files["image"] img_bytes = np.frombuffer(file.read(), np.uint8) img = cv2.imdecode(img_bytes, cv2.IMREAD_COLOR) results = model(img, conf=0.35, iou=0.45) detections = [] for r in results: for box in r.boxes: detections.append({ "cls": int(box.cls[0]), "conf": float(box.conf[0]), "xyxy": box.xyxy[0].tolist() }) return jsonify({"detections": detections}) @app.route("/health", methods=["GET"]) def health(): return jsonify({"status": "ok"})

置信度阈值conf我设0.35，比常规的0.25高一点，因为林火场景背景干扰多，阈值太低误报爆炸。但如果是夜间红外画面，可以降到0.25，红外下烟雾特征更明显。

这里有个性能优化的点：模型加载只做一次，放在全局，不要每次请求都重新加载。我见过有人把YOLO("best.pt")写在接口函数里，结果每次请求都要加载几百MB的权重，延迟直接上秒级。

另外，如果并发量高，Flask自带的开发服务器扛不住，要用gunicorn配合多worker。但注意每个worker都会加载一份模型，显存要算够。比如4个worker，每个模型占2GB显存，那就得8GB以上。

2.4 Spring Boot业务层的核心职责

Spring Boot这边不碰推理，专注做四件事：设备管理、告警接收、任务调度、数据持久化。

设备管理用简单的CRUD，每台设备记录IP、端口、位置、状态。告警接收提供一个REST接口，Flask检测到目标后POST过来，Spring Boot落库并触发后续流程。任务调度用Spring的@Scheduled，定期去拉取设备状态，或者定时清理过期告警。

和Flask的通信我用RestTemplate，简单直接。如果要更优雅，可以用WebClient做异步，但林火场景下告警量不会特别大，同步足够。

@PostMapping("/alert/receive") public ResponseEntity<?> receiveAlert(@RequestBody AlertDTO alert) { alertService.save(alert); if (alert.getConfidence() > 0.6) { alertService.pushToFrontend(alert); llmService.analyzeAsync(alert); } return ResponseEntity.ok().build(); }

这里有个设计取舍：高置信度告警直接推前端，低置信度的先攒着，等大模型研判完再决定是否推送。这样既保证了紧急情况的实时性，又避免了低质量告警刷屏。

2.5 Vue前端的可视化要点

前端用Vue 3 + Element Plus，核心页面就三个：实时监控、告警列表、模型对比。

实时监控页要能播放视频流，这里涉及m3u8的播放。林区带宽有限，直接用RTMP延迟低但兼容性差，HLS（m3u8）兼容性好但延迟高。我的折中方案是：边缘端做检测，只把检测结果和关键帧推给前端，视频流用低码率的HLS做预览，真正要看细节的时候再拉高清帧。

告警列表用表格展示，支持按时间、置信度、设备筛选。每条告警旁边有个"AI研判"按钮，点了之后调后端接口，把大模型的分析结果展示出来。

模型对比页是个亮点，把v8/v10/v11/v12在同一个测试集上的mAP、FPS、模型大小做成对比表格和柱状图，一目了然。

3. 实操过程与核心环节实现

3.1 环境搭建：从零到跑通

先说硬件。我测试用的配置是：边缘端一台带RTX 3060的工控机，业务端一台普通云服务器（4核8G），前端就是浏览器访问。

软件环境：

• 边缘端：Ubuntu 22.04 + Python 3.10 + CUDA 11.8 + PyTorch 2.1 + ultralytics 8.x
• 业务端：JDK 17 + Spring Boot 3.2 + MySQL 8.0 + Redis
• 前端：Node 18 + Vue 3 + Vite

Python环境我强烈建议用conda隔离，因为ultralytics对torch版本有要求，和系统里其他Python项目容易冲突。

conda create -n fire python=3.10 conda activate fire pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics flask opencv-python

Spring Boot项目用IDEA新建，依赖选Web、MySQL、Redis、Lombok。有个小坑：IDEA启动Spring Boot不显示端口号，一般是日志配置问题，在application.yml里加上logging.level.root=info就能看到。

Vue项目用Vite创建，npm create vite@latest，选Vue 3。依赖装完如果npm install卡住，换淘宝镜像。

3.2 模型训练与导出

数据准备好之后，写forest_fire.yaml：

path: ./dataset train: images/train val: images/val nc: 2 names: ["fire", "smoke"]

然后跑训练。我一般先跑50个epoch看趋势，如果mAP还在涨就继续，涨不动了就停。150个epoch是上限，再多容易过拟合。

训练完导出模型，边缘端部署用ONNX或TensorRT。TensorRT速度快但导出麻烦，ONNX通用性好。如果边缘端是NVIDIA显卡，建议导出TensorRT engine，FPS能翻倍。

model.export(format="engine", half=True, device=0)

half=True是FP16量化，精度损失很小，速度提升明显。但注意有些老显卡不支持FP16，导出会报错，那就去掉这个参数。

3.3 大模型接入：DeepSeek和千问的调用

大模型这块，我用的是API调用方式，不本地部署。原因很简单：本地部署大模型对硬件要求太高，业务服务器扛不住，而且林火场景下大模型调用频率不高，API成本可以接受。

DeepSeek的调用：

import requests def analyze_fire(image_base64, api_key): url = "https://api.deepseek.com/v1/chat/completions" headers = {"Authorization": f"Bearer {api_key}"} payload = { "model": "deepseek-chat", "messages": [ {"role": "system", "content": "你是森林火灾研判专家，请判断图片中是否为真实火灾烟雾，并给出简短描述。"}, {"role": "user", "content": f"请分析这张图片：{image_base64}"} ] } resp = requests.post(url, json=payload, headers=headers) return resp.json()["choices"][0]["message"]["content"]

千问的调用类似，换endpoint和model名即可。实际用下来，两个模型在火灾研判上表现都不错，DeepSeek的中文描述更自然，千问在多图对比上稍强。

注意：API key不要硬编码在代码里，用环境变量或配置中心。我见过有人把key提交到GitHub，第二天就被刷爆了。

3.4 端到端联调

联调顺序建议：先单独测Flask检测接口，用Postman传图，确认能返回框；再测Spring Boot接收告警，用Postman模拟Flask的POST；最后前端连后端，看数据能不能正常展示。

联调时最容易出问题的是图片编码。Flask收到的是multipart文件，Spring Boot转发给大模型时要转base64，前端展示时又要转回URL。这一串转换里，编码格式不统一就会乱码。我的做法是全程用base64，前端拿到base64直接塞进img标签的src。

另一个坑是跨域。Vue开发时跑在5173端口，Spring Boot跑在8080，浏览器会拦跨域请求。后端加@CrossOrigin注解，或者配个CorsFilter。

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

4.1 检测效果差：先别急着换模型

很多人一发现检测效果不好就想换更大的模型，其实大部分时候问题出在数据和阈值上。我整理了一个排查顺序：

我遇到过一次典型问题：白天检测很准，一到傍晚就疯狂误报。查了半天发现是训练集里傍晚的样本太少，模型把"暗色调"当成了烟雾特征。补了200张傍晚的负样本之后，问题解决。

4.2 推理速度慢：从这几个地方下手

FPS上不去，按这个顺序排查：

1. 模型是否用了TensorRT：ONNX比PyTorch快，TensorRT比ONNX快，差距能到2-3倍。
2. 是否开了FP16：half=True，速度提升明显。
3. 输入分辨率是否过高：640够用就别上1280。
4. 是否每帧都检测：视频可以隔帧检测，中间帧用跟踪算法补。
5. CPU是否成为瓶颈：图片解码、预处理如果走CPU，可能比推理还慢，用GPU解码。

4.3 大模型调用超时

大模型API偶尔会慢，如果同步调用会阻塞告警流程。我的做法是异步调用 + 超时降级：告警先推前端，大模型分析结果后到后补。如果大模型超时，就只展示YOLO的原始检测结果，不阻塞主流程。

@Async public void analyzeAsync(AlertDTO alert) { try { String result = llmService.analyze(alert.getImageBase64()); alert.setAiAnalysis(result); alertService.update(alert); } catch (Exception e) { log.warn("大模型分析失败，降级处理", e); } }

4.4 内存泄漏：Flask长时间运行必看

Flask跑久了内存一直涨，大概率是图片对象没释放。OpenCV的Mat对象、numpy数组，用完要显式释放。另外，ultralytics的results对象如果一直持有，也会占内存。

我的做法是每次请求处理完，手动del掉大对象，并定期重启worker。gunicorn配--max-requests 1000，跑满1000个请求自动重启worker，能有效防止内存泄漏累积。

4.5 模型对比：数据说话

最后说下模型对比这块，我实测下来（同一测试集，RTX 3060）：

v12精度最高但速度略慢，v11综合最均衡，v8最成熟稳定。如果边缘设备算力紧张，v8s是稳妥选择；如果追求精度且算力充足，v12s值得上。

我个人在实际部署中的体会是，别盲目追新版本。v8的生态最完善，遇到问题资料最多；v11和v12虽然指标好看，但有些部署工具链还没跟上，导出TensorRT时偶尔会碰到算子不支持的情况。选版本的时候，先看你的部署环境支持到哪一代，再决定用哪个。

最后分享一个小技巧：如果林区网络不稳定，可以在边缘端做个本地缓存队列，检测到告警先存本地，网络恢复后再批量上传。这样即使断网，也不会丢告警。