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

Jedes Ultralytics YOLO-Modell besteht aus drei Stufen: einem Backbone, das Merkmale extrahiert, einem Neck, das sie über verschiedene Skalen hinweg zusammenführt, und einem Head, der Boxen und Klassen vorhersagt. Dieser Leitfaden dokumentiert die Module der einzelnen Stufen und zeigt, wie sie sich von YOLOv3 bis YOLO26 verändert haben. Dabei wird jede Komponente auf ihre Definition in den Konfigurationsdateien unter ultralytics/cfg/models/ und auf die Modulklassen in ultralytics/nn/modules/ zurückgeführt.

Jedes Modell wird deklarativ in einer YAML-Datei als geordnete Liste von Layern definiert. Jeder Layer folgt dem Format [from, repeats, module, args]: welche Layer ihn speisen, wie oft das Modul wiederholt wird, die Layer-Klasse (Conv, C3k2, SPPF, Detect, …) und ihre Konstruktorargumente. Der Leitfaden zur Modell-YAML-Konfiguration beschreibt dieses Format – einschließlich der Skalierung von repeats und args anhand der Tiefen- und Breitenfaktoren der jeweiligen Variante – sowie das System zur Modulauflösung im Detail. Dieser Leitfaden konzentriert sich auf die Module selbst und ihre Veränderungen von Version zu Version.

Die drei Stufen#

Jedes Ultralytics YOLO-Modell verarbeitet das Bild nacheinander durch drei Stufen, die jeweils eine eigene Aufgabe haben:

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

Architekturdiagramme#

Jede Version behält dasselbe Backbone → Neck → Head-Grundgerüst bei und verändert bestimmte Stufen. Die Tabs unten zeigen den Aufbau der einzelnen Versionen: Die Backbone- und Neck-Stufen folgen den Konfigurationen in ultralytics/cfg/models/, während die YOLOv3- und YOLOv5-Heads in ihrer ursprünglichen anchor-basierten Form dargestellt sind und nicht als anchor-freie u-Variante, wie sie tatsächlich in den Paketkonfigurationen enthalten ist. Beim Durchgehen der Tabs siehst du, was jede Generation hinzugefügt hat. Kurz gesagt: YOLOv3 ist ein ausschließlich auf FPN basierender anchor-basierter Detektor; YOLOv5 ergänzt den Bottom-up-PAN-Pfad und SPPF; YOLOv8 wechselt zum C2f-Block mit einem anchor-freien Head mit DFL; YOLO11 fügt C2PSA-Attention und den C3k2-Block ein; und YOLO26 ergänzt eine SPPF-Residualverbindung, entfernt DFL und fügt optional einen NMS-freien Head hinzu.

Die YOLOv3- und YOLOv5-Diagramme zeigen den ursprünglichen ankerbasierten Head. Das Paket ultralytics enthält die ankerfreien Konfigurationen YOLOv3u und YOLOv5u – dieselben Darknet-53- und C3-Backbones mit YOLOv8s Detect-Head –, die unter Detection Head beschrieben sind.

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

Das Backbone reiht einen wiederkehrenden CSP-Block (Cross-Stage-Partial-Block) zwischen Downsampling-Layern mit Stride 2 und Conv aneinander. Dieser wiederkehrende Block hat sich über die Versionen hinweg am stärksten verändert. Alle folgenden Blöcke befinden sich in block.py; c1/c2 sind die Ein- und Ausgabekanäle, und c = 0.5 * c2 bezeichnet die verborgene Breite.

Bottleneck (YOLOv3)#

Die Grundeinheit ist Bottleneck: zwei Conv-Layer (Standard-Kernel (3, 3)) mit optionaler Residualaddition, wenn shortcut=True und c1 == c2. Das Darknet-53-Backbone von YOLOv3 reiht diese direkt aneinander, ohne CSP-Aufteilung, und erkennt Objekte auf drei Skalen (Strides 8, 16 und 32).

C3 (YOLOv5)#

