YOLO-Architektur erklärt: Von YOLOv3 bis YOLO26#

Jedes Ultralytics YOLO-Modell ist aus drei Stufen aufgebaut: einem Backbone, das Merkmale extrahiert, einem Neck, der sie über Skalen hinweg zusammenführt, und einem Head, der Boxen und Klassen vorhersagt. Diese Anleitung dokumentiert die Module, aus denen die einzelnen Stufen bestehen, und wie sie sich von YOLOv3 zu YOLO26 verändert haben, wobei jede Komponente bis zu ihrer Definition in den Konfigurationsdateien unter ultralytics/cfg/models/ und den Modulklassen in ultralytics/nn/modules/ zurückverfolgt wird.

Jedes Modell ist deklarativ in einer YAML-Datei als geordnete Liste von Schichten definiert, wobei jede Schicht dem Format von [from, repeats, module, args] folgt: welche Schicht(en) sie speisen, wie oft sich das Modul wiederholt, die Schichtklasse (Conv, C3k2, SPPF, Detect, …) und ihre Konstruktorargumente. Die Model YAML Configuration Guide dokumentiert dieses Format – einschließlich der Skalierung von repeats und args mit den Tiefen- und Breitenfaktoren der Variante – zusammen mit dem Modulauflösungssystem im Detail. Diese Anleitung konzentriert sich auf die Module selbst und darauf, wie sie sich von Version zu Version verändert haben.

Die drei Stufen#

Jedes Ultralytics YOLO-Modell leitet das Bild durch drei aufeinanderfolgende Stufen, jede mit einer eigenen Aufgabe:

Die grundlegende Einheit ist der Block Conv (definiert in conv.py): eine 2D-Faltung, Batch-Normalisierung und eine SiLU-Aktivierung, nacheinander angewendet. Jedes größere Modul weiter unten wird durch das Zusammensetzen von Conv-Blöcken aufgebaut.

Architekturdiagramme#

Jede Version behält das gleiche Backbone → Neck → Head-Skelett bei und ändert spezifische Stufen. Die Registerkarten unten zeigen die Struktur pro Version: Die Backbone- und Neck-Stufen folgen den Konfigurationen in ultralytics/cfg/models/, während die Heads von YOLOv3 und YOLOv5 in ihrer ursprünglichen Anker-basierten Form dargestellt werden und nicht in der ankerfreien u-Variante, die ihre Paketkonfigurationen tatsächlich ausliefern. Das Durchklicken der Registerkarten zeigt, was jede Generation hinzugefügt hat. Kurz gesagt lautet die Entwicklung: YOLOv3 ist ein reiner FPN-, Anker-basierter Detektor; YOLOv5 fügt den Bottom-Up-PAN-Pfad und SPPF hinzu; YOLOv8 wechselt zum C2f-Block mit einem ankerfreien DFL-Head; YOLO11 fügt C2PSA-Attention und den C3k2-Block ein; und YOLO26 fügt ein SPPF-Residual hinzu und macht den Head NMS-frei und DFL-frei. Die Knotenfarben folgen der Konvention der Dokumentationsdiagramme: grüner Input, blauer Backbone, schiefergraues Spatial Pooling und Attention, orangefarbener Neck, purpurner Head und Output.

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

Die Diagramme von YOLOv3 und YOLOv5 zeigen den ursprünglichen Anker-basierten Head. Das Paket ultralytics liefert die ankerfreien Konfigurationen YOLOv3u und YOLOv5u aus – dieselben Backbones von Darknet-53 und C3 mit dem Detect-Head von YOLOv8 –, die unter Detection Head beschrieben sind.

Backbone-Blöcke: Bottleneck → C3 → C2f → C3k2#

