目标检测框架选型实战：YOLOv8、MMDetection与Detectron2对比

1. 三个框架的真实定位——选型之前先看清家底

说句实话，我每次看到有人问"目标检测框架到底该选哪个"都挺感慨的。三年前我也在MMDetection和Detectron2之间反复横跳，装环境装到怀疑人生，后来YOLOv8横空出世，整个社区的生态格局一下子就清晰了。我把三个框架从零到一都跑过不少项目之后，最大的感受是：没有哪个框架绝对好，只有哪个框架在你这类任务里更顺手。

很多人在选型时只看Star数和论文标题，这其实是个误区。框架是一个工具链，它决定了你从"拿到一批图片"到"模型上线"这条路上，每一步是踩油门还是踩泥坑。我希望通过这篇文章，把三个框架从环境配置、数据准备、训练调参到部署推理的完整链路都摆出来，用实战记录告诉你它们各自的脾气和底牌。

我见过的实际项目里，90%以上的工业落地最终都用YOLOv8收尾，但研究实验和论文复现场景，MMDetection和Detectron2依然是绕不开的存在。关键要看你的核心诉求，是想快速出结果跑通流程，还是要深度定制模型结构做实验对比，甚至要复现SOTA论文的细节。

1.1 YOLOv8：工程落地效率派的第一顺位

YOLOv8是Ultralytics在2023年初推出的系列模型，如果说YOLOv5是"社区驱动的实用主义"代表，那YOLOv8则是把工程化体验又拉高了一个台阶。这个框架最大的特点就是开箱即用，API设计非常贴近人类直觉，你不需要读完五十页文档才能跑起第一个训练任务，一条命令行就能完成训练、验证、导出、预测的全流程。

它的核心卖点是三件事：统一完备的模型家族（n/s/m/l/x五个规格覆盖不同算力）、融合了anchor-free设计和新版C2f结构的解耦检测头、以及极度友好的Python接口和CLI工具链。实测下来，我甚至见过一个小白同学在半天之内就从零训练出了自己的检测模型——这在MMDetection时代几乎是不可想象的。

但是这里也要说句公道话，YOLOv8的灵活性不如后面两个框架。如果你想改检测头、换一种陌生的backbone、做某些冷门的trick，它的封装反而会成为阻碍。Ultralytics的代码抽象层越深，你要动的地方就越需要绕过它的设计逻辑，这在后面讲到"改进"时你们会深有体会。

1.2 Detectron2：研究性实验的干净工作台

Detectron2是Meta（原Facebook AI Research）在2019年发布的检测平台，它的定位从诞生那天起就不是"记录里最方便"，而是"代码最漂亮、结构最清晰、扩展性最强"。整个框架基于PyTorch，采用了一种"配置文件过脑子"的设计哲学——你看到的是注册器（Registry）机制和完美的模块化组装逻辑。

如果你做的是需要频繁改动模型结构的科研实验，比如给Faster R-CNN加一个新的RoI head模块，或者对比Mask R-CNN换backbone的效果，Detectron2会让你觉得很舒服。每一块功能都像一个积木，你的自定义零件能很容易地插进原有系统，几乎没有"框架在跟你对着干"的感觉。

我必须要强调的是，Detectron2对新手并不友好，这份不友好体现在安装步骤多、配置结构复杂、文档基本上是"给已经懂行的人看的"。但反过来，一旦你理解了它的module和config系统，你会获得一种前所未有的掌控感——你知道模型每一步在做什么，也知道想改哪一行代码能达到什么效果。

1.3 MMDetection：模型全家桶中的百科全书

MMDetection是OpenMMLab体系里最重要的成员，如果你在GitHub上搜索目标检测经典文章的官方实现，经常会跳转到这里来。它的特点可以浓缩成两个词：量大管饱、配置驱动。目前MMDetection已经收录了300多个基础模型和模块，从双阶段Faster R-CNN到单阶段FCOS、YOLOF、EfficientDet，再到Transformer系、Query-Based的DETR、Mask2Former，基本你能叫上名字的主流检测体系都有干净实现。

