# RF-DETR: Roboflow's Real-Time Detection and Segmentation Model, Reviewed for Adoption

> RF-DETR is a Python object detection, instance segmentation and keypoint model built on a DINOv2 backbone and distributed through pip. It is strong on COCO accuracy per millisecond, but the Apache 2.0 grant stops at the XL and 2XL weights.

**roboflow/rf-detr** — RF-DETR is a real-time object detection and segmentation model architecture developed by Roboflow, SOTA on COCO, designed for fine-tuning. [ICLR 2026] 

- Repository: https://github.com/roboflow/rf-detr
- Website: https://rfdetr.roboflow.com
- Stars: 9,617 · Forks: 1,214
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/roboflow-rf-detr

## What RF-DETR Solves, and Who It Is Actually For

The problem is the fine-tuning gap. A team has a few thousand labelled images of its own domain, not COCO, and needs a detector that trains on that data without a research team. RF-DETR is aimed at exactly that reader: a Python developer who wants to run `pip install rfdetr`, load a pretrained checkpoint, and fine-tune on a custom dataset.

The architecture is a DETR variant with a DINOv2 vision transformer backbone, which is what separates it from the CNN-based YOLO lineage. Roboflow publishes several sizes, from RF-DETR-N at 384x384 up to RF-DETR-2XL at 880x880, and the README reports COCO AP50:95 of 48.4 for the N model and 60.1 for the 2XL. Those numbers come from in-house measurement with pycocotools over the full 5,000-image val2017 split, and the README notes they may differ from vendor-reported figures. That disclosure matters: the comparison table puts RF-DETR-N at 48.4 AP50:95 against YOLO11-N at 37.4, but the YOLO rows carry an AGPL-3.0 licence and the RF-DETR rows do not all carry the same one.

The intended audience is narrower than the marketing suggests. Segmentation is documented as part of the same consistent API, but keypoint detection is explicitly marked as a preview. If your product depends on pose estimation today, you are on a preview path, not a supported one.

## How the DINOv2 Backbone and the Single API Fit Together

The mechanism visible in the repository is a package that wraps three tasks behind one model configuration. The dependency list in pyproject.toml names `transformers>=5.1.0,<6.0.0` for DINOv2 backbone loading, `torch>=2.2.0` and `torchvision>=0.17.0` for tensor ops and image transforms, plus `requests` and `tqdm` for downloading weights from remote URLs with a progress bar. Weights are not bundled; they are fetched at first use, which is why `requests` is a runtime dependency rather than a build-time one.

Configuration is handled through pydantic models, with `pydantic>=2.0,<3` pinned. That means the training and model configuration surface is typed and validated rather than a dictionary of loose keys, and the package ships a `py.typed` marker per the classifiers. For an integration, the practical consequence is that a misspelled config key fails at validation time instead of silently defaulting.

The single API claim is the design bet: detection, segmentation and keypoints share one interface, so switching task does not mean switching libraries. The trade-off is that the backbone is heavy. Parameter counts in the detection table run from 30.5M for RF-DETR-N to 33.9M for RF-DETR-L, then jump to 126.4M for XL and 126.9M for 2XL. Those are deployment fused `nn.Module` counts, not raw checkpoint tensors, according to the README. The small models are not small in the way YOLO11-N is, at 2.6M parameters. If you are targeting an edge device, that gap is the whole decision.

## Installing RF-DETR and Running a First Inference

The README gives one install path: a Python environment of 3.10 or newer with pip. The package name on PyPI is `rfdetr`.

```bash
pip install rfdetr
```

After that, the package is importable and the pretrained weights download on first use through the `requests` and `tqdm` dependencies. Expect that first call to be slower than later ones, since it is fetching a checkpoint rather than computing.

If you need features that have not yet been released, the README documents a source install from the develop branch and warns that those updates are still in development and may be less stable than the published release.

```bash
pip install https://github.com/roboflow/rf-detr/archive/refs/heads/develop.zip
```

