End-to-End-Erkennung in Ultralytics YOLO26 verstehen#

YOLO26 detection-style models — Erkennung, Segmentierung, Pose und OBB — sind standardmäßig NMS-frei: Sie geben endgültige Erkennungen direkt vom Modell aus, ohne einen Non-Maximum Suppression (NMS) Nachbearbeitungsschritt. Ältere Modelle wie YOLOv8 und YOLO11 erzeugen Tausende von überlappenden Vorhersagen, die ein separater NMS-Schritt herausfiltern muss, was die Latenz erhöht, Exportgraphen verkompliziert und sich auf verschiedenen Hardwareplattformen unterschiedlich verhalten kann.

Dies wird als End-to-End object detection bezeichnet und ist standardmäßig aktiviert. Das Ergebnis ist eine einfachere Bereitstellungspipeline und eine geringere Latenz — YOLO26n läuft auf Intel Xeon CPU @ 2.00 GHz bis zu 43 % schneller als YOLO11n bei der CPU-ONNX-Inferenz.

Dieser Leitfaden führt dich durch die Änderungen, erklärt, ob du deinen Code aktualisieren musst, welche Exportformate die End-to-End-Inferenz unterstützen und wie du problemlos von älteren YOLO-Modellen migrierst.

Einen tieferen Einblick in die Motivation hinter diesem architektonischen Wandel findest du im Blogbeitrag von Ultralytics darüber, warum YOLO26 NMS entfernt.

Wie End-to-End-Erkennung funktioniert#

YOLO26 verwendet während des Trainings eine Architektur mit zwei Köpfen. Beide Köpfe teilen sich dasselbe Backbone und denselben Neck, erzeugen die Ausgaben jedoch auf unterschiedliche Weise:

Die obigen Formen gelten für die detection, wobei N die batch size ist, nc die Anzahl der Klassen (z. B. 80 für COCO) und die Ankeranzahl von 8400 der Wert bei imgsz=640 ist. Andere Aufgaben erweitern die Eins-zu-Eins-Ausgabe um zusätzliche Daten pro Erkennung:

Während des Trainings laufen beide Köpfe gleichzeitig – der 1:viele-Kopf liefert ein reichhaltigeres Lernsignal, während der 1:1-Kopf lernt, saubere, sich nicht überschneidende Vorhersagen zu erzeugen. Während der Inferenz und des Exports ist standardmäßig nur der 1:1-Kopf aktiv, der bis zu 300 Detektionen pro Bild im Format [x1, y1, x2, y2, confidence, class_id] liefert.

Wenn du model.fuse() aufrufst, werden Conv- und BatchNorm-Schichten für eine schnellere Inferenz zusammengelegt, und bei End-to-End-Modellen wird außerdem der 1:viele-Kopf entfernt, wodurch Modellgröße und FLOPs reduziert werden. Weitere Einzelheiten zur Architektur mit zwei Köpfen findest du auf der YOLO26-Modellseite.

Muss ich meinen Code ändern?#

Verwendung der Ultralytics Python API oder CLI#

Keine Änderungen erforderlich. Wenn du die Standard-Ultralytics Python API oder CLI verwendest, funktioniert alles automatisch – Vorhersage, Validierung und Export verarbeiten End-to-End-Modelle von Haus aus.

from ultralytics import YOLO

# Load a YOLO26 model
model = YOLO("yolo26n.pt")

# Predict — no NMS step, no code changes
results = model.predict("image.jpg")

Verwendung von benutzerdefiniertem Inferenzcode#

Ja, das Ausgabeformat ist anders. Wenn du benutzerdefinierte Nachbearbeitungslogik für YOLOv8 oder YOLO11 geschrieben hast (z. B. beim Ausführen der Inferenz mit ONNX Runtime oder TensorRT), musst du diese aktualisieren, um die neue Ausgabeform zu verarbeiten:

Bei Segmentierungs-, Posen- und OBB-Aufgaben hängt YOLO26 aufgabenspezifische Daten an jede Detektion an – siehe die Tabelle der Ausgabeformen.

Mit End-to-End-Modellen wird die Nachbearbeitung viel einfacher – zum Beispiel bei der Verwendung von ONNX Runtime:

import onnxruntime as ort

# Load and run the exported end-to-end model
session = ort.InferenceSession("yolo26n.onnx")
output = session.run(None, {session.get_inputs()[0].name: input_tensor})

# End-to-end output: (batch, 300, 6) → [x1, y1, x2, y2, confidence, class_id]
detections = output[0][0]  # first image in batch
detections = detections[detections[:, 4] > 0.25]  # confidence filter, no NMS

Umschalten auf den One-to-Many-Kopf#

