Modellexport mit Ultralytics YOLO#

Mit Ultralytics lässt sich ein YOLO26-Modell unkompliziert ins ONNX-Format exportieren. Dafür stehen sowohl Python- als auch CLI-Verfahren zur Verfügung.

from ultralytics import YOLO

# Ein Modell laden
model = YOLO("yolo26n.pt")  # Ein offizielles Modell laden
model = YOLO("path/to/best.pt")  # Ein benutzerdefiniert trainiertes Modell laden

# Modell exportieren
model.export(format="onnx")

Weitere Informationen zum Ablauf, einschließlich erweiterter Optionen wie dem Umgang mit unterschiedlichen Eingabegrößen, findest du in der ONNX-Integrationsanleitung.

Der Export von Modellen mit TensorRT bringt deutliche Leistungsverbesserungen. Mit TensorRT exportierte YOLO26-Modelle können eine bis zu fünffache GPU-Beschleunigung erreichen und eignen sich daher ideal für Echtzeit-Inferenzanwendungen.

• Vielseitigkeit: Optimiere Modelle für eine bestimmte Hardwarekonfiguration.
• Geschwindigkeit: Erziele durch fortschrittliche Optimierungen eine schnellere Inferenz.
• Kompatibilität: Integriere Modelle nahtlos in NVIDIA-Hardware.

Weitere Informationen zur Integration von TensorRT findest du in der TensorRT-Integrationsanleitung.

Die INT8-Quantisierung ist eine hervorragende Möglichkeit, das Modell zu komprimieren und die Inferenz zu beschleunigen, insbesondere auf Edge-Geräten. So aktivierst du die INT8-Quantisierung:

from ultralytics import YOLO

model = YOLO("yolo26n.pt")  # Ein Modell laden
model.export(format="onnx", quantize=8, data="coco8.yaml")

Die INT8-Quantisierung kann auf Formate wie ONNX, TensorRT, OpenVINO, CoreML, Rockchip RKNN und AMD Xilinx angewendet werden. Für optimale Quantisierungsergebnisse gib über den Parameter data einen repräsentativen Datensatz an. Unter Quantisierungsoptionen findest du die akzeptierten Werte für quantize und die unterstützten Formate.

Eine dynamische Eingabegröße ermöglicht dem exportierten Modell, Bilder mit unterschiedlichen Abmessungen zu verarbeiten. Das sorgt für Flexibilität und eine effiziente Verarbeitung in verschiedenen Anwendungsfällen. Wenn du in Formate wie ONNX oder TensorRT exportierst, kann sich das Modell mit aktivierter dynamischer Eingabegröße nahtlos an unterschiedliche Eingabeformen anpassen.

Aktiviere diese Funktion beim Export mit dem Flag dynamic=True:

from ultralytics import YOLO

model = YOLO("yolo26n.pt")
model.export(format="onnx", dynamic=True)

Eine dynamische Eingabegröße ist besonders nützlich für Anwendungen, bei denen die Eingabeabmessungen variieren können, beispielsweise bei der Videoverarbeitung oder bei der Verarbeitung von Bildern aus verschiedenen Quellen.

PyTorch-Modelle und dynamische Exporte verwenden standardmäßig Padding auf das kleinste Rechteck, während statische Exporte auf die vollständige Größe imgsz auffüllen. Dadurch können sich Erkennungen nahe dem Konfidenzschwellwert unterscheiden. Verwende rect=False für die native Inferenz, um Ergebnisse wie bei einem statischen Export zu erhalten, oder exportiere mit dynamic=True, sofern unterstützt.

Für die Optimierung der Modellleistung ist es entscheidend, die Exportargumente zu verstehen und richtig zu konfigurieren:

• format: Zielformat des exportierten Modells (z. B. onnx, torchscript, saved_model).
• imgsz: Gewünschte Bildgröße für die Modelleingabe (z. B. 640 oder (height, width)).
• quantize: Quantisierungsgenauigkeit, z. B. 8/"int8", 16/"fp16", 32/"fp32" oder die unterstützten Verfahren mit gemischter Gewichts-/Aktivierungsgenauigkeit "w8a16" und "w8a32" (dynamisches INT8 bei LiteRT). Weitere Informationen findest du unter Quantisierungsoptionen.
• dynamic: Akzeptiert variable Eingabegrößen bei Formaten, die dynamische Formen unterstützen, etwa ONNX, OpenVINO und TensorRT.
• nms: Wählt Roh-Ausgaben für externe NMS (None), integrierte NMS (True) oder den NMS-freien Head (False) aus.
• device: Gerät, auf dem das Modell während des Exports nachverfolgt wird, z. B. cpu oder 0 für die erste CUDA-GPU; FP16-TorchScript erfordert eine GPU.

Für die Bereitstellung auf bestimmten Hardwareplattformen solltest du spezialisierte Exportformate verwenden, etwa TensorRT für NVIDIA-GPUs, CoreML für Apple-Geräte oder Edge TPU für Google-Coral-Geräte.

