Exportation de modèles avec Ultralytics YOLO#

Avec Ultralytics, l’exportation d’un modèle YOLO26 au format ONNX est simple. Tu peux exporter les modèles avec Python ou la CLI.

from ultralytics import YOLO

# Charger un modèle
model = YOLO("yolo26n.pt")  # charger un modèle officiel
model = YOLO("path/to/best.pt")  # charger un modèle entraîné personnalisé

# Exporter le modèle
model.export(format="onnx")

Pour en savoir plus sur le processus, notamment sur les options avancées comme la gestion de différentes tailles d’entrée, consulte le guide d’intégration ONNX.

L’utilisation de TensorRT pour l’exportation de modèles améliore considérablement les performances. Les modèles YOLO26 exportés vers TensorRT peuvent atteindre une accélération GPU jusqu’à 5 fois supérieure, ce qui en fait une solution idéale pour les applications d’inférence en temps réel.

• Polyvalence : optimise les modèles pour une configuration matérielle précise.
• Vitesse : accélère l’inférence grâce à des optimisations avancées.
• Compatibilité : s’intègre facilement au matériel NVIDIA.

Pour en savoir plus sur l’intégration de TensorRT, consulte le guide d’intégration TensorRT.

La quantification INT8 est un excellent moyen de compresser le modèle et d’accélérer l’inférence, en particulier sur les appareils périphériques. Voici comment activer la quantification INT8 :

from ultralytics import YOLO

model = YOLO("yolo26n.pt")  # Charger un modèle
model.export(format="onnx", quantize=8, data="coco8.yaml")

La quantification INT8 peut être appliquée à des formats comme ONNX, TensorRT, OpenVINO, CoreML, Rockchip RKNN et AMD Xilinx. Pour obtenir des résultats de quantification optimaux, fournis un jeu de données représentatif avec le paramètre data. Consulte les options de quantification pour connaître les valeurs quantize acceptées et les formats pris en charge.

La taille d’entrée dynamique permet au modèle exporté de traiter des images de dimensions variables, ce qui offre de la flexibilité et optimise l’efficacité du traitement selon les cas d’utilisation. Lors d’une exportation vers des formats comme ONNX ou TensorRT, l’activation de la taille d’entrée dynamique permet au modèle de s’adapter facilement à différentes formes d’entrée.

Pour activer cette fonctionnalité, utilise l’indicateur dynamic=True lors de l’exportation :

from ultralytics import YOLO

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

La taille d’entrée dynamique est particulièrement utile pour les applications où les dimensions d’entrée peuvent varier, comme le traitement vidéo ou l’analyse d’images provenant de différentes sources.

Par défaut, les modèles PyTorch et les exportations dynamiques utilisent le rembourrage en rectangle minimal, tandis que les exportations statiques ajoutent du rembourrage jusqu’à atteindre le imgsz complet ; les détections proches du seuil de confiance peuvent donc différer. Utilise rect=False pour effectuer l’inférence native et obtenir des résultats similaires à une exportation statique, ou exporte avec dynamic=True lorsque cette option est prise en charge.

Comprendre et configurer les arguments d’exportation est essentiel pour optimiser les performances d’un modèle :

• format: Format cible du modèle exporté (par exemple, onnx, torchscript, saved_model).
• imgsz: Taille d’image souhaitée pour l’entrée du modèle (par exemple, 640 ou (height, width)).
• quantize: Précision de quantification, par exemple 8/"int8", 16/"fp16", 32/"fp32", ou les modes mixtes poids/activations "w8a16" et "w8a32" (INT8 dynamique LiteRT) pour les formats pris en charge. Consulte les options de quantification.
• dynamic: Accepte des tailles d’entrée variables dans les formats prenant en charge les formes dynamiques, comme ONNX, OpenVINO et TensorRT.
• nms: Sélectionne les sorties brutes pour une NMS externe (None), une NMS intégrée (True) ou une tête sans NMS (False).
• device: Appareil utilisé pour tracer le modèle pendant l’exportation, par exemple cpu ou 0 pour le premier GPU CUDA ; TorchScript FP16 nécessite un GPU.

Pour un déploiement sur des plateformes matérielles spécifiques, pense à utiliser des formats d’exportation spécialisés comme TensorRT pour les GPU NVIDIA, CoreML pour les appareils Apple ou Edge TPU pour les appareils Google Coral.

