Different behavior when exporting YOLOv8 vs YOLO11 to TFLite INT8 for MDLA (Genio 700)

NeuroPilot NeuroPilot - Analytical AI
, , ,
1

Hi,

I am working on deploying pose estimation models on a Genio 700 platform (MDLA 3.0), using TFLite INT8 models compiled with ncc-tflite.

I observed different behavior between YOLOv8 and YOLO11 models when following the same export pipeline.

System
Ubuntu 22.04
Python 3.10.12

Workflow

I export the models directly using Ultralytics:

YOLOv8:
yolo export model=yolov8s-pose.pt format=tflite imgsz=640 opset=17 simplify=True dynamic=False nms=False batch=1 int8=True

YOLO11:
yolo export model=yolo11n-pose.pt format=tflite imgsz=640 opset=17 simplify=True dynamic=False nms=False batch=1 int8=True

Then I compile on the dla using:
ncc-tflite --arch=mdla3.0 <file>.tflite

Results

$ 20240108_Neuron_SDK_v1.2402.01_neuron-6-0-release/host/bin/ncc-tflite --arch=mdla3.0 yolov8s-pose_full_integer_quant.tflite
$ 20240108_Neuron_SDK_v1.2402.01_neuron-6-0-release/host/bin/ncc-tflite --arch=mdla3.0 yolo11n-pose_full_integer_quant.tflite
ERROR: Fail to create tflite context

$ ls *.dla
yolov8s-pose_full_integer_quant.dla

YOLOv8:
TFLite model compiles successfully
DLA file is generated
Model runs correctly on device

YOLO11:
Compilation fails with:
“ERROR: Fail to create tflite context”

Observations

  • Both models are exported using the same parameters
  • Both are INT8 TFLite models
  • The workflow is identical
  • YOLOv8 works, YOLO11 does not

Question

What could cause this difference between YOLOv8 and YOLO11 when targeting MDLA?

  • Are there known operator differences or constraints between these models that affect MDLA compatibility?
  • Is there any recommended way to adapt YOLO11 models to make them compatible with MDLA?

Thanks in advance.

2

Hi Marco,

Thanks for following up!

To identify unsupported operators, you can use the benchmark_model tool with the stable_delegate mounted. This triggers the PreOpCheck mechanism to scan the model against the hardware support list and point out the exact unsupported OP or version.

For detailed instructions, please refer to this guide:
How to Identify Unsupported Operators When ncc-tflite Returns “Fail to create tflite context” Error

Best,
Jun

3

Hi Jun, thanks for the guidance.

I did further validation using benchmark_model on Genio 700, and I can confirm the issue seems related to operator version mismatch.

Operations on yolo11 model

ERROR: OP CONV_2D (v6) is not supported ()
ERROR: OP BATCH_MATMUL (v2) is not supported (Unsupported operation type.)
ERROR: OP SOFTMAX (v2) is not supported (Output type should be one of kTfLiteFloat32.)

Operations supported by Genio 700

ncc-tflite --show-builtin-ops

TFLite Operation Name          Supported Op Versions
CONV_2D                        1,2,3,4,5
SOFTMAX                        1,2,3
BATCH_MATMUL                   1,2,3,4

Questions
About downgrading OP version

  • What is the recommended way to force lower op versions during export?
  • YOLO11 export seems to generate newer op versions (e.g. CONV_2D v6), is there a recommended export pipeline or flags to keep compatibility with MDLA?
5

Hi @Marco_Madrigal ,

Directly specifying a specific op version during a .tflite model compilation isn’t a direct parameter in the standard TFLiteConverter API. The TFLite converter automatically determines the minimum required version for each operator based on the model’s attributes.

Some pathways might be helpful for the model design:

  • yolo seems have the opset option that you can choose the tflite opset to use that are compatible with Genio-700.
  • Downgrade the tflite_interpreter version that naturally restricts the OP version
  • Try with mtk_converter, that might get your converted model better compatibility with the NPU