Link to this sectionArchitettura YOLO spiegata: da YOLOv3 a YOLO26#

Ogni modello Ultralytics YOLO è costruito su tre stadi: una backbone che estrae le feature, un neck che le fonde attraverso diverse scale e una head che predice riquadri e classi. Questa guida documenta i moduli che compongono ogni stadio e come sono cambiati da YOLOv3 a YOLO26, tracciando ogni componente fino alla sua definizione nei file di configurazione sotto ultralytics/cfg/models/ e alle classi dei moduli in ultralytics/nn/modules/.

Ogni modello è definito in modo dichiarativo in un file YAML come una lista ordinata di livelli, dove ogni livello segue il formato [from, repeats, module, args]: quali livelli lo alimentano, quante volte il modulo si ripete, la classe del livello (Conv, C3k2, SPPF, Detect, …) e i suoi argomenti del costruttore. La Guida alla configurazione del modello YAML documenta questo formato — incluso come repeats e args scalano con la profondità e la larghezza del variante — insieme al sistema di risoluzione dei moduli in dettaglio. Questa guida si concentra sui moduli stessi e su come sono cambiati da una versione all'altra.

Link to this sectionI tre stadi#

Ogni modello Ultralytics YOLO instrada l'immagine attraverso tre stadi sequenziali, ognuno con un compito distinto:

L'unità fondamentale è il blocco Conv (definito in conv.py): una convoluzione 2D, batch normalization e un'attivazione SiLU, applicate in sequenza. Ogni modulo più grande descritto di seguito è costruito componendo blocchi Conv.

Link to this sectionDiagrammi dell'architettura#

Ogni versione mantiene lo stesso scheletro backbone → neck → head e modifica stadi specifici. Le schede sottostanti mostrano la struttura per versione: gli stadi di backbone e neck seguono le configurazioni in ultralytics/cfg/models/, mentre le head di YOLOv3 e YOLOv5 sono disegnate nella loro forma originale basata su anchor anziché nella head u-variant anchor-free che i loro pacchetti di configurazione effettivamente spediscono. Esaminare le schede mostra cosa ha aggiunto ogni generazione. In breve, la progressione è: YOLOv3 è un rivelatore basato su anchor solo FPN; YOLOv5 aggiunge il percorso bottom-up PAN e SPPF; YOLOv8 passa al blocco C2f con una head anchor-free e DFL; YOLO11 inserisce l'attenzione C2PSA e il blocco C3k2; e YOLO26 aggiunge un residuo SPPF e rende la head priva di NMS e DFL. I colori dei nodi seguono la convenzione dei diagrammi di documentazione: input verde, backbone blu, spatial pooling e attenzione color ardesia, neck arancione, head e output viola.

flowchart TD
    IN[Input 640x640]:::start --> ST[Conv stem<br/>5x stride-2 down to P1-P5]:::proc
    ST --> BB[Darknet-53 backbone<br/>stacked Bottleneck]:::proc
    BB --> FPN[Neck FPN only<br/>top-down Upsample + Concat]:::decide
    FPN --> HD[Detect head<br/>3 scales, anchor-based]:::out
    HD --> O[Predictions + NMS]:::out
    classDef start fill:#4CAF50,color:#fff
    classDef proc fill:#2196F3,color:#fff
    classDef decide fill:#FF9800,color:#fff
    classDef out fill:#9C27B0,color:#fff

I diagrammi di YOLOv3 e YOLOv5 mostrano l'head originale basata su anchor. Il pacchetto ultralytics spedisce le configurazioni anchor-free YOLOv3u e YOLOv5u — le stesse backbone Darknet-53 e C3 con la head Detect di YOLOv8 — descritte in Detection Head.

Link to this sectionBlocchi backbone: Bottleneck → C3 → C2f → C3k2#

La backbone impila un blocco CSP (Cross-Stage Partial) ripetuto tra i livelli di downsampling Conv con stride 2. Quel blocco ripetuto è ciò che è cambiato maggiormente tra le versioni. Tutti i blocchi sottostanti risiedono in block.py; c1/c2 sono canali di input/output e c = 0.5 * c2 è la larghezza nascosta.

Link to this sectionBottleneck (YOLOv3)#

L'unità base è Bottleneck: due livelli Conv (kernel predefiniti (3, 3)) con un'aggiunta residua opzionale quando shortcut=True e c1 == c2. La backbone Darknet-53 di YOLOv3 li impila direttamente, senza split CSP, e rileva a tre scale (stride 8, 16, 32).

Link to this sectionC3 (YOLOv5)#