MMDetection的优势在于实验对比方便。你在做研究或者技术选型评估时，想横向对比十几二十个模型在同一数据集上的效果，MMDetection的环境配置一致性会让你省很多心。它统一了训练器、数据加载器、优化器、评估器这些底层组件，你只需要通过改动配置文件就能在模型之间切换。

但MMDetection的缺点也很扎心：学习曲线异常陡峭。配置文件的层级继承和变量组合能让一个熟悉PyTorch的人看三天都云里雾里。它的版本更迭又特别频繁，网上搜到的教程可能已经基于过期版本，照着敲一定会踩坑。这就是为什么我在后面会专门用一节的篇幅，单独讲清楚它的数据准备和配置结构。

1.4 选型速查：根据自己的项目类型直接对号入座

这里我整理了一份选型判断表，基本涵盖了我见过的绝大多数项目场景，你可以直接对照自己的需求往下走。

记住一个原则：不要因为哪个框架名气大就去学哪个，而是应该让你的项目需求决定框架选型。你花一个星期在那折腾MMDetection配置文件，如果用YOLOv8已经能把baseline跑出来开始迭代，那这星期的时间就是纯浪费。反过来，你想复现一篇CVPR论文却非要在YOLOv8改到怀疑人生，那其实也是绕着远路走。

2. 环境配置与安装——90%的人卡在这一关

说安装环境是选框架的"第一道生死关"一点也不夸张。我在各种技术群里见过太多人，模型原理学得头头是道，结果卡在某个依赖包版本不匹配的问题上一整天搞不定，心态直接崩了。这三个框架的环境配置各有各的坑，我一个个讲清楚，你照着做就能避开80%的问题。

2.1 YOLOv8环境配置实操（GTX 1660 Ti实测）

先说YOLOv8，它也是这三个里环境配置最省心的一个。官方对版本的要求非常宽泛，我用GTX 1660 Ti搭配了三种环境都跑通过：Python 3.9 + PyTorch 1.13.1 + CUDA 11.7，以及Python 3.10 + PyTorch 2.1.0 + CUDA 12.1，都可正常运行。具体配置命令如下。

# 创建并激活虚拟环境 conda create -n yolov8 python=3.9 -y conda activate yolov8 # 安装PyTorch（这里以CUDA 11.7为例，不同版本到官网复制对应命令即可） pip install torch==1.13.1+cu117 torchvision==0.14.1+cu117 --extra-index-url https://download.pytorch.org/whl/cu117 # 安装ultralytics包（YOLOv8官方库） pip install ultralytics

装完之后可以用一条命令验证环境是否可用，顺手拉一个预训练权重测试推理：

yolo predict model=yolov8n.pt source=https://ultralytics.com/images/bus.jpg

如果终端打印出了检测框和保存路径，整个环境就通了。这里有个提醒，保险起见再装一个nvidia-ml-py3包，方便后面查看显存占用：

pip install nvidia-ml-py3

实测GTX 1660 Ti 6GB显存跑YOLOv8各个规格模型的感受是：yolov8n和yolov8s属于完全无压力档位，batch size开32训练yolov8n毫无问题；yolov8m就需要把batch降到16甚至8，同时开启混合精度训练；yolov8l和yolov8x就非常勉强了，基本不适合6GB显存的卡。

2.2 Detectron2安装报错排查实录

Detectron2的安装问题在技术社区里几乎是"月经帖"，天天都有人问。其实归纳起来就三个大类：版本不匹配、编译工具链缺失、源码编译超时或失败。这里我给出Windows和Linux两套环境下的亲测可用方案。

先讲最稳妥的源码编译流程：

conda create -n d2 python=3.9 -y conda activate d2 # 安装PyTorch，推荐源码编译时用官方稳定版 pip install torch==1.13.1+cu117 torchvision==0.14.1+cu117 --extra-index-url https://download.pytorch.org/whl/cu117 # 从GitHub拉取源码 git clone https://github.com/facebookresearch/detectron2.git cd detectron2 # 源码安装 pip install -e .

这个流程在Linux上成功率高一些，前提是你的gcc版本不能太老。有一个细节大家可能不知道，编译Detectron2时gcc版本在5.x以上基本没问题，但如果你想编译带CUDA自定义算子，需要gcc与CUDA版本兼容，比如CUDA 11.7就要求gcc不超过11.x，否则会报unsupported GNU version的错误。

