AI Model Deployment · Reference · Supported Models Catalog · Updated 2026-05-16

Supported Models Catalog

Which model architectures and operators run on the DEEPX NPU. Sixfab-validated architecture families with deployment status, plus the upstream operator support reference. Read this before starting custom model deployment to confirm your architecture compiles cleanly.

Pre-deployment planning DEEPX operator support YOLO · MobileNet · ResNet · ViT

Which model architectures are supported on the DEEPX NPU?

The DEEPX DX-M1 family NPU compiles ONNX models built from standard convolutional and transformer operators. Sixfab has validated specific architecture families end-to-end on Sixfab edge AI hardware (AI HAT+, Edge AI Expansion Board, ALPON X5 AI). For the exhaustive operator-by-operator support matrix, DEEPX maintains the upstream reference at github.com/DEEPX-AI/dx-compiler. This page documents the Sixfab-validated set and provides planning guidance before you commit to a model architecture.

Pre-deployment planning

Before exporting your model to ONNX and running DX-COM, confirm three things. Most compile-time failures and post-compile accuracy regressions trace back to one of these checks being skipped.

Confirm your architecture family is in the validated list

Sixfab has tested specific architecture families end-to-end on Sixfab edge AI hardware. If your model belongs to a validated family (Validated architecture families), compile and deployment are well-supported paths. If your architecture is not in the list, check the operator support reference (Operator support) before committing — unsupported operators cause compile-time errors or silent CPU fallback at runtime.

Verify operator support against the DEEPX upstream list

Open your exported .onnx file in Netron, enumerate every operator in the graph, and compare against the DEEPX-supported list at github.com/DEEPX-AI/dx-compiler · 03_Building_Models.md. Unsupported operators in the middle of the graph break the compile; unsupported operators at graph boundaries may fall back to CPU at runtime.

Verify quantisation compatibility

The DEEPX DX-M1 family runs INT8 only. Expect approximately 2 % accuracy loss versus the FP32 baseline (Quantisation compatibility). Architectures with quantisation-sensitive layers (attention, layer norm) need extra care — sometimes quantisation-aware training before export, sometimes DXQ enhanced_scheme during compile.

For the canonical operator-by-operator support matrix, DEEPX maintains the upstream documentation at github.com/DEEPX-AI/dx-compiler. Sixfab does not republish that matrix; we document the architectures we have validated on Sixfab edge AI hardware and the planning patterns Sixfab teams encounter most often.

Validated architecture families

Sixfab has tested these architecture families on Sixfab edge AI hardware. Each entry lists deployment status, common gotchas, and a link to a Sixfab Model Zoo entry where a ready-to-run validated example exists.

Family	Status	Model Zoo example	PPU mode	Common gotcha
YOLO anchor-based (v3, v5, v7)	Supported	None in current zoo	`type 0`	Anchor arrays in PPU config
YOLO anchor-free (v8, v9, v11)	Validated	YoloV8N/S/M, YoloV9S/C	`type 1` · `type 2`	Layer name mapping for PPU
Classification (ResNet, MobileNet, EfficientNet)	Supported	None in current zoo	n/a	ImageNet normalisation
Face detection (SCRFD)	Validated	SCRFD500M	n/a	Output tensor differs from YOLO
Pose estimation (YOLO backbone)	Validated	YoloV5Pose	n/a	Per-keypoint decoding
Segmentation, YOLO-derived	Validated	YoloV26S-Seg	n/a	Pixel-level mask output
Segmentation, general (DeepLab, U-Net)	Unvalidated	None in current zoo	n/a	High-resolution memory pressure
Vision Transformer (ViT, DeiT, Swin)	Not yet supported	None	n/a	Transformer support not yet enabled on current silicon
Custom detection (non-YOLO heads)	Case-by-case	None in current zoo	n/a	Verify every operator against upstream

YOLO — anchor-based (v3, v5, v7)

Supported

Anchor-based YOLO detection architectures. Compile cleanly with DX-COM using PPU type 0 for hardware-accelerated post-processing.

