Yolo26 - Classification with Resnet Backbone

[kfrohwergmh]

Hello!

Is there a specific reason why, unlike yolo11, there is no yaml configuration for yolo26-cls that provides a ResNet backbone?
At first glance, the architecture structure within the yaml files looks the same between yolo11 and yolo26.
In my use case, inference is slightly faster with a ResNet backbone for yolo11 due to hardware limitations. I would like to try this with "yolo26-cls-resnet", as the inference of yolo26-cls is slower than yolo11-cls-resnet, and compare the performance.

Thank you very much for your guidance and for providing this excellent work.

[UltralyticsAssistant]

👋 Hello @kfrohwergmh, thank you for your interest in Ultralytics 🚀! This is an automated response to help you get started, and an Ultralytics engineer will also assist soon 😊. We recommend a visit to the Docs for new users where you can find many Python and CLI usage examples and where many of the most common questions may already be answered.

If this is a 🐛 Bug Report, please provide a minimum reproducible example to help us debug it.

If this is a custom training ❓ Question (including custom yolo26-cls YAML/backbone experiments), please provide as much information as possible, including dataset image examples and training logs, and verify you are following our Tips for Best Training Results.

Join the Ultralytics community where it suits you best. For real-time chat, head to Discord 🎧. Prefer in-depth discussions? Check out Discourse. Or dive into threads on our Subreddit to share knowledge with the community.

Upgrade

Upgrade to the latest ultralytics package including all requirements in a Python>=3.8 environment with PyTorch>=1.8 to verify your issue is not already resolved in the latest version:

pip install -U ultralytics

Environments

YOLO may be run in any of the following up-to-date verified environments (with all dependencies including CUDA/CUDNN, Python and PyTorch preinstalled):

• Notebooks with free GPU:
• Google Cloud Deep Learning VM. See GCP Quickstart Guide
• Amazon Deep Learning AMI. See AWS Quickstart Guide
• Docker Image. See Docker Quickstart Guide

Status

If this badge is green, all Ultralytics CI tests are currently passing. CI tests verify correct operation of all YOLO Modes and Tasks on macOS, Windows, and Ubuntu every 24 hours and on every commit.

[glenn-jocher]

That Axis DLPU detail helps—your TF Lite analyzer output already shows why yolo26n-cls can lose badly on embedded accelerators: it includes attention-style ops like SOFTMAX and large MATMUL blocks (these commonly fall back to a slow path when the delegate/DLPU doesn’t support them), while ResNet is mostly CONV_2D and tends to get near-complete INT8 acceleration, so wall-clock latency can be far better even if params/FLOPs look “worse” on paper; if you can share any Axis delegate report/log that lists which ops are offloaded vs CPU, we can confirm quickly and suggest a more “DLPU-friendly” YOLO26 backbone choice (ResNet/MobileNet-style) per the TFLite export guide.

On the uint8 export changes: if you’d like this upstream, please open a GitHub issue with a tiny repro script + yolo checks output (see the MRE guide); also, for a PR we’d want to keep it export-scoped (avoid expanding default.yaml unless strictly necessary) and add a small export test to prevent regressions.

[kfrohwergmh]

I did not manage to get a true report/log which ops are offloaded vs cpu, but i found this table of ops that are supported by the axis artpec8-dlpu in the docs:

Operator Category	Operators
Neural Network	FullyConnected, Conv2d, DepthwiseConv2d, TransposeConv, MaxPool2d, AveragePool2d
Data Manipulation	Concatenation, Reshape, ExpandDims, Squeeze, Slice, StridedSlice, Gather, GatherNd, OneHot, Split, Transpose, ResizeNearestNeighbor, ResizeBilinear, Cast
Math	Add, AddN, Mul, Div, FloorDiv, Pow, Square, Sin, Tanh, Abs, Neg, Sqrt, Floor, Minimum, Maximum
Comparison	Equal, NotEqual, Less, LessEqual, Greater, GreaterEqual
Logic	LogicalNot, LogicalAnd, LogicalOr
Activation Functions	Relu, Relu6, Softmax, Gelu, Elu, HardSwish
Reduction	ReduceMin, ReduceMax, ReduceAny, ReduceProd
Indexing	ArgMin, ArgMax

My guess is, that everything that is not listed in this table is delegated to the cpu / fallback.

In addition to that there are other general optimization tips:

• Use per-tensor quantization.
• Prefer regular convolutions over depth-wise convolutions, which means that architecture like RegNet-18 are more efficient than MobileNet.
• Optimal kernel size is 3x3.
• Use stride 2 whenever possible as it is natively supported by the convolution engine. For other cases, consider using pooling.
• Ensure the number of filters per convolution block is a multiple of 6.
• Applying ReLU as the activation function after a convolution will result in a faster fused layer.
• Sparsification can improve the performance of the model.

Perhaps it is not only related to blocks but also to the activation function. To my knowledge, ReLu is also mainly used in the ResNet architecture while yolo is using SiLu (Swish). The Table itself refers only to HardSwish as supported op.
While researching how to make the use of Ops visible, I also came across a patch from AXIS for Yolov5 that makes the model usable for cameras by setting the activation function from SiLu to ReLu. But thats yolov5 so I dont know whether this can be transferred to Yolo 26.

[glenn-jocher]

You’re reading the Axis table correctly: anything not covered by the ARTPEC8 DLPU op set will fall back (or run inefficiently), and your analyzer already shows two common “deal-breakers” for embedded delegates—SiLU typically becomes a LOGISTIC + MUL pair (often not fused/offloaded), and the attention block introduces MATMUL-heavy paths that many NPUs/DLPUs don’t accelerate even if SOFTMAX exists. Given that, a TorchVision backbone that’s mostly CONV_2D + ReLU (ResNet/RegNet-style) is usually the right choice for this hardware, and it also matches Axis’ own guidance about fused conv+ReLU and avoiding exotic blocks.

Switching YOLO26’s internal activations from SiLU→ReLU (like some older Axis YOLOv5 patches) isn’t something we expose as an export-only knob today—you’d want to define/train the model with ReLU (not just export) and keep the backbone attention-free to stay “delegate-friendly”; if you open a feature request with your ARTPEC8 constraints and analyzer snippet we can track it, and in the meantime the safest path is continuing with the ResNet/RegNet YAML approach and validating at your real classification imgsz (usually 224). For general export/deployment gotchas that often look like “mystery slowdowns,” see our common YOLO troubleshooting guide.

[kfrohwergmh]

Alright, thank you very much for your advice

[glenn-jocher]

You’re welcome, and thanks for sharing the ARTPEC8 details; if you’d like the uint8 export path tracked upstream, please open a focused feature request with a small repro so the team can review it properly.