Exportation Hailo pour les modèles YOLO d'Ultralytics#

Les accélérateurs Hailo AI exécutent des modèles HEF (Hailo Executable Format) compilés sur des appareils périphériques tels que le Raspberry Pi AI Kit et le AI HAT+. Ultralytics exporte directement les modèles de détection, de segmentation, de segmentation sémantique, d'estimation de profondeur, de classification, de pose et d'OBB YOLO au format HEF à l'aide du Hailo Dataflow Compiler (DFC).

Le déploiement Hailo est conçu pour la vision par ordinateur à la périphérie : caméras, robots, systèmes industriels, passerelles et autres dispositifs qui nécessitent une détection d'objets locale sans envoyer chaque image vers le cloud. Un fichier HEF compilé contient le réseau quantifié, l'allocation matérielle, la planification et le post-traitement HailoRT optionnel nécessaires pour l'accélérateur sélectionné.

Pourquoi déployer Ultralytics YOLO sur Hailo ?#

Combiner Ultralytics YOLO avec une unité de traitement neuronal (NPU) Hailo offre une voie pratique de l'entraînement du modèle à l'inférence d'IA basse consommation à la périphérie. Les cas d'utilisation courants incluent :

• Caméras intelligentes et analyse vidéo : Exécute la détection d'objets en temps réel près de la caméra pour des applications de sécurité, de commerce de détail, de trafic et d'occupation.
• Robotique et systèmes autonomes : Détecte des personnes, des véhicules, des colis, des outils ou des obstacles sans dépendre d'une connexion cloud continue.
• Vision industrielle par ordinateur : Déploie des modèles YOLO personnalisés pour l'inspection, le comptage, le contrôle de sécurité et le contrôle qualité.
• Projets Raspberry Pi AI : Ajoute l'inférence de vision accélérée aux systèmes Raspberry Pi en utilisant le AI Kit ou le AI HAT+.
• Passerelles de périphérie et PC IA : Traite localement plusieurs flux vidéo ou de capteurs tout en réduisant les besoins en bande passante et en calcul cloud.

L'inférence locale peut améliorer la confidentialité et le temps de réponse car les images restent sur le dispositif de déploiement. Le débit, la latence et la consommation d'énergie réels dépendent de la taille du modèle YOLO, de la résolution d'entrée, de l'architecture Hailo, du système hôte et du pipeline de l'application.

Comment fonctionne l'exportation Hailo#

Ultralytics gère l'intégralité du flux d'exportation derrière format="hailo" :

YOLO (.pt) -> ONNX -> Hailo parse -> INT8 optimization -> HEF compile

L'exportateur effectue ces étapes automatiquement :

1. Exporte un graphe ONNX statique avec des paramètres compatibles avec le compilateur.
2. Sélectionne les sorties de tête pour l'architecture du modèle.
3. Génère les directives de normalisation, d'activation et de post-traitement.
4. Construit un flux de calibration représentatif et quantifie le modèle en INT8.
5. Compile le graphe optimisé pour l'accélérateur Hailo sélectionné.
6. Enregistre le HEF avec les métadonnées Ultralytics et supprime le fichier ONNX intermédiaire.

