This page is the deepest custom-model reference for the Sixfab Edge AI Expansion Board for Raspberry Pi 5. It documents the conversion path end to end, calls out the constraints that catch most teams on their first deployment, and points to the partnership track that takes you from a labelled dataset to a deployed custom model in days.

The two-machine workflow

Custom-model deployment on the Edge AI Expansion Board is split between two machines because compilation is expensive and inference is not. Compilation runs once per model, on a desktop. Inference runs every frame, on the Pi.

Compiler machine requirements

The dx-compiler must run on a separate Ubuntu x86_64 machine, not on the Raspberry Pi itself. ARM / aarch64 is not supported for compilation.

Conversion path: ONNX → DXNN → deployed artifact

Three stages take a trained model from a development machine onto the NPU. Each stage runs in a different environment and produces a different artifact.

import torch

# 1. Load your trained model and switch to eval mode
model.eval()

# 2. Provide a dummy input matching the production input shape
dummy_input = torch.randn(1, 3, 640, 640)

# 3. Export to ONNX (opset 11 is widely compatible with dx-compiler)
torch.onnx.export(
    model, dummy_input,
    "my_model.onnx",
    opset_version=11,
    input_names=["images"],
    output_names=["output"]
)

yolo export model=yolov8n.pt format=onnx opset=11

# 1. Clone the dx-compiler toolchain on the Ubuntu x86_64 host
git clone https://github.com/DEEPX-AI/dx-compiler.git
cd dx-compiler

# 2. Follow the upstream install procedure for the toolchain release
#    matching the dxrt-runtime version installed on your Pi 5.
#    The compiler reads model parameters from a config.json file.

# 3. Compile ONNX → DXNN with the config for your model
dx-compiler --config <config.json>              --model my_model.onnx              --output my_model.dxnn

# 4. (Optional) inspect the compiled artifact
file my_model.dxnn

# Replace <pi_user> and <pi_host> with your values
scp my_model.dxnn <pi_user>@<pi_host>:~/models/

from dx_engine import InferenceEngine
import numpy as np
import cv2

# 1. Load the compiled DXNN model onto the NPU
engine = InferenceEngine("<model_path>/my_model.dxnn")

# 2. Preprocess on the Pi 5 CPU (BGR → RGB, normalize, NCHW)
frame = cv2.imread("<input_image>.jpg")
rgb   = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)
inp   = (rgb.astype(np.float32) / 255.0)
inp   = np.transpose(inp, (2, 0, 1))[np.newaxis]

# 3. Run inference on the NPU
outputs = engine.run(inp)

# 4. Parse outputs in your application code (no standard output format —
#    the shape matches what the ONNX graph produced)
print(outputs[0].shape)

# 1. Copy the new artifact
scp my_model_v2.dxnn <pi_user>@<pi_host>:~/models/

# 2. Restart the systemd service that loads the model
ssh <pi_user>@<pi_host> "sudo systemctl restart my-inference.service"

docker run --privileged   -v /dev/dxrt0:/dev/dxrt0   -v ~/models:/models   my-inference-app:latest

Sixfab × Ultralytics acceleration path

For teams who want to skip building the toolchain themselves and move from a labelled dataset to a deployed custom model in days, Sixfab offers a partnership track with Ultralytics that compresses the steps above into a guided pipeline.

Compatible Python libraries

Standard data-science and computer-vision libraries work alongside dxrt-runtime on Raspberry Pi 5 with no conflicts. OpenCV, Pillow, and NumPy are explicitly validated.

Pre-recorded video files are supported as inputs alongside live camera streams, which is the recommended approach for repeatable bench testing during development.

Integration patterns on the Edge AI Expansion Board

The Edge AI Expansion Board carries the NPU, the NVMe slot, and the LTE/5G modem on a single baseboard, so a deployed inference application typically writes to local storage and sends results upstream over cellular while inferring. The patterns below cover the points where Sixfab software ends and customer application code begins.

Inference, NVMe, and LTE/5G in the same pipeline

In bench testing, concurrent NVMe writes and LTE/5G traffic do not degrade AI inference throughput on the Edge AI Expansion Board. The NPU runs on a dedicated PCIe Gen 2/Gen 3 x1 link to the Pi 5, while storage and cellular share the on-board USB 3.2 Gen 1 hub. The practical implication for custom-model deployments: a single application can buffer raw frames to NVMe, run inference, and stream structured results over LTE/5G without staging a separate inference host.

Multiple concurrent models on one NPU

The DEEPX NPU can run more than one compiled model in parallel. Up to three concurrent models have been validated in bench testing; more is possible but not characterized. The practical pattern is a detection model plus a classification or pose model fed from the detected regions, all on the same NPU.

Multiple camera streams

Bench testing has shown the NPU handling four concurrent 720p streams cleanly. Beyond that, frame rate begins to drop — but the bottleneck is the Raspberry Pi 5 CPU handling capture, decode, and preprocessing, not the NPU itself. Plan accordingly: if more camera streams are needed, optimize the CPU-side pipeline (hardware decode, fewer copies, async I/O) before assuming the NPU is the limit.

Image preprocessing and postprocessing

The Raspberry Pi 5 CPU is responsible for everything around the inference call: capture, colour conversion, resize, normalisation, drawing bounding boxes and labels on output frames, and any non-maximum suppression that is not handled by a PPU-fused YOLO model. The NPU only runs the compiled graph. Image format expectations vary per model — most compiled models accept NHWC input and the exact tensor shape must match the config.json used at compile time.

Moving an existing application from a GPU or cloud server

If the model already fits within DEEPX-supported architectures, the transition is usually short. Compile the existing ONNX export with dx-compiler, swap the inference backend from the GPU framework to the dx_engine Python API (or dxrt in C++), and validate. With ready inference code, this is typically a matter of hours rather than weeks.

Limitations and constraints

Understanding these constraints up front saves significant debugging time later.