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

YOLO26 trainiert sowohl einen One-to-Many-Head als auch einen One-to-One-Head. Für Vorhersage und Validierung wird standardmäßig der One-to-Many-Head mit Non-Maximum Suppression (NMS) verwendet. Dies begünstigt die Genauigkeit bei denselben trainierten Gewichten. Setze nms=False, um stattdessen den schnelleren, NMS-freien One-to-One-Head zu verwenden.

Ein Argument steuert die Auswahl über Vorhersage, Validierung, Tracking, Export und Benchmarking hinweg:

None bedeutet, dass keine optionale Nachbearbeitung in das Modell eingebettet ist. Die normale Verarbeitung, die Modellausgaben in Vorhersageergebnisse oder Validierungsmetriken umwandelt, wird dabei nicht entfernt. Klassifizierung, semantische Segmentierung, Tiefe und Modelle ohne auswählbare Detektions-Heads behalten das native Verhalten ihrer Aufgabe bei.

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)  # opt into NMS-free inference
results = model.predict("image.jpg", nms=None)  # switch back to one-to-many + NMS

model.export(format="onnx")  # raw one-to-many outputs
model.export(format="onnx", nms=True)  # embed NMS
model.export(format="onnx", nms=False)  # NMS-free one-to-one outputs

So funktioniert die End-to-End-Erkennung#

Beide Heads teilen sich Backbone und Neck und werden während des Trainings optimiert. Der One-to-Many-Head liefert mehrere Kandidatenvorhersagen pro Objekt; NMS entfernt überlappende Detektionen. Der One-to-One-Head lernt, eine einzelne Vorhersage pro Objekt zu erzeugen. Die Auswahl des Inferenzpfads deaktiviert die Überwachung mit zwei Heads nicht. Die Validierung während des Trainings verwendet den ausgewählten Inferenz-Head, sodass Checkpoint-Auswahl und Early Stopping denselben Vorhersagen wie das Deployment folgen.

Hier ist N die Batch-Größe, nc die Anzahl der Klassen und 8400 die Anzahl der Kandidaten bei imgsz=640. Die One-to-One-Detektionszeilen enthalten [x1, y1, x2, y2, confidence, class_id]. Andere Detektionsaufgaben enthalten zusätzliche Ausgaben:

Durch Fusion werden nicht verwendete Inferenz-Branches entfernt sowie Conv- und BatchNorm-Schichten gefaltet. Behalte den ursprünglichen Trainings-Checkpoint bei, wenn du Heads wechseln musst: Durch Fusion kann ein bereits entfernter Branch nicht wiederhergestellt werden. Ein Modell, bei dem nur noch der One-to-One-Head verbleibt, behält diesen verfügbaren Pfad bei.

Exportierte Ausgaben#

Detektionsmodelle von YOLOv8, YOLO11 und YOLO26 exportieren standardmäßig rohe One-to-Many-Vorhersagen. Exportiere YOLO26 mit nms=False für NMS-freie Detektionen.

nms=True erzeugt ebenfalls verarbeitete Detektionen, verwendet jedoch den One-to-Many-Head und bettet herkömmliches NMS ein. Dies ist nützlich, wenn deine Deployment-Laufzeit Detektionen empfangen soll, ohne die Unterdrückung selbst implementieren zu müssen.

Der Graph eines exportierten Modells bestimmt dessen Ausgaben. Die Übergabe von nms beim Laden baut den Graphen nicht neu auf; exportiere den Quell-Checkpoint mit dem gewünschten nms-Wert, um seinen Ausgabepfad auszuwählen. Ultralytics verwendet die Metadaten des Artefakts, um zu vermeiden, dass NMS zweimal angewendet wird.

Kompatibilität der Exportformate#

ONNX, TensorRT, CoreML, OpenVINO und einige andere Formate unterstützen NMS-freie Exporte. NCNN, RKNN, PaddlePaddle, ExecuTorch, IMX, Edge TPU und Qualcomm QNN greifen auf den One-to-Many-Pfad zurück, wenn ihre Operatoren keine End-to-End-Ausgabe unterstützen. Formatwarnungen erläutern den Fallback.

• Eingebettetes NMS: nms=True unterliegt den Aufgaben-, Präzisions- und Dynamic-Shape-Beschränkungen des jeweiligen Formats. Formate ohne Unterstützung für eingebettetes NMS exportieren native Ausgaben für die externe Verarbeitung.
• CoreML: Das eingebettete NMS unterstützt Detect, Segment und Pose mit statischen Shapes. Verwende nms=True für Detektionsmodelle, die die NMS-Pipeline der Xcode Preview benötigen.
• MNN: Das eingebettete NMS unterstützt Detect und Pose mit dynamic=False.
• IMX: Detektion, Instanzsegmentierung und Pose erfordern eingebettetes NMS, das automatisch ausgewählt wird.
• Hailo: YOLO26 verwendet standardmäßig rohe Tensoren mit Host-NMS; nms=False wählt dessen One-to-One-Pfad aus. YOLOv8/YOLO11-Detektion verwendet HailoRT-NMS.
• Quantisierung: TensorRT-Versionen vor 8.5.0, TensorRT 10.3.0 INT8 auf JetPack 6 sowie LiteRT INT8 oder w8a16 greifen auf One-to-Many-Ausgaben zurück.

Siehe die einzelnen Integrationsanleitungen für Hardwareanforderungen. Für vollständige FP16-Ausgabetensoren verwendest du nms=None; End-to-End-Klassenindizes können Ausgabetensoren in FP32 halten, selbst wenn das Modell quantisiert ist.

Kompromisse zwischen Genauigkeit und Geschwindigkeit#

Die veröffentlichten YOLO26-COCO-Ergebnisse zeigen, dass der One-to-Many-Head die Detektions-mAP über die fünf Skalierungen hinweg um 0,6–0,8 Punkte verbessert: zum Beispiel 40,9 gegenüber 40,1 für YOLO26n und 57,5 gegenüber 56,9 für YOLO26x. Der One-to-One-Head vermeidet den NMS-Durchlauf und begünstigt die Latenz. Diese Ergebnisse begründen den Standard; sie garantieren keinen Gewinn auf jedem Datensatz.

Veröffentlichte NMS-freie Messungen der Geschwindigkeit verwenden nms=False. Vergleiche Genauigkeit und Latenz unter Verwendung derselben Head-Auswahl, Bildgröße, Präzision und Hardware.

FAQ#