Validated NEED FROM SIXFAB confirm tested YOLO v3 / v5 / v7 revisions

Gotchas Anchor arrays must be specified in PPU config; ONNX export must preserve detection head structure.

Reference PPU type 0 config

YOLO — anchor-free (v8, v9, v11)

Validated in Model Zoo

Anchor-free YOLO detection architectures. The modern default. Compile with DX-COM using PPU type 1 (NPU hardware path) or type 2 (CPU-side TopK with reduced candidate count).

Validated YOLOv8 (n / s / m), YOLOv9 (s / c) in Sixfab Model Zoo. NEED FROM SIXFAB confirm YOLOv11 validation status.

Gotchas PPU type 1 requires correct bbox / cls_conf node mapping (locate in Netron); type 2 requires custom export that removes DFL decoding from the graph.

Reference Sixfab Model Zoo · PPU type 1 vs type 2

Classification — ImageNet pretrained

Supported

Standard ImageNet-pretrained classification architectures: ResNet, MobileNet, EfficientNet. Compile cleanly without PPU.

Validated NEED FROM SIXFAB confirm tested ResNet (18 / 50 / 101), MobileNetV2 / V3, EfficientNet (B0 – B7) variants.

Gotchas ImageNet normalisation required: mean [0.485, 0.456, 0.406], std [0.229, 0.224, 0.225]. 224×224 default input.

Reference Complete classification config

Face detection — SCRFD

Validated in Model Zoo

SCRFD lightweight face detection backbone. Designed for scenes with many faces at once; good for visitor counters and access control.

Validated SCRFD500M (Sixfab Model Zoo).

Gotchas Output tensor structure differs from YOLO; PPU not applicable.

Reference SCRFD500M in Model Zoo

Pose estimation — YOLO backbone

Validated in Model Zoo

YOLO-derived pose estimation architectures. Detects people and pinpoints 17 body joints per person. Useful for fitness, sport analytics, and any project that cares how a person is moving, not just where they are.

Validated YoloV5Pose (Sixfab Model Zoo).

Gotchas Pose heads add per-keypoint regression; output decoding differs from object detection. PPU not applicable.

Reference YoloV5Pose in Model Zoo

Segmentation — YOLO-derived

Validated in Model Zoo

YOLO-derived instance segmentation. Traces the exact outline of every detected object instead of a rectangular bounding box. Useful for background removal, robot grasping, and precise area measurement.

Validated YoloV26S-Seg (Sixfab Model Zoo).

Gotchas Mask head adds pixel-level output; PPU not applicable for segmentation models.

Reference YoloV26S-Seg in Model Zoo

Segmentation — DeepLab, U-Net

Unvalidated

General-purpose semantic and instance segmentation architectures (DeepLab v3+, U-Net variants). Image-based, so the DEEPX NPU supports the underlying operator set, but Sixfab has not run end-to-end validation.

Validated NEED FROM SIXFAB confirm any tested DeepLab / U-Net variants.

Gotchas Pixel-level output increases memory pressure at high input resolution; PPU not applicable.

Reference DEEPX upstream operator list

Vision Transformer (ViT, DeiT, Swin)

Not yet supported

Vision Transformer architectures. Transformer-based model support is not yet enabled on current DEEPX silicon. Image-based convolutional models are the validated path today; transformer support is on the DEEPX roadmap and Sixfab will support it as the silicon enables. No dates.

Validated None on current silicon.

Gotchas Attention-heavy graphs (MatMul, Softmax, LayerNorm) are quantisation-sensitive even where operators are supported individually; structural transformer support is pending silicon roadmap.

Reference Track the DEEPX repository for upstream changes.

Custom detection architectures

Case-by-case

Detection heads outside the YOLO family (DETR-style, custom one-stage / two-stage detectors). Compatibility depends on operator support and output tensor structure.

Validated Reviewed individually.

Gotchas Custom output decoders likely require host-side post-processing (no PPU); verify every operator in the graph against upstream before committing.

