Ultralytics YOLO27 :

Export CVflow Ambarella pour les modèles Ultralytics YOLO#

Le déploiement de modèles Ultralytics YOLO sur les SoC Ambarella nécessite leur compilation à l’aide des outils de compilation d’Ambarella. Les modèles optimisés pour l’architecture CVflow offrent de meilleures performances à l’inférence. Ce fork d’Ultralytics intègre directement la boîte à outils de compression SpongeTorch d’Ambarella au pipeline d’entraînement, de validation et d’export, ce qui permet aux développeurs de générer des modèles optimisés pour un déploiement efficace sur du matériel Ambarella.

Ce guide présente le workflow actuel de déploiement de la détection d’objets, de l’entraînement tenant compte de la compression à l’inférence sur l’appareil (consulte la vue d’ensemble du workflow pour découvrir le pipeline complet).

Le format de point de contrôle AmbaPB est une extension spécifique à Ambarella de la spécification ONNX IR. Il prend en charge les primitives de calcul CVflow et regroupe les artefacts générés par les outils du SDK. Il s’agit de l’artefact côté hôte utilisé pour valider la précision du modèle compilé avant son déploiement ; le binaire Cavalry distinct, produit pour l’appareil cible, est celui qui s’exécute sur la carte.

Remarque

Ce workflow dépend de composants propriétaires du SDK Ambarella qui ne sont pas disponibles sur PyPI. Pour obtenir les packages du SDK requis, inscris-toi sur l’Ambarella Developer Zone et demande l’accès via la plateforme Cooper™ Developer Platform.

Assistance

Cette intégration est maintenue par Ambarella. Signale les problèmes liés au fork, à SpongeTorch ou au SDK à l’assistance Ambarella.

Qui est Ambarella ?#

Ambarella, dont le siège social se trouve à Santa Clara, en Californie, est une entreprise de semi-conducteurs qui conçoit des SoC d’IA en périphérie. Ses processeurs combinent le traitement du signal d’image, l’encodage vidéo et le calcul d’IA sur puce. Ils sont utilisés dans les appareils de sécurité, automobiles, robotiques, industriels et grand public.

Qu’est-ce que CVflow ?#

CVflow est l’architecture de traitement de la vision d’Ambarella. Elle utilise un moteur de vision dédié, distinct du CPU et du GPU, pour exécuter des charges de travail de vision par ordinateur et de réseaux neuronaux. Les modèles entraînés avec des frameworks comme PyTorch sont compilés au format natif de CVflow à l’aide du SDK Ambarella avant leur exécution sur le moteur.

Familles actuelles de SoC CVflow et leurs applications types :

Famille de SoCApplications types
CV72 / CV75Caméras de sécurité 4K avec IA, caméras intelligentes, vision industrielle
CV5 / CV52Drones, caméras d’action, robotique, systèmes multicaméras
N1-655Appareils d’IA générative sur site et d’analyse vidéo mult flux

Pourquoi déployer YOLO sur Ambarella ?#

  • Performances par watt : les SoC CVflow sont conçus pour l’IA en périphérie toujours active, avec une détection d’objets en temps réel dans les limites de consommation des caméras.
  • Entraînement tenant compte de la compression : SpongeTorch applique l’élagage pendant l’entraînement pour aider le modèle à conserver sa précision tout en devenant plus parcimonieux et plus efficace pour le déploiement sur CVflow.
  • Pipeline caméra intégré : les SoC Ambarella combinent un processeur de signal d’image (ISP), l’encodage vidéo ultra-HD et CVflow pour permettre différents systèmes de caméras à faible consommation. Un seul SoC Ambarella gère ainsi l’ensemble du pipeline de caméra IA.

Vue d’ensemble du workflow#

Le pipeline comprend six étapes :

  1. Entraînement tenant compte de la compression — entraîne le modèle avec une configuration SpongeKit (amba_config) afin que SpongeTorch applique progressivement l’élagage non structuré pendant l’entraînement. Lorsque la précision obtenue par quantification après entraînement (PTQ) n’est pas acceptable, SpongeTorch prend également en charge l’entraînement tenant compte de la quantification (QAT), mais cette méthode n’est pas encore intégrée à cette intégration Ultralytics et est prévue dans une prochaine version.
  2. Export ONNX — exporte le point de contrôle compressé avec le même amba_config afin de préserver la structure de compression dans le graphe ONNX.
  3. Compilation — compile le modèle ONNX en point de contrôle AmbaPB à l’aide des outils de compilation du SDK, qui appliquent la PTQ pour le moteur CVflow.
  4. Validation sur l’hôte — exécute le modèle compilé *.ambapb.ckpt.onnx via Ultralytics predict/val au moyen du backend AmbaPB afin de vérifier sa précision avant le déploiement.
  5. Conversion Cavalry — convertis le point de contrôle AmbaPB validé en binaire Cavalry à l’aide des outils du SDK.
  6. Exécution sur l’appareil — exécute le binaire Cavalry sur l’appareil avec la bibliothèque d’exécution du SDK Ambarella.