Das C3 von YOLOv5 teilt die Eingabe auf zwei 1x1-Faltungen auf: cv1 leitet sie durch n aufeinanderfolgende Bottleneck-Blöcke (Kernel (1, 1), dann (3, 3)), cv2 umgeht sie. Die beiden Pfade werden konkateniert und durch eine dritte 1x1-Conv-Faltung zusammengeführt:

def forward(self, x):
    # C3: Der Bottleneck-Pfad m(cv1(x)) wird mit dem Umgehungspfad cv2(x) konkateniert und anschließend durch cv3 zusammengeführt
    return self.cv3(torch.cat((self.m(self.cv1(x)), self.cv2(x)), 1))

Nur die Ausgabe des letzten Bottleneck-Blocks erreicht die Fusionsfaltung, daher erhält cv3 zwei Merkmalskarten.

C2f (YOLOv8)#

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

1. cv1 = Conv(c1, 2 * c, 1), anschließend teilt chunk(2) die Ausgabe in zwei Tensoren mit jeweils c Kanälen.
2. n Bottleneck(c, c)-Blöcke (Kernel (3, 3), (3, 3)) werden nacheinander ausgeführt; jeder erhält die Ausgabe des vorherigen Blocks als Eingabe.
3. Alle n + 2 Zwischentensoren werden konkateniert und durch cv2 = Conv((2 + n) * c, c2, 1) zusammengeführt.

Während C3 seiner Fusionsfaltung zwei Merkmalskarten zuführt, leitet C2f n + 2 Merkmalskarten weiter – jede Zwischenausgabe eines Bottleneck-Blocks wird wiederverwendet.

C3k2 (YOLO11 und YOLO26)#

YOLO11 und YOLO26 verwenden C3k2, eine Unterklasse von C2f, bei der die wiederkehrende Einheit ausgetauscht wird. Je nach Konstruktor-Flags wird jeder der n-Blöcke zu:

• einem einfachen Bottleneck (Standard, c3k=False),
• einem C3k-Block (c3k=True) – einer C3-Variante mit konfigurierbarer Kernelgröße – oder
• einem Paar aus Bottleneck und PSABlock (attn=True).

Das zweite YAML-Argument legt c3k fest, außer wenn die Skalierung m, l oder x beträgt; in diesen Fällen wird der Wert auf True gesetzt. So kann ein einziges yolo11.yaml alle fünf Varianten abdecken. Daher erstellt [-1, 2, C3k2, [512, False]] die internen Bottleneck-Blöcke bei n und s, die internen C3k-Blöcke jedoch bei m, l und x. Die 512 bezeichnet die Kanäle vor der Skalierung; der Breitenfaktor der Variante macht daraus 128 bei n und 768 bei x. Bei CSP-Modulen wird das Feld repeats – hier 2, bevor es mit dem Tiefenfaktor der Variante skaliert wird – zur internen Wiederholungszahl des Blocks, statt mehrere separate Module aneinanderzureihen.

Räumliches Pooling: SPP → SPPF#

Am Ende des Backbones erweitert ein räumlicher Pyramiden-Pooling-Block das rezeptive Feld. YOLOv5 ersetzte das ursprüngliche Multi-Kernel-SPP durch SPPF (schnelles räumliches Pyramiden-Pooling): Eine einzelne MaxPool2d(kernel_size=5, stride=1, padding=2) wird n = 3-mal nacheinander angewendet. Die Eingabe und alle drei gepoolten Ausgaben werden konkateniert und mit einer 1x1-Conv-Faltung zusammengeführt. Das ist mathematisch gleichwertig zu SPP(k=(5, 9, 13)), aber effizienter, weil die verketteten 5x5-Pooling-Operationen die rezeptiven Felder der größeren Kernel abdecken.

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

Räumliche Attention: C2PSA (ab YOLO11)#

