YOLO 2026: rilevamento senza NMS, una mappa delle versioni che inganna e la licenza che nessuno legge

YOLO26 elimina i due passaggi di post-elaborazione che rendevano scomodo l'uso dei detector precedenti. Di default esegue una testa di rilevamento one-to-one, quindi non c'è Non-Maximum Suppression (NMS) in fase di inferenza, e la rete restituisce direttamente le rilevazioni finali. Elimina anche la Distribution Focal Loss (DFL), il che rende la testa più leggera per dispositivi edge e a basso consumo energetico. Anche la ricetta di addestramento è nuova: un ottimizzatore MuSGD, una loss progressiva e un'assegnazione delle etichette per obiettivi piccoli.

Perché l'assenza di NMS è la parte che conta: NMS è un passaggio separato, dipendente dai dati, che viene eseguito dopo la rete, e la sua durata varia in base al numero di oggetti presenti nell'immagine. Eliminarlo vi dà una latenza deterministica e un export più pulito, esattamente ciò che serve quando l'obiettivo è ONNX, TensorRT, OpenVINO o CoreML su hardware fisso. Meno parametri di post-elaborazione significano meno modi in cui il percorso di produzione può discostarsi dal laboratorio.

I numeri sono incrementali, non eclatanti. Su COCO, YOLO26n raggiunge 40,9 mAP con 2,4M di parametri, e Ultralytics dichiara un'inferenza CPU-ONNX fino al 43 percento più veloce rispetto a YOLO11n. Questo dato sulla CPU, non l'accuratezza, è la notizia principale per un acquirente che esegue il rilevamento su silicio edge commerciale senza GPU.

La cosa più utile da capire nel 2026 è che "YOLO" non è più un singolo progetto e i numeri di versione provengono da team diversi. Ultralytics mantiene YOLO26, YOLO11 e le versioni precedenti v8 e v5. YOLOv12 e YOLOv13 sono linee accademiche separate, ed entrambe continuano a basarsi su NMS e DFL, esattamente le cose che YOLO26 ha eliminato.

La lezione è che un numero di versione più alto non è un prodotto più recente dello stesso fornitore. A volte è un gruppo di ricerca completamente diverso. YOLOv13 ha attirato critiche aperte perché ha riportato un AP di circa 54,8 contro il 55,2 di YOLOv12, pur essendo più pesante da eseguire, una regressione presentata come un upgrade. E YOLO stesso non è automaticamente il leader in accuratezza: i detector basati su transformer della famiglia RF-DETR ora competono direttamente ai vertici. Leggete il benchmark e il responsabile, non l'etichetta.

Prima dell'architettura, verificate la licenza, perché la licenza predefinita limita il modo in cui potete distribuire il prodotto. Ultralytics YOLO è concesso in licenza sotto AGPL-3.0. AGPL è una forte licenza copyleft: se distribuite il software o lo offrite come servizio tramite rete, siete generalmente obbligati a rilasciare il codice sorgente completo corrispondente della vostra opera derivata, e l'interpretazione diffusa estende questo obbligo ai pesi e al codice applicativo circostante.

Il punto che la maggior parte dei team trascura è che l'on-premise non vi esenta. La clausola di rete dell'AGPL viene attivata dall'offerta della funzionalità come servizio, secondo alcune interpretazioni persino se rivolta internamente, non solo dalla consegna di un binario a un cliente. Per un prodotto closed-source o un deployment che preferite non rendere open-source, Ultralytics vende una licenza commerciale Enterprise. Il prezzo è calcolato individualmente, senza tariffa pubblica, quindi va inserita presto nella conversazione di procurement, non dopo che il prototipo funziona.

La conclusione rilevante per il procurement è semplice: mettete in conto la licenza Enterprise oppure scegliete fin dall'inizio un detector con licenza permissiva (Apache o MIT). È la stessa questione di controllo a cui torniamo continuamente per i modelli open-weight, dove è la licenza e lo stack, non il benchmark, a decidere che cosa potete fare.

Trattate le release del 2026 come una breve e noiosa checklist, non come una classifica.

• Fissate una versione mantenuta. Per la produzione, la linea Ultralytics (YOLO26 o YOLO11) è il percorso supportato. Le linee accademiche v12 e v13 sono ricerca, utili da leggere, non lo standard per il deployment.
• Leggete il benchmark, non l'etichetta. Confrontate mAP e latenza su hardware simile al vostro, e siate onesti sul fatto che RF-DETR o un modello più piccolo e più vecchio possa vincere per il vostro scenario.
• Testate il percorso di export in anticipo. Il valore dell'assenza di NMS si realizza nell'export ONNX o TensorRT sul vostro dispositivo di destinazione. Confermatelo lì prima di impegnarvi.
• Chiarite la licenza prima del pilota. AGPL, licenza Enterprise o un'alternativa permissiva. Decidetelo finché è ancora economico da cambiare.

Niente di tutto questo richiede il numero più recente. Serve un detector che funzioni alla vostra latenza, sul vostro hardware, con una licenza con cui potete convivere.