Link to this sectionHailo Export for Ultralytics YOLO Models#

Hailo AI accelerators run compiled Hailo Executable Format (HEF) models on edge devices such as the Raspberry Pi AI Kit and AI HAT+. Ultralytics exports YOLO detection, segmentation, pose, OBB, classification, semantic segmentation, and depth estimation models directly to HEF with the Hailo Dataflow Compiler (DFC).

Hailo deployment is designed for computer vision at the edge: cameras, robots, industrial systems, gateways, and other devices that need local object detection without sending every frame to the cloud. A compiled HEF contains the quantized network, hardware allocation, scheduling, and optional HailoRT post-processing needed by the selected accelerator.

Link to this sectionWhy Deploy Ultralytics YOLO on Hailo?#

Combining Ultralytics YOLO with a Hailo neural processing unit (NPU) provides a practical path from model training to low-power edge AI inference. Common use cases include:

• Smart cameras and video analytics: Run real-time object detection near the camera for security, retail, traffic, and occupancy applications.
• Robotics and autonomous systems: Detect people, vehicles, packages, tools, or obstacles without relying on a continuous cloud connection.
• Industrial computer vision: Deploy custom YOLO models for inspection, counting, safety monitoring, and quality control.
• Raspberry Pi AI projects: Add accelerated vision inference to Raspberry Pi systems using the AI Kit or AI HAT+.
• Edge gateways and AI PCs: Process multiple video or sensor streams locally while reducing bandwidth and cloud-compute requirements.

Local inference can improve privacy and response time because images remain on the deployment device. Actual throughput, latency, and power use depend on the YOLO model size, input resolution, Hailo architecture, host system, and application pipeline.

Link to this sectionHow Hailo Export Works#

Ultralytics owns the complete export workflow behind format="hailo":

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

The exporter performs these stages automatically:

1. Exports a static ONNX graph with compiler-compatible settings.
2. Selects the head outputs for the model architecture.
3. Generates normalization, activation, and post-processing directives.
4. Builds a representative calibration stream and quantizes the model to INT8.
5. Compiles the optimized graph for the selected Hailo accelerator.
6. Saves the HEF with Ultralytics metadata and removes the intermediate ONNX file.

YOLOv8 and YOLO11 detection models use HailoRT YOLO NMS in the compiled pipeline. YOLO26 detection models use their NMS-free one-to-one outputs, so the exporter selects a different output and quantization path automatically. YOLOv8/YOLO11 segmentation, pose, and OBB compile the raw head tensors, which Ultralytics decodes at inference, and YOLOv8/YOLO11/YOLO26 classification runs softmax on chip so the HEF returns class probabilities directly. For YOLO26 semantic segmentation the exporter follows the accelerator: Hailo-8/8L (DFC v3.x) return classifier logits for host upsampling and reduction, while Hailo-10/15 (DFC v5.x) compile multi-class ArgMax heads on chip and return a compact class map. Single-class heads use the host-logit path on every target because they require a threshold instead of ArgMax. YOLO26 depth models compile the dense logit conv in a16 and rebuild the metric depth map on the host (the clamp/exp and learned log-affine calibration that follow the head), so the quantizer keeps its widest range on the raw logit. Users do not need to find ONNX end nodes, write a Hailo model script (.alls), or create an NMS JSON manually.

Link to this sectionInstallation#

Install Ultralytics and download the DFC wheel for your target hardware from the Hailo Developer Zone (free registration required):

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

Hailo-8 and Hailo-8L use DFC v3.x. Hailo-10 and Hailo-15 use DFC v5.x. Install the compiler generation that matches the target accelerator.

Link to this sectionExport a Hailo HEF Model#

Use format="hailo" and select the target accelerator with name:

from ultralytics import YOLO

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

The equivalent CLI command is:

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

Hailo export is INT8-only. Ultralytics automatically downloads a task-specific calibration dataset when data is not provided. For custom models, use representative training or validation images:

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

Compilation uses a fixed input shape. Set imgsz to the resolution used on the device:

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

Link to this sectionSupported Models and Hardware#

The Hailo ecosystem covers a broad range of computer vision workloads, but the Ultralytics format="hailo" exporter currently validates standard YOLO detection, segmentation, pose, OBB, classification, semantic segmentation, and depth estimation heads. The task table describes the available exporter paths; hardware validation is listed separately below.

Specialized detection families such as YOLOv10, YOLO-World, YOLOE, and RT-DETR are also ❌ unsupported. Ultralytics rejects these tasks and model families before compilation instead of producing an unvalidated HEF.

