RF-DETR vs YOLO-NAS: A Practical Benchmark for Edge Deployment: CPU, GPU, and Intel iGPU Compared

When accuracy matters, pick the transformer. When latency matters, pick the CNN. This article gives you the numbers to defend that call.

Disclosure: I’m an Intel Software Innovator for OpenVINO. Intel did not fund, review, or see this benchmark before publication, and had no input on what I measured or what I reported. Every number below is reproducible from the companion repository.

This post was corrected on 9 August 2026: the PyTorch YOLO-NAS mAP figures were too low, and RF-DETR’s accuracy lead is about half what I first published. The tables here are the corrected ones. What changed, and why a deterministic pipeline can still be wrong, is in the correction log at the end.

Every few months, a new object detection model claims state-of-the-art results on COCO. The leaderboard numbers look impressive, but they rarely answer the question that matters in production: which model should I deploy on my hardware, at my resolution, with my constraints?

In this article, I benchmark RF-DETR Nano and YOLO-NAS-S head-to-head on COCO-2017 validation across two input resolutions (256 and 384) and three compute targets (CPU, NVIDIA CUDA GPU, Intel Iris Xe integrated GPU). I also export both models to OpenVINO in FP32, FP16, and INT8 precision, fine-tune them on a custom dataset, and, critically, keep a single, consistent evaluation methodology across every run so the numbers are actually comparable.

That fine-tuning section is there on purpose. Hardly anyone ships COCO weights straight to production. The 80 COCO classes are almost never the ones you need, and the images those weights were trained on look nothing like the camera you are actually pointing at the problem. The real job is to take a pretrained checkpoint, show it a few hundred labelled images of your own, and find out what comes back. That step carries costs a leaderboard never reports: how much GPU memory the training run needs, how long one experiment takes end to end, how much accuracy survives when the dataset is small. Those are the numbers I want in front of me when I’m choosing a detector for a real project, so I measured them alongside the COCO ones.

The short answer: RF-DETR is the accuracy leader. YOLO-NAS is the speed, efficiency, and edge-deployment leader. The trade-off is sharp and predictable. The full picture is more interesting than that one-liner, which is why you’re here.

All code, configs, and reproduction scripts are in the companion repository. YOLO-NAS training and inference are powered by modern-yolonas, a clean reimplementation of the YOLO-NAS architecture with a modern training pipeline, written up in its own post: YOLO-NAS without super-gradients.

---

TL;DR

• Accuracy (COCO mAP, PyTorch): RF-DETR wins at every resolution tested. At 256x256 it beats YOLO-NAS by +17% relative mAP (0.437 vs 0.3735). At 384x384 the gap narrows to +11% (0.506 vs 0.4560), but RF-DETR still wins.
• Latency (PyTorch): YOLO-NAS is 1.6–1.8x faster than RF-DETR on both CPU and CUDA at every tested resolution.
• The cost side of that: RF-DETR Nano carries 30.5M parameters and 14.1 GFLOPs at 256x256 against YOLO-NAS-S’s 19.1M and 5.4 GFLOPs, so it is doing 2.6x the arithmetic per image.
• GPU latency is nearly resolution-invariant. Both models run within 1ms of themselves going 256 → 384 on CUDA. On GPU, you can just pick the resolution that maximizes accuracy.
• Intel Iris Xe iGPU via OpenVINO: YOLO-NAS hits 151 FPS at FP32 and 215 FPS at INT8, 3.5x faster than RF-DETR on the same iGPU. Real-time detection with no discrete GPU needed.
• INT8 collapses the accuracy gap. RF-DETR loses 21% mAP to quantization; YOLO-NAS loses just 2.5%. At INT8, the two models land within noise of each other on mAP (0.336 vs 0.338), but YOLO-NAS runs 3.5x faster.
• Fine-tuning on a custom 200-image dataset: RF-DETR wins accuracy by +30% mAP@0.50 (0.607 vs 0.468). YOLO-NAS trains 11.6x faster with 3.8x less GPU memory and runs 1.7x faster at inference.
• Licences differ where it counts. RF-DETR Nano’s weights are Apache-2.0. YOLO-NAS’s pretrained COCO weights are not: they are non-commercial.

If you only deploy on a dedicated GPU running FP32/FP16 and accuracy is everything, pick RF-DETR. If you deploy on iGPU, CPU, embedded, or any INT8 runtime, or if training budget is tight, pick YOLO-NAS.

---

The Models

RF-DETR Nano

RF-DETR is a detection transformer published at ICLR 2026 by Robinson et al. from Roboflow [1]. It pairs a pre-trained DINOv2 Vision Transformer backbone [7] with a lightweight deformable DETR decoder [10]. The model is NMS-free, and its self-supervised pretraining gives it strong feature representations before it has seen a single detection label. RF-DETR also applies Neural Architecture Search to pick encoder-decoder configurations for different latency targets, which is where the paper’s title comes from.

That sentence is dense with jargon, so here is what each piece actually means.

