YOLO26, il rilevatore in tempo reale che rinuncia al filtro finale

Ultralytics pubblica il paper di YOLO26, la famiglia di rilevatori che toglie la non-maximum suppression dall'inferenza, alleggerisce la testa di regressione e prende in prestito dai modelli linguistici l'ottimizzatore Muon. Cosa cambia per chi deve far girare un modello di visione su un dispositivo, quanto valgono i guadagni sui numeri del paper e dove il confronto è più generoso del necessario.

Immaginate un’aula d’esame in cui ogni studente può consegnare quante risposte vuole alla stessa domanda. Alla fine un correttore paziente deve sfogliare la pila, riconoscere i doppioni e tenere solo la versione migliore di ciascuna. Il lavoro si fa, ma dopo, e con una regola rigida: se due risposte si somigliano più di tanto, una delle due va buttata. Un’aula diversa chiede a ogni studente di consegnare una risposta sola, e passa la fatica a monte, all’allenamento. Niente correttore alla fine, niente regola da tarare.

Quasi tutti i rilevatori di oggetti basati su reti convoluzionali lavorano come la prima aula. La rete propone migliaia di riquadri, molti dei quali inquadrano lo stesso pedone, e un passaggio a valle chiamato non-maximum suppression (NMS) sfoltisce i doppioni. Ultralytics YOLO26: Unified Real-Time End-to-End Vision Models, pubblicato su arXiv il 2 giugno 2026 (2606.03748) da sei ricercatori di Ultralytics, e in queste settimane fra i paper più seguiti su Papers with Code, descrive una famiglia di modelli costruita per la seconda aula. Non è la prima a provarci, nemmeno dentro la stirpe YOLO (YOLOv10 lo ha fatto nel 2024), ma qui l’inferenza senza NMS diventa l’impostazione predefinita della famiglia che, dice il paper, è ancora il rilevatore in tempo reale più diffuso nell’industria.

Che cosa sia un riquadro di rilevamento, perché servano la non-maximum suppression e l’intersection over union, e come YOLO predica tutto in un solo passaggio: il libro lo spiega dall’inizio.

Leggi «Detection e segmentazione» nel libro →

Perché conta adesso

Il campo dei rilevatori in tempo reale, negli ultimi due anni, si è diviso. Da una parte la stirpe YOLO, fatta di convoluzioni standard. Dall’altra gli eredi di DETR (RT-DETR, D-FINE, DEIM, RF-DETR), che trattano il rilevamento come la previsione di un insieme e quindi non hanno bisogno di NMS, ma che, osserva il paper, spesso poggiano su grandi backbone preaddestrati, attenzione deformabile o risoluzioni fisse. Sono scelte che complicano la vita a chi deve esportare il modello su un acceleratore di un’automobile o su un telefono.

YOLO26 prova a tenere il meglio delle due strade: l’inferenza senza NMS dei transformer, dentro un’architettura che resta convoluzionale e quindi esportabile. Il paper elenca 19 formati di destinazione oltre a PyTorch, da ONNX e TensorRT a CoreML, TensorFlow Lite, NCNN ed ExecuTorch. È questo il motivo per cui il lavoro interessa anche a chi non ha mai letto un paper di visione: è probabile che finisca, per inerzia, in molti dei progetti che oggi usano YOLOv8 o YOLO11.

Due teste, una sola in produzione

L’idea di fondo viene da YOLOv10 (2024): la rete ha due teste che condividono backbone e collo. La testa «uno-a-molti» è quella classica: durante l’addestramento a ogni oggetto vero vengono assegnate fino a 10 posizioni candidate, e in inferenza produce le solite migliaia di riquadri (8400 posizioni per un’immagine da 640 pixel) da sfoltire con NMS. La testa «uno-a-uno» impara invece ad assegnare a ogni oggetto una posizione sola: si parte da 7 candidati e se ne tiene uno. In inferenza restituisce al massimo 300 rilevamenti già puliti, e il filtro finale sparisce.

Il prezzo è misurato: sul COCO la testa senza NMS resta dietro di 0,6–0,8 punti di AP rispetto a quella con NMS, a tutte le taglie. Il paper la usa come impostazione predefinita e lascia l’altra come manopola per chi vuole l’ultimo decimale. C’è anche una clausola pratica: i runtime che non supportano le operazioni di top-K necessarie alla decodifica end-to-end ricadono, all’esportazione, sulla testa con NMS.

Dove finisce il lavoro: prima e dopo YOLO26 YOLO11 backbone + collo testa con DFL 4 × 16 valori per box 8400 proposte NMS soglia da tarare YOLO26 backbone + collo testa uno-a-uno 4 numeri per box al massimo 300 rilevamenti, nessun filtro (la testa uno-a-molti resta, facoltativa, per chi accetta la NMS) COCO: la via senza NMS perde 0,6–0,8 punti di AP rispetto a quella con NMS