Wenn du ein YOLO-Modell in Formate wie ONNX oder TensorRT exportierst, hängt die Struktur des Ausgabetensors von der Modellaufgabe ab. Für eigene Inferenzimplementierungen ist es wichtig, diese Ausgaben zu verstehen.

Für YOLO26-Erkennungsmodelle (z. B. yolo26n.pt), die mit nms=False exportiert werden, erzeugen unterstützte Formate eine NMS-freie Ausgabe mit der Form (batch_size, max_detections, 6) und [x1, y1, x2, y2, confidence, class_id] Werten. Bei der Standardeinstellung max_det=300 ist dies üblicherweise (batch_size, 300, 6). Einige Formate mit Einschränkungen greifen automatisch auf das herkömmliche Ausgabelayout zurück, wenn Operatoren für die End-to-End-Verarbeitung nicht unterstützt werden.

Standardmäßig (nms=None) exportieren Erkennungsmodelle, einschließlich YOLO26, rohe One-to-many-Vorhersagen: Die Ausgabe ist üblicherweise ein einzelner Tensor mit der Form (batch_size, 4 + num_classes, num_predictions), dessen Kanäle die Boxkoordinaten und die Bewertungen pro Klasse darstellen. num_predictions hängt von der Eingabeauflösung beim Export ab und kann dynamisch sein. Im Leitfaden zur End-to-End-Erkennung erfährst du, welche Formate die End-to-End-Ausgabe beibehalten.

Bei Segmentierungsmodellen (z. B. yolo26n-seg.pt) erhältst du üblicherweise zwei Ausgaben: Der erste Tensor hat die Form (batch_size, 4 + num_classes + mask_dim, num_predictions) (Boxen, Klassenbewertungen und Maskenkoeffizienten), der zweite Tensor hat die Form (batch_size, mask_dim, proto_h, proto_w) und enthält Maskenprototypen, die zusammen mit den Koeffizienten zur Erzeugung von Instanzmasken verwendet werden. Die Größen hängen von der Eingabeauflösung beim Export ab und können dynamisch sein.

Bei Posenmodellen (z. B. yolo26n-pose.pt) hat der Ausgabetensor üblicherweise die Form (batch_size, 4 + num_classes + keypoint_dims, num_predictions). keypoint_dims hängt von der Posenspezifikation ab (z. B. von der Anzahl der Schlüsselpunkte und davon, ob Konfidenzwerte enthalten sind), während num_predictions von der Eingabeauflösung beim Export abhängt und dynamisch sein kann.

Die Beispiele in den ONNX-Inferenzbeispielen veranschaulichen, wie du diese Ausgaben für jeden Modelltyp verarbeiten kannst.

Ultralytics bietet derzeit keine dedizierte C++-Inferenz-API für YOLO-Modelle an. Für C++-Bereitstellungen exportierst du das Modell in ein Laufzeitformat wie ONNX, TensorRT, TorchScript oder MNN und lädst das exportierte Artefakt anschließend mit der nativen C++-API dieser Laufzeitumgebung.

Exportiere beispielsweise ein Erkennungsmodell mit yolo export model=yolo26n.pt format=onnx und führe die Datei .onnx mit ONNX Runtime C++ aus. Oder exportiere es mit format=engine und führe die TensorRT-Engine in einer TensorRT-C++-Anwendung aus. Wenn du eine eigene C++-Nachverarbeitung verwendest, muss das Layout des Ausgabetensors zu deiner Aufgabe und den Exporteinstellungen passen. Standardmäßige YOLO26-Erkennungsexporte liefern rohe Vorhersagetensoren, für die eine externe NMS erforderlich ist. Exportiere mit nms=False, um NMS-freie Erkennungen mit der Form (batch, max_det, 6) zu erhalten, oder mit nms=True, um NMS in unterstützte Formate einzubetten.

Beim Export mit quantize=16 (FP16) oder quantize=8 (INT8) werden die meisten Tensoren in eine niedrigere Genauigkeit umgewandelt, um die Modellgröße zu reduzieren und die Leistung zu verbessern. Ist jedoch nms=False aktiviert, wird die Nachverarbeitung (einschließlich der Klassenindizes) direkt in den exportierten Graphen eingebettet.

Der Tensor output0 enthält Klassenindizes, die intern als Gleitkommazahlen dargestellt werden. Aufgrund der begrenzten Mantissenpräzision kann FP16 ganzzahlige Werte über 2048 nicht zuverlässig darstellen. Um möglichen Präzisionsverlust oder falsche Klassen-IDs zu vermeiden, bleibt output0 absichtlich im FP32-Format.

Wenn du vollständige FP16-Ausgaben benötigst, exportiere mit nms=None auf einer GPU und führe die Nachverarbeitung extern durch. FP16-ONNX-Exporte auf der CPU behalten unabhängig davon FP32-Eingaben und -Ausgaben bei; nur der interne Graph wird umgewandelt.