{"notes":[{"id":"object-detection/yolo26","category":"object-detection","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"YOLO26","subtitle":"Keeping Both Heads","author":"Z. Yuan","paperDate":"2026-06-02","publishedOn":"2026-10-07","paperTitle":"Ultralytics YOLO26: Unified Real-Time End-to-End Vision Models","paperUrl":"https://arxiv.org/abs/2606.03748","bibliography":{"title":"Ultralytics YOLO26: Unified Real-Time End-to-End Vision Models","authors":["Glenn Jocher","Jing Qiu","Mengyu Liu","Shuai Lyu","Fatih Cagatay Akyon","Muhammet Esat Kalfaoglu"],"url":"https://arxiv.org/abs/2606.03748","pdfUrl":"https://arxiv.org/pdf/2606.03748v1","codeUrl":"https://github.com/ultralytics/ultralytics","preprint":{"id":"2606.03748","submittedOn":"2026-06-02","url":"https://arxiv.org/abs/2606.03748"},"publication":null,"citation":"@misc{objectdetectionyolo262026,\n  title = {{Ultralytics YOLO26: Unified Real-Time End-to-End Vision Models}},\n  author = {Glenn Jocher and Jing Qiu and Mengyu Liu and Shuai Lyu and Fatih Cagatay Akyon and Muhammet Esat Kalfaoglu},\n  year = {2026},\n  eprint = {2606.03748},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2606.03748}\n}\n","citationPath":"/content/papers/citations/object-detection/yolo26.d5782368677d.bib"},"thumbnail":{"src":"/content/papers/assets/81b8a4e821bdb84f6040563add1c1f2341963826d993348c64cab2715e5d6e93.png","width":1494,"height":367},"locale":"en","path":"/content/papers/en/object-detection/yolo26.4a077009bab2.md","headings":[{"id":"problem-definition","text":"Problem Definition","depth":2},{"id":"solution","text":"Solution","depth":2},{"id":"training-pipeline","text":"Training Pipeline","depth":3},{"id":"two-heads-each-picking-its-own-positives","text":"Two Heads, Each Picking Its Own Positives","depth":3},{"id":"progressive-loss","text":"Progressive Loss","depth":3},{"id":"dropping-dfl","text":"Dropping DFL","depth":3},{"id":"stal","text":"STAL","depth":3},{"id":"musgd","text":"MuSGD","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"from-yolo11s-to-yolo26s-one-step-at-a-time","text":"From YOLO11s to YOLO26s, One Step at a Time","depth":3},{"id":"how-the-weights-are-scheduled","text":"How the Weights Are Scheduled","depth":3},{"id":"three-more-ablations","text":"Three More Ablations","depth":3},{"id":"how-far-apart-are-the-two-heads","text":"How Far Apart Are the Two Heads?","depth":3},{"id":"the-headline-numbers-come-from-two-heads","text":"The Headline Numbers Come from Two Heads","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/yolov10","relation":"referenced","topic":""},{"id":"object-detection/gfl","relation":"referenced","topic":""},{"id":"object-detection/tood","relation":"referenced","topic":""}]},{"id":"object-detection/yolov10","category":"object-detection","legacyPath":"object-detection/2405-yolov10","legacySlug":"2405-yolov10","legacyPaths":[],"title":"YOLOv10","subtitle":"Goodbye NMS","author":"Z. Yuan","paperDate":"2024-05-23","publishedOn":"2025-07-19","paperTitle":"YOLOv10: Real-Time End-to-End Object Detection","paperUrl":"https://proceedings.neurips.cc/paper_files/paper/2024/hash/c34ddd05eb089991f06f3c5dc36836e0-Abstract-Conference.html","bibliography":{"title":"YOLOv10: Real-Time End-to-End Object Detection","authors":["Ao Wang","Hui Chen","Lihao Liu","Kai Chen","Zijia Lin","Jungong Han","Guiguang Ding"],"url":"https://proceedings.neurips.cc/paper_files/paper/2024/hash/c34ddd05eb089991f06f3c5dc36836e0-Abstract-Conference.html","pdfUrl":"https://proceedings.neurips.cc/paper_files/paper/2024/file/c34ddd05eb089991f06f3c5dc36836e0-Paper-Conference.pdf","codeUrl":"https://github.com/THU-MIG/yolov10","preprint":{"id":"2405.14458","submittedOn":"2024-05-23","url":"https://arxiv.org/abs/2405.14458"},"publication":{"venue":"NeurIPS","year":2024,"kind":"conference","url":"https://proceedings.neurips.cc/paper_files/paper/2024/hash/c34ddd05eb089991f06f3c5dc36836e0-Abstract-Conference.html"},"citation":"@misc{objectdetectionyolov102024,\n  title = {{YOLOv10: Real-Time End-to-End Object Detection}},\n  author = {Ao Wang and Hui Chen and Lihao Liu and Kai Chen and Zijia Lin and Jungong Han and Guiguang Ding},\n  year = {2024},\n  eprint = {2405.14458},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2405.14458}\n}\n","citationPath":"/content/papers/citations/object-detection/yolov10.f624ec9e20b6.bib"},"thumbnail":{"src":"/content/papers/assets/43843817d1e6667933eb36b7b588db3ca318fe74e00d2d47095426923f3a5b44.jpg","width":1614,"height":536},"locale":"en","path":"/content/papers/en/object-detection/yolov10.0dbaf7fa020d.md","headings":[{"id":"problem-definition","text":"Problem Definition","depth":2},{"id":"solution","text":"Solution","depth":2},{"id":"dual-annotation-architecture","text":"Dual Annotation Architecture","depth":3},{"id":"efficiency-and-accuracy-optimization","text":"Efficiency and Accuracy Optimization","depth":3},{"id":"accuracy-oriented-enhancements","text":"Accuracy-Oriented Enhancements","depth":3},{"id":"implementation-details","text":"Implementation Details","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"comparison-with-sota-methods","text":"Comparison with SOTA Methods","depth":3},{"id":"ablation-study","text":"Ablation Study","depth":3},{"id":"can-nms-free-truly-replace-traditional-methods","text":"Can NMS-free Truly Replace Traditional Methods?","depth":3},{"id":"why-doesnt-simplification-drag-performance","text":"Why Doesn’t Simplification Drag Performance?","depth":3},{"id":"accuracy-improvements-with-nearly-no-latency-increase","text":"Accuracy Improvements with Nearly No Latency Increase?","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{"experimental-results-and-discussion":"discussion"},"guide":null,"relatedReading":[{"id":"object-detection/yolov11","relation":"comparison","topic":"Recent designs for efficient real-time detection"},{"id":"object-detection/yolo-tiny","relation":"comparison","topic":"Recent designs for efficient real-time detection"}]},{"id":"object-detection/gfl","category":"object-detection","legacyPath":"object-detection/2006-gfl","legacySlug":"2006-gfl","legacyPaths":[],"title":"GFL","subtitle":"Unified Focus","author":"Z. Yuan","paperDate":"2020-06-08","publishedOn":"2025-08-23","paperTitle":"Generalized Focal Loss: Learning Qualified and Distributed Bounding Boxes for Dense Object Detection","paperUrl":"https://arxiv.org/abs/2006.04388","bibliography":{"title":"Generalized Focal Loss: Learning Qualified and Distributed Bounding Boxes for Dense Object Detection","authors":["Xiang Li","Wenhai Wang","Lijun Wu","Shuo Chen","Xiaolin Hu","Jun Li","Jinhui Tang","Jian Yang"],"url":"https://arxiv.org/abs/2006.04388","pdfUrl":"https://proceedings.neurips.cc/paper_files/paper/2020/file/f0bda020d2470f2e74990a07a607ebd9-Paper.pdf","codeUrl":"https://github.com/implus/GFocal","preprint":{"id":"2006.04388","submittedOn":"2020-06-08","url":"https://arxiv.org/abs/2006.04388"},"publication":{"venue":"NeurIPS","year":2020,"kind":"conference","url":"https://papers.nips.cc/paper_files/paper/2020/hash/f0bda020d2470f2e74990a07a607ebd9-Abstract.html"},"citation":"@misc{objectdetectiongfl2020,\n  title = {{Generalized Focal Loss: Learning Qualified and Distributed Bounding Boxes for Dense Object Detection}},\n  author = {Xiang Li and Wenhai Wang and Lijun Wu and Shuo Chen and Xiaolin Hu and Jun Li and Jinhui Tang and Jian Yang},\n  year = {2020},\n  eprint = {2006.04388},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2006.04388}\n}\n","citationPath":"/content/papers/citations/object-detection/gfl.71fabce4b963.bib"},"thumbnail":{"src":"/content/papers/assets/b23270560323cea28f3b1fe736d861dd3365d20c4fb99278dcc3ce306df890dc.jpg","width":1224,"height":380},"locale":"en","path":"/content/papers/en/object-detection/gfl.b9fa7b27fd1a.md","headings":[{"id":"problem-definition","text":"Problem Definition","depth":2},{"id":"solution","text":"Solution","depth":2},{"id":"focal-loss","text":"Focal Loss","depth":3},{"id":"quality-focal-loss","text":"Quality Focal Loss","depth":3},{"id":"distribution-focal-loss","text":"Distribution Focal Loss","depth":3},{"id":"generalized-focal-loss","text":"Generalized Focal Loss","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"is-qfl-effective","text":"Is QFL Effective?","depth":3},{"id":"is-dfl-effective","text":"Is DFL Effective?","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{"解決問題":"solution","qfl-put-quality-into-the-class-score":"quality-focal-loss","dfl-turn-one-distance-into-a-distribution":"distribution-focal-loss","one-general-form-two-uses":"generalized-focal-loss","experimental-results-and-discussion":"discussion","qfl-does-the-score-improve-ranking":"is-qfl-effective","dfl-what-does-the-box-distribution-add":"is-dfl-effective"},"guide":null,"relatedReading":[{"id":"object-detection/fcos","relation":"comparison","topic":"Aligning classification and localization quality"},{"id":"object-detection/tood","relation":"comparison","topic":"Aligning classification and localization quality"}]},{"id":"object-detection/tood","category":"object-detection","legacyPath":"object-detection/2108-tood","legacySlug":"2108-tood","legacyPaths":[],"title":"TOOD","subtitle":"The End of Misalignment","author":"Z. Yuan","paperDate":"2021-08-17","publishedOn":"2025-08-30","paperTitle":"TOOD: Task-aligned One-stage Object Detection","paperUrl":"https://arxiv.org/abs/2108.07755","bibliography":{"title":"TOOD: Task-aligned One-stage Object Detection","authors":["Chengjian Feng","Yujie Zhong","Yu Gao","Matthew R. Scott","Weilin Huang"],"url":"https://arxiv.org/abs/2108.07755","pdfUrl":"https://openaccess.thecvf.com/content/ICCV2021/papers/Feng_TOOD_Task-Aligned_One-Stage_Object_Detection_ICCV_2021_paper.pdf","codeUrl":"https://github.com/fcjian/TOOD","preprint":{"id":"2108.07755","submittedOn":"2021-08-17","url":"https://arxiv.org/abs/2108.07755"},"publication":{"venue":"ICCV","year":2021,"kind":"conference","url":"https://openaccess.thecvf.com/content/ICCV2021/html/Feng_TOOD_Task-Aligned_One-Stage_Object_Detection_ICCV_2021_paper.html"},"citation":"@misc{objectdetectiontood2021,\n  title = {{TOOD: Task-aligned One-stage Object Detection}},\n  author = {Chengjian Feng and Yujie Zhong and Yu Gao and Matthew R. Scott and Weilin Huang},\n  year = {2021},\n  eprint = {2108.07755},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2108.07755}\n}\n","citationPath":"/content/papers/citations/object-detection/tood.4de53d61811e.bib"},"thumbnail":{"src":"/content/papers/assets/d5560386911d14104af5e1609a50f0af6db4f571f764de0e5f60f48ff30f4584.jpg","width":904,"height":772},"locale":"en","path":"/content/papers/en/object-detection/tood.cf11810df802.md","headings":[{"id":"problem-definition","text":"Problem Definition","depth":2},{"id":"problem-solving","text":"Problem Solving","depth":2},{"id":"task-interaction-features","text":"Task Interaction Features","depth":3},{"id":"tap-layer-wise-attention","text":"TAP: Layer-wise Attention","depth":3},{"id":"explicit-alignment-m-and-o","text":"Explicit Alignment: M and O","depth":3},{"id":"task-aligned-sample-assignment","text":"Task-aligned Sample Assignment","depth":3},{"id":"loss-design","text":"Loss Design","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"is-t-head-worth-replacing","text":"Is T-head Worth Replacing?","depth":3},{"id":"tal-effectiveness","text":"TAL Effectiveness","depth":3},{"id":"the-complete-tood","text":"The Complete TOOD","depth":3},{"id":"comparison-with-sota","text":"Comparison with SOTA","depth":3},{"id":"did-alignment-actually-happen","text":"Did “Alignment” Actually Happen?","depth":3},{"id":"how-was-misalignment-improved","text":"How Was Misalignment Improved?","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{"solution":"problem-solving","share-first-then-select-features-for-each-task":"task-interaction-features","align-the-outputs-too-m-and-o":"explicit-alignment-m-and-o","tal-measure-score-and-box-with-one-ruler":"task-aligned-sample-assignment","experimental-results-and-discussion":"discussion","swap-in-the-t-head-first":"is-t-head-worth-replacing","tal-assignment-soft-targets-and-schedule":"tal-effectiveness","complete-tood-and-test-dev":"the-complete-tood","did-alignment-actually-improve":"did-alignment-actually-happen"},"guide":null,"relatedReading":[{"id":"object-detection/fcos","relation":"comparison","topic":"Aligning classification and localization quality"},{"id":"object-detection/gfl","relation":"comparison","topic":"Aligning classification and localization quality"}]}],"text":"YOLO26 is a real-time object detection model from Ultralytics, the company that maintains the open-source `ultralytics` library and made YOLOv5, YOLOv8, and YOLO11. Give YOLO26 a photo and it returns a list of boxes, each with a class and a confidence score; the same backbone also handles instance segmentation, pose estimation, oriented-box detection, and image classification. The model comes in five sizes, n, s, m, l, and x. The smallest, n, has only 2.4 million parameters and is aimed at compute-constrained edge devices such as phones and embedded boards.\n\nIt debuted on September 25, 2025, at YOLO Vision 2025, the event Ultralytics held in London, and was officially released with `ultralytics` 8.4.0 on January 14, 2026. The first highlight in the release notes was its native end-to-end design, with inference needing no NMS post-processing at all; next came 43% faster CPU inference, the new MuSGD optimizer, and the removal of DFL. [Ultralytics blog, 2025-09-29](https://www.ultralytics.com/blog/ultralytics-key-highlights-from-yolo-vision-2025), [Ultralytics v8.4.0](https://github.com/ultralytics/ultralytics/releases/tag/v8.4.0)\n\nThe paper didn't reach arXiv until June 2026. Earlier Ultralytics YOLO generations had only code and online documentation, and when this paper cites YOLOv8 and YOLO11, it even adds “no formal paper” after their reference entries. This time we finally get to see the reasoning and ablations behind each design.\n\nIn 2024, YOLOv10 had already trained two output heads together, dropping the one-to-many head at inference and using only the one-to-one head. YOLO26 keeps both heads in the same set of weights; the paper's default is the one-to-one head without NMS, and when accuracy matters most, you can switch to the one-to-many head followed by NMS.\n\nWhen two heads train together, how should the training effort be split between them? And how much accuracy does the head used for deployment give up? Most of the paper's methods and experiments revolve around these two questions.\n\n\n> [!NOTE]\n> \n> If you're not yet familiar with NMS and one-to-one matching, here's a bit of background. YOLO guesses a box at every position, and during training it lets several positions near an object all count as positives (one-to-many), so at inference the same object shows up in several boxes, and NMS has to sort them by score and delete same-class boxes that overlap too much. One-to-one assignment gives each object only one positive, so the model learns to report each object just once and needs no NMS at inference. For YOLOv10's dual-head design, see our note:\n> \n> - **[[24.05] YOLOv10: Goodbye NMS](/blog/papers/object-detection/yolov10)**\n\n\n## Problem Definition\n\nThe authors argue that YOLO has stayed the industry's most widely used real-time detector for two reasons. First, it uses only standard convolution operations, so it can be exported directly to inference environments such as TensorRT, ONNX, CoreML, TFLite, OpenVINO, NCNN, and ExecuTorch; second, the same backbone and neck can support detection, segmentation, pose, and other tasks at once. DETR-family real-time models such as RT-DETR, D-FINE, DEIM, and RF-DETR have caught up in accuracy, but the authors argue that they often depend on large pre-trained backbones, custom operators like deformable attention, or fixed input resolutions, which makes them harder to deploy across hardware. This is Ultralytics' own position, worth keeping in mind when reading the comparison tables later.\n\nNext, the authors list four limitations of existing YOLO detectors:\n\n1. **NMS and dual-head training**. Most CNN detectors still rely on NMS at inference to remove duplicate boxes. YOLOv10 used two heads to get rid of NMS, but gave both heads the same loss weights from start to finish; the authors argue that the one-to-one head, the only one used at inference, was therefore never trained as far as it could go.\n2. **DFL's parameters and range**. The DFL used since YOLOv8 expands each position's box from 4 numbers to 4K logits (usually K=16), inflating the head's parameters along with it. Removing DFL from YOLO11n cuts its parameters from 2.6M to 2.3M and its GFLOPs from 6.5 to 5.2. DFL also caps how large a box can be.\n3. **Training takes too long**. The standard SGD recipe needs about 600 epochs to reach competitive accuracy on COCO, which makes quickly trying out new ideas expensive.\n4. **The smallest objects get no positives**. Label assignment schemes like TAL only consider positions whose center points fall inside the ground-truth box; when an object is smaller than the smallest stride, there may be no position inside its box at all, and it contributes no gradient for the whole of training.\n\nYOLO26 builds on YOLO11 and addresses these four points in turn with two heads plus Progressive Loss (written ProgLoss on Ultralytics' blog), direct regression in place of DFL, the MuSGD optimizer, and STAL (Small-Target-Aware Label Assignment).\n\n## Solution\n\n### Training Pipeline\n\nFigure 2 of the paper draws the whole training pipeline; read it from left to right.\n\n[![YOLO26 training pipeline diagram: on the far left is Backbone + Neck, which splits into two lines, the One-to-Many Branch (TAL topk = 10) above and the One-to-One Branch (TAL topk = 7, topk2 = 1) below; both lines enter Task-Aligned Assignment, then compute the One-to-Many Loss and One-to-One Loss separately, which go to Progressive Loss Weighting (the one-to-many weight falls from 0.8 to 0.1) and finally to the MuSGD Optimizer](/content/papers/assets/81b8a4e821bdb84f6040563add1c1f2341963826d993348c64cab2715e5d6e93.png)](/content/papers/assets/81b8a4e821bdb84f6040563add1c1f2341963826d993348c64cab2715e5d6e93.png)\n\n*Figure 2 from the paper (Jocher et al.), excerpted from [**page 6 of the v1 PDF**](https://arxiv.org/pdf/2606.03748v1#page=6), CC BY 4.0. YOLO26's training pipeline.*\n\nThe backbone and neck extract multi-scale features and hand them to both detection heads at once. Both heads pick positives with TAL (Task-Aligned Assignment); the one-to-many head is labeled topk = 10, and the one-to-one head topk = 7, topk2 = 1. Each side computes its own box and class losses, progressive loss weighting adds them together, and MuSGD then updates the parameters. STAL isn't drawn in the figure; it's tucked into the step where TAL picks candidates.\n\nTable 1 of the paper lists what these components are called in the ultralytics library. The dual heads live in `Detect`, direct regression corresponds to `reg_max=1`, STAL is in `TaskAlignedAssigner`, progressive loss is `E2ELoss`, and the optimizer is simply called `MuSGD`. The implementation details below follow the code in version 8.4.0.\n\n### Two Heads, Each Picking Its Own Positives\n\nA 640×640 photo passes through feature maps at strides 8, 16, and 32, sized 80×80, 40×40, and 20×20, for a total of 8,400 positions. Both heads output a set of class scores and one box at every position; the only difference is which positions count as positives during training.\n\nTAL scores every position against every annotated object, and the score is high only when both classification and localization are accurate. Ultralytics' implementation writes it as $s^{0.5}\\cdot u^{6}$, where $s$ is the position's score for the annotated class and $u$ is the IoU between the predicted box and the ground-truth box; the consistent matching metric that YOLOv10's two heads share uses the same exponents. Before scoring, only positions whose center points fall inside the ground-truth box can be candidates.\n\n- **One-to-many head**: takes up to the top 10 per object as positives. At inference, its output shape is `(N, nc+4, 8400)`, where `N` is the batch size and `nc` the number of classes, and NMS has to follow.\n- **One-to-one head**: first takes the top 7 as candidates, resolves cases where several objects claim the same position, and keeps only the top 1 for each object. At inference, it picks the 300 highest-scoring of the 8,400 positions and outputs `(N, 300, 6)`, where each row holds the box's four coordinates, the score, and the class, with no IoU suppression of any kind.\n\nThe two heads hand over very different amounts of output. For COCO's 80 classes, the one-to-many head outputs 84×8,400 = 705,600 numbers per image, and NMS has to sift through 8,400 candidates; the one-to-one head outputs just 300×6 = 1,800.\n\n\n> [!NOTE]\n> \n> During training, the one-to-one head receives `detach()`ed features, so its gradients don't flow back into the backbone and neck; the shared features are shaped only by the one-to-many head's loss. The paper doesn't mention this detail; on the current main branch, this line carries the comment “detach keeps one2one out of the backbone.” YOLOv10's official implementation is wired the same way.\n\n\n### Progressive Loss\n\nProgressive loss decides how the two heads' losses are added together. Equations (2) and (3) of the paper are:\n\n$$\n\\mathcal{L}_{\\text{total}} = \\alpha(t)\\,\\mathcal{L}_{\\text{one2many}} + \\bigl(1-\\alpha(t)\\bigr)\\,\\mathcal{L}_{\\text{one2one}}\n$$\n\n$$\n\\alpha(t) = \\max\\!\\left(1-\\frac{t}{\\max(E-1,\\,1)},\\ 0\\right)\\bigl(\\alpha_{\\text{init}}-\\alpha_{\\text{final}}\\bigr)+\\alpha_{\\text{final}}\n$$\n\n$t$ is the current epoch (counting from 0), and $E$ is the total number of epochs. The implementation uses $\\alpha_{\\text{init}}=0.8$ and $\\alpha_{\\text{final}}=0.1$, updated once at the end of every epoch (§4.1). In other words, the one-to-many and one-to-one weights start at 0.8 to 0.2 and move in a straight line to 0.1 to 0.9.\n\nThe authors' reasoning is that the one-to-many head, with its many positives, is easy to train early on and can steady the features first; the one-to-one head has stricter conditions, but it's the one that ultimately decides the output at deployment. With fixed weights from start to finish, as in YOLOv10, the head used for deployment doesn't get enough of the effort.\n\nLet's work it out for a 100-epoch run:\n\n```python\ndef o2m_weight(t, E, a_init=0.8, a_final=0.1):\n    # Eq. (3) of the paper: t is the current epoch (counting from 0), updated once at the end of each epoch\n    return max(1 - t / max(E - 1, 1), 0) * (a_init - a_final) + a_final\n\nE = 100\nfor t in (0, 25, 42, 43, 75, 99):\n    a = o2m_weight(t, E)\n    print(f\"epoch {t:>2}: one-to-many {a:.3f}, one-to-one {1 - a:.3f}\")\n```\n\n```text\nepoch  0: one-to-many 0.800, one-to-one 0.200\nepoch 25: one-to-many 0.623, one-to-one 0.377\nepoch 42: one-to-many 0.503, one-to-one 0.497\nepoch 43: one-to-many 0.496, one-to-one 0.504\nepoch 75: one-to-many 0.270, one-to-one 0.730\nepoch 99: one-to-many 0.100, one-to-one 0.900\n```\n\nBetween epochs 42 and 43, the two weights cross. In general, $\\alpha(t)=0.5$ falls at $t/(E-1)=3/7$; that is, once training is about 43% of the way through, the one-to-one head starts getting the larger weight.\n\nNow back to that `detach()`. The backbone and neck get gradients only from the one-to-many loss, with a coefficient of $\\alpha(t)$ that falls from 0.8 to 0.1; the one-to-one head updates only its own set of convolutions, with a coefficient rising from 0.2 to 0.9. How much each step actually changes the weights also depends on the optimizer; the Muon part of MuSGD first orthogonalizes the update matrix, so the size of the update barely depends on how the gradient is scaled.\n\n### Dropping DFL\n\nDFL (Distribution Focal Loss) comes from GFL. Instead of regressing a single number for how far each edge of the box is from the center point, it predicts a probability distribution over K bins and takes the expected value:\n\n$$\nd=\\sum_{i=0}^{K-1} i\\cdot\\operatorname{softmax}(z)_i,\\qquad z\\in\\mathbb{R}^{K}\n$$\n\nYOLOv8 through YOLO11 all use K=16, which brings two costs.\n\nThe first is output size. Each position's box goes from 4 numbers to 64 logits; across 8,400 positions, that's 537,600 versus 33,600.\n\nThe second is range. The expected value $d$ can be at most $K-1=15$, and after multiplying by the stride, each edge reaches at most 15 strides. On the stride-32 level, an edge can extend at most 480 pixels, putting the maximum box width at about 960 pixels. With the input enlarged to 1280, large objects can exceed that.\n\nWhere the parameters get saved depends on how the Ultralytics detection head is written. The box branch's channel width is `max(16, ch // 4, 4 * reg_max)`, where `ch` is the channel count of the shallowest feature level (stride 8). YOLO11n's `ch` is 64; with DFL, `reg_max=16` and the width is max(16, 16, 64) = 64; without DFL, `reg_max=1` and the width drops to 16. Counting the parameters of the three box branches with this formula gives about 382,000 with DFL and about 72,000 without, a difference of 310,000, which matches the paper's drop from 2.6M to 2.3M. Apply the same calculation to the m model, where `ch // 4` is already 64, and the widths are the same either way, a difference of only about 12,000 parameters. DFL's parameter cost falls mainly on the two small models, n and s.\n\nYOLO26 instead predicts the four distances directly (`reg_max=1`) and adds an L1 loss. If you read YOLO26's training config, you'll find the `dfl` field is still there; in YOLO26 it has become the weight of the L1 regression loss (Appendix S3), and a nonzero value switches on the L1 loss.\n\n\n> [!TIP]\n> \n> For where DFL came from, see our note:\n> \n> - **[[20.06] GFL: Unified Focus](/blog/papers/object-detection/gfl)**\n\n\n### STAL\n\nAs mentioned earlier, TAL picks candidates only at positions whose center points fall inside the ground-truth box. A 6×6-pixel object that happens to sit between two rows of center points on the stride-8 level gets no candidates at all. STAL changes only this candidate-selection step, stretching any side narrower than the smallest stride (8 pixels) to the next level's stride (16 pixels); the scoring, matching, and box regression that follow still use the original box.\n\nLet's place a 6×6 object centered at (96, 96) and see what happens:\n\n```python\ndef centers(stride, size=640):\n    # Center coordinates (pixels) of each grid cell, e.g. 4, 12, 20, ... for stride 8\n    return [(i + 0.5) * stride for i in range(size // stride)]\n\ndef n_candidates(cx, cy, w, h, stride):\n    x1, x2, y1, y2 = cx - w / 2, cx + w / 2, cy - h / 2, cy + h / 2\n    xs = [c for c in centers(stride) if x1 < c < x2]\n    ys = [c for c in centers(stride) if y1 < c < y2]\n    return len(xs) * len(ys)\n\ndef stal(w, h, s_min=8, s_ref=16):\n    # Only when picking candidates, stretch any side smaller than the minimum stride to s_ref\n    return (s_ref if w < s_min else w), (s_ref if h < s_min else h)\n\ncx, cy, w, h = 96, 96, 6, 6\nfor name, (bw, bh) in [(\"Original box\", (w, h)), (\"After STAL\", stal(w, h))]:\n    counts = {s: n_candidates(cx, cy, bw, bh, s) for s in (8, 16, 32)}\n    print(f\"{name} {bw}×{bh}:\", counts, \"total\", sum(counts.values()))\n```\n\n```text\nOriginal box 6×6: {8: 0, 16: 0, 32: 0} total 0\nAfter STAL 16×16: {8: 4, 16: 0, 32: 0} total 4\n```\n\nThe original box runs from 93 to 99, and the stride-8 center points at 92 and 100 both fall just outside it; the other two levels are sparser and have none either. Stretched to 16×16, the box runs from 88 to 104, and the stride-8 points at 92 and 100 both come inside, two in each direction, for 4 candidates.\n\nThis position was picked on purpose. We also placed objects at random across the whole image, 20,000 trials per size. For 2×2, 4×4, and 6×6 objects, about 92%, 67%, and 34% of placements, respectively, got no candidates at all; after stretching, every trial had at least one candidate. This only counts the candidate-selection step; which candidates end up as positives still depends on TAL's scores.\n\n\n> [!TIP]\n> \n> TAL's scoring scheme comes from TOOD; see our note:\n> \n> - **[[21.08] TOOD: The End of Misalignment](/blog/papers/object-detection/tood)**\n\n\n### MuSGD\n\nMuSGD blends two optimizers. Muon accumulates momentum as usual, then orthogonalizes this update matrix with a few Newton–Schulz iterations; the paper cites Moonshot AI's research saying it is about twice as compute-efficient as AdamW for training large language models. For multi-dimensional parameters such as convolution kernels and linear layers, MuSGD adds the Muon and SGD updates in proportion; for one-dimensional parameters such as biases and normalization-layer scales, it uses SGD only. The release notes mention that the idea comes from Moonshot AI's Kimi K2.\n\nThe paper also designs separate heads and losses for segmentation, pose, and oriented boxes, and puts YOLO26's detector into the open-vocabulary YOLOE to make YOLOE-26. This note covers only object detection.\n\n## Discussion\n\n### From YOLO11s to YOLO26s, One Step at a Time\n\nTable 2 of the paper starts from YOLO11s and adds one change at a time. In the table, E2E means the one-to-one head without NMS, and non-E2E means the one-to-many head with NMS.\n\n| Step | AP (E2E) | AP (non-E2E) | Params (M) | GFLOPs | Latency (ms) |\n| --- | ---: | ---: | ---: | ---: | ---: |\n| YOLO11s baseline | – | 47.0 | 9.4 | 21.5 | 2.5 |\n| Remove DFL | – | 46.4 | 9.1 | 20.1 | 2.3 |\n| Add L1 loss | – | 46.6 | 9.1 | 20.1 | 2.3 |\n| Add STAL | – | 46.8 | 9.1 | 20.1 | 2.3 |\n| Tweak backbone and neck | – | 47.0 | 9.5 | 20.7 | 2.5 |\n| Add one-to-one head | 46.4 | 47.0 | 9.5 | 20.7 | 2.5 |\n| Progressive loss | 46.7 | 47.2 | 9.5 | 20.7 | 2.5 |\n| MuSGD | 47.1 | 47.6 | 9.5 | 20.7 | 2.5 |\n| Objects365 pre-training | 47.4 | 48.0 | 9.5 | 20.7 | 2.5 |\n| Hyperparameter search | 47.8 | 48.6 | 9.5 | 20.7 | 2.5 |\n\n*Table: Table 2 of the paper.*\n\n1. **Removing DFL first costs 0.6 AP**, and the L1 loss, STAL, and the backbone and neck tweaks (an extra attention layer inserted into the neck) each win back 0.2. After these four steps, AP is back at 47.0, GFLOPs fall from 21.5 to 20.7, and latency holds steady.\n2. **Adding the one-to-one head leaves the one-to-many path no worse**, still at 47.0; the one-to-one head scores 46.4, 0.6 lower.\n3. **Progressive loss gives the one-to-one head another 0.3**, and the one-to-many head gains 0.2 as well.\n4. **The last two rows have nothing to do with architecture**. The one-to-many head goes from 47.0 to 48.6, and 1.0 of those 1.6 AP comes from Objects365 pre-training and hyperparameter search.\n\nThis ablation doesn't say how many epochs were trained, and each row is a single run. The paper doesn't report the variance across repeated runs, so differences of 0.2 to 0.4 AP should be read cautiously.\n\n### How the Weights Are Scheduled\n\nTable 5 compares six schedules on the same YOLO11s setup; the numbers are the AP of the one-to-one head without NMS:\n\n| Start (one-to-many, one-to-one) | End (one-to-many, one-to-one) | AP (E2E) |\n| --- | --- | ---: |\n| (0.5, 0.5) | (0.5, 0.5) | 46.4 |\n| (1.0, 0.0) | (0.1, 0.9) | 46.4 |\n| (1.0, 0.0) | (0.2, 0.8) | 46.4 |\n| (1.0, 0.0) | (0.3, 0.7) | 46.3 |\n| (0.8, 0.2) | (0.1, 0.9) | 46.7 |\n| (0.9, 0.1) | (0.1, 0.9) | 46.3 |\n\n*Table: Table 5 of the paper, based on YOLO11s.*\n\nA fixed 0.5 to 0.5 gives 46.4, and the default, 0.8 to 0.2 moving to 0.1 to 0.9, gives 46.7; these two cells match the “Add one-to-one head” and “Progressive loss” rows of Table 2 exactly. The three schedules where the one-to-one weight starts from 0 land between 46.3 and 46.4, no better than fixed weights. From this, the authors conclude that the one-to-one head needs a little supervision from the very start, increased gradually after that.\n\nThen again, the schedule starting at 0.9 to 0.1 scores 46.3 in the table, on par with the schedules that start from 0, so “a little from the start” doesn't hold up as a pattern yet either. Read conservatively, the table puts the default schedule 0.3 AP above fixed weights in this setup, with every other schedule within 0.1 of fixed weights.\n\n### Three More Ablations\n\n1. **DFL**. Table 3 trains from scratch with the YOLO26s setup, differing only in whether DFL is used. At 640 resolution, removing DFL raises AP from 46.0 to 46.3 and large-object $\\text{AP}_L$ from 62.8 to 63.8; at 1280 resolution, AP rises from 49.8 to 51.1 and $\\text{AP}_L$ from 61.8 to 64.0, while small and medium objects drop slightly. Set against the 0.6 drop on YOLO11s in Table 2, whether removing DFL pays off depends on the rest of the setup; the authors attribute the large-object gain at high resolution to DFL's range cap. The table doesn't say which head's AP it reports.\n2. **MuSGD**. Table 4 trains on COCO from scratch, where SGD reaches 47.0 in 600 epochs and MuSGD reaches 47.4 in 500. The paper doesn't state the model size or report actual training time; the Newton–Schulz iterations add computation at every step, so 16.7% fewer epochs may not save that much time. In the ImageNet classification comparison (Appendix Table S1), top-1 improves by 0.4 to 1.4 at all five sizes.\n3. **STAL**. In Table 6, based on YOLO11s, the original TAL gives 46.6 with a small-object $\\text{AP}_S$ of 29.0; stretching to 16 pixels gives 46.8 with an $\\text{AP}_S$ of 29.6. Stretching to 8 pixels actually drops $\\text{AP}_S$ to 27.7, and stretching to 32 pixels lowers the overall score to 46.5. The default of 16 pixels adds 0.2 AP overall.\n\n### How Far Apart Are the Two Heads?\n\nTable 7 gives the released models' COCO results, listing the accuracy of both heads:\n\n| Model | mAP (one-to-many + NMS) | mAP (one-to-one) | Gap | T4 TensorRT (ms) | CPU ONNX (ms) | Params (M) |\n| --- | ---: | ---: | ---: | ---: | ---: | ---: |\n| YOLO26n | 40.9 | 40.1 | 0.8 | 1.7 | 38.9 | 2.4 |\n| YOLO26s | 48.6 | 47.8 | 0.8 | 2.5 | 87.2 | 9.5 |\n| YOLO26m | 53.1 | 52.5 | 0.6 | 4.7 | 220.0 | 20.4 |\n| YOLO26l | 55.0 | 54.4 | 0.6 | 6.2 | 286.2 | 24.8 |\n| YOLO26x | 57.5 | 56.9 | 0.6 | 11.8 | 525.8 | 55.7 |\n\n*Table: Table 7 of the paper, COCO val2017, 640×640 input; the “Gap” column is computed for this note. The CPU is an Intel Xeon @ 2.00 GHz running ONNX.*\n\nAt all five sizes, the one-to-one head is 0.6 to 0.8 AP below one-to-many plus NMS. The authors write in §4.4 that if the target platform can run NMS efficiently and AP matters most, the one-to-many head can still be the first choice; when deployment simplicity, ease of integration, or skipping NMS matters more, go with the default one-to-one head.\n\nLet's compare the gap with YOLOv10's. The YOLOv10 paper reports gaps of 1.0 for N, 0.5 for S, 0.2 for M, B, and L, and 0 for X. YOLOv10, however, compares against a separate model trained only one-to-many and followed by NMS, while YOLO26 directly compares the two heads within the same set of weights. The two sets of numbers measure different things, so there's no telling whose one-to-one head is better trained. YOLO26's gap doesn't vanish on large models either; the x model still trails by 0.6.\n\nThe one-to-one head doesn't guarantee freedom from duplicate boxes either. In July 2026, someone reported nearly overlapping duplicate boxes in YOLO26n-obb predictions, and an Ultralytics collaborator replied that YOLO26n sometimes does this, that NMS can be added on top when needed, and that with so few boxes it should be fast. [ultralytics #25304](https://github.com/ultralytics/ultralytics/issues/25304)\n\n§3.5 of the paper also notes that some runtimes don't support the top-K operation that end-to-end decoding needs, and exports for them automatically fall back to the one-to-many head. Ultralytics' end-to-end guide lists formats such as NCNN, RKNN, Edge TPU, and Qualcomm QNN that fall back this way when their operators can't support end-to-end output. [Ultralytics end-to-end detection guide](https://docs.ultralytics.com/guides/end2end-detection/)\n\n### The Headline Numbers Come from Two Heads\n\nThe paper's abstract says YOLO26 reaches 40.9–57.5 mAP on COCO at 1.7–11.8 ms of T4 TensorRT latency. The accuracy range is the one-to-many plus NMS results from Table 7, while a footnote in Ultralytics' docs says latency is measured on the one-to-one head without NMS (`nms=False`). Deployed without NMS, the corresponding accuracy is 40.1 to 56.9; going with the one-to-many head, the latency has to include NMS time that isn't in the table. [YOLO26 docs](https://docs.ultralytics.com/models/yolo26/)\n\nAppendix Table S9, for the segmentation models, lists the two heads' latencies separately, neither including NMS. For the n model on a T4, the one-to-one head takes 2.1 ms and the one-to-many head 2.0 ms; for the x model, it's 16.4 ms versus 16.8 ms. Looking at the model alone, the two paths are about equally fast, and the one-to-one head saves the NMS step.\n\nThe “43% faster” CPU claim comes with conditions too. The paper states that this compares YOLO26n with YOLO11n running ONNX on an Intel Xeon CPU. Per the tables in the two official docs pages, YOLO11n takes 56.1 ms and YOLO26n 38.9 ms, which is 1.44 times the throughput, or about 31% less latency. Matching up the other sizes one by one, the s model goes from 90.0 ms to 87.2 ms, about the same; for m, l, and x, YOLO26 is actually 14% to 20% slower than YOLO11. On the T4, the n model is 1.5 ms versus 1.7 ms, with YOLO26 slightly slower. The YOLO11 docs don't say whether their latency includes NMS. [YOLO11 docs](https://docs.ultralytics.com/models/yolo11/)\n\nNow look at the paper's headline figure. The y-axis is COCO mAP, and the x-axis is latency on a T4 with TensorRT10 and FP16:\n\n[![Scatter plot of accuracy versus latency on COCO val2017: the x-axis is T4 TensorRT10 FP16 latency (0 to 16 ms), and the y-axis is COCO mAP 50-95 (37.5 to 57.5). The dark blue YOLO26 curve runs from 26n (about 1.7 ms, 40.9) to 26x (about 11.8 ms, 57.5), above the other curves; the other curves are YOLO11, YOLOv10, YOLOv9, YOLOv8, YOLOv7, YOLOv6-3.0, YOLOv5, PP-YOLOE+, DAMO-YOLO, and RTMDet](/content/papers/assets/ab67bb3bd246062be0c7a56a363c356177cca42c6e7349343402535b7b723f2c.png)](/content/papers/assets/ab67bb3bd246062be0c7a56a363c356177cca42c6e7349343402535b7b723f2c.png)\n\n*Figure 1 from the paper (Jocher et al.), excerpted from [**page 1 of the v1 PDF**](https://arxiv.org/pdf/2606.03748v1#page=1), CC BY 4.0. Accuracy and latency on COCO val2017.*\n\nThe dark blue line is YOLO26, and its points reuse the numbers above, pairing one-to-many plus NMS mAP with the one-to-one head's latency. All the other lines are YOLO models, plus three CNN detectors, PP-YOLOE+, DAMO-YOLO, and RTMDet.\n\nWhen the paper made it onto Hacker News, a user who identified as a Roboflow co-founder objected that the paper's headline figure included only one DETR, from 2022, while claiming the best AP–latency trade-off. Roboflow develops RF-DETR and is a direct competitor of Ultralytics. [Hacker News, 2026-06-23](https://news.ycombinator.com/item?id=48639434) The figure itself doesn't contain a single DETR-family model. DETR-family real-time models appear only in Appendix Table S8, which has RT-DETRv2, D-FINE, and DEIM; RF-DETR, which the paper's introduction mentions, is left out of the comparison.\n\nIn the x tier of Table S8, YOLO26x is 57.5 AP at 11.8 ms, DEIM-X is 56.5 AP at 12.9 ms, and D-FINE-X is 55.8 AP at 12.9 ms. Here too, YOLO26's AP comes from one-to-many plus NMS and its latency from the one-to-one head; YOLO26 was also pre-trained on Objects365, whereas the D-FINE and DEIM rows are versions trained only on COCO. D-FINE's own published Objects365-pre-trained X model reaches 59.3 AP. [D-FINE](https://github.com/Peterande/D-FINE) For how the DETR side measures latency and accounts for NMS time, compare with our note on [RF-DETR](/blog/papers/object-detection/rf-detr).\n\n## Conclusion\n\nYOLO26 keeps both heads, uses progressive loss to shift the training emphasis gradually from one-to-many to one-to-one, then drops DFL, switches to MuSGD, and adds STAL. Put together, the paper's evidence comes down to roughly these points:\n\n1. **The one-to-one head is 0.6 to 0.8 AP lower at all five sizes**, in exchange for a fixed output of at most 300 boxes with no NMS.\n2. **The direct evidence for progressive loss is a single ablation**. On YOLO11s, the default schedule is 0.3 AP above fixed weights; schedules starting from 0 do no better than fixed weights.\n3. **The parameters saved by dropping DFL are concentrated in n and s**, and at high resolution the change favors large objects. STAL guarantees candidates for objects smaller than 8 pixels and adds 0.2 AP overall.\n4. **Part of the gain over YOLO11 comes from the training recipe**. Of the s model's 1.6 AP, 1.0 comes from Objects365 pre-training and hyperparameter search.\n\nWhen the paper was written, the default was still the one-to-one head. `ultralytics` 8.4.142, released on September 5, 2026, changed YOLO26's default for prediction and validation to the one-to-many head plus NMS, on the grounds that it is usually more accurate than the one-to-one head without NMS; to use the NMS-free head, you have to set `nms=False` yourself. Both heads are still trained; only validation, checkpoint selection, and early stopping now follow the selected head. [Ultralytics v8.4.142](https://github.com/ultralytics/ultralytics/releases/tag/v8.4.142)\n\nSo before comparing YOLO26 with other detectors, first decide which head your deployment will use, then compare that same head's accuracy and latency; Ultralytics' end-to-end guide recommends the same. If you're running on a CPU, the n model shows the clearest speedup, while m and up are slower than YOLO11 in the official tables. On HN, someone also said that YOLO26 did worse than v9 and v11 on their own soccer-video task, though they gave no numbers; on your own data, you still have to measure for yourself. Also, the `ultralytics` library is licensed under AGPL-3.0, so check the license as well before building a product on it.\n","imageSizes":{"/content/papers/assets/81b8a4e821bdb84f6040563add1c1f2341963826d993348c64cab2715e5d6e93.png":{"width":1494,"height":367},"/content/papers/assets/ab67bb3bd246062be0c7a56a363c356177cca42c6e7349343402535b7b723f2c.png":{"width":1362,"height":633}}}