RF-DETR: where the Apache 2.0 line ends and the license does not

The two most accurate sizes are not Apache 2.0

RF-DETR ships as a package called `rfdetr` under Apache 2.0, and the sizes named RF-DETR-N, RF-DETR-S, RF-DETR-M, and RF-DETR-L are Apache-designated models. The two largest detection sizes are not, and neither are Atto, Femto and Pico. RF-DETR-XL and RF-DETR-2XL are Plus components in the optional `rfdetr[plus]` extension, licensed under PML 1.0, and the detection table flags both rows because of it.

Those two rows are the accuracy ceiling of the detection family, at 77.4 and 78.5 COCO AP50 and 58.6 and 60.1 AP50:95. The closest Apache row is RF-DETR-L at 75.1 and 56.5. So the measured cost of staying inside Apache 2.0 is 3.4 points of AP50 and 3.6 points of AP50:95, plus 11.5 ms and 17.2 ms of reported latency against 6.8 ms for L. The assumption that an Apache 2.0 repository hands you an Apache 2.0 model holds for four of the nine detection sizes, and the two largest of the five that break it are the ones you would otherwise pick for accuracy work.

Every latency number comes from one T4 at batch size 1

Read the benchmark footnotes before you plan capacity. All latency figures were measured on an NVIDIA T4 using TensorRT, FP16, and batch size 1. Parameter counts are deployment fused `nn.Module` counts taken from `model.parameters()`, not the raw tensor count of the saved checkpoint.

Three consequences follow. A number from that setup is a batch-1 figure, so a serving path with eight concurrent frames will not reproduce it. It is a TensorRT FP16 figure, so an eager PyTorch deployment is not what is being described. And because the counts are fused module counts, sizing a memory budget from the Params column understates what you download and load.

Accuracy is in-house too: every COCO number shown was computed with pycocotools in SAB over the full 5,000-image `val2017` split for all models, which makes the rows comparable to one another but not necessarily to figures a vendor published. Rows marked with a dagger are quoted from the original authors' paper and were not measured in SAB at all.

Each size changes its own input resolution, from 384x384 to 880x880

Swapping sizes is not a config change. RF-DETR-N runs at 384x384, RF-DETR-S at 512x512, RF-DETR-M at 576x576, and RF-DETR-L at 704x704. The PML-licensed XL sits at 700x700 and 2XL at 880x880, so the progression is not even monotonic between L and XL, which rules out any assumption that resolution scales with the size name.

For a team that already has a trained checkpoint, this is the part that bites. Moving from N to L changes the input geometry, which changes preprocessing, augmentation, and any downstream code that assumed a fixed frame size. It also moves accuracy from 67.6 to 75.1 AP50 and latency from 2.3 ms to 6.8 ms. The migration is therefore a retraining project rather than a config edit, and it deserves its own evaluation cycle instead of being folded into a release.

The published sizes came out of neural architecture search

The shipped sizes were produced with neural architecture search rather than drawn by hand, and the same search method is offered on the Roboflow platform so you can look for a better architecture for your own dataset. What lands in the pip package is therefore the output of a search, not a family you can extrapolate from. Nothing in the published set tells you what an intermediate size between M and L would cost in latency or accuracy, and nothing guarantees the search that produced N through 2XL is the search you would run on a small industrial dataset.

Underneath, the sizes other than Atto, Femto and Pico sit on a DINOv2 vision transformer backbone (those three use a PE-Core-T backbone) shared by detection, instance segmentation, and the preview keypoint head, which is how one API surface covers all three tasks. If your imagery sits far from COCO and RF100-VL, the platform search is a separate product decision the open repository does not make for you.

Keypoint detection is labeled preview in the same breath as detection

The headline covers three tasks through one API: object detection, instance segmentation, and keypoint detection, and the parenthetical that follows keypoint detection is the word preview. The qualifier shows up in the summary line and again in the description of the API surface, so it is a deliberate label rather than a stray adjective.

That label is the only maturity signal you get, and it carries the whole weight. Detection and segmentation carry full tables on COCO and RF100-VL. The benchmark tables cover detection and segmentation. If you are planning a pose pipeline on RF-DETR you are planning on the preview tier, and the figures you will be measured against are detection and segmentation figures that say nothing about keypoint quality, error rate, or throughput. Treat pose work as an evaluation project with a planned exit, not as a drop-in replacement for a keypoint model you already run.

RF100-VL is scored for detection only, leaving segmentation on COCO alone

The benchmark tables carry two dataset columns, COCO and RF100-VL, and the scope note is explicit that RF100-VL is used for detection only. No RF100-VL segmentation column appears in what is published.

So the segmentation story in this repository rests on a single dataset. COCO has established annotation conventions and a well known class distribution, and a segmentation number there does not transfer on its own to a warehouse aisle, an assembly bench, or a retail shelf. The RF100-VL column, which is the more distribution-shifted read, tells you nothing about masks. If segmentation is your actual task, the table gives you a ranking rather than a prediction, and you need your own labelled set to choose between RF-DETR-M at 576x576 and something cheaper.

Installing from source pulls a develop branch the project calls less stable

The published install is one command in a Python 3.10 or newer environment:

pip install rfdetr

There is a second path. The source install is an archive of the develop branch:

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

The note attached to that second command says the updates are still in development and may not be as stable as the latest published release, which means the two paths do not install the same thing. The repository tip sits at version 1.12.0.dev in pyproject.toml while the newest tagged release is 1.11.2, so the branch you install from source is a full minor version ahead of what has shipped. Use the package install unless you need a specific unreleased change, and if you do take the source path, record the commit so the environment is reproducible later.

The dependency floor pins transformers below 6.0 and torch above 2.2

The dependency list is short and its floors are explicit. `torch>=2.2.0` carries the core tensor ops and the model forward pass, `torchvision>=0.17.0` is aligned with it for image transforms and ops, and `transformers>=5.1.0,<6.0.0` exists to load the DINOv2 backbone. `requests` and `tqdm` handle weight downloads from remote URLs, `numpy` handles array conversion across inference, evaluation, export, and visualization, and `pydantic` handles configuration.

The transformers ceiling is the constraint that bites. An environment already on transformers 6 cannot take this package without moving backwards, so RF-DETR can end up deciding the transformers version for a whole environment. Python support runs from 3.10 through 3.14, and the project classifies itself as Beta. Recent release titles show the churn: 1.11.0 brought a wider export surface and faster training, 1.11.1 brought correctness fixes for LoRA, TensorRT, and crowd mAP, and 1.11.2 brought safer threaded inference and training inputs. Pin exact versions and read the notes, because a TensorRT export correctness fix arriving in a patch release is a reason to distrust every export you validated before it.

Editorial conclusion

RF-DETR suits teams fine-tuning detection or segmentation on their own labelled data who can accept an Apache 2.0 ceiling at RF-DETR-L instead of the two strongest detection sizes. It does not suit a requirement for XL or 2XL under Apache terms, a production pose pipeline built on keypoint detection, or a latency budget copied from a batch-1 TensorRT run on an NVIDIA T4. Before adopting it, check the license attached to the exact size you plan to deploy, pin the package version because 1.11.1 was a correctness fix release covering LoRA, TensorRT, and crowd mAP, and re-measure latency on your own accelerator.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. roboflow/rf-detr on GitHub