Windows用户会遇到的典型报错是ERROR: Failed building wheel for detectron2或者类似cl.exe编译失败的提示。这种情况的根本原因通常是缺少Microsoft C++ Build Tools，或者PyTorch版本和MSVC版本不匹配。最稳妥的做法是先装好Visual Studio 2019及C++桌面开发组件，再确保用x64 Native Tools Command Prompt进入命令行执行安装指令。

还有一类高频报错是undefined symbol或libtorch_python.so: undefined symbol，这种十有八九是PyTorch版本不匹配，比如编Detectron2时用的PyTorch和你运行时的PyTorch版本不一致。解决办法很粗暴：重新用同一个环境里的PyTorch版本编译一遍。

2.3 MMDetection安装要点与mmcv版本搭配

MMDetection的安装复杂度比Detectron2还要高一点，因为它的底层托着MMEngine和MMCV两套基础设施，版本之间强耦合。我在3.x版本时代踩过很多坑，核心结论就是：MMDetection、MMEngine、MMCV三者的版本号必须严格匹配，不能随便装最新的。

推荐安装流程如下：

conda create -n mmdet python=3.9 -y conda activate mmdet pip install torch==1.13.1+cu117 torchvision==0.14.1+cu117 --extra-index-url https://download.pytorch.org/whl/cu117 # 安装openmim工具，它可以帮助我们自动匹配版本 pip install -U openmim mim install mmengine mim install "mmcv>=2.0.0" mim install mmdet

最近MMDetection已经发布了3.3.0版本，API相比2.x变化非常大，配置文件的后缀从.py变得更Python化，整体模块化程度更高。但社区里大量老教程、博客文章用的还是2.x版本，所以你照着网上搜到的内容操作经常报错。建议直接跳进3.x，即使遇到问题，去官方文档查最新示例也更容易。

MMDetection安装时最常出问题的就是mmcv，因为mmcv的编译依赖于CUDA版本和PyTorch版本，如果直接用pip install mmcv装到的是CPU版本，训练时会报Not compiled with CUDA之类的错误。用mim安装会自动帮你匹配对应的CUDA版本，这是我试过最省心的方案。

2.4 硬件配置和显存优化建议

很多人的GPU是8GB、6GB这种入门级显存，却硬要去跑大模型大分辨率，最后抱怨框架跑不动。其实每个框架都提供了显存优化手段，关键看你有没有用对。我把三框架在6GB显存下的可行训练方案整理成了表格。

这里特别说一个我在GTX 1660 Ti上反复验证的经验：混合精度训练（AMP）在它的收益非常可观，显存占用能降低30%左右，训练速度提升20%以上。虽然1660Ti没有Tensor Core，AMP加速比不像高端卡那么夸张，但显存节省对6GB卡来说就是"能不能训练"的本质区别。三框架里YOLOv8默认开启AMP，Detectron2和MMDetection需要手动在配置中开启。

3. 用自己的数据训练一个检测模型——完整闭环

环境装好了，模型选型也定了，接下来是正戏：拿自己的数据集训练模型。这一节我用一个统一的小案例——检测传送带上的芯片瑕疵——来分别跑通三个框架的完整流程。你可以把数据替换成自己的任何场景，流程完全一致。

3.1 YOLOv8：从图片文件夹到pt文件的三步捷径

YOLOv8是这三个里数据准备最直观的，它要求的数据标注格式是YOLO txt格式，也就是每张图片对应一个同名txt文件，里面每一行是类别id 中心点x 中心点y 宽度 高度这样的五列数字。这里的的坐标全都是相对于图片宽高的归一化值，取值范围0到1。

假设你有images/和labels/两个文件夹，需要按train/val划分，整体目录结构长这样：

dataset/ ├── images/ │ ├── train/ │ │ ├── chip_001.jpg │ │ └── ... │ └── val/ │ ├── chip_052.jpg │ └── ... └── labels/ ├── train/ │ ├── chip_001.txt │ └── ... └── val/ ├── chip_052.txt └── ...

然后在数据集根目录写一个数据配置文件，告诉YOLOv8你的路径和类别信息：