Der Backbone stapelt einen sich wiederholenden CSP-Block (Cross-Stage Partial) zwischen Conv-Downsampling-Schichten mit Schrittweite 2 (stride-2). Dieser sich wiederholende Block hat sich über die Versionen hinweg am meisten verändert. Alle folgenden Blöcke befinden sich in block.py; c1/c2 sind Eingabe-/Ausgabekanäle und c = 0.5 * c2 ist die versteckte Breite.

Bottleneck (YOLOv3)#

Die Basiseinheit ist Bottleneck: zwei Conv-Schichten (Standardkerne (3, 3)) mit einer optionalen Residual-Addition, wenn shortcut=True und c1 == c2. Der Darknet-53-Backbone von YOLOv3 stapelt diese direkt ohne CSP-Split und detektiert in drei Skalen (Schrittweiten 8, 16, 32).

C3 (YOLOv5)#

Der C3 von YOLOv5 teilt die Eingabe auf zwei 1x1-Faltungen auf: cv1 speist n sequenzielle Bottleneck-Blöcke (Kerne (1, 1) und danach (3, 3)), cv2 umgeht sie. Die beiden Pfade werden verkettet und durch eine dritte 1x1 Conv zusammengeführt:

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))

Nur die finale Bottleneck-Ausgabe erreicht die Fusionsfaltung, sodass cv3 2 Feature-Maps sieht.

C2f (YOLOv8)#

Der C2f von YOLOv8 („CSP Bottleneck mit 2 Faltungen, schneller“) ändert, welche Merkmale die Fusionsfaltung erreichen:

1. cv1 = Conv(c1, 2 * c, 1), dann teilt chunk(2) die Ausgabe in zwei c-Kanäle-Tensoren auf.
2. n Bottleneck(c, c)-Blöcke (Kerne (3, 3), (3, 3)) laufen nacheinander, wobei jeder die Ausgabe des vorherigen Blocks erhält.
3. Alle intermediären Tensoren von n + 2 werden verkettet und durch cv2 = Conv((2 + n) * c, c2, 1) zusammengeführt.

Wo C3 2 Feature-Maps in seine Fusionsfaltung leitet, leitet C2f n + 2 weiter – jede intermediäre Bottleneck-Ausgabe wird wiederverwendet.

C3k2 (YOLO11 und YOLO26)#

YOLO11 und YOLO26 verwenden C3k2, eine Unterklasse von C2f, die die Wiederholungseinheit austauscht. Jeder der n-Blöcke wird, abhängig von den Konstruktor-Flags, zu:

• einem einfachen Bottleneck (Standard, c3k=False),
• einem C3k-Block (c3k=True) – einer C3-Variante mit einer konfigurierbaren Kern Größe, oder
• einem Bottleneck + PSABlock-Paar (attn=True).

Das zweite YAML-Argument legt c3k fest; zum Beispiel erstellt [-1, 2, C3k2, [512, True]] ein C3k2-Modul bei 512 Ausgabekanälen, dessen interne Blöcke C3k sind (da c3k=True). Bei CSP-Modulen wird das Feld repeats – hier 2, bevor es mit dem Tiefenmultiplikator der Variante skaliert wird – zur internen Wiederholungsanzahl des Blocks anstatt separate Module zu stapeln.

Räumliches Pooling: SPP → SPPF#

Am Ende des Backbones erweitert ein Spatial-Pyramid-Pooling-Block das receptive Feld. YOLOv5 ersetzte das ursprüngliche Multi-Kernel SPP durch SPPF (Spatial Pyramid Pooling - Fast): eine einzelne MaxPool2d(kernel_size=5, stride=1, padding=2), die n = 3-mal nacheinander angewendet wird, wobei die Eingabe und alle drei gepoolten Ausgaben durch ein 1x1 Conv verkettet und zusammengeführt werden. Dies ist mathematisch äquivalent zu SPP(k=(5, 9, 13)), aber kostengünstiger, da die verketteten 5x5-Pools die rezeptiven Felder der größeren Kerne abdecken.