That URL is the one in the README; the default branch of the repository is develop, and pyproject.toml carries version 1.11.0.dev0 while the most recent tagged release is 1.10.1 from 2026-09-07. The gap between the two is the usual cost of tracking source: you get unreleased fixes, and you also get whatever is mid-flight.

The repository layout gives a second signal about how to work with it. There is a `configs/` directory, a `src/` tree, and a `tests/` directory, alongside docs and an mkdocs configuration. The README does not walk through a fine-tuning command in the excerpt available here, so the concrete training invocation is something to read from the docs site rather than guess at.

## The Licence Split Is the Real Adoption Constraint

This is where RF-DETR differs from a plain Apache 2.0 release, and the README is direct about it. The open-source `rfdetr` package and the Apache-designated models are Apache 2.0. The Plus components, published as `rfdetr_plus`, including the RF-DETR-XL and RF-DETR-2XL detection models, are licensed under PML 1.0.

Read the benchmark table with that split in mind. The best accuracy rows, 58.6 AP50:95 for XL and 60.1 for 2XL, are the PML 1.0 rows. The Apache 2.0 rows top out at RF-DETR-L with 56.5 AP50:95. If your evaluation shortlists RF-DETR because of the 2XL number, you have shortlisted a model whose licence differs from the one you may have assumed. Whether PML 1.0 is acceptable for your deployment is a question for your own legal review; this article cannot answer it, and the README does not attempt to either.

The comparison against YOLO has the same shape in reverse. The YOLO11 rows in the same table are AGPL-3.0, which is a copyleft licence with its own obligations for networked use. So the choice is not permissive versus restrictive in one direction. It is Apache 2.0 plus a paid-licence tier on one side, and AGPL on the other. Teams that have already ruled out AGPL for their product should note that the RF-DETR-L row is the permissively licensed ceiling here.

## Where RF-DETR Is the Wrong Tool

The clearest limitation is keypoints. The README describes keypoint detection as a preview, and the package classifiers in pyproject.toml list Development Status as Beta. A preview feature inside a beta package is not a foundation for a shipped product, and the documentation excerpt does not describe a stability guarantee for it.

The second limitation is parameter budget. RF-DETR-N carries 30.5M parameters at 384x384, against 2.6M for YOLO11-N at 640x640. The README's latency figures were measured on an NVIDIA T4 with TensorRT, FP16 and batch size 1, and they show RF-DETR-N at 2.3 ms against YOLO11-N at 2.5 ms. Those two numbers are close, but they were produced by a benchmarking harness the README links to separately, and they are not a prediction for your device. A 30M-parameter transformer backbone has different memory behaviour from a 2.6M-parameter CNN, and if you are deploying to a microcontroller-class accelerator, the architecture itself, not the latency table, rules RF-DETR out.

The third case is a team with no labelled data and no intention of labelling any. RF-DETR is described as designed for fine-tuning. The pretrained COCO checkpoints are the starting point, not the product. Neural architecture search, which produced the published sizes, is offered on the Roboflow platform rather than in the package, so the path to a custom architecture runs through a hosted service. If you want an offline-only pipeline, that part of the story is not in the open-source package.

## RF-DETR Versus YOLO and RT-DETR: Different Backbones, Different Trade-offs

The honest alternative for most readers is a YOLO model, and the difference is architectural rather than incremental. YOLO detectors are CNN-based and anchor-driven; RF-DETR is a transformer detector with a DINOv2 backbone. The README's own table makes the consequence visible: RF-DETR-N reaches 48.4 COCO AP50:95 where YOLO11-N reaches 37.4, while carrying roughly twelve times the parameters. You are buying accuracy per image with model size, not with a free lunch.

Against RT-DETR, the distinction is the backbone. RT-DETR is the earlier real-time DETR line; RF-DETR's claim rests on swapping in a DINOv2 vision transformer and running neural architecture search over the resulting sizes. The README does not publish an RT-DETR row in the excerpt available here, so a direct head-to-head is not something this article can give you. Anyone weighing the two should run both on their own dataset rather than trust a cross-paper number.