# chip.yaml path: /home/user/dataset train: images/train val: images/val nc: 2 names: ['scratch', 'foreign_matter']

训练只需要一条命令。以yolov8s为例：

yolo train model=yolov8s.pt data=chip.yaml epochs=100 imgsz=640 batch=16 device=0

这里要补充一下batch参数的选择逻辑。6GB显存上设置为16较为稳妥，但如果你发现显存不够，优先降低batch而不是imgsz，因为分辨率降低会影响小目标检测效果。训练一次之后，项目目录下会出现runs/detect/train/文件夹，里面有weights/best.pt和weights/last.pt，以及损失曲线和指标曲线图。

我用1660Ti实测训了100个epoch，yolov8s在自制的500张芯片瑕疵数据集上大概用了40分钟，验证集mAP50达到了0.87左右，这个效率是非常令人满意的。

3.2 MMDetection数据准备：COCO格式其实没那么可怕

MMDetection的数据格式更重，默认要求COCO格式。它需要你把所有标注信息写进一个大的JSON文件，里面最重要有三个字段：images是所有图片的尺寸和文件名列表，annotations是每一个标注框的坐标和类别信息，categories是类别名称和ID的映射。

我还是用芯片瑕疵数据集举例，COCO JSON的最小结构长这样：

{ "images": [ {"id": 1, "file_name": "chip_001.jpg", "width": 640, "height": 640} ], "annotations": [ {"id": 1, "image_id": 1, "category_id": 1, "bbox": [100, 120, 80, 50], "area": 4000} ], "categories": [ {"id": 1, "name": "scratch"}, {"id": 2, "name": "foreign_matter"} ] }

这里特别提醒坑位：COCO的bbox格式是[左上角x, 左上角y, 框宽, 框高]，它不是中心点坐标，很多从Labelme转过来的人在这里翻车。而且area字段在旧版本中可以省略，但如果在训练时用到一些特殊评估逻辑，最好还是填上，直接写width * height即可。

如果你用的是Labelme或者Roboflow标注，建议用现成的脚本转换而不是手写转换器。Roboflow导出COCO格式一条龙非常方便，Labelme的工具labelme2coco.py也好用。数据准备完成之后，你需要在MMDetection里改一下数据集配置文件。以Faster R-CNN为例，新的3.x版本一般这么配置：

# faster_rcnn_r50_fpn_1x_chip.py _base_ = './faster_rcnn_r50_fpn_1x_coco.py' data_root = 'data/chip/' train_dataloader = dict( dataset=dict( data_root=data_root, ann_file='annotations/instances_train.json', data_prefix=dict(img='images/train/'), metainfo=dict(classes=('scratch', 'foreign_matter')) ) ) val_dataloader = dict( dataset=dict( data_root=data_root, ann_file='annotations/instances_val.json', data_prefix=dict(img='images/val/'), metainfo=dict(classes=('scratch', 'foreign_matter')) ) )

训练命令同样简洁：

python tools/train.py configs/chip/faster_rcnn_r50_fpn_1x_chip.py

这里我想多讲一句，MMDetection最让人迷糊的地方是_base_继承机制。它允许你的配置文件继承另一个配置文件的所有字段，然后只覆盖你想改的部分。好处是省代码，坏处是你不知道哪些配置被"默默"继承了。排查问题时建议用官方提供的工具把整个配置打印出来看看：

python tools/misc/print_config.py configs/chip/faster_rcnn_r50_fpn_1x_chip.py

3.3 Detectron2的数据注册与训练配置

Detectron2的数据接口设计得相对清晰，它对COCO格式的支持非常完善，但不支持直接在配置文件里指定路径，而是要先在Python代码里"注册"数据集。一个典型的训练脚本长这样：

