YOLO Evolution: A Comprehensive Benchmark and Architectural Review of YOLOv12, YOLO11, and Their Previous Versions

In plain words

YOLO is a family of fast object detectors: one network looks at a picture once and reports what objects are where. Over several years the family grew many versions and sizes, and the newest versions had not yet been measured across the whole family on the same data with the same settings. This paper takes the models that the Ultralytics library offers, from the oldest version to the newest, trains each one on three different image collections using identical settings, and measures how accurate each one is and how long it takes to run.

The three collections were picked to differ from each other: traffic signs, wildlife in Africa, and ships. They differ in object size, aspect ratio, rotation and overlap. Because every model gets the same training settings, the results compare the models themselves rather than how well each one was tuned. The main findings are that the YOLO11 models give the best mix of accuracy and speed, and that YOLOv12 is slower without being clearly more accurate.

TL;DR

• This is a benchmark, not a new architecture: 33 Ultralytics checkpoints from 7 YOLO versions, fine-tuned with one shared setting §3.2 tab. 3.
• Three datasets: traffic signs (24 classes), African wildlife (4 classes), ships (1 class) §3.1.
• Author-reported headline: YOLO11 gives the most balanced accuracy and efficiency; YOLOv12 is slow without a clear accuracy gain §5 §7.
• The linked repository contains training notebooks for traffic signs only. Several numbers in the text disagree with the paper's own tables (see Paper vs code).
• No repeated runs or variance are reported, so treat small gaps as ties.

Problem

Earlier YOLO reviews, as the paper describes them, judge versions mainly on mAP and FPS, leave out precision and recall, leave out the newest versions, or do not benchmark at all §2. Without one common protocol, numbers from different papers mix datasets, settings and metrics, so they cannot be ranked against each other.

The paper also has to deal with a source problem. Several YOLO versions (YOLOv4, YOLOv6, YOLOv7) have no Ultralytics support, and the authors argue that Ultralytics ports and original releases give different numbers on the same data. They therefore benchmark only the Ultralytics-supported models §3.2.1 tab. 1 tab. 2.

Method

This is an experimental protocol, not a new model. Each pretrained Ultralytics checkpoint is fine-tuned on the training split of each dataset with the shared settings in tab. 3, then evaluated with the metrics in §3.4. The paper states that all 33 models from 7 versions were trained on the three datasets §3.2 fig. 4.

Models and scale suffixes. The suffixes are n (nano), s (small), m (medium), l (large), x (extra-large), t (tiny), c (compact), b (balanced) and e (extended) §3.2. The variants that appear in the result tables are: YOLOv3u (plus a tiny variant), YOLOv5u (n, s, m, l, x), YOLOv8 (n, s, m, l, x), YOLOv9 (t, s, m, c, e), YOLOv10 (n, s, m, b, l, x), YOLO11 (n, s, m, l, x) and YOLOv12 (n, s, m, l, x) fig. 12 fig. 16 fig. 20.

Architectural notes that the paper gives for each version (its own description, not verified here):

• YOLOv3u: an anchor-free detection head, which the paper says later appears in YOLOv8 §3.2.2.
• YOLOv5u: anchor-free detection on a YOLOv5-style backbone with CSP connections and SPPF §3.2.3 fig. 6.
• YOLOv8: C2f blocks in place of CSP layers; the Ultralytics model also covers segmentation, pose and OBB tasks §3.2.4 fig. 7.
• YOLOv9: programmable gradient information (PGI) and GELAN blocks §3.2.5 fig. 8.
• YOLOv10: NMS-free training with a one-to-many head for training and a one-to-one head for inference §3.2.6 fig. 9.
• YOLO11: C3k2 blocks in place of C2f, and a C2PSA module for spatial attention §3.2.7 fig. 10.
• YOLOv12: Area Attention (A2), R-ELAN blocks, FlashAttention, MLP ratio reduced from 4 to 1.2, no positional encodings, one R-ELAN block in the last backbone stage, and convolution plus batch normalisation in place of linear layers §3.2.8 fig. 11.

