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 组件除外）。它的血统也说得清——README 致谢声明建立在 LW-DETR、DINOv2 与 Deformable DETR 之上：DINOv2 出骨干，LW-DETR 一系的检测头出框。这也是基准表里 LW-DETR 被列为主要对手的原因：同门竞速。

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

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（实例分割，全族 Apache 2.0）
        └── 关键点头   → 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 档（XL 126.4M，2XL 126.9M），分辨率也提上去（700² / 880²），COCO AP50:95 分别为 58.6 和 60.1，延迟 11.5ms 和 17.2ms。它们走 rfdetr_plus 扩展包（pip install rfdetr[plus]），许可证是 PML 1.0 而非 Apache 2.0。注意分界线画在检测族内：分割族的 Seg-XL / Seg-2XL 仍是 Apache 2.0。选型时要先看清这条线。
3. 三任务一个 API。 检测、分割、关键点（预览版）共用同一套骨干与调用方式，微调一次骨干的经验可以平移。

此外，已发布的尺寸来自神经架构搜索（Neural Architecture Search，NAS），同一套 NAS 方法已在 Roboflow 平台开放，可以对自己的数据集搜架构——README 称平台版单次训练即可产出全部尺寸，成绩超过论文 NAS 与开源 checkpoint。开源仓库本身不包含 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，其余不动。关键点头目前只有一个预览类 RFDETRKeypointPreview，在 COCO 行人关键点（person keypoints）上预训练，分辨率 576²、参数 40.7M。也可以走 Roboflow Inference 库（get_model("rfdetr-medium")）获得统一的推理封装，模型别名（rfdetr-nano 到 rfdetr-2xlarge）与包内类名（RFDETRNano 到 RFDETR2XLarge）一一对应。

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

README 的基准表是本文最有信息量也最需要谨慎引用的部分。口径先说清：精度是 COCO AP50:95（IoU 阈值 0.5 到 0.95 步进平均的严格口径），延迟是 NVIDIA T4 + TensorRT + FP16 + batch=1 的组合，单位毫秒。挑关键行（完整表覆盖全部六个尺寸与 YOLO11/YOLO26/LW-DETR/D-FINE 全系）：

能推出的结论：

• 同延迟档，RF-DETR 精度显著占优。 RF-DETR-L 以 6.8ms 做到 YOLO26-X 要 9.6ms 才能拿到的同一档精度（56.5 vs 56.9，差 0.4 AP），延迟省约 30%。中档更明显：RF-DETR-M 只用 4.4ms 就拿到 54.7，同延迟的 YOLO26-M 是 52.5。
• 参数效率是反的，但工程上未必要命。 RF-DETR-N 参数是 YOLO11-N 的近 12 倍，但延迟反而更低（2.3 vs 2.5ms）——ViT 的结构规整对 TensorRT 这类编译器更友好，参数量不直接等于慢。
• RF100-VL 上差距更大。 在这个多域真实数据检测基准（Roboflow100-VL，覆盖大量非 COCO 分布的数据集）上，RF-DETR-N 的 AP50 达 85.0，YOLO11-N 只有 81.4，YOLO26-N 更低到 76.7。严格口径下 RF-DETR-M 的 RF100-VL AP50:95 为 61.2，已超过延迟两倍的 YOLO26-X（60.0）。README 的定位语 “designed for fine-tuning” 在这里兑现：自监督骨干迁移到非 COCO 分布数据时衰减更小。

不能推出的结论：

• 延迟数字是 T4 + TensorRT + FP16 + batch=1 的特定组合，换 A100、换 ONNX Runtime、换 batch、换 INT8 量化，相对位次可能移动。参数量是部署态融合后的 nn.Module 计数，不是 checkpoint 裸张量数。
• 精度是官方自测：Roboflow 用自家 SAB 流水线（single_artifact_benchmarking，方法与复现细节开源在 github.com/roboflow/single_artifact_benchmarking）以 pycocotools 在 COCO val2017 全量 5000 张上统一测得，行行同源可比，但与各家论文自报数字不同口径。表中标注 † 的 SAM 3 一行（RF100-VL AP50:95 61.6，约 850M 参数）是唯一例外，转引自原作者论文（arXiv:2511.16719，Table 36）——它只说明 SAM 3 这种量级的通用大模型在 RF100-VL 上也没有碾压 RF-DETR-XL（62.9），不构成同预算对比。
• COCO 位次不等于 RF100-VL 位次。 XL 档就是现成的例子：COCO AP50:95 上 D-FINE-X 以 62.0M 参数、11.5ms 拿到 59.3，反超 RF-DETR-XL 的 58.6；换到 RF100-VL AP50:95，RF-DETR-XL 以 62.9 反超 D-FINE-X 的 62.2。分布一换，位次就动——这正是"选型要拿自己的数据实测"的依据，而不是任一边基准表的依据。
• 关键点一行是 preview，OKS-based（基于目标关键点相似度）AP50:95 71.8 对 YOLO26-pose-X 的 71.0，延迟几乎持平（9.7 vs 9.8ms），参数还少 17M，但领先幅度仍在噪声边缘，且成熟度未经验证。

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

适用边界与采用建议

按顺序给建议：

1. 工业检测/分割微调场景，首选试 RF-DETR-S 或 M。 S 档 3.5ms / 53.0 AP，M 档 4.4ms / 54.7 AP，都在 Apache 2.0 区间内；预训练分布与自定义数据集的差异越小，骨干优势越能兑现。官方提供了微调 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 主线不同，商用前读条款；同延迟档还有 Apache 2.0 的 D-FINE-X 可比（COCO 上还略高）。
4. 关键点检测，目前只是 preview，生产选型建议等正式版或继续用 YOLO-pose。
5. 想要 NAS 搜自己的架构，开源仓库不含训练侧 NAS，需要 Roboflow 平台。

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

仓库信息

• 仓库：https://github.com/roboflow/rf-detr （9.6k stars，2026-09-28 快照 9,617；Apache 2.0 主线，Python；默认分支 develop，源码安装走 develop 分支）
• 文档与 demo：https://rfdetr.roboflow.com
• 基准方法论：https://github.com/roboflow/single_artifact_benchmarking
• 基准数据集：https://github.com/roboflow/rf100-vl
• 论文：arXiv:2511.09554（ICLR 2026）