Link to this sectionEsportazione Hailo per modelli Ultralytics YOLO#

Gli acceleratori AI Hailo eseguono modelli compilati in formato HEF (Hailo Executable Format) su dispositivi edge come il Raspberry Pi AI Kit e l'AI HAT+. Ultralytics esporta modelli di rilevamento, segmentazione, posa, OBB, classificazione, segmentazione semantica e stima della profondità YOLO direttamente in HEF con il compilatore Hailo Dataflow Compiler (DFC).

Il deployment su Hailo è progettato per la computer vision all'edge: telecamere, robot, sistemi industriali, gateway e altri dispositivi che necessitano di un rilevamento di oggetti in locale senza inviare ogni frame al cloud. Un HEF compilato contiene la rete quantizzata, l'allocazione hardware, la pianificazione e l'eventuale post-elaborazione HailoRT necessaria per l'acceleratore selezionato.

Link to this sectionPerché effettuare il deployment di Ultralytics YOLO su Hailo?#

Combinare Ultralytics YOLO con una neural processing unit (NPU) Hailo fornisce un percorso pratico dall'addestramento del modello all'inferenza AI edge a basso consumo. I casi d'uso comuni includono:

• Telecamere intelligenti e video analisi: esegui il rilevamento di oggetti in tempo reale vicino alla telecamera per applicazioni di sicurezza, vendita al dettaglio, traffico e rilevamento occupazione.
• Robotica e sistemi autonomi: rileva persone, veicoli, pacchi, strumenti o ostacoli senza dipendere da una connessione cloud continua.
• Computer vision industriale: esegui il deployment di modelli YOLO personalizzati per ispezione, conteggio, monitoraggio della sicurezza e controllo qualità.
• Progetti Raspberry Pi AI: aggiungi l'inferenza di visione accelerata ai sistemi Raspberry Pi utilizzando l'AI Kit o l'AI HAT+.
• Edge gateway e PC AI: elabora flussi video o di sensori multipli localmente riducendo i requisiti di larghezza di banda e di calcolo cloud.

L'inferenza locale può migliorare la privacy e il tempo di risposta poiché le immagini rimangono sul dispositivo di deployment. Il throughput effettivo, la latenza e il consumo energetico dipendono dalla dimensione del modello YOLO, dalla risoluzione dell'input, dall'architettura Hailo, dal sistema host e dalla pipeline dell'applicazione.

Link to this sectionCome funziona l'esportazione Hailo#

Ultralytics gestisce l'intero flusso di lavoro di esportazione dietro format="hailo":

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

L'esportatore esegue automaticamente queste fasi:

1. Esporta un grafo ONNX statico con impostazioni compatibili con il compilatore.
2. Seleziona gli output della head per l'architettura del modello.
3. Genera direttive di normalizzazione, attivazione e post-elaborazione.
4. Crea un flusso di calibrazione rappresentativo e quantizza il modello in INT8.
5. Compila il grafo ottimizzato per l'acceleratore Hailo selezionato.
6. Salva l'HEF con i metadati Ultralytics e rimuove il file ONNX intermedio.

I modelli di rilevamento YOLOv8 e YOLO11 utilizzano HailoRT YOLO NMS nella pipeline compilata. I modelli di rilevamento YOLO26 utilizzano le loro uscite uno-a-uno senza NMS, quindi l'esportatore seleziona automaticamente un percorso di output e quantizzazione diverso. La segmentazione, la posa e l'OBB di YOLOv8/YOLO11 compilano i tensori della testa grezza, che Ultralytics decodifica durante l'inferenza, e la classificazione di YOLOv8/YOLO11/YOLO26 esegue il softmax on-chip in modo che l'HEF restituisca direttamente le probabilità delle classi. Per la segmentazione semantica di YOLO26, l'esportatore segue l'acceleratore: Hailo-8/8L (DFC v3.x) restituiscono i logit del classificatore per l'upsampling e la riduzione sull'host, mentre Hailo-10/15 (DFC v5.x) compilano le teste ArgMax multi-classe on-chip e restituiscono una mappa di classe compatta. Le teste a classe singola utilizzano il percorso del logit host su ogni target perché richiedono una soglia anziché ArgMax. I modelli di profondità YOLO26 compilano la convoluzione del logit denso in a16 e ricostruiscono la mappa di profondità metrica sull'host (clamp/exp e calibrazione log-affine appresa che seguono la testa), in modo che il quantizzatore mantenga il suo intervallo più ampio sul logit grezzo. Gli utenti non devono trovare nodi finali ONNX, scrivere uno script del modello Hailo (.alls) o creare manualmente un JSON NMS.