from detectron2.data.datasets import register_coco_instances from detectron2.engine import DefaultTrainer from detectron2.config import get_cfg import os register_coco_instances("chip_train", {}, "data/chip/annotations/instances_train.json", "data/chip/images/train") register_coco_instances("chip_val", {}, "data/chip/annotations/instances_val.json", "data/chip/images/val") cfg = get_cfg() cfg.merge_from_file("configs/COCO-Detection/faster_rcnn_R_50_FPN_3x.yaml") cfg.DATASETS.TRAIN = ("chip_train",) cfg.DATASETS.TEST = ("chip_val",) cfg.DATASETS.NUM_CLASSES = 2 cfg.SOLVER.IMS_PER_BATCH = 4 cfg.SOLVER.BASE_LR = 0.0025 cfg.SOLVER.MAX_ITER = 5000 cfg.OUTPUT_DIR = "output/chip_faster_rcnn" os.makedirs(cfg.OUTPUT_DIR, exist_ok=True) trainer = DefaultTrainer(cfg) trainer.resume_or_load(resume=False) trainer.train()

这个方式的逻辑是：注册器告诉Detectron2有这样一个数据集叫chip_train，然后配置文件里只要引用这个名字就行。代码本身就是完整的脚本，不需要额外写命令行入口。

如果你不想每次都写脚本，官方也提供了tools/train_net.py，配合--num-gpus等参数即可开训：

python tools/train_net.py --config-file configs/COCO-Detection/faster_rcnn_R_50_FPN_3x.yaml --num-gpus 1

Detectron2训练结束后，会在OUTPUT_DIR里生成model_final.pth，以及每个iter打印的指标摘要。我用同样的数据集跑过一次Faster R-CNN，50个epoch的mAP50能到0.84左右，效果不错但训练时间明显比YOLOv8要长，主要是双阶段模型的setp耗时更多。

3.4 损失函数曲线图的正确打开方式

很多同学训练完之后最关心模型到底学得怎么样了，这时候看损失函数曲线的走向比单纯看精度指标更能反映问题。YOLOv8在训练过程中会自动保存一张results.png，里面包含了box_loss、cls_loss、dfl_loss和precision/recall/mAP等曲线的变化趋势，这是最省事的方式。

但如果你想自己把曲线画得更精细，比如同时对比两个跑批的效果，YOLOv8也提供了results.csv文件，直接用pandas加matplotlib画就行：

import pandas as pd import matplotlib.pyplot as plt df = pd.read_csv("runs/detect/train/results.csv") df.columns = [c.strip() for c in df.columns] plt.figure(figsize=(10, 4)) plt.subplot(1, 2, 1) plt.plot(df["epoch"], df["train/box_loss"], label="box_loss") plt.plot(df["epoch"], df["train/cls_loss"], label="cls_loss") plt.plot(df["epoch"], df["train/dfl_loss"], label="dfl_loss") plt.xlabel("epoch") plt.ylabel("loss") plt.legend() plt.title("Training Loss") plt.subplot(1, 2, 2) plt.plot(df["epoch"], df["metrics/mAP50(B)"], label="mAP50") plt.plot(df["epoch"], df["metrics/mAP50-95(B)"], label="mAP50-95") plt.xlabel("epoch") plt.ylabel("mAP") plt.legend() plt.title("Validation mAP") plt.tight_layout() plt.savefig("custom_training_curve.png", dpi=150)

曲线怎么看？我分享一个实用经验：如果train loss最后还在持续下降但val mAP不再上升甚至开始跌，这就是典型的过拟合信号，建议提前停止增加epoch，或者降低学习率、增大数据增强。如果loss曲线剧烈震荡迟迟不收敛，大概率是学习率过大或batch size太小。如果cls_loss降得很慢而box_loss已经像模像样，可能是类别不平衡在作祟。

4. 模型结构对比与改进思路——选型之后还是得懂原理

三个框架装好了、模型也训起来了，但要想把效果做得比默认更好，你就得搞清楚模型内部到底发生了什么。这一节我主要围绕热度最高的YOLOv8网络结构展开，然后顺带讲讲三框架在模型改进和部署环节的差异。

4.1 YOLOv8网络结构拆解：C2f模块到底在做什么

YOLOv8的网络结构可以理解为四个部分：输入端的Mosaic数据增强与自适应锚框计算、Backbone特征提取网络、Neck特征融合网络（PAN-FPN）、以及Head检测头。其中最有辨识度的是Backbone和Neck部分反复出现的C2f模块，它是YOLOv5中C3模块的升级版。

