← Back to all posts
News

YOLO26 Kills NMS: Ultralytics' New Detector Goes End-to-End and Runs 43% Faster on CPU

June 23, 2026 · News
YOLO26 Kills NMS: Ultralytics' New Detector Goes End-to-End and Runs 43% Faster on CPU

TL;DR

Ultralytics dropped the formal paper for YOLO26, and the headline is not a bigger backbone. It is a smaller one. The new family removes Non-Maximum Suppression (NMS) and Distribution Focal Loss (DFL) from the detection path, ships a native end-to-end one-shot inference branch, and reports up to 43% faster CPU inference on the nano model versus YOLO11n. Accuracy lands at 40.9 to 57.5 mAP on COCO across five sizes, all at single-digit-millisecond GPU latency.

What actually changed

Every YOLO since the v8 era shipped the same dirty secret: the model spits out hundreds of overlapping candidate boxes, then a separate, non-differentiable post-processing step (NMS) prunes them down. That step is not in the graph, it is sensitive to a confidence threshold you have to tune, and it adds latency that nobody puts on the benchmark chart. On a CPU or a microcontroller, it is a real tax.

YOLO26 deletes it. A dual-head design trains a one-to-many branch (with NMS, for the classic path) alongside a one-to-one branch that emits final predictions directly. At inference you run the one-to-one head and get boxes straight out of the network. No threshold to babysit, no post-processing op to port to your edge runtime, one clean graph to export.

before: YOLO11 (NMS in post-processing) model NMS post-processtune threshold boxes after: YOLO26 (native end-to-end) model (one-to-one head) boxes
The whole pitch in one diagram: the post-processing box is gone, so the export graph is the whole model.

DFL goes too. Distribution Focal Loss modeled each box coordinate as a probability distribution over bins, which helped accuracy but bloated the head and capped the regression range. YOLO26 drops it for a lighter head with an unconstrained range. To recover the accuracy you would normally lose, the team leaned on training tricks instead of architecture.

The training-side tricks

  • MuSGD optimizer. A hybrid of SGD and Muon, the optimizer that has been turning heads in large language model pretraining. Borrowing an LLM training idea and dropping it into a vision detector is the kind of cross-pollination worth noticing.
  • Progressive Loss (ProgLoss). Shifts supervision toward the inference-time one-to-one head as training proceeds, so the branch you actually ship gets the attention.
  • STAL. A label-assignment scheme that improves positive coverage for small objects, the classic weak spot for real-time detectors.

The numbers

Five sizes, COCO val mAP from 40.9 (nano) to 57.5 (extra large), GPU latency from 1.7 to 11.8 ms on a T4 with TensorRT. The accuracy curve flattens fast: going from nano to extra large costs you 23x the parameters (2.4M to 55.7M) for about 17 points of mAP. For a lot of edge work, nano or small is the honest pick.

COCO mAP (50-95) by model size 26n40.9 26s48.6 26m53.1 26l55.0 26x57.5
Diminishing returns: the jump from nano to extra large is 23x the parameters for roughly 17 mAP points.

The number edge builders care about most is CPU. The nano model clocks 38.9 ms ONNX on an Intel Xeon at 2.00 GHz, which the paper frames as up to 43% faster than YOLO11n. Part of that win is simply not running NMS on the CPU anymore.

T4 TensorRT latency, ms (lower is better) 26n1.7 26m4.7 26x11.8
Even the extra-large model stays in single-digit-plus milliseconds on a budget T4 GPU.

Why a builder should care

If you run vision on the edge, a Pi, a Jetson, an industrial camera, an NVR box, the win is portability, not just speed. An NMS-free model exports to ONNX, TensorRT, CoreML, or TFLite as a single self-contained graph. No custom post-processing op to reimplement, no confidence-threshold drift between your training rig and the deployed device. That is the kind of papercut that eats a weekend.

YOLO26 also keeps the multi-task story: detection, instance segmentation, pose estimation, oriented bounding boxes, and classification all ship in the family, so the same toolchain covers most of what a homelab camera stack needs.

The license asterisk

Same as ever with Ultralytics: AGPL-3.0 or a paid Enterprise license. AGPL is fine for research, internal tooling, and anything you are happy to open-source. The moment YOLO26 sits behind a network service in a product you ship, AGPL's network clause applies and you are looking at the commercial license. Budget for that before you build a business on the nano model.

Key Takeaways

  • YOLO26 removes NMS and DFL, shipping a native end-to-end one-to-one inference head that emits final boxes with no post-processing.
  • The nano model is up to 43% faster on CPU than YOLO11n (38.9 ms ONNX on an Intel Xeon at 2.00 GHz), partly because NMS is gone.
  • Accuracy spans 40.9 to 57.5 mAP on COCO across five sizes, at 1.7 to 11.8 ms T4 TensorRT latency.
  • Training-side wins do the heavy lifting: the MuSGD optimizer (borrowed from LLM pretraining), Progressive Loss, and STAL for small objects.
  • The real edge benefit is a single clean export graph with no custom NMS op and no threshold drift across devices.
  • Licensing is unchanged: AGPL-3.0 or a paid Enterprise license for closed-source or networked products.

Sources: Ultralytics YOLO26: Unified Real-Time End-to-End Vision Models (arXiv), Ultralytics YOLO26 Docs, Roboflow: An Introduction to YOLO26

AIcomputer visionYOLOobject detectionedge AIopen sourceUltralyticsONNX
CONSOLE
$