Les modèles de détection YOLOv8 et YOLO11 utilisent HailoRT YOLO NMS dans le pipeline compilé. Les modèles de détection YOLO26 utilisent leurs sorties one-to-one sans NMS, de sorte que l'exportateur sélectionne automatiquement un chemin de sortie et de quantification différent. La segmentation, la pose et l'OBB de YOLOv8/YOLO11 compilent les tenseurs bruts de la tête, qu'Ultralytics décode lors de l'inférence, et la classification de YOLOv8/YOLO11/YOLO26 exécute le softmax sur la puce afin que le HEF renvoie directement les probabilités de classe. Pour la segmentation sémantique de YOLO26, l'exportateur suit l'accélérateur : Hailo-8/8L (DFC v3.x) renvoient les logits du classificateur pour le suréchantillonnage et la réduction sur l'hôte, tandis que Hailo-10/15 (DFC v5.x) compilent des têtes ArgMax multiclasses sur la puce et renvoient une carte de classes compacte. Les têtes monoclasses utilisent le chemin des logits de l'hôte sur chaque cible, car elles nécessitent un seuil au lieu de ArgMax. Les modèles de profondeur YOLO26 compilent la convolution dense des logits dans a16 et reconstruisent la carte de profondeur métrique sur l'hôte (le clamp/exp et la calibration log-affine apprise qui suivent la tête), de sorte que le quantificateur conserve sa plage la plus large sur le logit brut. Les utilisateurs n'ont pas besoin de trouver des nœuds de fin ONNX, d'écrire un script de modèle Hailo (.alls) ou de créer un JSON NMS manuellement.

Installation#

Installe Ultralytics et télécharge le wheel DFC pour ton matériel cible depuis la Hailo Developer Zone (inscription gratuite requise) :

pip install ultralytics
pip install /path/to/hailo_dataflow_compiler-*.whl

Hailo-8 et Hailo-8L utilisent DFC v3.x. Hailo-10 et Hailo-15 utilisent DFC v5.x. Installe la génération de compilateur qui correspond à l'accélérateur cible.

Exporter un modèle Hailo HEF#

Utilise format="hailo" et sélectionne l'accélérateur cible avec name :

from ultralytics import YOLO

model = YOLO("yolo11n.pt")
output = model.export(format="hailo", name="hailo8l")
print(output)  # yolo11n_hailo_model/

La commande CLI équivalente est :

yolo export model=yolo11n.pt format=hailo name=hailo8l

L'exportation Hailo est strictement INT8. Ultralytics télécharge automatiquement un jeu de données de calibration spécifique à une tâche lorsque data n'est pas fourni. Pour les modèles personnalisés, utilise des images d'entraînement ou de validation représentatives :

model.export(format="hailo", name="hailo8l", data="path/to/dataset.yaml")

La compilation utilise une forme d'entrée fixe. Définis imgsz sur la résolution utilisée sur l'appareil :

model.export(format="hailo", name="hailo8l", imgsz=640)

Modèles et matériel pris en charge#

L'écosystème Hailo couvre un large éventail de charges de travail de vision par ordinateur, mais l'exportateur Ultralytics format="hailo" valide actuellement les têtes standard de détection, de segmentation, de segmentation sémantique, d'estimation de profondeur, de classification, de pose et d'OBB YOLO. Le tableau des tâches décrit les chemins d'exportation disponibles ; la validation matérielle est répertoriée séparément ci-dessous.

Les familles de détection spécialisées telles que YOLOv10, YOLO-World, YOLOE et RT-DETR sont également ❌ non prises en charge. Ultralytics rejette ces tâches et familles de modèles avant la compilation au lieu de produire un HEF non validé.

La pose, l'OBB, la classification, la segmentation sémantique YOLO26 et l'estimation de profondeur YOLO26 (chemin Hailo-8/8L) ont été validées sur Hailo-8L avec HailoRT 4.23 et DFC 3.33. L'exportateur accepte les autres cibles répertoriées, mais ces nouveaux chemins de tâches nécessitent une validation avec le compilateur et l'appareil correspondants avant une utilisation en production.

Sélectionne l'une de ces valeurs pour name :

hailo8l est la valeur par défaut. Installe la génération de DFC qui correspond à la cible sélectionnée.

Générations de matériel et SDK Hailo#

Les familles d'accélérateurs Hailo utilisent différentes générations de compilateurs. Le HEF généré doit correspondre au matériel cible. Choisis donc name pour l'appareil qui exécutera l'inférence plutôt que pour la machine effectuant l'exportation.

