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

Jedes Ultralytics YOLO-Modell besteht aus drei Stufen: einem Backbone, der Merkmale extrahiert, einem Neck, der sie über mehrere Maßstäbe hinweg zusammenführt, und einem Head, der Boxen und Klassen vorhersagt. Dieser Leitfaden dokumentiert die Module der einzelnen Stufen und ihre Änderungen von YOLOv3 bis YOLO26 und ordnet jede Komponente ihrer Definition in den Konfigurationsdateien unter ultralytics/cfg/models/ sowie den Modulklassen in ultralytics/nn/modules/ zu.

Jedes Modell wird deklarativ in einer YAML-Datei als geordnete Liste von Layern definiert. Jeder Layer folgt dem Format [from, repeats, module, args]: von welchen Layern er Eingaben erhält, wie oft das Modul wiederholt wird, die Layerklasse (Conv, C3k2, SPPF, Detect, …) und ihre Konstruktorargumente. Der Leitfaden zur YAML-Modellkonfiguration dokumentiert dieses Format – einschließlich der Skalierung von repeats und args mit den Tiefen- und Breitenmultiplikatoren der Variante – sowie das Modulauflösungssystem im Detail. Dieser Leitfaden konzentriert sich auf die Module selbst und ihre Änderungen von Version zu Version.

Die drei Stufen#

Jedes Ultralytics YOLO-Modell führt das Bild durch drei aufeinanderfolgende Stufen, die jeweils eine bestimmte Aufgabe erfüllen:

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

Architekturdiagramme#

Jede Version behält das gleiche Grundgerüst aus Backbone → Neck → Head bei und verändert bestimmte Stufen. Die folgenden Registerkarten zeigen die Struktur 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 ankerbasierten Form dargestellt sind, statt als die tatsächlich in den Paketkonfigurationen enthaltene ankerfreie u-Varianten-Head. Beim Durchgehen der Registerkarten siehst du, was jede Generation hinzugefügt hat. Kurz zusammengefasst: YOLOv3 ist ein ausschließlich auf FPN basierender, ankerbasierter Detektor; YOLOv5 ergänzt den Bottom-up-PAN-Pfad und SPPF; YOLOv8 wechselt zum C2f-Block mit einem ankerfreien DFL-Head; YOLO11 fügt C2PSA-Aufmerksamkeit und den C3k2-Block ein; und YOLO26 ergänzt eine SPPF-Restverbindung und macht den Head frei von NMS und DFL. Die Knotenfarben folgen der Konvention der Dokumentationsdiagramme: grüner Eingang, blaues Backbone, schiefergraues räumliches Pooling und Aufmerksamkeit, orangefarbener Neck, violetter Head und Ausgabe.

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 ankerbasierten Head. Das Paket ultralytics enthält die ankerfreien Konfigurationen YOLOv3u und YOLOv5u – dieselben Darknet-53- und C3-Backbones mit dem Detect-Head von YOLOv8 –, die unter Detection Head beschrieben werden.

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

Das Backbone stapelt einen wiederholten CSP-Block (Cross-Stage Partial) zwischen Downsampling-Layern Conv mit Stride 2. Dieser wiederholte 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 Eingabe-/Ausgabekanäle und c = 0.5 * c2 ist die verborgene Breite.

Bottleneck (YOLOv3)#

Die Basiseinheit ist Bottleneck: zwei Conv-Layer (Standardkernel (3, 3)) mit einer optionalen Restaddition, wenn shortcut=True und c1 == c2. Das Darknet-53-Backbone von YOLOv3 stapelt diese direkt, ohne CSP-Aufteilung, und führt Detektionen auf drei Maßstäben durch (Strides 8, 16, 32).

C3 (YOLOv5)#

C3 von YOLOv5 teilt die Eingabe über zwei 1x1-Faltungen auf: cv1 führt zu n aufeinanderfolgenden Bottleneck-Blöcken (Kernel (1, 1), dann (3, 3)), während cv2 sie umgeht. 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 Ausgabe des letzten Bottlenecks erreicht die Fusionsfaltung, daher sieht cv3 zwei Feature-Maps.

C2f (YOLOv8)#

C2f von YOLOv8 („CSP Bottleneck with 2 convolutions, faster“) 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 c Kanälen auf.
2. n-Bottleneck(c, c)-Blöcke (Kernel (3, 3), (3, 3)) werden nacheinander ausgeführt, wobei jeder die Ausgabe des vorherigen Blocks erhält.
3. Alle n + 2-Zwischentensoren werden verkettet und durch cv2 = Conv((2 + n) * c, c2, 1) zusammengeführt.

Während C3 zwei Feature-Maps an seine Fusionsfaltung übergibt, übergibt C2f n + 2 – jede Ausgabe eines Zwischen-Bottlenecks 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 Variante von C3 mit konfigurierbarer Kernelgröße – oder
• einem Paar aus Bottleneck + PSABlock (attn=True).

