Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 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. Environment 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 Training Command $ 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 Export Command $ 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. Neutron Compilation ~/Downloads/eiq-neutron-sdk-linux-3.1.3/bin/neutron-converter \ --target imx95 \ --input best_int8.tflite \ --output my_model_int8_npu.tflite Converter Output 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: WARNING: None of the operators from the graph was mapped to Neutron. WARNING: The converted model is the same as the input model because no operators were mapped to Neutron. WARNING: Graph has FLOAT operators which are NOT supported! This can result in low conversion ratio. Additional Information 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. Questions 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. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 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. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 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.
Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 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:
the graph is fully quantized,
there are no FLOAT operators,
weights are symmetric int8,
input/output tensor types are compatible, or converted with the Neutron converter uint8-to-int8 options if applicable,
YOLO post-processing such as decode/NMS is kept outside the NPU graph unless the exact operators are confirmed supported by the SDK.
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.
View full article
