RF-DETR vs YOLO26: Which Detector Wins in 2026?

Quick answer. At similar T4 GPU latency, RF-DETR posts higher COCO mAP and adapts to custom datasets better, but carries 30M+ parameters and no real CPU path. YOLO26 is far lighter (2.4M params), runs fast on CPU, and covers more tasks. Choose RF-DETR for GPU-backed products; YOLO26 for low-power edge and IoT.

RF-DETR and YOLO26 are the two detectors most teams shortlist in 2026, and they sit on opposite sides of a real architectural split. RF-DETR is a transformer (a DETR variant on a DINOv2 backbone) built for fine-tuning accuracy. YOLO26 is the latest Ultralytics CNN, tuned relentlessly for small size and low-power inference. This is a neutral, benchmark-driven head-to-head so you can pick the right one without re-running every experiment yourself.

All numbers below come from each project's own published benchmarks. One caveat up front: the two families report latency on slightly different stacks (both NVIDIA T4, FP16, batch size 1, but different TensorRT/CUDA builds), so treat sub-millisecond gaps as noise, not a verdict.

What is actually different: transformer vs CNN?

The headline difference is the backbone and how each model turns features into boxes.

• RF-DETR uses a DINOv2 Vision Transformer backbone with deformable attention. It is a DETR-style detector: no anchor boxes and no non-maximum suppression (NMS). Object queries attend directly to image features and emit a fixed set of predictions end-to-end. The pretrained DINOv2 features are the reason it transfers so well to custom data.
• YOLO26 is a CNN detector, but it has closed much of the gap in workflow. YOLO26 introduces a native end-to-end, NMS-free dual-head design, removes Distribution Focal Loss (DFL) for a lighter regression head, and trains with a hybrid MuSGD optimizer plus Progressive Loss (ProgLoss) and a small-target-aware label assignment (STAL). The result is a tiny, fast model that no longer needs an NMS post-processing step either.

So "transformer vs CNN with NMS" is now outdated — both ship NMS-free in 2026. The live tradeoff is accuracy-per-millisecond and, more importantly, parameter count and where the model can physically run.

How do RF-DETR and YOLO26 compare on COCO?

Here are the two lineups on COCO, measured on a T4 with TensorRT FP16.

YOLO26 (COCO detection)

RF-DETR (COCO detection)

Reading the two tables against each other tells a consistent story. At roughly matched GPU latency, RF-DETR is the more accurate model:

• RF-DETR-Medium hits 54.7 mAP at 4.4 ms vs YOLO26m at 53.1 mAP at 4.7 ms.
• RF-DETR-Large hits 56.5 mAP at 6.8 ms vs YOLO26l at 55.0 mAP at 6.2 ms.
• At the top end, RF-DETR-2XLarge reaches 60.1 mAP — the highest here — but at 17.2 ms and 126.9M params.

But look at the params column. Every RF-DETR tier starts at ~30M parameters because the DINOv2 backbone is not small. YOLO26n does 40.9 mAP with just 2.4M parameters — an order of magnitude lighter than RF-DETR-Nano's 30.5M. That gap is the whole ballgame once you leave the GPU.

Which model handles custom datasets better?

COCO is a leaderboard, not your problem. Most production detection work is fine-tuning on a domain-specific dataset (retail shelves, defects on a line, medical frames, aerial imagery). This is where RF-DETR was explicitly designed to win.

Roboflow benchmarks RF-DETR on RF100-VL, a 100-dataset domain-adaptation suite that measures how well a model transfers to varied real-world data. RF-DETR posts strong RF100-VL scores across tiers (roughly 57.7 mAP for Nano up to 63.2 mAP for 2XLarge), and the DINOv2 pretraining is the reason — those self-supervised features generalize to new domains with less data. If your moat is a proprietary dataset and you have GPUs to fine-tune on, RF-DETR's transfer behavior is a genuine advantage.

YOLO26 fine-tunes cleanly too and its tooling is more mature for beginners, but Ultralytics does not market a comparable domain-adaptation transfer story — its edge is size and speed, not custom-data ceiling.

What about CPU, edge, and IoT?

This is where YOLO26 is simply in a different class. RF-DETR does not publish CPU latency numbers, and for good reason: a 30M+ parameter Vision Transformer with deformable attention is not something you want running on a Raspberry Pi, a phone, or a battery-powered camera.

YOLO26 was built for exactly that. YOLO26n is 2.4M params and Ultralytics reports up to 43% faster CPU ONNX inference for YOLO26n vs YOLO11n on an Intel Xeon CPU. The n and s tiers quantize well and export cleanly to ONNX, TensorRT, CoreML, TFLite, and NCNN — the formats that actually matter for embedded and mobile targets. If your compute budget is a CPU or a low-power NPU, YOLO26 is the only serious option of the two.

YOLO26 also covers more tasks in one framework: detection, instance and semantic segmentation, classification, pose estimation, and oriented bounding boxes (OBB). RF-DETR covers detection, instance segmentation, and keypoint detection (preview) — a narrower but capable set.

Does the license matter for a commercial product?