C2f模块的核心思想借鉴了CSPNet（Cross Stage Partial Network），但不是简单地把特征切两半，而是将输入先过一个1x1卷积调整通道，然后拆成两个分支。主分支经过多个Bottleneck残差块串行计算，每一层的输出都会被拼接到最终结果中。这个设计让梯度在反向传播时能同时走"高速公路"和"支线小路"，浅层和深层的特征信息都被保留下来，在不大幅增加参数量的情况下提升梯度流动。官方在l/s/m等不同规格里，通过调整Bottleneck的堆叠次数class和通道数来平衡算力与精度。

我画过一张手工结构图，这里用文字描述一下：输入特征进入C2f模块后，先经过一个cv1卷积层（1x1），它的输出接着一分为二。一个分支直接作为恒等映射保留，另一个分支经过由n个Bottleneck模块组成的串联结构，每个Bottleneck由两个3x3卷积加残差边构成。最终所有分支的输出在通道维度上拼接起来，再经过一个cv2的1x1卷积恢复输出通道数。整个过程可以理解为"多路径特征提取 + 拼接融合 + 投影输出"，这也是为什么C2f比C3更擅长捕捉多尺度细节。

4.2 YOLOv8的改进方向与实操建议

网上关于"YOLOv8改进"的讨论热度一直很高，这其实也是它的生态魅力所在。基于网络结构，我总结几个经过验证的改进方向：

• 注意力机制增强：在Backbone的C2f之后并联或串联一个SE模块、CBAM模块或者CA模块，能明显提升小目标和遮挡目标的检出率。实现方式是在YOLOv8的ultralytics/nn/modules/conv.py后面定义一个新的注意力类，然后在yaml配置文件中把某个C2f替换成C3k2等派生模块。
• 小目标检测头：YOLOv8默认从P3（80x80）开始检测，如果我面对的是遥感和航拍这类小目标占比极高的场景，需要额外增加一个更高分辨率的P2输出层（160x160）。这个改动工程量不小，需要改模型结构定义和Neck的通道对齐逻辑，但效果确实立竿见影。
• 损失函数优化：YOLOv8默认使用CIoU作为box回归损失，如果你发现自己的数据里长宽比悬殊较大，可以尝试换成SIoU或WIoU，它们对几何信息的建模更细腻。改动点主要在loss.py的BboxLoss类里。
• 轻量化替代：把backbone改成MobileNetV3、ShuffleNetV2这些轻量网络，换上之后在边缘设备上的推理速度提升是一倍起步，代价是mAP会掉1-3个点，适合对实时性要求极高的场景。

这三个改进方向，只有YOLOv8能在一天内修改并验证完毕。Detectron2和MMDetection当然也能改，但因为设计目标的差异，改动步骤要多得多，需要同时调整配置文件、模块文件、注册器，对代码理解的深度要求更高。

4.3 推理部署与可移植性对比

模型训完总得落地部署，这一块三个框架的差距很悬殊。YOLOv8的部署生态最成熟，官方提供了完整的导出工具，一条命令就能导出ONNX、TensorRT Engine、CoreML、OpenVINO等格式：

yolo export model=best.pt format=onnx yolo export model=best.pt format=engine device=0

导出的ONNX模型可以用onnxruntime-gpu或TensorRT在业务服务里直接推理。MMDetection需要先将模型权重转成onnx，然后处理非极大值抑制（NMS）的自定义算子，麻烦不少。Detectron2本身以PyTorch的TorchScript部署为主，效果也不错，但生态支持没有YOLOv8那么直白。

对于GTX 1660Ti这种显卡，我一直建议用TensorRT加速YOLOv8，在FP16精度下yolov8s能从30 FPS左右提速到60 FPS以上，效果非常明显。

5. 实操中的高频坑位与排查经验

框架本身不会找麻烦，但数据集和参数会。这一节把我这几年跑模型遇到的典型问题集中整理一下，附上排查思路。这些问题不是"某个框架特有"，而是目标检测训练中跨框架的常见现象，但不同框架排查的手法差异很大。

5.1 训练不收敛、Loss爆炸、mAP始终为0

这几个问题是最劝退新手的存在，我一一拆解。

