Ultralytics YOLO26: Unified Real-Time End-to-End Vision Models

In plain words

YOLO26 is a family of fast object detectors, from a tiny model to a large one. Older detectors of this kind often need an extra cleanup step after the model runs, which removes duplicate boxes for the same object. YOLO26 is built so the model can give its final answer directly, without that cleanup step, while a second, denser output head is kept for cases where the cleanup is acceptable.

The team also changed how the box coordinates are predicted, which makes the prediction head smaller and lighter. The training recipe changed too: a new optimizer that mixes a recent matrix-based method with ordinary momentum SGD, a schedule that moves training attention from the dense head to the direct head over time, and a rule that makes sure very small objects still get training signal.

The same backbone is reused for segmentation, pose and rotated boxes, and an open-vocabulary variant lets you name the objects you want to find in text.

TL;DR

YOLO26 is a real-time detector family with five sizes (n, s, m, l, x). Its default head outputs boxes without NMS, the box head has no Distribution Focal Loss, and it is trained with MuSGD, Progressive Loss and STAL. The authors report up to 57.5 COCO mAP, at 11.8 ms on a T4 with TensorRT. Use it when you need a fast detector with a simple deployment path. Treat the numbers as author-reported, and check the code notes below before reimplementing.

Problem

Real-time detectors need high accuracy, cheap inference, and easy deployment. The paper lists four limits of current YOLO-style detectors §1:

• NMS at inference. Dense detectors need non-maximum suppression to remove duplicates, which adds post-processing cost and complicates export §1.
• Heavy box regression head. Distribution Focal Loss predicts each box side as a distribution over bins, which multiplies head outputs and limits the largest box side that can be represented §3.2.2 eq. 1.
• Long schedules. Standard SGD recipes need roughly 600 epochs for competitive COCO accuracy, according to the paper's motivation §1.
• Zero positives for tiny objects. Task-aligned assignment selects anchor centres inside each ground-truth box. After downsampling, a very small box can have no anchor centre at all, and then it gets no training signal §3.3.3.

The paper also states that the two-head design applies identical loss weights to both heads, leaving the one-to-one head under-optimised §1.

Method

YOLO26 keeps the YOLO11 backbone-neck-head layout §3.1 and changes four parts: a dual-head output, a DFL-free box head, a training pipeline, and task heads for segmentation, pose, oriented boxes and open-vocabulary detection. Figure descriptions are in the text; the paper's training-pipeline and deployment figures are cited by section §3.1 §3.5.

Dual-head end-to-end output §3.2.1

• One-to-one head (default). Gives at most 300 detections per image, shape (N, 300, 6) §3.2.1. It is trained with TAL, using topk = 7 and then a secondary topk2 = 1 filter, so each ground-truth object gets one positive §3.2.1 loss.py.
• One-to-many head. Standard dense output, shape (N, n_c + 4, 8400) at 640 px, trained with TAL topk = 10 and decoded with NMS at inference §3.2.1 loss.py.

DFL-free box regression §3.2.2

• Box sides are regressed directly, without a discrete distribution. The regression is reg_max = 1, so the head outputs four values per location tab. 1 §3.2.2.
• The regression loss is an L1 distance when reg_max <= 1. The code path that does this is BboxLoss loss.py.
• On the YOLO11s baseline, dropping DFL lowers AP by 0.6 points, and the later STAL and backbone/neck changes win that back tab. 2 §4.2.

Training pipeline §3.3

Shared features feed both heads. STAL shapes the candidate set, Progressive Loss mixes the two branch losses, and MuSGD updates the weights §3.3.

MuSGD §3.3.1. Matrices and convolution kernels receive an orthogonalised Muon update plus an SGD-momentum update. Biases and normalisation scales receive plain SGD. The paper cites the Muon optimizer and its Newton-Schulz orthogonalisation §3.3.1.

Progressive Loss §3.3.2. The total loss is a weighted sum of the one-to-many loss and the one-to-one loss eq. 2. The one-to-many weight decays linearly from an initial to a final value, and the one-to-one weight takes the rest eq. 3. The released implementation starts at 0.8 and ends at 0.1 §4.1 loss.py loss.py.

STAL §3.3.3. STAL changes only the candidate mask. It builds a surrogate box where any side below the smallest pyramid stride is replaced by a reference size eq. 4 eq. 5. Anchor centres inside the surrogate are candidates eq. 6. The original box is still used for task-aligned scoring, final assignment and regression §3.3.3.

# Progressive Loss weight for the one-to-many branch  [§3.3.2] [eq. 3]
# Input: t (0-based epoch), E (total epochs), a_init, a_final
# Output: scalar weight; the one-to-one weight is 1 - weight
def one_to_many_weight(t, E, a_init, a_final):
    # Linear decay over epochs, clamped at zero  [eq. 3]
    decay = max(1 - t / max(E - 1, 1), 0)
    # Scale between the initial and final weight  [eq. 3]
    return decay * (a_init - a_final) + a_final

