Exportation vers Hailo pour les modèles YOLO Ultralytics#

Les accélérateurs d’IA Hailo exécutent des modèles compilés au format exécutable Hailo (HEF) sur des appareils en périphérie tels que le AI HAT+ pour Raspberry Pi et 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 de boîtes englobantes orientées (OBB), à l’aide du compilateur de flux de données Hailo (DFC).

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

Pourquoi déployer Ultralytics YOLO sur Hailo ?#

Associer Ultralytics YOLO à une unité de traitement neuronal (NPU) Hailo offre une voie pratique entre l’entraînement du modèle et l’inférence IA en périphérie. Les cas d’utilisation courants comprennent :

• 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 les applications de sécurité, de commerce de détail, de circulation et de suivi de l’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 continue au cloud.
• 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 d’IA sur Raspberry Pi : ajoute l’inférence visuelle accélérée aux systèmes Raspberry Pi à l’aide de l’AI HAT+ ou de l’AI HAT+ 2.
• 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 dans le 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 électrique 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 gère l’ensemble du workflow d’export derrière format="hailo" :

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

L’exporteur 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. Crée 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 fichier 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é. YOLO26 compile les tenseurs bruts de la tête de détection : Ultralytics applique NMS aux sorties one-to-many par défaut, ou décode les sorties one-to-one sans NMS avec nms=False. Les modèles de segmentation, de pose et OBB YOLOv8/YOLO11 compilent les tenseurs bruts de la tête, qu’Ultralytics décode lors de l’inférence, et la classification YOLOv8/YOLO11/YOLO26 exécute softmax sur la puce afin que le fichier HEF renvoie directement les probabilités des classes. Pour la segmentation sémantique YOLO26, l’exporteur 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 sur la puce des têtes ArgMax multiclasse et renvoient une carte de classes compacte. 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 que 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 (l’opération clamp/exp et l’étalonnage log-affine appris qui suivent la tête), afin que le quantificateur conserve sa plage la plus large sur les logits bruts. Il n’est pas nécessaire de trouver 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 le 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 HEF Hailo#

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 utilise uniquement INT8. Ultralytics télécharge automatiquement un jeu de données de calibration adapté à la tâche si 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 en vision par ordinateur, mais l’exporteur 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 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 par la voie Ultralytics format="hailo". Ultralytics rejette ces tâches et familles de modèles avant la compilation au lieu de produire un fichier HEF non validé.

La pose, 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’exporteur accepte les autres cibles répertoriées, mais ces nouvelles voies de traitement 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 de 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 fichier HEF généré doit correspondre au matériel cible ; choisis donc name en fonction de l’appareil qui exécutera l’inférence, et non de la machine qui effectue l’export.

Le compilateur s’exécute sous Linux x86_64, tandis que le fichier 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 de périphérie ARM ou x86.

Remarques sur la compatibilité#

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

• 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 fichier 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 fichier HEF distinct pour chaque résolution.
• 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 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 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 du DFC et ne sont pas interchangeables.

Calibration et quantification INT8#

L’export 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’annotations pendant la compilation.

Lorsque data est omis, Ultralytics utilise un jeu de données léger d’étalonnage propre à 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 d’étalonnage : étalonner un modèle de profondeur avec des images de détection sans rapport aplatit la carte prédite, et des jeux de données plus grands et du même domaine améliorent la fidélité. Pour un modèle de vision par ordinateur personnalisé, indique le YAML du jeu de données avec data 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 l’étalonnage. Les listes [train, val, test] définissent une limite pour chaque sous-ensemble, les listes de deux éléments laissent test complet, et 0 ignore test. Un plus grand nombre 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 après quantification 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 d’étalonnage avant de modifier les paramètres du modèle ou de l’environnement d’exécution.

Attentes en matière de précision selon la famille de modèles#

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

La rétention compare les deux modèles au même seuil de confiance. Les HEF YOLOv8 et YOLO11 intègrent le conf du moment de l’export (0.25 par défaut) à la NMS sur puce. Ainsi, les valider par rapport à une référence PyTorch avec son seuil bas par défaut prend en compte une plus grande partie de la courbe précision-rappel et surestime l’écart dû à la quantification.

Au-delà de la détection, les chemins d’export pour la segmentation, la pose, les 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 le même sous-ensemble de validation, avec un étalonnage dans le domaine :

La segmentation, la pose et les OBB ont été étalonnés avec le jeu par défaut de chaque tâche et du même domaine (COCO128-seg, COCO8-pose, DOTA128) ; la classification a été étalonnée avec ImageNet100. Ces paramètres par défaut impliquent deux réserves : COCO8-pose ne contient que 8 images ; considère donc la pose comme indicative et fournis un data= plus grand pour la production. DOTA8 atteint un plateau de mAP50 proche de 100 % pour les deux modèles, c’est pourquoi les OBB sont évalués sur DOTA128. La classification est aussi la seule tâche où YOLO11 conserve une meilleure précision que YOLOv8 ; pour les autres tâches, le backbone d’attention de YOLO11 est plus sensible à INT8.

