简介面向水产养殖与计算机视觉研究者的技术文档系统讲解YOLOv11在鱼类行为识别与密度统计中的完整落地方法。文档针对传统人工监测效率低、成本高、难以实时预警等痛点从智慧养殖需求与YOLO系列算法演进讲起重点剖析YOLOv11的网络结构优化、多尺度特征融合与损失函数改进并逐步展开数据采集PythonOpenCV、图像清洗标注、数据集划分、模型配置训练、行为分类识别、目标计数与密度计算以及系统评估与优化等环节覆盖数据准备、模型训练、结果验证全流程配有可运行代码示例和实验对比分析。资源包含1份PDF文档约1.95MB共30页支持目录跳转与大纲定位结构清晰、阅读便捷。已有85人学习适合水产养殖智能化从业者、计算机视觉初学者及高校课题师生作为方案参考。1. 智慧养殖进入“视觉时代”为什么是YOLOv11来做鱼类行为识别与密度统计水产养殖的利润模型里饲料成本和死鱼损耗是两个最深的水下黑洞。传统靠人工巡塘、掂网采样、肉眼估重的方式既依赖老师傅的经验又无法覆盖24小时连续变化。一个7000立方米的循环水车间摄像头装得再多如果后端算法跟不上画面也只是“看着安心”不产生决策价值。鱼类行为识别和密度统计本质是把连续视频变成结构化数据某区域此刻有多少尾鱼、游动速度是否异常、抢食是否剧烈、有没有长时间停滞在水面或池底的个体。有了这组数据投饵机才能按需启停增氧机才能提前响应。YOLOv11出现在这个场景里原因很直接它把“实时性”和“易部署性”做到了一线项目能接受的程度。相比前代v11在检测头结构、训练收敛速度和模型体积上都做了调整对水下这种光照不匀、遮挡严重、目标尺寸小的视频流配合切片推理和帧间后处理能稳定跑出30FPS以上的实时结果。这篇文章不会绕道讲框架原理手册直接沿着“数据准备 — 模型训练 — 行为识别逻辑 — 密度统计口径 — 部署排坑”这条路把能复现的命令和参数逐个落地。适合正在做智慧渔业项目、或者准备把目标检测引入农业场景的算法工程师和全栈开发者。2. YOLOv11的模型结构与水下目标的适配逻辑2.1 从C3k2到检测头v11相对v8到底改了什么YOLOv11的Backbone延续了CSPNet风格但把v8里用的C2f模块换成了C3k2这是第一个肉眼可见的变化。C3k2内部用两个卷积分支加一个可选的k×k卷积堆叠在同样FLOPs预算下特征表达的非线性更强。对鱼类目标来说鱼身是细长形态鳃盖和尾鳍属于高频纹理C3k2这种“少层次、多分支”的结构在浅层能保留更多边缘细节不会像深层金字塔那样直接丢失小目标的轮廓信息。真正影响水下任务的是检测头的解耦设计v11保留了Anchor-Free分支用DFLDistribution Focal Loss来回归边界框的分布而不是直接回归四个坐标值。这一点的实际意义在于DFL让框的输出变成一个离散概率分布模型对“这尾鱼到底多长”的估计会综合考虑相邻尺寸的权重。水下画面因为折射和悬浮颗粒鱼体边缘往往是模糊渐变硬回归容易把框抖来抖去DFL的软分布对这类噪声更稳。训练时还有一个容易被忽略的细节v11在分类分支和回归分支之间增加了独立的BN层这虽然只是工程上的小改动但能明显缓解水下数据里“分类易、定位难”导致的梯度不平衡。所以如果是从v8迁移过来不要只改配置文件里的yaml版本号损失函数和增强策略要根据鱼的形态重新调。2.1.1 网络结构图中的关键尺寸谁在决定小目标检测能力看YOLOv11的结构图时重点看三个输出特征图的尺寸。输入640×640经过Backbone和Neck后检测头分别在80×80、40×40、20×20的特征图上做预测。80×80这一层拥有最大的感受野密度用来负责小目标。但实际水下项目中摄像头覆盖一个8米直径的圆形养殖池单尾鱼在画面里可能只有30×15像素这时候即便用上80×80的特征图每个grid cell对应的原始像素区域仍约等于8×8单尾鱼落在3~4个cell里本身是够用的问题出在正样本分配的尺度策略上。YOLOv11的标签分配策略会根据GT框的尺寸自动选择匹配的层级但鱼的尺寸波动极大——刚投苗时只有3厘米养成期能到30厘米同一个批次里大小混养也很常见。如果GT框纵横比超过1:4默认的anchor匹配策略会将其判定为困难样本导致小尺寸的鱼在前几百个epoch里学不到有效梯度。常见做法是关闭Mosaic后几轮的增强v11默认会自动衰减并配合多尺度训练参数让模型见过更多不同分辨率的鱼体。2.2 为什么不能直接套用COCO预训练权重COCO的80类里没有鱼这一类更别提“进食中的鱼”和“缺氧浮头的鱼”这种细粒度行为状态。但这不代表预训练权重无用。v11的预训练权重在ImageNet和COCO上学到的底层特征是通用的鳃盖的纹理边缘、鱼鳞的反光模式、水波纹的干扰形态这些Low-level特征可以直接迁移。正确的做法是保留Backbone和Neck的权重随机初始化检测头然后用鱼类数据微调。如果你直接从头训练以几千张水下图片的数据量模型会在第50个epoch前后开始过拟合验证集mAP50涨到0.85附近就停滞但mAP50-95始终上不去典型的“框得准但框不全”。用预训练权重时还要修改数据集的类别数。假设只识别一种鱼nc设为1如果是多品种混养比如草鱼和鲤鱼要分别统计那nc设为2或更多。修改之后检测头的输出通道数会从COCO的80类自动重建这时候如果你用ultralytics的API系统会检测nc变化并重设对应层的shape不需要手动改权重文件的结构。但有一个坑如果你使用了自己魔改的网络结构比如加了注意力模块预训练权重加载时会提示缺失key此时需要设置strictFalse让缺少的层以默认初始化开始训练。3. 数据准备与标注策略决定模型上限的第一步3.1 水下鱼群视频的采集与抽帧规范很多人把精力花在调参上却忽略了输入数据的质量下限。水下摄像头拍到的视频因为水体浊度、灯光阴影、气泡干扰单帧的有效信息量远低于地面场景。采集时要注意三个点第一摄像头固定安装尽量减少晃动因为行为识别依赖帧间连续性画面抖动会让鱼的动作矢量失真第二灯光尽量用侧光或顶光避免正面强光造成鱼鳞反光过曝反光区域在模型眼里是一团白色噪点第三拍摄时段要覆盖喂食前、喂食中、喂食后、夜间四个典型节点否则行为识别的样本多样性不够。抽帧的节奏也有讲究。24小时连续视频如果每秒抽1帧一天就是86400张大部分是冗余的。建议按场景动态抽帧静止时段每10秒抽1帧喂食时段的视频单独切成片段每0.5秒抽1帧。这样既保证行为变化的连续性又不会让数据集被高相似度的画面淹没。抽帧用OpenCV几行代码就可以实现关键在于按视频的时间戳分段处理而不是一次性读入全量帧。ffmpeg -i feed_session_01.mp4 -vf fps2 -q:v 2 feed_frames/frame_%04d.jpg这个命令把喂食视频按2fps抽帧q:v设置为2保证JPEG质量。注意fps参数控制的是输出帧率而不是抽帧间隔如果你的原视频是30fpsfps2意味着每15帧取1帧。抽出来的图片先按“时段池号摄像头编号”重命名便于后续按场景划分训练集和验证集。3.1.1 标注工具与类别体系设计标注工具推荐LabelImg或X-AnyLabeling后者对视频标注更友好。标注之前先定义好类别体系这直接决定了行为识别的复杂度。建议按“对象行为状态”组合标注normal正常游动、feeding抢食、surface_gasping浮头、lethargic呆滞。这里注意不要用单一类别“fish”做目标检测然后指望后续用行为识别算法去区分状态因为鱼的姿态在视觉上差异明显直接建模成多类别检测器本身的分类分支就能帮你做第一层行为过滤后续的行为分析只需在同类别的轨迹和密度变化上做文章省掉一个额外的分类模型。标注时还有一个容易忽略的边界情况鱼群重叠严重时很多标注工具画出的框IoU会超过0.7模型训练时NMS会把置信度低的框抑制掉导致漏检。应对策略是按“可见轮廓”标准来标注——只要鱼头或鱼身前半部分可见就标注一个完整的预测框不要因为尾部被遮挡就把整条鱼删掉。这样做检测器能学到“可见部分推断整体位置”的能力推理时对密集场景的鲁棒性明显提升。3.2 构建YOLOv11训练数据集目录结构、YAML配置与增强参数数据集准备好后按ultralytics的标准格式组织目录然后写模型对应的YAML文件。这里给出一个可以直接修改使用的配置dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yaml# data.yaml path: /home/user/fish_dataset train: images/train val: images/val nc: 4 names: 0: normal 1: feeding 2: surface_gasping 3: lethargicYAML里的path字段要用绝对路径相对路径在ultralytics的新版本里虽然支持但如果你同时跑多个项目绝对路径能避免不少低级错误。nc和names的数量和顺序必须与标注文件里的类别ID严格一致这里最容易出错的是当你删除了某个类别后忘记同步YAML训练时index越界会直接报错。数据增强在ultralytics里通过训练参数控制默认的Mosaic增强在鱼类数据集上建议做两个调整一是把mosaic超参数在前10个epoch关闭因为水下鱼群本来就密集Mosaic的四图拼接会把不同水体和光照条件的鱼混在一起让模型学到错误的不变特征二是hsv_h、hsv_s和hsv_v这三项默认值在水下场景可以适度调大因为水下光照变化剧烈颜色增强能提升模型对水体浊度变化的鲁棒性但注意不要超过默认值的1.5倍否则鱼的体色会失真到无法辨认。4. 模型训练与推理优化从命令行到核心参数说明4.1 用YOLOv11训练自己的鱼群检测模型最小可复现命令环境配置这里直接梳理精简路径Python 3.9或3.10PyTorch 2.0以上CUDA 11.8或12.1然后安装ultralytics包。不需要手动编译CUDA算子v11的常规模块在PyPI轮子里都有预编译版本。安装完成后跑训练命令yolo detect train \ --model yolov11s.pt \ --data fish_data.yaml \ --epochs 150 \ --imgsz 640 \ --batch 16 \ --patience 20 \ --device 0这里一个容易踩的坑是不指定model的参数规模而直接使用默认值。yolov11s.pt指的是small版本在640分辨率下推理一张图大约需要2.1ms根据GPU型号不同有浮动训练速度也比nano版慢一些但精度提升明显。如果你的显存只有8GB把batch降到8或者把imgsz降到480但imgsz一旦低于480yolov11的检测头对小鱼目标的召回率会显著下降。patience设为20代表连续20个epoch验证集指标没有提升就自动停止避免你在训练时去手动盯日志。训练过程中要看的指标不只是mAP50日志里Pprecision和Rrecall的差值值得重点关注。鱼类数据集常见的情况是P高R低意味着检测器倾向于“保守”——它只框那些特征明显的鱼对遮挡和模糊的鱼选择忽略。这时候调conf_thres没有意义问题出在训练时的正样本分配上。v11的解决方案是调整anchor_t和box_loss_gainanchor_t是标签分配的IoU阈值默认是4.0适当降低到3.0会让更多低质量预测框参与学习R值的提升会比较明显但要注意P会小幅回落需要在验证集上做权衡。4.2 训练后的预测、保存与结果验证训练完成后模型权重保存在runs/detect/train/weights/目录下best.pt是验证集指标最优的权重last.pt是最后一个epoch的权重。从经验上说如果训练没有出现过拟合训练损失和验证损失同步下降last.pt在多数场景下比best.pt更可靠。推理时保存结果用yolo detect predict \ --model runs/detect/train/weights/best.pt \ --source ./test_videos/pond_03.mp4 \ --conf 0.35 \ --iou 0.45 \ --save-txt \ --save-crop \ --project ./runs/predictconf阈值建议设到0.3~0.4之间。水下场景的检测框置信度本来就比地面低设到0.5会漏掉不少被气泡遮挡的鱼。save-txt会输出与每帧对应的标签文件格式是“类别ID x_center y_center width height”这是后续做密度统计和行为分析的原始输入。save-crop会把每个检测框内的图像裁剪保存方便你快速看一眼检测结果的质量——这个习惯很重要它比盯着终端里的mAP数字更直观地暴露问题。运行结束之后在runs/predict目录下检查三件事检测框有没有漏掉小目标同类鱼框的IoU是否过大导致计数重复夜间画面里是否存在大量误检。任何一项有问题都回到数据集和增强参数上找原因不要去动模型结构。4.2.1 在Python脚本中调用模型实现逐帧推理命令行适合快速验证但实际项目中行为识别和密度统计需要逐帧处理视频并叠加业务逻辑所以要用Python API来接。下面这段代码展示了从加载模型到逐帧处理的关键流程from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) def process_frame(frame, frame_id): results model.predict( frame, conf0.35, iou0.45, classes[0, 1, 2, 3], verboseFalse ) boxes results[0].boxes cls_ids boxes.cls.cpu().numpy().astype(int) xywh boxes.xywh.cpu().numpy() return cls_ids, xywh # 视频读取循环中调用 import cv2 cap cv2.VideoCapture(test_videos/pond_03.mp4) frame_id 0 while cap.isOpened(): ret, frame cap.read() if not ret: break cls_ids, xywh process_frame(frame, frame_id) # 这里可以追加密度统计或行为判断逻辑 frame_id 1 cap.release()这段代码的关键点是predict方法里传入了classes参数显式限制检测类别范围。如果你的模型曾经训练过4个类别但部署时只想统计正常游动的鱼用classes过滤比在代码里写if判断要高效得多。boxes.xywh返回的是归一化后的中心点坐标和宽高如果要换算成实际像素坐标需要乘以原图像宽高。帧循环里有一个性能隐患需要提前处理model.predict方法每次调用都有内部预处理和NMS计算如果视频分辨率高于1080P建议先用cv2.resize把帧缩放到模型输入尺寸附近。5. 身份管理用ByteTrack在连续视频帧中保持鱼类轨迹ID5.1 为什么光靠检测框算不出准确的鱼群数量一个非常常见但容易忽略的技术细节是视频里直接数检测框等于把统计结果建立在“每一帧都独立”的假设上。这在鱼群密集的场景下是不成立的——同一帧里鱼A的半边身体被鱼B遮挡检测器偶尔会把A漏掉下一帧A又重新出现计数就会在真实值和少一之间跳变。如果直接把每帧的框数量求平均波动会大到没法用。解决这个问题的方式是引入目标追踪Tracking给每条被检测到的鱼分配一个全局唯一的track_id。有了track_id之后鱼群数量的统计口径就变成了“在单位时间内出现的唯一ID数量”而不是“每帧检测框数量的均值”。5.2 在YOLOv11上接入ByteTrack的配置与代码实现YOLOv11没有内置追踪器但ultralytics框架留了追踪接口常见做法是接入ByteTrack或BoT-SORT。ByteTrack之所以适合鱼类场景是因为它处理低置信度检测框的方式特别友好——它不像SORT那样把低于阈值的框直接扔掉而是利用高置信度框和低置信度框的关联关系保留被遮挡目标的位置估计。你要做的改造不需要太深直接用ultralytics的追踪API即可from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) # 原理说明track()方法内部会自动完成检测跟踪两步操作 # persistTrue表示跟踪器状态会跨帧保存保持ID的连续性 results model.track( sourcetest_videos/pond_03.mp4, conf0.35, iou0.45, trackerbytetrack.yaml, persistTrue, saveFalse, streamTrue ) for frame_idx, r in enumerate(results): if r.boxes is None or r.boxes.id is None: continue # 从检测框对象里同时取类别、坐标和轨迹ID track_ids r.boxes.id.cpu().numpy().astype(int) cls_ids r.boxes.cls.cpu().numpy().astype(int) xywh r.boxes.xywh.cpu().numpy() # 按track_id聚合每帧的鱼的位置和类别 for tid, cid, box in zip(track_ids, cls_ids, xywh): cx, cy, w, h box print(fframe{frame_idx}, track_id{tid}, class{cid}, x{cx:.2f}, y{cy:.2f})track()方法传了离线视频路径它会自动处理视频解码、逐帧推理和跟踪ID分配。值得注意的是tracker参数指定的bytetrack.yaml配置文件在ultralytics的安装目录下可以找到里面有track_buffer、match_thresh等跟踪器超参数。水下项目中track_buffer默认的30帧可能需要调大一些因为鱼游动速度慢在画面里滞留时间长track_buffer太小会导致短暂遮挡后ID就丢了。5.2.1 track_id丢失与跳变如何用缓冲机制稳定轨迹跟踪器在鱼重叠严重或者突然转向时最容易出现ID切换一个ID中途跳成另一个ID。这时候不能指望跟踪器完全不出错而是在应用层做容错。一个常见的做法是引入“轨迹去重”逻辑记录一个track_id连续出现的起止帧号如果某条轨迹的存活时间低于某个阈值比如3帧大概率是跟踪器碎片化产生的噪声在统计时把它过滤掉。另一个做法是维护一个双向映射表当检测到跨帧ID跳变时根据位置IoU把新旧ID关联起来实现“合并计数”而不是“重复计数”。这两种逻辑叠加Buffer窗口能显著提高密度统计的稳定性。6. 鱼类行为识别与密度统计算法实战6.1 行为识别策略不是训练行为模型而是定义行为数学模型行为识别的首要决策是要不要单独训练一个时间序列模型比如LSTM或Transformer来分类鱼的行为。我的答案是“不要默认这么做”——在养殖场景里绝大多数行为状态可以通过检测结果的时间和空间分布直接推导。比如“进食”最显著的特征是检测框的移动速度显著加快并且多个框的IoU重叠率短时间内快速上升“缺氧浮头”的特征是大量鱼在同一时间涌向水面区域画面顶部且横向移动速度趋近于零“呆滞”的特征是单条鱼的轨迹在长期内滞留在一个小范围内。这些都能用纯几何计算和分析做出来省掉训练行为模型的大量成本。下面是作者在项目中常用的行为变化检测核心逻辑适合在帧循环里对track_id做状态判定from collections import defaultdict import math class FishBehaviorTracker: def __init__(self, fps30): self.fps fps # 使用字典存储每个track_id的历史轨迹 self.traj defaultdict(list) # 每个track_id在画面中的累计移动距离 self.total_dist defaultdict(float) def update(self, track_id, cx, cy): hist self.traj[track_id] if hist: prev_x, prev_y hist[-1] dx cx - prev_x dy cy - prev_y # 欧氏距离表示相邻两帧的位移 self.total_dist[track_id] math.sqrt(dx*dx dy*dy) hist.append((cx, cy)) # 只保留最近N帧的轨迹控制内存占用 if len(hist) self.fps * 10: hist.pop(0) def speed(self, track_id): # 计算最近1秒内的平均移动速度像素/秒 hist self.traj[track_id] if len(hist) 2: return 0.0 recent hist[-self.fps:] dist sum(math.hypot(recent[i][0]-recent[i-1][0], recent[i][1]-recent[i-1][1]) for i in range(1, len(recent))) return dist / (len(recent) / self.fps)这段代码的思路是维护一个高频轨迹缓冲区通过累计移动距离来判定行为类别。speed值配合检测框与投饵机的区域判断就能区分“抢食高速且集中在投饵区”和“正常巡游中速且全池分布”。行为识别输出不必输出一个严格的类别标签可以做成区间阈值速度小于5像素/秒且持续5秒标记为呆滞速度大于20像素/秒且集中在喂食区标记为进食。6.2 密度统计的两种口径基于轨迹的去重计数与基于密度图的估计密度统计在鱼群场景有两种方法论独立存在一种是前面提到的基于检测跟踪的“轨迹去重计数”另一种是基于密度图的回归计数。前者精度高但严重依赖跟踪稳定性后者抗遮挡能力强但无法提供个体级的位置信息。在养殖场景里跟踪稳定性其实远高于人流量统计因为鱼是分批投放、数量固定的不存在无限进出的情况。所以我通常选择“轨迹去重计数”为主“截断样本修正”为辅。具体的统计口径是设定一个时间窗口比如5分钟在这个窗口内出现的去重track_id数量即为该区域的“活跃鱼群数量”。这个数值比瞬时帧的框平均更稳定适合作为投喂决策的反馈信号。密度统计算法落地的计算量也值得提一下。按30FPS处理1080P视频单纯做检测每帧大约需要50ms GPU时间加上跟踪和统计实际能达到20FPS左右。如果你需要同时处理4路摄像头单张显卡的资源就吃紧了。这时候用画面分割推理把一张大图切成多个patch分别推理会带来重复计数的问题建议改成每路摄像头独立进程处理再在统计层合并结果。6.2.1 水下遮挡场景的密度补偿静态区域修正法水下遮挡是无法消除的物理干扰但有一个低成本修正方案在固定机位下标定画面中的结构遮挡区域比如池中央的立柱、增氧盘统计这些区域面积占整个画面的比例。然后用可见区域的去重计数除以可见比例得到全池估计量。这个修正系数在安装摄像头后做一次静态标定即可不需要在线动态维护。如果鱼群在画面中分布不均匀常常聚集在投饵区则按区域网格比如4×4网格分别统计再求和让每个网格独立乘以补偿系数——这个方法在工程上足够有效。6.3 结果验证如何判断计数误差在可接受范围内算法写完了验证方式很重要。在投放鱼苗时人工按批次记录一个精确的总数N。部署系统运行后持续监控系统输出的活跃轨迹数在人工投喂且光线条件好的时段取连续10分钟的峰值根据经验这在多数情况下等价于“全部鱼都在活动”的状态。如果这个峰值与N的偏差超过30%优先检查跟踪器的track_buffer是否太长导致ID被合并其次检查conf阈值是否过高导致小鱼漏检。另一种验证方式是人工截取5段每个10秒的视频片段手动数鱼并和算法输出做对比记录误差率。在密度统计场景中工程上通用的验收标准是误差率在±15%以内即可。注意不要用准确率这个指标鱼群里个体尺寸小、重叠频繁人工计数本身也有误差准确率的数字没有实操意义。7. 部署实战模型导出与推理管线收敛在边缘设备7.1 导出为TensorRT引擎而不是直接跑PyTorch模型水下养殖车间的算力环境通常不比数据中心常见是一台IPC工控机配一张RTX 3060或更高一点的卡。PyTorch模型在GPU上推理虽然速度快但显存占用和延迟抖动不稳定。生产环境里把训练好的模型导出成TensorRT FP16引擎是成熟路径。执行导出之前先确认你装的ultralytics版本对应的TensorRT版本兼容性然后用一行命令完成导出yolo export modelruns/detect/train/weights/best.pt formatengine device0 halfTrue导出成功的标志是目录下生成一个best.engine文件注意输出日志里的“TensorRT initialized”字样不要只看文件后缀。engine文件是绑定特定GPU型号的换一张卡必须重新导出。halfTrue开启FP16量化对鱼类目标检测场景精度损失通常在0.5%以内速度提升约60%——如果追求更极限的性能可以用int8量化但需要准备校准数据集。calibration命令在ultralytics里需要手动传入校准图片目录这里不展开因为多数项目用FP16已经足够满足实时性要求。7.2 推理管线中的缓存复用与掉帧策略视频流推理时最容易忽略的性能瓶颈在“预处理”和“后处理”上而不在模型推理本身。cv2读取一帧、BGR转RGB、缩放、归一化这些操作如果每次重复分配内存叠加起来会占掉5ms以上的CPU时间。解决办法是在管线启动时固定一块缓冲区每帧读入后直接写入这块内存不产生新的numpy数组。另外如果跑不到目标FPS宁可掉帧也不要积压延迟。正确策略是让采集线程持续读帧推理线程只拿最新帧丢弃中间未处理的旧帧。下面是部署时常用的线程化推理的最小骨架import threading import cv2 from ultralytics import YOLO class InferencePipeline: def __init__(self, source, engine_path): self.cap cv2.VideoCapture(source) self.model YOLO(engine_path, taskdetect) self.running True self.latest_frame None self.lock threading.Lock() def capture_loop(self): while self.running: ret, frame self.cap.read() if not ret: break with self.lock: self.latest_frame frame def infer_loop(self): while self.running: with self.lock: frame self.latest_frame if frame is not None: results self.model.predict(frame, conf0.35, imgsz640) # 在这里接入行为识别和密度统计逻辑这个骨架解决的是视频源读取和推理速度不匹配的问题。capture_loop线程负责快速读帧infer_loop线程只处理最新帧两者通过锁保护共享变量。注意锁定时间要尽量短不要在锁内做耗时操作。在实际项目中推流地址RTSP如果断流OpenCV的read方法会阻塞需要给capture_loop加超时处理否则整个管线挂起。7.3 实际部署落地的3个进阶排错点部署阶段常见的三个坑每个都能让系统在验收时翻车。第一类坑在光线变化水产车间的灯光在夜间会自动切换色温同一个模型的检测置信度会在夜间下降10个百分点左右。解决方案不是关灯训练而是在训练数据里增补一部分夜间红外灯下的图片配合Augment的HSV增强模型会对光线变化更鲁棒。第二类坑在水产车间的湿度GPU工控机的散热如果直接吸入潮湿空气推理卡的显存频率会因温度升高自动降频表现为FPS从稳定30跌到18。需要做机箱的防尘防潮处理或者在软件里加FPS告警。第三类坑是模型版本管理训练时用的best.pt和部署时的engine文件可能是不同时间训练的如果中途重训过导出的engine与训练时的结构不一致会导致推理结果异常。这要求运维上设置机制部署时检查engine文件对应的md5值确保版本匹配。最后说一个容易被忽视的验证技巧把推理结果同时保存成带标注框的MP4视频每天抽一段人工回放对比检测框是否跟随鱼体、ID是否稳定、类别标签是否符合目视。这个人工抽检习惯能兜住算法指标之外的“体感问题”——数值上mAP都很好但客户看到视频觉得“不准”往往就是因为这些细节。本文还有配套的精品资源点击获取 
长河君 · 2026/9/18 2:51:22 · 阅读 1.2k YOLOv11实战智慧养殖：鱼类行为识别与密度统计算法全解析
简介面向水产养殖与计算机视觉研究者的技术文档系统讲解YOLOv11在鱼类行为识别与密度统计中的完整落地方法。文档针对传统人工监测效率低、成本高、难以实时预警等痛点从智慧养殖需求与YOLO系列算法演进讲起重点剖析YOLOv11的网络结构优化、多尺度特征融合与损失函数改进并逐步展开数据采集PythonOpenCV、图像清洗标注、数据集划分、模型配置训练、行为分类识别、目标计数与密度计算以及系统评估与优化等环节覆盖数据准备、模型训练、结果验证全流程配有可运行代码示例和实验对比分析。资源包含1份PDF文档约1.95MB共30页支持目录跳转与大纲定位结构清晰、阅读便捷。已有85人学习适合水产养殖智能化从业者、计算机视觉初学者及高校课题师生作为方案参考。1. 智慧养殖进入“视觉时代”为什么是YOLOv11来做鱼类行为识别与密度统计水产养殖的利润模型里饲料成本和死鱼损耗是两个最深的水下黑洞。传统靠人工巡塘、掂网采样、肉眼估重的方式既依赖老师傅的经验又无法覆盖24小时连续变化。一个7000立方米的循环水车间摄像头装得再多如果后端算法跟不上画面也只是“看着安心”不产生决策价值。鱼类行为识别和密度统计本质是把连续视频变成结构化数据某区域此刻有多少尾鱼、游动速度是否异常、抢食是否剧烈、有没有长时间停滞在水面或池底的个体。有了这组数据投饵机才能按需启停增氧机才能提前响应。YOLOv11出现在这个场景里原因很直接它把“实时性”和“易部署性”做到了一线项目能接受的程度。相比前代v11在检测头结构、训练收敛速度和模型体积上都做了调整对水下这种光照不匀、遮挡严重、目标尺寸小的视频流配合切片推理和帧间后处理能稳定跑出30FPS以上的实时结果。这篇文章不会绕道讲框架原理手册直接沿着“数据准备 — 模型训练 — 行为识别逻辑 — 密度统计口径 — 部署排坑”这条路把能复现的命令和参数逐个落地。适合正在做智慧渔业项目、或者准备把目标检测引入农业场景的算法工程师和全栈开发者。2. YOLOv11的模型结构与水下目标的适配逻辑2.1 从C3k2到检测头v11相对v8到底改了什么YOLOv11的Backbone延续了CSPNet风格但把v8里用的C2f模块换成了C3k2这是第一个肉眼可见的变化。C3k2内部用两个卷积分支加一个可选的k×k卷积堆叠在同样FLOPs预算下特征表达的非线性更强。对鱼类目标来说鱼身是细长形态鳃盖和尾鳍属于高频纹理C3k2这种“少层次、多分支”的结构在浅层能保留更多边缘细节不会像深层金字塔那样直接丢失小目标的轮廓信息。真正影响水下任务的是检测头的解耦设计v11保留了Anchor-Free分支用DFLDistribution Focal Loss来回归边界框的分布而不是直接回归四个坐标值。这一点的实际意义在于DFL让框的输出变成一个离散概率分布模型对“这尾鱼到底多长”的估计会综合考虑相邻尺寸的权重。水下画面因为折射和悬浮颗粒鱼体边缘往往是模糊渐变硬回归容易把框抖来抖去DFL的软分布对这类噪声更稳。训练时还有一个容易被忽略的细节v11在分类分支和回归分支之间增加了独立的BN层这虽然只是工程上的小改动但能明显缓解水下数据里“分类易、定位难”导致的梯度不平衡。所以如果是从v8迁移过来不要只改配置文件里的yaml版本号损失函数和增强策略要根据鱼的形态重新调。2.1.1 网络结构图中的关键尺寸谁在决定小目标检测能力看YOLOv11的结构图时重点看三个输出特征图的尺寸。输入640×640经过Backbone和Neck后检测头分别在80×80、40×40、20×20的特征图上做预测。80×80这一层拥有最大的感受野密度用来负责小目标。但实际水下项目中摄像头覆盖一个8米直径的圆形养殖池单尾鱼在画面里可能只有30×15像素这时候即便用上80×80的特征图每个grid cell对应的原始像素区域仍约等于8×8单尾鱼落在3~4个cell里本身是够用的问题出在正样本分配的尺度策略上。YOLOv11的标签分配策略会根据GT框的尺寸自动选择匹配的层级但鱼的尺寸波动极大——刚投苗时只有3厘米养成期能到30厘米同一个批次里大小混养也很常见。如果GT框纵横比超过1:4默认的anchor匹配策略会将其判定为困难样本导致小尺寸的鱼在前几百个epoch里学不到有效梯度。常见做法是关闭Mosaic后几轮的增强v11默认会自动衰减并配合多尺度训练参数让模型见过更多不同分辨率的鱼体。2.2 为什么不能直接套用COCO预训练权重COCO的80类里没有鱼这一类更别提“进食中的鱼”和“缺氧浮头的鱼”这种细粒度行为状态。但这不代表预训练权重无用。v11的预训练权重在ImageNet和COCO上学到的底层特征是通用的鳃盖的纹理边缘、鱼鳞的反光模式、水波纹的干扰形态这些Low-level特征可以直接迁移。正确的做法是保留Backbone和Neck的权重随机初始化检测头然后用鱼类数据微调。如果你直接从头训练以几千张水下图片的数据量模型会在第50个epoch前后开始过拟合验证集mAP50涨到0.85附近就停滞但mAP50-95始终上不去典型的“框得准但框不全”。用预训练权重时还要修改数据集的类别数。假设只识别一种鱼nc设为1如果是多品种混养比如草鱼和鲤鱼要分别统计那nc设为2或更多。修改之后检测头的输出通道数会从COCO的80类自动重建这时候如果你用ultralytics的API系统会检测nc变化并重设对应层的shape不需要手动改权重文件的结构。但有一个坑如果你使用了自己魔改的网络结构比如加了注意力模块预训练权重加载时会提示缺失key此时需要设置strictFalse让缺少的层以默认初始化开始训练。3. 数据准备与标注策略决定模型上限的第一步3.1 水下鱼群视频的采集与抽帧规范很多人把精力花在调参上却忽略了输入数据的质量下限。水下摄像头拍到的视频因为水体浊度、灯光阴影、气泡干扰单帧的有效信息量远低于地面场景。采集时要注意三个点第一摄像头固定安装尽量减少晃动因为行为识别依赖帧间连续性画面抖动会让鱼的动作矢量失真第二灯光尽量用侧光或顶光避免正面强光造成鱼鳞反光过曝反光区域在模型眼里是一团白色噪点第三拍摄时段要覆盖喂食前、喂食中、喂食后、夜间四个典型节点否则行为识别的样本多样性不够。抽帧的节奏也有讲究。24小时连续视频如果每秒抽1帧一天就是86400张大部分是冗余的。建议按场景动态抽帧静止时段每10秒抽1帧喂食时段的视频单独切成片段每0.5秒抽1帧。这样既保证行为变化的连续性又不会让数据集被高相似度的画面淹没。抽帧用OpenCV几行代码就可以实现关键在于按视频的时间戳分段处理而不是一次性读入全量帧。ffmpeg -i feed_session_01.mp4 -vf fps2 -q:v 2 feed_frames/frame_%04d.jpg这个命令把喂食视频按2fps抽帧q:v设置为2保证JPEG质量。注意fps参数控制的是输出帧率而不是抽帧间隔如果你的原视频是30fpsfps2意味着每15帧取1帧。抽出来的图片先按“时段池号摄像头编号”重命名便于后续按场景划分训练集和验证集。3.1.1 标注工具与类别体系设计标注工具推荐LabelImg或X-AnyLabeling后者对视频标注更友好。标注之前先定义好类别体系这直接决定了行为识别的复杂度。建议按“对象行为状态”组合标注normal正常游动、feeding抢食、surface_gasping浮头、lethargic呆滞。这里注意不要用单一类别“fish”做目标检测然后指望后续用行为识别算法去区分状态因为鱼的姿态在视觉上差异明显直接建模成多类别检测器本身的分类分支就能帮你做第一层行为过滤后续的行为分析只需在同类别的轨迹和密度变化上做文章省掉一个额外的分类模型。标注时还有一个容易忽略的边界情况鱼群重叠严重时很多标注工具画出的框IoU会超过0.7模型训练时NMS会把置信度低的框抑制掉导致漏检。应对策略是按“可见轮廓”标准来标注——只要鱼头或鱼身前半部分可见就标注一个完整的预测框不要因为尾部被遮挡就把整条鱼删掉。这样做检测器能学到“可见部分推断整体位置”的能力推理时对密集场景的鲁棒性明显提升。3.2 构建YOLOv11训练数据集目录结构、YAML配置与增强参数数据集准备好后按ultralytics的标准格式组织目录然后写模型对应的YAML文件。这里给出一个可以直接修改使用的配置dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yaml# data.yaml path: /home/user/fish_dataset train: images/train val: images/val nc: 4 names: 0: normal 1: feeding 2: surface_gasping 3: lethargicYAML里的path字段要用绝对路径相对路径在ultralytics的新版本里虽然支持但如果你同时跑多个项目绝对路径能避免不少低级错误。nc和names的数量和顺序必须与标注文件里的类别ID严格一致这里最容易出错的是当你删除了某个类别后忘记同步YAML训练时index越界会直接报错。数据增强在ultralytics里通过训练参数控制默认的Mosaic增强在鱼类数据集上建议做两个调整一是把mosaic超参数在前10个epoch关闭因为水下鱼群本来就密集Mosaic的四图拼接会把不同水体和光照条件的鱼混在一起让模型学到错误的不变特征二是hsv_h、hsv_s和hsv_v这三项默认值在水下场景可以适度调大因为水下光照变化剧烈颜色增强能提升模型对水体浊度变化的鲁棒性但注意不要超过默认值的1.5倍否则鱼的体色会失真到无法辨认。4. 模型训练与推理优化从命令行到核心参数说明4.1 用YOLOv11训练自己的鱼群检测模型最小可复现命令环境配置这里直接梳理精简路径Python 3.9或3.10PyTorch 2.0以上CUDA 11.8或12.1然后安装ultralytics包。不需要手动编译CUDA算子v11的常规模块在PyPI轮子里都有预编译版本。安装完成后跑训练命令yolo detect train \ --model yolov11s.pt \ --data fish_data.yaml \ --epochs 150 \ --imgsz 640 \ --batch 16 \ --patience 20 \ --device 0这里一个容易踩的坑是不指定model的参数规模而直接使用默认值。yolov11s.pt指的是small版本在640分辨率下推理一张图大约需要2.1ms根据GPU型号不同有浮动训练速度也比nano版慢一些但精度提升明显。如果你的显存只有8GB把batch降到8或者把imgsz降到480但imgsz一旦低于480yolov11的检测头对小鱼目标的召回率会显著下降。patience设为20代表连续20个epoch验证集指标没有提升就自动停止避免你在训练时去手动盯日志。训练过程中要看的指标不只是mAP50日志里Pprecision和Rrecall的差值值得重点关注。鱼类数据集常见的情况是P高R低意味着检测器倾向于“保守”——它只框那些特征明显的鱼对遮挡和模糊的鱼选择忽略。这时候调conf_thres没有意义问题出在训练时的正样本分配上。v11的解决方案是调整anchor_t和box_loss_gainanchor_t是标签分配的IoU阈值默认是4.0适当降低到3.0会让更多低质量预测框参与学习R值的提升会比较明显但要注意P会小幅回落需要在验证集上做权衡。4.2 训练后的预测、保存与结果验证训练完成后模型权重保存在runs/detect/train/weights/目录下best.pt是验证集指标最优的权重last.pt是最后一个epoch的权重。从经验上说如果训练没有出现过拟合训练损失和验证损失同步下降last.pt在多数场景下比best.pt更可靠。推理时保存结果用yolo detect predict \ --model runs/detect/train/weights/best.pt \ --source ./test_videos/pond_03.mp4 \ --conf 0.35 \ --iou 0.45 \ --save-txt \ --save-crop \ --project ./runs/predictconf阈值建议设到0.3~0.4之间。水下场景的检测框置信度本来就比地面低设到0.5会漏掉不少被气泡遮挡的鱼。save-txt会输出与每帧对应的标签文件格式是“类别ID x_center y_center width height”这是后续做密度统计和行为分析的原始输入。save-crop会把每个检测框内的图像裁剪保存方便你快速看一眼检测结果的质量——这个习惯很重要它比盯着终端里的mAP数字更直观地暴露问题。运行结束之后在runs/predict目录下检查三件事检测框有没有漏掉小目标同类鱼框的IoU是否过大导致计数重复夜间画面里是否存在大量误检。任何一项有问题都回到数据集和增强参数上找原因不要去动模型结构。4.2.1 在Python脚本中调用模型实现逐帧推理命令行适合快速验证但实际项目中行为识别和密度统计需要逐帧处理视频并叠加业务逻辑所以要用Python API来接。下面这段代码展示了从加载模型到逐帧处理的关键流程from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) def process_frame(frame, frame_id): results model.predict( frame, conf0.35, iou0.45, classes[0, 1, 2, 3], verboseFalse ) boxes results[0].boxes cls_ids boxes.cls.cpu().numpy().astype(int) xywh boxes.xywh.cpu().numpy() return cls_ids, xywh # 视频读取循环中调用 import cv2 cap cv2.VideoCapture(test_videos/pond_03.mp4) frame_id 0 while cap.isOpened(): ret, frame cap.read() if not ret: break cls_ids, xywh process_frame(frame, frame_id) # 这里可以追加密度统计或行为判断逻辑 frame_id 1 cap.release()这段代码的关键点是predict方法里传入了classes参数显式限制检测类别范围。如果你的模型曾经训练过4个类别但部署时只想统计正常游动的鱼用classes过滤比在代码里写if判断要高效得多。boxes.xywh返回的是归一化后的中心点坐标和宽高如果要换算成实际像素坐标需要乘以原图像宽高。帧循环里有一个性能隐患需要提前处理model.predict方法每次调用都有内部预处理和NMS计算如果视频分辨率高于1080P建议先用cv2.resize把帧缩放到模型输入尺寸附近。5. 身份管理用ByteTrack在连续视频帧中保持鱼类轨迹ID5.1 为什么光靠检测框算不出准确的鱼群数量一个非常常见但容易忽略的技术细节是视频里直接数检测框等于把统计结果建立在“每一帧都独立”的假设上。这在鱼群密集的场景下是不成立的——同一帧里鱼A的半边身体被鱼B遮挡检测器偶尔会把A漏掉下一帧A又重新出现计数就会在真实值和少一之间跳变。如果直接把每帧的框数量求平均波动会大到没法用。解决这个问题的方式是引入目标追踪Tracking给每条被检测到的鱼分配一个全局唯一的track_id。有了track_id之后鱼群数量的统计口径就变成了“在单位时间内出现的唯一ID数量”而不是“每帧检测框数量的均值”。5.2 在YOLOv11上接入ByteTrack的配置与代码实现YOLOv11没有内置追踪器但ultralytics框架留了追踪接口常见做法是接入ByteTrack或BoT-SORT。ByteTrack之所以适合鱼类场景是因为它处理低置信度检测框的方式特别友好——它不像SORT那样把低于阈值的框直接扔掉而是利用高置信度框和低置信度框的关联关系保留被遮挡目标的位置估计。你要做的改造不需要太深直接用ultralytics的追踪API即可from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) # 原理说明track()方法内部会自动完成检测跟踪两步操作 # persistTrue表示跟踪器状态会跨帧保存保持ID的连续性 results model.track( sourcetest_videos/pond_03.mp4, conf0.35, iou0.45, trackerbytetrack.yaml, persistTrue, saveFalse, streamTrue ) for frame_idx, r in enumerate(results): if r.boxes is None or r.boxes.id is None: continue # 从检测框对象里同时取类别、坐标和轨迹ID track_ids r.boxes.id.cpu().numpy().astype(int) cls_ids r.boxes.cls.cpu().numpy().astype(int) xywh r.boxes.xywh.cpu().numpy() # 按track_id聚合每帧的鱼的位置和类别 for tid, cid, box in zip(track_ids, cls_ids, xywh): cx, cy, w, h box print(fframe{frame_idx}, track_id{tid}, class{cid}, x{cx:.2f}, y{cy:.2f})track()方法传了离线视频路径它会自动处理视频解码、逐帧推理和跟踪ID分配。值得注意的是tracker参数指定的bytetrack.yaml配置文件在ultralytics的安装目录下可以找到里面有track_buffer、match_thresh等跟踪器超参数。水下项目中track_buffer默认的30帧可能需要调大一些因为鱼游动速度慢在画面里滞留时间长track_buffer太小会导致短暂遮挡后ID就丢了。5.2.1 track_id丢失与跳变如何用缓冲机制稳定轨迹跟踪器在鱼重叠严重或者突然转向时最容易出现ID切换一个ID中途跳成另一个ID。这时候不能指望跟踪器完全不出错而是在应用层做容错。一个常见的做法是引入“轨迹去重”逻辑记录一个track_id连续出现的起止帧号如果某条轨迹的存活时间低于某个阈值比如3帧大概率是跟踪器碎片化产生的噪声在统计时把它过滤掉。另一个做法是维护一个双向映射表当检测到跨帧ID跳变时根据位置IoU把新旧ID关联起来实现“合并计数”而不是“重复计数”。这两种逻辑叠加Buffer窗口能显著提高密度统计的稳定性。6. 鱼类行为识别与密度统计算法实战6.1 行为识别策略不是训练行为模型而是定义行为数学模型行为识别的首要决策是要不要单独训练一个时间序列模型比如LSTM或Transformer来分类鱼的行为。我的答案是“不要默认这么做”——在养殖场景里绝大多数行为状态可以通过检测结果的时间和空间分布直接推导。比如“进食”最显著的特征是检测框的移动速度显著加快并且多个框的IoU重叠率短时间内快速上升“缺氧浮头”的特征是大量鱼在同一时间涌向水面区域画面顶部且横向移动速度趋近于零“呆滞”的特征是单条鱼的轨迹在长期内滞留在一个小范围内。这些都能用纯几何计算和分析做出来省掉训练行为模型的大量成本。下面是作者在项目中常用的行为变化检测核心逻辑适合在帧循环里对track_id做状态判定from collections import defaultdict import math class FishBehaviorTracker: def __init__(self, fps30): self.fps fps # 使用字典存储每个track_id的历史轨迹 self.traj defaultdict(list) # 每个track_id在画面中的累计移动距离 self.total_dist defaultdict(float) def update(self, track_id, cx, cy): hist self.traj[track_id] if hist: prev_x, prev_y hist[-1] dx cx - prev_x dy cy - prev_y # 欧氏距离表示相邻两帧的位移 self.total_dist[track_id] math.sqrt(dx*dx dy*dy) hist.append((cx, cy)) # 只保留最近N帧的轨迹控制内存占用 if len(hist) self.fps * 10: hist.pop(0) def speed(self, track_id): # 计算最近1秒内的平均移动速度像素/秒 hist self.traj[track_id] if len(hist) 2: return 0.0 recent hist[-self.fps:] dist sum(math.hypot(recent[i][0]-recent[i-1][0], recent[i][1]-recent[i-1][1]) for i in range(1, len(recent))) return dist / (len(recent) / self.fps)这段代码的思路是维护一个高频轨迹缓冲区通过累计移动距离来判定行为类别。speed值配合检测框与投饵机的区域判断就能区分“抢食高速且集中在投饵区”和“正常巡游中速且全池分布”。行为识别输出不必输出一个严格的类别标签可以做成区间阈值速度小于5像素/秒且持续5秒标记为呆滞速度大于20像素/秒且集中在喂食区标记为进食。6.2 密度统计的两种口径基于轨迹的去重计数与基于密度图的估计密度统计在鱼群场景有两种方法论独立存在一种是前面提到的基于检测跟踪的“轨迹去重计数”另一种是基于密度图的回归计数。前者精度高但严重依赖跟踪稳定性后者抗遮挡能力强但无法提供个体级的位置信息。在养殖场景里跟踪稳定性其实远高于人流量统计因为鱼是分批投放、数量固定的不存在无限进出的情况。所以我通常选择“轨迹去重计数”为主“截断样本修正”为辅。具体的统计口径是设定一个时间窗口比如5分钟在这个窗口内出现的去重track_id数量即为该区域的“活跃鱼群数量”。这个数值比瞬时帧的框平均更稳定适合作为投喂决策的反馈信号。密度统计算法落地的计算量也值得提一下。按30FPS处理1080P视频单纯做检测每帧大约需要50ms GPU时间加上跟踪和统计实际能达到20FPS左右。如果你需要同时处理4路摄像头单张显卡的资源就吃紧了。这时候用画面分割推理把一张大图切成多个patch分别推理会带来重复计数的问题建议改成每路摄像头独立进程处理再在统计层合并结果。6.2.1 水下遮挡场景的密度补偿静态区域修正法水下遮挡是无法消除的物理干扰但有一个低成本修正方案在固定机位下标定画面中的结构遮挡区域比如池中央的立柱、增氧盘统计这些区域面积占整个画面的比例。然后用可见区域的去重计数除以可见比例得到全池估计量。这个修正系数在安装摄像头后做一次静态标定即可不需要在线动态维护。如果鱼群在画面中分布不均匀常常聚集在投饵区则按区域网格比如4×4网格分别统计再求和让每个网格独立乘以补偿系数——这个方法在工程上足够有效。6.3 结果验证如何判断计数误差在可接受范围内算法写完了验证方式很重要。在投放鱼苗时人工按批次记录一个精确的总数N。部署系统运行后持续监控系统输出的活跃轨迹数在人工投喂且光线条件好的时段取连续10分钟的峰值根据经验这在多数情况下等价于“全部鱼都在活动”的状态。如果这个峰值与N的偏差超过30%优先检查跟踪器的track_buffer是否太长导致ID被合并其次检查conf阈值是否过高导致小鱼漏检。另一种验证方式是人工截取5段每个10秒的视频片段手动数鱼并和算法输出做对比记录误差率。在密度统计场景中工程上通用的验收标准是误差率在±15%以内即可。注意不要用准确率这个指标鱼群里个体尺寸小、重叠频繁人工计数本身也有误差准确率的数字没有实操意义。7. 部署实战模型导出与推理管线收敛在边缘设备7.1 导出为TensorRT引擎而不是直接跑PyTorch模型水下养殖车间的算力环境通常不比数据中心常见是一台IPC工控机配一张RTX 3060或更高一点的卡。PyTorch模型在GPU上推理虽然速度快但显存占用和延迟抖动不稳定。生产环境里把训练好的模型导出成TensorRT FP16引擎是成熟路径。执行导出之前先确认你装的ultralytics版本对应的TensorRT版本兼容性然后用一行命令完成导出yolo export modelruns/detect/train/weights/best.pt formatengine device0 halfTrue导出成功的标志是目录下生成一个best.engine文件注意输出日志里的“TensorRT initialized”字样不要只看文件后缀。engine文件是绑定特定GPU型号的换一张卡必须重新导出。halfTrue开启FP16量化对鱼类目标检测场景精度损失通常在0.5%以内速度提升约60%——如果追求更极限的性能可以用int8量化但需要准备校准数据集。calibration命令在ultralytics里需要手动传入校准图片目录这里不展开因为多数项目用FP16已经足够满足实时性要求。7.2 推理管线中的缓存复用与掉帧策略视频流推理时最容易忽略的性能瓶颈在“预处理”和“后处理”上而不在模型推理本身。cv2读取一帧、BGR转RGB、缩放、归一化这些操作如果每次重复分配内存叠加起来会占掉5ms以上的CPU时间。解决办法是在管线启动时固定一块缓冲区每帧读入后直接写入这块内存不产生新的numpy数组。另外如果跑不到目标FPS宁可掉帧也不要积压延迟。正确策略是让采集线程持续读帧推理线程只拿最新帧丢弃中间未处理的旧帧。下面是部署时常用的线程化推理的最小骨架import threading import cv2 from ultralytics import YOLO class InferencePipeline: def __init__(self, source, engine_path): self.cap cv2.VideoCapture(source) self.model YOLO(engine_path, taskdetect) self.running True self.latest_frame None self.lock threading.Lock() def capture_loop(self): while self.running: ret, frame self.cap.read() if not ret: break with self.lock: self.latest_frame frame def infer_loop(self): while self.running: with self.lock: frame self.latest_frame if frame is not None: results self.model.predict(frame, conf0.35, imgsz640) # 在这里接入行为识别和密度统计逻辑这个骨架解决的是视频源读取和推理速度不匹配的问题。capture_loop线程负责快速读帧infer_loop线程只处理最新帧两者通过锁保护共享变量。注意锁定时间要尽量短不要在锁内做耗时操作。在实际项目中推流地址RTSP如果断流OpenCV的read方法会阻塞需要给capture_loop加超时处理否则整个管线挂起。7.3 实际部署落地的3个进阶排错点部署阶段常见的三个坑每个都能让系统在验收时翻车。第一类坑在光线变化水产车间的灯光在夜间会自动切换色温同一个模型的检测置信度会在夜间下降10个百分点左右。解决方案不是关灯训练而是在训练数据里增补一部分夜间红外灯下的图片配合Augment的HSV增强模型会对光线变化更鲁棒。第二类坑在水产车间的湿度GPU工控机的散热如果直接吸入潮湿空气推理卡的显存频率会因温度升高自动降频表现为FPS从稳定30跌到18。需要做机箱的防尘防潮处理或者在软件里加FPS告警。第三类坑是模型版本管理训练时用的best.pt和部署时的engine文件可能是不同时间训练的如果中途重训过导出的engine与训练时的结构不一致会导致推理结果异常。这要求运维上设置机制部署时检查engine文件对应的md5值确保版本匹配。最后说一个容易被忽视的验证技巧把推理结果同时保存成带标注框的MP4视频每天抽一段人工回放对比检测框是否跟随鱼体、ID是否稳定、类别标签是否符合目视。这个人工抽检习惯能兜住算法指标之外的“体感问题”——数值上mAP都很好但客户看到视频觉得“不准”往往就是因为这些细节。本文还有配套的精品资源点击获取