YOLO26 übergibt ein Shortcut-Flag (SPPF, [1024, 5, 3, True]); da c1 == c2 == 1024 in der tiefsten Schicht, fügt SPPF eine Residual-Verbindung (return y + x) hinzu.

Räumliche Attention: C2PSA (YOLO11+)#

YOLO11 fügte C2PSA nach SPPF hinzu. Es ist ein CSP-Block, dessen aktiver Zweig ein Stapel von n PSABlock (Position-Sensitive Attention)-Modulen ist: cv1 = Conv(c1, 2 * c, 1) teilt die Merkmale auf, eine Hälfte läuft durch den PSABlock-Stapel, und cv2 = Conv(2 * c, c1, 1) führt die Verkettung zusammen. Jedes PSABlock wendet Multi-Head-Attention gefolgt von einem zweischichtigen Feed-Forward-Netzwerk (Conv(c, 2 * c, 1) → Conv(2 * c, c, 1)) an, jeweils mit einer Residual-Verbindung. YOLO26 behält denselben C3k2 + C2PSA-Backbone bei.

Neck: FPN + PAN#

Der Neck führt die P3/P4/P5-Feature-Maps des Backbones mit einem Top-Down Feature Pyramid Network (FPN) zusammen, gefolgt von einem Bottom-Up Path Aggregation Network (PAN). Im YAML-Head-Abschnitt ist FPN nn.Upsample + Concat (das semantische Informationen nach unten zu höheren Auflösungen trägt) und PAN ist stride-2 Conv + Concat (das Lokalisierungsinformationen wieder nach oben trägt):

# 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

Der Neck verwendet den Backbone-Block seiner Generation wieder – C3 in YOLOv5, C2f in YOLOv8, C3k2 in YOLO11 und YOLO26 –, sodass jeder Zusammenführungspunkt dasselbe Modul ausführt, das auch der Backbone nutzt. Die drei zusammengeführten Ausgaben speisen den Head. YOLOv3 ist die Ausnahme: Sein Neck besteht nur aus Top-Down-FPN (sein YAML-Head hat kein stride-2-Downsampling), ohne den von YOLOv5 eingeführten Bottom-Up-PAN-Pfad.

Detection Head: Ankerbasiert → Ankerfrei → NMS-frei#

Der Head wandelt die drei zusammengeführten Feature-Maps in Vorhersagen für die Detektionsaufgabe um. Sein Design hat sich über die Versionen hinweg verändert, von Anker-basiert über ankerfrei bis hin zu NMS-frei.

Ankerfreier, entkoppelter Detect#

Der ursprüngliche YOLOv3 und YOLOv5 verwendeten einen Anker-basierten, gekoppelten Head: vordefinierte Ankerboxen und einen gemeinsamen Zweig für Box- und Klassenvorhersagen. Die eigenständigen Repositories ultralytics/yolov3 und ultralytics/yolov5 behalten dieses Anker-basierte Design bei. Das Hauptpaket ultralytics liefert stattdessen die ankerfreien Varianten YOLOv3u und YOLOv5u aus – dieselben Backbones von Darknet-53 und C3 mit dem ankerfreien Detect-Head von YOLOv8 –, und die hier dokumentierten Konfigurationen yolov3.yaml und yolov5.yaml sind diese u-Varianten und nicht das historische Design.

Der Detect-Head (head.py) ist ankerfrei und entkoppelt: Pro Pyramidenebene führt er zwei parallele Zweige aus und prognostiziert direkt auf Gitterpunkten anstatt gegen Ankerboxen.

• Box-Zweig (cv2): Conv(x, c2, 3) → Conv(c2, c2, 3) → Conv2d(c2, 4 * reg_max, 1).
• Klassen-Zweig (cv3): in YOLO11 und YOLO26 zwei tiefenseparierbare Blöcke (DWConv + 1x1 Conv) → Conv2d(c3, nc, 1); YOLOv8 verwendet die Legacy-Variante, zwei 3x3 Conv-Schichten → Conv2d(c3, nc, 1).

