---
title: YOLOX vs RF-DETR: which object detector should you train?
description: A practical decision guide for choosing between YOLOX and RF-DETR object detection in Pictograph - speed and edge deployment vs accuracy on hard, crowded scenes. Both train from the same export in one call.
section: Guides
order: 5
---
Pictograph trains two object detectors from the same annotated dataset: **YOLOX** and
**RF-DETR**. They solve the same task - boxes around objects - but they make opposite
trade-offs, and the right choice depends on where the model runs and how hard your images
are.

The short version: **reach for YOLOX when speed and a small footprint matter, and
RF-DETR when accuracy on crowded or cluttered scenes matters.** Both train from a
completed export in one `client.training.create(...)` call, so you can train both on the
same data and compare.

## Pick in one table

| If you care most about... | Train | Why |
| --- | --- | --- |
| Real-time or edge inference | `yolox` | A compact CNN with a decoupled head; fast and small to deploy |
| A small or clean dataset | `yolox` | Converges quickly and rarely overfits on a few hundred images |
| Accuracy on crowded / cluttered scenes | `rfdetr_detection` | A transformer that reasons globally and needs no NMS to separate overlaps |
| Many overlapping instances | `rfdetr_detection` | Set-based prediction avoids the duplicate-box merging YOLOX leans on |
| The lowest possible cost per run | `yolox` | Fewer GPU-seconds to a usable model |

## YOLOX: fast, small, forgiving

YOLOX is an anchor-free member of the YOLO family. It is a convolutional detector with a
decoupled classification and box head, and it predicts a dense grid of candidate boxes
that non-maximum suppression (NMS) then merges. That design makes it **fast to run and
cheap to train**, and it exports to a compact ONNX graph that serves well on modest
hardware.

Choose YOLOX when:

- The model has to run in real time, on an edge device, or inside a
  [deployment](/docs/deployments.md) where latency and footprint matter.
- Your dataset is small or visually clean - a few hundred images of well-separated objects.
- You want the cheapest path to a working detector to validate an idea.

```python
from pictograph import Client, TrainingRun

client = Client()

client.exports.create(
    dataset_name="road-signs",
    name="road-signs-v1",
    format="pictograph",
    include_images=True,
    wait=True,
)

run: TrainingRun = client.training.create(
    dataset_name="road-signs",
    export_name="road-signs-v1",
    pipeline_type="yolox",
    name="road-signs-yolox",
    gpu_type="a10g",
    config={"epochs": 50, "batch_size": 16, "image_size": 640},
)
print(run.metrics.get("mAP"))
```

## RF-DETR: accurate on hard data

RF-DETR is a real-time DETR - a transformer detector that predicts a fixed set of objects
directly, with **no anchors and no NMS**. Because it reasons over the whole image at once,
it separates overlapping and densely packed objects more cleanly than a grid-and-NMS
detector, and it tends to reach a **higher mAP than YOLOX on harder data**. That accuracy
costs more compute per image and usually wants more data to shine.

Choose RF-DETR (`rfdetr_detection`) when:

- Scenes are crowded, cluttered, or full of overlapping instances - retail shelves,
  traffic, aerial imagery, waste sorting (see the public
  [TACO trash dataset](/datasets/pictograph-research/taco)).
- Accuracy matters more than milliseconds, and inference runs on a GPU
  [deployment](/docs/deployments.md) rather than an edge device.
- You have enough labeled data (auto-label a directory fast with
  [SAM3](/docs/sam3-auto-annotation.md) if you do not).

```python
run = client.training.create(
    dataset_name="street-scenes",
    export_name="street-scenes-v1",
    pipeline_type="rfdetr_detection",
    name="street-scenes-rfdetr",
    gpu_type="a10g",
    config={"epochs": 50, "batch_size": 8},
)
print(run.metrics.get("mAP"))
```

RF-DETR is heavier than YOLOX, so raise `gpu_type` to `a100` for large images or big batch
sizes, or pass `auto` to let the platform pick the cheapest tier your config fits.

Both report accuracy as **mAP**, so a run of each on the same export is directly
comparable - train both, read `run.metrics["mAP"]`, and keep the winner. A good starting
dataset is the public [COCO 5k](/datasets/pictograph-research/coco-5k) detection set.

## Beyond boxes

The choice only matters for plain detection. If your task is more than boxes, the pipeline
is already decided:

- **Instance masks** (polygons per object) - `rfdetr_segmentation`.
- **Keypoints / pose** (a joint set per object) - `rfdetr_keypoint`; see
  [keypoint training](/docs/guides/train#keypoint-pose-training).
- **Pixel-wise class maps** (no instances) - `sm_pytorch` semantic segmentation.
- **Whole-image labels** (no geometry) - `classification`.

There is no YOLOX equivalent for masks or keypoints in Pictograph, so segmentation and
pose always run on the RF-DETR family.

## Cost and speed

Training is [billed by the GPU-second](/pricing) while it runs, charged only when the run
succeeds. YOLOX reaches a usable model in fewer seconds than RF-DETR on the same data, so
it is the cheaper run; RF-DETR trades that for accuracy. Neither charges up front, and you
see an estimated cost before you start, so training one of each to compare is inexpensive.

At inference time the same ordering holds: YOLOX is the lighter, faster model to serve,
and RF-DETR is the more accurate one. If you are unsure, train YOLOX first for a fast
baseline, then train RF-DETR on the same export and keep whichever mAP you prefer.

## See also

- [Train a model](/docs/guides/train.md) - the full training call, GPU tiers, and hyperparameters
- [SAM3 auto-annotation](/docs/sam3-auto-annotation.md) - label a dataset fast before you train
- [Local inference](/docs/local-inference.md) - run the trained ONNX model on your own machine
- [Deployments](/docs/deployments.md) - serve the model behind one authenticated URL
- [Pricing](/pricing) - what a training run and an inference deployment cost