Hey all 
Sharing something new that recently landed in the Ultralytics package: you can now export YOLO models directly to a Hailo HEF using the standard Ultralytics API.
The short version: one command takes a trained .pt all the way to a deployable HEF.
from ultralytics import YOLO
model = YOLO("yolo11n.pt")
model.export(format="hailo", name="hailo8") # -> yolo11n_hailo_model/
Behind the scenes it drives the Dataflow Compiler (ONNX export → parse → INT8 optimization → compile) and writes out the HEF plus its metadata. You then run inference through the same Ultralytics API on the compiled model:
model = YOLO("yolo11n_hailo_model")
results = model.predict("image.jpg") # runs on HailoRT
What you can do with it today:
-
Tasks: detection, instance segmentation, semantic segmentation, depth estimation, classification, pose, and OBB (task coverage varies a bit by model family).
-
Model families: YOLOv8, YOLO11, and YOLO26.
-
Targets: pick your device with name= — hailo8, hailo8l, hailo10h, hailo15h, hailo15l.
-
Deployment: the exported folder works with Ultralytics predict/val, and the HEF drops straight into your app.
Please note that compilation needs the Dataflow Compiler installed on your development machine. The Dataflow Compiler is available from our Dev Zone as usual. Only HailoRT is required on the target device, so you compile once and ship the small runtime artifact to the edge.
In some cases, particularly with YOLO26 models, the quantized accuracy from Hailo’s Model Zoo is currently a little better than the Ultralytics export path. If you’re squeezing for maximum accuracy on those models today, the Model Zoo is still the reference — we’d expect the gap to narrow over time.
Full walkthrough (install, arguments, troubleshooting) is in the Ultralytics docs: https://docs.ultralytics.com/integrations/hailo/
4 Likes
Hi @Eldad_Rubinstein
Good to see this out. I contributed most of the non-detection task paths upstream (segmentation, pose, OBB, classification, semantic segmentation and depth), and each one was validated on a physical Hailo-8L with DFC 3.33 and HailoRT 4.23 before it went in, so let me add some numbers to the YOLO26 accuracy note, since that is the part people will hit first.
On the 8L with in-domain calibration (COCO128, 128 images), this is the mAP50 the exported HEF keeps against its PyTorch checkpoint, both read at the same confidence threshold:
| Model |
mAP50 retention |
|
| YOLOv8n |
~100% |
DFL head, on-chip NMS |
| YOLO11n |
~96% |
attention in the backbone |
| YOLO26n |
~93% |
end-to-end head plus attention |
The interesting part is where the YOLO26 loss comes from. Running the same checkpoint through its one-to-many head with the on-chip NMS instead gives 91.5%, so it is not the NMS-free head, the damage is already in the body. I also tried the Model Zoo recipe of protecting the depthwise and the output convolutions at a16_w16 on the exporter path: 0.4260 vs 0.4274 mAP50, which on this setup is noise.
That matches what the compiler offers. On Hailo-8/8L the matmul layers of the attention blocks keep INT8 activation inputs in every mode available for them (a8_w8, a8_w8_a8, a8_w8_a16), and the 16-bit output mode fails allocation for this graph. So for YOLO26 on this generation I would read the gap as a structural ceiling around 93-94% rather than something the export path can close on its own. Happy to be wrong there, every silicon measurement I have is on the 8L.
The lever that does work is the threshold:
- Quantisation shifts YOLO26 scores down by roughly
0.05, so conf=0.20 on device matches the detection count of PyTorch at conf=0.25, and around conf=0.15 recovers essentially all of the remaining mAP50 gap. About 20% of the detections get re-ranked permanently, but that reshuffling does not block the recovery at the lower threshold.
- Calibrating out of domain is the same as not fine-tuning at all — 1,238 out-of-domain images gave
85.7%, identical to no fine-tune. A small in-domain set beats a large generic one.
One question on the Model Zoo comparison, which size and which target is that measured on? If it is 26s/26m or a Hailo-15/10 part, that is outside what I could measure here and I would be interested in seeing the number ..
Hi @Jesus_Royeth ,
Thanks for your Hailo-related contribution to the Ultralytics repository.
Please see here the accuracy reached by the Hailo Model Zoo:
On the gap: I think the key point is that the recipe is more than the 16-bit change. The version proposed in #25687 (later reverted in #25728 as too model-specific) changes several .alls configs together - adaround, optimization_level=4, and ≥1,024 calibration images - not just a16_w16 on the depthwise/output layers.
1 Like