Exportation CVflow Ambarella pour les modèles Ultralytics YOLO#
Déployer des modèles Ultralytics YOLO sur des SoC Ambarella nécessite de compiler les modèles à l'aide des outils de compilation d'Ambarella, et les modèles optimisés pour l'architecture CVflow offrent de meilleures performances au moment de l'inférence. Cette version dérivée d'Ultralytics intègre directement la boîte à outils de compression SpongeTorch d'Ambarella dans le pipeline d'entraînement, de validation et d'exportation, permettant aux développeurs de générer des modèles optimisés pour un déploiement efficace sur le matériel Ambarella.
Ce guide couvre le flux de travail actuel de déploiement pour la détection d'objets, de l'entraînement tenant compte de la compression jusqu'à l'inférence sur l'appareil (consulte l'aperçu du flux de travail pour tout le pipeline).
Le format de point de contrôle AmbaPB est une extension spécifique à Ambarella de la spécification IR d'ONNX qui prend en charge les primitives de calcul CVflow et regroupe les artefacts générés par les outils du SDK. C'est l'artefact côté hôte utilisé pour valider la précision du modèle compilé avant le déploiement ; le fichier binaire Cavalry distinct produit pour l'appareil cible est celui qui s'exécute sur la carte.
Ce flux de travail dépend de composants propriétaires du SDK d'Ambarella qui ne sont pas disponibles sur PyPI. Pour obtenir les paquets du SDK requis, inscris-toi dans la zone des développeurs d'Ambarella et demande l'accès via la plateforme de développement Cooper™.
Cette intégration est maintenue par Ambarella. Signale les problèmes concernant la version dérivée, SpongeTorch ou le SDK au support d'Ambarella.
Qu'est-ce qu'Ambarella ?#
Ambarella, dont le siège social est à 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 de signal d'image, l'encodage vidéo et le calcul d'IA sur puce, et 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 vision d'Ambarella. Elle utilise un moteur de vision dédié, séparé 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 dans des frameworks tels que PyTorch sont compilés au format natif de CVflow avec le SDK d'Ambarella avant de s'exécuter sur le moteur.
Familles de SoC CVflow actuelles et leurs applications typiques :
| Famille de SoC | Applications typiques |
|---|---|
| CV72 / CV75 | Caméras de sécurité IA 4K, caméras intelligentes, vision industrielle |
| CV5 / CV52 | Drones, caméras d'action, robotique, systèmes multicaméras |
| N1-655 | Appliances d'IA générative sur site et d'analyse vidéo multi-flux |
Pourquoi déployer YOLO sur Ambarella ?#
- Performances par watt : les SoC CVflow sont conçus pour l'IA de périphérie toujours active et exécutent la détection d'objets en temps réel dans les budgets de consommation d'une caméra.
- 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 clairsemé et plus efficace pour le déploiement CVflow.
- Pipeline de caméra intégré : Les SoC d'Ambarella combinent un processeur de signal d'image (ISP), un encodage vidéo ultra-HD et CVflow pour prendre en charge divers systèmes de caméras à faible consommation d'énergie, de sorte qu'un seul SoC Ambarella gère l'intégralité du pipeline de caméra IA.
Vue d'ensemble du workflow#
Le pipeline comporte six étapes :
- Entraînement tenant compte de la compression — entraîne avec une configuration SpongeKit (
amba_config) pour que SpongeTorch applique un élagage non structuré progressivement pendant l'entraînement. Lorsque la précision de la quantification post-entraînement (PTQ) n'est pas acceptable, SpongeTorch prend également en charge l'entraînement tenant compte de la quantification (QAT), mais cette voie n'est pas encore intégrée à cette intégration Ultralytics et est prévue pour une version ultérieure. - Exportation ONNX — exporte le checkpoint compressé avec le même
amba_config, en conservant la structure de compression dans le graphe ONNX. - Compilation — compile le modèle ONNX en un point de contrôle AmbaPB avec les outils de compilation du SDK, qui appliquent la PTQ pour le moteur CVflow.
- Validation de l'hôte — exécute le modèle
*.ambapb.ckpt.onnxcompilé via Ultralyticspredict/valvia le backend AmbaPB pour vérifier la précision avant le déploiement. - Conversion Cavalry — convertit le point de contrôle AmbaPB validé en un fichier binaire Cavalry avec les outils du SDK.
- Exécution sur l'appareil — exécute le fichier binaire Cavalry sur l'appareil avec la bibliothèque d'exécution du SDK d'Ambarella.
Le flux de travail d'entraînement et d'exportation de SpongeTorch est facultatif et peut être remplacé par une exportation ONNX simple (voir Exportation sans SpongeTorch).
Prérequis#
Installation#
Installe cette version dérivée d'Ultralytics, puis configure le SDK Ambarella CVflow — qui comprend les outils de compilation et la bibliothèque cvflowbackend — et installe la roue spongetorch distribuée à ses côtés :
# 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-*.whlAutoBackend localise cvflowbackend par le biais de la commande tv2 des outils de compilation du SDK (tv2 -libpath cvflowbackend), de sorte que les outils de compilation du SDK doivent être installés et présents sur ton PATH avant d'exécuter l'inférence ou la validation avec des modèles compilés.
Fichier de configuration SpongeKit#
SpongeTorch est piloté par un fichier de configuration SpongeKit (format texte protobuf, .prototxt) qui définit les passes d'élagage, y compris les cibles de parcimonie et le calendrier de compression. Obtiens des exemples de configuration et la documentation du schéma correspondant auprès de ta version du SDK Ambarella. Pour maintenir 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 la même configuration lors de l'exportation d'un point de contrôle compressé.
Arguments Amba#
Deux arguments contrôlent l'intégration de SpongeTorch dans les modes train, val et export :
| Argument | Type | Valeur par défaut | Description |
|---|---|---|---|
amba_config | str | None | Chemin vers la configuration SpongeKit transmise à spongetorch.prepare(). Active l'entraînement tenant compte de la compression et l'exportation compatible avec SpongeTorch. |
amba_chipset | str | None | Nom du chipset cible transmis à spongetorch.set_target_chipset(), par exemple CV72. |
Le fork ajoute également un argument d'exportation général :
| Argument | Type | Valeur par défaut | Description |
|---|---|---|---|
export_file | str | None | Chemin/nom de sortie d'exportation personnalisé, par exemple '/tmp/model.onnx' ou 'model.onnx'. |
Entraînement tenant compte de la compression#
Entraîne (ou ajuste) ton modèle avec la compression SpongeTorch activée :
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, de sorte que le réseau apprend à rester précis tout en devenant clairsemé. Le point de contrôle entraîné stocke l'état clairsemé de SpongeTorch (tensors _orig/_mask), dont l'étape d'exportation a besoin par la suite. Le fichier de configuration est copié dans le répertoire d'exécution sous le nom de amba_config.prototxt à des fins de reproductibilité.
best.pt et last.pt ne sont volontairement pas enregistrés tant que le calendrier de compression SpongeTorch n'a pas franchi son end_step — un checkpoint à moitié compressé ne serait pas utilisable. Vérifie que epochs est suffisamment long pour permettre au calendrier de ta configuration d'aller à son terme ; le journal indique à quel moment l'enregistrement des checkpoints 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 un tel checkpoint ne doit pas être déployé.
Pour obtenir la meilleure précision, entraîne d'abord ton modèle normalement (ou pars d'un checkpoint pré-entraîné), puis effectue un ajustement plus court avec compression et amba_config sur les poids entraînés.
Validation du checkpoint compressé#
Valide la précision avant la compilation, en utilisant la même configuration :
yolo val model=runs/detect/train/weights/best.pt data=coco8.yaml \
amba_config=config.prototxt amba_chipset=CV72Le validateur réapplique spongetorch.prepare() lorsque nécessaire et désactive la fusion Conv+BN afin de préserver la structure de compression. Compare le mAP à ta référence non compressée ; si la baisse de précision est trop importante, ajuste la configuration SpongeKit et réentraîne le modèle.
Exporter vers ONNX#
Exporte le checkpoint compressé avec le même amba_config que celui utilisé pour l'entraînement :
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 clairsemé dans la structure préparée et trace vers ONNX avec la fusion Conv+BN désactivée, produisant un graphe sous la forme exacte attendue par les outils de compilation du SDK.
Préserver les métadonnées du modèle#
L'exportation ONNX intègre la tâche du modèle, les noms de classes, le pas (stride) et la taille d'entrée dans le fichier ONNX, tandis que le backend AmbaPB lit ces informations à partir d'un fichier annexe metadata.yaml situé à côté du modèle compilé. Sauf si tes outils de compilation du SDK créent ce fichier annexe, extrait-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 *.ambapb.ckpt.onnx ou *.ambapb.fastckpt.onnx compilé.
- Le point de contrôle doit inclure l'état de compression de SpongeTorch. Tenter d'exporter un point de contrôle non compressé alors que
amba_configest défini lève l'erreur : "Le point de contrôle n'a pas d'état d'élagage SpongeTorch... Utilise un point de contrôle compressé provenant de l'entraînement amba avant l'exportation." - La configuration doit correspondre à celle utilisée pendant l'entraînement. L'utilisation d'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 ton jeu de puces cible à l'aide des outils de compilation du SDK, en suivant le guide de compilation du SDK. Les outils mappent le graphe sur le moteur d'IA CVflow — en appliquant la PTQ, la planification et la planification de la mémoire — et produisent le point de contrôle AmbaPB pour la validation de l'hôte.
La PTQ applique une quantification INT8 à l'aide d'images de calibration (préparées comme décrit dans le guide de compilation du SDK), et les outils de compilation équilibrent la précision par rapport à la latence d'exécution : mapper plus d'opérations sur INT8 réduit la latence mais peut réduire la précision, tandis que conserver plus d'opérations en FP16 préserve la précision à une latence plus élevée. Lorsque la PTQ ne peut pas atteindre ta cible de précision au niveau INT8 requis pour ton budget de latence, la QAT avec SpongeTorch est le remède prévu — elle entraîne le modèle à tolérer une quantification INT8 plus agressive, récupérant de la précision à un point de fonctionnement à plus faible latence. La QAT n'est pas encore disponible dans cette intégration et est prévue pour une version ultérieure.
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 achemine l'inférence via cvflowbackend, exécutant le modèle tel qu'il s'exécutera sur le moteur d'IA :
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 vérification finale de la précision avant le déploiement sur le matériel, y compris tous les effets de quantification du compilateur. Si un fichier metadata.yaml se trouve à côté du modèle compilé, le backend y lit les noms des classes, le stride et les informations sur la tâche. Le backend utilise par défaut 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 sorties à des fins de débogage.
Convertir en un fichier binaire Cavalry#
Une fois que le point de contrôle AmbaPB a réussi la validation de l'hôte, utilise les outils de compilation du SDK pour le convertir en un fichier binaire Cavalry pour ton appareil cible, en suivant le guide de compilation du SDK. Le fichier binaire Cavalry est la forme exécutée par la bibliothèque d'exécution du SDK sur la carte.
Déployer sur la carte#
Charge le fichier binaire Cavalry sur ton appareil Ambarella à l'aide du runtime du SDK Ambarella. Le prétraitement et le post-traitement doivent correspondre à ce pour quoi le modèle de détection a été compilé : une entrée RVB avec bandes noires (letterbox) dans la plage 0–255, et un décodage de détection YOLO standard sur les sorties. Consulte la documentation de déploiement du SDK pour les API d'exécution.
Exportation sans SpongeTorch#
Si tu n'as pas besoin de l'élagage lors de l'entraînement de SpongeTorch, le pipeline Ultralytics standard produit également un modèle que les outils du SDK peuvent compiler :
yolo export model=yolo26n.pt format=onnxCompile le fichier ONNX résultant avec les outils de compilation du SDK, qui effectuent eux-mêmes la quantification post-entraînement. Cette voie échange une partie des performances d'exécution et de la précision quantifiée contre un flux de travail plus simple sans dépendance à spongetorch au moment de l'entraînement.
Applications concrètes#
Les modèles Ultralytics YOLO sur les SoC Ambarella CVflow alimentent la vision périphérique toujours active :
- Caméras de sécurité 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 de vente au détail : comptage de personnes sur plusieurs flux, détection des EPI et surveillance des rayons sur des appliances périphériques.
Résumé#
Ce guide a présenté le flux de travail actuel pour déployer des modèles Ultralytics YOLO sur des SoC Ambarella CVflow : entraînement tenant compte de la compression avec SpongeTorch (amba_config/amba_chipset), exportation ONNX du point de contrôle compressé, compilation hors ligne vers un point de contrôle AmbaPB avec les outils du SDK, validation de l'hôte via Ultralytics, et conversion en un fichier binaire Cavalry pour un déploiement sur l'appareil avec le SDK Ambarella.
Pour d'autres cibles d'IA de périphérie, consulte les guides associés Hailo, Rockchip RKNN, Sony IMX500, Qualcomm QNN, DEEPX et Axelera. Pour consulter la liste complète des formats d'exportation, consulte la documentation du mode Export et la page des intégrations.
FAQ#
Non. Il n'y a pas de cible
format="ambarella". Exporte vers ONNX (éventuellement avec la compression SpongeTorch viaamba_config), puis compile le modèle ONNX en AmbaPB hors ligne avec les outils de compilation du SDK Ambarella.N'importe quel SoC basé sur CVflow pris en charge par tes outils de compilation du SDK peut être ciblé, y compris les familles CV72/CV75 pour les caméras IA et CV5/CV52 pour les drones et la robotique. L'argument
amba_chipsetconfigure la cible d'optimisation de SpongeTorch ; sélectionne la cible correspondante séparément lors de la compilation. Les chaînes de jeux de puces acceptées et la 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 possède également des variantes Caffe et TensorFlow), intégrée dans la version dérivée d'Ambarella d'Ultralytics pour l'élagage non structuré au moment de l'entraînement (l'entraînement tenant compte de la quantification est prévu pour une version ultérieure). Elle est facultative : une simple exportation ONNX d'Ultralytics peut également être compilée avec les outils de compilation du SDK, qui effectuent eux-mêmes la quantification, au détriment des performances d'exécution et de la précision quantifiée.
Ils sont propriétaires et ne figurent pas sur PyPI. Inscris-toi sur la zone des développeurs d'Ambarella pour demander l'accès au SDK ; le SDK comprend les outils de compilation (avec
cvflowbackend), et la rouespongetorchdistribuée séparément est fournie avec.
Exécute
yolo val model=model.ambapb.ckpt.onnx data=your_data.yamlavec la version dérivée d'Ambarella installée. Le backend AmbaPB exécute le modèle compilé tel qu'il s'exécute sur le moteur d'IA CVflow, de sorte que le mAP rapporté inclut tous les effets de quantification du compilateur.