Term	What it means here
Encoder–decoder	Two stacks of layers. The encoder turns the image into a set of feature vectors; the decoder reads those vectors and produces the outputs, one per candidate object. The split comes from the original transformer [11], and detection transformers reuse it with image patches standing in for words.
Deformable DETR decoder	The first DETR had every decoder query attend to every position in the feature map, which is expensive and notoriously slow to converge. Deformable attention instead lets each query sample a handful of learned offset positions [10], a few points per query per feature level rather than the whole map. “Lightweight” here means RF-DETR uses fewer decoder layers and fewer queries on top of that.
NMS-free (set prediction)	A classic detector emits many overlapping boxes and then deletes the duplicates with non-maximum suppression: sort by score, keep the best box, drop everything overlapping it past an IoU threshold, repeat [5]. DETR-style models are trained with a bipartite matching loss that assigns exactly one prediction to each ground-truth object [9], so the duplicates are never produced and the NMS step disappears from the pipeline along with its threshold and its CPU cost. YOLO-NAS still needs NMS.
Self-supervised pretraining	The backbone learned its features from unlabelled images, by being asked to give two different crops of the same photo the same representation, rather than from human class labels. DINOv2 [7] is the version RF-DETR builds on.
Neural Architecture Search (NAS)	Instead of a human picking layer widths, depths and block types, a search algorithm proposes architectures, scores them against an objective (here, accuracy at a fixed latency) and keeps the winners [12]. Both models in this article were shaped by it, at different points in their design.

YOLO-NAS-S

YOLO-NAS was developed by Deci AI using their proprietary AutoNAC Neural Architecture Search technology [2]. Its backbone uses optimized Quantization-Aware RepVGG (QA-RepVGG) blocks designed specifically so that accuracy survives INT8 post-training quantization, which is the one architectural fact most of Result 3 below turns on. The architecture uses two specialized quantization-aware modules, QSP and QCI blocks, built from QA-RepVGG, and an anchor-free detection head with Distribution Focal Loss (DFL) [3]. Deci reported searching a space of over 10^14 possible configurations to maximize the accuracy-latency Pareto frontier.

Running YOLO-NAS here meant rebuilding it: super-gradients has not shipped a PyPI release since April 2024. That reimplementation, what the model looks like from the inside, and the licensing trap attached to its weights are the subject of a separate post, YOLO-NAS without super-gradients.

A note on sourcing: Deci’s own blog post is the only primary source for the QSP/QCI naming and the 10^14 figure, and since the NVIDIA acquisition it renders as a JavaScript-only page. Secondary write-ups disagree on what the two acronyms expand to, so I’ve left them unexpanded rather than pick a version I can’t verify. The architectural claim that matters here, that these blocks were designed for INT8 post-training quantization, is corroborated by the survey in [3] and is what the measurements below actually test.

Side by side

Feature	RF-DETR Nano	YOLO-NAS-S
Backbone	DINOv2 (ViT)	NAS-optimized CNN (QA-RepVGG)
Detection Head	Deformable DETR decoder	Anchor-free (DFL)
NMS Required	No (set prediction)	Yes
Quantization Design	Not quantization-aware	INT8-aware (QA-RepVGG)
Parameters	30.47M	19.05M
GFLOPs @ 256x256	14.11	5.42
GFLOPs @ 384x384	29.04	12.20
Code licence	Apache-2.0	Apache-2.0 (super-gradients)
Pretrained COCO weights	Apache-2.0	Super Gradients Model EULA, non-commercial
Inference library	rfdetr v1.6.4	modern-yolonas v0.3.0

Parameters are sum(p.numel() for p in model.parameters()). FLOPs are one batch-1 forward pass counted with torch.utils.flop_counter, which scores a multiply-accumulate as two FLOPs; halve them if you want the GMACs figure that detection papers usually print. Both come from model_complexity.py in the companion repo. RF-DETR carries 1.6x the weights and 2.6x the arithmetic of YOLO-NAS at the same input size, which is most of the latency story before a single benchmark has been run.

---

Benchmark Setup

Before we get to the numbers, here’s exactly how the benchmarks were run, so you can verify, reproduce, or contest them.

Parameter	Value
CPU	12th Gen Intel Core i7-12700H
iGPU	Intel Iris Xe Graphics, 96 EU (OpenVINO device GPU.0)
dGPU	NVIDIA GeForce RTX 3060 Laptop
RAM / OS	31 GiB / Ubuntu 22.04 LTS, x86_64
Python	3.13
PyTorch	2.10.0+cu130
RF-DETR runtime	rfdetr 1.6.4, checkpoint rf-detr-nano.pth (Apache-2.0)
YOLO-NAS runtime	modern-yolonas 0.3.0, Deci COCO weights (Super Gradients Model EULA, non-commercial)
OpenVINO / NNCF	openvino 2026.0.0 / nncf 3.0.0
Export	ONNX opset 17 → ov.convert_model
Quantization	NNCF PTQ, QuantizationPreset.PERFORMANCE, 100 COCO-val calibration images. YOLO-NAS excludes /heads/.* via IgnoredScope
Dataset	COCO-2017 validation, 500 samples (see Which 500? below)
Evaluation	FiftyOne 1.13.4, method="coco" (pycocotools-compatible, IoU 0.5:0.05:0.95)
Resolutions	256x256 and 384x384 (both models, square input)
Confidence threshold	0.05 (low, and critical for correct mAP PR-curve coverage)
Batch size	1 (single-image inference, typical for real-time deployment)
Warmup	5 inferences on the first image, discarded
Timing	One pass of 500 timed inferences per configuration; the reported figure is the mean, and FPS = 1000 / mean. CUDA runs call torch.cuda.synchronize() on both sides of the timer
Inside the timer	Image decode, preprocessing, forward pass, postprocessing (and NMS, for YOLO-NAS)
Outside the timer	FiftyOne format conversion, dataset writes, and mAP evaluation

Two of those rows deserve their own paragraph.

