AMD Xilinx Export for Ultralytics YOLO with Vitis AI#

Exporting Ultralytics YOLO26 models with format="xilinx" quantizes them with AMD Quark for the NPU in AMD Versal AI Edge Series Gen 2 adaptive SoCs, ready for AMD's Vitis AI compiler to build a .rai model. The same export validates INT8 accuracy on any host before you deploy.

AMD Xilinx devices power many of the world's industrial cameras, automotive vision systems, robots, drones and medical imaging products. They combine Arm processors with programmable logic and, on newer devices, dedicated AI Engines, so a single chip can capture video, preprocess it, run object detection and act on the result with low, predictable inference latency.

This guide covers the AMD Xilinx export, how to compile and run it on a Versal board, what each AMD Xilinx device family is, how AI runs on them, and which Ultralytics YOLO operators each accelerator supports.

What is AMD Xilinx?#

Xilinx invented the field-programmable gate array (FPGA) in the 1980s and became a leading supplier of adaptive SoCs and FPGAs. AMD completed its acquisition of Xilinx in February 2022, and the product lines are now sold under the AMD brand as AMD Zynq, AMD Kria, AMD Versal and AMD Vitis.

Key Terms and Concepts#

AMD Xilinx deployment uses its own vocabulary. The table below explains every term used in this guide.

AMD Xilinx Device Families for Edge AI#

AMD Xilinx devices for edge AI fall into three families. Zynq and Kria use the DPU in programmable logic, while the Versal AI Edge devices covered here use the NPU on their AI Engines.

Zynq UltraScale+ MPSoC#

Each Zynq UltraScale+ chip pairs an Arm processing system, with dual-core (CG) or quad-core (EG and EV) Cortex-A53 cores and real-time Cortex-R5F cores, with FPGA logic. EV devices add a hardened H.264/H.265 video codec. To run neural networks, designers build a DPU into the logic next to their camera and video pipelines. On small devices the DPU competes for space with the rest of the design.

Kria System-on-Modules#

The Kria K26 module packages a Zynq UltraScale+ MPSoC, memory and power on a production-ready module, so you avoid designing the processor, memory and power subsystem yourself. The module plugs into a carrier card, either a starter-kit board or your own design. It powers the KV260 Vision AI Starter Kit for smart cameras and the KR260 Robotics Starter Kit for robotics. Because the K26 is built on Zynq UltraScale+, it uses the same DPU flow. The Kria portfolio also includes other modules, so check which processor your module uses before choosing a flow.

Versal Adaptive SoCs#

Versal is AMD's adaptive SoC family. Its AI Edge and AI Core series add hardened AI Engines next to the Arm cores and programmable logic, while some other Versal series have no AI Engines. AMD's NPU IP runs on AI Engines and programmable logic together, and Vitis AI targets the AIE-ML parts of the AI Edge series, such as the VE2302 and VE2802. The Versal AI Edge Series (VEK280 evaluation kit) and the Versal AI Edge Series Gen 2 (VEK385 evaluation kit) are AMD's current targets for edge AI and the focus of current Vitis AI releases.

How AI Runs on AMD Xilinx Devices: DPU vs NPU#

Most AMD Xilinx AI deployments follow the same pattern. The accelerator runs the layers it supports, the Arm CPU runs preprocessing, post-processing and any layers the accelerator cannot execute, and a runtime on the board coordinates the two.

graph LR
    A[Camera / video input]:::start --> B[Arm CPU<br>Linux, preprocessing,<br>post-processing]:::proc
    B <--> C[AI accelerator<br>DPU in programmable logic<br>or NPU on AI Engines + PL]:::out
    B --> D[Application<br>alerts, control, display]:::start

    classDef start fill:#4CAF50,color:#fff
    classDef proc fill:#2196F3,color:#fff
    classDef out fill:#9C27B0,color:#fff

AMD has shipped two generations of accelerator, each with its own toolchain and compiled model file. This guide follows Vitis AI 3.5 for the DPU and Vitis AI 6.3 for the NPU; check AMD's current documentation for later releases.

