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.

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.

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.

---

TL;DR

• Accuracy (COCO mAP, PyTorch): RF-DETR wins at every resolution tested. At 256x256 it beats YOLO-NAS by +41% relative mAP (0.437 vs 0.310). At 384x384 the gap narrows slightly to +29% (0.506 vs 0.391), but RF-DETR still wins.
• Latency (PyTorch): YOLO-NAS is 1.6–1.7x faster than RF-DETR on both CPU and CUDA at every tested resolution.
• 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.

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 with a lightweight deformable DETR decoder. The model is NMS-free (it uses set prediction), and its self-supervised pretraining gives it strong feature representations out of the box. RF-DETR also incorporates Neural Architecture Search to discover optimal encoder-decoder configurations for different latency targets.

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 specifically designed for efficient hardware utilization and INT8 quantization compatibility. The architecture uses two specialized modules — QSP (Quantization Shortcut Path) and QCI (Quantization-Compatible Inference) blocks — built from QA-RepVGG, and an anchor-free detection head with Distribution Focal Loss (DFL). The NAS process explored over 10^14 possible configurations to maximize the accuracy-latency Pareto frontier.

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)
Inference library	rfdetr v1.6.4	modern-yolonas

---

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
Dataset	COCO-2017 Validation, 500 samples
Evaluation	FiftyOne COCO mAP (pycocotools-compatible, IoU 0.5:0.05:0.95)
Resolutions	256x256 and 384x384 (both models, square input)
Confidence threshold	0.05 (low — critical for correct mAP PR-curve coverage)
Warmup	5 inferences discarded before timing
Batch size	1 (single-image inference, typical for real-time deployment)
RF-DETR runtime	PyTorch 2.10 (cu130), rfdetr 1.6.4
YOLO-NAS runtime	PyTorch 2.10 (cu130), modern-yolonas (editable)
OpenVINO	2024.x on Intel Iris Xe (device GPU.0)
CPU	12th Gen Intel Core i7-12700H
dGPU	NVIDIA GeForce RTX 3060 Laptop
iGPU	Intel Iris Xe Graphics

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.

---

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.310	38.4	26.1
RFDETRNano 256	CUDA	0.437	17.4	57.6
YOLO-NAS-S 256	CUDA	0.310	10.6	94.3

RF-DETR beats YOLO-NAS by +41% relative mAP (0.437 vs 0.310). That gap is large — far beyond any noise margin you’d get from a 500-sample eval. The DINOv2 backbone’s self-supervised pretraining gives RF-DETR a clear 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. CNN forward passes are still cheaper than attention at this scale, and YOLO-NAS’s architecture was explicitly NAS-searched to minimize latency.

Observation: CPU and CUDA mAP match to within 0.0001 (0.4366 vs 0.4367 for RF-DETR; 0.3098 vs 0.3097 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.

---

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.391	59.2	16.9
RFDETRNano 384	CUDA	0.506	17.8	56.2
YOLO-NAS-S 384	CUDA	0.391	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.310	0.391	+26%

Two surprises here:

1. YOLO-NAS gains more from higher resolution than RF-DETR. The popular narrative — that transformers need high resolution, 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). The reason: on a 3060, the GPU finishes the forward pass long before it saturates; what’s left is preprocessing, decoder work, and host/device round-trips, which don’t scale with resolution. On GPU, use the higher resolution — it’s essentially free. On CPU, the story flips: 384 costs ~1.6x more time than 256 because CPU compute does scale with pixel count.

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 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).

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 +41% 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%

This gap is architectural, not accidental. YOLO-NAS was explicitly built for quantization from day one. Its QA-RepVGG (Quantization-Aware RepVGG) blocks were designed to maintain accuracy under INT8 post-training quantization. The QSP (Quantization Shortcut Path) and QCI (Quantization-Compatible Inference) 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 the expected cost of quantizing an architecture that was optimized purely for floating-point accuracy.

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 — 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.

---

Result 4: Fine-Tuning on a Custom Dataset

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 — 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 — 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 — 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).

Choose YOLO-NAS-S when:

• Latency is the top priority and the +29–41% 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.
• 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
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

---

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 — a clean reimplementation of the YOLO-NAS architecture. 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.

---

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. Batched throughput, longer thermal soak, and other concurrent load on the laptop would all shift the absolute numbers; lean on the same-device ratios.
• One machine, one driver stack. Iris Xe via OpenVINO 2024.x, 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 the cost of quantizing a non-quantization-aware transformer with stock settings; QAT or a transformer-aware preset could narrow it (we explore exactly that in the segmentation sequel).
• 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.

---

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

---

Further reading

• Go deeper: Szeliski, Computer Vision (2nd ed.) §6.3 (detection) and §5.5.4 (quantization for deployment).
• 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; read the numbers via object-detection metrics.

References

[1] Robinson, I., Robicheaux, P., Popov, M., Ramanan, D., & Peri, N. (2025). RF-DETR: Neural Architecture Search for Real-Time Detection Transformers. International Conference on Learning Representations (ICLR), 2026. arXiv:2511.09554. 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., & Romero-Gonzalez, J. (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. GitHub.

[5] Szeliski, R. (2022). Computer Vision: Algorithms and Applications (2nd ed.), §6.3 (object detection) & §5.5.4 (quantization for deployment). 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 and NNCF (Neural Network Compression Framework). Docs. Eval harness: FiftyOne.