YOLO11n 是 Ultralytics 在 YOLOv8 之后推出的轻量级目标检测模型我拿到手后做的第一个完整落地项目是工地安全帽佩戴检测。这篇笔记准备了很久把从选型、数据标注、训练调参、部署到排查问题的全过程都整理了出来。如果你正准备用 YOLO11 系列做目标检测或者卡在“模型能跑通但效果不对”“训练完不知道怎么部署”这个阶段这篇内容应该能给你省下不少时间。全文围绕 YOLO11n 展开不涉及复杂理论推导尽量用实际项目的视角讲清楚每一处关键选择背后的原因。1. 为什么最终选 YOLO11n一次目标检测模型的选型复盘1.1 项目背景与真实需求这个安全帽检测项目的实际需求其实很典型摄像头安装在工地出入口需要实时判断进入人员是否佩戴安全帽识别到未佩戴就触发告警。场景不算复杂但有几个硬约束第一设备是 Jetson Orin Nano 级别的边缘盒子不能用大模型第二需要 7×24 小时运行推理帧率不能低于 25 FPS第三现场网络不稳定不能依赖云端 API必须本地化推理。在这种需求下模型的选型思路就比较明确了第一优先级是“性能够用且推理够快”第二优先级是“部署生态成熟”。我当时横向对比了 YOLOv8n、YOLOv5n、YOLO11n 以及 SSD-MobileNet 这类经典轻量方案。SSD-MobileNet 虽然更快但小目标召回率明显不足安全帽在画面里占比不大所以优先排除。YOLOv5n 和 YOLOv8n 都很成熟但既然 Ultralytics 官方已经发布了 YOLO11 系列与其花时间在一个即将进入维护期的版本上不如直接用新一代模型。最终选 YOLO11n 的核心原因有三点一是参数规模约 2.6M计算量约 6.5 GFLOPs在边缘设备上有非常充裕的余量二是官方直接支持 ONNX、TensorRT、OpenVINO 多种导出格式部署链条完整三是检测头的解耦设计和新增的 C2PSA 模块在精度上相比同量级的 YOLOv8n 有一定提升。实际跑下来这个选择是正确的。1.2 YOLO11n 相比前代到底改了什么网上搜 YOLO11 的资料时你会发现很多文章把重点放在“更强”“更快”这种形容词上但真正上手后必须搞清楚它内部改了什么否则调参时容易抓瞎。结合 Ultralytics 源码和实测我理解的 YOLO11n 核心变化有四个方面第一骨干网络的 C3K2 模块替代了原来的 C2f。C2f 通过 split 和 concat 增强梯度流但参数量偏高C3K2 保留了类似 C3 的简洁结构同时用两个 3×3 卷积的组合替代部分 1×1 卷积在保持感受野的前提下减少了冗余参数。第二第四个 Stage 之后引入了 C2PSA 模块本质是 C2f 和轻量级多头自注意力的结合让模型在深层特征上具备更好的全局建模能力这对重叠目标和遮挡场景帮助很大。第三检测头继续使用解耦结构分类分支和回归分支分离各自输出独立特征同时保持 Anchor-Free 设计省掉了 Anchor 聚类的麻烦。第四整体深度和宽度比例做了调整nano 版本更保守不会因为追求精度牺牲推理速度。这些改动在实际项目中带来的体感是训练同样的轮次YOLO11n 的收敛速度略快于 YOLOv8n尤其是在验证集 mAP50-95 这个指标上尤其是当目标有遮挡或者背景相近时检测结果更稳定。当然这不是说 YOLOv8n 不行而是新模型在相近资源消耗下确实更优。注意YOLO 系列的版本迭代很快网上很多 YOLO3、YOLOv5 的旧教程里提到的配置方式在 YOLO11 里不一定适用。最靠谱的资料是 Ultralytics 官方文档和 GitHub 仓库直接看源码里的 yaml 配置比看二手博客更准确。1.3 与其他轻量级模型的对比选型为了让你更有体感我把当时看过的几类方案整理成一张对比表。表格里的数据来自官方模型卡和我的实测环境是 Jetson Orin Nano 8GBTensorRT FP16 推理输入分辨率 640×640。模型参数量计算量(GFLOPs)COCO mAP50-95边缘端推理FPS(实测)适合场景YOLO11n2.6M6.539.5%约55边缘实时检测轻量部署YOLOv8n3.2M8.737.3%约50轻量部署生态成熟YOLOv5n2.5M7.734.3%约48老项目兼容工业存量多SSD-MobileNetV24.3M1.322%左右约70极低算力设备精度要求不高RT-DETR-L32M11053.0%边缘端跑不动服务器端高精度场景从这张表能看出YOLO11n 在精度、速度、生态三者的平衡点是最好的。如果你的设备比 Jetson 更弱比如只有 CPU 或者树莓派那么可以选择 YOLO11n 再量化成 INT8或者退一步用 YOLOv8n。如果精度要求极高且设备算力充足那直接上 YOLO11m/l 或者 RT-DETR 这类 Transformer 结构模型更合适。选择模型不是越新越好而是匹配算力与场景需求。2. 数据集准备与标注最容易翻车的一个环节2.1 数据从哪里来怎么整理成 YOLO 格式很多初学者拿到 YOLO11n 之后第一件事就是跑官方预训练权重然后换自己的数据集训练结果发现效果远不如预期。原因往往不在模型而在数据。目标检测项目里我踩过最大的坑就是数据集质量。安全帽检测这个项目我使用了 4800 张现场图片其中 2600 张来自现场固定摄像头抓拍1200 张来自公开数据集如 SHWD 安全帽数据集剩下 1000 张是人工补充的包括不同光照、角度、遮挡情况。混合数据源要特别注意标签格式统一YOLO 格式的标注是每个 txt 文件对应一张图片每行是 class_id center_x center_y width height坐标归一化到 0~1 之间。如果你用的是 LabelImg 或者 Labelme 标注导出时选择 YOLO 格式即可。但我建议直接用 Roboflow 做数据管理它可以在线标注、自动导出 YOLO 格式还能一键做数据增强和数据集划分。不过要注意 Roboflow 免费版有图片数量限制而且它的增强操作会增多训练样本初学者可能搞不清哪些增强是自己加的哪些是原始数据后面出了问题不好排查。我个人的习惯是数据清洗和标注管理用 Roboflow导出后用 Python 脚本做一次格式校验确保没有坐标越界和空标注文件。2.2 类别不平衡与标注质量的实战处理安全帽检测这个任务标注了三类person人员、helmet安全帽、head未佩戴安全帽的头部。刚开始我用的是 helmet 和 no-helmet 二分类但训练后误报率很高因为模型会把背景中的圆形物体当成安全帽把安全帽拿在手里也识别成“已佩戴”。后来改成 person、helmet、head 三类让模型先检测人再根据头部区域是否存在 helmet 判断佩戴状态误报率降了很多。这个设计思路很重要与其让模型直接输出一个复杂的决策结果不如拆成多步推理模型只做它擅长的“检测”判断逻辑交给业务层完成。类别不平衡也是个容易被忽略的问题。我的数据里 person 样本非常多helmet 次之head未佩戴样本最少。训练时如果不做处理loss 会被 person 主导head 类别的召回率会很低。处理方法有两种一种是重采样对 head 类图片做重复采样或复制增强另一种是调整损失权重在 loss 函数里给样本少的类别更高的权重。Ultralytics 支持在数据配置中通过 weights 参数控制类别权重不过手动权重需要多试几次过于激进会导致 head 类过拟合。标注质量方面我发现最大的问题是框的边界随意。有些人标注安全帽时把整个帽子边缘都框进去有些人只框帽檐部分这种不一致会让模型的回归分支很难收敛。我的处理办法是写了一个简单的清洗脚本统计每个类别的宽高比分布找出异常偏离的值然后单独人工复核。这种做法效率不错可以帮你快速发现“标反了”或者“标漏了”的情况。2.3 训练集、验证集、测试集的划分细节数据集划分看上去简单但里面也有学问。安全帽数据里有很多来自同一摄像头连续帧的截图如果随机划分训练集和验证集里可能出现大量高度相似图片验证集指标虚高实际部署后效果立刻暴露问题。正确做法是尽可能按照“场景”划分同一个摄像头、同一天、同一段时间内抓拍的图片归入同一组避免数据泄漏。我的划分比例是训练集 3600 张、验证集 800 张、测试集 400 张。验证集用来做早停和超参数选择测试集只用于最终评估不参与任何训练决策。这个比例可能和你看到的七三开不同我建议在数据量足够的情况下刻意多留一点验证集因为小模型对验证集噪声非常敏感验证集太少会导致早停判断不稳定。另外一个细节是图片分辨率。原始抓拍图一般是 1920×1080直接使用会导致训练显存爆掉但缩太小又会丢失小目标。Ultralytics 的做法是训练时随机缩放和裁剪到 imgsz 大小默认 640。安全帽目标在原始图中大概占 30~100 像素640 分辨率下还能保持清晰度所以我训练时保持 640。如果你的目标是更小的小目标比如远距离的人脸或者红外小目标推荐使用 imgsz1280 训练再结合切片推理后面会详细说。3. 环境搭建与训练实操从零到一跑通 YOLO11n3.1 环境配置CUDA、PyTorch 与 Ultralytics 版本锁定的坑环境配置这里我不想啰嗦太多但有一个必须强调的教训版本锁定。Ultralytics 的迭代速度很快不同版本之间的行为差异有时候很大比如数据增强参数、loss 计算方式、默认超参数都会悄悄变化。同一份代码和数据集升级版本后训练结果可能完全不同。我的建议是创建独立的虚拟环境并锁定版本号。推荐方案是 Python 3.10 PyTorch 2.1.0 或 2.2.0 CUDA 11.8 或 12.1Ultralytics 版本固定到一个稳定版本。可以这样操作conda create -n yolo11 python3.10 conda activate yolo11 pip install torch2.1.0 torchvision0.16.0 --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics8.3.0为什么要固定版本因为我在一个项目里踩过坑ultralytics 8.2.x 升级到 8.3.x 后默认的数据增强策略变了同样的超参数训练出来的 mAP 掉了 2 个点一开始还以为是代码写错了排查了两天才发现是版本问题。从那时起我就养成了“记录环境和依赖版本”的习惯每次实验都把pip freeze requirements.txt保存下来。3.2 数据配置与训练命令详解数据准备完成后需要写一个数据 yaml 文件告诉 Ultralytics 图片路径和类别名称。我的文件长这样# helmet.yaml path: /data/helmet train: images/train val: images/val test: images/test names: 0: person 1: helmet 2: head注意path可以是相对路径或绝对路径建议用绝对路径避免不同环境之间的路径混淆问题。类别名称要和标注文件的索引对应好写错一个就会导致全部训练白费。训练命令非常简单Ultralytics 封装得相当好yolo detect train \ datahelmet.yaml \ modelyolo11n.pt \ epochs100 \ imgsz640 \ batch16 \ device0 \ workers4 \ patience20 \ cos_lrTrue \ lr00.01 \ lrf0.01 \ weight_decay0.0005 \ optimizerSGD这里面的关键参数我逐个解释一下。modelyolo11n.pt表示使用官方预训练权重作为初始权重这叫迁移学习。为什么不用随机初始化因为预训练模型已经在 COCO 上学会了通用特征提取能力迁移学习能让模型在 50 轮以内就收敛到不错的效果随机初始化则可能需要几百轮。epochs100在迁移学习场景下完全够用配合patience20早停机制如果连续 20 轮验证集指标没有提升就自动停止。batch16受限于 GPU 显存如果 8GB 显存跑 640 分辨率batch 16 差不多是上限。batch 大小会影响 BN 层的统计效果太小的 batch 会导致 BN 不稳定如果你的 GPU 显存不够可以考虑把imgsz降到 576 或者 512而不是强行用小 batch。cos_lrTrue表示使用余弦退火学习率调度前期快速下降、后期缓慢微调对收敛效果有明显帮助。optimizerSGD是官方在 COCO 上验证过的最稳方案AdamW 虽然收敛快但容易过拟合迁移学习场景下 SGD 往往泛化更好。3.3 训练日志、曲线与 loss 看懂多少才算入门训练开始后Ultralytics 会输出每轮的训练日志并在 runs/detect/train 文件夹下生成一堆曲线图。初学者经常只看 mAP 最后的值忽略了过程曲线里的诊断信息这是不对的。我至少会看四个图Box Loss、Cls Loss、Precision、Recall。Box Loss 是边界框回归的损失正常情况下应该持续下降并最终稳定在一个较小值。如果 Box Loss 反复震荡下不去说明回归任务太难或者标注质量太差。Cls Loss 是分类损失如果 Cls Loss 下降缓慢检查一下类别不平衡问题。Precision 高但 Recall 低说明模型“宁可少检不愿错检”适合误报惩罚高的场景反之 Recall 高 Precision 低说明模型倾向于多检适合漏检代价高的场景。安全帽检测这种场景我认为 Recall 比 Precision 更重要因为漏掉一个未佩戴安全帽的人是严重安全事故而误报只是让值守人员多看一眼。训练结束后best.pt 和 last.pt 两个权重文件要区分清楚。last.pt 是最后一轮的权重best.pt 是在验证集上表现最好的权重。默认验证指标是 mAP50-95但我个人经验是用 best.pt 做部署更稳妥。3.4 我这次训练的实际结果用上面这套配置我在一个单卡 10GB 显存的环境下训练了大约 1.5 小时早停在第 78 轮触发。最终验证集指标mAP50 是 0.941mAP50-95 是 0.763Precision 0.921Recall 0.938。对于一个轻量级 nano 模型来说这个结果可以接受尤其是 Recall 达到了 0.93 以上漏检率较低。不过要注意这个结果和数据集强相关。安全帽检测任务相对简单目标较大、类别少、背景固定如果你的任务是检测密集人群中的小目标或者红外场景下的弱小目标指标会比这个难看很多这是场景本身决定的不代表模型出了问题。4. 模型评估与推理部署训练完只是第一步4.1 mAP 系列指标的正确理解方式每次有人说“我的模型 mAP 达到 0.9”我都会追问一句你说的是 mAP50 还是 mAP50-95因为这两个数字差距巨大。mAP50 是当预测框和真实框的 IoU 大于 0.5 时算作检测正确然后计算所有类别的平均精度。这个指标比较宽松适合快速验证“模型是不是正常工作了”。mAP50-95 则是把 IoU 从 0.5 到 0.95 每隔 0.05 计算一次 AP然后取平均它要求预测框不仅类别正确位置还非常精准是学术界和工业界更认可的指标。部署时真正要关注的是 Precision-Recall 曲线。Ultralytics 会生成 per-class 的 PR 曲线你可以根据曲线选择合适的置信度阈值。比如安全帽场景我希望在保持高 Recall 的同时尽量提高 Precision在 PR 曲线上找到“拐点”对应置信度阈值大约是 0.35。实际部署时我把 conf_thres 设成了 0.35而不是默认的 0.25。千万别小看这个参数选择它比很多调参操作都有效。4.2 从 PyTorch 权重导出 ONNX 与 TensorRT训练完的 best.pt 是 PyTorch 格式但边缘设备上不会直接跑 PyTorch太慢了。我一般先用 ONNX 做中间格式验证如果设备是 NVIDIA 平台再转 TensorRT。导出 ONNX 的命令yolo export modelweights/best.pt formatonnx opset12 imgsz640导出后的 onnx 文件可以用onnxruntime或者OpenCV DNN加载。如果只是做验证onnxruntime CPU 推理大概每张图 20~30 毫秒如果追求极致性能在 Jetson 上转 TensorRT FP16推理时间能压到每张图约 8~12 毫秒。转换命令trtexec --onnxbest.onnx --saveEnginebest_fp16.engine --fp16这里有一个坑TensorRT 的 input 尺寸是固定的导出的时候 imgsz 是多少推理的时候就必须是多少或者用动态形状但会牺牲部分优化效果。所以部署前一定要想清楚线上分辨率不要训练用 640 推理用 1280否则预处理和后处理都要重新适配。4.3 推理代码里的 letterbox 与 NMS我见过不少人在部署环节翻车模型明明很准但线上框的位置偏移严重。问题大部分出在预处理时没有做 letterbox或者 letterbox 的参数和训练时不一致。YOLO 系列在训练时会把图片等比例缩放并填充灰色边保证输入图像不被拉伸变形。推理时你必须保持同样的操作否则坐标回归就会偏。Ultralytics 的 Python 推理已经封装好了但如果用 ONNX Runtime 自写推理预处理代码要注意几点一是原始图片除以 255 归一化二是将 BGR 转 RGB三是记录 letterbox 的填充量和缩放比例后处理时用这些参数把坐标映射回原图四是中心点坐标cx, cy不需要额外归一化因为模型输出已经是基于输入尺寸的比例值。NMS非极大值抑制的后处理同样重要。模型原始输出会给出大量冗余框NMS 把重叠度高的框合并保留置信度最高的。Ultralytics 默认使用 IoU 阈值 0.5 的 NMS如果你发现同一个目标上出现多个框适当降低 NMS 阈值如果发现真正重叠的目标被合并掉一个适当提高。安全帽这种目标重叠度高我把 NMS 阈值从 0.5 调到了 0.45效果更好一点。这个值也是靠验证集试出来的不是拍脑袋定的。提示在自写推理时一定要对比处理后的结果和 Ultralytics 自带推理的结果确认 bbox 坐标转换公式正确尤其是 letterbox 的 scale 和 padding 记录方式非常容易出错。5. 常见问题与排查技巧实录训练部署中的那些神坑5.1 Loss 下降但 mAP 不涨甚至跌了这是新手最容易困惑的问题明明训练集 loss 一直降验证集 mAP 却不见涨甚至还在跌。我遇到过几次最快的定位方式是检查训练集和验证集的分布是否一致。有一次我从网上爬了一批白天数据验证集里恰好大多是夜间数据那 mAP 下降就再正常不过了。还有一种情况是过拟合模型开始“死记硬背”训练集里的样本尤其是数据量不足或者增强不够的时候。解决方法是增大数据增强强度Ultralytics 里的 hsv 和 flip 参数、增加数据量、或者提前停止训练。5.2 小目标漏检严重目标占整图不到 1%YOLO11n 是小模型对小目标的敏感度天然不如大模型。安全帽已经算是中等目标但如果你做的是红外小目标或者远距离人脸检测会出现严重的漏检。排查思路有两个方向。方向一是提高输入分辨率把 imgsz 从 640 提到 1280训练和推理都改小目标像素数增加后检测率会明显上升但推理耗时也会变高。方向二是引入 P2 层更高分辨率的特征图YOLO11 默认从 P3 开始检测P2 层拥有原图 1/4 分辨率的特征对小目标更友好。Ultralytics 支持通过修改模型 yaml 增加额外检测头但这需要改动网络结构对新手不友好。我更推荐先用 SAHI切片辅助推理方案推理时把大图切成若干 640×640 的块分别检测再把结果合并。这种方式对小目标检测的提升非常显著缺点是推理耗时成倍增加适合离线分析场景。5.3 训练时 GPU 显存不足OOMYOLO11n 已经是最轻量的模型了如果你的 GPU 还是爆显存一般有两个原因一是 batch 太大二是 imgsz 太大三是开启了 cache 选项把数据一次性加载到显存。我建议按优先级排查先把 batch 减半然后把 imgsz 从 640 降到 512最后检查cacheTrue改成cacheFalse。如果还不行检查是否有其他进程占用显存。如果你的机器只有 4GB 显存训练 imgsz640、batch8 的 YOLO11n 理论上是可行的只要把workers适当调低就行。另外还有一个不常见但很搞人的问题workers设置太高导致系统内存不足进程被杀看起来像是 GPU OOM。适当降低workers到 4 或 2往往能解决这种假性 OOM。5.4 推理时出现大量重复框或漏框这个现象集中出现在自写推理代码的场景。如果同一个目标出现多个框先看 NMS 有没有执行再看 NMS 的阈值是否正确如果框的坐标偏移先检查 letterbox 参数是否一致如果有些目标明明很清晰却检测不出来先把 conf_thres 降到 0.1 看能不能检测出来如果还是检测不出来那说明模型没学好这个类别需要回到数据层面去补样本。排查逻辑应该是“先确认模型能力再排查部署环节”不要把问题都归到部署代码上。下面整理一份速查表方便你对照现象可能原因排查操作Loss 降但 mAP 不涨数据分布不一致检查训练/验证集来源使用场景分组划分小目标漏检输入分辨率低 / 特征层选择不当提高 imgsz、使用 SAHI切片推理GPU OOMbatch 或 imgsz 过大减小 batch、降低 imgsz、关闭 cache推理框偏移letterbox 参数不一致核对缩放比例与填充量大量重复框NMS 未执行或阈值太高执行 NMS降低 IoU 阈值到 0.4~0.5误报多背景样本不丰富补充负样本图片增加背景难例6. 从 YOLO11n 到更广阔的目标检测方向6.1 小目标、红外与频域特征的进阶思路做完安全帽项目后我开始关注更难的检测场景尤其是热词里反复出现的小目标检测和红外小目标检测。这类任务和普通目标检测有本质区别小目标在特征图上只占很少像素很容易在下采样过程丢失红外小目标则往往没有颜色纹理信息只有极低信噪比的亮度点。目前的主流思路有几个方向一是多尺度特征融合在 P2 甚至 P1 层增加检测头通过保留高分辨率特征图来捕捉小目标二是“空域-频域协同”思路把图像从空间域变换到频率域提取周期特征和细节特征再与空域特征融合这对红外弱小目标尤其有效三是基于注意力机制的方法让模型主动关注小目标的微弱特征。做 YOLO11n 时学到的训练技巧在这些场景基本适用但难度提升后数据增强策略和数据量要求会高一个量级。6.2 Transformer 端点检测与视觉语言模型的热度这几年目标检测领域明显分成两派以 YOLO 系列为代表的 CNN 派以及以 DETR、RT-DETR 为代表的 Transformer 派。YOLO11n 里引入的 C2PSA 模块就是 CNN 与注意力机制的融合产物可以看作是轻量模型对 Transformer 优势的吸收。Transformer 检测器的核心特点是端到端不需要 NMS 后处理通过匈牙利匹配算法直接输出检测结果。这种方式简化了流程但训练收敛慢、计算量大边缘设备上跑不动。如果你的设备算力充足且对延迟不敏感RT-DETR-L 这类模型值得尝试。热词里那个“QwenVL 目标检测用绝对位置还是相对位置”的问题本质上是在问视觉语言模型里的位置编码设计。这类模型比如视觉语言多模态模型会把图片编码成视觉 token再通过文本 prompt 引导输出检测结果位置编码方式直接决定模型对空间位置的理解能力。不同模型差别很大有的用绝对位置编码有的用旋转位置编码不能一概而论需要具体看某个版本模型的源码实现。多模态目标检测是未来趋势但现在还不适合直接替换 YOLO11n 这种成熟方案做工业落地。6.3 点云 3D 目标检测与多模态融合如果你继续深入目标检测三维目标检测是绕不开的方向。点云 3D 目标检测通过激光雷达获取三维空间点云然后用 PointPillars、CenterPoint 这类算法识别物体的三维位置和朝向。这和 YOLO11n 的二维检测完全不同它的核心难点在于如何高效处理和编码稀疏、无序的点云数据如果只做视觉和点云融合还需要考虑不同传感器之间的坐标系对齐和时间同步。我目前只做过一点调研还没有在点云方向上跑通完整项目。但我建议读完这篇笔记的朋友不要急着跳到三维或多模态先把二维目标检测的工程能力打扎实数据清洗、模型训练、部署调优、问题排查这四个环节都经历一遍比盲目追新方向更有价值。6.4 学习路线目标检测项目成长的四个阶段根据自己做项目的体会我建议把学习路线分成四个阶段。第一阶段是“会用框架”能按文档跑通预训练模型完成推理第二阶段是“能改数据”会清洗数据、标注、划分和做增强第三阶段是“能调模型”理解学习率、batch、imgsz、NMS 阈值等关键参数对结果的影响第四阶段是“能部署优化”能针对设备约束做模型导出、量化和推理加速。这篇笔记覆盖了前三个阶段的大部分内容最后一个阶段需要你自己在真实设备上磨炼。每个阶段都有对应的标志性成果第一阶段是推理出一张图第二阶段是训练一个自己的模型并且 mAP 达到可接受水平第三阶段是针对自己的场景把 mAP 提升若干个百分点第四阶段是把模型跑在设备上并且保证稳定运行。到第四阶段你就真正具备了独立负责目标检测项目的能力。我个人在实际操作中最深的体会是目标检测项目本质上是一个“数据工程”的项目模型反而是最不令人担心的部分。YOLO11n 这类成熟模型已经把算法层面的容错率做得足够好真正决定项目成败的往往是数据质量、部署细节和问题排查能力。我见过太多人花大量时间追求新模型、新算法却连数据集划分的一致性都没做好最后得到的指标都是虚的。最后分享一个实用小技巧做任何目标检测实验前先固定随机种子torch.manual_seed(0)加上np.random.seed(0)Ultralytics 也支持seed参数。这样即使改了某个参数导致效果变化你才能确定这个变化是参数引起的而不是随机性造成的。这个习惯在初期可能感觉不到价值等到你为了一个 0.5 个点的 mAP 提升反复做消融实验时就会明白固定随机种子有多重要。