Which Vitis AI Flow Do I Need?#

Pick your flow from the device on your board:

graph TD
    A[Start: which AMD device<br>is on your board?]:::start --> B{Device family?}:::decide
    B -->|Zynq UltraScale+ MPSoC<br>or Kria K26| C[DPU flow<br>Vitis AI 3.5]:::proc
    B -->|Versal AI Edge<br>VEK280| D[NPU snapshot flow<br>Vitis AI 6.3]:::proc
    B -->|Versal AI Edge Gen 2<br>VEK385| E[Ultralytics export<br>format=xilinx]:::proc
    C --> F[Train YOLO with Hard-Swish<br>then compile to .xmodel]:::out
    D --> G[Run your model on calibration<br>images to capture a snapshot]:::out
    E --> H[Compile to .rai<br>with Vitis AI 6.3]:::out

    classDef start fill:#4CAF50,color:#fff
    classDef proc fill:#2196F3,color:#fff
    classDef decide fill:#FF9800,color:#fff
    classDef out fill:#9C27B0,color:#fff

Export to AMD Xilinx: Converting Your YOLO Model#

Supported Tasks#

AMD Xilinx export supports all seven Ultralytics tasks. Semantic segmentation and depth estimation are available only with YOLO26, the only family that ships those heads.

Installation#

AMD Xilinx export runs on Linux (x86-64 or ARM64) with Python 3.11 to 3.13, the versions AMD Quark supports. The first export also compiles Quark's custom operators, which needs a C++ compiler such as g++.

# Install the required package for YOLO
pip install ultralytics

AMD Quark is installed automatically from PyPI on the first export. To preinstall the export dependencies:

pip install "ultralytics[export-xilinx]"

For an editable repository install, replace "ultralytics[export-xilinx]" with -e ".[export-base,export-xilinx]". To reproduce the Python 3.12 environment and smoke export used by CI, run the existing environment builder from the repository root:

ULTRALYTICS_ISOLATED_VENVS="$PWD/.venvs" python .github/scripts/create-export-env.py --env isolated-xilinx

Usage#

The AMD Xilinx format supports the Export, Predict, and Validate modes. Without AMD's Vitis AI Execution Provider, predict and validate run the quantized model with ONNX Runtime on the CPU, which measures its INT8 accuracy on any host. When ONNX Runtime provides the VitisAIExecutionProvider, as on a Versal AI Edge Series Gen 2 board, Ultralytics selects it automatically.

from ultralytics import YOLO

# Load a YOLO26 model
model = YOLO("yolo26n.pt")

# Export to AMD Xilinx format for the VEK385 (quantize=8 is enforced automatically)
model.export(format="xilinx")  # creates 'yolo26n_xilinx_model/'

from ultralytics import YOLO

# Load the exported AMD Xilinx model
model = YOLO("yolo26n_xilinx_model")

# Run inference
results = model("https://ultralytics.com/images/bus.jpg")

from ultralytics import YOLO

# Load the exported AMD Xilinx model
model = YOLO("yolo26n_xilinx_model")

# Validate INT8 accuracy on the COCO8 dataset
metrics = model.val(data="coco8.yaml")

The vitis, vitisai and versal format names are aliases for xilinx.

Export Arguments#

Set nms=False to export the YOLO26 NMS-free head. Embedded NMS (nms=True) is not supported, because AMD lists NonMaxSuppression among the operators that can force the entire model onto the CPU.

For more details about the export process, visit the Ultralytics documentation page on exporting.

Output Structure#

After a successful export, a model directory is created with the following layout:

yolo26n_xilinx_model/
├── yolo26n.onnx          # AMD Quark VINT8 model with the Ultralytics metadata
└── vitisai_config.json   # Vitis AI compiler configuration for the target device

Compiling the model, as described below, adds a yolo26n/ compiler cache to the same directory, containing the yolo26n.rai NPU model and AMD's compile reports such as final-vaiml-pass-summary.txt.

How the Export Works#