The RF100-VL column is the more interesting comparison for applied teams, because it measures transfer to a hundred varied datasets rather than COCO. There RF-DETR-N scores 57.7 AP50:95 against YOLO11-N at 55.3, and RF-DETR-L scores 62.2 against YOLO11-L at 56.5. The margin is real but smaller than on COCO, which is a useful correction if you were reading the COCO gap as the whole story.

## Maintenance, Releases and What Upgrades Cost

The repository is not archived, and the last push was on 2026-09-10. The release cadence is visible in the tags: 1.10.1 on 2026-09-07 addressed CUDA compile fixes and memory reduction, 1.10.0 on 2026-09-04 covered faster training and inference, and 1.9.4 on 2026-08-24 fixed export and augmentation correctness. Three releases in roughly two weeks, two of which are correctness or compile fixes, tells you the project is moving quickly and that pinning a version is worth the effort.

That cadence is also the upgrade cost. A package that ships CUDA compile fixes and export correctness fixes in point releases is one where a floating version constraint can change numerics between runs. The pyproject.toml pins `transformers` to a major range and `pydantic` to a major range, but the package itself is published as `rfdetr` without a stated compatibility promise across minor versions. For a production pipeline, the safe pattern is an explicit pin plus a re-run of your evaluation set on upgrade, particularly if you rely on export paths, since those were the subject of the 1.9.4 fixes.

On licensing, the split described above is the operative fact. Apache 2.0 covers the open-source package and the Apache-designated models; PML 1.0 covers the Plus components and the XL and 2XL detection weights. Read the LICENSE file and the model cards for the specific checkpoint you download, because the licence follows the weights, not just the code.

## Conclusion

Adopt RF-DETR if you are fine-tuning a detector on your own labelled data and want a pip-installable package with an Apache 2.0 core and a single API across detection, segmentation and keypoints. Do not adopt it if you need the XL or 2XL accuracy tiers under a permissive licence, since those weights sit under PML 1.0, or if you need a mature keypoint pipeline, which the README still labels a preview. Before committing, verify three things on your own data: that the DINOv2 backbone downloads cleanly in your environment, that your target latency holds on your hardware rather than on the T4 numbers in the benchmark table, and that the segmentation and keypoint paths behave as documented for your label format.

## FAQ

### What does RF-DETR stand for?

RF-DETR combines the Roboflow prefix with DETR, the Detection Transformer architecture. The README describes it as a real-time transformer architecture for object detection, instance segmentation and keypoint detection built on a DINOv2 vision transformer backbone.

### Is RF-DETR allowed for commercial use?

It depends on which weights you use. The README states that the open-source rfdetr package and the Apache-designated models are released under Apache 2.0, while the Plus components including the RF-DETR-XL and RF-DETR-2XL detection models are licensed under PML 1.0. Check the licence attached to the specific checkpoint you deploy.

### How do I install RF-DETR?

The README gives a single command in a Python 3.10 or newer environment: pip install rfdetr. A source install from the develop branch is also documented, with the warning that those updates are still in development and may be less stable than the published release.

### What is the RF-DETR segmentation model?

Segmentation is one of the three tasks RF-DETR supports through a single consistent API, alongside object detection and keypoint detection. The README presents detection and segmentation benchmarks on Microsoft COCO, with RF100-VL used for detection only.

### Is RF-DETR better than YOLO?

On the README's own table, RF-DETR-N scores 48.4 COCO AP50:95 against 37.4 for YOLO11-N, but it carries 30.5M parameters against 2.6M. The accuracy gap narrows on RF100-VL, to 57.7 against 55.3 for the N sizes, and the two families carry different licences.

## Sources

- [License: Apache-2.0](https://github.com/roboflow/rf-detr/blob/develop/LICENSE)
- [Project website](https://rfdetr.roboflow.com)
- [README](https://github.com/roboflow/rf-detr/blob/develop/README.md)
- [Releases](https://github.com/roboflow/rf-detr/releases)
- [roboflow/rf-detr on GitHub](https://github.com/roboflow/rf-detr)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/roboflow-rf-detr