[Feature Request]: Support E2E YOLO model

[hermeschen1116]

Request Description

I recently tried out the ultralytics release of the new E2E YOLO26 model using OpenVINO, but I noticed some hiccups when running inference on Intel NPU. I’ve reported this to ultralytics in this issue. They mentioned that OpenVINO might not support it at the moment. Would you be able to add support for this?

Feature Use Case

Deploy the new E2E YOLO26 model on an Intel NPU using OpenVINO.

Issue submission checklist

• The feature request or improvement must be related to OpenVINO

[krgkaushik]

Hi @hermeschen1116,

Thanks for the feature request. I am interested in helping with the enablement of the YOLO26 E2E architecture on NPU.

Since YOLO26 introduced the native NMS-free head (removing the DFL module), this is likely an operation support issue within the specific NPU plugin graph compilation.

To help me analyze the gap, could you please provide:

The Export Command: (e.g., yolo export model=yolo26n.pt format=openvino half=True)

The Error Log: Are you seeing a compilation failure (e.g., [ ERROR ] Node ... is not supported) or a runtime accuracy issue?

Ultralytics Version: Are you using the latest 8.4.x release?

Once you share this, I can try to reproduce the export locally and check the operation coverage using the benchmark_app tool.

[hermeschen1116]

I see you reply under the issue that I opened in ultralytics repo. Do you still need any other information?

[krgkaushik]

Yes, please!

While the logs show what the error is (datatype mismatch in the Floor operation), I need the best_int8_openvino_model.xml file to see exactly where in the graph that node is located.

Specifically, I need to see the input/output port names of that Floor node so I can write a Python script to inject the Convert layer precisely at that point.

Could you please attach just the .xml file (you don't need to upload the large .bin file) to the OpenVINO issue (#33918)? I will pick it up from there and draft the fix for you.

[hermeschen1116]

@krgkaushik Here you are.

best.xml
metadata.yaml

[hermeschen1116]

As @glenn-jocher mentioned in ultralytics issue.
Here is some extra information about this issue.

1. Hardware info

openvino: 2026.1.0-21000-6b20eaa9884                                                                                
devices: ['CPU', 'GPU.0', 'GPU.1', 'NPU']                                                                           
NPU versions: {'NPU': <Version: 2026.1.0-21000-6b20eaa9884 openvino_intel_npu_plugin>}     

2. I've tested to export model with agnostic_nms enabled, and it works on NPU.

[krgkaushik]

Hi @hermeschen1116,

Thanks for providing the XML! I've taken a look at the graph.

The issue stems from the NPU plugin requiring strict Floating Point inputs for Floor operations in this specific topology, but the export is passing a data type (likely from the anchor decoding or coordinate calculation) that causes a mismatch during the graph compilation on the NPU.

I have written a Python script below that uses the OpenVINO Runtime API to programmatically find the Floor node and inject a Convert layer (casting to FP32) immediately before it. This should resolve the datatype mismatch and allow the graph to compile on the NPU.

Fix Script (fix_yolo_npu.py)
You can run this script in the same environment where you have openvino installed:

from openvino.runtime import opset10 as ops
from pathlib import Path

def fix_floor_precision(model_path, output_path):
    core = ov.Core()
    print(f"Reading model: {model_path}")
    model = core.read_model(model_path)

    found = False
    for op in model.get_ops():
        # Look for the Floor operation
        if op.get_type_name() == "Floor":
            print(f"Found Floor node: {op.get_friendly_name()}")
            
            # Check the input element type
            input_type = op.input_value(0).get_element_type()
            print(f"Original Input Type: {input_type}")

            # If the input is NOT f32, we inject a Convert layer
            if input_type != ov.Type.f32:
                print(f"-> Injecting Convert (to f32) before {op.get_friendly_name()}...")
                
                # 1. Create the Convert node (Source -> Convert -> Floor)
                convert_node = ops.convert(op.input_value(0), destination_type=ov.Type.f32)
                
                # 2. Replace the input of the Floor node with the output of the new Convert node
                op.input(0).replace_source_output(convert_node.output(0))
                
                found = True
            else:
                print("-> Input is already f32. No changes needed for this node.")

    if found:
        # Validate and save the new model
        model.validate_nodes_and_infer_types()
        ov.save_model(model, output_path)
        print(f"\nSuccess! Fixed model saved to: {output_path}")
        print("Please try running this model on NPU.")
    else:
        print("\nNo non-f32 Floor nodes found. The model might already be correct or the issue lies elsewhere.")

if __name__ == "__main__":
    # Adjust filenames if needed
    fix_floor_precision("best.xml", "best_fixed.xml")```