For a closed-source commercial product this is not a footnote — it can decide the whole thing.

• RF-DETR: the Nano through Large detection models and all training/inference code are Apache 2.0 — permissive, commercial-friendly, no copyleft. Only the XLarge/2XLarge "Plus" tiers use a separate PML 1.0 license.
• YOLO26: AGPL-3.0 or a paid Ultralytics Enterprise license. AGPL is copyleft and its network clause can require you to release your source if you ship YOLO26 inside a hosted service — so many companies buy the Enterprise license.

If you are building a proprietary GPU-backed product and want to avoid copyleft obligations without paying a per-seat license, RF-DETR's Apache 2.0 core tiers are the easier legal path.

How do you install and run each model?

Both are a one-line pip install. Here is a minimal inference run for each.

YOLO26

pip install ultralytics

from ultralytics import YOLO

# n / s / m / l / x tiers
model = YOLO("yolo26n.pt")

results = model("image.jpg", conf=0.25)
results[0].show()          # or .save(), or read results[0].boxes

RF-DETR

pip install rfdetr        # Python 3.10+

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

# RFDETRNano / RFDETRSmall / RFDETRMedium / RFDETRLarge
model = RFDETRMedium()

detections = model.predict("dog.jpg", threshold=0.5)

labels = [COCO_CLASSES[cid] for cid in detections.class_id]
annotated = sv.BoxAnnotator().annotate(
    detections.metadata["source_image"], detections
)
annotated = sv.LabelAnnotator().annotate(annotated, detections, labels)

Note that the XLarge and 2XLarge RF-DETR tiers ship in the rfdetr[plus] package under the PML 1.0 license, not the base Apache 2.0 install.

The verdict: which detector should you pick?

There is no single winner — the honest answer depends on your deployment target.

• Building a GPU-backed commercial product where accuracy and custom-data performance matter? Pick RF-DETR. It wins on COCO mAP at matched GPU latency, transfers to your own dataset better (RF100-VL), and its Apache 2.0 core tiers avoid AGPL headaches.
• Shipping to low-power CPUs, IoT devices, phones, or the edge — or you need OBB/pose in one framework? Pick YOLO26. Its 2.4M-parameter tiers, fast CPU ONNX path, and broad export support are unmatched by a 30M-parameter transformer.

A practical rule of thumb: if there is a discrete GPU in the loop and a dataset to fine-tune on, lean RF-DETR. If the model has to run where there is no GPU, lean YOLO26.

Deploying either at scale usually means owning the training and serving infrastructure yourself. If that is the direction, our guide to self-hosting open models on your own hardware covers the GPU, quantization, and serving decisions that carry over to vision workloads. And if you need engineers who have shipped detectors like these into production, Codersera can help you hire vetted machine-learning developers.

Want the rest of the cluster? See our YOLOv12 vs YOLOv10 vs YOLO26 comparison for the CNN lineage, and EfficientDet vs Detectron2 vs RF-DETR for how RF-DETR stacks up against the earlier two-stage and single-stage detectors.

FAQ

Is RF-DETR more accurate than YOLO26?

At comparable T4 GPU latency, yes. RF-DETR-Medium reaches 54.7 mAP at 4.4 ms versus YOLO26m at 53.1 mAP at 4.7 ms, and RF-DETR-2XLarge tops the chart at 60.1 mAP. The catch is parameter count: RF-DETR tiers start around 30M params, so that accuracy is only available where you have GPU headroom.

Can RF-DETR run on CPU or edge devices like YOLO26?

It can run, but it is not built for it. RF-DETR's DINOv2 Vision Transformer backbone and 30M+ parameters make CPU and low-power inference slow, and Roboflow does not publish CPU latency figures. YOLO26n at 2.4M params with a native CPU ONNX path is the correct choice for IoT, mobile, and embedded targets.

Which is better for fine-tuning on a custom dataset?

RF-DETR. It was explicitly designed for fine-tuning and leads on the RF100-VL domain-adaptation benchmark thanks to DINOv2 pretraining, so it transfers to new domains with less data. YOLO26 fine-tunes well too, but its advantage is size and speed rather than custom-data ceiling.

Do both models work without NMS?

Yes. RF-DETR is NMS-free by DETR design (object queries, no anchors). YOLO26 added a native end-to-end, NMS-free dual-head, so neither model needs a non-maximum-suppression post-processing step in 2026.

What licenses do RF-DETR and YOLO26 use?

RF-DETR's Nano through Large models and all code are Apache 2.0; the XLarge/2XLarge tiers use PML 1.0 via rfdetr[plus]. YOLO26 is AGPL-3.0 or a paid Ultralytics Enterprise license. For closed commercial products, RF-DETR's permissive core tiers are usually the simpler legal path.

Which model is faster overall?

On GPU at the smallest tier, YOLO26n (1.7 ms) edges RF-DETR-Nano (2.3 ms). On CPU, YOLO26 has no real competition because RF-DETR's transformer backbone is too heavy. At matched mid-range latency, RF-DETR delivers more accuracy per millisecond on GPU.