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

YOLO26 trainiert sowohl einen One-to-many-Kopf als auch einen One-to-one-Kopf. Vorhersage und Validierung verwenden standardmäßig den One-to-many-Kopf mit Unterdrückung nicht maximaler Werte (NMS). Das begünstigt die Genauigkeit bei Verwendung derselben trainierten Gewichte. Setze nms=False, um stattdessen den schnelleren One-to-one-Kopf ohne NMS zu verwenden.

Ein Argument steuert die Auswahl bei Vorhersagen, Validierung, Tracking, Export und Benchmarking:

None bedeutet, dass keine optionale Nachverarbeitung in das Modell eingebettet ist. Die normale Verarbeitung, die Modellausgaben in Vorhersageergebnisse oder Validierungsmetriken umwandelt, bleibt davon unberührt. Klassifizierung, semantische Segmentierung, Tiefenschätzung und Modelle ohne auswählbare Detektionsköpfe behalten das für ihre Aufgabe vorgesehene Verhalten.

from ultralytics import YOLO

model = YOLO("yolo26n.pt")
results = model.predict("image.jpg")  # One-to-many + NMS
metrics = model.val(data="coco.yaml")  # One-to-many + NMS
results = model.predict("image.jpg", nms=False)  # Inferenz ohne NMS aktivieren
results = model.predict("image.jpg", nms=None)  # Zurück zu One-to-many + NMS wechseln

model.export(format="onnx")  # Rohausgaben des One-to-many-Kopfs
model.export(format="onnx", nms=True)  # NMS einbetten
model.export(format="onnx", nms=False)  # Ausgaben des One-to-one-Kopfs ohne NMS

So funktioniert die End-to-End-Detektion#

Beide Köpfe verwenden denselben Backbone und Neck und werden während des Trainings optimiert. Der One-to-many-Kopf liefert mehrere Vorhersagekandidaten pro Objekt; NMS entfernt überlappende Detektionen. Der One-to-one-Kopf lernt, eine einzelne Vorhersage pro Objekt zu erzeugen. Die Auswahl des Inferenzpfads deaktiviert nicht die Überwachung mit beiden Köpfen. Während des Trainings verwendet die Validierung den ausgewählten Inferenzkopf. Dadurch richten sich die Auswahl des Checkpoints und das vorzeitige Beenden des Trainings nach denselben Vorhersagen wie bei der Bereitstellung.

Hier steht N für die Batchgröße, nc für die Anzahl der Klassen und 8400 für die Anzahl der Kandidaten bei imgsz=640. Die Detektionszeilen des One-to-one-Kopfs enthalten [x1, y1, x2, y2, confidence, class_id]. Bei anderen Detektionsaufgaben kommen weitere Ausgaben hinzu:

Beim Fusionieren werden nicht verwendete Inferenzzweige entfernt und Conv- und BatchNorm-Schichten zusammengeführt. Bewahre den ursprünglichen Trainingscheckpoint auf, wenn du zwischen den Köpfen wechseln musst: Ein bereits entfernter Zweig lässt sich durch die Fusion nicht wiederherstellen. Bei einem Modell, dessen Eins-zu-eins-Kopf als einziger übrig bleibt, steht dieser Pfad weiterhin zur Verfügung.

Exportierte Ausgaben#

Detektionsmodelle mit YOLOv8, YOLO11 und YOLO26 exportieren standardmäßig rohe Eins-zu-viele-Vorhersagen. Exportiere YOLO26 mit nms=False, um Detektionen ohne NMS zu erhalten.

nms=True erzeugt ebenfalls verarbeitete Detektionen, verwendet jedoch den Eins-zu-viele-Kopf und bindet herkömmliches NMS ein. Das ist nützlich, wenn die Laufzeitumgebung deiner Bereitstellung Detektionen erhalten soll, ohne die Unterdrückung selbst implementieren zu müssen.

Der Graph eines exportierten Modells legt dessen Ausgaben fest. Wenn du beim Laden nms übergibst, wird der Graph nicht neu erstellt. Exportiere den Quellcheckpoint mit dem gewünschten Wert nms, um den Ausgabeweg festzulegen. Ultralytics verwendet die Metadaten des Artefakts, um ein zweimaliges Anwenden von NMS zu verhindern.

Kompatibilität der Exportformate#

ONNX, TensorRT, CoreML, OpenVINO und mehrere weitere Formate unterstützen Exporte ohne NMS. NCNN, RKNN, PaddlePaddle, ExecuTorch, IMX, Edge TPU und Qualcomm QNN greifen auf den Eins-zu-viele-Pfad zurück, wenn ihre Operatoren keine durchgängige Ausgabe unterstützen. Warnungen zum Format erläutern den Rückgriff.

• Eingebettetes NMS: nms=True unterliegt den jeweiligen Einschränkungen des Formats hinsichtlich Aufgabe, Genauigkeit und dynamischer Formen. Formate ohne Unterstützung für eingebettetes NMS exportieren native Ausgaben zur externen Verarbeitung.
• CoreML: Eingebettetes NMS unterstützt detect, segment und pose bei statischen Formen. Verwende nms=True für Detektionsmodelle, die die NMS-Pipeline der Xcode-Vorschau benötigen.
• MNN: Eingebettetes NMS unterstützt detect und pose mit dynamic=False.
• IMX: Für Detektion, Instanzsegmentierung und pose ist eingebettetes NMS erforderlich; es wird automatisch ausgewählt.
• Hailo: YOLO26 verwendet standardmäßig rohe Tensoren mit NMS auf dem Host; nms=False wählt den Eins-zu-eins-Pfad. Bei der Detektion mit YOLOv8/YOLO11 kommt HailoRT NMS zum Einsatz.
• Quantisierung: TensorRT-Versionen vor 8.5.0, TensorRT 10.3.0 INT8 unter JetPack 6 sowie LiteRT INT8 oder w8a16 greifen auf Ausgaben im Eins-zu-viele-Format zurück.

Die Integrationsanleitungen enthalten Informationen zu den Hardwareanforderungen. Verwende nms=None für vollständige FP16-Ausgabetensoren. End-to-End-Klassenindizes können die Ausgabetensoren auch bei einem quantisierten Modell im FP32-Format belassen.

Kompromisse zwischen Genauigkeit und Geschwindigkeit#

Die veröffentlichten YOLO26-Ergebnisse auf COCO zeigen, dass der Eins-zu-viele-Kopf die Detektions-mAP über alle fünf Größen hinweg um 0,6–0,8 Punkte verbessert: zum Beispiel 40,9 gegenüber 40,1 bei YOLO26n und 57,5 gegenüber 56,9 bei YOLO26x. Der Eins-zu-eins-Kopf vermeidet den NMS-Durchlauf und ist auf geringe Latenz ausgelegt. Diese Ergebnisse begründen die Standardeinstellung, garantieren aber keinen Vorteil bei jedem Datensatz.

Veröffentlichte Messungen der NMS-freien Geschwindigkeit verwenden nms=False. Vergleiche Genauigkeit und Latenz bei identischer Auswahl des Kopfes, Bildgröße, Genauigkeit und Hardware.

Häufig gestellte Fragen#