Why threshold = 0.05? This caught me off-guard during the investigation. Running mAP eval with a 0.5 confidence threshold, a common default for visualization, truncates the precision-recall curve and produces dramatically wrong mAP values. Ideally use 0.0 or 0.01; 0.05 is a safe cutoff that keeps the eval fast without losing meaningful recall. If your mAP numbers don’t match published COCO leaderboards, check your threshold first.

That was the advice in the first version of this post. It deserved a measurement, so here is one. Same 500 images, same models, only the confidence threshold moving (threshold_sweep.py in the companion repo):

Confidence	YOLO-NAS-S @256	RF-DETR @256	YOLO-NAS-S @384	RF-DETR @384
0.001	0.3738	0.4358	0.4563	0.5136
0.01	0.3738	0.4358	0.4563	0.5136
0.05	0.3735	0.4354	0.4560	0.5131
0.1	0.3710	0.4329	0.4525	0.5105
0.25	0.3532	0.4168	0.4339	0.4899

Two things fall out of that. Between 0.001 and 0.05 the answer barely moves — under 0.1% for every model and resolution, so the cheaper cutoff costs nothing worth having, which is the whole reason to use it. And the damage past that point arrives sooner than you would guess: measured against the 0.05 row, a threshold of 0.25 costs 4.3–5.4% relative mAP. It is not a cliff you fall off at 0.5. You are already paying at 0.25.

The effect is not a quirk of one architecture either. The NMS-free transformer and the CNN lose a similar fraction, because what a high threshold truncates is the low-precision tail of the PR curve, and both models have one.

(The RF-DETR figures in this table sit 0.001 below the ones in Results 1 and 2. This sweep was run in August 2026 against newer library versions than the original benchmark; the difference is in the third decimal, which the Limitations section already asks you to treat as noise. YOLO-NAS reproduces the main tables exactly.)

Image decode is inside the timer. Every latency figure below includes reading the JPEG off disk and preprocessing it, not just the forward pass. That is deliberate, because it is what a real pipeline pays, but it matters when you read Result 2: that per-image cost is fixed, and it does not shrink when the network’s input resolution does.

Which 500?

A fair question about any subset benchmark: which 500 images, and can I get the same ones? No seed is involved, and none is needed. FiftyOne’s COCO loader defaults to shuffle=False, sorts the candidate image IDs, and returns image_ids[:max_samples], so max_samples=500 is always the 500 lowest-numbered images in val2017, on any machine, from the same annotations file.

import fiftyone.zoo as foz

dataset = foz.load_zoo_dataset(
    "coco-2017",
    split="validation",
    max_samples=500,
    shuffle=False,   # the default; stated so the subset documents itself
)

To make that checkable rather than a claim you have to take on trust, the companion repo ships subset_fingerprint.py:

Property	Value
Samples	500
First file	000000000139.jpg
Last file	000000056545.jpg
SHA-256 of the sorted filename list	3c9ca937aa926ea52fa435f87894e2f42fbf6b434bdeddb220fcbd2611a19273

If your hash matches, you are evaluating on exactly the images I evaluated on. If it doesn’t, nothing below is comparable, and that is worth finding out before you argue with the numbers.

---

Result 1: Accuracy vs Latency at 256x256

This is the canonical comparison. Most edge deployments ship at 256 or thereabouts, small enough to fit in a quantized model running on an iGPU or embedded accelerator.

Model	Device	mAP	Avg (ms)	FPS
RFDETRNano 256	CPU	0.437	65.9	15.2
YOLO-NAS-S 256	CPU	0.3735	38.4	26.1
RFDETRNano 256	CUDA	0.437	17.4	57.6
YOLO-NAS-S 256	CUDA	0.3735	10.6	94.3

The chart shows the shape of the trade-off in a way the table can’t: each model occupies its own horizontal band. Swapping CPU for a GPU slides you left along that band and buys speed. Nothing about the hardware moves you up. Accuracy is decided entirely by which model you picked.

RF-DETR beats YOLO-NAS by +17% relative mAP (0.437 vs 0.3735). That gap is still well beyond the noise margin of a 500-sample eval. The DINOv2 backbone’s self-supervised pretraining gives RF-DETR a feature-quality advantage at this resolution.

YOLO-NAS beats RF-DETR on latency by a consistent 1.6–1.7x on both CPU and CUDA. That ratio should not surprise anyone who read the complexity table: RF-DETR is doing 2.6x the arithmetic per image. CNN forward passes are still cheaper than attention at this scale, and YOLO-NAS’s architecture was NAS-searched to minimize latency in the first place.

Observation: CPU and CUDA mAP agree to the fourth decimal place (0.4366 vs 0.4367 for RF-DETR; both 0.3735 for YOLO-NAS). This is your sanity check: if a methodology change moved mAP, CPU and CUDA would diverge. Agreement this tight means the evaluation pipeline is deterministic and reproducible — and note that it is a check on determinism, not on correctness. A pipeline can be perfectly reproducible and still be systematically wrong, which is exactly what happened here (see the correction log).

---

Result 2: Does Higher Resolution Help? (384x384)

Model	Device	mAP	Avg (ms)	FPS
RFDETRNano 384	CPU	0.506	106.4	9.4
YOLO-NAS-S 384	CPU	0.4560	59.2	16.9
RFDETRNano 384	CUDA	0.506	17.8	56.2
YOLO-NAS-S 384	CUDA	0.4560	10.5	94.9

Both models improve at higher resolution, but the gap doesn’t close much:

Model	mAP @256	mAP @384	Relative Δ
RF-DETR Nano	0.437	0.506	+16%
YOLO-NAS-S	0.3735	0.4560	+22%

Two surprises here:

1. YOLO-NAS gains more from higher resolution than RF-DETR. The popular narrative, that transformers need high resolution and CNNs don’t, doesn’t hold for this pair. YOLO-NAS’s CNN benefits more (relatively) from more pixels. RF-DETR starts from a much higher baseline, so it has less room to grow.

2. GPU latency is nearly resolution-invariant. On CUDA, RF-DETR runs at 17.4ms @256 and 17.8ms @384, a 0.4ms (2%) increase for 2.25x more pixels. YOLO-NAS is similarly flat (10.6 → 10.5ms). On the GPU the extra pixels are essentially free; on the CPU they cost about 1.5–1.6x.

The two flat CUDA lines are the interesting part, and they are not saying compute is free. Both models really do more arithmetic at 384: RF-DETR goes from 14.1 to 29.0 GFLOPs, YOLO-NAS from 5.4 to 12.2. The RTX 3060 just finishes either amount long before the rest of the per-image work is done. What’s left is JPEG decode, preprocessing, postprocessing and host/device round-trips, all of which sit inside the timer (see Benchmark Setup) and none of which care about the network’s input size. On the CPU there is no such slack, so the dashed lines climb — though less steeply than compute alone: RF-DETR’s arithmetic goes up 2.06x for a 1.61x increase in CPU time, and YOLO-NAS’s 2.25x for 1.54x. The gap between those pairs is the same fixed decode-and-preprocess cost, sitting in every measurement and growing with none of them.

Practical takeaway: resolution is not the differentiator between these models. They each have a fixed accuracy-latency ratio that stays roughly consistent across resolutions. Pick the model first (based on accuracy vs speed priority), then pick the resolution based on your hardware constraints.

---

Result 3: OpenVINO on Intel iGPU, the Edge Deployment Story

I exported both models to OpenVINO IR format [8] and benchmarked them on the Intel Iris Xe integrated GPU, the graphics processor that ships in most modern laptops and many edge devices. All numbers below use the same methodology as the PyTorch runs above (n=500, threshold=0.05, FiftyOne COCO eval).

How the export actually works

I don’t have a standalone post on this yet, and the OpenVINO path is short enough that it may never need one. Export to ONNX, convert, save. Three calls:

import openvino as ov

# PyTorch -> ONNX (opset 17) is the usual torch.onnx.export, or the framework's
# own exporter: rfdetr ships model.export().
ov_model = ov.convert_model("model.onnx")

ov.save_model(ov_model, "FP32/model.xml")
ov.save_model(ov_model, "FP16/model.xml", compress_to_fp16=True)

INT8 is one more call, into NNCF. The only extra input it needs is a few hundred real images run through the same preprocessing the model will see in production. Get that wrong and the calibration statistics describe a distribution your deployment never produces:

import nncf

def calibration_data():
    for path in calibration_images:      # 100 COCO val images here
        yield preprocess(path)           # the deployment preprocessing, not a bare resize

int8_model = nncf.quantize(
    ov_model,
    nncf.Dataset(calibration_data()),
    preset=nncf.QuantizationPreset.PERFORMANCE,
    # YOLO-NAS only: the detection heads hit a shape-inference bug in the
    # OpenVINO GPU plugin when quantized, so they stay in floating point.
    # Backbone and neck are fully INT8.
    ignored_scope=nncf.IgnoredScope(patterns=["/heads/.*"]),
)
ov.save_model(int8_model, "INT8/model.xml")

The full version, including both preprocessing functions, is in export_openvino.py in the companion repo.

The numbers

Model	Precision	mAP	Avg (ms)	FPS
RFDETRNano 256	FP32	0.428	22.2	45.1
RFDETRNano 256	FP16	0.428	22.0	45.5
RFDETRNano 256	INT8	0.338	16.1	62.1
YOLO-NAS-S 256	FP32	0.345	6.6	151.2
YOLO-NAS-S 256	FP16	0.345	6.6	151.4
YOLO-NAS-S 256	INT8	0.336	4.7	215.0

Two headlines:

1. YOLO-NAS runs 3.3–3.5x faster than RF-DETR on the iGPU at every precision. At FP32 it does 151 FPS. At INT8 it does 215 FPS: real-time detection on integrated graphics with zero discrete GPU required.

2. At INT8, the two models hit virtually identical mAP (0.336 YOLO-NAS vs 0.338 RF-DETR). The PyTorch accuracy gap collapses to within noise, because RF-DETR loses 21% of its mAP to quantization while YOLO-NAS loses only 2.5%.

The Quantization Story

INT8 quantization affects the two architectures very differently:

Model	FP32 mAP	INT8 mAP	Δ mAP	FPS gain
RF-DETR Nano	0.428	0.338	−21.2%	+38%
YOLO-NAS-S	0.345	0.336	−2.5%	+42%

RF-DETR loses 21% of its accuracy to INT8; YOLO-NAS loses 2.5%. YOLO-NAS was built for quantization from day one. Its QA-RepVGG blocks were designed to maintain accuracy under INT8 post-training quantization. The QSP and QCI modules avoid the numerical instabilities that typically arise when quantizing skip connections and batch normalization layers. Deci’s NAS process specifically searched for architectures that held accuracy after INT8 conversion.

RF-DETR was not designed with quantization in mind. Its DINOv2 backbone uses standard ViT blocks with self-attention operations involving softmax normalization and large dynamic ranges in the query-key dot products, operations that are inherently sensitive to reduced numerical precision. The 21% mAP loss is what one default PTQ configuration costs an architecture optimized purely for floating-point accuracy. I did not try to rescue it, so read the Limitations before treating that figure as an architectural ceiling.