YOLOv5's C3 splits the input across two 1x1 convolutions: cv1 feeds n sequential Bottleneck blocks (kernels (1, 1) then (3, 3)), cv2 bypasses them. The two paths are concatenated and fused by a third 1x1 Conv:

def forward(self, x):
    # C3: bottleneck path m(cv1(x)) concatenated with bypass cv2(x), then fused by cv3
    return self.cv3(torch.cat((self.m(self.cv1(x)), self.cv2(x)), 1))

Solo l'output del bottleneck finale raggiunge la conv di fusione, quindi cv3 vede 2 mappe delle feature.

Link to this sectionC2f (YOLOv8)#

YOLOv8's C2f ("CSP Bottleneck with 2 convolutions, faster") changes which features reach the fusion conv:

1. cv1 = Conv(c1, 2 * c, 1), poi chunk(2) divide l'output in due tensori a canale c.
2. n blocchi Bottleneck(c, c) (kernel (3, 3), (3, 3)) vengono eseguiti sequenzialmente, ognuno alimentato dall'output del blocco precedente.
3. Tutti i tensori intermedi n + 2 vengono concatenati e fusi da cv2 = Conv((2 + n) * c, c2, 1).

Dove C3 passa 2 mappe delle feature nella sua conv di fusione, C2f ne passa n + 2 — ogni output di bottleneck intermedio viene riutilizzato.

Link to this sectionC3k2 (YOLO11 e YOLO26)#

YOLO11 e YOLO26 usano C3k2, una sottoclasse di C2f che scambia l'unità di ripetizione. Ciascuno degli n blocchi diventa, a seconda dei flag del costruttore:

• un Bottleneck semplice (predefinito, c3k=False),
• un blocco C3k (c3k=True) — una variante di C3 con una dimensione del kernel configurabile, o
• una coppia Bottleneck + PSABlock (attn=True).

Il secondo argomento YAML imposta c3k; ad esempio [-1, 2, C3k2, [512, True]] costruisce un modulo C3k2 a 512 canali di output i cui blocchi interni sono C3k (poiché c3k=True). Per i moduli CSP, il campo repeats — qui 2, prima di essere scalato dal multiplo di profondità della variante — diventa il conteggio delle ripetizioni interne del blocco invece di impilare moduli separati.

Link to this sectionSpatial pooling: SPP → SPPF#

At the end of the backbone, a spatial-pyramid-pooling block widens the receptive field. YOLOv5 replaced the original multi-kernel SPP with SPPF (Spatial Pyramid Pooling - Fast): a single MaxPool2d(kernel_size=5, stride=1, padding=2) applied n = 3 times in sequence, with the input and all three pooled outputs concatenated and fused by a 1x1 Conv. This is mathematically equivalent to SPP(k=(5, 9, 13)) but cheaper, because the chained 5x5 pools cover the larger kernels' receptive fields.

YOLO26 passa un flag shortcut (SPPF, [1024, 5, 3, True]); poiché c1 == c2 == 1024 al livello più profondo, SPPF aggiunge una connessione residua (return y + x).

Link to this sectionSpatial Attention: C2PSA (YOLO11+)#

YOLO11 ha aggiunto C2PSA dopo SPPF. È un blocco CSP il cui ramo attivo è una pila di n moduli PSABlock (Position-Sensitive Attention): cv1 = Conv(c1, 2 * c, 1) divide le feature, una metà passa attraverso la pila PSABlock, e cv2 = Conv(2 * c, c1, 1) fonde la concatenazione. Ogni PSABlock applica attenzione multi-testa seguita da una rete feed-forward a due livelli (Conv(c, 2 * c, 1) → Conv(2 * c, c, 1)), ciascuna con una connessione residua. YOLO26 mantiene la stessa backbone C3k2 + C2PSA.

Link to this sectionNeck: FPN + PAN#