YOLO11 fügte C2PSA nach SPPF hinzu. Dabei handelt es sich um einen CSP-Block, dessen aktiver Zweig aus einer Folge von n PSABlock-Modulen (positionssensitive Attention) besteht: cv1 = Conv(c1, 2 * c, 1) teilt die Merkmale auf, eine Hälfte durchläuft die PSABlock-Folge, und cv2 = Conv(2 * c, c1, 1) führt die konkatenierten Merkmale zusammen. Jedes PSABlock wendet Multi-Head-Attention an, gefolgt von einem zweischichtigen Feedforward-Netzwerk (Conv(c, 2 * c, 1) → Conv(2 * c, c, 1)); beide verfügen über eine Residualverbindung. YOLO26 behält dasselbe C3k2-C2PSA-Backbone bei.

Neck: FPN + PAN#

Das Neck führt die Merkmalskarten P3/P4/P5 des Backbones mit einem Feature Pyramid Network (FPN) von oben nach unten und anschließend einem Path Aggregation Network (PAN) von unten nach oben zusammen. Im YAML-Abschnitt für den Head besteht das FPN aus nn.Upsample + Concat (semantische Informationen werden zu höheren Auflösungen weitergegeben); das PAN besteht aus Conv + Concat mit Stride 2 (Lokalisierungsinformationen werden wieder nach oben geleitet):

# 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

Das Neck verwendet den Backbone-Block der jeweiligen Generation erneut: C3 in YOLOv5, C2f in YOLOv8 und C3k2 in YOLO11 und YOLO26. An jeder Zusammenführungsstelle kommt somit dasselbe Modul wie im Backbone zum Einsatz. Die drei zusammengeführten Ausgaben werden dem Head zugeführt. YOLOv3 ist die Ausnahme: Sein Neck besteht ausschließlich aus einem FPN von oben nach unten (der YAML-Head enthält kein Downsampling mit Stride 2) und hat keinen Bottom-up-PAN-Pfad, den YOLOv5 eingeführt hat.

Detection Head: ankerbasiert → ankerfrei → ohne NMS#

Der Head wandelt die drei zusammengeführten Merkmalskarten in Vorhersagen für die Detektionsaufgabe um. Sein Aufbau hat sich über die Versionen hinweg verändert: von ankerbasiert zu ankerfrei und schließlich zu einer Variante ohne NMS.

Ankerfreier, entkoppelter Detect#

Das ursprüngliche YOLOv3 und YOLOv5 verwendeten einen ankerbasierten, gekoppelten Head: vordefinierte Ankerboxen und einen gemeinsamen Zweig für Box- und Klassenvorhersagen. Die eigenständigen Repositories ultralytics/yolov3 und ultralytics/yolov5 behalten diesen ankerbasierten Aufbau bei. Das Hauptpaket ultralytics enthält stattdessen die ankerfreien Varianten YOLOv3u und YOLOv5u – mit denselben Darknet-53- und C3-Backbones, aber mit dem ankerfreien Detect-Head von YOLOv8. Die hier dokumentierten Konfigurationen yolov3.yaml und yolov5.yaml gehören zu diesen u-Varianten, nicht zum historischen Aufbau.

Der Detect-Head (head.py) ist ankerfrei und entkoppelt: Auf jeder Pyramidenebene führt er zwei parallele Zweige aus und sagt Merkmale direkt an Gitterpunkten statt relativ zu Ankerboxen voraus.

• Box-Zweig (cv2): Conv(x, c2, 3) → Conv(c2, c2, 3) → Conv2d(c2, 4 * reg_max, 1).
• Klassenzweig (cv3): Bei YOLO11 und YOLO26 kommen zwei tiefenweise separierbare Blöcke zum Einsatz (DWConv + 1x1 Conv) → Conv2d(c3, nc, 1); YOLOv8 verwendet die ältere Variante mit zwei 3x3 Conv-Layern → Conv2d(c3, nc, 1).

Jeder Ankerpunkt gibt somit no = nc + 4 * reg_max Werte aus. Durch den Wegfall vordefinierter Anker müssen Ankerboxgrößen und Seitenverhältnisse nicht mehr als Hyperparameter abgestimmt werden.

Distribution Focal Loss (DFL)#