# Candidate box for STAL, used only for positive-candidate selection  [§3.3.3]
# Input: box (x, y, w, h); s_min smallest stride; s_ref reference size
# Output: surrogate box used only in the candidate mask  [eq. 4] [eq. 6]
def stal_candidate_box(box, s_min, s_ref):
    # Each side is handled on its own  [eq. 5]
    # The paper's threshold is s_min; see Paper vs code for the code's value
    width = s_ref if box.w < s_min else box.w
    height = s_ref if box.h < s_min else box.h
    # Keep the centre; only the size changes  [eq. 4]
    return (box.x, box.y, width, height)

Task extensions §3.4

Instance segmentation §3.4.1. A shared prototype tensor is built once per image, and each instance predicts coefficients that combine the prototypes into a mask eq. 7. Prototypes come from a fused multi-scale feature eq. 8 eq. 9. A training-only semantic segmentation branch with BCE plus Dice loss is added and removed at fusion, so it adds no inference cost §3.4.1.

Pose §3.4.2. Each keypoint has a predicted location and a sigma per axis §3.4.2. The residual is normalised by sigma eq. 10 and scored with a normalising flow (RealNVP) inside a residual log-likelihood loss eq. 11. Keypoints with large sigma are down-weighted §3.4.2.

Oriented boxes §3.4.3. The angle is defined on the long edge with range [-45, 135) degrees, and width is at least height §3.4.3. The angle is predicted directly instead of through a sigmoid squash eq. 12 eq. 13. A separate angle loss for near-square boxes uses a double-angle penalty taken modulo pi, weighted by an aspect-ratio factor, normalised by the TAL assignment weights eq. 14 eq. 15 §3.4.3.

# Angle loss for oriented boxes  [§3.4.3] [eq. 14] [eq. 15]
# Input: pred_theta, true_theta, true_w, true_h, assign_w (TAL weight), lam
# Output: scalar loss for foreground anchors (summed over batch)
def angle_loss_term(pred_theta, true_theta, true_w, true_h, assign_w, lam):
    # Residual taken modulo pi, since a rotation by pi is the same box  [eq. 14]
    delta = pred_theta - true_theta
    delta = delta - round(delta / pi) * pi
    # Double-angle penalty, which is strong for near-square boxes  [eq. 15]
    penalty = sin(2 * delta) ** 2
    # Aspect-ratio weight: elongated boxes get a small weight  [eq. 15]
    omega = exp(-(log(true_w / true_h) ** 2) / lam ** 2)
    return sum(assign_w * omega * penalty) / max(sum(assign_w), 1)

Open-vocabulary YOLOE-26 §3.6. Builds on YOLOE's three inference modes (text, visual, prompt-free) with a YOLO26 backbone and head §3.6. Class scores are a scaled inner product between normalised region embeddings and prompt embeddings, plus a bias, passed through a sigmoid eq. 16 eq. 17. It uses MobileCLIP2 as the text encoder, a pseudo-label data engine built with a YOLOE teacher, and a segmentation head that is trained in a later stage §3.6.

Model variants and deployment §3.5

Five sizes (n, s, m, l, x) cover detection, instance segmentation, classification, pose and oriented detection. The paper lists 19 export targets §3.5. Some runtimes that cannot run the top-K step fall back to the dense branch at export §3.5. The authors report up to 43 percent faster CPU inference than YOLO11n in ONNX on one Xeon CPU §3.5.

Hyperparameters

Values from the paper and the released checkpoint recipes. Released checkpoints use the train_args recorded in the Objects365-v1 and COCO runs [app. Training Recipes].

Released COCO fine-tuning settings, for YOLO26 with end-to-end training [app. Training Recipes]. One row per setting. The augmentation and loss rows are the release values, not the defaults in the code.

Objects365-v1 pretraining, same format app. Training Recipes: MuSGD for all sizes, end2end unset, 640 px, batch 128, 150 epochs, lr0 0.01, lrf 0.01, momentum 0.94, weight_decay 0.0005, close_mosaic 8, box 7.5, cls 0.5, dfl 6.0. Warmup is 1 epoch for n/s/m/l and 2 for x. Augmentation strengths rise with size, for example mixup 0.00 (n) to 0.20 (x) and copy_paste 0.10 (n) to 0.60 (x). The internal rows are 0.10 for o2m at n/s/m and 1.00 at l/x, with muon_w 0.45 to 0.50 and sgd_w 0.50 to 0.60 app. Training Recipes.

Progressive Loss and the one-to-many schedule are updated once per epoch §4.1 trainer.py.

Results