Wenn du das traditionelle YOLO-Ausgabeformat benötigst (z. B. um bestehenden NMS-basierten Nachbearbeitungscode wiederzuverwenden), kannst du zum 1:viele-Kopf wechseln, sofern dieser verfügbar ist, indem du end2end=False einstellst:

from ultralytics import YOLO

model = YOLO("yolo26n.pt")

# Prediction with NMS (traditional behavior)
results = model.predict("image.jpg", end2end=False)

# Validation with NMS
metrics = model.val(data="coco.yaml", end2end=False)

# Export without end-to-end
model.export(format="onnx", end2end=False)

Kompatibilität der Exportformate#

Die meisten Exportformate unterstützen die End-to-End-Inferenz von Haus aus, darunter ONNX, TensorRT, CoreML, OpenVINO, LiteRT und MNN.

Die folgenden Formate unterstützen End-to-End nicht und greifen automatisch auf den 1:viele-Kopf zurück: NCNN, RKNN, PaddlePaddle, ExecuTorch, IMX, Edge TPU und Qualcomm QNN.

Für Hailo wählt der Exporter den Ausgabepfad aus dem geladenen Kopf statt aus einem Argument, sodass end2end bei Übergabe abgelehnt wird: Ein standardmäßiges YOLO26-Erkennungsmodell behält seine NMS-freien Eins-zu-Eins-Ausgaben, während ein Checkpoint, dessen Kopf bereits end2end=False ist, den herkömmlichen Pfad mit HailoRT NMS kompiliert.

Kompromisse zwischen Genauigkeit und Geschwindigkeit#

End-to-End-Detektion bietet erhebliche Vorteile bei der Bereitstellung bei minimalen Auswirkungen auf die Genauigkeit:

Über die fünf Erkennungsskalen hinweg kostet der Eins-zu-Eins-Kopf 0,6-0,8 mAP auf COCO — 40,9 bis 40,1 für YOLO26n und 57,5 bis 56,9 für YOLO26x — im Austausch für den vollständigen Wegfall des NMS-Durchlaufs. Wenn maximale Genauigkeit für dich Priorität hat, greife auf den Eins-zu-Viele-Kopf mit end2end=False zurück.

Siehe die YOLO26-Leistungsmetriken für detaillierte Benchmarks über alle Modellgrößen hinweg (n, s, m, l, x).

Migration von YOLOv8 oder YOLO11#

Wenn du ein bestehendes Projekt auf YOLO26 aktualisierst:

• Benutzer von Ultralytics API / CLI: Keine Änderungen erforderlich – aktualisiere einfach den Modellnamen auf yolo26n.pt (oder yolo26n-seg.pt, yolo26n-pose.pt, yolo26n-obb.pt)
• Benutzerdefinierter Nachbearbeitungscode: Aktualisiere ihn zur Verarbeitung der neuen Ausgabeformen – (N, 300, 6) für die Detektion sowie aufgabenspezifische Daten für Segmentierung, Pose und OBB. Beachte auch die Änderung des Box-Formats von xywh zu xyxy
• Exportpipelines: Überprüfe den Abschnitt zur Formatkompatibilität für dein Zielformat
• TensorRT unter 8.5.0: End-to-End ist bei jeder Präzision deaktiviert — aktualisiere TensorRT auf 8.5.0 oder höher, um es beizubehalten
• Quantisierte Exporte: TensorRT 10.3.0 mit quantize=8 auf JetPack 6 und LiteRT mit quantize=8 oder quantize="w8a16" deaktivieren End-to-End automatisch — exportiere mit einer höheren Präzision, um es beizubehalten
• FP16-Exporte: Wenn du alle Ausgaben in FP16 benötigst, exportiere mit end2end=False – siehe warum output0 FP32 bleibt
• iOS / CoreML: End-to-End wird vollständig unterstützt. Wenn du Xcode-Vorschauunterstützung benötigst, verwende end2end=False mit nms=True
• Edge-Geräte (NCNN, RKNN): Diese Formate fallen automatisch auf One-to-Many zurück, also füge NMS in deine On-Device-Pipeline ein

Fazit#

Die End-to-End-Detektion ist in YOLO26 der Standard und erfordert keine Codeänderungen, wenn du die Ultralytics Python API oder CLI verwendest. Lediglich benutzerdefinierte Nachbearbeitungspipelines müssen aktualisiert werden, um die neue (N, 300, 6)-Ausgabe zu lesen und den NMS-Schritt wegzulassen – mit Ausnahme von Exportformaten, die auf die 1:viele-Ausgabe zurückgreifen (wie NCNN und RKNN), welche weiterhin NMS auf dem Gerät erfordern. Detaillierte Geschwindigkeits- und Genauigkeits-Benchmarks über alle Modellgrößen hinweg findest du auf der YOLO26-Modellseite und den vollständigen Satz an Exportoptionen und -formaten in der Dokumentation zum Export-Modus.

FAQ#