YOLOv8 und YOLO11 modellieren jede der vier Boxkoordinaten als Verteilung über reg_max = 16 Bins, statt einen einzelnen Skalar vorherzusagen (die Integralform aus Generalized Focal Loss). Das Modul DFL formt die 4 * reg_max Boxkanäle in (4, reg_max) um, wendet Softmax über die reg_max Bins an und verwendet den erwarteten Bin-Index als vorhergesagte Koordinate. Dazu wird jeder Bin-Index mit seiner Softmax-Wahrscheinlichkeit gewichtet und anschließend summiert. Das wird durch eine feste 1x1-Faltung implementiert, deren Gewichte die Bin-Indizes arange(reg_max) sind. Die gewichtete Summe entspricht damit einem einzelnen Skalarprodukt.

YOLO26: ohne NMS, ohne DFL#

YOLO26 setzt zwei YAML-Parameter, die der Head direkt ausliest:

• end2end: True – Detect erstellt durch Kopieren seiner Zweige einen One-to-One-Head (one2one_cv2/one2one_cv3), der eine einzelne Vorhersage pro Objekt lernt. Diese YAML-Einstellung erzeugt beide Trainings-Heads; zur Laufzeit wählt nms=False den One-to-One-Head aus und entfernt die Nachbearbeitung durch Non-Maximum Suppression (NMS). Einzelheiten zu Inferenz und Export findest du im Leitfaden zur End-to-End-Erkennung.
• reg_max: 1 – bei einem Bin wird self.dfl zu nn.Identity() und no = nc + 4; der Head regressiert die Koordinaten direkt, und im exportierten ONNX-Graph ist keine DFL-Operation enthalten.

In seinen fünf Modellgrößen (n/s/m/l/x) erreicht YOLO26 laut YOLO26-Studie auf COCO 40,9–57,5 mAP bei einer TensorRT-Latenz auf T4 von 1,7–11,8 ms.

Zusammenfassung nach Version#

Einzelheiten zu den jeweiligen Modellen, Leistungstabellen und Anwendungsbeispiele findest du auf den einzelnen Seiten zu YOLOv3, YOLOv5, YOLOv8, YOLO11 und YOLO26.

Untersuche die Architektur selbst#

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

from ultralytics import YOLO

# Vortrainiertes Modell laden
model = YOLO("yolo11n.pt")

# Fasse Conv- und BatchNorm-Layer zusammen, damit die Werte den veröffentlichten Spezifikationen entsprechen
model.fuse()

# Gib eine Zusammenfassung aus: Layer, Parameter, Gradienten, GFLOPs
model.info()

# Untersuche den Detection Head (das letzte Modul im Netzwerk)
head = model.model.model[-1]
print(type(head).__name__, "| reg_max:", head.reg_max, "| DFL layer:", type(head.dfl).__name__)

Wenn du das Snippet auf drei Generationen anwendest, werden die Änderungen anhand der Zahlen sichtbar. Dies sind tatsächliche Ausgaben der zusammengeführten Modelle aus dem Paket ultralytics; die Parameter- und FLOPs-Werte entsprechen den Angaben auf den jeweiligen Modellseiten:

YOLO26n weist reg_max=1 und einen DFL-Layer Identity aus. Vorhersage und Validierung verwenden standardmäßig One-to-Many mit NMS; setze nms=False, um Inferenz ohne NMS auszuführen. Beide Heads werden trainiert.

Fazit#

Im Laufe der Versionen wurde die YOLO-Architektur schrittweise verändert: Das Backbone wechselte von Darknet-53 zu CSP-basierten C3-, C2f- und C3k2-Blöcken mit C2PSA-Attention; der Neck behielt seine FPN- und PAN-Struktur bei, während SPP zu SPPF wurde; und der Head wechselte von anchor-basiert zu anchor-frei und anschließend zum DFL-freien Design von YOLO26 mit einem optionalen NMS-freien End-to-End-Head.

Informationen zum Definieren eigener Architekturen findest du im Leitfaden zur YAML-Modellkonfiguration oder beim Vergleich der Modelle auf den Modellseiten. Bei Fragen kannst du dich über GitHub oder Discord an uns wenden.

Häufig gestellte Fragen#