Author-reported. Setup: COCO val2017 detection, trained on Objects365-v1 and then COCO, T4 TensorRT10 and CPU ONNX latency on an Intel Xeon at 2.00 GHz tab. 7.

The paper says the one-to-one path trails the NMS path by 0.6 to 0.8 AP across sizes §4.4. Its comparison with YOLO11 is a 1.6 to 2.8 point COCO AP gain at matched sizes §1. The full grouped comparison with other real-time detectors is in app. Literature Comparison.

Component ablation from YOLO11s to YOLO26s tab. 2:

DFL removal, controlled, YOLO26s, trained from scratch tab. 3:

MuSGD vs SGD, from scratch on COCO tab. 4: SGD 47.0 mAP at 600 epochs; MuSGD 47.4 mAP at 500 epochs. A matched classification comparison in [app. MuSGD Transfer] shows MuSGD ahead at every scale, for example 71.4 vs 70.0 top-1 for n and 79.9 vs 79.5 for x.

Progressive Loss schedules on YOLO11s tab. 5:

STAL reference size on YOLO11s tab. 6: TAL 46.6 AP (AP_S 29.0); STAL with s_ref 8 gives 46.6 (27.7); s_ref 16 gives 46.8 (29.6); s_ref 32 gives 46.5 (28.3).

Instance segmentation, YOLO11s ablation tab. 8: baseline 32.0 mask mAP,

• multi-scale proto 32.4, + auxiliary loss 32.7. The full COCO comparison gives YOLO26 +1.6 to +2.5 box AP and +2.4 to +3.7 mask AP over YOLO11 §4.5.1 app. Additional Task Benchmarks.

Pose, YOLO26s tab. 9, weights (w_OKS, w_RLE) with keypoint mAP: (48, 0) 61.5; (48, 1) 60.8; (24, 1) 63.0; (24, 2) 62.5; (12, 1) 62.6; (0, 1) 61.9; (0, 2) 62.4. The full COCO keypoint comparison gives +2.1 to +7.2 pose AP over YOLO11 in the E2E setting §4.5.2.

Oriented boxes, DOTA-v1.0 validation, YOLO26s tab. 10: angle range (0, 90] gives 47.7 mAP; [-45, 135) gives 49.0. Angle loss lambda tab. 11: none 49.0; 1 gives 49.4; 2 gives 49.5; 3 gives 50.2; 4 gives 49.8; 5 gives 47.1. The full test-set comparison gives +2.5 to +3.4 mAP over YOLO11 §4.5.3.

YOLOE-26 on LVIS minival tab. 12, ablation on YOLOE-26s-TP, AP:

Text prompts on LVIS minival app. Additional YOLOE-26 Benchmarks: YOLOE-26x 40.6 AP (visual 38.5), YOLOE-26l 37.8 (36.3), YOLOE-26m 35.4 (33.9), YOLOE-26s 30.8 (28.6), YOLOE-26n 24.7 (21.9), using the non-E2E head as the headline. The E2E head trails by up to 1.1 AP for text prompts. Prompt-free non-E2E reaches 31.1 AP for YOLOE-26x app. Additional YOLOE-26 Benchmarks.

Paper vs code