Loss出现NaN：原因通常有两种，一是学习率过大导致梯度爆炸，二是数据集中有空的标注文件或者非法归一化值。排查顺序：先把学习率降为默认值的1/10试试，如果还是NaN，就写个脚本去检查labels文件夹里是否有0字节文件、坐标值有没有超出0到1的范围。

mAP为0但loss正常降低：我在YOLOv8里遇到过这种情况，最后定位为类别ID和配置文件里的names对不上。比如你标注了5个类别但配置里只给了4个名字，或者类别ID从1开始而不是0，都会导致评估阶段找不到正确匹配。这种情况最好用代码一口气检查一遍：

import numpy as np labels = open("labels/train/chip_001.txt").readlines() for line in labels: cls_id = int(line.split()[0]) coords = list(map(float, line.split()[1:])) assert 0 <= cls_id < 5, "class id out of range" assert len(coords) == 4, "illegal bbox format" assert all(0 <= c <= 1 for c in coords), "coords not normalized"

验证集精度远低于训练集：这说明模型过拟合了，优先检查训练集和验证集是否存在图片泄露，很多人在划分数据集时把同一张芯片的不同裁剪版本分给了train和val，这会让模型的泛化指标虚高。

5.2 显存不足（OOM）与训练速度过慢

6GB显存跑大模型必然OOM。优先按这个顺序优化环境：开启AMP混合精度（最省心且几乎不降精度）→ 降低batch size → 降低输入分辨率 → 开启梯度累积（自动模拟大batch）。

在YOLOv8里，梯度累积的设置方式很简单：

yolo train model=yolov8s.pt data=chip.yaml batch=8 imgsz=640 optimizer=SGD amp=True

如果你想模拟batch size为16的效果，只需要在YOLO的配置里设置nbs为16并搭配batch为8，代码会自动做梯度累积。

训练速度慢的另一个大坑是数据加载瓶颈。不要小看磁盘I/O，当GPU计算的耗时远小于数据从磁盘到显存的耗时，你的GPU就一直在"摸鱼"。三个框架都提供了多进程数据加载参数：YOLOv8的workers、Detectron2的NUM_WORKERS、MMDetection的num_workers。在Windows上这个值不要超过CPU逻辑核心数的一半，Linux上可以开足。另外，把数据放到SSD上和开启pin_memory也会带来肉眼可见的速度提升。

5.3 什么时候该换框架？我真实的迁移经历

最后聊聊"选型"这个动态过程。说句掏心窝的话，我自己就经历过从MMDetection费劲跑通Faster R-CNN到换YOLOv8后半天出基线的迁移。那是一次工业质检项目，客户要求3天内出结果，MMDetection的配置系统确实强大但我当时对3.x版本不熟，光是解决mmcv编译问题就花了一整天。后来冷静下来，用YOLOv8重写整个流程，数据转换脚本加训练加评估一共用了6小时。

但另一个情况又反过来了。后来我要复现一篇关于Query-Based检测器的论文，对比DETR和Deformable DETR的效果，YOLOv8里哪有这些现成实现，我只好老老实实把MMDetection捡起来。它的模型库直接就有现成的DETR系列配置和预训练权重，跑对比实验极其省事。

所以我的建议很直接：如果你是在评估一个检测任务能不能做、数据质量如何、大概能到什么精度，请直接上YOLOv8。等确认任务可行、模型需要长期迭代和深度优化时，再根据具体需求切换到MMDetection或Detectron2也不迟。技术的世界里，换框架从来不丢人，浪费时间才丢人。

根据我个人经验，这三个框架没有谁完胜谁，它们就像螺丝刀、电钻和车床的区别：螺丝刀顺手但费劲，电钻省力但需要一定操作技巧，车床功能强大但只给会用的人创造价值。你先想清楚自己是在拧螺丝、打孔还是造零件，再伸手拿工具，比到处问"哪个工具最好"靠谱一百倍。最后再分享一个小技巧：无论选哪个框架，一定要把环境依赖用pip freeze > requirements.txt或者conda的export命令保存下来。我见过太多人模型跑得好好的，重装系统后配置全部推倒重来，这种痛苦，提前锁定环境版本就能完全避免。