CoolFace
Modelpublic

Arm/yolo26n-fp16-litert

sourceHugging Faceagpl-3.0updated 20d agoView on Hugging Face
0likes26downloads
Model Card

YOLO26n FP16 — LiteRT

YOLO26n FP16 is a LiteRT object-detection model prepared for the XNNPACK FP16 packed-weight path.

✨ Key Highlights

  • —Lower latency — Delivers 1.85× faster p50 end-to-end inference than the FP32 baseline on Android™ Vivo X300.
  • —Higher throughput — On Android™ Vivo X300, processes 55.99 frames per second on one Arm® CPU core.
  • —Comparable quality — Achieves 40.23% mAP50–95 on COCO 2017 val, within 0.02 percentage points of the FP32 baseline.

📦 Model Details

Model Description

This package contains the YOLO26n object detector converted to LiteRT and arranged so XNNPACK can run Conv2D through its FP16 packed-weight path. The model accepts 640 × 640 images and returns up to 300 detections per image.

  • —Developed by: Ultralytics
  • —Model type: Object detector
  • —License: AGPL-3.0
  • —Base model: Ultralytics/YOLO26
  • —Packaged variant: LiteRT model prepared for FP16 execution with XNNPACK

Model Sources

  • —Base model: `yolo26n.pt` at revision 070ac3c51435984d992ba92eb3f234daf4e4500d
  • —Upstream repository: Ultralytics

🚀 Get Started with the Model

🔓 Compute Flow — Early Access

The inference engine for this model package is available through the Compute Flow Early Access Program.

Want to try it?

📩 Contact us at ai-early-access@arm.com to request access.

📊 Quality evaluation

Quality was evaluated on all 5,000 images in the COCO 2017 val2017 split at 640 × 640 input resolution with batch size 1. Higher mAP values are better.

MetricFP32 baselineFP16 optimizedChange
mAP50–9540.25%40.23%0.02 percentage points lower
mAP5055.78%55.78%No change
mAP7543.62%43.58%0.04 percentage points lower

🎯 Performance evaluation

Performance was measured under the following conditions:

  • —Target: Android™ Vivo X300.
  • —Runtime: One Arm® CPU core.
  • —Runs: 100 warmups followed by 100 measured runs.

The following methodology and definitions were used:

  • —The input was a batch of one 640 × 640 image from COCO 2017 val2017.
  • —End-to-end latency is the elapsed time from supplying the input image until final detections are available, including preprocessing, model inference, and post-processing.
  • —Average memory is the mean sampled resident memory of the benchmark process across measured runs.
  • —Peak memory is the maximum high-water-mark resident memory of the benchmark process across measured runs.
  • —Lower latency and memory values are better; higher frames-per-second values are better.

Compared with the FP32 baseline under the same protocol, the FP16 optimized profile provides the following results.

MetricFP32 baselineFP16 optimizedUplift
End-to-end latency, p5033.02 ms17.86 ms1.85× faster
End-to-end latency, p9034.628 ms19.026 ms1.82× faster
Frames per second30.2855.991.85× higher
Time to first inference35.579 ms19.313 ms1.84× faster
Model load time9.504 ms10.218 ms7.51% slower
Average memory82.36 MB82.45 MB0.11% higher
Peak memory82.39 MB82.50 MB0.13% higher

🛠️ Technical Specifications

Objective

The package provides YOLO26n for object detection with FP16-optimized LiteRT execution.

Runtime Architecture

Component roleFramework / format
Object detectorLiteRT (.tflite)
Runtime configurationObject-detection manifest (.json)
Class-name mappingJSON
Representative inputJPEG image

Precision and Quantization

The optimized profile executes Conv2D through XNNPACK's FP16 packed-weight path. The model keeps Conv2D weights as direct float32 constants and includes one unused float16 constant so runtime code can detect whether FP16 execution can be forced through XNNPACK. The input and output tensors use float32.

Input Specification

InputDescription
imgFloat32 tensor with shape [1, 3, 640, 640]

Output Specification

OutputDescription
outputFloat32 detection tensor with shape [1, 300, 6]

The manifest specifies external non-maximum suppression with a confidence threshold of 0.25, an NMS threshold of 0.4, a maximum of 300 detections per image, and non-normalized coordinates.

Repository Contents

  • —assets/class_names.json — COCO class-name mapping referenced by the manifest.
  • —benchmarks/yolo26n-fp16-litert-vivo-x300-fp16.yaml — FP16 quality and performance report for Vivo X300.
  • —benchmarks/yolo26n-fp16-litert-vivo-x300-fp32.yaml — FP32 baseline quality and performance report for Vivo X300.
  • —metadata.yaml — model and benchmark metadata.
  • —samples/sample.jpg — sample image for object_detection_cli smoke tests.
  • —yolo26n_conv2d_f16_weights.tflite — LiteRT object-detection model referenced by the manifest.
  • —yolo_manifest.json — object-detection manifest.
  • —SHA256SUMS — model-package checksums for reproducibility.

🗂️ Model and Asset Origin

  • —Model: yolo26n_conv2d_f16_weights.tflite was converted from the Ultralytics yolo26n.pt PyTorch checkpoint to LiteRT with litert-torch 0.9.1, using a wrapper that returns the [1, 300, 6] detection tensor. Starting from the FP32 LiteRT bundle, Conv2D weights were kept as direct float32 constants. One unused float16 constant was added so runtime code can detect whether FP16 execution can be forced through XNNPACK.
  • —Class names: assets/class_names.json contains COCO class labels from `coco.names`.
  • —Sample: samples/sample.jpg was copied from the YOLO26n FP32 LiteRT model bundle.

🔐 Checksums

SHA256SUMS was generated by recursively hashing every regular file in the model bundle, including files in subdirectories, except the generated root SHA256SUMS and paths with a dotfile component.

From the model bundle root, verify the checked-out files with:

sh
shasum -a 256 -c SHA256SUMS