Checked against the official Ultralytics repository, commit bdf53d2d5cbbe5969ad946e9832217d799417111 (main at the time of cloning, not necessarily the commit used for the paper's tables). The repository is AGPL-3.0. We cite it by path and line only and write our own pseudocode.

Matches the paper

• The one-to-one and one-to-many TAL settings and the Progressive Loss start and end weights are as stated loss.py.
• The schedule is applied once per epoch at the end of the epoch [code: ultralytics/engine/trainer.py#L650-L651]. The update counter is incremented before the decay is computed, so 0-based epoch t gives the paper's weight.
• The one-to-one head caps detections at 300 head.py.
• The oriented head outputs raw angles with no sigmoid squash [code: ultralytics/nn/modules/head.py#L568]. The base class still has the squash [code: ultralytics/nn/modules/head.py#L529].
• The angle loss has the modulo-pi residual, the double-angle penalty and the aspect-ratio weight, with lambda default 3 loss.py.
• The pose head uses a normalising flow, and the residual log-likelihood loss is implemented head.py loss.py.

Differs from the paper

• STAL threshold. The paper sets s_min = 8 and clamps sides below 8 px to 16 §4.1 §3.3.3. The code sets stride_val to the second stride, 16, and enlarges any side below 16 to 16 tal.py tal.py. More small boxes are enlarged in the code than in the paper's text.
• Muon orthogonalisation. The paper says "a few" Newton-Schulz iterations. The code uses five fixed steps with fixed coefficients [code: ultralytics/optim/muon.py#L10-L52], and scales the update by the square root of max(1, rows / columns) muon.py.
• Which parameters get Muon. The paper says multi-dimensional parameters. The trainer routes only tensors with two or four dimensions to Muon [code: ultralytics/engine/trainer.py#L1208]. Biases and normalisation scales use SGD.
• MuSGD mixing weights. The paper gives no numeric mix. The code defaults to Muon scale 0.2 and SGD scale 1.0 trainer.py. The released checkpoint records muon_w 0.44 to 0.53 and sgd_w 0.48 to 0.67 [app. Training Recipes]. The keys muon_w, sgd_w, cls_w, topk and o2m from that table did not appear as config keys in this repository's Python or YAML, so the checkpoint values cannot be traced here.
• Checkpoint topk and o2m. The checkpoint records topk 8 (n) and 5 (s to x) and o2m 1.00 or 0.71 app. Training Recipes. This disagrees with the code default topk 10 loss.py and the 0.8 to 0.1 schedule §4.1. Which value the checkpoints actually used is unresolved.
• Pose gain. The paper's best pose weights are w_OKS = 24 and w_RLE = 1 [tab. 9]. The config default for the pose gain is 12.0 default.yaml, and the paper does not map its w_OKS to a config key. Unresolved.
• Box regression key. The paper says DFL is removed. The config field dfl is kept and now scales the L1 box loss app. Training Recipes [code: ultralytics/cfg/default.yaml#L107]. The released n checkpoint uses dfl 9.04 and the other sizes 0.96.
• Fine-tuning learning rate. When fine-tuning, the trainer splits the MuSGD groups and gives the cv3 head parameters and the semantic-segmentation branch a higher learning rate trainer.py. A code comment describes that half as a learning rate times three [code: ultralytics/utils/events.py#L134]. The paper does not describe this.

Not verified in this repository

• The OBB angle range [-45, 135) degrees. No constant matching it was found in ultralytics/utils/ops.py, metrics.py or tal.py.
• The YOLOE-26 pseudo-label data engine (teacher vocabulary of 4585 classes, IoU below 0.5, confidence above 0.5). Searching the Python code for "4585" and "pseudo" found nothing.
• The YOLOE-26 training stages and their learning rates [app. YOLOE-26 Implementation Details]. Not checked here.

The repository is the one the paper links, under the Ultralytics organisation, which is the affiliation the authors list on the title page.

Pitfalls

• Tiny-box threshold. Follow the paper's text (threshold 8) or the code (threshold 16) on purpose. They produce different candidate sets for boxes between 8 and 16 px. Table 6 tests s_ref, not this threshold.
• Progressive Loss weight is per epoch, not per iteration. The one-to-many weight changes only at the end of each epoch trainer.py. With E = 1 the only epoch uses the initial weight, since the decay never runs.
• Dense output at NMS inference. The one-to-many head's accuracy needs NMS at deployment. Runtimes without top-K operations fall back to it at export §3.5.
• DFL-free head and the dfl key. A nonzero dfl value in the released recipe does not mean DFL is active. It scales the L1 box loss app. Training Recipes.
• Muon parameter routing. Only two- and four-dimensional tensors use Muon. A reimplementation that applies Muon to every parameter, or to 1D scales, will not match the code.
• MuSGD has no numeric mix in the paper. Choose the mix from the code default (0.2 Muon, 1.0 SGD) or from the release table, and say which you used.
• Latency numbers exclude NMS for segmentation. The paper states this for instance segmentation latency app. Additional Task Benchmarks. Compare latencies only under the same post-processing.
• Reported gains are small. Many component gains are 0.2 AP in the ablation tab. 2 tab. 6. The paper gives single runs without variance.
• Hardware-specific latency. CPU numbers are from one Intel Xeon at 2.00 GHz and T4 numbers from TensorRT10 tab. 7. Speed rankings will change on other hardware.
• Mixed release and paper settings. The paper's tables and the released Ultralytics benchmark table tab. 7 come from different runs. The checkpoint recipe values differ from the code defaults app. Training Recipes. Take training settings from the release recipe, not the defaults.
• Licence. The repository is AGPL-3.0. Use the paper and the cited paths for reference, and do not copy code from it into permissively licensed work.

Lineage

• Builds on the YOLO11 model family §3.1, and the YOLOv10 dual assignment idea §2 §3.2.1.
• Its Distribution Focal Loss removal responds to the DFL head used since YOLOv8 and YOLO11 §3.2.2.
• The one-to-one training follows the Task-Aligned Learning assignment §3.2.1.
• The MuSGD optimizer uses the Muon method and SGD momentum §3.3.1.
• The open-vocabulary variant builds on YOLOE §3.6.
• The angle definition follows the MMRotate long-edge convention §3.4.3.
• Compared against YOLO11 and other recent real-time detectors §2 [app. Literature Comparison].