Jeder Ankerpunkt gibt daher no = nc + 4 * reg_max Ausgaben aus. Durch das Entfernen vordefinierter Anker entfallen die Ankerboxgrößen und Seitenverhältnisse aus den Hyperparametern, die abgestimmt werden müssen.

Distribution Focal Loss (DFL)#

YOLOv8 und YOLO11 regredieren jede der 4 Boxkoordinaten als Verteilung über reg_max = 16-Bins anstelle eines einzelnen Skalars (die integrale Form aus Generalized Focal Loss). Das Modul DFL formt die Box-Kanäle von 4 * reg_max in (4, reg_max) um, wendet eine Softmax über die reg_max-Bins an und nimmt den erwarteten Bin-Index – wobei jeder Bin-Index mit seiner Softmax-Wahrscheinlichkeit gewichtet und dann summiert wird – als vorhergesagte Koordinate. Dies ist als feste 1x1-Faltung implementiert, deren Gewichte die Bin-Indizes arange(reg_max) sind, sodass die gewichtete Summe ein einzelnes Skalarprodukt ist.

YOLO26: NMS-frei, DFL-frei#

YOLO26 legt zwei YAML-Parameter fest, die der Head direkt liest:

• end2end: True – Detect kopiert seine Zweige tief in einen Eins-zu-Eins-Head (one2one_cv2/one2one_cv3), der eine einzige Vorhersage pro Objekt erzeugt, wodurch der Nachbearbeitungsschritt der Non-Maximum Suppression (NMS) entfällt. Siehe den End-to-End Detection guide für Export- und Migrationsdetails.
• reg_max: 1 – mit einem Bin wird self.dfl zu nn.Identity() und no = nc + 4; der Head regrediert Koordinaten direkt und im exportierten ONNX-Graphen taucht keine DFL-Operation auf.

Über seine fünf Modellgrößen (n/s/m/l/x) hinweg erreicht YOLOv26 40,9-57,5 mAP auf COCO bei 1,7-11,8 ms T4-TensorRT-Latenz, wie im YOLO26 paper berichtet.

Zusammenfassung nach Versionen#

Für modellbezogene Details, Leistungstabellen und Anwendungsbeispiele siehe die einzelnen Seiten für YOLOv3, YOLOv5, YOLOv8, YOLO11 und YOLO26.

Untersuche die Architektur selbst#

Die Methode model.info() gibt eine Zusammenfassung der Schichten, Parameter und FLOPs aus, und die geparste Modulliste ist unter model.model.model verfügbar.

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)

Das Ausführen des Snippets über drei Generationen hinweg zeigt die Änderungen numerisch. Dies sind reale Ausgaben fusionierter Modelle aus dem Paket ultralytics, die mit den auf jeder Modellseite veröffentlichten Parameter- und FLOPs-Zahlen übereinstimmen:

YOLO26n meldet reg_max=1, end2end=True und eine Identity DFL-Schicht – die architektonische Signatur seines NMS-freien, DFL-freien Heads.

Fazit#

Über alle Versionen hinweg hat sich die YOLO-Architektur Stufe für Stufe verändert: Der Backbone wechselte von Darknet-53 zu CSP-basierten C3-, C2f- und C3k2-Blöcken mit C2PSA-Attention; der Neck behielt seine FPN + PAN-Struktur bei, während SPP zu SPPF wurde; und der Head wechselte von Anker-basiert zu ankerfrei und schließlich zum NMS-freien, DFL-freien End-to-End-Design von YOLO26.

Um benutzerdefinierte Architekturen zu definieren, siehe die Model YAML Configuration Guide oder vergleiche Modelle auf den Modellseiten. Bei Fragen wende dich auf GitHub oder Discord an uns.

FAQ#