Pose, OBB, classification, YOLO26 semantic segmentation, and YOLO26 depth estimation (Hailo-8/8L path) were validated on Hailo-8L with HailoRT 4.23 and DFC 3.33. The exporter accepts the other listed targets, but those new task paths require validation with the matching compiler and device before production use.

Select one of these name values:

hailo8l is the default. Install the DFC generation that matches the selected target.

Link to this sectionHailo Hardware and SDK Generations#

Hailo accelerator families use different compiler generations. The generated HEF must match the target hardware, so choose name for the device that will run inference rather than the machine performing the export.

The compiler runs on Linux x86_64, while the resulting HEF runs on the Hailo device through HailoRT. This separation lets you compile on a workstation or in Ultralytics Platform and deploy the small runtime artifact to an ARM or x86 edge host.

Link to this sectionCompatibility Notes#

Hailo compilation is hardware-specific and uses a fixed input shape. Keep these constraints in mind:

• The selected name must match the deployment accelerator.
• Calibration images should represent the lighting, viewpoints, objects, and backgrounds expected in production.
• A HEF compiled with one imgsz does not become dynamically resizable at runtime.
• Custom class counts are supported because Ultralytics generates post-processing configuration from the model metadata.
• Detection models with standard Ultralytics Detect heads, YOLOv8/YOLO11 segmentation, pose, and OBB models, and YOLOv8/YOLO11/YOLO26 classification models, and YOLO26 semantic segmentation and depth estimation models are supported; YOLO26 instance segmentation, pose, and oriented bounding box, along with YOLO-World, YOLOE, YOLOv10, and RT-DETR exports, are not currently supported.
• Hailo-8/8L and Hailo-10/15 artifacts are compiled by different DFC generations and are not interchangeable.

Link to this sectionCalibration and INT8 Quantization#

Hailo HEF export uses INT8 quantization to map the YOLO network efficiently onto the accelerator. The calibration dataset estimates activation ranges; it does not retrain the model or require labels during compilation.

When data is omitted, Ultralytics uses a task-specific lightweight calibration dataset, such as COCO128 for detection, cityscapes8 for semantic segmentation, or depth8 for depth estimation. The dense depth head is especially sensitive to the calibration domain: calibrating a depth model with unrelated detection images flattens the predicted map, and larger in-domain sets improve fidelity. For a custom computer vision model, point data to its dataset YAML so the compiler observes representative images from the actual deployment domain:

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

fraction selects the portion of the dataset used for calibration. More images help only when they represent the deployment domain; out-of-domain images can reduce quantized accuracy and increase optimization time. If the INT8 HEF loses accuracy relative to the original PyTorch model, first improve the calibration data before changing model or runtime settings.

Link to this sectionAccuracy Expectations by Model Family#

Measured on a Hailo-8L with in-domain calibration (COCO128, 128 images), INT8 HEF exports retain the following share of their PyTorch mAP50 under the same evaluation protocol:

Retention compares both models at the same confidence threshold. YOLOv8 and YOLO11 HEFs bake the export-time conf (default 0.25) into the on-chip NMS, so validating against a PyTorch baseline at its default low threshold integrates a larger part of the precision-recall curve and overstates the quantization gap.

Beyond detection, the segmentation, pose, OBB, and classification exporter paths were validated on the same Hailo-8L (DFC 3.33, HailoRT 4.23). Each INT8 HEF was compared with its PyTorch checkpoint on the same validation split, using in-domain calibration:

Segmentation, pose, and OBB were calibrated with each task's default in-domain set (COCO128-seg, COCO8-pose, DOTA128); classification was calibrated with ImageNet100. Two caveats follow from those defaults: COCO8-pose is only 8 images, so treat pose as indicative and pass a larger data= for production, and DOTA8 saturates mAP50 near 100% for both models, which is why OBB is read on DOTA128. Classification is also the one task where YOLO11 retains more than YOLOv8; for the others the YOLO11 attention backbone is more INT8-sensitive.

Three practical rules follow from device measurements:

