Sixfab × Ultralytics Acceleration Path
Export Ultralytics YOLO models to DEEPX format for the DEEPX DX-M1 NPU, covering native export, Ultralytics Platform, and local DX-COM. Then deploy the .dxnn on Sixfab AI HAT+, Edge AI Expansion Board, or ALPON X5 AI.
Sixfab × Ultralytics Acceleration Path
Ultralytics now exports directly to DEEPX format, with no manual ONNX export or standalone DX-COM install required. This guide covers that native export, plus two alternatives worth knowing about: training and exporting through Ultralytics Platform in the cloud, and running DX-COM manually when you need full control over calibration. It ends with a pointer to the sixfab-dx-examples repository for deploying the result on a Sixfab AI HAT+ or Edge AI Expansion Board.
Three paths take an Ultralytics YOLO model to a DEEPX .dxnn binary for the
DEEPX DX-M1 NPU: the native format="DEEPX" export, training and exporting on
Ultralytics Platform in the cloud, and a local DX-COM run for full control. For most people
training with Ultralytics locally, the native export is the right starting point.
Which path should you use?
All three paths produce the same .dxnn binary for the DEEPX DX-M1 NPU. They
differ in where compilation runs, what you have to set up, and how much control you get over
quantization.
Native format="DEEPX" export |
Ultralytics Platform | Local DX-COM | |
|---|---|---|---|
| Where compilation happens | Your machine, inside the ultralytics package |
Ultralytics' cloud infrastructure | Your machine |
| Setup | pip install ultralytics; dx_com installs itself on first export |
Ultralytics Platform account, no local compiler needed | Separate DX-COM install, manual ONNX export |
| Host requirement | x86-64 Linux (export step only) | Any OS with bash/curl |
x86-64 Linux, glibc ≥ 2.31, Python 3.12 |
| Calibration dataset | Auto-selected (coco8.yaml by default, or your own data= argument) |
Handled automatically | You provide it |
| config.json | Generated for you | Generated for you | You write it |
| Control over quantization | Standard INT8 + calibration dataset choice | Limited: accepts platform defaults | Full: calibration count, PPU, DXQ, custom preprocessing |
| Training included | No; bring your own .pt |
Yes; annotate, train on cloud GPUs, and export in one place | No |
| Best for | Most YOLO users; the default choice | Teams that want dataset, training, and export in one workflow, or anyone without an x86-64 Linux box | Custom architectures, PPU offload, accuracy tuning beyond the standard pipeline |
If you are training with Ultralytics locally, the native format="DEEPX"
export below is the right starting point. If your dataset and training runs already live
in the cloud, skip to Path B (Ultralytics Platform). Reach for
local DX-COM only when you need control beyond the standard pipeline.
Path A: Native export with ultralytics (recommended)
Prerequisites
- x86-64 Linux for this export step (ARM64, including Raspberry Pi 5, is not supported for compiling, only for running the resulting
.dxnnfile) - Python environment with
pip install ultralytics
The dx_com compiler package installs itself automatically from the DEEPX SDK on
your first DEEPX export, so you don't need to install it separately.
Export
from ultralytics import YOLO # Load a YOLO model: YOLO26, YOLO11, and YOLOv8 families are all supported model = YOLO("yolo26n.pt") # Export to DEEPX format (INT8 quantization is enforced automatically) model.export(format="DEEPX") # creates 'yolo26n_DEEPX_model/'
Supported tasks: detection, instance segmentation, semantic segmentation, pose estimation,
OBB detection, and classification. All work with the same format="DEEPX" call.
Useful export arguments:
| Argument | Default | Notes |
|---|---|---|
imgsz |
640 |
Must be square: pass an integer or a matching height/width tuple |
quantize |
8 (auto) |
INT8 is required for DEEPX and enforced regardless of what you pass |
data |
coco8.yaml |
Calibration dataset for INT8 quantization; point this at images from your deployment domain for better accuracy |
device |
None |
0 for GPU, cpu for CPU |
optimize |
False |
Higher compiler optimization; lowers inference latency, raises compile time |
Output
yolo26n_DEEPX_model/ ├── yolo26n.dxnn # compiled NPU binary ├── config.json # calibration and preprocessing settings └── metadata.yaml # class names, image size, task type
Run inference or validate directly from Python
from ultralytics import YOLO model = YOLO("yolo26n_DEEPX_model") results = model("https://ultralytics.com/images/bus.jpg") # predict metrics = model.val(data="coco8.yaml") # validate
This works once the DEEPX runtime (driver + libdxrt + dx_engine) is
installed on the target device. See Deploying the compiled model below.
In Ultralytics' own benchmarks on a Raspberry Pi 5 + DX-M1 M.2 module, YOLO26n dropped from 0.476 to 0.466 mAP50-95 after DEEPX INT8 export while inference time went from roughly 315 ms to 35 ms per image. Expect a similar small accuracy trade for a large speed gain. Actual numbers vary by model and task.
Path B: Train and export on Ultralytics Platform
Ultralytics Platform
covers the whole chain in the browser: upload a dataset, train on cloud GPUs, test the
trained weights, and export straight to DEEPX, without a local compiler or an x86-64 Linux
machine. The walkthrough below follows one full run, from an empty account to a
.dxnn file on disk.
Prerequisites
- An Ultralytics Platform account
- Account balance for cloud training (GPU time is billed per hour; the estimate is shown before you start)
- Your Ultralytics API key (Settings → API Keys) for the download script at the end
bashandcurl(any Linux, macOS, or WSL shell; no DX-COM environment requirements here)
Create a dataset
From Home → Datasets → New Dataset, either drop images in from your machine or point Platform at a URL. The URL path is the faster route for public datasets: paste the archive link, name the dataset, pick the task type, and Platform pulls it in for you.
Fields that matter here:
| Field | What to enter |
|---|---|
| Dataset URL | A ZIP, TAR, or NDJSON archive (up to 50 GB, varies by plan). The green check confirms the URL is reachable. |
| Dataset Name | Display name; COCO in this run |
| URL slug | Lowercase letters, numbers, and hyphens; this becomes ul://<user>/datasets/<slug> in your training command |
| Task Type | Detect, Segment, Pose, Classify, or OBB; this must match the annotations in the archive |
| Visibility | Public or private |
Accepted formats: images (AVIF, BMP, DNG, HEIC, JP2, JPG, MPO, PNG, TIFF, WEBP up to 50 MB each), videos (MP4, WEBM, MOV, AVI, MKV, M4V up to 1 GB), dataset archives (ZIP, TAR, NDJSON), and annotations in YOLO, COCO JSON, or Ultralytics NDJSON.
Wait for processing
Platform transfers the archive to cloud storage, then indexes and validates it. Both stages report progress; large datasets take a while at the processing stage, so leave the tab open or come back to it later.
Confirm the dataset is ready
When the status badge flips to Ready, you get the full picture: image count, labeled count, annotation count, storage size, and the train/val/test split. The COCO import in this run landed at 354,346 images, 349,626 labeled, 4,970,819 annotations, 30.2 GB, split 344,194 train / 10,152 val.
A class-count mismatch between your annotations and your intent is easier to catch now than after a 26-hour training run. When the data looks right, hit New Model.
Configure the training run
The Train New Model dialog is where the run is defined.
| Setting | Value in this run | Notes |
|---|---|---|
| Base Model | yolo26n |
YOLO26, YOLO11, and YOLOv8 families are all valid DEEPX export sources |
| Dataset | COCO 2 |
The dataset from Step 3 |
| Project | sample-project |
Auto-generated name; rename it if you plan to keep several runs |
| Epochs | 50 |
|
| Batch Size | -1 |
-1 enables auto-batch; the trainer picks the largest batch the GPU memory allows |
| Image Size | 640 |
Keep this square. DEEPX compilation requires a square input, and matching train and export imgsz avoids a resize mismatch later. |
| Run Name | exp |
Optional, but a named run is easier to find in the export step |
| GPU Type | A100 SXM (80 GB, $1.49/hr) |
B200 and B300 require a Pro or Enterprise plan |
Platform prices the run before you commit: ~14h 14m at $1.49/hr, about 17.0 min/epoch over 354,346 images, for an estimated $21.21. The actual run in this walkthrough took 1d 2h of wall-clock time. Budget accordingly, and prefer Local Training if you already have a GPU box and only want Platform for metric streaming and the export pipeline.
Watch the run
Once training starts, the run page streams progress: epoch counter, elapsed time, live compute cost, and the full environment record, including Ultralytics version, OS, Python version, CPU, GPU, container, parent model, and Git commit.
The page also prints the equivalent CLI command, which is the useful part if you want to reproduce the run outside the browser:
yolo train device=7 model=ul://ultralytics/yolo26/yolo26n data=ul://ahmet-durmaz/datasets/coco-2 \ project=ahmet-durmaz/yolo26n-coco name=exp epochs=50 batch=-1 imgsz=640
This command form needs ultralytics>=8.4.51. Cancel
stops the run and the billing with it.
Read the results
A completed run puts the headline metrics at the top of the model page: mAP50, mAP50-95, precision, and recall, each with its training curve. This run finished at 55.7% mAP50, 40.1% mAP50-95, 64.9% precision, and 50.7% recall after 1d 2h.
Write down the mAP50-95 figure. It's the number you'll compare against after INT8 quantization to see what the DEEPX export cost you in accuracy.
Sanity-check the weights in Predict
Before spending compile time, confirm the model actually detects what you trained it on. The Predict tab takes an uploaded image, a webcam frame, or one of the two built-in examples.
Results come back with per-stage timing and per-detection confidence, plus the raw JSON
the API would return. On the zidane.jpg example, this model returned 3
detections, two person boxes at 92.7% and 83.1% and a tie at
40.5%, at 90.4 ms inference on CPU (PyTorch 2.12.0+cpu).
That 90.4 ms CPU number is worth holding onto as a baseline. It's the same PyTorch model you're about to compile for the DX-M1 NPU.
Open the Export tab
Export lists every target format Platform can compile to: ONNX, TorchScript, OpenVINO, TensorRT, CoreML, TF Lite, PaddlePaddle, NCNN, MNN, RKNN, IMX500, Axelera, ExecuTorch, DEEPX, and Qualcomm. Each format can be exported multiple times with different settings, so a 640 build and a 320 build can coexist.
Expanding a format shows its settings before you commit. ONNX, for example, exposes image size, batch size, FP16, dynamic shapes, simplification, opset, and post-processing options:
After the job completes, the row records the exact arguments used, the artifact size,
and the compile time, here imgsz=640, half=true, dynamic=false, simplify=true,
nms=false, batch=1, int8=false, 4.8 MB, 2.0s, with a download button next to it.
You don't need the ONNX file for the DEEPX path. It's here because it shows the pattern every format follows, and because an ONNX export is a quick way to verify the graph before you spend minutes on NPU compilation.
Export to DEEPX
Scroll to the DEEPX row, described as "DEEPX NPU accelerators for power-efficient edge inference", and press Export. Platform runs the ONNX-to-DXNN compilation server-side.
imgsz=640, int8=true, optimize=true, a 4.7 MB artifact in 5m 24s.
The finished export records its arguments the same way:
imgsz=640, int8=true, optimize=true, producing a 4.7 MB
artifact in 5m 24s. Two of those flags are not optional:
int8=true: the DX-M1 NPU runs INT8. Quantization is enforced regardless of what you pass.imgsz=640: square, and matching the training image size.optimize=true: higher compiler optimization. It lowers inference latency at the cost of compile time, which is part of why this export took 5m 24s rather than the 2.0s an ONNX export needs.
Compilation is measured in minutes, not seconds. The 1 exported badge on the row and the green check on the artifact line are the signals that it's done.
Download the export
The download icon on the DEEPX artifact row gives you the archive directly. If you'd rather not click through the UI, or you want this in a build script, the one-liner in the next section does the same job from a terminal.
Downloading a Platform export from the terminal
This script authenticates with your Ultralytics API key, lists your projects, models, and exports, then downloads and unzips the archive. It can also kick off a new DEEPX export if none exists yet.
ULTRALYTICS_API_KEY=<YOUR_ULTRALYTICS_API_KEY> bash <(curl -sL https://gist.githubusercontent.com/aahmetdurmaz/086a396dbbfd9002475cf1e58d87e41f/raw/515d3bcb5d5a1b638307dd8c1d1cfe9fbae4886c/platform.sh)
Replace <YOUR_ULTRALYTICS_API_KEY> with your own key from
Settings → API Keys. Treat it like a password: don't commit it to a
repository or paste it into shared logs. To keep it out of your shell history, export it
from a file instead:
export ULTRALYTICS_API_KEY="$(cat ~/.ultralytics_key)" bash <(curl -sL https://gist.githubusercontent.com/aahmetdurmaz/086a396dbbfd9002475cf1e58d87e41f/raw/515d3bcb5d5a1b638307dd8c1d1cfe9fbae4886c/platform.sh)
What the prompts look like
== Ultralytics Platform Model Downloader == Fetching projects... Projects: 1) <project-name> (<project-id>) Select a project (number): 1 Selected project: <project-name> Fetching models... Models: 1) <model-name> [detect | mAP50: 0.xxxxx] Select a model (number): 1 Selected model: <model-name> Fetching exports... Available exports: 1) DEEPX [completed] <export-id> 2) onnx [completed] <export-id> 3) Create new export (format: DEEPX) Your choice (1-3, q to quit): 1 Downloading -> ./models/<model-name>/<model>.DEEPX.zip Done. Extracting ./models/<model-name>/<model>.DEEPX.zip... Archive: ./models/<model-name>/<model>.DEEPX.zip inflating: ./models/<model-name>/<model>_DEEPX_model/<model>.dxnn inflating: ./models/<model-name>/<model>_DEEPX_model/config.json inflating: ./models/<model-name>/<model>_DEEPX_model/metadata.yaml Extracted to: ./models/<model-name>
Select a project
Every project tied to your API key.
Select a model
Each trained model in that project, with task type and headline metric.
Select an export
Pick an existing DEEPX export to download it directly, or choose
Create new export (format: DEEPX) if none exists yet; Platform runs the
compilation server-side and makes the archive available once it completes.
The extracted folder has the same three files as the native export: .dxnn,
config.json, metadata.yaml. Everything downstream is identical no
matter which path produced it. Copy that folder to your Raspberry Pi 5 and it's ready for
the DEEPX runtime.
Path C: Manual export and compile with local DX-COM
Use this only when you need more control than either export path above gives you: custom calibration counts, PPU offload configuration, or DXQ enhanced quantization.
Export your model to ONNX yourself
model.export(format="onnx") (batch size 1, the DX-COM requirement, is
Ultralytics' default).
Find the input tensor name
Open the model in Netron;
the input is typically images for YOLO exports.
Prepare calibration images and write config.json
Prepare a calibration image set from your deployment domain and write a config.json by hand.
Compile with the dxcom CLI
Run the standalone dxcom CLI to compile.
Full steps are in the
DX-COM Installation & Usage Guide
and the
DX-COM Configuration Reference:
environment prerequisites (glibc ≥ 2.31, Python 3.12), config.json parameters,
PPU configuration, DXQ, and reading NPU-integrated preprocessing from the compile log.
Deploying the compiled model
Whichever path produced your .dxnn, you still need the DEEPX runtime installed on
the target device to run it. On Sixfab hardware, install it via APT:
sudo apt update sudo apt install apt-repo-sixfab sudo apt update && sudo apt install sixfab-dx
See the
AI HAT+ Raspberry Pi 5 Quickstart
for the full setup. Once the runtime is installed, the
sixfab-dx-examples
repository has deployment code for Sixfab AI HAT+ and Edge AI Expansion Board: model loading,
pre/post-processing, and inference loops for common vision tasks. Clone it and point it at
your .dxnn file to get inference running.
If you'd rather integrate the DEEPX runtime into your own application instead of using the repository as-is, it's still useful as a reference codebase, since the same model-loading and pre/post-processing patterns apply either way.
Set up the DEEPX runtime on Sixfab hardware
Driver, runtime, and device health check, end to end for Raspberry Pi 5.
Deployment code and examples
Model loading, pre/post-processing, and inference loops for AI HAT+ and Edge AI Expansion Board.
FAQ
Do I need to export to ONNX first and run DX-COM separately?
No, not anymore. model.export(format="DEEPX") in the ultralytics
package runs the full ONNX-to-DXNN compilation for you, installing dx_com
automatically on first use. Manual ONNX export plus a standalone DX-COM run is only needed
for the advanced control described in Path C.
Can I run the export on a Raspberry Pi or other ARM64 device?
Not the export/compile step; that requires x86-64 Linux. The resulting .dxnn
file runs on both x86-64 and ARM64 (including Raspberry Pi 5), so compile on an x86-64
machine, then copy the exported folder to your Pi for inference. If you don't have an
x86-64 Linux machine available, Path B (Ultralytics Platform)
compiles in the cloud instead.
Do I have to train on Ultralytics Platform to use its DEEPX export?
No. Platform can export any model in your account, including weights you upload rather than train there. Training in the cloud is one option in the Train New Model dialog; Local Training streams metrics from your own GPU and still leaves the model exportable from the Export tab.
How long does a DEEPX export take on Ultralytics Platform?
Minutes, not seconds. The run in this guide compiled a YOLO26n detection model at
imgsz=640, int8=true, optimize=true in 5m 24s, producing a 4.7 MB
artifact. Compile time rises with model size and with optimize=true.
What's the difference between the DEEPX and onnx exports on Ultralytics Platform?
onnx is the uncompiled model. DEEPX is the same model already
compiled into a .dxnn binary, ready for the DEEPX DX-M1 NPU.
Why does the DEEPX export force INT8?
The DX-M1 NPU executes INT8 arithmetic. FP16 and FP32 graphs have to be quantized before
they can run on it, so the export pipeline enforces int8=true rather than
letting a non-runnable artifact through.
My compiled model's accuracy is lower than expected.
Some accuracy loss from INT8 quantization is normal. Compare the post-export mAP50-95
against the figure from your training run; in Ultralytics' Raspberry Pi 5 benchmark,
YOLO26n dropped from 0.476 to 0.466 mAP50-95. For the native or Platform export,
pass a data= calibration set that matches your real deployment images rather
than the default coco8.yaml. For the local DX-COM path, increase
calibration_num and consider DXQ enhanced quantization. See the
DX-COM Configuration Reference.
How do I install the DEEPX runtime to actually run the .dxnn file?
On a Sixfab AI HAT+ or Edge AI Expansion Board, install it through Sixfab's APT repository:
# 1. Refresh the package index sudo apt update # 2. Install the Sixfab APT repository sudo apt install apt-repo-sixfab # 3. Refresh again, then install the DEEPX runtime sudo apt update && sudo apt install sixfab-dx
This installs the driver and runtime needed to run the .dxnn file on the NPU.
Full steps are in the
AI HAT+ Raspberry Pi 5 Quickstart.
For deployment code on top of the runtime, the
sixfab-dx-examples
repository wraps model loading and pre/post-processing into ready-to-run examples.
Updated 8 days ago