YOLO versions compared

Setup#

pip install ultralytics torch

The snippets below were run against ultralytics 8.3.40 and torch 2.5.1. That package version ships configs up to YOLO11 and YOLOv10. YOLO26 and YOLOv12 need a newer ultralytics release. The inspection below covers the models this pinned version can build. Everything runs on CPU and nothing is downloaded.

What each generation's head actually outputs#

import torch
import torch.nn.functional as F
from torchvision.ops import nms

# --- 1. How many candidate boxes each generation of head produces at 640x640.
old = sum(s * s * 3 * (5 + 80) for s in (80, 40, 20))     # v3/v5: 3 anchors, 4 box + 1 objectness + 80 classes
new = sum(s * s * (4 * 16 + 80) for s in (80, 40, 20))    # v8 onward: no anchors, 16-bin box sides
print(f"anchor-based head (v3/v5 style): {old:>9,} numbers, {(80*80+40*40+20*20)*3:>6,} candidate boxes")
print(f"anchor-free head  (v8 style)   : {new:>9,} numbers, {80*80+40*40+20*20:>6,} candidate boxes")

# --- 2. One box side, predicted as a 16-bin distribution, then integrated (DFL).
logits = torch.tensor([0., 0., 0., 0., 0., 1., 4., 6., 4., 1., 0., 0., 0., 0., 0., 0.])
p = F.softmax(logits, dim=0)
bins = torch.arange(16, dtype=torch.float32)
distance = (p * bins).sum()
print("\none side of one box as a 16-bin distribution:")
print("  probabilities:", [round(v, 3) for v in p.tolist()])
print(f"  peak bin {p.argmax().item()}, expected value {distance:.3f} cells")
print(f"  at stride 8 that is {distance * 8:.1f} pixels from the cell centre")

# --- 3. Anchor-free decode: four distances from the cell centre to the four edges.
cx, cy, stride = 12.5, 7.5, 8.0
left, top, right, bottom = 2.0, 3.5, 4.0, 6.5
box = torch.tensor([(cx - left) * stride, (cy - top) * stride,
                    (cx + right) * stride, (cy + bottom) * stride])
print("\ndecoded box in image pixels:", [round(v, 1) for v in box.tolist()])

# --- 4. Why v10 and YOLO26 can drop NMS: one-to-one assignment during training.
boxes = torch.tensor([[100., 100., 200., 200.],
                      [ 98., 104., 205., 198.],
                      [104., 102., 196., 203.],
                      [ 96.,  99., 202., 201.]])
one_to_many = torch.tensor([0.90, 0.86, 0.83, 0.79])
one_to_one = torch.tensor([0.91, 0.04, 0.03, 0.02])
print(f"\none-to-many head, above 0.25 before NMS: {(one_to_many > 0.25).sum().item()} boxes")
print(f"one-to-many head, after NMS            : {nms(boxes, one_to_many, 0.5).numel()} boxes")
print(f"one-to-one head, above 0.25, no NMS    : {(one_to_one > 0.25).sum().item()} boxes")

anchor-based head (v3/v5 style): 2,142,000 numbers, 25,200 candidate boxes
anchor-free head  (v8 style)   : 1,209,600 numbers,  8,400 candidate boxes

one side of one box as a 16-bin distribution:
  probabilities: [0.002, 0.002, 0.002, 0.002, 0.002, 0.005, 0.103, 0.763, 0.103, 0.005, 0.002, 0.002, 0.002, 0.002, 0.002, 0.002]
  peak bin 7, expected value 7.015 cells
  at stride 8 that is 56.1 pixels from the cell centre

decoded box in image pixels: [84.0, 32.0, 132.0, 112.0]

one-to-many head, above 0.25 before NMS: 4 boxes
one-to-many head, after NMS            : 1 boxes
one-to-one head, above 0.25, no NMS    : 1 boxes

Reading that output#

Dropping anchors cut candidate boxes from 25,200 to 8,400. Three anchors per cell became one prediction per cell. Fewer candidates means a cheaper NMS step and fewer negatives to drown the loss.

The 16-bin distribution is the piece most people have never looked at. Since YOLOv8, each of the four box sides is a distribution over 16 discrete distances. It is not a single number. The final value is the expected value of that distribution, 7.015 here from a peak at bin 7.

This is Distribution Focal Loss, from the Generalized Focal Loss paper. It buys two things. A blurry or occluded edge produces a wide distribution rather than a confidently wrong number. The softmax also gives sub-cell precision, with no separate refinement stage. It costs 64 output channels per cell instead of 4.

