← Back to list

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.

Luís Condados in LatinXinAI · 2026-05-29 13:57 · 2 claps · 12.1 min read
#computer-vision #ai #openvino #rf-detr #opencv
Open on Medium ↗
Wiki topics: EVAL · Evaluation & Benchmarks OPS · LLMOps & Inference AI · AI · General

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

RF-DETR (LEFT) x YOLO-NAS-S (RIGHT)

RF-DETR (LEFT) x YOLO-NAS-S (RIGHT)

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 — maintain a single, consistent evaluation methodology across all runs 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. Modern-yolonas, a clean reimplementation of the YOLO-NAS architecture with a modern training pipeline, powers YOLO-NAS training and inference.

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 a GPU, you can pick the resolution that maximizes accuracy.

Intel Iris Xe iGPU via OpenVINO: YOLO-NAS hits 151 FPS at FP32 and 215 FPS at INT, 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.

RF-DETR Architecture — ViT backbone extracts multi-scale features, passed through a projector to deformable cross-attention decoder groups with query embeddings. Source: Robinson et al., 2025.

RF-DETR Architecture — ViT backbone extracts multi-scale features, passed through a projector to deformable cross-attention decoder groups with query embeddings. Source: Robinson et al., 2025.

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¹⁴ possible configurations to maximize the accuracy-latency Pareto frontier.

YOLO-NAS Architecture, Backbone with 4 stages feeds into an FPN-style neck (up/down stages) with three detection heads. QSP and QCI blocks built from QA-RepVGG enable efficient INT8 quantization. Source: Terven et al., 2023.

YOLO-NAS Architecture, Backbone with 4 stages feeds into an FPN-style neck (up/down stages) with three detection heads. QSP and QCI blocks built from QA-RepVGG enable efficient INT8 quantization. Source: Terven et al., 2023.

Feature · RF-DETR Nano · YOLO-NAS-S

Feature · RF-DETR Nano · YOLO-NAS-S

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

Parameter · Value

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

Model · Device · mAP · Avg (ms) · FPS

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. An agreement this tight means the evaluation pipeline is deterministic and reproducible.

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

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

Model · mAP @256 · mAP @384 · Relative Δ

Model · mAP @256 · mAP @384 · Relative Δ

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 the GPU, using the higher resolution is 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 and problem domain constraints. Consider the relative size of your target subject. Would it be visible enough on the input resolution?

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

Model · Precision · mAP · Avg (ms) · FPS

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

Model · FP32 mAP · INT8 mAP · Δ mAP · FPS gain

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 the same 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

Configuration · mAP · FPS

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 were 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

Metric · RF-DETR Nano · YOLO-NAS-S

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

Model · mAP@0.50 · mAP@0.50:0.95 · FPS

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.

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 GP; 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

If your constraint is… · Pick

The Framework Behind This Benchmark:

modern-yolonas; YOLO-NAS Training & Inference

[embed]GitHub - CondadosAI/modern-yolonas: Modern re-implementation of the famous YOLO-NAS model Modern re-implementation of the famous YOLO-NAS model - CondadosAI/modern-yolonasgithub.com

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:

[embed]GitHub - roboflow/rf-detr: RF-DETR is a real-time object detection and segmentation model… RF-DETR is a real-time object detection and segmentation model architecture developed by Roboflow, SOTA on COCO…github.com

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.

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 on accuracy, while YOLO-NAS wins on latency and efficiency. Neither model dominates the other; they sit on different points of the Pareto frontier.

What the data reveals, 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.

Side-by-side detection comparison on COCO validation images at 256x256. RF-DETR Nano (left) vs YOLO-NAS-S (right) with FPS overlay.

Side-by-side detection comparison on COCO validation images at 256x256. RF-DETR Nano (left) vs YOLO-NAS-S (right) with FPS overlay.

💡 Found this useful? Clap, share, and leave a comment!

#IntelSoftwareInnovator #openvino #RFDETR #INT8Quantization #IntelGPU #ModelConversion #EdgeAI #DeepLearning #MachineLearning #AIAtTheEdge #IntelSoftwareInnovator #ComputerVision #PyTorch

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


메타데이터
post_id
852ff98eee3d
slug
rf-detr-vs-yolo-nas-a-practical-benchmark-for-edge-deployment-cpu-gpu-and-intel-igpu-compared-852ff98eee3d
url
https://medium.com/@condadoslgpc/rf-detr-vs-yolo-nas-a-practical-benchmark-for-edge-deployment-cpu-gpu-and-intel-igpu-compared-852ff98eee3d
canonical_url
https://medium.com/@condadoslgpc/rf-detr-vs-yolo-nas-a-practical-benchmark-for-edge-deployment-cpu-gpu-and-intel-igpu-compared-852ff98eee3d
author_url
https://medium.com/@condadoslgpc
status
ok
fetched_at
2026-06-09 15:37:30