Hello NXP Support Team,
We are evaluating object detection on the FRDM i.MX95 platform using the Neutron SDK v3.1.3 and are unable to generate an NPU-compatible model. The Neutron converter successfully loads the model, but reports that 0 operators are mapped to the Neutron NPU.
Target Board: FRDM i.MX95
Neutron SDK: 3.1.3
Ultralytics: Tested with both YOLO11 and YOLOv8
eIQ Toolkit: Used for ONNX → TFLite conversion
Model: Custom single-class peg detector
$ yolo detect train \ model=yolov11n.pt \ data=/visual_inspect_yolo/dataset/dataset.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ project=models \ name=peg_detector_v8
$ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml
We also tested an alternative workflow:
Export PyTorch → ONNX
Convert ONNX → INT8 TFLite using the NXP eIQ Toolkit
Both workflows produced the same result when compiled with the Neutron SDK.
~/Downloads/eiq-neutron-sdk-linux-3.1.3/bin/neutron-converter \ --target imx95 \ --input best_int8.tflite \ --output my_model_int8_npu.tflite
The converter reports:
Operators after import: 341
Operators after optimization: 367
Operators converted: 0
Operator conversion ratio: 0 / 367
Number of Neutron graphs: 0
Warnings:
We observed the same behavior with:
YOLO11
YOLOv8
Direct Ultralytics TFLite export
ONNX → eIQ Toolkit → INT8 TFLite
All generated TFLite models result in 0 operators being mapped by the Neutron compiler.
Are YOLOv8 or YOLO11 object detection models officially supported by the Neutron compiler for the i.MX95?
Is there a recommended export pipeline for YOLO models targeting the i.MX95 NPU?
Are there any known limitations with the current Neutron SDK (v3.1.3) regarding YOLO detection heads?
Does NXP provide a reference YOLOv8/YOLO11 model that successfully compiles for the i.MX95 NPU?
Is there any additional compiler option or preprocessing step required to enable operator mapping?
We would appreciate any guidance, recommended workflows, or reference models that are known to work with the i.MX95 Neutron NPU.
Thank you.
Thank you for your response.
I would like to inquire if there is a standard procedure available for training, exporting, and deploying models on the IMX95 board.
As we currently have the ARA2, we are looking to fully utilize its capabilities and customize our models. We have upcoming demos for NXP Tech Days, and your assistance in this matter would be greatly appreciated.
Thank you for your help.
Tried the yolo8m model from eIQ model zoo on imx95 board with LF 2026 Q2 release image. kernel version is 6.18.20 using neutron SDK 3.1.2. it works.
You can try it firstly by:
wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite
root@imx95evk:/usr/bin/tensorflow-lite-2.19.0/examples# ./benchmark_model --graph=yolov8n-det-int8-smart.imx95.tflite --external_delegate_path=/usr/lib/libneutron_delegate.so
more info you can refer the README eiq-model-zoo/tasks/vision/object-detection/yolov8 at main · NXP/eiq-model-zoo
What's more, you can attached model and details log of convert/complier.
Based on the converter log, the first issue to resolve is that the generated TFLite model still contains FLOAT operators:
WARNING: Graph has FLOAT operators which are NOT supported!
For i.MX95 Neutron, the input to neutron-converter must be a TFLite model whose operators and quantization format are compatible with the Neutron compiler. In particular, the i.MX95 Neutron flow expects quantized TFLite and symmetric int8 weights. If the model still contains FLOAT operators/tensors after the Ultralytics export or ONNX-to-TFLite conversion, the converter may be unable to create any Neutron-compatible subgraph, which is consistent with the reported result:
Operators converted: 0
Number of Neutron graphs: 0
YOLOv8 has been evaluated on i.MX95 in some flows, but full end-to-end YOLOv8/YOLO11 offload should not be assumed for arbitrary Ultralytics exports. Depending on the exported TFLite graph, only part of the model may be converted to NeutronGraph and unsupported operators will remain on CPU. Therefore, the recommended next step is to inspect/profile the generated TFLite model and confirm:
Please also ensure that the neutron-converter version and the Neutron runtime/firmware/delegate on the board are from the same compatible SDK/BSP release.
As a recommended flow, please try the NXP/eIQ conversion path:
PyTorch -> ONNX with static input shape -> NXP/eIQ quantization with representative calibration data -> quantized TFLite -> neutron-converter --target imx95
If the model has uint8 input/output tensors, please also test:
--convert-inputs-uint8-to-int8
--convert-outputs-uint8-to-int8
If the conversion still reports 0 mapped operators after removing FLOAT operators, please share:
- the complete neutron-converter log with verbose/profiling output if available,
- the TFLite operator list,
- tensor data types and quantization parameters,
- the exact BSP/runtime Neutron delegate/firmware versions on the FRDM i.MX95 board,
- whether the YOLO detection head includes NMS or other post-processing inside the TFLite graph.