YOLO26 removes DFL again. The argument is that the extra channels cost more at export time than they return, especially on integer-quantised edge hardware.

The one-to-one comparison is the end-to-end story. Four overlapping boxes above threshold need NMS to become one. A one-to-one trained head puts almost all its confidence on a single cell, so the output is already clean. The saving is not only average latency; it is that latency stops depending on how crowded the frame is.

Inspecting the real architectures#

import ultralytics
from ultralytics import YOLO

print("ultralytics", ultralytics.__version__)
for cfg in ["yolov8n.yaml", "yolov9t.yaml", "yolov10n.yaml", "yolo11n.yaml"]:
    m = YOLO(cfg)                      # builds from config; no weights are downloaded
    head = m.model.model[-1]
    n = sum(p.numel() for p in m.model.parameters())
    one2one = hasattr(head, "one2one_cv2")
    print(f"{cfg:<14} head={type(head).__name__:<10} params={n:>9,}"
          f"  reg_max={head.reg_max}  end2end={head.end2end}  one-to-one branch={one2one}")

ultralytics 8.3.40
yolov8n.yaml   head=Detect     params=3,157,200  reg_max=16  end2end=False  one-to-one branch=False
yolov9t.yaml   head=Detect     params=2,128,720  reg_max=16  end2end=False  one-to-one branch=False
yolov10n.yaml  head=v10Detect  params=2,775,520  reg_max=16  end2end=True  one-to-one branch=True
yolo11n.yaml   head=Detect     params=2,624,080  reg_max=16  end2end=False  one-to-one branch=False

Three real facts fall out of that, none of which you would get from a benchmark table.

reg_max=16 is identical across all four. The distribution-based box representation has been stable since v8.

Only yolov10n reports end2end=True and carries a one2one_cv2 branch. That extra branch is the architectural difference behind the NMS-free claim. v10 trains two heads. A one-to-many head gives rich gradients, and a one-to-one head is used at inference.

YOLO11n has fewer parameters than YOLOv8n (2.62M against 3.16M). Smaller is a design goal in this family, not an accident.

One warning about this package. ultralytics also ships yolov3.yaml and yolov5.yaml, but they are re-implementations built with the modern anchor-free Detect head. Building them and reporting "YOLOv5 is anchor-free" would be wrong. The original v3 and v5 are anchor-based. Do not use these configs as evidence about the original models.

The family, and what each release actually changed#

Ultralytics documents YOLO26 as released in January 2026. It is natively end-to-end with no NMS, and Distribution Focal Loss is removed. The release also adds a progressive loss schedule, small-target-aware label assignment and a hybrid optimiser. Their published COCO table lists YOLO26n at 40.9 mAP and YOLO26x at 57.5 mAP, measured on a T4 with TensorRT.

Treat every vendor table, including that one, as a claim measured under a specific recipe on one dataset. It is not a prediction about your data.

Choosing a version, honestly#

Ask these in order.

What is the licence? Ultralytics YOLO models are AGPL-3.0 with a paid commercial option. YOLOX and RTMDet are Apache-2.0 and MIT respectively. RF-DETR is Apache-2.0. If your product ships to customers, this question outranks accuracy.

What runs on your hardware? An export path that works beats two extra mAP points. Test ONNX or TensorRT export early, not at the end.

Does end-to-end help you? If you process video with tight latency budgets, an NMS-free model gives you steadier frame times. If you run batch jobs, it changes little.

Have you measured on your own data? Train two candidates for a short schedule on your dataset and compare. Published COCO numbers rank models on 80 everyday classes at moderate resolution. That may have nothing to do with cracks on a weld.

Common mistakes#

Believing a version number is a ranking. YOLOv9, v10 and v12 came from three different groups. They are not sequential improvements on one codebase.

Comparing at different input sizes. A model at 1280 will beat the same model at 640 on small objects and be four times slower. Fix the resolution before comparing anything.

Comparing PyTorch latency to TensorRT latency. Published speed tables are usually exported and half-precision. Your unexported PyTorch loop is not the same measurement.

Ignoring the licence until launch. This is the single most expensive mistake in this list.

Skipping the export test. Some architectures export cleanly to ONNX, some need work. Find out on day one.

Try it yourself#

Build yolov10n.yaml and yolo11n.yaml, and print head.one2one_cv2 for the one that has it. Then count how many output tensors each head returns in eval mode. That difference is the whole NMS-free mechanism, visible in ten lines of code.

What to learn next#

• Anchor-free detection — the head design every modern YOLO uses.
• Focal loss and RetinaNet — the loss family DFL grew out of.
• YOLO — running one end to end on a real image.