1. Calibrate in-domain, always. Fine-tuning with out-of-domain images is equivalent to disabling fine-tuning entirely: a YOLO26n calibrated with 1,238 out-of-domain images retains the same accuracy (85.7%) as one compiled without fine-tuning. A small in-domain set beats a large out-of-domain one.
2. Lower conf by about 0.05 for YOLO26 deployments. Quantization shifts YOLO26 scores down by roughly 0.05 on average, so a threshold tuned in PyTorch drops valid detections on the HEF. Using conf=0.20 on device matches the detection count of PyTorch at conf=0.25, and lowering slightly further (around conf=0.15) recovers essentially all of the remaining mAP50 gap at the cost of more low-confidence detections. Quantization also re-ranks roughly 20% of detections — a permanent ordering effect that no threshold undoes — but that reshuffling does not block mAP50 recovery at the lower threshold.
3. The attention penalty is structural on Hailo-8/8L (DFC 3.33). The attention blocks compile to matmul operations that keep INT8 activation inputs in every mode the compiler offers for them; the 16-bit-output mode fails allocation for this graph, and raising the precision of the surrounding layers does not help because the matmul requantizes its inputs to INT8 anyway (protecting the depthwise and output convolutions at 16-bit left mAP unchanged in our tests). When accuracy is the priority and the model is interchangeable, YOLO11 currently quantizes better than YOLO26 here; newer Hailo generations (DFC 5.x) expose more mixed-precision options and may differ.

Link to this sectionExported Artifacts#

Export creates a directory containing the deployable HEF and Ultralytics metadata:

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

• *.hef is the compiled model loaded by HailoRT.
• metadata.yaml preserves model names, task, input size, stride, and Hailo target information.
• nms_config.json records the generated HailoRT NMS configuration for YOLOv8 and YOLO11 detection models. YOLO26 detection and all non-detection tasks (segmentation, pose, OBB, classification, semantic) do not use this file.

The intermediate ONNX graph is removed after compilation.

Link to this sectionRun Inference on Hailo Hardware#

Install HailoRT on the target device. Raspberry Pi AI Kit and AI HAT+ users can follow the Raspberry Pi AI software guide:

sudo apt install hailo-all
hailortcli fw-control identify

Copy the complete export directory to the device so metadata.yaml remains next to the HEF. Ultralytics uses HailoRT to run predict and val directly on the exported directory:

from ultralytics import YOLO

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

For detection models, the backend converts YOLOv8 and YOLO11 HailoRT NMS output and decodes YOLO26 one-to-one outputs automatically. It decodes raw segmentation, pose, and OBB tensors, returns on-chip classification probabilities, and produces semantic class maps through host reduction on Hailo-8/8L and all single-class heads or an on-chip ArgMax for multi-class Hailo-10/15 heads. TAPPAS, GStreamer, and the Raspberry Pi picamera2.devices.Hailo helper remain available for application-specific pipelines.

For a GStreamer deployment, pass the HEF to 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 sectionHailo Deployment Options#

The HEF is the same deployable model artifact across several Hailo runtime interfaces. Choose the interface that fits the application:

Keep metadata.yaml with the HEF when the application needs Ultralytics class names, input size, stride, or other model information. The HEF itself does not replace the application-level logic for camera capture, visualization, tracking, alerts, or storage.

Link to this sectionVerify the Hailo Device and HEF#

Before integrating a camera or video pipeline, verify the runtime and accelerator independently:

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

Device-only performance measurements isolate Hailo inference from video decoding, image resizing, drawing, and application I/O. Measure the complete application separately when estimating end-to-end latency or frames per second.

Link to this sectionHailo Compared with Other YOLO Export Formats#

Choose an export format based on the hardware that will execute the model:

HEF is the correct choice when the final device contains a Hailo accelerator. ONNX remains useful as a portable interchange format, but HailoRT executes the hardware-specific HEF produced by the DFC rather than the original ONNX model.

Link to this sectionOptimize Hailo Computer Vision Performance#

Model and pipeline choices often matter more than compiler flags:

• Start with a small YOLO model and increase model size only when accuracy requires it.
• Choose the lowest fixed imgsz that still preserves the objects important to the application.
• Use calibration images from the real camera and environment when possible.
• Keep the Hailo network active across frames instead of reopening the HEF for every inference.
• Separate device inference time from preprocessing, video decoding, post-processing, visualization, and network I/O.
• Use a streaming pipeline such as GStreamer for sustained video workloads.
• Validate the exported HEF on the exact accelerator and HailoRT version used in production.

Link to this sectionExport Arguments#

For detection export, YOLOv8 and YOLO11 receive HailoRT NMS, while YOLO26 keeps its NMS-free one-to-one outputs. Segmentation, pose, and OBB use raw head tensors, classification returns on-chip probabilities, and semantic segmentation returns raw logits on Hailo-8/8L and all single-class heads or baked class maps for multi-class Hailo-10/15 heads. Depth estimation returns the raw depth logit, which Ultralytics decodes into a metric depth map at inference. Do not pass end2end; explicit overrides are rejected. Dynamic shapes, batches larger than one, embedded Ultralytics NMS, FP16, and FP32 are also unsupported.

Link to this sectionTroubleshooting Hailo Export#

Link to this sectionHailo Dataflow Compiler Import Error#