Metrics §3.4:

• Precision: correct predictions divided by all predictions.
• Recall: correct predictions divided by all actual objects.
• mAP50: mean average precision at an IoU threshold of 0.50.
• mAP50-95: mean average precision averaged over IoU thresholds from 0.50 to 0.95 in steps of 0.05.
• Preprocessing, inference and postprocessing time, GFLOPs, and model size.

Protocol, as a sketch of the paper's procedure with the code's calls noted:

# Benchmark protocol  [§3] [tab. 3]
# Input:  three datasets (train/val/test), 33 pretrained checkpoints
# Output: per model and dataset: P, R, mAP50, mAP50-95, times, GFLOPs, size

def run_benchmark(datasets, checkpoints):
    # One shared training setting for every model  [§3.2] [tab. 3]
    settings = shared_training_settings()
    results = []
    for dataset in datasets:
        for checkpoint in checkpoints:
            # Start from the pretrained weights  [§1]
            # [code: traffic-sign-detection-yolov8m.ipynb#L1346]
            model = load_pretrained(checkpoint)
            # Fine-tune on the training split  [§3.1] [tab. 3]
            model.train(dataset.train, settings)
            # Score on the validation split (the code calls .val())
            # [code: traffic-sign-detection-yolov8m.ipynb#L4309]
            metrics = model.evaluate(dataset.val)
            results.append(metrics)
    return results

mAP50-95 for one model. The paper gives the thresholds but not how classes are averaged §3.4:

# mAP50-95 for one model  [§3.4]
# Input:  average precision per class at each IoU threshold
# Output: one scalar

def map_50_95(ap_by_class_and_iou):
    # IoU thresholds 0.50, 0.55, ..., 0.95  [§3.4]
    thresholds = [0.50 + 0.05 * step for step in range(10)]
    # Mean over classes at each threshold; class averaging not stated  [§3.4]
    per_threshold = [
        mean_over_classes(ap_by_class_and_iou, threshold)
        for threshold in thresholds
    ]
    # Mean over thresholds  [§3.4]
    return mean(per_threshold)

Ranking. For the discussion, the paper ranks models by mAP50-95 for accuracy and by total processing time for speed. Models are first grouped by scale (nano, small, medium, large, extra-large) so that like is compared with like. Family rankings are averages of those ranks across scales and datasets §5 tab. 4 fig. 24. The exact rank procedure is not spelled out; see Pitfalls.

Hyperparameters

Values from tab. 3 and §3.1 are the paper's. The "code" entries are the values the notebooks actually pass or log, for the traffic-sign runs only. Paths are relative to the repository at code_commit.

Results

Author-reported. Setup: three datasets, each with one run per model under tab. 3 settings, on 2 × RTX 4090 §3.3. The comparison baselines are the other YOLO versions and scales in the same tables. tab. 2 is the only comparison with non-Ultralytics (original) implementations, and it is on traffic signs only. The paper does not say which split the reported metrics come from; see Pitfalls.

Headline numbers, as stated in the text and checked against the figure tables:

• Traffic signs: YOLO11m is named the most consistently strong model §4.1.1. Its figures are mAP50 0.893, mAP50-95 0.795, total time 4 ms, 67.9 GFLOPs and size 38.8 fig. 12. YOLOv5ul has the highest mAP50-95, at 0.799 fig. 12. YOLOv10n is the fastest at total time 2 ms and 8.3 GFLOPs §4.1.1 fig. 12.
• African wildlife: YOLOv9s has mAP50-95 0.832 and mAP50 0.956 §4.1.2 fig. 16. YOLO11l has the highest mAP50, at 0.965 fig. 16. YOLOv12x is the slowest, at total time 12.8 ms fig. 16.
• Ships: YOLO11x has the highest mAP50-95, at 0.327 §4.1.3 fig. 20. YOLOv12x is the slowest, at total time 10.9 ms fig. 20.
• Family ranking by the authors: YOLO11 and YOLOv12 rank first on accuracy, YOLO11 first on GFLOPs, YOLOv3u first on speed and YOLOv10 first on size. YOLOv12 ranks last on speed tab. 4 fig. 24.