Le compilateur s'exécute sur Linux x86_64, tandis que le HEF résultant s'exécute sur le dispositif Hailo via HailoRT. Cette séparation te permet de compiler sur une station de travail ou dans Ultralytics Platform et de déployer l'artefact de runtime léger sur un hôte de périphérie ARM ou x86.

Notes de compatibilité#

La compilation Hailo est spécifique au matériel et utilise une forme d'entrée fixe. Garde ces contraintes à l'esprit :

• Le paramètre name sélectionné doit correspondre à l'accélérateur de déploiement.
• Les images de calibration doivent représenter l'éclairage, les points de vue, les objets et les arrière-plans attendus en production.
• Un HEF compilé avec un imgsz ne devient pas redimensionnable dynamiquement au moment de l'exécution.
• Les nombres de classes personnalisés sont pris en charge car Ultralytics génère la configuration de post-traitement à partir des métadonnées du modèle.
• Les modèles de détection avec des têtes standard Ultralytics Detect, les modèles de segmentation, de pose et d'OBB YOLOv8/YOLO11, les modèles de classification YOLOv8/YOLO11/YOLO26, ainsi que les modèles de segmentation sémantique et d'estimation de profondeur YOLO26 sont pris en charge. La segmentation d'instances, la pose et les boîtes englobantes orientées de YOLO26, ainsi que les exportations YOLO-World, YOLOE, YOLOv10 et RT-DETR ne sont actuellement pas prises en charge.
• Les artefacts Hailo-8/8L et Hailo-10/15 sont compilés par différentes générations de DFC et ne sont pas interchangeables.

Calibration et quantification INT8#

L'exportation HEF Hailo utilise la quantification INT8 pour mapper efficacement le réseau YOLO sur l'accélérateur. Le jeu de données de calibration estime les plages d'activation ; il ne réentraîne pas le modèle et ne nécessite pas d'étiquettes pendant la compilation.

Lorsque data est omis, Ultralytics utilise un jeu de données de calibration léger spécifique à la tâche, tel que COCO128 pour la détection, cityscapes8 pour la segmentation sémantique ou depth8 pour l'estimation de profondeur. La tête de profondeur dense est particulièrement sensible au domaine de calibration : calibrer un modèle de profondeur avec des images de détection non liées aplatit la carte prédite, et des ensembles plus grands dans le domaine améliorent la fidélité. Pour un modèle de vision par ordinateur personnalisé, pointe data vers son fichier YAML de jeu de données afin que le compilateur observe des images représentatives du domaine de déploiement réel :

model.export(format="hailo", name="hailo8l", data="my_dataset.yaml")

fraction sélectionne la portion du jeu de données utilisée pour la calibration. Davantage d'images ne sont utiles que lorsqu'elles représentent le domaine de déploiement ; des images hors domaine peuvent réduire la précision quantifiée et augmenter le temps d'optimisation. Si le HEF INT8 perd en précision par rapport au modèle PyTorch d'origine, améliore d'abord les données de calibration avant de modifier les paramètres du modèle ou du runtime.

Attentes de précision par famille de modèles#

Mesurés sur un Hailo-8L avec un calibrage dans le domaine (COCO128, 128 images), les exports HEF en INT8 conservent la part suivante de leur mAP50 PyTorch sous le même protocole d'évaluation :

La conservation compare les deux modèles au même seuil de confiance. Les HEF YOLOv8 et YOLO11 intègrent la valeur conf du moment de l'exportation (par défaut 0,25) dans le NMS sur puce. Par conséquent, valider par rapport à une référence PyTorch à son seuil bas par défaut intègre une plus grande partie de la courbe précision-rappel et exagère l'écart de quantification.

Au-delà de la détection, les chemins d'exportation pour la segmentation, la pose, l'OBB et la classification ont été validés sur le même Hailo-8L (DFC 3.33, HailoRT 4.23). Chaque HEF INT8 a été comparé avec son point de contrôle PyTorch sur le même ensemble de validation, en utilisant un étalonnage dans le domaine :