Via la DFL: meno parametri, e un tetto in meno

La seconda scelta riguarda come la rete dice dove sta un bordo. Da YOLOv8 in poi, ogni lato del riquadro non è un numero ma una piccola distribuzione su $K$ caselle, di solito 16, letta come media pesata: è la Distribution Focal Loss (DFL),

$$d = \sum_{i=0}^{K-1} i \cdot \mathrm{softmax}(z)_i, \qquad z \in \mathbb{R}^K.$$

Funziona, ma costa: quattro lati per sedici caselle fanno 64 valori per posizione invece di 4. Per i modelli più piccoli la testa pesa sul totale, e il paper porta un esempio: YOLO11n passa da 2,6 a 2,3 milioni di parametri e da 6,5 a 5,2 GFLOPs togliendo solo la DFL. E c’è un tetto meno evidente. Poiché $d$ non può superare $K-1$, la distanza massima di un bordo dal centro è $(K-1)\,s$ pixel, dove $s$ è il passo della mappa: con $K = 16$ e $s = 32$ fa circa 960 pixel. A 640 pixel di risoluzione non si nota quasi; a 1280 un oggetto grande può non entrare nel riquadro.

YOLO26 torna alla regressione diretta di quattro numeri, con una loss L1. Il conto non è gratis: nel percorso a tappe da YOLO11s, togliere la DFL da sola costa 0,6 punti di AP (da 47,0 a 46,4), recuperati poi con la loss L1, STAL e un ritocco al collo. Il controllo del paper su YOLO26s, addestrato da zero con e senza DFL, dice che la versione senza guadagna 0,3 punti di AP a 640 pixel e 1,3 a 1280. Sugli oggetti grandi il guadagno sale da 1,0 a 2,2 punti. A 1280 però gli oggetti piccoli e medi perdono qualcosa: i piccoli passano da 36,0 a 35,9, i medi da 55,7 a 55,2. Il vantaggio è concentrato dove il tetto della DFL morde.

Tre ritocchi all’addestramento

Togliere la DFL e la NMS rende la rete più semplice ma più difficile da addestrare bene. Il paper compensa con tre interventi, e il più curioso arriva dai modelli linguistici.

MuSGD. Muon è un ottimizzatore che ortogonalizza l’aggiornamento delle matrici di pesi con qualche iterazione di Newton–Schulz; il paper cita il lavoro di Moonshot secondo cui, nell’addestramento degli LLM, è circa due volte più efficiente di AdamW. YOLO26 lo mescola con il classico SGD con momento sui tensori a più dimensioni (kernel di convoluzione, pesi lineari) e lascia SGD puro su bias e scale di normalizzazione. Addestrando da zero sul COCO, MuSGD arriva a 47,4 mAP in 500 epoche contro 47,0 di SGD in 600: un sesto di epoche in meno e quattro decimi in più.

SGD, momento e il resto della cassetta degli attrezzi per far convergere una rete profonda: nel libro, prima di capire che cosa Muon cambi.

Leggi «Far funzionare le reti profonde» nel libro →

Progressive Loss. YOLOv10 addestrava le due teste con lo stesso peso dall’inizio alla fine, e così la testa che va in produzione riceveva la stessa attenzione di quella che resta in panchina. YOLO26 sposta l’enfasi nel tempo:

$$\mathcal{L}_{\text{tot}} = \alpha(t)\,\mathcal{L}_{\text{uno-a-molti}} + \big(1-\alpha(t)\big)\,\mathcal{L}_{\text{uno-a-uno}},$$

con $\alpha(t)$ che scende in linea retta, un’epoca alla volta, da 0,8 a 0,1. All’inizio domina la testa densa, più facile da ottimizzare, che stabilizza le feature; alla fine domina quella che servirà davvero. Nell’ablazione il peso fisso 50/50 dà 46,4 di AP end-to-end, questo programma 46,7. Partire da un peso nullo sulla testa uno-a-uno non aiuta: la testa di produzione ha bisogno di un segnale fin dal primo giorno.

STAL. L’assegnazione delle etichette usata da YOLO considera candidate solo le posizioni della griglia che cadono dentro il riquadro vero. Su una griglia con passo di 8 pixel, un oggetto largo 5 pixel può non contenerne nessuna: zero candidati, zero gradiente, come se non esistesse. STAL (Small-Target-Aware Label Assignment) gonfia a 16 pixel, solo per la scelta dei candidati, ogni lato sotto gli 8; il riquadro vero resta quello su cui si calcolano punteggi e regressione. Il guadagno è piccolo in media, da 46,6 a 46,8 di AP, e più visibile sugli oggetti piccoli, da 29,0 a 29,6.