Table: Ultralytics vs original implementations, traffic signs (author-reported, one run each) tab. 2:

Table: family ranking, averaged over scales and datasets (rank 1 is best) tab. 4:

Units: the paper's text gives processing time in milliseconds per image §4.1.1. The figure tables give no units. Size units are not stated. Total time is preprocessing plus inference plus postprocessing; this was spot-checked on several rows and appears to hold.

Traffic signs, all 33 models fig. 12. Columns: precision, recall, mAP50, mAP50-95, preprocess time, inference time, postprocess time, total time, GFLOPs, size:

African wildlife, all 33 models fig. 16:

Ships, all 33 models fig. 20:

Paper vs code

The repository is Nidhal-Jegham/YOLO-Benchmark-Paper, owned by the first author's GitHub account. The paper's Declarations say the code will be public on publication. Code paths below are relative to the repository root at code_commit. The repository has no LICENSE file, so its license is "not stated" and no code may be quoted verbatim.

• Scope. The repository has three notebooks, all for traffic signs: traffic-sign-detection-yolov8m.ipynb, traffic-sign-detection-yolov5mu.ipynb and traffic-sign-detection-yolov5.ipynb. No training code for the African wildlife or ships datasets is included. Their figures exist only in the paper and in CSV sheets Comparative Analysis YOLO African Animals - Sheet1.csv Comparative Analysis YOLO Ships - Sheet1.csv.
• Results files. The traffic-sign CSV has no YOLO11 or YOLOv12 rows Comparative Analysis YOLO - Sheet1.csv. Its YOLOv10 rows differ from fig. 12; for example YOLOv10n has mAP50 0.756 in the CSV and 0.722 in fig. 12. The timings also differ for every dataset; YOLOv3u inference on traffic signs is 7.2 ms in the CSV Comparative Analysis YOLO - Sheet1.csv and 8.5 ms in fig. 12. The repository does not say which run produced the CSVs or the figures.
• Optimizer and learning rate. tab. 3 lists AdamW with initial and final rates (0.0001, 0.01). The code passes optimizer=auto together with lr0=0.0001 and momentum=0.937. The log says the auto setting ignored those two values and used AdamW(lr=0.000169, momentum=0.9) traffic-sign-detection-yolov8m.ipynb traffic-sign-detection-yolov8m.ipynb. The effective learning rate therefore differs from tab. 3. The same happens in the YOLOv5mu notebook traffic-sign-detection-yolov5mu.ipynb.
• Augmentation. tab. 3 lists "None", and §3.1.1 says no augmentation was applied. The printed training arguments show mosaic=1.0, mixup=0.0, copy_paste=0.0, auto_augment=randaugment and erasing=0.4 traffic-sign-detection-yolov8m.ipynb. augment=False refers to test-time augmentation, not training. The paper's "no augmentation" statement therefore does not match the code, at least for traffic signs.
• Evaluation split. §3.1 gives a 70 / 20 / 10 train / val / test split. The code calls .val(), and the printed arguments set split=val traffic-sign-detection-yolov8m.ipynb traffic-sign-detection-yolov8m.ipynb. The code therefore reports validation-split metrics. The paper does not say which split its tables use.
• Software and hardware. §3.3 states Python 3.12, CUDA 12.4 and Ultralytics 8.2.55 on two RTX 4090s. The notebook logs show Python-3.10.13 and a single device, CUDA:0 traffic-sign-detection-yolov8m.ipynb. Ultralytics is installed unpinned traffic-sign-detection-yolov8m.ipynb.
• Agreement. These values match the code: 100 epochs, batch 16, image size 640, dropout 0.15 tab. 3 traffic-sign-detection-yolov8m.ipynb traffic-sign-detection-yolov8m.ipynb.
• Original implementations (tab. 2). No code in this repository produces the "GitHub" rows. The closest notebook, traffic-sign-detection-yolov5.ipynb, loads the Ultralytics checkpoint YOLO('yolov5m.pt') traffic-sign-detection-yolov5.ipynb.
• Text against figures. The text and figures disagree in several places:
  • §4.1.1 gives YOLOv5ul mAP50 as 0.866; fig. 12 shows 0.886.
  • §4.1.3 says YOLO11x has the highest accuracy at mAP50 0.529, but fig. 20 shows YOLOv5ux at 0.531, with YOLO11x best only on mAP50-95 (0.327).
  • §4.1.3 gives YOLOv12x an inference time of 10.9 ms; in fig. 20 10.9 ms is the total and inference is 9.3 ms.
  • §4.1.3 labels a row "YOLOv5n"; fig. 20 labels it YOLOv5un.