Link to this sectionInstallazione#

Installa Ultralytics e scarica il wheel DFC per il tuo hardware di destinazione dalla Hailo Developer Zone (è richiesta la registrazione gratuita):

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

Hailo-8 e Hailo-8L utilizzano DFC v3.x. Hailo-10 e Hailo-15 utilizzano DFC v5.x. Installa la generazione del compilatore che corrisponde all'acceleratore di destinazione.

Link to this sectionEsporta un modello HEF Hailo#

Usa format="hailo" e seleziona l'acceleratore di destinazione con name:

from ultralytics import YOLO

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

Il comando CLI equivalente è:

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

L'esportazione Hailo è solo INT8. Ultralytics scarica automaticamente un set di dati di calibrazione specifico per il compito quando data non viene fornito. Per modelli personalizzati, utilizza immagini di addestramento o validazione rappresentative:

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

La compilazione utilizza una forma di input fissa. Imposta imgsz sulla risoluzione utilizzata sul dispositivo:

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

Link to this sectionModelli e hardware supportati#

L'ecosistema Hailo copre un'ampia gamma di carichi di lavoro di computer vision, ma l'esportatore Ultralytics format="hailo" convalida attualmente le teste standard di rilevamento, segmentazione, posa, OBB, classificazione, segmentazione semantica e stima della profondità YOLO. La tabella delle attività descrive i percorsi di esportazione disponibili; la convalida dell'hardware è elencata separatamente di seguito.

Famiglie di rilevamento specializzate come YOLOv10, YOLO-World, YOLOE e RT-DETR sono anch'esse ❌ non supportate. Ultralytics rifiuta queste attività e famiglie di modelli prima della compilazione invece di produrre un HEF non convalidato.

Posa, OBB, classificazione, segmentazione semantica YOLO26 e stima della profondità YOLO26 (percorso Hailo-8/8L) sono stati convalidati su Hailo-8L con HailoRT 4.23 e DFC 3.33. L'esportatore accetta gli altri target elencati, ma quei nuovi percorsi di attività richiedono la convalida con il compilatore e il dispositivo corrispondenti prima dell'uso in produzione.

Seleziona uno di questi valori name:

hailo8l è l'impostazione predefinita. Installa la generazione DFC che corrisponde alla destinazione selezionata.

Link to this sectionGenerazioni di hardware e SDK Hailo#

Le famiglie di acceleratori Hailo utilizzano diverse generazioni di compilatori. L'HEF generato deve corrispondere all'hardware di destinazione, quindi scegli name per il dispositivo che eseguirà l'inferenza piuttosto che per la macchina che esegue l'esportazione.

Il compilatore viene eseguito su Linux x86_64, mentre l'HEF risultante viene eseguito sul dispositivo Hailo tramite HailoRT. Questa separazione ti consente di compilare su una workstation o nella Ultralytics Platform e di distribuire il piccolo artefatto runtime su un host edge ARM o x86.

Link to this sectionNote sulla compatibilità#

La compilazione Hailo è specifica per l'hardware e utilizza una forma di input fissa. Tieni a mente questi vincoli:

• Il name selezionato deve corrispondere all'acceleratore di deployment.
• Le immagini di calibrazione dovrebbero rappresentare l'illuminazione, i punti di vista, gli oggetti e gli sfondi previsti in produzione.
• Un HEF compilato con un imgsz non diventa ridimensionabile dinamicamente durante il runtime.
• I conteggi delle classi personalizzate sono supportati poiché Ultralytics genera la configurazione di post-elaborazione dai metadati del modello.
• Sono supportati i modelli di rilevamento con teste Detect standard di Ultralytics, i modelli di segmentazione, posa e OBB di YOLOv8/YOLO11, i modelli di classificazione di YOLOv8/YOLO11/YOLO26 e i modelli di segmentazione semantica e stima della profondità di YOLO26; la segmentazione di istanze, la posa e il bounding box orientato di YOLO26, insieme alle esportazioni di YOLO-World, YOLOE, YOLOv10 e RT-DETR, non sono attualmente supportati.
• Gli artefatti Hailo-8/8L e Hailo-10/15 sono compilati da diverse generazioni di DFC e non sono intercambiabili.