The export follows AMD's documented Vitis AI flow for Versal AI Edge Series Gen 2:

graph LR
    A[YOLO model<br>yolo26n.pt]:::start --> B[ONNX export<br>opset 17]:::proc
    B --> C[AMD Quark VINT8<br>head kept in float]:::proc
    C --> D[yolo26n_xilinx_model/<br>ONNX + vitisai_config.json]:::out
    D --> E[Vitis AI 6.3 compiler<br>yolo26n.rai]:::proc
    E --> F[VEK385 NPU<br>INT8 + BF16]:::out
    D -.->|host CPU| G[INT8 accuracy check<br>yolo val]:::start

    classDef start fill:#4CAF50,color:#fff
    classDef proc fill:#2196F3,color:#fff
    classDef out fill:#9C27B0,color:#fff

1. ONNX export at opset 17 with a static batch size of 1.
2. AMD Quark quantization with the VINT8 configuration (symmetric INT8 with power-of-two scales) and the options AMD requires for NPU compilation: Int32Bias=False, enable_npu_cnn=True, DedicatedQDQPair=True and QuantizeAllOpTypes=True. Calibration uses the standard Ultralytics INT8 calibration loader, with the same letterbox, RGB and 0–1 preprocessing as inference.
3. Mixed precision: the model head stays in floating point, and the Vitis AI compiler runs it in BF16 on the NPU. Quantizing the head to INT8 causes most of the accuracy loss, and AMD's YOLOv8m tutorial keeps its post-processing tail out of INT8 for the same reason.
4. Compiler configuration: vitisai_config.json selects the VAIML target and the device from name.

Accuracy#

The table compares the exported INT8 model with the FP32 ONNX model on COCO val2017 (5,000 images) at 640, both run with ONNX Runtime on the host CPU. The INT8 models were calibrated on the default coco128.yaml dataset; calibrating on your own deployment images usually narrows the gap.

These host results run the quantized model with ONNX Runtime on the CPU, the baseline AMD's accuracy methodology compares NPU results against. AMD's published YOLOv8m results on the VEK385 show the same mixed-precision approach on the NPU:

Source: AMD YOLOv8m tutorial for Versal AI Edge Gen 2, which also reports a 10.69 ms average inference time over 100 VART runs at dp_size=1.

Compile and Run on Versal AI Edge Gen 2#

The exported directory is ready for AMD's Vitis AI compiler, which builds the .rai model that runs on the NPU.

1. Prepare the host and board. Compile on an x86-64 Linux host with AMD's Vitis AI 6.3 Docker image for Versal AI Edge Gen 2 and an AMD AI Engine compiler license (see AMD's licensing page). Set up the VEK385 with AMD's board setup guide.

2. Compile. Inside the container, create an ONNX Runtime session with the Vitis AI Execution Provider, the same call AMD's compilation guide uses. It writes the yolo26n/ cache with yolo26n.rai into the export directory:

   import onnxruntime as ort
   
   d = "yolo26n_xilinx_model"
   options = {"config_file": f"{d}/vitisai_config.json", "cache_dir": d, "cache_key": "yolo26n", "target": "VAIML"}
   ort.InferenceSession(f"{d}/yolo26n.onnx", providers=["VitisAIExecutionProvider"], provider_options=[options])

   Check yolo26n_xilinx_model/yolo26n/final-vaiml-pass-summary.txt for how much of the model runs on the NPU. For YOLO26n at 640, AMD's Vitis AI 6.3 compiler places 99.9% of the operators and of the compute on the VEK385 NPU in a single partition.

3. Run on the board. Copy the export directory to the VEK385. ONNX Runtime with the Vitis AI Execution Provider loads the compiled yolo26n.rai and runs it on the NPU, and YOLO("yolo26n_xilinx_model") selects this provider automatically when it is available.

Compilation needs only AMD's ONNX Runtime, so export on any Linux machine and copy the directory into the container rather than installing Ultralytics there, which can change the container's pinned packages. Where Ultralytics is installed alongside AMD's onnxruntime-vitisai build, as on the board, it keeps that build instead of replacing it with stock onnxruntime.