• Training cost. The log for one YOLOv8m traffic-sign run reports 3.332 hours traffic-sign-detection-yolov8m.ipynb. The paper gives no training time.

Pitfalls

• One run per model, no variance. Each model gets one training run, and no repeats or intervals are reported. Gaps of a few thousandths, such as YOLO11m (0.795) against YOLO11l (0.794) on traffic-sign mAP50-95 fig. 12, should not be read as a ranking.
• Which split the numbers come from. The paper lists a 10% test split §3.1, but the code reports validation metrics traffic-sign-detection-yolov8m.ipynb. Whether the test split was scored at all is not stated.
• Effective settings differ from the table. On traffic signs, the optimizer, learning rate and augmentation that actually ran differ from tab. 3 (see Paper vs code). Any re-run that follows the table will not reproduce the numbers.
• Augmentation on the other datasets is unknown. Only the traffic-sign notebooks exist, so the augmentation for African wildlife and ships is not stated. The paper's "no augmentation" claim is the only source for them.
• Scale grouping is inconsistent. §5 lists YOLOv9c as medium and also as large. The ranking is described as "by scale", but the group boundaries and the averaging across datasets are not given, so the family ranks in tab. 4 are hard to reproduce exactly.
• Scale count. §3.2.6 says YOLOv10 has five scaled versions. fig. 12 shows six (n, s, m, b, l, x).
• Timing conditions. The tables give no units. The text uses milliseconds per image §4.1.1. Batch size for timing, numerical precision, warm-up, and whether timing includes the same preprocessing as training are not stated. Size units are not stated.
• Ranking method. The paper ranks by mAP50-95 for accuracy and total time for speed, but the rule for combining ranks across scales and datasets is not stated. The overall ranking figure fig. 24 is not transcribed here.
• Dataset construction. The traffic-sign set starts with about 55 classes; the authors remove classes with fewer than 50 observations and keep 24 §3.1.1. The list of the kept classes is not given, and the undersampling procedure is not described.
• Dataset size. The Africa set has at least 376 images per class §3.1.2. Results on such a small set are noisy. The authors attribute weak large-model results to overfitting §4.1.2 §5.3, but no training-curve evidence is given in the paper.
• Ships dataset. Its size is given as approximately 13.5k images §3.1.3, and the number used for each split is not stated.
• Latency explanation. The paper attributes YOLOv12's latency to FlashAttention and to model complexity §5.2. These are the authors' explanations; no ablation isolates them.
• Training cost. The traffic-sign notebooks log per-run training times of about 3.3 hours traffic-sign-detection-yolov8m.ipynb. The paper gives no training time, so budget a re-run from this figure.
• Ultralytics ports. The "u" models (for example YOLOv5u, YOLOv3u) are Ultralytics versions with an anchor-free head, not the original releases §3.2.1. Conclusions about "YOLOv5" in this paper apply to these ports.

Lineage

• Builds on: the YOLO versions described in §1 and §3.2, from YOLOv1 to YOLOv12. The paper gives its references by name, but no arXiv ids appear in its text, so no cards are linked here.
• Compared against: the other Ultralytics checkpoints in the same tables. Original implementations are compared only in tab. 2, on traffic signs.
• Related card: What is YOLOv8 covers YOLOv8 internals. This paper uses YOLOv8 checkpoints as baselines §3.2.4.
• Superseded by: not stated.