Link to this sectionCalibrazione e quantizzazione INT8#

L'esportazione Hailo HEF utilizza la quantizzazione INT8 per mappare la rete YOLO in modo efficiente sull'acceleratore. Il dataset di calibrazione stima gli intervalli di attivazione; non riaddestra il modello né richiede etichette durante la compilazione.

Quando data viene omesso, Ultralytics utilizza un set di dati di calibrazione leggero specifico per l'attività, come COCO128 per il rilevamento, cityscapes8 per la segmentazione semantica o depth8 per la stima della profondità. La testa di profondità densa è particolarmente sensibile al dominio di calibrazione: calibrare un modello di profondità con immagini di rilevamento non correlate appiattisce la mappa prevista, e set in-domain più ampi migliorano la fedeltà. Per un modello di computer vision personalizzato, punta data al suo YAML del set di dati in modo che il compilatore osservi immagini rappresentative dal dominio di distribuzione effettivo:

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

fraction seleziona la porzione di dataset utilizzata per la calibrazione. Più immagini aiutano solo se rappresentano il dominio di implementazione; immagini fuori dominio possono ridurre l'accuratezza quantizzata e aumentare il tempo di ottimizzazione. Se l'HEF INT8 perde accuratezza rispetto al modello PyTorch originale, migliora prima i dati di calibrazione prima di modificare le impostazioni del modello o del runtime.

Link to this sectionAspettative di accuratezza per famiglia di modelli#

Misurati su un Hailo-8L con calibrazione in-domain (COCO128, 128 immagini), gli export HEF in INT8 mantengono la seguente quota del loro mAP50 PyTorch sotto lo stesso protocollo di valutazione:

La ritenzione confronta entrambi i modelli alla stessa soglia di confidenza. Gli HEF di YOLOv8 e YOLO11 incorporano il conf in fase di export (default 0.25) nell'NMS on-chip, quindi convalidare rispetto a un baseline PyTorch alla sua soglia bassa predefinita integra una parte maggiore della curva precision-recall e sovrastima il gap di quantizzazione.

Oltre al rilevamento, i percorsi di esportazione per segmentazione, posa, OBB e classificazione sono stati validati sullo stesso Hailo-8L (DFC 3.33, HailoRT 4.23). Ogni HEF INT8 è stato confrontato con il relativo checkpoint PyTorch sullo stesso split di validazione, utilizzando una calibrazione in-domain:

Segmentazione, posa e OBB sono stati calibrati con il set in-domain predefinito per ogni attività (COCO128-seg, COCO8-pose, DOTA128); la classificazione è stata calibrata con ImageNet100. Due avvertenze derivano da tali impostazioni predefinite: COCO8-pose contiene solo 8 immagini, quindi considera la posa come indicativa e passa un data= più ampio per la produzione; inoltre DOTA8 satura l'mAP50 vicino al 100% per entrambi i modelli, motivo per cui l'OBB viene letto su DOTA128. La classificazione è anche l'unica attività in cui YOLO11 mantiene di più rispetto a YOLOv8; per le altre, il backbone con attenzione di YOLO11 è più sensibile all'INT8.

Dalle misurazioni sui dispositivi derivano tre regole pratiche:

1. Calibra sempre in-domain. Il fine-tuning con immagini out-of-domain equivale a disabilitarlo completamente: uno YOLO26n calibrato con 1.238 immagini out-of-domain mantiene la stessa accuratezza (85.7%) di uno compilato senza fine-tuning. Un piccolo set in-domain supera uno grande out-of-domain.
2. Abbassa conf di circa 0,05 per i deployment di YOLO26. La quantizzazione sposta i punteggi di YOLO26 verso il basso di circa 0,05 in media, quindi una soglia ottimizzata in PyTorch causa la perdita di rilevamenti validi sull'HEF. L'uso di conf=0.20 sul dispositivo corrisponde al conteggio dei rilevamenti di PyTorch a conf=0.25, e abbassarlo leggermente ancora (intorno a conf=0.15) recupera praticamente tutto il gap rimanente di mAP50 a costo di più rilevamenti a bassa confidenza. La quantizzazione inoltre riordina circa il 20% dei rilevamenti — un effetto di ordinamento permanente che nessuna soglia può annullare — ma tale rimescolamento non impedisce il recupero dell'mAP50 alla soglia inferiore.
3. La penalità dell'attenzione è strutturale su Hailo-8/8L (DFC 3.33). I blocchi di attenzione vengono compilati in operazioni matmul che mantengono input di attivazione INT8 in ogni modalità offerta dal compilatore; la modalità di output a 16-bit fallisce l'allocazione per questo grafo, e aumentare la precisione dei layer circostanti non aiuta perché la matmul riquantizza comunque i suoi input in INT8 (proteggere le convoluzioni depthwise e di output a 16-bit non ha cambiato il mAP nei nostri test). Quando l'accuratezza è la priorità e il modello è intercambiabile, YOLO11 attualmente si quantizza meglio di YOLO26 in questo caso; le generazioni Hailo più recenti (DFC 5.x) espongono più opzioni a precisione mista e potrebbero differire.

Link to this sectionArtefatti esportati#

L'esportazione crea una directory contenente l'HEF distribuibile e i metadati Ultralytics:

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

• *.hef è il modello compilato caricato da HailoRT.
• metadata.yaml conserva i nomi del modello, l'attività, la dimensione dell'input, lo stride e le informazioni sulla destinazione Hailo.
• nms_config.json registra la configurazione NMS di HailoRT generata per i modelli di rilevamento YOLOv8 e YOLO11. Il rilevamento YOLO26 e tutti i compiti non di rilevamento (segmentazione, pose, OBB, classificazione, semantica) non utilizzano questo file.

Il grafo ONNX intermedio viene rimosso dopo la compilazione.

Link to this sectionEsegui l'inferenza su hardware Hailo#

Installa HailoRT sul dispositivo di destinazione. Gli utenti di Raspberry Pi AI Kit e AI HAT+ possono seguire la guida software Raspberry Pi AI:

sudo apt install hailo-all
hailortcli fw-control identify

Copia l'intera directory di esportazione sul dispositivo in modo che metadata.yaml rimanga accanto all'HEF. Ultralytics utilizza HailoRT per eseguire predict e val direttamente sulla directory esportata:

from ultralytics import YOLO

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

Per i modelli di rilevamento, il backend converte automaticamente l'output NMS HailoRT di YOLOv8 e YOLO11 e decodifica le uscite one-to-one di YOLO26. Decodifica i tensori raw di segmentazione, pose e OBB, restituisce probabilità di classificazione on-chip e produce mappe di classe semantica tramite riduzione host su Hailo-8/8L e tutte le teste a classe singola, o un ArgMax on-chip per teste Hailo-10/15 multi-classe. TAPPAS, GStreamer e l'helper Raspberry Pi picamera2.devices.Hailo rimangono disponibili per pipeline specifiche dell'applicazione.

Per un deployment GStreamer, passa l'HEF a 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 sectionOpzioni di deployment Hailo#

L'HEF è lo stesso artefatto di modello distribuibile su diverse interfacce runtime Hailo. Scegli l'interfaccia adatta all'applicazione:

Mantieni metadata.yaml con l'HEF quando l'applicazione richiede i nomi delle classi, la dimensione di input, lo stride o altre informazioni sul modello di Ultralytics. L'HEF in sé non sostituisce la logica a livello di applicazione per l'acquisizione della fotocamera, la visualizzazione, il tracciamento, gli avvisi o l'archiviazione.

Link to this sectionVerifica il dispositivo Hailo e l'HEF#

Prima di integrare una fotocamera o una pipeline video, verifica il runtime e l'acceleratore in modo indipendente:

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

Le misurazioni delle prestazioni del solo dispositivo isolano l'inferenza Hailo dalla decodifica video, dal ridimensionamento dell'immagine, dal disegno e dall'I/O dell'applicazione. Misura l'applicazione completa separatamente quando stimi la latenza end-to-end o i fotogrammi al secondo.