For YOLO-NAS, INT8 is essentially free. For RF-DETR, it’s a painful trade: you give up the accuracy advantage that was the reason to pick RF-DETR in the first place.

FP16 is free, on both models

On the Iris Xe GPU plugin, FP16 and FP32 are indistinguishable in mAP and throughput for both models. No reason to ship FP32 on this device. (This is plugin-specific: on CPU and some other accelerators FP16 has different latency trade-offs.)

A cross-device comparison worth pausing on

Configuration	mAP	FPS
YOLO-NAS-S, OpenVINO INT8, Intel Iris Xe iGPU	0.336	215.0
RF-DETR Nano, PyTorch FP32, NVIDIA RTX 3060 dGPU	0.437	57.6

YOLO-NAS-S INT8 on an integrated GPU achieves 3.7x the throughput of RF-DETR on a dedicated RTX 3060, at the cost of 23% mAP. This doesn’t make YOLO-NAS “better”; it makes it a very different deployment choice. The right model combined with OpenVINO INT8 turns a low-power iGPU into a 200 FPS inference engine. For cost-sensitive, power-sensitive, or fanless edge deployments, this changes the hardware story.

---

What 30 FPS Actually Costs

Throughput only becomes a budget once you divide it by the workload. Take 30 FPS as the bar for a real-time camera and read Result 3 as cameras per box rather than frames per second:

Model (OpenVINO INT8, Iris Xe)	FPS	30-FPS streams per box	Cost per stream at $379
YOLO-NAS-S 256	215.0	7	~$54
RF-DETR Nano 256	62.1	2	~$190

The first thing to notice is what doesn’t happen. Both models clear 30 FPS on the cheap integrated GPU. RF-DETR Nano does 62 FPS at INT8 and 45 FPS at FP32 on that same Iris Xe. Nobody here is pushed onto a discrete GPU to hit real-time on one camera, so if you have a single stream this section is moot: buy the box, run either model, choose on accuracy.

The 3.5x starts to matter when you have more than one camera. Seven streams per box against two is 3.5x fewer boxes for the same camera count, and that multiplies through everything downstream: hardware, rack space, power, and the number of machines somebody has to keep patched. At a street price of $329–379 for a Beelink EQi12-class mini PC with an Iris Xe iGPU (checked 16 August 2026), a 16-camera site is roughly three boxes on YOLO-NAS and eight on RF-DETR.

Three caveats, because this arithmetic is doing a lot of work:

• I measured one stream, batch 1. Dividing throughput by 30 assumes the box scales close to linearly with concurrent streams. It won’t: memory bandwidth, scheduler overhead and thermals all take a cut. Treat these as ceilings and measure your own concurrency before you buy anything.
• I did not benchmark a mini PC. My Iris Xe is the one in an i7-12700H laptop, with 96 execution units. The i5-1235U in that Beelink has 80, so a real box should land under these numbers.
• Prices move. The dollar figures anchor the ratio; they are not a quote.

The ratio is the durable part. The absolute FPS belongs to my laptop.

---

Result 4: Fine-Tuning on a Custom Dataset

This is the part that matters most for real work, and the part a COCO leaderboard cannot tell you anything about. To test transfer learning, I fine-tuned both models on a small custom dataset: 5 animal classes (bird, cat, dog, horse, sheep) extracted from COCO, with only 200 training images and 50 validation images. Both models trained for up to 30 epochs at 256x256 on the RTX 3060. RF-DETR stopped early at 29 epochs (10-patience on val mAP). YOLO-NAS ran the full 30.

Training Efficiency

Metric	RF-DETR Nano	YOLO-NAS-S
Training time	3604s	311s (11.6x faster)
Peak GPU memory	2774 MB	733 MB (3.8x less)

YOLO-NAS trains 11.6x faster and uses 3.8x less GPU memory. On a 4GB or 6GB GPU, which is common for laptops and lower-tier edge boxes, this is the difference between fine-tuning being possible and not.

The training-time delta is larger than you’d expect from architecture alone: rfdetr 1.6.4 uses a PyTorch Lightning training pipeline that adds real per-epoch validation and checkpoint overhead. On a tiny 200-image dataset, that overhead dominates. On larger datasets the ratio would shrink, but for rapid iteration on custom data it’s very much the lived experience. This is where modern-yolonas earns its keep: a minimal, Python 3.13-native training loop that does only what you need (EMA, mixed precision, cosine LR, task-aligned assignment) without dragging in a heavy orchestration framework.

Detection Quality (Standardized FiftyOne COCO Eval, threshold=0.05)

Model	mAP@0.50	mAP@0.50:0.95	FPS
RF-DETR Nano FT	0.607	0.457	62.3
YOLO-NAS-S FT	0.468	0.328	106.4

RF-DETR wins accuracy on fine-tuning too, by +30% relative mAP@0.50 (0.607 vs 0.468) and +39% relative mAP@0.50:0.95. The transformer’s self-supervised DINOv2 pretraining is pulling its weight here: it transfers better to a small custom dataset than YOLO-NAS’s CNN-based COCO pretraining. If you have 200 labeled images and want the best possible accuracy, RF-DETR is the right tool.

YOLO-NAS wins inference speed after fine-tuning: 1.7x faster (106.4 vs 62.3 FPS). Same trade-off as with pretrained weights.

What “tighter boxes” means in practice: mAP@0.50:0.95 averages precision across IoU thresholds up to 0.95 [5], where higher values mean boxes line up more precisely with ground-truth edges. This matters if you’re cropping objects, measuring dimensions, or feeding boxes into a downstream tracker that cares about box stability across frames. RF-DETR’s +39% relative advantage here is significant for those use cases. (For more on these numbers, see the object detection metrics primer.)