Das zweite YAML-Argument legt c3k fest, außer wenn der Maßstab m, l oder x ist; dann wird der Wert auf True erzwungen. So bedient ein einziges yolo11.yaml alle fünf Varianten. Daher erstellt [-1, 2, C3k2, [512, False]] die Interna von Bottleneck bei n und s, aber die Interna von C3k bei m, l und x; 512 ist die Kanalzahl vor der Skalierung, die der Breitenmultiplikator der Variante bei n in 128 und bei x in 768 umwandelt. Bei CSP-Modulen wird das Feld repeats – hier 2, bevor es mit dem Tiefenmultiplikator der Variante skaliert wird – zur internen Wiederholungsanzahl des Blocks, statt separate Module zu stapeln.

Räumliches Pooling: SPP → SPPF#

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

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

Räumliche Aufmerksamkeit: C2PSA (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 (Position-Sensitive 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 Verkettung zusammen. Jedes PSABlock wendet Aufmerksamkeit mit mehreren Köpfen an, gefolgt von einem zweischichtigen Feedforward-Netzwerk (Conv(c, 2 * c, 1) → Conv(2 * c, c, 1)), jeweils mit einer Restverbindung. YOLO26 behält dasselbe 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) und anschließend einem Bottom-up-Path-Aggregation-Network (PAN) zusammen. Im YAML-Head-Abschnitt ist FPN nn.Upsample + Concat (überträgt semantische Informationen auf höhere Auflösungen), und PAN ist Conv + Concat mit Stride 2 (überträgt Lokalisierungsinformationen zurück nach oben):

# 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 wie das Backbone ausführt. Die drei zusammengeführten Ausgaben werden an den Head übergeben. YOLOv3 ist die Ausnahme: Sein Neck besteht nur aus einem Top-down-FPN (sein YAML-Head enthält kein Downsampling mit Stride 2) und nicht aus dem Bottom-up-PAN-Pfad, den YOLOv5 eingeführt hat.

Detection Head: ankerbasiert → ankerfrei → frei von NMS#

Der Head wandelt die drei zusammengeführten Feature-Maps in Vorhersagen für die Detektionsaufgabe um. Sein Aufbau hat sich über die Versionen vom ankerbasierten über den ankerfreien zum NMS-freien Ansatz entwickelt.

Ankerfreier, entkoppelter Detect#

Das ursprüngliche YOLOv3 und YOLOv5 verwendeten einen ankerbasierten, gekoppelten Head: vorab definierte Ankerboxen und einen gemeinsamen Zweig für Box- und Klassenvorhersagen. Die eigenständigen Repositorys ultralytics/yolov3 und ultralytics/yolov5 behalten dieses ankerbasierte Design bei. Das Hauptpaket ultralytics enthält stattdessen die ankerfreien Varianten YOLOv3u und YOLOv5u – dieselben Darknet-53- und C3-Backbones mit dem ankerfreien Detect-Head von YOLOv8. 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 Pyramidenstufe führt er zwei parallele Zweige aus und sagt direkt an Rasterpunkten statt relativ zu Ankerboxen voraus.

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

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

Distribution Focal Loss (DFL)#

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

YOLO26: frei von NMS und DFL#

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

• end2end: True – Detect kopiert seine Zweige in einen One-to-one-Head (one2one_cv2/one2one_cv3), der eine einzelne Vorhersage pro Objekt erzeugt und dadurch die Nachverarbeitung mit Non-Maximum Suppression (NMS) entfernt. Einzelheiten zu Export und Migration findest du im Leitfaden zur End-to-End-Detektion.
• 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-Graphen erscheint keine DFL-Operation.

Über seine fünf Modellgrößen (n/s/m/l/x) erreicht YOLO26 auf COCO 40.9–57.5 mAP bei einer T4-TensorRT-Latenz von 1.7–11.8 ms, wie im YOLO26-Paper berichtet.

Zusammenfassung nach Version#

Details zu den einzelnen Modellen, Leistungstabellen und Anwendungsbeispiele findest du auf den jeweiligen 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 Liste der geparsten Module 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)

Wenn du das Snippet über drei Generationen hinweg ausführst, werden die Änderungen numerisch sichtbar. Dies sind echte Ausgaben zusammengeführter Modelle aus dem Paket ultralytics, die den auf jeder Modellseite veröffentlichten Parameter- und FLOPs-Zahlen entsprechen:

YOLO26n meldet reg_max=1, end2end=True und einen Identity-DFL-Layer – das architektonische Kennzeichen seines NMS-freien, DFL-freien Heads.

Fazit#

Über die Versionen hinweg wurde die YOLO-Architektur schrittweise verändert: Das Backbone entwickelte sich von Darknet-53 zu CSP-basierten C3-, C2f- und C3k2-Blöcken mit C2PSA-Aufmerksamkeit; der Neck behielt seine FPN- + PAN-Struktur bei, während SPP zu SPPF wurde; und der Head entwickelte sich vom ankerbasierten zum ankerfreien und schließlich zum NMS-freien, DFL-freien End-to-End-Design von YOLO26.

Zum Definieren benutzerdefinierter Architekturen siehe den Leitfaden zur YAML-Modellkonfiguration oder vergleiche Modelle auf den Modellseiten. Bei Fragen kannst du dich an GitHub oder Discord wenden.

FAQ#