Lorsque tu exportes un modèle YOLO vers des formats comme ONNX ou TensorRT, la structure du tenseur de sortie dépend de la tâche du modèle. Il est important de comprendre ces sorties pour implémenter des inférences personnalisées.

Pour les modèles de détection YOLO26 (p. ex. yolo26n.pt) exportés avec nms=False, les formats pris en charge produisent une sortie sans NMS de forme (batch_size, max_detections, 6) avec [x1, y1, x2, y2, confidence, class_id] valeurs. Avec le max_det=300 par défaut, cette sortie est généralement (batch_size, 300, 6). Certains formats soumis à des contraintes reviennent automatiquement à la disposition de sortie traditionnelle lorsque les opérateurs de bout en bout ne sont pas pris en charge.

Par défaut (nms=None), les modèles de détection, notamment YOLO26, exportent des prédictions brutes un-vers-plusieurs : la sortie est généralement un seul tenseur de forme (batch_size, 4 + num_classes, num_predictions), dont les canaux représentent les coordonnées des boîtes et les scores par classe, et num_predictions dépend de la résolution d'entrée de l'exportation (et peut être dynamique). Le guide de la détection de bout en bout indique quels formats conservent la sortie de bout en bout.

Pour les modèles de segmentation (p. ex. yolo26n-seg.pt), tu obtiendras généralement deux sorties : le premier tenseur, de forme (batch_size, 4 + num_classes + mask_dim, num_predictions) (boîtes, scores par classe et coefficients de masque), et le second tenseur, de forme (batch_size, mask_dim, proto_h, proto_w), qui contient les prototypes de masque utilisés avec les coefficients pour générer les masques d'instance. Les tailles dépendent de la résolution d'entrée de l'exportation (et peuvent être dynamiques).

Pour les modèles de pose (p. ex. yolo26n-pose.pt), le tenseur de sortie a généralement la forme (batch_size, 4 + num_classes + keypoint_dims, num_predictions), où keypoint_dims dépend de la spécification de pose (p. ex. du nombre de points clés et de l'inclusion ou non de la confiance), et num_predictions dépend de la résolution d'entrée de l'exportation (et peut être dynamique).

Les exemples de la page Exemples d'inférence ONNX montrent comment traiter ces sorties pour chaque type de modèle.

Ultralytics ne fournit actuellement pas d'API d'inférence C++ dédiée aux modèles YOLO. Pour les déploiements en C++, exporte le modèle vers un format d'exécution comme ONNX, TensorRT, TorchScript ou MNN, puis charge l'artefact exporté avec l'API C++ native de ce moteur d'exécution.

Par exemple, exporte un modèle de détection avec yolo export model=yolo26n.pt format=onnx et exécute le fichier .onnx avec ONNX Runtime C++, ou exporte avec format=engine et exécute le moteur TensorRT depuis une application C++ TensorRT. Lorsque tu utilises un post-traitement C++ personnalisé, veille à ce que la disposition du tenseur de sortie corresponde à la tâche et aux paramètres d'exportation ; les exportations de détection YOLO26 par défaut renvoient des tenseurs de prédiction bruts qui nécessitent une NMS externe. Exporte avec nms=False pour obtenir des détections sans NMS de forme (batch, max_det, 6), ou avec nms=True pour intégrer la NMS dans les formats pris en charge.

Lors d'une exportation avec quantize=16 (FP16) ou quantize=8 (INT8), la plupart des tenseurs sont convertis en précision réduite afin de diminuer la taille du modèle et d'améliorer ses performances. Toutefois, lorsque nms=False est activé, le post-traitement (y compris les indices de classe) est intégré directement au graphe exporté.

Le tenseur output0 contient les indices de classe, qui sont représentés en interne sous forme de nombres à virgule flottante. En raison de la précision limitée de sa mantisse, FP16 ne peut pas représenter de manière fiable les valeurs entières supérieures à 2048. Pour éviter une éventuelle perte de précision ou des ID de classe incorrects, output0 est volontairement conservé en FP32.

Si tu as besoin de sorties entièrement en FP16, exporte avec nms=None sur un GPU et effectue le post-traitement à l'extérieur. Les exportations ONNX FP16 sur CPU conservent dans tous les cas des entrées et des sorties FP32 ; seule la représentation interne du graphe est convertie.