The practical question: is the accuracy gap worth 11.6x more training time?

For a one-shot fine-tune on a production dataset, 3600s is 1 hour, which is trivial. Take the accuracy.

For rapid iteration (“let me try a different augmentation, different class mapping, different LR schedule”) YOLO-NAS’s 5-minute turnaround vs RF-DETR’s 1-hour is the difference between 10 experiments in an afternoon and 2 experiments in an afternoon. If you’re still figuring out the right training config, YOLO-NAS lets you iterate.

---

When to Choose Which Model

Choose RF-DETR Nano when:

• Accuracy is the top priority and you can afford ~1.6x the latency.
• You have a dedicated GPU. GPU latency barely scales with resolution, so run it at 384 and reap the +16% mAP.
• You need tight bounding boxes (downstream cropping, measurement, tracking).
• Your deployment is floating-point (FP32/FP16). INT8 on RF-DETR costs 21% mAP, wiping out its accuracy advantage.
• You don’t need NMS (set prediction simplifies some pipelines).
• You are shipping commercially on pretrained weights. RF-DETR Nano’s are Apache-2.0. YOLO-NAS’s are not.

Choose YOLO-NAS-S when:

• Latency is the top priority and the +11–17% mAP gap is acceptable for your task.
• You’re deploying on CPU, iGPU, ARM, or embedded hardware. YOLO-NAS is architecturally faster across the board.
• You need INT8 quantization without severe accuracy loss (−2.5% vs RF-DETR’s −21%). At INT8, YOLO-NAS is effectively tied on mAP with RF-DETR while running 3.5x faster.
• You need many streams per box: 7 concurrent 30-FPS cameras on one iGPU against RF-DETR’s 2.
• Your training budget is tight. 11.6x faster training, 3.8x less GPU memory. Worth it for rapid iteration even if you eventually re-train with RF-DETR for the final model.
• You’re targeting OpenVINO or similar optimized runtimes (YOLO-NAS reaches 215 FPS on an integrated GPU).

Quick decision table

If your constraint is…	Pick
Best possible COCO mAP	RF-DETR
Tightest bounding boxes	RF-DETR
Highest FPS on dGPU	YOLO-NAS
Intel iGPU deployment	YOLO-NAS
CPU-only deployment	YOLO-NAS
INT8 quantized inference	YOLO-NAS
Most 30-FPS streams per box	YOLO-NAS (7 vs 2)
Fine-tuning on an 8GB-or-smaller GPU	YOLO-NAS
Fast iteration on custom data	YOLO-NAS (11.6x faster training)
Best custom-data accuracy	RF-DETR (+30% mAP@0.50 after fine-tuning)
Real-time video (>60 FPS) on modest hardware	YOLO-NAS
Sub-real-time is fine, want max mAP	RF-DETR
Commercial product on pretrained weights	RF-DETR (Apache-2.0)

---

The Framework Behind This Benchmark

modern-yolonas: YOLO-NAS Training & Inference

All YOLO-NAS inference and fine-tuning in this article runs on modern-yolonas v0.3.0, a clean reimplementation of the YOLO-NAS architecture [4]. The design goals:

• Modern Python only: Built for Python 3.13+. No six-year-old dependency pins to work around.
• No super-gradients: Compatible with Deci AI’s pretrained weights, but without the heavy dependency tree. pip install finishes in seconds.
• Complete training pipeline: PPYoloE loss, Task-Aligned Assignment, EMA, mixed precision, cosine LR scheduling.
• Minimal inference API: One-line model loading, one-line prediction.

from modern_yolonas import Detector

det = Detector("yolo_nas_s", device="cuda", input_size=256)
result = det("image.jpg")
# result.boxes   -> (N, 4) xyxy
# result.scores  -> (N,)
# result.class_ids -> (N,) COCO-80 indices

For RF-DETR, the official rfdetr package (v1.6.4) is used:

from rfdetr import RFDETRNano
import numpy as np
from PIL import Image

model = RFDETRNano(resolution=256, device="cuda")
img = np.array(Image.open("image.jpg").convert("RGB"))  # rfdetr needs RGB
detections = model.predict(img, threshold=0.05)
# detections.xyxy, detections.class_id, detections.confidence

The companion repository has reproduction scripts for every number in this article. Just uv sync and run.

---

What should I benchmark next?

This harness — one evaluation protocol, three devices, FP32/FP16/INT8, and a fine-tune on top — is reusable, and I would rather point it at something you actually need than at whatever is trending this month. Two questions:

---

Limitations & scope

Read the verdict inside these bounds:

• Evaluation is on 500 COCO-val images [6], not the full 5k set. It’s enough to separate models whose mAP differs by tens of percent, but treat the third decimal as noise, and these are COCO-pretrained weights, not your domain.
• Latency is single-image, batch-1, with 5-warmup discarded, and it includes image decode and preprocessing. Batched throughput, longer thermal soak, and other concurrent load on the laptop would all shift the absolute numbers; lean on the same-device ratios.
• These are cold, average-latency numbers. I did not run sustained load. On a laptop-class Iris Xe the thermal envelope is not a footnote: twenty minutes into a real workload the clocks drop, and the number that decides your deployment is p99 under heat, not the average over the first thirty seconds. I also did not measure power draw, which is what actually decides a fanless design. Both are the subject of a follow-up.
• The cost-per-stream table is arithmetic, not a measurement. I never ran seven concurrent streams and I never ran a mini PC. The caveats in that section are part of the result.
• Package versions move. This ran in May 2026 against rfdetr 1.6.4. Since then 1.7.x has added L/XL/2XL detection checkpoints and a full Nano-to-2XL segmentation range, moved the Plus models into a separate rfdetr_plus package under the Roboflow Model License rather than Apache 2.0, and fixed bugs in BF16 mixed-precision training, checkpoint loading, and NumPy 2.x compatibility. The Nano results here stand, but pip install today does not give you the package I tested.
• One machine, one driver stack. Iris Xe via OpenVINO 2026.0.0, RTX 3060, a 12700H. A different OpenVINO release, GPU plugin, or CPU can move both the FPS and the INT8 retention.
• INT8 used default PTQ calibration. RF-DETR’s 21% mAP drop is what it costs to quantize a non-quantization-aware transformer with stock settings, on one configuration. I did not try a larger or better-matched calibration set, mixed-precision quantization, or QAT, and any of those could narrow it — we explore exactly that in the segmentation sequel. Read the 21% as what you get out of the box, not as a property of the architecture.
• The fine-tune is a 200-image toy set. It demonstrates transfer and training cost, not production accuracy.

Conclusion

The object detection landscape is not a single leaderboard. Across two resolutions and three compute targets, the trade-off between RF-DETR and YOLO-NAS is consistent and sharp: RF-DETR wins accuracy, YOLO-NAS wins latency and efficiency. Neither model dominates the other; they sit on different points of the Pareto frontier.

What the data retires, though, is the idea that one model becomes the “right” choice at low resolution. Both models scale with resolution in the same direction, and the accuracy gap never closes in floating-point. If you can afford RF-DETR’s latency, it’s the accuracy leader everywhere in FP32/FP16. If you can’t, because you’re on an iGPU, a CPU, an ARM board, or you need INT8, YOLO-NAS offers a practical, quantizable, cheaply-trainable alternative that reaches 215 FPS on integrated graphics.

The most striking single number in this entire benchmark is that the PyTorch accuracy gap between these two models collapses to zero under INT8 quantization, not because RF-DETR gets smaller but because YOLO-NAS barely moves. An Intel laptop chip, running a well-implemented and INT8-quantized CNN through OpenVINO, gets you tied-accuracy, 3.5x-faster inference than a non-quantization-friendly transformer on the same device. The model choice matters more than the hardware choice.

Why these two, and what their licences let you do

I picked these two architectures because they are the ones I reach for most in my own work, and because both have open source code you can read, patch and ship. That matters more than it sounds. There is no shortage of strong detectors, but plenty of them arrive with a commercial licence attached, and for a small company or a side project that licence is often what ends the conversation long before anyone gets to the accuracy numbers.

Open source code is not the same thing as open weights, though, and this pair is a good lesson in the difference:

	Code	Pretrained COCO weights
RF-DETR Nano	Apache-2.0	Apache-2.0
YOLO-NAS-S	Apache-2.0 (super-gradients)	Super Gradients Model EULA, non-commercial

RF-DETR Nano is Apache-2.0 the whole way down, so you can ship it. YOLO-NAS’s code is Apache-2.0 and always was, but the pretrained COCO weights are under Deci’s Model EULA and are licensed for non-commercial use only. My own modern-yolonas reimplementation is MIT, and that changes nothing about the weights it loads: a permissive licence on the code that reads a checkpoint does not relicense the checkpoint. If you want YOLO-NAS in a commercial product, you train it yourself on data you’re allowed to use. That trap, and how to check for it in any model you’re evaluating, is the subject of the modern-yolonas post.

---

All benchmark code, scripts, and raw logs are available in the companion repository. YOLO-NAS training and inference powered by modern-yolonas.

---

Correction log

9 August 2026 — the PyTorch YOLO-NAS mAP numbers were too low.

The original version of this post understated YOLO-NAS-S accuracy in the PyTorch results. modern-yolonas was feeding the network OpenCV’s BGR channel order while the pretrained weights expect RGB, which cost about 6.4 mAP points at these resolutions. The bug is fixed, and the PyTorch tables above have been re-measured with the same protocol (same 500-sample COCO subset, threshold 0.05, FiftyOne COCO eval).

	was	now
YOLO-NAS-S mAP @256	0.310	0.3735
YOLO-NAS-S mAP @384	0.391	0.4560
RF-DETR’s relative accuracy lead	+41% / +29%	+17% / +11%

RF-DETR still wins on accuracy, but by roughly half of what I originally reported. What did not change: every latency, FPS, memory and training-time figure (channel order has no effect on timing), and every OpenVINO/iGPU and fine-tuning number — those pipelines did their own RGB conversion and were correct all along. The INT8 findings therefore stand as published.

Independent confirmation that the fix is right: on the full 5,000-image COCO val2017 set, the corrected pipeline scores 0.4761 mAP against the published YOLO-NAS-S reference of 47.5. The old BGR path scored 0.4420.

How I found it, and why a deterministic pipeline can still be wrong, is written up in the modern-yolonas deep dive.

Also removed in that pass: a “Why Resolution Matters: CNN vs Transformer” figure carrying mAP values (0.418 / 0.413 for YOLO-NAS, 0.389 / 0.459 for RF-DETR) that appeared in no table in this post, and that claimed YOLO-NAS is flat across resolution while RF-DETR degrades, the opposite of what the measurements show. It was wrong before this correction and unrelated to the channel-order bug. Better no figure than a figure that argues against its own article.