La segmentation, la pose et l'OBB ont été calibrés avec l'ensemble dans le domaine par défaut de chaque tâche (COCO128-seg, COCO8-pose, DOTA128) ; la classification a été calibrée avec ImageNet100. Deux réserves découlent de ces valeurs par défaut : COCO8-pose ne compte que 8 images, traite donc la pose comme indicative et passe un data= plus grand pour la production, et DOTA8 sature mAP50 près de 100 % pour les deux modèles, raison pour laquelle l'OBB est lu sur DOTA128. La classification est également la seule tâche où YOLO11 retient plus que YOLOv8 ; pour les autres, le backbone d'attention de YOLO11 est plus sensible à l'INT8.

Trois règles pratiques découlent des mesures sur le périphérique :

1. Calibre toujours dans le domaine. Le réglage fin avec des images hors domaine équivaut à désactiver complètement le réglage fin : un YOLO26n calibré avec 1 238 images hors domaine conserve la même précision (85,7 %) qu'un modèle compilé sans réglage fin. Un petit jeu de données dans le domaine surpasse un grand jeu hors domaine.
2. Abaisse conf d'environ 0,05 pour les déploiements YOLO26. La quantification réduit les scores YOLO26 d'environ 0,05 en moyenne. Un seuil réglé dans PyTorch élimine donc des détections valides sur le HEF. L'utilisation de conf=0.20 sur l'appareil correspond au nombre de détections de PyTorch à conf=0.25, et baisser légèrement davantage (autour de conf=0.15) récupère essentiellement la totalité de l'écart mAP50 restant au détriment d'un plus grand nombre de détections à faible confiance. La quantification réordonne également environ 20 % des détections — un effet d'ordre permanent qu'aucun seuil n'annule — mais ce réagencement n'empêche pas la récupération du mAP50 au seuil inférieur.
3. La pénalité d'attention est structurelle sur Hailo-8/8L (DFC 3.33). Les blocs d'attention seompilent en opérations matmul qui conservent les entrées d'activation INT8 dans tous les modes que le compilateur propose pour elles ; le mode à sortie 16 bits échoue à l'allocation pour ce graphe, et l'augmentation de la précision des couches environnantes n'aide pas car le produit matriciel (matmul) requantifie de toute façon ses entrées en INT8 (protéger les convolutions depthwise et de sortie en 16 bits n'a pas modifié le mAP dans nos tests). Lorsque la précision est la priorité et que le modèle est interchangeable, YOLO11 se quantifie actuellement mieux que YOLO26 ici ; les générations Hailo plus récentes (DFC 5.x) exposent davantage d'options en précision mixte et peuvent différer.

Artefacts exportés#

L'exportation crée un répertoire contenant le HEF déployable et les métadonnées Ultralytics :

yolo11n_hailo_model/
├── yolo11n.hef
├── metadata.yaml
└── nms_config.json

• *.hef est le modèle compilé chargé par HailoRT.
• metadata.yaml préserve les noms de modèles, la tâche, la taille d'entrée, le pas (stride) et les informations sur la cible Hailo.
• nms_config.json enregistre la configuration NMS HailoRT générée pour les modèles de détection YOLOv8 et YOLO11. La détection YOLO26 et toutes les tâches autres que la détection (segmentation, sémantique, profondeur, classification, pose, OBB) n'utilisent pas ce fichier.

Le graphe ONNX intermédiaire est supprimé après la compilation.

Exécuter l'inférence sur le matériel Hailo#

Installe HailoRT sur l'appareil cible. Les utilisateurs du Raspberry Pi AI Kit et du AI HAT+ peuvent suivre le guide du logiciel Raspberry Pi AI :

sudo apt install hailo-all
hailortcli fw-control identify

Copie le répertoire d'exportation complet sur l'appareil afin que metadata.yaml reste à côté du HEF. Ultralytics utilise HailoRT pour exécuter predict et val directement sur le répertoire exporté :

from ultralytics import YOLO

model = YOLO("yolo11n_hailo_model")
results = model.predict("path/to/image.jpg")

Pour les modèles de détection, le backend convertit la sortie NMS HailoRT de YOLOv8 et YOLO11 et décode automatiquement les sorties one-to-one de YOLO26. Il décode les tenseurs bruts de segmentation, de pose et d'OBB, renvoie les probabilités de classification sur la puce et produit des cartes de classes sémantiques par réduction sur l'hôte sur les têtes Hailo-8/8L et toutes les têtes monoclasses, ou par un ArgMax sur la puce pour les têtes multiclasses Hailo-10/15. TAPPAS, GStreamer et l'assistant picamera2.devices.Hailo pour Raspberry Pi restent disponibles pour les pipelines spécifiques à l'application.

Pour un déploiement GStreamer, passe le HEF à hailonet :

gst-launch-1.0 filesrc location=video.mp4 ! decodebin ! videoconvert ! \
  hailonet hef-path=yolo11n_hailo_model/yolo11n.hef ! \
  hailofilter function-name=yolov8 ! hailooverlay ! autovideosink

Options de déploiement Hailo#

Le HEF est le même artefact de modèle déployable à travers plusieurs interfaces de runtime Hailo. Choisis l'interface qui convient à l'application :

Conserve metadata.yaml avec le HEF lorsque l'application a besoin des noms de classes d'Ultralytics, de la taille d'entrée, du pas ou d'autres informations sur le modèle. Le HEF lui-même ne remplace pas la logique au niveau de l'application pour la capture de la caméra, la visualisation, le suivi, les alertes ou le stockage.

Vérifier le périphérique Hailo et le HEF#

Avant d'intégrer une caméra ou un pipeline vidéo, vérifie indépendamment le runtime et l'accélérateur :

hailortcli fw-control identify
hailortcli parse-hef yolo11n_hailo_model/yolo11n.hef

Les mesures de performance basées uniquement sur le périphérique isolent l'inférence Hailo du décodage vidéo, du redimensionnement d'image, du rendu et des E/S de l'application. Mesure l'application complète séparément lors de l'estimation de la latence de bout en bout ou du nombre d'images par seconde.

Hailo comparé aux autres formats d'exportation YOLO#

Choisis un format d'exportation en fonction du matériel qui exécutera le modèle :

HEF est le bon choix lorsque l'appareil final contient un accélérateur Hailo. ONNX reste utile en tant que format d'échange portable, mais HailoRT exécute le HEF spécifique au matériel produit par le DFC plutôt que le modèle ONNX original.

Optimiser les performances de vision par ordinateur Hailo#

Le choix du modèle et du pipeline compte souvent plus que les flags du compilateur :

• Commence avec un petit modèle YOLO et n'augmente sa taille que si la précision l'exige.
• Choisis la valeur fixe imgsz la plus basse qui préserve tout de même les objets importants pour l'application.
• Utilise des images de calibration provenant de la caméra réelle et de l'environnement si possible.
• Maintiens le réseau Hailo actif entre les images au lieu de rouvrir le HEF à chaque inférence.
• Sépare le temps d'inférence sur le périphérique du prétraitement, du décodage vidéo, du post-traitement, de la visualisation et des E/S réseau.
• Utilise un pipeline de streaming tel que GStreamer pour les charges de travail vidéo soutenues.
• Valide le HEF exporté sur l'accélérateur et la version HailoRT exacts utilisés en production.

Arguments d'exportation#

Pour l'exportation de détection, YOLOv8 et YOLO11 reçoivent le NMS HailoRT, tandis que YOLO26 conserve ses sorties one-to-one sans NMS. La segmentation, la pose et l'OBB utilisent des tenseurs de tête bruts, la classification renvoie des probabilités sur la puce, et la segmentation sémantique renvoie des logits bruts sur Hailo-8/8L et toutes les têtes monoclasses, ou des cartes de classes intégrées pour les têtes multiclasses Hailo-10/15. L'estimation de profondeur renvoie le logit de profondeur brut, qu'Ultralytics décode en une carte de profondeur métrique lors de l'inférence. Ne transmets pas end2end ; les surcharges explicites sont rejetées. Les formes dynamiques, les lots (batches) supérieurs à un, le NMS Ultralytics intégré, le FP16 et le FP32 ne sont également pas pris en charge.

Dépannage de l'exportation Hailo#

Erreur d'importation du Hailo Dataflow Compiler#

Si l'exportation indique qu'il manque hailo_sdk_client, installe le package wheel du DFC pour la génération de matériel cible dans le même environnement Python qu'Ultralytics. Hailo-8/8L et Hailo-10/15 nécessitent des générations de compilateurs différentes.

Système d'exploitation ou architecture non pris en charge#

La compilation HEF est prise en charge sur Linux x86_64. Effectue l'exportation via Ultralytics Platform ou utilise une station de travail compatible si l'ordinateur local est sous macOS, Windows, Raspberry Pi ou un autre système ARM.

L'exportation prend beaucoup de temps#

L'optimisation DFC est l'étape la plus coûteuse. Le temps de compilation augmente avec la taille du modèle, la résolution d'entrée et les données de calibration. Un GPU pris en charge peut accélérer l'optimisation, tandis qu'une compilation uniquement CPU peut être nettement plus lente.

La précision du modèle quantifié chute#

Utilise des images de calibration qui ressemblent aux entrées de production et incluent les objets importants, les échelles, les conditions d'éclairage et les arrière-plans. Compare le modèle PyTorch d'origine et le HEF exporté sur le même ensemble de validation avant le déploiement. Un écart modéré dépendant de la famille subsiste même avec une bonne calibration ; consulte Attentes de précision par famille de modèles pour les références mesurées.

Le HEF ne se charge pas sur le périphérique#

Confirme que name correspond à l'architecture Hailo physique et que le pilote de l'appareil, le micrologiciel (firmware) et les packages HailoRT sont mutuellement compatibles. Inspecte l'artefact avec hailortcli parse-hef et vérifie l'accélérateur avec hailortcli fw-control identify.

L'analyse de la sortie semble incorrecte#

Conserve metadata.yaml à côté du HEF afin qu'Ultralytics puisse sélectionner le chemin de post-traitement YOLOv8, YOLO11 ou YOLO26 correspondant. Les applications HailoRT personnalisées doivent de même faire correspondre le post-traitement à la famille de modèles exportés.

Résumé#

L'exportation Hailo d'Ultralytics fournit un chemin direct d'un modèle YOLO entraîné vers un HEF déployable :

1. Charge un modèle de détection ou de classification YOLOv8, YOLO11 ou YOLO26, un modèle de segmentation, de pose ou d'OBB YOLOv8/YOLO11, ou un modèle de segmentation sémantique ou d'estimation de profondeur YOLO26.
2. Exporte avec format="hailo" et sélectionne l'architecture cible.
3. Calibre et compile localement avec le DFC correspondant, ou utilise l'exportation gérée dans Ultralytics Platform.
4. Copie le HEF et metadata.yaml sur l'appareil périphérique alimenté par Hailo.
5. Exécute l'inférence avec HailoRT, Raspberry Pi Picamera2 ou un pipeline vidéo GStreamer.

Pour d'autres cibles de déploiement en vision par ordinateur, consulte Mode Export, Mode Benchmark et le guide des intégrations. Les guides matériels associés incluent ONNX, OpenVINO, TensorRT, NCNN, RKNN, Sony IMX500 et Qualcomm QNN.

FAQ#