Reference Sixfab × Ultralytics Acceleration Path for managed evaluation.

Operator support

DEEPX maintains the canonical operator-by-operator support reference. Sixfab does not republish that matrix; we link to it and summarise the patterns Sixfab teams encounter most often.

Upstream reference DEEPX supported operators reference

The canonical operator-by-operator support list maintained by DEEPX. Verify every operator in your ONNX graph against this list before compiling.

Open repository

Commonly-encountered patterns

Convolutional operators

Standard 2D convolutions (Conv, ConvTranspose), batch normalisation (BatchNormalization), pooling (MaxPool, AveragePool, GlobalAveragePool), and activation functions (ReLU, LeakyReLU, SiLU) are well-supported. These form the backbone of all validated YOLO and classification architectures.

Element-wise and shape operators

Element-wise math (Add, Mul, Sub, Div), reshape and transpose (Reshape, Transpose, Squeeze, Unsqueeze), and concatenation (Concat) are well-supported. These appear throughout most ONNX exports.

Attention operators (transformer-heavy graphs)

MatMul, Softmax, and LayerNormalization appear in transformer architectures. Individual operator support exists, but the structural transformer model path is not yet enabled on current DEEPX silicon — see Validated architecture families — Vision Transformer. Where individual attention operators appear in otherwise-convolutional graphs, expect higher quantisation sensitivity; DXQ enhanced_scheme often helps recover accuracy. NEED FROM SIXFAB confirm any tested attention-operator caveats in non-transformer graphs.

Operators with known fallback behaviour

Some operators fall back to CPU execution at runtime instead of erroring at compile time. CPU fallback degrades end-to-end latency. NEED FROM SIXFAB document whether dxcom emits explicit fallback warnings during compilation or whether detection requires inspecting the compile log post hoc.

When in doubt, enumerate operators in Netron. Open your .onnx file in netron.app, write down every unique operator name, and check each against the upstream list before compiling. Most compile failures trace to a single unsupported operator inside the graph.

Quantisation compatibility

DEEPX silicon runs INT8 only. After DX-COM compilation, expect approximately 2 % accuracy loss versus the original FP32 baseline. Some architectures quantise cleanly; others need extra steps.

Architecture family	Quantisation cleanliness	Recommended approach
YOLO anchor-based (v3, v5, v7)	Clean	Standard calibration with 100+ representative images. No DXQ needed.
YOLO anchor-free (v8, v9, v11)	Clean	Standard calibration. PPU `type 1` for hardware-accelerated post-processing.
Classification (ResNet, MobileNet, EfficientNet)	Clean	Standard calibration. ImageNet normalisation required to match training pipeline.
Face detection (SCRFD)	Clean	Standard calibration.
YOLO pose and segmentation (YOLO-derived)	Clean	Standard calibration.
Segmentation, general (DeepLab, U-Net)	Unvalidated	Validate accuracy against FP32 baseline after compile. If drop > ~2 %, try DXQ `enhanced_scheme P3`.
Vision Transformer (ViT, DeiT, Swin)	Not yet supported	Transformer model support is on the DEEPX roadmap. No dates.
Generative architectures (GANs, diffusion)	Not supported	Vision today; LLMs and generative AI are on the DEEPX roadmap and Sixfab will support them as the silicon enables.

This is the honest INT8 inference envelope on DEEPX silicon. If your post-compile accuracy drop is substantially larger than 2 %, the problem is almost always one of:

ONNX export from training mode instead of model.eval().
Opset mismatch (try opset 11 first, then 13, then 17).
Unsupported operators silently falling back to CPU.
Weak calibration dataset (too few images, wrong domain).
Preprocessing pipeline mismatch between training and inference.

For diagnostic steps on each product, see the product Troubleshooting pages.

DXQ accuracy recovery

For quantisation-sensitive architectures, enable enhanced_scheme in config.json. DXQ inspects per-layer quantisation error and applies layer-wise corrections during compilation. Inference speed is unchanged; compile time increases. Schemes range from P0 (fast, modest improvement) to P5 (slow, high improvement); P3 is the validated starting point.