YOLO Model Compatibility and Supported Operators#

An accelerator only speeds up the operators it implements in hardware. When a model contains an unsupported operator, the compiler usually sends that part of the network to the Arm CPU, and each round trip between the accelerator and the CPU adds latency. Some operators cannot be partitioned: on the Versal AI Edge Gen 2 NPU, AMD lists operators such as NonZero and NonMaxSuppression that can force the entire model onto the CPU. Operator support is the most important factor in how well a YOLO model performs on AMD Xilinx hardware.

graph LR
    subgraph S1 [Stock YOLO26 on the DPU]
        A1[Conv]:::out --> A2[SiLU<br>CPU]:::error --> A3[Conv]:::out --> A4[SiLU<br>CPU]:::error --> A5[...]:::proc
    end
    subgraph S2 [Hard-Swish YOLO26 on the DPU]
        B1[Backbone<br>Conv + Hard-Swish<br>DPU]:::out --> B2[C2PSA attention<br>CPU]:::error --> B3[Neck<br>DPU]:::out --> B4[C3k2 attention<br>CPU]:::error --> B5[Detect head<br>DPU]:::out --> B6[Sigmoid and<br>post-processing<br>CPU]:::error
    end

    classDef proc fill:#2196F3,color:#fff
    classDef out fill:#9C27B0,color:#fff
    classDef error fill:#F44336,color:#fff

The table shows where each operator in a YOLO26 model runs. A stock YOLO26n ONNX export contains 87 SiLU activations, each exported as a Sigmoid and a Mul, plus 4 MatMul and 2 Softmax operators from its two attention blocks: the C2PSA block at the end of the backbone (layer 10) and the attention-enabled C3k2 block that produces the P5 output (layer 22).

Sources: AMD UG1414 supported operators, PyTorch operator support, and the Versal AI Edge Gen 2 supported, CPU partition and unsupported operator lists. Support also depends on your DPU configuration and graph patterns, so always check the compiler's partition report.

Make YOLO26 DPU-Ready with Hard-Swish#

The DPU fuses only ReLU, ReLU6, LeakyReLU, Hard-Swish and Hard-Sigmoid into its convolutions. Hard-Swish is a hardware-friendly approximation of SiLU, which makes it the natural replacement. Ultralytics model YAML files accept an activation key that changes the default activation of Conv blocks (Model YAML Configuration Guide).

Copy yolo26.yaml to yolo26-hswish.yaml and add one line under the parameters:

# Parameters
nc: 80 # number of classes
activation: nn.Hardswish() # default Conv activation, DPU-native
end2end: True # whether to use end-to-end mode

Then build the model, transfer the pretrained YOLO26 weights and fine-tune on your dataset:

from ultralytics import YOLO

# Build YOLO26n with Hard-Swish activations; the 'n' in the name selects the nano scale
model = YOLO("yolo26n-hswish.yaml").load("yolo26n.pt")  # transfer pretrained weights

# Fine-tune so the network adapts to Hard-Swish
model.train(data="coco8.yaml", epochs=100, imgsz=640)

Activations have no weights, so all of the pretrained weights transfer. The exported ONNX graph then contains 87 HardSwish operators and no SiLU. Replace coco8.yaml with your own dataset, and compare accuracy against the SiLU model with Val mode before deployment.

Handling Attention Blocks on the DPU#

YOLO26 applies attention at the lowest resolution (a 20×20 grid at 640 input) in two places: the C2PSA block at layer 10 and the attention-enabled C3k2 block at layer 22. YOLO11 has one C2PSA block. On a DPU their MatMul and Softmax operators run on the CPU, which splits the model into alternating DPU and CPU subgraphs. You have three options:

1. Accept the CPU blocks. The compiled .xmodel then contains CPU subgraphs, so run it with AMD's Graph Runner, which executes DPU and CPU subgraphs together when a CPU implementation exists for every operator; otherwise you must implement and register the missing operators. At 20×20 the attention computation is small, but each extra transfer between the DPU and the CPU adds latency, so measure it on your board.