Il neck fonde le mappe delle feature P3/P4/P5 della backbone con una Feature Pyramid Network (FPN) top-down seguita da una Path Aggregation Network (PAN) bottom-up. Nella sezione head dello YAML, FPN è nn.Upsample + Concat (che porta informazioni semantiche verso il basso a risoluzioni più alte) e PAN è Conv stride 2 + Concat (che riporta le informazioni di localizzazione verso l'alto):

# YOLO11 head (FPN top-down, then PAN bottom-up)
- [-1, 1, nn.Upsample, [None, 2, "nearest"]]
- [[-1, 6], 1, Concat, [1]] # cat backbone P4
- [-1, 2, C3k2, [512, False]] # 13
# ... second upsample + concat to P3 ...
- [-1, 1, Conv, [256, 3, 2]]
- [[-1, 13], 1, Concat, [1]] # cat head P4 (PAN)
- [-1, 2, C3k2, [512, False]] # 19

Il neck riutilizza il blocco backbone della sua generazione — C3 in YOLOv5, C2f in YOLOv8, C3k2 in YOLO11 e YOLO26 — quindi ogni punto di fusione esegue lo stesso modulo usato dalla backbone. I tre output fusi alimentano l'head. YOLOv3 è l'eccezione: il suo neck è solo FPN top-down (la sua head YAML non ha downsampling stride 2), senza il percorso bottom-up PAN introdotto da YOLOv5.

Link to this sectionDetection Head: da basato su anchor → anchor-free → NMS-free#

L'head trasforma le tre mappe delle feature fuse in previsioni per il task di rilevamento. Il suo design è cambiato tra le versioni, passando da basato su anchor a anchor-free a NMS-free.

Link to this sectionHead Detect disaccoppiata e anchor-free#

I originali YOLOv3 e YOLOv5 usavano un'head accoppiata basata su anchor: anchor box predefinite e un ramo condiviso per le previsioni di box e classe. I repository standalone ultralytics/yolov3 e ultralytics/yolov5 mantengono quel design basato su anchor. Il pacchetto principale ultralytics invece spedisce le varianti anchor-free YOLOv3u e YOLOv5u — le stesse backbone Darknet-53 e C3 con l'head Detect anchor-free di YOLOv8 — e le configurazioni yolov3.yaml e yolov5.yaml documentate qui sono queste varianti u, non il design storico.

L'head Detect (head.py) è anchor-free e disaccoppiata: per livello di piramide esegue due rami paralleli e predice direttamente sui punti della griglia anziché sugli anchor box.

• Ramo box (cv2): Conv(x, c2, 3) → Conv(c2, c2, 3) → Conv2d(c2, 4 * reg_max, 1).
• Ramo classe (cv3): in YOLO11 e YOLO26, due blocchi depthwise-separable (DWConv + 1x1 Conv) → Conv2d(c3, nc, 1); YOLOv8 usa la variante legacy, due livelli 3x3 Conv → Conv2d(c3, nc, 1).

Ogni anchor point emette quindi no = nc + 4 * reg_max output. Rimuovere gli anchor predefiniti elimina le dimensioni e le proporzioni degli anchor box dagli iperparametri che devono essere ottimizzati.

Link to this sectionDistribution Focal Loss (DFL)#

YOLOv8 e YOLO11 regrediscono ognuna delle 4 coordinate del box come una distribuzione su reg_max = 16 bin anziché come un singolo scalare (la forma integrale da Generalized Focal Loss). Il modulo DFL rimodella i 4 * reg_max canali del box in (4, reg_max), applica una softmax sui bin reg_max e prende l'indice del bin atteso — ogni indice di bin ponderato dalla sua probabilità softmax, quindi sommato — come coordinata predetta. Questo è implementato come una convoluzione 1x1 fissa i cui pesi sono gli indici dei bin arange(reg_max), quindi la somma ponderata è un singolo prodotto scalare.

Link to this sectionYOLO26: NMS-free, DFL-free#

YOLO26 imposta due parametri YAML che l'head legge direttamente:

• end2end: True — Detect copia profondamente i suoi rami in un'head uno-a-uno (one2one_cv2/one2one_cv3) che produce una singola previsione per oggetto, eliminando il passaggio di post-elaborazione Non-Maximum Suppression (NMS). Vedi la guida al rilevamento End-to-End per i dettagli su esportazione e migrazione.
• reg_max: 1 — con un bin, self.dfl diventa nn.Identity() e no = nc + 4; l'head regredisce le coordinate direttamente e nessuna operazione DFL appare nel grafico ONNX esportato.

Attraverso le sue cinque dimensioni di modello (n/s/m/l/x), YOLO26 raggiunge 40.9-57.5 mAP su COCO a 1.7-11.8 ms di latenza T4 TensorRT, come riportato nel documento di YOLO26.

Link to this sectionRiepilogo versione per versione#

Per dettagli specifici sul modello, tabelle delle prestazioni ed esempi di utilizzo, consulta le pagine individuali per YOLOv3, YOLOv5, YOLOv8, YOLO11 e YOLO26.

Link to this sectionEsamina l'architettura da solo#

Il metodo model.info() stampa un riepilogo di livelli, parametri e FLOPs, e la lista dei moduli analizzati è disponibile su model.model.model.

from ultralytics import YOLO

# Load a pretrained model
model = YOLO("yolo11n.pt")

# Fuse Conv + BatchNorm layers so counts match the published specs
model.fuse()

# Print a summary: layers, parameters, gradients, GFLOPs
model.info()

# Inspect the detection head (the last module in the network)
head = model.model.model[-1]
print(type(head).__name__, "| reg_max:", head.reg_max, "| end2end:", head.end2end)

Eseguire lo snippet attraverso tre generazioni mostra i cambiamenti numericamente. Questi sono output reali di modelli fusi dal pacchetto ultralytics, che corrispondono ai conteggi di parametri e FLOPs pubblicati su ogni pagina del modello:

YOLO26n riporta reg_max=1, end2end=True e un livello DFL Identity — la firma architettonica della sua head NMS-free e DFL-free.

Link to this sectionConclusione#

Tra le varie versioni, l'architettura YOLO è cambiata una fase alla volta: il backbone è passato da Darknet-53 a blocchi C3, C2f e C3k2 basati su CSP con attenzione C2PSA; il neck ha mantenuto la sua struttura FPN + PAN mentre SPP è diventato SPPF; e l'head è passato da un approccio basato su anchor a uno senza anchor, fino al design end-to-end senza NMS e senza DFL di YOLO26.

Per definire architetture personalizzate, consulta la Guida alla configurazione YAML dei modelli o confronta i modelli sulle pagine dei modelli. Per domande, contattaci su GitHub o Discord.

Link to this sectionFAQ#

Link to this sectionQuali sono le tre fasi di un'architettura YOLO?#

Un modello YOLO ha un backbone che estrae le caratteristiche dall'immagine a stride 8, 16 e 32, un neck che fonde tali caratteristiche attraverso le scale con FPN e PAN, e un head che predice i bounding box e i punteggi delle classi. Ogni modello Ultralytics YOLO, da YOLOv3 a YOLO26, segue questo design a tre fasi.

Link to this sectionQual è la differenza tra i blocchi C2f e C3k2?#

C2f (YOLOv8) è un blocco CSP che concatena gli output di ogni Bottleneck interno — n + 2 mappe di caratteristiche — prima della sua convoluzione di fusione, mentre il C3 più vecchio ne passa solo 2. C3k2 (YOLO11 e YOLO26) è una sottoclasse di C2f che può sostituire ogni Bottleneck con un blocco C3k (una variante di C3 con una dimensione del kernel configurabile) quando il flag c3k è impostato. Entrambi sono definiti in block.py.

Link to this sectionCosa è cambiato nell'architettura tra YOLOv8 e YOLO11?#

YOLO11 apporta tre modifiche strutturali a YOLOv8: sostituisce il backbone e il blocco neck C2f con C3k2, inserisce un blocco di self-attention C2PSA dopo SPPF e passa il ramo di classificazione dell'head a convoluzioni depthwise-separable più leggere. Entrambi mantengono lo stesso head Detect disaccoppiato e senza anchor con regressione DFL reg_max=16, quindi le modifiche riducono il numero di parametri e FLOP migliorando al contempo l'accuratezza, anziché riprogettare l'interfaccia di rilevamento.

Link to this sectionYOLO è senza anchor?#

I moderni modelli Ultralytics YOLO sono senza anchor. YOLOv8, YOLO11 e YOLO26 utilizzano un head Detect senza anchor e disaccoppiato, con rami separati per la regressione dei box e la classificazione. Gli originali YOLOv3 e YOLOv5 erano basati su anchor, ma Ultralytics li distribuisce come varianti YOLOv3u e YOLOv5u, le cui configurazioni utilizzano lo stesso head senza anchor di YOLOv8.

Link to this sectionYOLO26 ha rimosso la NMS?#

Sì — YOLO26 imposta end2end=True, il che conferisce a Detect un head one-to-one che produce una singola predizione per oggetto e rimuove il passaggio di post-elaborazione Non-Maximum Suppression richiesto dai modelli precedenti. Vedi la guida al rilevamento End-to-End per i dettagli.

Link to this sectionCos'è la Distribution Focal Loss (DFL) e perché YOLO26 l'ha rimossa?#

La DFL esegue la regressione di ogni coordinata del box come una distribuzione softmax su reg_max bin (16 di default in YOLOv8 e YOLO11) e ne prende il valore atteso come coordinata, invece di predire un singolo scalare. YOLO26 imposta reg_max=1, quindi il livello DFL diventa un'operazione di identità, l'head esegue la regressione delle coordinate direttamente e nessuna operazione DFL appare nei grafi ONNX o TensorRT esportati.

Link to this sectionCome posso vedere l'architettura di uno specifico modello YOLO?#

Carica il modello in Python e richiama model.info() per un riepilogo di livelli, parametri e GFLOP. I livelli analizzati si trovano in model.model.model — ad esempio, model.model.model[-1] è l'head Detect, che espone attributi come reg_max e end2end. L'architettura completa è definita nel file di configurazione YAML del modello.