Le workflow d’entraînement et d’export SpongeTorch est facultatif et peut être remplacé par un simple export ONNX (consulte Exporter sans SpongeTorch).

Prérequis#

Installation#

Installe ce fork d’Ultralytics, puis configure le SDK Ambarella CVflow — qui comprend les outils de compilation et la bibliothèque cvflowbackend — et installe le wheel spongetorch distribué avec celui-ci :

Installation
# Install this Ultralytics fork from source
git clone https://github.com/Ambarella-Inc/ultralytics
cd ultralytics
git checkout amba_v8.4.46
pip install -e .

# Access and set up the Ambarella SDK compilation tools
# After the environment is ready, install the spongetorch library
pip install /path/to/spongetorch-*.whl

AutoBackend localise cvflowbackend via la commande tv2 (tv2 -libpath cvflowbackend) des outils de compilation du SDK. Ces outils doivent donc être installés et figurer dans ton PATH avant toute inférence ou validation avec des modèles compilés.

Fichier de configuration SpongeKit#

SpongeTorch est piloté par un fichier de configuration SpongeKit (format protobuf-text, .prototxt) qui définit les passes d’élagage, notamment les objectifs de parcimonie et le calendrier de compression. Récupère les exemples de configuration et la documentation du schéma correspondant dans la version de ton SDK Ambarella. Pour assurer la cohérence entre l’entraînement, la validation et le déploiement, utilise la configuration d’entraînement chaque fois que la validation doit préparer à nouveau le modèle, et utilise toujours cette même configuration pour exporter un point de contrôle compressé.

Arguments Amba#

Deux arguments contrôlent l’intégration SpongeTorch dans les modes train, val et export :

ArgumentTypeValeur par défautDescription
amba_configstrNoneChemin vers la configuration SpongeKit transmise à spongetorch.prepare(). Active l’entraînement tenant compte de la compression et l’export compatible avec SpongeTorch.
amba_chipsetstrNoneNom du chipset cible transmis à spongetorch.set_target_chipset(), par exemple CV72.

Le fork ajoute également un argument d’export général :

ArgumentTypeValeur par défautDescription
export_filestrNoneChemin/nom personnalisé du fichier d’export, par exemple '/tmp/model.onnx' ou 'model.onnx'.

Entraînement tenant compte de la compression#

Entraîne (ou affine) ton modèle avec la compression SpongeTorch activée :

Utilisation
from ultralytics import YOLO

model = YOLO("yolo26n.pt")
model.train(
    data="coco8.yaml",
    epochs=100,
    amba_config="config.prototxt",
    amba_chipset="CV72",
)

Lorsque amba_config est défini, l’entraîneur enveloppe le modèle et l’optimiseur avec spongetorch.prepare() lors de la configuration. La compression est appliquée progressivement selon un calendrier d’étapes, afin que le réseau apprenne à conserver sa précision tout en devenant parcimonieux. Le point de contrôle entraîné stocke l’état parcimonieux de SpongeTorch (tenseurs _orig/_mask), nécessaire à l’étape d’export ultérieure. Le fichier de configuration est copié dans le répertoire d’exécution sous le nom amba_config.prototxt pour assurer la reproductibilité.

Condition de sauvegarde du point de contrôle

best.pt et last.pt ne sont volontairement pas enregistrés avant que le calendrier de compression SpongeTorch atteigne son end_step — un point de contrôle à moitié compressé serait inutilisable. Vérifie que epochs est suffisamment long pour permettre au calendrier de ta configuration d’arriver à son terme ; le journal indique à quel moment l’enregistrement des points de contrôle commence. Si l’entraînement se termine avant la fin du calendrier, la dernière époque est tout de même enregistrée avec un avertissement, mais ce point de contrôle ne doit pas être déployé.

Affine le modèle plutôt que de l’entraîner de zéro

Pour obtenir la meilleure précision, entraîne d’abord ton modèle normalement (ou pars d’un point de contrôle préentraîné), puis effectue un affinage plus court avec compression en appliquant amba_config aux poids entraînés.

Validation du point de contrôle compressé#

Valide la précision avant la compilation en utilisant la même configuration :

Utilisation
yolo val model=runs/detect/train/weights/best.pt data=coco8.yaml \
  amba_config=config.prototxt amba_chipset=CV72