Les mesures sur l’appareil permettent de dégager trois règles pratiques :

1. Effectue toujours l’étalonnage dans le domaine. Un affinage avec des images hors domaine revient à ne pas effectuer d’affinage : un YOLO26n étalonné avec 1,238 image hors domaine conserve la même précision (85.7 %) qu’un modèle compilé sans affinage. Un petit jeu de données du domaine vaut mieux qu’un grand jeu de données hors domaine.
2. Réduis conf d’environ 0.05 pour les déploiements YOLO26. La quantification abaisse les scores de YOLO26 d’environ 0.05 en moyenne ; un seuil réglé dans PyTorch écarte donc des détections valides sur le HEF. Utiliser conf=0.20 sur l’appareil donne le même nombre de détections que PyTorch avec conf=0.25, et le réduire encore légèrement (aux alentours de conf=0.15) permet de récupérer pratiquement tout l’écart de mAP50 restant, au prix d’un plus grand nombre de détections à faible confiance. La quantification réordonne aussi environ 20 % des détections — un effet de classement permanent qu’aucun seuil ne peut annuler — mais ce réagencement n’empêche pas de récupérer la mAP50 avec un seuil plus bas.
3. La pénalité liée à l’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 ces opérations ; le mode de sortie 16 bits échoue à l’allocation pour ce graphe, et augmenter la précision des couches environnantes ne sert à rien, car le produit matriciel 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é la mAP dans nos tests). Lorsque la précision est prioritaire et que le modèle peut être remplacé par un autre, YOLO11 se quantifie actuellement mieux que YOLO26 sur cet appareil ; les générations Hailo plus récentes (DFC 5.x) offrent davantage d’options de précision mixte et peuvent donner des résultats différents.

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 de modèles, la tâche, la taille d’entrée, le stride et les informations sur la cible Hailo.
• nms_config.json consigne 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, 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 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 l’AI HAT+ (Hailo-8 / Hailo-8L) :

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

Pour l’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 pour que metadata.yaml reste à côté du HEF. Ultralytics utilise HailoRT pour exécuter directement predict et val 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/YOLO11 et décode automatiquement l’une ou l’autre des têtes YOLO26. Leurs sorties par défaut one-to-many passent par la NMS du prédicteur. Il décode les tenseurs bruts de segmentation, de pose et d’OBB, renvoie les probabilités de classification calculées sur la puce et génère les cartes de classes sémantiques au moyen d’une réduction sur l’hôte pour Hailo-8/8L et toutes les têtes à classe unique, ou d’un ArgMax sur puce pour les têtes multi-classes Hailo-10H/15. TAPPAS, GStreamer et l’utilitaire picamera2.devices.Hailo de Raspberry Pi restent disponibles pour les pipelines propres à une application.

Pour un déploiement GStreamer, transmets 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 d’exécution Hailo. Choisis l’interface adaptée à l’application :

Conserve metadata.yaml avec le HEF si l’application a besoin des noms de classes, de la taille d’entrée, du stride ou d’autres informations du modèle Ultralytics. Le HEF ne remplace pas la logique au niveau de l’application pour la capture par caméra, la visualisation, le suivi, les alertes ou le stockage.

Vérifier l’appareil Hailo et le HEF#

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

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

Les mesures de performances sur l’appareil seul 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.

Benchmarks#

L’équipe Ultralytics a réalisé des benchmarks des modèles YOLO26, en comparant la vitesse et la précision entre PyTorch et Hailo.

Performances

Raspberry Pi 5 + AI HAT+ (Hailo-8)D’autres appareils arrivent bientôt !

Modèle	Format	Statut	Taille (Mo)	metrics/mAP50-95(B)	Temps d’inférence (ms/im)
YOLO26n	PyTorch	✅	5.3	0.477	364.6
YOLO26n	Hailo	✅	7.3	0.455	21.7

Modèle	Format	Statut	Taille (Mo)	metrics/mIoU	Temps d’inférence (ms/im)
YOLO26n-sem	PyTorch	✅	3.3	0.611	831.2
YOLO26n-sem	Hailo	✅	6.2	0.611	34.8

Modèle	Format	Statut	Taille (Mo)	metrics/delta1	metrics/abs_rel	metrics/rmse	Temps d’inférence (ms/im)
YOLO26n-depth	PyTorch	✅	12.4	0.8535	0.0983	0.2047	2133.4
YOLO26n-depth	Hailo	✅	9.9	0.8241	0.1232	0.2554	29.6

