Link to this sectionYOLO-Architektur erklärt: Von YOLOv3 bis YOLO26#

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

Jedes Modell wird deklarativ in einer YAML-Datei als geordnete Liste von Schichten definiert, wobei jede Schicht dem Format [from, repeats, module, args] folgt: welche Schicht(en) sie speisen, wie oft das Modul wiederholt wird, die Schichtklasse (Conv, C3k2, SPPF, Detect, …) und ihre Konstruktor-Argumente. Der Leitfaden zur Modell-YAML-Konfiguration dokumentiert dieses Format — einschließlich der Art und Weise, wie repeats und args mit der Tiefe und Breite der Variante skalieren — zusammen mit dem System zur Modulauflösung im Detail. Dieser Leitfaden konzentriert sich auf die Module selbst und darauf, wie sie sich von Version zu Version verändert haben.

Link to this sectionDie drei Stufen#

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

Die grundlegende Einheit ist der Conv-Block (definiert in conv.py): eine 2D-Faltung, batch normalization und eine SiLU-Aktivierung, die nacheinander angewendet werden. Jedes größere Modul weiter unten ist aus Conv-Blöcken zusammengesetzt.

Link to this sectionArchitekturdiagramme#

Jede Version behält das gleiche Backbone → Neck → Head-Skelett bei und ändert spezifische Stufen. Die Reiter unten zeigen die Struktur pro Version: 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 und nicht als ankerfreie u-Varianten-Heads, die ihre Paketkonfigurationen tatsächlich ausliefern. Das Durchgehen der Reiter zeigt, was jede Generation hinzugefügt hat. Kurz gesagt: YOLOv3 ist ein reiner FPN-, ankerbasierter 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 einen SPPF-Residual hinzu und macht den Head NMS-frei und DFL-frei. Die Knotenfarben folgen der Konvention der Dokumentationsdiagramme: grün für Eingabe, blau für Backbone, schiefergrau für räumliches Pooling und Attention, orange für Neck, lila für 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 YOLOv3- und YOLOv5-Diagramme zeigen den ursprünglichen ankerbasierten Head. Das ultralytics-Paket liefert die ankerfreien YOLOv3u- und YOLOv5u-Konfigurationen aus — dieselben Darknet-53- und C3-Backbones mit dem Detect-Head von YOLOv8 — die unter Detection Head beschrieben sind.

Link to this sectionBackbone-Blöcke: Bottleneck → C3 → C2f → C3k2#

Der Backbone stapelt einen sich wiederholenden CSP (Cross-Stage Partial)-Block zwischen Stride-2-Conv-Downsampling-Schichten. Dieser sich wiederholende Block hat sich über die Versionen hinweg am stärksten verändert. Alle unten aufgeführten Blöcke befinden sich in block.py; c1/c2 sind Eingangs-/Ausgangskanäle und c = 0.5 * c2 ist die verborgene Breite.

Link to this sectionBottleneck (YOLOv3)#

Die Basiseinheit ist Bottleneck: zwei Conv-Schichten (Standard-Kernel (3, 3)) mit einem optionalen Residual-Add, wenn shortcut=True und c1 == c2. Der Darknet-53-Backbone von YOLOv3 stapelt diese direkt, ohne CSP-Split, und detektiert in drei Skalen (Strides 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))

Nur der endgültige Bottleneck-Ausgang erreicht die Fusions-Conv, daher sieht cv3 2 Merkmalskarten.

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), dann teilt chunk(2) den Ausgang in zwei c-Kanal-Tensoren auf.
2. n Bottleneck(c, c)-Blöcke (Kernel (3, 3), (3, 3)) laufen sequentiell, wobei jeder den Ausgang des vorherigen Blocks erhält.
3. Alle n + 2 Zwischen-Tensoren werden verkettet und durch cv2 = Conv((2 + n) * c, c2, 1) zusammengeführt.

Während C3 2 Merkmalskarten in seine Fusions-Conv leitet, leitet C2f n + 2 weiter — jeder Zwischen-Bottleneck-Ausgang wird wiederverwendet.