Link to this sectionConfronto di Hailo con altri formati di esportazione YOLO#

Scegli un formato di esportazione basato sull'hardware che eseguirà il modello:

HEF è la scelta corretta quando il dispositivo finale contiene un acceleratore Hailo. ONNX rimane utile come formato di interscambio portabile, ma HailoRT esegue l'HEF specifico per l'hardware prodotto dal DFC anziché il modello ONNX originale.

Link to this sectionOttimizza le prestazioni della computer vision su Hailo#

Le scelte relative al modello e alla pipeline contano spesso più dei flag del compilatore:

• Inizia con un modello YOLO piccolo e aumenta la dimensione del modello solo quando la precisione lo richiede.
• Scegli il imgsz fisso più basso che preservi comunque gli oggetti importanti per l'applicazione.
• Usa immagini di calibrazione dalla fotocamera e dall'ambiente reali quando possibile.
• Mantieni la rete Hailo attiva tra un fotogramma e l'altro invece di riaprire l'HEF per ogni inferenza.
• Separa il tempo di inferenza del dispositivo dalla pre-elaborazione, dalla decodifica video, dalla post-elaborazione, dalla visualizzazione e dall'I/O di rete.
• Usa una pipeline di streaming come GStreamer per carichi di lavoro video sostenuti.
• Convalida l'HEF esportato sull'acceleratore esatto e sulla versione di HailoRT utilizzata in produzione.

Link to this sectionArgomenti di esportazione#

Per l'esportazione del rilevamento, YOLOv8 e YOLO11 ricevono HailoRT NMS, mentre YOLO26 mantiene le sue uscite uno-a-uno senza NMS. Segmentazione, posa e OBB utilizzano tensori della testa grezza, la classificazione restituisce probabilità on-chip e la segmentazione semantica restituisce logit grezzi su Hailo-8/8L e tutte le teste a classe singola o mappe di classe incorporate per teste multi-classe Hailo-10/15. La stima della profondità restituisce il logit di profondità grezzo, che Ultralytics decodifica in una mappa di profondità metrica durante l'inferenza. Non passare end2end; gli override espliciti vengono rifiutati. Non sono inoltre supportati forme dinamiche, batch superiori a uno, NMS Ultralytics incorporato, FP16 e FP32.

Link to this sectionRisoluzione dei problemi di esportazione Hailo#

Link to this sectionErrore di importazione del compilatore Hailo Dataflow#

Se l'esportazione segnala che hailo_sdk_client manca, installa il wheel del DFC per la generazione di hardware target nello stesso ambiente Python di Ultralytics. Hailo-8/8L e Hailo-10/15 richiedono generazioni di compilatori differenti.

Link to this sectionSistema operativo o architettura non supportati#

La compilazione HEF è supportata su Linux x86_64. Esporta tramite la piattaforma Ultralytics o utilizza una workstation compatibile se il computer locale è macOS, Windows, Raspberry Pi o un altro sistema ARM.

Link to this sectionL'esportazione richiede molto tempo#

L'ottimizzazione DFC è la fase più onerosa. Il tempo di compilazione aumenta con la dimensione del modello, la risoluzione di input e i dati di calibrazione. Una GPU supportata può accelerare l'ottimizzazione, mentre la compilazione basata solo su CPU può essere sostanzialmente più lenta.

Link to this sectionLa precisione del modello quantizzato diminuisce#

Usa immagini di calibrazione che somigliano agli input di produzione e includono oggetti importanti, scale, condizioni di luce e sfondi. Confronta il modello PyTorch originale e l'HEF esportato sullo stesso set di validazione prima del deployment. Un gap moderato dipendente dalla famiglia rimane anche con una buona calibrazione; vedi Aspettative di accuratezza per famiglia di modelli per i baseline misurati.

Link to this sectionL'HEF non viene caricato sul dispositivo#

Conferma che name corrisponda all'architettura fisica Hailo e che il driver del dispositivo, il firmware e i pacchetti HailoRT siano reciprocamente compatibili. Ispeziona l'artefatto con hailortcli parse-hef e verifica l'acceleratore con hailortcli fw-control identify.

Link to this sectionL'analisi dell'output sembra errata#