Modèle	Format	Statut	Taille (Mo)	précision (top1)	précision (top5)	Temps d’inférence (ms/im)
YOLO26n-cls	PyTorch	✅	5.5	0.431	0.716	33.8
YOLO26n-cls	Hailo	✅	3.5	0.441	0.716	2.0

Remarque

La validation des benchmarks ci-dessus a été effectuée avec COCO128 pour la détection, Cityscapes8 pour la segmentation sémantique, Depth8 pour l’estimation de profondeur et ImageNet100 pour la classification. Cityscapes8 et Depth8 ne contiennent que 4 images de validation chacun ; considère donc les valeurs de précision pour la segmentation sémantique et la profondeur comme des résultats de tests rapides, et non comme des mesures de maintien de la précision ; valide les résultats sur un jeu de données complet tel que Cityscapes ou NYU Depth V2 avant de tirer des conclusions sur la précision. Le temps d’inférence n’inclut pas le prétraitement ni le post-traitement.

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 propre au matériel et doit être choisi lorsque l’appareil cible contient déjà un accélérateur Hailo, et non comme format généraliste ou automatiquement le plus rapide pour l’edge.

Ne pars pas du principe que Hailo est plus rapide ou plus économe en énergie au seul motif qu’il s’agit d’un NPU. Pour les nouveaux déploiements M.2, DeepX est un candidat plus intéressant 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 économique populaire pour les SBC et les systèmes embarqués. Les valeurs TOPS et de puissance des fournisseurs ne sont pas directement comparables à des mesures de performances applicatives ; avant d’acheter du matériel, valide donc les mêmes checkpoint YOLO, taille d’entrée, précision, hôte et pipeline vidéo complet sur les appareils envisagés.

Optimiser les performances de la vision par ordinateur sur Hailo#

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

• Commence par un petit modèle YOLO et n’augmente sa taille que si la précision l’exige.
• Choisis la valeur fixe la plus basse de imgsz qui préserve tout de même les objets importants pour l’application.
• Dans la mesure du possible, utilise des images d’étalonnage provenant de la véritable caméra et de l’environnement réel.
• 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 comme GStreamer pour les charges vidéo soutenues.
• Valide le HEF exporté sur l’accélérateur exact et avec la version de HailoRT utilisés en production.

Arguments d’exportation#

Les exports de détection YOLOv8/YOLO11 appliquent NMS HailoRT. YOLO26 produit par défaut des sorties brutes one-to-many pour la NMS sur l’hôte ; nms=False sélectionne ses sorties one-to-one sans NMS. La segmentation, la pose et OBB utilisent les tenseurs bruts des têtes, la classification renvoie des probabilités calculées sur la puce, et la segmentation sémantique renvoie les logits bruts sur Hailo-8/8L et toutes les têtes à classe unique, ou des cartes de classes précalculées pour les têtes Hailo-10H/15 multiclasses. L’estimation de profondeur renvoie le logit brut de profondeur, qu’Ultralytics décode en carte de profondeur métrique lors de l’inférence. Les formes dynamiques, la NMS Ultralytics intégrée, FP16 et FP32 ne sont pas pris en charge.

Dépannage de l’export Hailo#

Erreur d’importation de 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. Passe par Ultralytics Platform ou utilise une station de travail compatible si ton ordinateur local fonctionne sous 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. La durée 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 sur CPU peut être nettement plus lente.

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

Utilise des images de calibration similaires aux entrées de production et incluant les objets, échelles, conditions d’éclairage et arrière-plans importants. Compare le modèle PyTorch d’origine et le HEF exporté sur le même jeu de validation avant le déploiement. Même avec une bonne calibration, un écart modéré, qui dépend de la famille du modèle, subsiste ; consulte Précision attendue selon la 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 packages HailoRT sont compatibles entre eux. 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#

Garde metadata.yaml à côté du HEF afin qu’Ultralytics puisse sélectionner le chemin de post-traitement correspondant à YOLOv8, YOLO11 ou YOLO26. Les applications HailoRT personnalisées doivent elles aussi adapter le post-traitement à la famille du modèle exporté.

Résumé#

L’export Hailo d’Ultralytics offre 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 OBB YOLOv8/YOLO11, ou un modèle YOLO26 de segmentation sémantique ou d’estimation de profondeur.
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. Lance 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 le mode Export, le mode Benchmark et le guide des intégrations. Parmi les guides matériels associés, tu trouveras DeepX, Axelera, ONNX, OpenVINO, TensorRT, NCNN, RKNN, Sony IMX500 et Qualcomm QNN.

FAQ#