If export reports that hailo_sdk_client is missing, install the DFC wheel for the target hardware generation in the same Python environment as Ultralytics. Hailo-8/8L and Hailo-10/15 require different compiler generations.

Link to this sectionUnsupported Operating System or Architecture#

HEF compilation is supported on Linux x86_64. Export through Ultralytics Platform or use a compatible workstation if the local computer is macOS, Windows, Raspberry Pi, or another ARM system.

Link to this sectionExport Takes a Long Time#

DFC optimization is the most expensive stage. Compilation time increases with model size, input resolution, and calibration data. A supported GPU can accelerate optimization, while CPU-only compilation can be substantially slower.

Link to this sectionQuantized Model Accuracy Drops#

Use calibration images that resemble production inputs and include the important objects, scales, lighting conditions, and backgrounds. Compare the original PyTorch model and exported HEF on the same validation set before deployment. A moderate family-dependent gap remains even with good calibration; see Accuracy Expectations by Model Family for the measured baselines.

Link to this sectionHEF Does Not Load on the Device#

Confirm that name matched the physical Hailo architecture and that the device driver, firmware, and HailoRT packages are mutually compatible. Inspect the artifact with hailortcli parse-hef and verify the accelerator with hailortcli fw-control identify.

Link to this sectionOutput Parsing Looks Incorrect#

Keep metadata.yaml beside the HEF so Ultralytics can select the matching YOLOv8, YOLO11, or YOLO26 post-processing path. Custom HailoRT applications must likewise match post-processing to the exported model family.

Link to this sectionFAQ#

Link to this sectionCan I compile a HEF on a Raspberry Pi?#

No. Run the DFC on a supported Linux x86_64 system and deploy the resulting HEF to the Raspberry Pi.

Link to this sectionDo I need an NVIDIA GPU?#

A supported GPU greatly reduces DFC optimization time. CPU compilation is possible but can take substantially longer.

Link to this sectionWhich YOLO models support Hailo export?#

Direct export supports detection models with the standard YOLOv8, YOLO11, or YOLO26 detection head, YOLOv8/YOLO11 segmentation, pose, and OBB models, and YOLOv8/YOLO11/YOLO26 classification models. This includes custom-trained models built from those standard architectures. YOLO26 semantic segmentation and depth estimation models are also supported. YOLO26 instance segmentation, pose, and OBB, along with YOLOv10, YOLO-World, YOLOE, and RT-DETR, are rejected rather than producing an unvalidated HEF.

Link to this sectionCan I export a custom-trained YOLO model?#

Yes. Use the same format="hailo" command with the custom .pt weights and pass the training dataset YAML through data for representative INT8 calibration. Class names and class count are read from the model metadata.

Link to this sectionDoes Hailo export support dynamic image sizes?#

No. The DFC compiles a fixed input shape into the HEF. Choose imgsz during export to match the resolution used by the deployment pipeline.

Link to this sectionWhy does YOLO26 produce different Hailo outputs?#

YOLO26 uses an NMS-free one-to-one detection head. Ultralytics compiles those output tensors directly instead of attaching the HailoRT YOLOv8-style NMS used for YOLOv8 and YOLO11.

Link to this sectionWhat is the difference between the DFC and HailoRT?#

The Hailo Dataflow Compiler converts and quantizes the model into a hardware-specific HEF on a Linux x86_64 build machine. HailoRT loads and runs that HEF on the target device.

Link to this sectionShould I deploy the ONNX or HEF file?#

Deploy the compiled HEF to the Hailo runtime. ONNX is an intermediate representation used during export and is removed after successful compilation.

Link to this sectionWhere can I get the Hailo DFC?#

Download the compiler wheel for your hardware generation from the Hailo Developer Zone. The compiler is required only to create the HEF; HailoRT runs it on the target accelerator.

Link to this sectionSummary#

Ultralytics Hailo export provides a direct path from a trained YOLO model to a deployable HEF:

1. Load a YOLOv8, YOLO11, or YOLO26 detection or classification model, a YOLOv8/YOLO11 segmentation, pose, or OBB model, or a YOLO26 semantic segmentation or depth estimation model.
2. Export with format="hailo" and select the target architecture.
3. Calibrate and compile locally with the matching DFC, or use managed export in Ultralytics Platform.
4. Copy the HEF and metadata.yaml to the Hailo-powered edge device.
5. Run inference with HailoRT, Raspberry Pi Picamera2, or a GStreamer video pipeline.

For other computer vision deployment targets, see Export mode, Benchmark mode, and the integrations guide. Related hardware guides include ONNX, OpenVINO, TensorRT, NCNN, RKNN, Sony IMX500, and Qualcomm QNN.