RF-DETR puts three vision tasks behind one Python API
RF-DETR v1.10.1 covers object detection, instance segmentation, and preview keypoint detection. A Python caller loads a size-specific class, passes an image, and receives detections that work with Roboflow's Supervision library. Fine-tuning uses COCO-format datasets, and export paths cover common deployment targets. This is a practical shape for a team that wants to compare one model family across several vision jobs without assembling a training framework first.
The repository is substantial even before weights arrive. Our commit 1312bf0 checkout contained 398 files and about 116,354 lines of source in 6.4 MB. The model API is much smaller than that count suggests, but the surrounding training, evaluation, augmentation, and export code matters when debugging a custom dataset. A buyer should review the particular path they will operate, since an inference-only use and a TensorRT training pipeline carry very different dependencies.
The 5,778 MB install changes the quick-start calculation
Our fresh Python 3.12 environment installed 97 packages in 160 seconds and occupied 5,778 MB. That is a large local footprint for a README whose first instruction is one pip command. The result does not include a downloaded checkpoint or a training dataset, so disk planning cannot stop at the Python environment. Small CI runners and shared notebooks may feel this cost before the first image reaches the model.
Optional features widen the setup further. Training, LoRA, ONNX, TensorRT, TFLite, Core ML, logging, visualization, and the Plus models have separate extras. Python 3.10 or newer is required, and the repository supplies 15 CI workflow files but no Dockerfile. That leaves image construction, CUDA compatibility, and cache policy with the adopter. For repeatable work, pin the chosen extra and the model asset instead of installing every path.
What happened when we ran it
Our sandbox installed RF-DETR in 160 seconds, built it in 6 seconds, and found 0 known vulnerabilities with pip-audit. The environment used 3 CPUs, 8 GB of RAM, Python 3.12 on Debian, and no secrets. Those results establish that commit 1312bf0 could resolve and build in a clean container. They do not measure inference speed, model accuracy, GPU memory, training time, or the quality of any exported model.
The test step failed after 24 seconds with exit code 4. Pytest did not reach test execution: it rejected the --doctest-plus argument while reading pyproject.toml. The log tells us the option was unrecognized, but it does not establish why. Treat the result narrowly. The checked source did not pass its configured test command in our environment, and a team depending on source installs should reproduce that command in its own image before promotion.
Preview keypoints and split licensing limit a blanket adoption
The 398-file checkout contains a wider product boundary than the Apache badge alone conveys. The README says the open rfdetr package and Apache-designated model weights use Apache 2.0. RF-DETR-XL and 2XL detection models come through rfdetr_plus under PML 1.0. Procurement should map the exact class name to its license before a model enters a product, especially if experiments may graduate to a larger size.
Keypoint detection needs similar precision. The README calls it preview and documents one person-keypoint class, while detection and segmentation each span several sizes. Teams building pose-dependent controls should not infer equal maturity from the shared API. The same caution applies to README benchmark tables: they describe NVIDIA T4, TensorRT, FP16, and batch size 1, conditions unlike our 3-CPU container and possibly unlike the hardware you will deploy.
Fifteen CI workflows show activity, while open reports expose edge cases
GitHub showed 9,342 stars and 96 combined issues and pull requests, with code pushed on September 7, 2026. Release 1.10.1 arrived that day with CUDA compile fixes and lower peak memory in segmentation loss. Current activity is easy to see in both code and issue updates. The combined open count is not a bug count, but it is enough traffic that adopters should search by model size, export target, and hardware before upgrading.
Two open threads describe limits worth testing locally. Issue 1414 asks about overlapping boxes after custom multiclass training, and issue 1391 proposes faster CPU JPEG decoding because data loading can starve a GPU. Neither report proves a general defect. They do identify useful acceptance tests: inspect predictions from your fine-tuned checkpoint, then profile the input pipeline rather than assuming model compute is the only bottleneck. Our 24-second test failure adds another reason to pin upgrades behind a project-specific check.
The 97-package environment suits measured GPU trials
RF-DETR makes most sense when a team owns the evaluation loop. Compare the Apache-licensed sizes against Ultralytics, D-FINE, or another baseline using your dataset, precision, batch size, and target device. Check false positives visually, confirm export parity, record cold-start behavior, and budget for checkpoints beside the 5,778 MB environment. The supplied API lowers the cost of running that trial, while the split extras keep optional deployment stacks out of the base package.
A quick demo is easier than a production decision. The source build passed in 6 seconds, yet pytest stopped before collecting tests, so our evidence is mixed rather than negative across the board. RF-DETR earns attention for a team that needs both boxes and masks and can test on the intended GPU. A developer seeking a tiny CPU package, a ready-made container, or a single licensing answer across every detection size has better starting points.