Full parameter detail and scheme selection guidance: DX-COM Configuration Reference §05 — enhanced_scheme (DXQ).

Common compile-time errors

If DX-COM fails to compile, the error usually traces to one of three patterns. Diagnosing the right pattern saves debugging time.

Unsupported operator inside the graph

Symptom. dxcom exits with an error mentioning a specific operator name.

Cause. An operator in the middle of the model is not on the DEEPX supported list.

Fix. Open the .onnx in Netron, locate the operator, and consider:

Re-exporting with a different opset (try opset 11 first, then 13, 17).
Replacing the operator at the framework level — a custom layer that produces an unsupported op can often be swapped for a supported equivalent.
Falling back to the Sixfab × Ultralytics acceleration path if the operator is structural to the model.

Input shape mismatch

Symptom. dxcom error mentioning input dimensions or batch size.

Cause. The inputs field in config.json does not match the ONNX graph input tensor.

Fix. Open the .onnx in Netron, click the first node, copy the input tensor name and shape exactly. Batch dimension must be 1. See DX-COM Configuration Reference §02 — inputs.

Memory planning failure

Symptom. dxcom error indicating the model does not fit in NPU memory.

Cause. Model size exceeds available NPU on-chip memory budget.

Fix. Consider:

A smaller model variant (e.g., YOLOv8s instead of YOLOv8m).
A reduced input resolution (e.g., 416×416 instead of 640×640) if your accuracy budget allows.
A larger-memory variant of the silicon — DEEPX DX-M1M (25 TOPS at INT8, 1 GB LPDDR4X) and DEEPX DX-M1 (25 TOPS at INT8, 4 GB) carry more on-package memory than DEEPX DX-M1ML (13 TOPS at INT8, 512 MB LPDDR4x).

Approximate model envelope. Sixfab has not benchmarked an exact upper bound on compiled model size per variant, but engineering guidance is that models large enough to occupy the full 4 GB on DX-M1 will not run on the smaller variants. NEED FROM SIXFAB publish a more precise per-variant model-size envelope where available.

Runtime errors For runtime errors after compile, see your product's Troubleshooting page.

Sixfab AI HAT+ Troubleshooting. For Edge AI Expansion Board and ALPON X5 AI, the equivalent pages are published on each product's sidebar. NEED FROM SIXFAB canonical Troubleshooting URLs for Edge AI Expansion Board and ALPON X5 AI.

Open

What if my architecture is not here

If your architecture is not in the validated list, three options.

Option 1

Compile and test yourself

Run your model through DX-COM with a small calibration set first (calibration_num: 10). If it compiles, run inference against an FP32 baseline to validate accuracy. If compile fails, the error message tells you which operators are problematic.

Best for: Teams with ONNX export expertise and time to iterate.

Deployment Workflow

Option 2

Sixfab × Ultralytics Acceleration Path

Sixfab partners with Ultralytics to provide a managed evaluation and deployment service for custom architectures. Bring a labelled dataset; the partnership delivers a trained, optimised, and deployed custom model on target Sixfab hardware.

Best for: Teams without internal ML engineering bandwidth, or architectures structurally outside the validated YOLO family.

Sixfab × Ultralytics Acceleration Path

Option 3

Ask the upstream

DEEPX maintains an active GitHub repository for the compiler. For operator-level questions, open an issue at github.com/DEEPX-AI/dx-compiler.

Best for: Technical teams investigating specific operator support gaps.

DEEPX repository

Next step Architecture confirmed? Move to the operational walkthrough.

Two-machine workflow, three-stage conversion path, and validated compile commands.

Deployment Workflow

Reference Need parameter-level detail?

Every config.json field, all three PPU types, DXQ accuracy recovery, and the full preprocessing operator list.

DX-COM Configuration Reference

Intelligented by DEEPX Built on Raspberry Pi