Link to this sectionExportation Hailo pour les modèles YOLO d'Ultralytics#

Les accélérateurs Hailo AI exécutent des modèles au format HEF (Hailo Executable Format) compilés sur des appareils edge tels que le Raspberry Pi AI Kit et le AI HAT+. Ultralytics exporte directement les modèles de détection, segmentation, pose, OBB, classification, segmentation sémantique et estimation de profondeur YOLO vers HEF à l'aide du compilateur 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é.

Link to this sectionPourquoi 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.

Link to this sectionComment fonctionne l'exportation Hailo#

Ultralytics possède le flux de travail d'exportation complet 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 autre chemin de sortie et de quantification. La segmentation, la pose et l'OBB de YOLOv8/YOLO11 compilent les tenseurs de tête bruts qu'Ultralytics décode lors de l'inférence, et la classification 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 YOLO26, l'exportateur suit l'accélérateur : Hailo-8/8L (DFC v3.x) renvoient les logits du classeteur 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 de logits denses en a16 et reconstruisent la carte de profondeur métrique sur l'hôte (le clamp/exp et l'étalonnage log-affine appris qui suivent la tête), de sorte que le quantificateur conserve sa plage la plus large sur le logit brut. Tu n'as pas besoin de rechercher des nœuds de fin ONNX, d'écrire un script de modèle Hailo (.alls) ou de créer manuellement un JSON NMS.

Link to this sectionInstallation#

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.

Link to this sectionExporter 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'export Hailo est uniquement en 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 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 le dispositif :

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

Link to this sectionModè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, segmentation, pose, OBB, classification, segmentation sémantique et estimation de profondeur 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 name :

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

Link to this sectionGénérations de matériel et SDK Hailo#

Les familles d'accélérateurs Hailo utilisent différentes générations de compilateur. Le HEF généré doit correspondre au matériel cible, choisis donc name pour le dispositif 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.

Link to this sectionNotes 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 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 une imgsz spécifique 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 dotés de têtes Detect standard d'Ultralytics, 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 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.

Link to this sectionCalibration 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 d'étalonnage 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 d'étalonnage : étalonner un modèle de profondeur avec des images de détection non liées aplatit la carte prédite, et des ensembles in-domain plus grands 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 partie du jeu de données utilisée pour la calibration. Davantage d'images n'aident 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 original, améliore d'abord les données de calibration avant de modifier les paramètres du modèle ou de l'exécution.

