RF-DETR：在 DINOv2 骨干上重写实时检测的精度-延迟曲线

面向做视觉检测落地选型的工程师：在预算固定的延迟窗口里挑一个精度上限最高、又能在自己数据集上微调（fine-tuning）的检测模型。前置知识：卷积与 Transformer 检测器的基本分野、mAP 指标含义、常见部署量化流程。

读完本文你能回答：RF-DETR 的核心赌注是什么；它为什么把宝押在 DINOv2 骨干上；N 到 2XL 六个尺寸各自处在精度-延迟曲线的哪个位置；README 那些基准数字能推出什么、不能推出什么；以及你的场景该从哪个尺寸开始试。

一句话判断

RF-DETR 的核心赌注只有一条：检测精度上限由骨干（backbone）决定，而 DINOv2 这个自监督预训练的视觉 Transformer 骨干，在同延迟预算下比 YOLO 系列从头训或弱监督训出来的骨干强得多——代价是参数量整体偏大（最小档也有 30.5M 参数，而 YOLO11-N 只有 2.6M）。这不是"又一个 DETR 变体"的论文贡献，而是一次面向落地微调的工程重构：模型族谱整齐、单一 API、检测/分割/关键点三任务共用一套骨干，Apache 2.0 开源（Plus 组件除外）。

系统地图：一个骨干，三个头，六个尺寸

RF-DETR 的结构可以用一张三层地图说清：

DINOv2 ViT 骨干（自监督预训练，分辨率随尺寸缩放）
        │
        ├── 检测头     → RF-DETR-N / S / M / L（Apache 2.0）
        │                RF-DETR-XL / 2XL（rfdetr_plus，PML 1.0）
        ├── 分割头     → RF-DETR-Seg-N … Seg-2XL（实例分割）
        └── 关键点头   → RF-DETR Keypoint（preview，Apache 2.0）

三个要点：

1. 骨干不变，分辨率缩放。 检测族从 N（384×384）到 L（704×704），参数量几乎不动（30.5M → 33.9M），精度靠分辨率和训练配置拉开（COCO AP50 从 67.6 涨到 75.1）。这与 YOLO 系"小模型堆通道"的尺寸策略是两种哲学——RF-DETR 认为骨干的表征质量是地板，分辨率是旋钮。
2. XL/2XL 是另一条产品线。 参数量跳到 126M+，走 rfdetr_plus 扩展包（pip install rfdetr[plus]），许可证是 PML 1.0 而非 Apache 2.0。选型时要先看清这条线。
3. 三任务一个 API。 检测、分割、关键点（预览版）共用同一套骨干与调用方式，微调一次骨干的经验可以平移。

此外，已发布的尺寸来自神经架构搜索（Neural Architecture Search，NAS），同一套 NAS 方法已在 Roboflow 平台开放，可以对自己的数据集搜架构——这是仓库与商业平台之间明确挂钩的部分，开源仓库本身不包含 NAS 训练代码。

任务流：一张图怎么流过模型

以检测为例，官方最小可运行示例：

import supervision as sv
from rfdetr import RFDETRMedium
from rfdetr.assets.coco_classes import COCO_CLASSES

model = RFDETRMedium()
detections = model.predict("https://media.roboflow.com/dog.jpg", threshold=0.5)

labels = [f"{COCO_CLASSES[class_id]}" for class_id in detections.class_id]
annotated_image = sv.BoxAnnotator().annotate(detections.metadata["source_image"], detections)
annotated_image = sv.LabelAnnotator().annotate(annotated_image, detections, labels)

数据流是：图像 URL 或本地路径 → 模型内部完成预处理（含按尺寸缩放）→ DINOv2 骨干提特征 → 检测头出框 → model.predict 返回 supervision 格式的 Detections 对象（含 class_id、置信度、源图元数据）。标注可视化交给 supervision 库——这也是 Roboflow 自家的 CV 工具库，两仓库配合是设计意图而非巧合。

