Export Hailo pour les modèles YOLO Ultralytics#

Les accélérateurs Hailo AI exécutent des modèles compilés au format exécutable Hailo (HEF) sur des appareils edge tels que le AI HAT+ de Raspberry Pi et l’AI HAT+ 2. Ultralytics exporte directement vers HEF les modèles YOLO de détection, de segmentation, de segmentation sémantique, d’estimation de profondeur, de classification, de pose et d’OBB avec le compilateur de flux de données Hailo (DFC).

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

Pourquoi déployer Ultralytics YOLO sur Hailo ?#

Associer Ultralytics YOLO à une unité de traitement neuronal (NPU) Hailo offre un parcours pratique, de l’entraînement du modèle à l’inférence IA en périphérie. Les cas d’usage courants incluent :

• Caméras intelligentes et analyse vidéo : exécute une détection d’objets en temps réel près de la caméra pour les applications de sécurité, de vente au détail, de circulation et d’occupation.
• Robotique et systèmes autonomes : détecte les personnes, les véhicules, les colis, les outils ou les obstacles sans dépendre d’une connexion cloud continue.
• Vision par ordinateur industrielle : déploie des modèles YOLO personnalisés pour l’inspection, le comptage, la surveillance de la sécurité et le contrôle qualité.
• Projets Raspberry Pi AI : ajoute l’inférence visuelle accélérée aux systèmes Raspberry Pi avec l’AI HAT+ ou l’AI HAT+ 2.
• Passerelles edge 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 l’appareil 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 applicatif.

Fonctionnement de l’export Hailo#

Ultralytics prend en charge l’ensemble du workflow d’export sous-jacent à format="hailo" :

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

L’exportateur effectue automatiquement les étapes suivantes :

1. Exporte un graphe ONNX statique avec des paramètres compatibles avec le compilateur.
2. Sélectionne les sorties de tête correspondant à 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 un-à-un sans NMS ; l’exportateur sélectionne donc automatiquement une autre sortie et une autre voie de quantification. 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, tandis que la classification YOLOv8/YOLO11/YOLO26 exécute softmax sur la puce afin que le HEF renvoie directement les probabilités des classes. Pour la segmentation sémantique YOLO26, l’exportateur s’adapte à l’accélérateur : Hailo-8/8L (DFC v3.x) renvoient les logits du classifieur pour le suréchantillonnage et la réduction sur l’hôte, tandis que Hailo-10H/15 (DFC v5.x) compilent les têtes ArgMax multi-classes sur la puce et renvoient une carte compacte des classes. Les têtes à classe unique utilisent la voie des logits sur l’hôte pour toutes les cibles, car elles nécessitent un seuil plutôt qu’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) ; le quantificateur conserve ainsi sa plage la plus large sur le logit brut. Tu n’as pas besoin de rechercher les nœuds de sortie ONNX, d’écrire un script de modèle Hailo (.alls) ni de créer manuellement un fichier JSON NMS.

Installation#

Installe Ultralytics et télécharge le paquet wheel DFC correspondant à 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-10H et Hailo-15 utilisent DFC v5.x. Installe la génération du compilateur correspondant à 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="hailo8")
print(output)  # yolo11n_hailo_model/

La commande CLI équivalente est :

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

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

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

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

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

Modèles et matériels 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 YOLO standard de détection, de segmentation, de segmentation sémantique, d’estimation de profondeur, de classification, de pose et d’OBB. Le tableau des tâches décrit les voies d’export disponibles ; la validation matérielle est indiquée séparément ci-dessous.