2. Use an attention-free YAML. In your Hard-Swish YAML, replace the C2PSA layer with nn.Identity so the layer indices used by Concat and Detect stay valid, and disable attention in layer 22:

   backbone:
       # ... layers 0-9 unchanged
       - [-1, 1, nn.Identity, []] # 10 C2PSA removed; keeps later layer indices valid
   
   head:
       # ... layers 11-21 unchanged
       - [-1, 1, C3k2, [1024, True, 0.5, False]] # 22 (P5/32-large), attention disabled
       - [[16, 19, 22], 1, Detect, [nc]] # Detect(P3, P4, P5)

   The exported ONNX graph then contains no MatMul or Softmax operators. The attention weights no longer apply (624 of 666 YOLO26n weights transfer), so fine-tune longer and compare accuracy with Val mode.

3. Use an attention-free model such as YOLOv8, which AMD has used in its own DPU examples.

On Versal AI Edge Gen 2, attention operators are listed as NPU-supported, so these changes are usually unnecessary. Confirm placement in the compiler report, because AMD notes that supported operators can still fall back to the CPU because of configuration or memory constraints.

Model Compatibility at a Glance#

Deploying on Other AMD Xilinx Targets#

Zynq UltraScale+ and Kria DPUs and the first-generation Versal AI Edge NPU use Vitis AI flows that format="xilinx" does not produce. Train with Ultralytics, then build the target's artifact with AMD's tools in their x86-64 Linux Docker images. Choose the tab for your device:

Prepare the board with a hardware design and Linux image that contain the accelerator configuration you compiled for, plus the matching Vitis AI runtime. See AMD's setup guides for Zynq UltraScale+ and Kria DPU targets and Versal AI Edge (VEK280), then copy the artifacts your runtime needs:

On the DPU, VART buffers hold fixed-point INT8 values: query each tensor's shape and fix_point scale, quantize inputs and dequantize outputs before post-processing. The Graph Runner returns the full graph's outputs, while a DPU-only runner returns intermediate DPU subgraph outputs that your code must finish computing. VART-ML on the VEK280 defaults to hardware tensor views whose shape, data type and memory layout can differ from the ONNX layouts, so configure the runner's input and output tensor types as CPU views or convert the hardware format yourself (see AMD's VART-ML architecture overview).

Real-World Applications#

AMD Xilinx devices are common wherever vision AI must run in real time, at low power, close to the sensor:

• Industrial and construction safety: Detect people and machines around heavy equipment, and monitor work zones with object detection and object counting.
• Automotive and off-highway vision: Run camera-based perception on qualified automotive-grade parts, supporting autonomous vehicles and driver assistance.
• Smart cameras and video analytics: Combine video capture, encoding and YOLO inference on one chip for security systems and video analytics.
• Machine vision and quality inspection: Pair FPGA-based high-speed image capture with YOLO instance segmentation or classification for inline defect detection.
• Robotics and drones: Use Kria KR260 or Versal modules for pose estimation, oriented object detection and navigation with deterministic latency.

Summary#

Exporting with format="xilinx" quantizes Ultralytics YOLO models with AMD Quark for Versal AI Edge Series Gen 2 NPUs, keeps the head in BF16, and writes the Vitis AI compiler configuration beside the model. Validate the INT8 accuracy on any host, compile the .rai model in AMD's Vitis AI Docker image, and run it on the board with ONNX Runtime and the Vitis AI Execution Provider.

Older AMD Xilinx devices use other flows. The DPU on Zynq UltraScale+ and Kria uses the frozen Vitis AI 3.5 toolchain and .xmodel files, needs DPU-native activations such as Hard-Swish, and runs attention on the CPU. The first-generation Versal AI Edge NPU uses the snapshot flow, with operator coverage that depends on the Vitis AI version and precision.

For other deployment targets, see the model deployment options guide, deployment best practices, and accelerator integrations such as Hailo, Rockchip RKNN and Axelera.

FAQ#