Link to this sectionC3k2 (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 konfigurierbarer Kernelgröße, oder
• einem Bottleneck + PSABlock-Paar (attn=True).

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

Link to this sectionRäumliches Pooling: SPP → SPPF#

Am Ende des Backbones erweitert ein Spatial-Pyramid-Pooling-Block das rezeptive Feld. YOLOv5 ersetzte das ursprüngliche Multi-Kernel-SPP durch SPPF (Spatial Pyramid Pooling - Fast): ein einzelner MaxPool2d(kernel_size=5, stride=1, padding=2), der n = 3 Mal hintereinander angewendet wird, wobei die Eingabe und alle drei gepoolten Ausgänge 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-Pools 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 Residual-Verbindung (return y + x) hinzu.

Link to this sectionRäumliche Attention: C2PSA (YOLO11+)#

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

Link to this sectionNeck: FPN + PAN#

Der Neck führt die P3/P4/P5-Merkmalskarten 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 (trägt semantische Informationen zu höheren Auflösungen nach unten) und PAN ist Stride-2 Conv + Concat (trä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 ausführt, das auch der Backbone verwendet. Die drei zusammengeführten Ausgänge 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 Bottom-Up-PAN-Pfad, den YOLOv5 einführte.

Link to this sectionDetection Head: Ankerbasiert → Ankerfrei → NMS-frei#

Der Head verwandelt die drei zusammengeführten Merkmalskarten in Vorhersagen für die Detektionsaufgabe. Sein Design hat sich über die Versionen hinweg geändert, von ankerbasiert über ankerfrei bis hin zu NMS-frei.

Link to this sectionAnkerfreier, entkoppelter Detect-Head#

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 dieses ankerbasierte Design bei. Das Hauptpaket ultralytics liefert stattdessen die ankerfreien YOLOv3u- und YOLOv5u-Varianten — dieselben Darknet-53- und C3-Backbones mit dem ankerfreien Detect-Head von YOLOv8 — und die hier dokumentierten yolov3.yaml- und yolov5.yaml-Konfigurationen sind diese u-Varianten, nicht das historische Design.

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

• 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 emittiert daher no = nc + 4 * reg_max Ausgänge. Das Entfernen vordefinierter Anker streicht die Ankerboxgrößen und Seitenverhältnisse aus den Hyperparametern, die angepasst werden müssen.

Link to this sectionDistribution Focal Loss (DFL)#

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

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

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

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

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

Link to this sectionZusammenfassung nach Versionen#

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

Link to this sectionUntersuche die Architektur selbst#

Die Methode model.info() druckt eine Zusammenfassung von Schicht, Parametern und FLOPs, 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 Veränderungen numerisch. Dies sind echte Ausgaben fusionierter Modelle aus dem ultralytics-Paket, die mit den auf jeder Modellseite veröffentlichten Parameter- und FLOPs-Anzahlen übereinstimmen:

YOLO26n meldet reg_max=1, end2end=True und eine Identity-DFL-Schicht — das architektonische Merkmal seines NMS-freien, DFL-freien Heads.

Link to this sectionFazit#

Über die Versionen hinweg änderte sich die YOLO-Architektur schrittweise: Das 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 anchor-basiert zu anchor-free und dann zum NMS-freien, DFL-freien End-to-End-Design von YOLO26.

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

Link to this sectionFAQ#

Link to this sectionWas sind die drei Stufen einer YOLO-Architektur?#

Ein YOLO-Modell verfügt über ein Backbone, das Merkmale aus dem Bild mit Strides von 8, 16 und 32 extrahiert, einen Neck, der diese Merkmale über Skalen hinweg mit FPN und PAN fusioniert, und einen Head, der Bounding Boxes und Klassenscores vorhersagt. Jedes Ultralytics YOLO-Modell von YOLOv3 bis YOLO26 folgt diesem dreistufigen Design.

Link to this sectionWas ist der Unterschied zwischen den C2f- und C3k2-Blöcken?#

C2f (YOLOv8) ist ein CSP-Block, der die Ausgaben jedes internen Bottleneck — n + 2 Feature Maps — vor seiner Fusions-Convolution verkettet, wobei der ältere C3 nur 2 weitergibt. C3k2 (YOLO11 und YOLO26) ist eine Unterklasse von C2f, die jeden Bottleneck durch einen C3k-Block (eine C3-Variante mit konfigurierbarer Kernelgröße) ersetzen kann, wenn das c3k-Flag gesetzt ist. Beide sind in block.py definiert.

Link to this sectionWas hat sich in der Architektur zwischen YOLOv8 und YOLO11 geändert?#

YOLO11 nimmt drei strukturelle Änderungen an YOLOv8 vor: Es ersetzt den C2f-Backbone- und Neck-Block durch C3k2, fügt einen C2PSA-Self-Attention-Block nach SPPF ein und stellt den Klassifikationszweig des Head auf leichtere depthwise-separable Convolutions um. Beide behalten denselben anchor-freien, entkoppelten Detect-Head mit reg_max=16 DFL-Regression bei, sodass die Änderungen die Parameter- und FLOPs-Werte senken und die Genauigkeit erhöhen, anstatt das Erkennungs-Interface neu zu gestalten.

Link to this sectionIst YOLO anchor-free?#

Moderne Ultralytics YOLO-Modelle sind anchor-free. YOLOv8, YOLO11 und YOLO26 verwenden einen anchor-freien, entkoppelten Detect-Head mit separaten Zweigen für Box-Regression und Klassifikation. Die ursprünglichen YOLOv3 und YOLOv5 waren anchor-basiert, aber Ultralytics liefert sie als YOLOv3u- und YOLOv5u-Varianten aus, deren Konfigurationen denselben anchor-freien Head wie YOLOv8 verwenden.

Link to this sectionHat YOLO26 NMS entfernt?#

Ja — YOLO26 setzt end2end=True, was dem Detect-Head ein One-to-One-Design verleiht, das eine einzige Vorhersage pro Objekt liefert und den für frühere Modelle erforderlichen Non-Maximum Suppression-Nachbearbeitungsschritt entfernt. Siehe den End-to-End Detection Guide für Details.

Link to this sectionWas ist Distribution Focal Loss (DFL) und warum hat YOLO26 es entfernt?#

DFL regrediert jede Box-Koordinate als Softmax-Verteilung über reg_max-Bins (standardmäßig 16 in YOLOv8 und YOLO11) und nimmt den Erwartungswert als Koordinate, anstatt einen einzelnen Skalar vorherzusagen. YOLO26 setzt reg_max=1, sodass die DFL-Schicht zu einer Identitätsoperation wird, der Head die Koordinaten direkt regrediert und in exportierten ONNX- oder TensorRT-Graphen keine DFL-Operation erscheint.

Link to this sectionWie kann ich die Architektur eines bestimmten YOLO-Modells sehen?#

Lade das Modell in Python und rufe model.info() für eine Zusammenfassung der Layer, Parameter und GFLOPs auf. Die geparsten Layer befinden sich in model.model.model — zum Beispiel ist model.model.model[-1] der Detect-Head, der Attribute wie reg_max und end2end offenlegt. Die vollständige Architektur ist in der YAML-Konfigurationsdatei des Modells definiert.