Les familles de détection spécialisées telles que YOLOv10, YOLO-World, YOLOE et RT-DETR ne sont actuellement ❌ pas prises en charge via la voie Ultralytics format="hailo". 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 (voie 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 nouvelles voies de tâches nécessitent une validation avec le compilateur et l’appareil correspondants avant toute utilisation en production.

Sélectionne l’une de ces valeurs name :

Si name est omis, hailo8l est utilisé par défaut ; définis name sur l’accélérateur sur lequel tu effectueras le déploiement. Installe la génération du DFC correspondant à la cible sélectionnée.

Générations matérielles 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 qui effectue l’export.

Le compilateur s’exécute sous Linux x86_64, tandis que le HEF obtenu s’exécute sur l’appareil Hailo via HailoRT. Cette séparation te permet de compiler sur une station de travail ou dans Ultralytics Platform, puis de déployer le petit artefact d’exécution sur un hôte edge ARM ou x86.

Notes de compatibilité#

La compilation Hailo dépend du matériel et utilise une forme d’entrée fixe. Garde à l’esprit les contraintes suivantes :

• Le 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.
• Chaque HEF est compilé pour un imgsz fixe. Pour traiter plusieurs résolutions, redimensionne les images sur l’hôte à la taille compilée ou compile un HEF distinct pour chaque résolution.
• Les nombres de classes personnalisés sont pris en charge, car Ultralytics génère la configuration du post-traitement à partir des métadonnées du modèle.
• Les modèles de détection dotés de têtes Detect standard d’Ultralytics, les modèles de segmentation, de pose et 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 exports YOLO-World, YOLOE, YOLOv10 et RT-DETR, ne sont actuellement pas pris en charge.
• Les artefacts Hailo-8/8L et Hailo-10H/15 sont compilés par des générations différentes de DFC et ne sont pas interchangeables.

Calibration et quantification INT8#

L’export Hailo HEF 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’annotations lors de la compilation.

Lorsque data est omis, Ultralytics utilise un jeu de données de calibration léger et spécifique à la tâche, comme 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 sans rapport aplatit la carte prédite, tandis que des jeux plus importants du domaine cible améliorent la fidélité. Pour un modèle de vision par ordinateur personnalisé, indique data vers son fichier YAML de données afin que le compilateur observe des images représentatives du domaine réel de déploiement :

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

fraction sélectionne le ratio ou le nombre d’images utilisé pour la calibration. Les listes [train, val, test] limitent chaque partition, les listes à deux éléments laissent test complet, et 0 ignore le test. Davantage d’images n’est utile que si 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, commence par améliorer 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 une calibration dans le domaine cible (COCO128, 128 images), les exports HEF INT8 conservent la part suivante de leur mAP50 PyTorch selon le même protocole d’évaluation :

La conservation compare les deux modèles avec le même seuil de confiance. Les HEF YOLOv8 et YOLO11 intègrent le conf au moment de l’export (0,25 par défaut) dans le NMS sur puce ; les valider par rapport à une référence PyTorch utilisant son seuil bas par défaut couvre une portion plus importante de la courbe précision-rappel et surestime 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é à son checkpoint PyTorch sur la même partition de validation, avec une calibration dans le domaine cible :

La segmentation, la pose et l’OBB ont été calibrées avec le jeu par défaut de chaque tâche dans le domaine cible (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 contient que 8 images, considère donc la pose comme indicative et passe un data= plus grand en production ; et DOTA8 sature le mAP50 près de 100 % pour les deux modèles, raison pour laquelle l’OBB est évaluée sur DOTA128. La classification est également la seule tâche où YOLO11 conserve davantage que YOLOv8 ; pour les autres, le backbone à attention de YOLO11 est plus sensible à l’INT8.

Trois règles pratiques découlent des mesures effectuées sur l’appareil :

1. Calibre toujours dans le domaine cible. Un réglage fin avec des images hors domaine revient à 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 du domaine cible vaut mieux qu’un grand jeu hors domaine.
2. Diminue 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 ajusté dans PyTorch exclut donc des détections valides dans le HEF. Utiliser conf=0.20 sur l’appareil correspond au nombre de détections de PyTorch avec conf=0.25, et diminuer encore légèrement (environ conf=0.15) récupère pratiquement tout l’écart de mAP50 restant, au prix 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 ne peut annuler — mais ce remaniement n’empêche pas de récupérer le mAP50 avec le seuil inférieur.
3. La pénalité d’attention est structurelle sur Hailo-8/8L (DFC 3.33). Les blocs d’attention sont compilés en opérations matmul qui conservent des entrées d’activation INT8 dans tous les modes que le compilateur propose pour celles-ci ; le mode de sortie 16 bits échoue lors de l’allocation pour ce graphe, et augmenter la précision des couches environnantes n’aide pas, car la multiplication matricielle 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 prioritaire 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) offrent davantage d’options de précision mixte et peuvent se comporter différemment.

Artefacts exportés#

L’export 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 conserve les noms des modèles, la tâche, la taille d’entrée, le 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 sans détection (segmentation, 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 des inférences sur le matériel Hailo#

Installe HailoRT sur l’appareil cible. Les utilisateurs de Raspberry Pi AI HAT+ et AI HAT+ 2 peuvent suivre le guide logiciel Raspberry Pi AI. Sous Raspberry Pi OS, les deux ensembles de paquets ne peuvent pas être installés simultanément ; exécute donc uniquement le bloc correspondant à ton matériel, puis redémarre.

Pour AI HAT+ (Hailo-8 / Hailo-8L) :

sudo apt install dkms
sudo apt install hailo-all
sudo reboot

Pour AI HAT+ 2 (Hailo-10H, Raspberry Pi OS Trixie ou version ultérieure) :

sudo apt install dkms
sudo apt install hailo-h10-all
sudo reboot

Après le redémarrage, vérifie que l’accélérateur est détecté :

hailortcli fw-control identify

Copie le répertoire d’export complet sur l’appareil afin que metadata.yaml reste à côté du HEF. Ultralytics utilise HailoRT pour exécuter predict et val directement depuis 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 automatiquement la sortie NMS HailoRT de YOLOv8 et YOLO11 et décode 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 puce et produit des cartes de classes sémantiques par réduction côté hôte sur Hailo-8/8L et pour toutes les têtes à classe unique, ou par un ArgMax sur puce pour les têtes multiclasses Hailo-10H/15. TAPPAS, GStreamer et l’assistant picamera2.devices.Hailo de Raspberry Pi restent disponibles pour les pipelines propres à chaque 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 pour plusieurs interfaces de runtime Hailo. Choisis l’interface adaptée à ton application :

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

Vérifier l’appareil Hailo et le HEF#

Avant d’intégrer un pipeline caméra ou vidéo, vérifie séparément le runtime et l’accélérateur :

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

Les mesures de performances limitées à l’appareil isolent l’inférence Hailo du décodage vidéo, du redimensionnement des images, du dessin et des E/S de l’application. Mesure séparément l’application complète pour estimer la latence de bout en bout ou le nombre d’images par seconde.

Hailo comparé aux autres formats d’export YOLO#

Choisis un format d’export en fonction du matériel qui exécutera le modèle. Le HEF est spécifique au matériel et doit être choisi lorsque l’appareil final contient déjà un accélérateur Hailo, et non comme format edge polyvalent ou automatiquement le plus rapide.

Ne suppose pas que Hailo est plus rapide ou plus économe en énergie simplement parce qu’il s’agit d’un NPU. Pour les nouveaux déploiements M.2, DeepX est le meilleur candidat pour obtenir de meilleures performances YOLO et de meilleures performances par watt, tandis qu’Axelera vise un débit nettement supérieur avec plusieurs flux. Rockchip est une option populaire et moins coûteuse pour les SBC et les systèmes embarqués. Les valeurs TOPS et de puissance des fabricants ne sont pas directement comparables à des benchmarks applicatifs ; valide donc le même checkpoint YOLO, la même taille d’entrée, la même précision, le même hôte et le pipeline vidéo complet sur les appareils candidats avant d’acheter le matériel.

Optimiser les performances de vision par ordinateur avec Hailo#

Les choix de modèle et de pipeline comptent souvent davantage que les options du compilateur :

• Commence avec un petit modèle YOLO et augmente sa taille uniquement lorsque la précision l’exige.
• Choisis le imgsz fixe le plus bas qui préserve encore les objets importants pour l’application.
• Utilise si possible des images de calibration provenant de la caméra et de l’environnement réels.
• Garde 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 l’appareil 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 vidéo soutenues.
• Valide le HEF exporté sur l’accélérateur exact et la version de HailoRT utilisés en production.

Arguments d'exportation#

Pour l’export de détection, YOLOv8 et YOLO11 reçoivent le NMS HailoRT, tandis que YOLO26 conserve ses sorties un-à-un sans NMS. La segmentation, la pose et l’OBB utilisent les tenseurs bruts de la tête, la classification renvoie les probabilités sur puce, et la segmentation sémantique renvoie les logits bruts sur Hailo-8/8L ainsi que pour toutes les têtes à classe unique, ou des cartes de classes intégrées pour les têtes Hailo-10H/15 multiclasses. L’estimation de profondeur renvoie le logit de profondeur brut, qu’Ultralytics décode en carte de profondeur métrique lors de l’inférence. Ne passe pas end2end ; les remplacements explicites sont refusés. Les formes dynamiques, le NMS Ultralytics intégré, FP16 et FP32 ne sont pas pris en charge.

Résolution des problèmes liés à l’export Hailo#

Erreur d’importation du Hailo Dataflow Compiler#

Si l’export indique que hailo_sdk_client est manquant, installe le wheel DFC correspondant à la génération matérielle cible dans le même environnement Python qu’Ultralytics. Hailo-8/8L et Hailo-10H/15 nécessitent des générations de compilateur différentes.

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

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

L’export 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 utilisant uniquement le CPU peut être considérablement plus lente.

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

Utilise des images de calibration qui ressemblent aux entrées de production et qui 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. Même avec une bonne calibration, un écart modéré dépendant de la famille de modèles subsiste ; consulte Attentes en matière de précision par famille de modèles pour connaître les valeurs de référence mesurées.

Le HEF ne se charge pas sur l’appareil#

Vérifie que name correspond à l’architecture Hailo physique et que le pilote de l’appareil, le firmware et les paquets 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 des sorties 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 également faire correspondre le post-traitement à la famille du modèle exporté.

Résumé#

L’export Hailo d’Ultralytics fournit un chemin direct entre un modèle YOLO entraîné et 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. Effectue la calibration et la compilation localement avec le DFC correspondant, ou utilise l’export géré dans Ultralytics Platform.
4. Copie le HEF et metadata.yaml sur l’appareil edge équipé de 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 DeepX, Axelera, ONNX, OpenVINO, TensorRT, NCNN, RKNN, Sony IMX500 et Qualcomm QNN.

FAQ#