Le validateur réapplique spongetorch.prepare() si nécessaire et désactive la fusion Conv+BN afin de préserver la structure de compression. Compare le mAP à celui de ta référence non compressée ; si la baisse de précision est trop importante, ajuste la configuration SpongeKit et relance l’entraînement.

Exporter au format ONNX#

Exporte le point de contrôle compressé avec le même amba_config que celui utilisé pour l’entraînement :

Utilisation
from ultralytics import YOLO

model = YOLO("runs/detect/train/weights/best.pt")
model.export(
    format="onnx",
    amba_config="config.prototxt",
    amba_chipset="CV72",
)

L’exportateur reconstruit le modèle, réapplique spongetorch.prepare() avec ta configuration, recharge les poids du point de contrôle parcimonieux dans la structure préparée et trace le modèle vers ONNX avec la fusion Conv+BN désactivée. Le graphe obtenu est exactement au format attendu par les outils de compilation du SDK.

Préserver les métadonnées du modèle#

L’export ONNX intègre la tâche du modèle, les noms de classes, le stride et la taille d’entrée dans le fichier ONNX, tandis que le backend AmbaPB lit ces informations dans un fichier annexe metadata.yaml placé à côté du modèle compilé. Si les outils de compilation de ton SDK ne créent pas ce fichier annexe, extrais-le du modèle ONNX avant la compilation :

import onnx

from ultralytics.utils import YAML

model = onnx.load("model.onnx")
YAML.save("metadata.yaml", {item.key: item.value for item in model.metadata_props})

Garde metadata.yaml dans le même répertoire que le fichier compilé *.ambapb.ckpt.onnx ou *.ambapb.fastckpt.onnx.

Avertissement
  • Le point de contrôle doit inclure l’état de compression SpongeTorch. Toute tentative d’exporter un point de contrôle non compressé avec amba_config défini déclenche l’erreur : « Checkpoint has no SpongeTorch pruning state... Use a compressed checkpoint from amba training before export. »
  • La configuration doit correspondre à celle utilisée pendant l’entraînement. Une configuration différente peut empêcher le chargement correct des poids du point de contrôle.

Compiler avec les outils du SDK#

Compile le modèle ONNX exporté pour le chipset cible à l’aide des outils de compilation du SDK, en suivant le guide de compilation du SDK. Les outils projettent le graphe sur le moteur d’IA CVflow — en appliquant la PTQ, l’ordonnancement et la planification de la mémoire — et produisent le point de contrôle AmbaPB destiné à la validation sur l’hôte.

La PTQ applique une quantification INT8 à l’aide d’images d’étalonnage (préparées selon les instructions du guide de compilation du SDK). Les outils de compilation arbitrent entre précision et latence d’exécution : mapper davantage d’opérations en INT8 réduit la latence, mais peut diminuer la précision, tandis que conserver davantage d’opérations en FP16 préserve la précision au prix d’une latence accrue. Lorsque la PTQ ne permet pas d’atteindre ton objectif de précision au niveau INT8 requis par ton budget de latence, le QAT avec SpongeTorch est la solution prévue : il entraîne le modèle à tolérer une quantification INT8 plus agressive, ce qui permet de récupérer de la précision avec une latence moindre. Le QAT n’est pas encore disponible dans cette intégration et est prévu dans une prochaine version.

Remarque

Pour qu’Ultralytics reconnaisse le modèle compilé, son nom de fichier doit se terminer par .ambapb.ckpt.onnx ou .ambapb.fastckpt.onnx.

Exécuter l’inférence avec le modèle compilé#

Le modèle AmbaPB compilé se charge directement via l’API Ultralytics — AutoBackend détecte le suffixe .ambapb et dirige l’inférence vers cvflowbackend, ce qui exécute le modèle comme il le sera sur le moteur d’IA :

Utilisation
from ultralytics import YOLO

model = YOLO("model.ambapb.ckpt.onnx")

# Inference
results = model("https://ultralytics.com/images/bus.jpg")

# Validation
metrics = model.val(data="coco8.yaml")

Il s’agit de la dernière vérification de précision avant le déploiement sur le matériel, qui tient compte de tous les effets de quantification du compilateur. Si un fichier metadata.yaml se trouve à côté du modèle compilé, le backend en lit les noms de classes, le stride et les informations sur la tâche. Par défaut, le backend utilise le mode d’inférence CVflow acinf ; définis la variable d’environnement ULTRALYTICS_AMBAPB_DEBUG=1 pour consigner les détails des entrées et des sorties à des fins de débogage.

Convertir en binaire Cavalry#

