Exportation de modèles avec Ultralytics YOLO#

Introduction#

L'objectif ultime de l'entraînement d'un modèle est de le déployer pour des applications concrètes. Le mode d'exportation d'Ultralytics YOLO26 offre une gamme polyvalente d'options pour exporter ton modèle entraîné vers différents formats, ce qui le rend déployable sur de multiples plateformes et appareils. Ce guide complet a pour but de t'accompagner à travers les nuances de l'exportation de modèles, en montrant comment atteindre une compatibilité et des performances maximales.

Consulte l'aperçu non publié de YOLO27 pour connaître la prise en charge des exportations prévues.

Pourquoi choisir le mode d'exportation de YOLO26 ?#

• Polyvalence : Exporte vers de multiples formats, y compris ONNX, TensorRT, CoreML, et bien d'autres.
• Performance : Obtiens jusqu'à 5 fois d'accélération GPU avec TensorRT et 3 fois d'accélération CPU avec ONNX ou OpenVINO.
• Compatibilité : Rends ton modèle universellement déployable sur de nombreux environnements matériels et logiciels.
• Simplicité d'utilisation : Une interface en ligne de commande et une API Python simples pour une exportation de modèle rapide et directe.

Fonctionnalités clés du mode d'exportation#

Voici quelques-unes des fonctionnalités phares :

• Exportation en un clic : Des commandes simples pour exporter vers différents formats.
• Exportation par lots : Exporte des modèles capables d'effectuer des inférences par lots.
• Inférence optimisée : Les modèles exportés sont optimisés pour des temps d'inférence plus rapides.
• Tutoriels vidéo : Des guides approfondis et des tutoriels pour une expérience d'exportation fluide.

Exemples d’utilisation#

Exporte un modèle YOLO26n vers un format différent tel que ONNX ou TensorRT. Consulte la section des arguments ci-dessous pour obtenir la liste complète des arguments d'exportation.

from ultralytics import YOLO

# Load a model
model = YOLO("yolo26n.pt")  # load an official model
model = YOLO("path/to/best.pt")  # load a custom-trained model

# Export the model
model.export(format="onnx")

Arguments#

Ce tableau détaille les configurations et options disponibles pour exporter des modèles YOLO vers différents formats. Ces paramètres sont essentiels pour optimiser les performances, la taille et la compatibilité du modèle exporté sur diverses plateformes et environnements. Une configuration correcte garantit que le modèle est prêt pour le déploiement dans l'application visée avec une efficacité optimale.

L'ajustement de ces paramètres permet de personnaliser le processus d'exportation pour répondre à des exigences spécifiques, telles que l'environnement de déploiement, les contraintes matérielles et les objectifs de performance. La sélection du format et des paramètres appropriés est essentielle pour obtenir le meilleur équilibre entre la taille du modèle, sa vitesse et son précision.

Formats d'exportation#

Les formats d'exportation disponibles pour YOLO26 sont présentés dans le tableau ci-dessous. Tu peux exporter vers n'importe quel format en utilisant l'argument format, c'est-à-dire format='onnx' ou format='engine'. Tu peux effectuer des prédictions ou des validations directement sur les modèles exportés, c'est-à-dire yolo predict model=yolo26n.onnx. Des exemples d'utilisation sont affichés pour ton modèle une fois l'exportation terminée. Les modèles peuvent également être exportés directement depuis le navigateur sur Ultralytics Platform sans aucune configuration locale.

nms=None utilise par défaut des sorties brutes pour NMS externe. Définis nms=False pour sélectionner une tête sans NMS disponible ; les formats non pris en charge reviennent à leur chemin de sortie natif. Les entrées nms ci-dessus identifient les formats capables d'intégrer NMS avec nms=True.

Options de quantification#

Utilise l'argument quantize pour demander la précision de l'exportation. Les valeurs textuelles ne sont pas sensibles à la casse, et Ultralytics normalise les alias acceptés avant l'exportation :