I numeri

Sul COCO le cinque taglie (n, s, m, l, x) vanno da 40,9 a 57,5 mAP con la NMS, e da 40,1 a 56,9 senza. Le latenze vanno da 1,7 a 11,8 millisecondi su una GPU T4 con TensorRT in FP16. A parità di taglia il miglioramento su YOLO11 è di 1,6–2,8 punti. Sulla CPU il paper dichiara fino al 43% di velocità in più per il modello nano rispetto a YOLO11n in ONNX, su un Xeon a 2 GHz; in tabella YOLO26n impiega 38,9 millisecondi per immagine.

Il resto della famiglia beneficia delle stesse scelte più alcuni ritocchi specifici: prototipi multi-scala e una loss semantica ausiliaria (solo in addestramento) per la segmentazione, una loss probabilistica che stima l’incertezza di ogni giuntura per la stima della posa, una nuova definizione dell’angolo per i riquadri orientati delle immagini aeree. Rispetto a YOLO11 i guadagni massimi sono +3,7 punti di AP sulle maschere, +7,2 sulla posa, +3,4 sul DOTA-v1.0. E c’è YOLOE-26, la variante a vocabolario aperto che accetta un nome o un’immagine d’esempio come richiesta: il modello più grande arriva a 40,6 AP sul LVIS minival con richieste testuali, 6,2 punti sopra DetCLIP-T. La voce più istruttiva, nella sua ablazione, è anche la più banale: un modello già addestrato ha ripassato i dati di addestramento trovando oggetti che gli annotatori avevano saltato, e aggiungerli come pseudo-etichette vale 1,1–1,3 punti, poco meno del passaggio all’intera architettura YOLO26, che ne vale 1,5.

Quello che il paper non dice, o dice piano

Il primo punto è di contesto: il paper è firmato dall’azienda che distribuisce il modello, e confronta soprattutto il modello con i propri predecessori. La tabella che lo mette accanto ai concorrenti (supplementare S8) è onesta nei numeri; un po’ meno l’introduzione, che parla di concorrenti superati lungo tutta la frontiera fra accuratezza e latenza. Alla taglia piccola il migliore non è YOLO26s (48,6) ma DEIM-S (49,0), che però impiega 3,5 millisecondi contro 2,5; nella sezione dei risultati il paper, correttamente, rivendica il primato solo per le taglie media, grande ed extra. RF-DETR, citato nell’introduzione come uno dei concorrenti diretti, nella tabella non c’è. E per YOLO26 vi compaiono i numeri della testa con NMS, non quelli della testa end-to-end che è la ragione d’essere del modello.

Il secondo punto riguarda le ablazioni. Ogni componente vale due o tre decimi di AP, misurati su un solo dataset e senza ripetizioni né barre d’errore dichiarate: differenze di quest’ordine stanno vicine al rumore di un addestramento. Il paper lo lascia intuire presentando i pesi della Progressive Loss come scelte d’implementazione, non come iperparametri ottimizzati. E la testa «strettamente più leggera» di cui parla il testo lo è a metà strada: dopo il ritocco al collo, che aggiunge uno strato di attenzione, YOLO26s ha 9,5 milioni di parametri contro i 9,4 di YOLO11s, con la stessa latenza di 2,5 millisecondi. Il risparmio netto sta nei FLOPs (20,7 contro 21,5), non nei parametri.

Il terzo è dichiarato dagli autori stessi: quasi tutto è misurato sul COCO (con DOTA e LVIS per i compiti accessori), dopo un preaddestramento su Objects365. Il paper indica come lavoro futuro proprio «una valutazione più ampia oltre i benchmark centrati sul COCO». Chi rileva difetti su una linea di produzione, o pesci in un video subacqueo, dovrà misurare da sé.

La posta in gioco

YOLO26 non è un salto concettuale. La doppia testa è di YOLOv10, Muon viene dagli LLM, l’idea di rinunciare alla NMS è di DETR, che ha sei anni. Il contributo è un altro, e ha più a che fare con l’ingegneria che con la ricerca: mettere insieme questi pezzi dentro la libreria che l’industria già usa, fino a rendere l’inferenza senza filtro finale l’impostazione predefinita. Per chi deploya su hardware piccolo significa un passaggio in meno da reimplementare in ogni runtime e una soglia in meno da tarare. È il correttore che esce dall’aula: non si nota finché c’è, ma chi deve pagarlo, un millisecondo alla volta su un dispositivo, se ne accorge quando se ne va.

I commenti sono riservati agli iscritti.

Accedi per commentare