Tieni metadata.yaml accanto all'HEF in modo che Ultralytics possa selezionare il percorso di post-elaborazione corrispondente per YOLOv8, YOLO11 o YOLO26. Le applicazioni HailoRT personalizzate devono allo stesso modo abbinare la post-elaborazione alla famiglia di modelli esportata.

Link to this sectionFAQ#

Link to this sectionPosso compilare un HEF su un Raspberry Pi?#

No. Esegui il DFC su un sistema Linux x86_64 supportato e distribuisci l'HEF risultante sul Raspberry Pi.

Link to this sectionHo bisogno di una GPU NVIDIA?#

Una GPU supportata riduce notevolmente il tempo di ottimizzazione del DFC. La compilazione su CPU è possibile ma può richiedere molto più tempo.

Link to this sectionQuali modelli YOLO supportano l'esportazione Hailo?#

L'esportazione diretta supporta modelli di rilevamento con la testa di rilevamento standard YOLOv8, YOLO11 o YOLO26, modelli di segmentazione, posa e OBB di YOLOv8/YOLO11 e modelli di classificazione di YOLOv8/YOLO11/YOLO26. Questo include modelli addestrati personalizzati costruiti da tali architetture standard. Sono supportati anche i modelli di segmentazione semantica e stima della profondità di YOLO26. Segmentazione di istanze, posa e OBB di YOLO26, insieme a YOLOv10, YOLO-World, YOLOE e RT-DETR, vengono rifiutati anziché produrre un HEF non convalidato.

Link to this sectionPosso esportare un modello YOLO addestrato su misura?#

Sì. Usa lo stesso comando format="hailo" con i pesi .pt personalizzati e passa lo YAML del dataset di addestramento tramite data per una calibrazione INT8 rappresentativa. I nomi delle classi e il conteggio delle classi vengono letti dai metadati del modello.

Link to this sectionL'esportazione Hailo supporta dimensioni immagine dinamiche?#

No. Il DFC compila una forma di input fissa nell'HEF. Scegli imgsz durante l'esportazione per corrispondere alla risoluzione utilizzata dalla pipeline di distribuzione.

Link to this sectionPerché YOLO26 produce output Hailo differenti?#

YOLO26 utilizza una testa di rilevamento uno-a-uno senza NMS. Ultralytics compila direttamente quei tensori di output anziché allegare l'NMS in stile YOLOv8 di HailoRT utilizzato per YOLOv8 e YOLO11.

Link to this sectionQual è la differenza tra DFC e HailoRT?#

Il compilatore Hailo Dataflow converte e quantizza il modello in un HEF specifico per l'hardware su una macchina di build Linux x86_64. HailoRT carica ed esegue quell'HEF sul dispositivo target.

Link to this sectionDovrei distribuire il file ONNX o HEF?#

Distribuisci l'HEF compilato nel runtime Hailo. ONNX è una rappresentazione intermedia utilizzata durante l'esportazione e viene rimossa dopo una compilazione riuscita.

Link to this sectionDove posso ottenere il DFC di Hailo?#

Scarica il wheel del compilatore per la tua generazione di hardware dalla Hailo Developer Zone. Il compilatore è necessario solo per creare l'HEF; HailoRT lo esegue sull'acceleratore target.

Link to this sectionRiepilogo#

L'esportazione Ultralytics Hailo fornisce un percorso diretto da un modello YOLO addestrato a un HEF distribuibile:

1. Carica un modello di rilevamento o classificazione YOLOv8, YOLO11 o YOLO26, un modello di segmentazione, posa o OBB di YOLOv8/YOLO11, oppure un modello di segmentazione semantica o stima della profondità di YOLO26.
2. Esporta con format="hailo" e seleziona l'architettura target.
3. Calibra e compila localmente con il DFC corrispondente, oppure utilizza l'esportazione gestita nella piattaforma Ultralytics.
4. Copia l'HEF e il metadata.yaml sul dispositivo edge basato su Hailo.
5. Esegui l'inferenza con HailoRT, Raspberry Pi Picamera2 o una pipeline video GStreamer.

Per altri target di distribuzione di computer vision, consulta la modalità di esportazione, la modalità benchmark e la guida alle integrazioni. Le guide hardware correlate includono ONNX, OpenVINO, TensorRT, NCNN, RKNN, Sony IMX500 e Qualcomm QNN.