Les anciens indicateurs half=True et int8=True sont toujours acceptés avec des avertissements de dépréciation et sont redirigés vers quantize=16 et quantize=8.

Tous les formats d'exportation ne prennent pas en charge toutes les précisions. Les requêtes explicites quantize produisent soit cette précision, soit un échec avant l'exportation :

Pour les exportations INT8 et W8A16, fournis des données de calibration représentatives avec data, telles que data="coco8.yaml", sauf si l'intégration cible documente un comportement par défaut ou activé automatiquement. Le schéma "w8a32" de LiteRT (INT8 dynamique) ne nécessite aucune donnée de calibration.

Entraînement conscient de la quantification#

Les exportations INT8 ci-dessus relèvent de la quantification post-entraînement (PTQ) : les plages sont observées lors d'un unique passage de calibration sur data. L'entraînement conscient de la quantification (QAT) apprend plutôt des poids qui tolèrent l'INT8 en affinant avec une fausse quantification dans la boucle, ce que la seule calibration perd et que cela permet de récupérer. Passe quantize=8 à train pour affiner un point de contrôle pré-entraîné, puis exporte-le comme d'habitude :

from ultralytics import YOLO

model = YOLO("yolo26n.pt")
model.train(
    data="coco.yaml",
    quantize=8,
    epochs=5,
    batch=64,
    optimizer="AdamW",
    lr0=0.00001,
    lrf=0.1,
    warmup_epochs=0.5,
    cos_lr=True,
    mosaic=0.0,
)
model.export(format="engine", quantize=8)  # ranges travel with the checkpoint, no calibration data needed

Utilise un petit taux d'apprentissage lors de l'affinage d'un point de contrôle pré-entraîné. L'entraînement conscient de la quantification peut initialement réduire la précision, et son avantage par rapport à la quantification post-entraînement dépend du modèle, de l'ensemble de données et du budget d'entraînement. Valide le modèle exporté par rapport au point de contrôle d'origine et à une exportation quantifiée post-entraînement ; les scores de fausse quantification pendant l'entraînement n'établissent pas la précision du déploiement.

L'intérêt de QAT dépend de la façon dont la propre calibration du moteur d'exportation gère le modèle. Les valeurs ci-dessous sont le mAP50-95 sur COCO val2017, mesurées avec des moteurs TensorRT 10.16 à imgsz=640 et un lot de 1, où chaque point de contrôle QAT a été entraîné avec epochs=20 patience=3 :

QAT coûte de 0.008 à 0.017 en mAP50-95 par rapport au FP32 sur toute la gamme, tandis que la quantification post-entraînement coûte 0.010 sur yolo26n et de 0.038 à 0.057 sur les modèles plus grands. Ainsi, QAT n'apporte presque rien sur le plus petit modèle, où la calibration fonctionne déjà bien, et de 0.030 à 0.044 sur le reste. Attends-toi à des chiffres différents sur un autre jeu de données, un autre format d'exportation ou une autre version de TensorRT, et mesure tes propres résultats.

Les modèles d'entraînement conscient de la quantification nécessitent compile=False ; les modules quantifiés de ModelOpt ne prennent pas en charge torch.compile.

La tête de sortie est délibérément laissée en float pour limiter la perte de précision INT8 ; TensorRT active la précision mixte FP16 pour ses couches non quantifiées. La QAT s'exécute via NVIDIA TensorRT Model Optimizer, installé automatiquement lors de la première utilisation, et le point de contrôle résultant nécessite son installation pour être chargé. Ces plages voyagent avec le point de contrôle et les exportations onnx et engine les émettent sous forme de nœuds Q/DQ ; d'autres formats lisent la calibration à la place et rejetteront un point de contrôle QAT.

Et ensuite ?#

Trouve le guide d'intégration de ta cible de déploiement — ONNX, TensorRT, CoreML, et bien d'autres se trouvent sur la liste complète des intégrations — pour savoir comment exécuter le modèle exporté.

FAQ#