Link to this sectionAttentes 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 rétention compare les deux modèles au même seuil de confiance. Les HEF YOLOv8 et YOLO11 intègrent le conf défini lors de l'export (par défaut 0,25) dans le NMS sur puce. Ainsi, 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 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é 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é étalonnés avec l'ensemble par défaut de chaque tâche dans le domaine (COCO128-seg, COCO8-pose, DOTA128) ; la classification a été étalonnée avec ImageNet100. Deux mises en garde découlent de ces valeurs par défaut : COCO8-pose ne contient que 8 images, donc considère la pose comme indicative et transmets un data= plus grand pour la production, et DOTA8 sature le mAP50 près de 100 % pour les deux modèles, c'est pourquoi l'OBB est lu sur DOTA128. La classification est également la seule tâche où YOLO11 conserve plus que YOLOv8 ; pour les autres, l'ossature 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. Réduis conf d'environ 0,05 pour les déploiements YOLO26. La quantification décale les scores de YOLO26 vers le bas d'environ 0,05 en moyenne, donc un seuil ajusté dans PyTorch élimine des détections valides sur le HEF. Utiliser conf=0.20 sur le périphérique 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 pratiquement tout l'écart de mAP50 restant au prix de plus de détections à faible confiance. La quantification reclasse également environ 20 % des détections — un effet d'ordre permanent qu'aucun seuil n'annule — mais ce remaniement ne bloque 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 se compilent en opérations matmul qui conservent les entrées d'activation INT8 dans tous les modes proposés par le compilateur ; le mode de sortie 16 bits échoue à l'allocation pour ce graphe, et augmenter la précision des couches environnantes n'aide pas car le matmul requantifie ses entrées en INT8 de toute façon (protéger les convolutions en profondeur 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 est interchangeable, YOLO11 se quantifie actuellement mieux que YOLO26 ici ; les générations Hailo plus récentes (DFC 5.x) exposent plus d'options de précision mixte et peuvent différer.

Link to this sectionArtefacts 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 conserve les noms de modèle, la tâche, la taille d'entrée, le pas et les informations de 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 hors détection (segmentation, pose, OBB, classification, sémantique) n'utilisent pas ce fichier.

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

Link to this sectionExécuter l'inférence sur le matériel Hailo#

Installe HailoRT sur le dispositif cible. Les utilisateurs de Raspberry Pi AI Kit et AI HAT+ peuvent suivre le guide logiciel Raspberry Pi AI :

sudo apt install hailo-all
hailortcli fw-control identify

Copie le répertoire d'export complet sur ton appareil afin que metadata.yaml reste à côté du fichier 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 un-à-un de YOLO26. Il décode les tenseurs bruts de segmentation, pose et OBB, renvoie les probabilités de classification sur puce et produit des cartes de classe sémantiques via une réduction hôte sur Hailo-8/8L et toutes les têtes mono-classe ou via un ArgMax sur puce pour les têtes multi-classes Hailo-10/15. TAPPAS, GStreamer et l'assistant Raspberry Pi picamera2.devices.Hailo 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

Link to this sectionOptions 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 classe, de la taille d'entrée, du stride ou d'autres informations sur le modèle Ultralytics. Le fichier HEF lui-même ne remplace pas la logique au niveau de l'application pour la capture caméra, la visualisation, le suivi, les alertes ou le stockage.

Link to this sectionVé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.

Link to this sectionHailo 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.

Link to this sectionOptimiser 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 plus petite valeur imgsz fixe qui préserve les objets importants pour ton 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.

Link to this sectionArguments d'exportation#

Pour l'exportation de détection, YOLOv8 et YOLO11 reçoivent HailoRT NMS, 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 à l'inférence. Ne passe pas end2end ; les remplacements explicites sont rejetés. Les formes dynamiques, les lots supérieurs à un, le NMS Ultralytics intégré, FP16 et FP32 ne sont également pas pris en charge.

Link to this sectionDépannage de l'exportation Hailo#

Link to this sectionErreur d'importation du Hailo Dataflow Compiler#

Si l'exportation signale que hailo_sdk_client est manquant, installe le wheel 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.

Link to this sectionSystème d'exploitation ou architecture non pris en charge#

La compilation HEF est prise en charge sur Linux x86_64. Exporte 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.

Link to this sectionL'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.

Link to this sectionLa précision du modèle quantifié chute#

Utilise des images de calibrage 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 original 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 un bon calibrage ; voir Attentes de précision par famille de modèles pour les références mesurées.

Link to this sectionLe HEF ne se charge pas sur le périphérique#

Confirme que name correspond à l'architecture Hailo physique et que le pilote du périphérique, 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.

Link to this sectionL'analyse de la sortie semble incorrecte#

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

Link to this sectionFAQ#

Link to this sectionPuis-je compiler un HEF sur un Raspberry Pi ?#

Non. Exécute le DFC sur un système Linux x86_64 pris en charge et déploie le HEF résultant sur le Raspberry Pi.

Link to this sectionAi-je besoin d'un GPU NVIDIA ?#

Un GPU pris en charge réduit considérablement le temps d'optimisation DFC. La compilation sur CPU est possible mais peut prendre beaucoup plus de temps.

Link to this sectionQuels modèles YOLO prennent en charge l'exportation Hailo ?#

L'exportation directe prend en charge les modèles de détection dotés de la tête de détection standard YOLOv8, YOLO11 ou YOLO26, les modèles de segmentation, de pose et d'OBB YOLOv8/YOLO11, ainsi que les modèles de classification YOLOv8/YOLO11/YOLO26. Cela inclut les modèles entraînés sur mesure construits à partir de ces architectures standard. Les modèles de segmentation sémantique et d'estimation de profondeur YOLO26 sont également pris en charge. La segmentation d'instances, la pose et l'OBB YOLO26, ainsi que YOLOv10, YOLO-World, YOLOE et RT-DETR sont rejetés au lieu de produire un HEF non validé.

Link to this sectionPuis-je exporter un modèle YOLO entraîné sur mesure ?#

Oui. Utilise la même commande format="hailo" avec les poids .pt personnalisés et passe le YAML du jeu de données d'entraînement via data pour une calibration INT8 représentative. Les noms de classe et le nombre de classes sont lus à partir des métadonnées du modèle.

Link to this sectionL'exportation Hailo prend-elle en charge les tailles d'image dynamiques ?#

Non. Le DFC compile une forme d'entrée fixe dans le HEF. Choisis imgsz lors de l'exportation pour correspondre à la résolution utilisée par le pipeline de déploiement.

Link to this sectionPourquoi YOLO26 produit-il des sorties Hailo différentes ?#

YOLO26 utilise une tête de détection sans NMS. Ultralytics compile ces tenseurs de sortie directement au lieu d'attacher le NMS de style YOLOv8 utilisé pour YOLOv8 et YOLO11.

Link to this sectionQuelle est la différence entre le DFC et HailoRT ?#

Le Hailo Dataflow Compiler convertit et quantifie le modèle en un HEF spécifique au matériel sur une machine de construction Linux x86_64. HailoRT charge et exécute ce HEF sur le périphérique cible.

Link to this sectionDois-je déployer le fichier ONNX ou HEF ?#

Déploie le HEF compilé vers le runtime Hailo. ONNX est une représentation intermédiaire utilisée lors de l'exportation et est supprimée après une compilation réussie.

Link to this sectionOù puis-je obtenir le DFC Hailo ?#

Télécharge le wheel du compilateur pour ta génération de matériel depuis la zone développeur Hailo. Le compilateur est requis uniquement pour créer le HEF ; HailoRT l'exécute sur l'accélérateur cible.

Link to this sectionRé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 le périphérique 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 de vision par ordinateur, consulte Mode Export, Mode Benchmark, et le guide d'intégrations. Les guides matériels associés incluent ONNX, OpenVINO, TensorRT, NCNN, RKNN, Sony IMX500 et Qualcomm QNN.