一个微调用户会立刻撞到的细节：COCO_CLASSES 只对 COCO 预训练模型有效；微调后的模型应改用 detections.data["class_name"]，类名直接从 checkpoint 解析，COCO 与自定义数据集通用。

分割与关键点的调用同构：把类名换成 RFDETRSegMedium，把 BoxAnnotator 换成 MaskAnnotator，其余不动。也可以走 Roboflow Inference 库（get_model("rfdetr-medium")）获得统一的推理封装，模型别名与包内类名一一对应。

基准解读：数字能推出什么，不能推出什么

README 的基准表是本文最有信息量也最需要谨慎引用的部分。先看三行关键数据（COCO 检测，AP50:95）：

能推出的结论：

• 同延迟档，RF-DETR 精度显著占优。 RF-DETR-L 以 6.8ms 达到 YOLO26-X 需要 9.6ms 才能摸到的精度（56.5 vs 56.9），延迟省约 30%。
• 参数效率是反的，但工程上未必要命。 RF-DETR-N 参数是 YOLO11-N 的近 12 倍，但延迟反而更低（2.3 vs 2.5ms）——ViT 的结构规整对 TensorRT 这类编译器更友好，参数量不直接等于慢。
• RF100-VL 上差距更大。 在这个更贴近工业数据的基准上，RF-DETR-N 的 AP50 达 85.0，YOLO11-N 只有 81.4。README 的定位语"designed for fine-tuning"在这里兑现：自监督骨干迁移到非 COCO 分布数据时衰减更小。

不能推出的结论：

• 延迟数字是 T4 + TensorRT + FP16 + batch=1 的特定组合，换 A100、换 ONNX Runtime、换 batch、换 INT8 量化，相对位次可能移动。参数量是部署态融合后的 nn.Module 计数，不是 checkpoint 裸张量数。
• 精度是官方自测（pycocotools 在 COCO val2017 全量 5000 张上），与各家论文自报数字不同源；表中标注 † 的 SAM 3 一行（RF100-VL 61.6，约 850M 参数）转引自原作者论文，只说明 SAM 3 这种量级的通用大模型在 RF100-VL 上也没有碾压 RF-DETR-XL（62.9），不构成同预算对比。
• 关键点一行是 preview，OKS-based AP 71.8 对 YOLO26-pose-X 的 71.0，领先幅度在噪声边缘，且成熟度未经验证。

许可证差异本身也是一个选型事实：YOLO 系 AGPL-3.0，RF-DETR Apache 2.0（XL/2XL 除外）。对无法接受 AGPL 传染的商业落地，这一条有时比 mAP 更决定性。

适用边界与采用建议

按顺序给建议：

1. 工业检测/分割微调场景，首选试 RF-DETR-S 或 M。 预训练分布与自定义数据集的差异越小，骨干优势越能兑现；官方提供了微调 Colab notebook（见仓库 README 徽章链接），pip install rfdetr 即装（Python ≥ 3.10）。
2. 延迟预算 5ms 以内且精度要求不高，YOLO26-N 这类小模型仍是合理选择——2.6M 参数的极限压缩在边缘设备内存受限时是硬优势，RF-DETR 最小档也要 30M。
3. 需要 2XL 级精度，先算清账：rfdetr_plus 的 PML 1.0 许可证与 Apache 2.0 主线不同，商用前读条款。
4. 关键点检测，目前只是 preview，生产选型建议等正式版或继续用 YOLO-pose。
5. 想要 NAS 搜自己的架构，开源仓库不含训练侧 NAS，需要 Roboflow 平台。

本文不覆盖：训练超参细节、部署量化实测、与 D-FINE / LW-DETR 的逐项消融——仓库论文（arXiv:2511.09554，ICLR 2026）是这些问题的第一手来源。

仓库信息

• 仓库：https://github.com/roboflow/rf-detr （9.3k stars，Apache 2.0 主线，Python）
• 文档与 demo：https://rfdetr.roboflow.com
• 论文：arXiv:2511.09554（ICLR 2026）