Une fois le point de contrôle AmbaPB validé sur l’hôte, utilise les outils de compilation du SDK pour le convertir en binaire Cavalry destiné à ton appareil cible, en suivant le guide de compilation du SDK. Le binaire Cavalry est le format exécuté sur la carte par la bibliothèque d’exécution du SDK.

Déployer sur la carte#

Charge le binaire Cavalry sur ton appareil Ambarella à l’aide du moteur d’exécution du SDK Ambarella. Le prétraitement et le post-traitement doivent correspondre à ceux pour lesquels le modèle de détection a été compilé : une entrée RGB avec letterboxing dans la plage 0–255 et un décodage standard des sorties de détection YOLO. Consulte la documentation de déploiement du SDK pour connaître les API d’exécution.

Exporter sans SpongeTorch#

Si tu n’as pas besoin de l’élagage effectué pendant l’entraînement par SpongeTorch, le pipeline Ultralytics standard permet également de produire un modèle compilable par les outils du SDK :

Utilisation
yolo export model=yolo26n.pt format=onnx

Compile le fichier ONNX obtenu à l’aide des outils de compilation du SDK, qui effectuent eux-mêmes la quantification après entraînement. Cette méthode simplifie le workflow, sans dépendance à spongetorch pendant l’entraînement, au prix d’une baisse des performances d’exécution et de la précision après quantification.

Applications concrètes#

Les modèles Ultralytics YOLO sur les SoC Ambarella CVflow assurent une vision toujours active en périphérie :

  • Caméras de sécurité avec IA : détection en temps réel des personnes et des véhicules sur des caméras IP 4K, avec une consommation inférieure à 3 W.
  • Drones et robotique : détection et suivi d’objets embarqués pour la navigation, l’inspection et la livraison sur des puces de classe CV5.
  • Analyse industrielle et commerciale : comptage de personnes sur plusieurs flux, détection des EPI et surveillance des rayons sur des appareils en périphérie.

Résumé#

Ce guide a présenté le workflow actuel de déploiement des modèles Ultralytics YOLO sur les SoC Ambarella CVflow : entraînement tenant compte de la compression avec SpongeTorch (amba_config/amba_chipset), export ONNX du point de contrôle compressé, compilation hors ligne en point de contrôle AmbaPB avec les outils du SDK, validation sur l’hôte via Ultralytics et conversion en binaire Cavalry pour le déploiement sur l’appareil avec le SDK Ambarella.

Pour d’autres cibles d’IA en périphérie, consulte les guides Hailo, Rockchip RKNN, Sony IMX500, Qualcomm QNN, DEEPX et Axelera. Pour consulter la liste complète des formats d’export, visite la documentation du mode Export et la page des intégrations.

FAQ#

  • Non. Il n’existe pas de cible format="ambarella". Exporte le modèle au format ONNX (avec, en option, la compression SpongeTorch via amba_config), puis compile hors ligne le modèle ONNX en AmbaPB à l’aide des outils de compilation du SDK Ambarella.

  • Tu peux cibler n’importe quel SoC basé sur CVflow pris en charge par les outils de compilation de ton SDK, notamment les familles CV72/CV75 pour les caméras IA et CV5/CV52 pour les drones et la robotique. L’argument amba_chipset configure la cible d’optimisation de SpongeTorch ; sélectionne séparément la cible correspondante lors de la compilation. Les valeurs de chipset acceptées et leur disponibilité dépendent de la version du SDK installée.

  • SpongeTorch est la variante PyTorch de la bibliothèque de compression de modèles SpongeKit d’Ambarella (qui existe également en variantes Caffe et TensorFlow). Elle est intégrée au fork d’Ultralytics d’Ambarella pour permettre l’élagage non structuré pendant l’entraînement (l’entraînement tenant compte de la quantification est prévu dans une prochaine version). Elle est facultative : un simple export ONNX d’Ultralytics peut aussi être compilé avec les outils de compilation du SDK, qui effectuent eux-mêmes la quantification, au prix d’une baisse des performances d’exécution et de la précision après quantification.

  • Ils sont propriétaires et ne sont pas disponibles sur PyPI. Inscris-toi sur l’Ambarella Developer Zone pour demander l’accès au SDK ; celui-ci comprend les outils de compilation (avec cvflowbackend), et le wheel spongetorch, distribué séparément, est fourni avec le SDK.

  • Exécute yolo val model=model.ambapb.ckpt.onnx data=your_data.yaml avec le fork Ambarella installé. Le backend AmbaPB exécute le modèle compilé comme il le serait sur le moteur d’IA CVflow. Le mAP rapporté tient donc compte de tous les effets de quantification du compilateur.

Commentaires