16 August 2026 — version, range, and reproducibility fixes.

• The setup table said OpenVINO “2024.x”. The version pinned in the companion repo’s lockfile has been 2026.0.0 since April 2026; the Limitations section and the further-reading link now say so too.
• The TL;DR said YOLO-NAS is “1.6–1.7x faster”. At 384 on CPU it is 1.8x (106.4ms vs 59.2ms), so the range now reads 1.6–1.8x.
• modern-yolonas was listed as an editable checkout, which pins nothing. It is now v0.3.0, a tagged release that contains the channel-order fix above.
• Added this revision: measured parameter and FLOP counts, the 500-image subset fingerprint, the cost-per-stream section, and the concept glossary in The Models.

17 August 2026 — the published code could not reproduce the published numbers.

No figure in this post changes. What changed is that the companion repo now actually produces them.

benchmark.py took a --threshold and passed it to RF-DETR’s predict() while dropping it for YOLO-NAS, which fell back to modern-yolonas’s default conf_threshold=0.25. So the two models were being compared at different operating points, and one of them sat at a threshold this very section warns against. Anyone who cloned the repo and ran it as documented got 0.3533 at 256 and 0.4340 at 384 for YOLO-NAS, roughly 5% under the tables above, and would have been right to conclude the post was wrong.

The tables are correct. They come from the 9 August re-measurement, which applied 0.05 properly, and the sweep in Benchmark Setup confirms it: at 0.05 YOLO-NAS-S scores 0.3735 and 0.4560, matching the published figures to the fourth decimal, and at 0.25 it scores 0.3532 and 0.4339, matching what the broken harness produced. Two thresholds, four numbers, no ambiguity about which is which.

The bug never touched the other results. benchmark_openvino.py applies the threshold in its own postprocessing and the fine-tuning scripts pass it through, so Results 3 and 4 were always evaluated at 0.05 as stated. It is also older than the channel-order bug: every commit that has ever touched benchmark.py carried it, which means the original May tables were wrong twice over — BGR input and a 0.25 threshold. The August correction fixed both and only noticed one.

I am leaving this in the post rather than quietly patching the repo, because “the numbers are right but the code that made them was not published” is exactly the failure a reproducibility section is supposed to catch, and it went unnoticed through a correction pass that was itself about a measurement bug.

Further reading

• Go deeper: Szeliski, Computer Vision (2nd ed.) §6.3 (Object detection) for the detection side; for quantization, the OpenVINO NNCF post-training quantization guide.
• The DETR line of work: Carion et al. [9] for why set prediction removes NMS, then Zhu et al. [10] for the deformable attention that made the idea fast enough to matter. Read them in that order; the second only makes sense as a fix for the first.
• The tooling: OpenVINO + NNCF, the INT8 export/quantization path used here.
• Related on CondadosAI: the segmentation sequel, YOLO26-seg vs RF-DETR-Seg on an iGPU; the YOLO-NAS internals and its licence trap in YOLO-NAS without super-gradients; read the numbers via object-detection metrics.

References

[1] Robinson, I., Robicheaux, P., Popov, M., Ramanan, D., & Peri, N. (2026). RF-DETR: Neural Architecture Search for Real-Time Detection Transformers. International Conference on Learning Representations (ICLR), 2026. Preprint arXiv:2511.09554 (2025). GitHub.

[2] Deci AI. (2023). YOLO-NAS: A Next-Generation Object Detection Foundation Model. Deci Blog. GitHub (super-gradients).

[3] Terven, J., & Cordova-Esparza, D. (2023). A Comprehensive Review of YOLO Architectures in Computer Vision: From YOLOv1 to YOLOv8 and YOLO-NAS. arXiv:2304.00501. (YOLO-NAS architecture diagram source.)

[4] Condados AI. (2025). modern-yolonas: A clean, modern reimplementation of YOLO-NAS, v0.3.0. GitHub.

[5] Szeliski, R. (2022). Computer Vision: Algorithms and Applications (2nd ed.), §6.3 (Object detection). Springer. Free PDF.

[6] Lin, T.-Y., et al. (2014). Microsoft COCO: Common Objects in Context. ECCV. arXiv:1405.0312. (Evaluation dataset.)

[7] Oquab, M., et al. (2023). DINOv2: Learning Robust Visual Features without Supervision. Transactions on Machine Learning Research. arXiv:2304.07193. (RF-DETR backbone.)

[8] Intel. OpenVINO Toolkit Documentation (2026.0) and NNCF (Neural Network Compression Framework) 3.0.0. Docs. Eval harness: FiftyOne 1.13.4.

[9] Carion, N., Massa, F., Synnaeve, G., Usunier, N., Kirillov, A., & Zagoruyko, S. (2020). End-to-End Object Detection with Transformers. ECCV. arXiv:2005.12872. (Set prediction, and why DETR needs no NMS.)

[10] Zhu, X., Su, W., Lu, L., Li, B., Wang, X., & Dai, J. (2021). Deformable DETR: Deformable Transformers for End-to-End Object Detection. International Conference on Learning Representations (ICLR), 2021. arXiv:2010.04159. (The deformable decoder RF-DETR builds on.)

[11] Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, L., & Polosukhin, I. (2017). Attention Is All You Need. NeurIPS. arXiv:1706.03762. (Where the encoder-decoder split comes from.)

[12] Elsken, T., Metzen, J. H., & Hutter, F. (2019). Neural Architecture Search: A Survey. Journal of Machine Learning Research, 20(55), 1-21. arXiv:1808.05377. (What NAS is, and how candidate architectures get scored.)