YOLO26 Detection models trained on COCO 2017 (80 classes) and validated on real edge hardware with the EdgeFirst Profiler, which runs the pipeline and computes the accuracy on the device itself. Each row in the tables below cites the EdgeFirst Studio validation session (v-XXXX) that produced the measurement.
[!TIP]
Training experiment: View on EdgeFirst Studio — dataset, training configuration, metrics, and exported artifacts.
[!NOTE]
End-to-end attention head. end2end=False required for INT8 export.
Reference accuracy — ONNX FP32
Accuracy ceiling for each size, measured against COCO val2017 (5,000 images) with pycocotools. Quantized and compiled artifacts (TFLite INT8, HEF, etc.) are graded against this reference per the EdgeFirst publication rule.
Sizes. The EdgeFirst Model Zoo currently validates Nano, Small, and Medium. The Large and XLarge variants are not evaluated at this time — their parameter and GFLOP counts are listed above for reference, with accuracy shown as —.
Accuracy methodology & relation to Ultralytics
Every model in this zoo uses the official Ultralytics pretrained weights, byte-for-byte — there is no re-training. These are the same models Ultralytics ships, measured on the deployment-realistic path: a fixed-input ONNX graph (square letterbox, rect=False), the standard COCO AP@[maxDets=100] convention, and COCO crowd regions scored as normal detections. Ultralytics' headline COCO numbers use their internal validator (rectangular inference, crowd-ignored, maxDets=300), so a small, fully-explained offset on identical weights is expected — not an accuracy deficit.
Full deployment path — fixed-input ONNX + pycocotools
Ultralytics-validator proxy
40.22%
Portable re-implementation of the Ultralytics validator
Ultralytics (official)
39.8%
Ultralytics' published COCO figure
The ~1 pp spread decomposes into a ~0.6–0.7 pp methodology leg (square-letterbox / crowd / maxDets) and a ~0.5–0.9 pp deployment-decode leg. The methodology leg is measured, not assumed: a rect=True + crowd-ignored parity pass reproduces the official figure (e.g. YOLOv5n → 34.4 vs 34.3 official). The decode leg shrinks toward zero for the NMS-free YOLO26, which already matches its official number. None of the offset reflects a weight or training difference.
On-target validation results
Each row is one EdgeFirst Studio validation session. Click the Source link to inspect the full session — model artifact, dataset version, parameters, per-stage Perfetto trace, and the host hardware description (hostname, kernel version, SoC, NPU, profiler version).
Row conventions in the table below:
Rows whose Δ cell reads ref are the float reference runs each quantized/compiled measurement is graded against.
Rows without a number under the metric columns are validation sessions currently in progress, or a session not yet linked to its ONNX FP32 reference. The Studio Source link tracks the current status.
Rows whose Δ vs FP32 cell carries a ⚠ are below our accuracy expectations for that platform (more than 10 percentage points under the float reference). The numbers are real measurements on real hardware, reproducible from the linked Studio session, and we publish them as-is; we are investigating the results to make improvements, and the next snapshot of this card will reflect any recovered accuracy.
Rows whose metric cells read In progress indicate platforms where this model family already runs on target but accuracy work is still in progress with the silicon vendor, so we withhold the numbers until that work lands. The Studio source link tracks the session; the next snapshot of this card will publish the measured results once resolved.
Precision varies by target: the ONNX reference rows are FP32; macOS CoreML and NVIDIA Jetson TensorRT run FP16; the NXP i.MX 8M Plus, NXP i.MX 95 Neutron, and Hailo NPUs run INT8. The NXP Ara240 DNPU runs a mixed INT8/INT16 scheme — most of the model is INT8, with the box-regression path (and the ops feeding it) promoted to INT16 to improve localization accuracy.
Decoder variants. EdgeFirst ships three INT8 split-decoders — smart, logical, and combined (described under Decode below). Every one we have measured is listed; none is headlined over another, because which one wins is a property of the target, not of the variant. Full converter documentation: EdgeFirst model conversion — these are the converters used by this Model Zoo and the EdgeFirst Performance Index report.
Runtime. Which inference stack executed the model. It is a column of its own because one accelerator can be reached by more than one: on Qualcomm Hexagon HTP, ONNX · QNN EP is an ONNX Runtime EPContext binary while LiteRT is the LiteRT + QNN delegate path, and the two produce measurably different pipelines from the same weights on the same silicon. Compare rows that share a size, platform, precision, and decode to read that difference directly.
Decode. What the exported graph emits, and therefore what your application has to do with it. Logical keeps the head's outputs separate and named — boxes, scores, and for segmentation the mask prototypes and coefficients — so reading them needs no decoder beyond taking the tensors as they come. Smart cuts the graph further upstream, at a point chosen by dynamic range and sliceability: the operations that quantize worst are lifted out of the model and run outside it, which is what recovers the accuracy, and which is why it needs a decoder implementing that cut (in EdgeFirst deployments, the HAL provides it). Combined fuses the decode into the quantized graph — the standard upstream export. It is the least accurate of the three by construction, and the EdgeFirst converters do not emit it for quantized targets; rows appear only where one was measured. Compare rows sharing a size and platform to see what the cut buys on your target — on detection it is often small, on quantized segmentation masks it is usually decisive. A — means the run carries no quantized decode split at all (float ONNX / TensorRT / CoreML).
Rows are not ranked. Where a size and platform appear more than once, the rows are competing configurations — a different runtime, precision, decode variant, pipeline mode, or board — not duplicates. Only genuinely repeated measurements of the same configuration are collapsed, newest first.
Platform-label suffixes.(FRDM) / (Phytec) name the NXP i.MX 95 development board a session ran on. — latency / — throughput mark the two pipeline configurations the NXP i.MX 95 Neutron and NXP Ara240 targets run: the latency pipeline runs inference serially for the lowest per-frame latency; the throughput pipeline runs multiple inference workers for the highest FPS, which raises per-call inference time in exchange. Rows with neither suffix run a single pipeline.
End-to-end (ms) is the sequential per-image latency of the compute pipeline — preprocess → inference → postprocess. Image acquisition (camera or file load + JPEG decode) overlaps these stages and is excluded from this figure.
Realized FPS vs Core-throughput ceiling (FPS).Realized FPS is the measured steady-state throughput — the rate at which final results are actually delivered over the full validation pipeline. It normally exceeds 1000 / end-to-end because the runtime overlaps stages across frames, and it is the true, priority number. Core-throughput ceiling (FPS) (shown with a ~) is the accelerator's core ceiling — 1000 / device-compute-time, the rate the NPU/DNPU could sustain if it were the only bottleneck — so it is a possibly-achievable note, not a claim. It is read from the isolated device-compute stage, which (unlike the host capture/preprocess stages, whose measured time inflates when the pipeline is backpressured) is stable and load-independent. Whether a deployment approaches it depends on the surrounding pipeline, and two levers dominate: (1) host bottlenecks — these validation runs decode a JPEG per image, whereas a live camera pipeline skips that decode and can run closer to the ceiling; and (2) confidence threshold — validation runs at 0.001 to capture every detection for mAP, which makes NMS/decode heavy, while a deployment threshold of 0.25–0.75 produces far fewer candidate boxes and lighter postprocessing, raising realized FPS toward the ceiling.
⚠ Below expectations — under investigation. The rows marked ⚠ above measure more than 10 percentage points below the same training session's float reference: the model accuracy on that platform is below our expectations. We publish the measured numbers rather than hiding them, and we are investigating the results to make improvements — the next snapshot of this card will reflect any recovered accuracy.
Validation pipeline
These results are produced by the EdgeFirst on-target validation pipeline:
EdgeFirst Profiler runs on the target hardware, executes the full inference pipeline (capture → preprocess → inference → postprocess), and scores the predictions against ground truth on the device. COCO accuracy and every timing block are computed in-process — there is no Python and no pycocotools on the target. It emits per-image predictions in EdgeFirst Arrow/Parquet, a Perfetto trace, and the computed metrics.
EdgeFirst Studio receives the metrics, predictions, charts and trace, and publishes them as the v-XXXX validation session every row above cites. Studio is where results are published, compared and browsed — it is not where they are computed.
EdgeFirst HAL (open source) provides the hardware-accelerated preprocessing and post-decoding primitives used at both validation and deployment time, so the timings measured here reflect the same accelerated paths a production runtime would take.
Inference latency is reported as the on-accelerator inference time. End-to-end latency is the sequential per-image latency across the compute pipeline — preprocessing, inference, and postprocessing; image acquisition (file or camera load and JPEG decode) overlaps these stages and is excluded from this figure.
Two throughput figures are reported. Realized FPS is the measured steady-state rate at which final results are emitted, measured directly from the profiler's per-frame result-emission timestamps over the steady-state stream — trace-independent; the Perfetto trace's own FPS is used only as a fallback on sessions where that scalar isn't available. It is the true, priority number and generally exceeds 1000 / end-to-end because the runtime overlaps stages across frames. Core-throughput ceiling (FPS) is the accelerator's core ceiling — 1000 / device-compute-time, i.e. the throughput if the accelerator were the only bottleneck. It is taken from the isolated device-compute stage (on transfer-split runtimes the trace separates host↔device transfers from device compute), which is load-independent — unlike the host capture/preprocess service times, whose measured cost inflates under pipeline backpressure (the same 5000 JPEGs cost ~7.8 ms/frame serialized but far more under throughput backpressure), so the slowest-stage figure would understate a fast accelerator. It is a possibly-achievable ceiling, not a measured result: reaching it depends on the deployment pipeline. A validation run decodes a JPEG per image and evaluates at a 0.001 confidence threshold (to capture every detection for mAP), both of which load the host and postprocess stages; a production camera pipeline (no JPEG decode) at a deployment threshold of 0.25–0.75 (far fewer candidate boxes through NMS) moves realized throughput toward the core-throughput ceiling.
Artifacts are organized by deployment target. Each model file embeds the EdgeFirst edgefirst.json metadata (training session, dataset version, calibration artifact, converter chain) so a single file is sufficient for deployment — no sidecar configuration required.
Browse and download every artifact from the repository file tree. Files are organized into per-target folders and follow the naming convention yolo26{size}-det-{precision}[-smart]{extension}:
Target
Folder
Format
ONNX FP32
onnx/
.onnx
TFLite INT8
tflite/
.tflite
NXP i.MX 95 (eIQ Neutron)
imx95/
.imx95.tflite
NXP Ara240
ara240/
.dvm
RPi5 + Hailo-8L (13 TOPS)
hailo/
.hailo8l.hef
NVIDIA Jetson (TensorRT)
jetson/
.engine
Snapdragon (Qualcomm Hexagon HTP)
qnn/
.htp-v81.qnn.onnx
Each file embeds its edgefirst.json metadata (training session, dataset version, calibration artifact, converter chain), so a single download is sufficient for deployment — no sidecar configuration required.
Inference example (Python)
python
1from edgefirst.hal import Model, TensorImage
23# Load the model — embedded edgefirst.json carries labels and decoder config4model = Model("yolo26n-det-int8.tflite")56# Run inference on an image7image = TensorImage.from_file("image.jpg")8results = model.predict(image)910# Iterate detections11for det in results.detections:12print(f"{det.label}: {det.confidence:.2f} at {det.bbox}")
EdgeFirst HAL — Hardware abstraction layer with accelerated inference delegates.
Traceability
Every measurement in the tables above is reachable through the EdgeFirst Studio validation framework. The v-XXXX Source link on each row resolves to a public Studio URL of the form:
The link lands on the Charts view — live system traces (CPU, memory, temperature, power) and per-stage timing recorded during the validation run. The Info and Metrics tabs on the same page carry the configuration and full COCO metric breakdown.
From there, the full provenance chain is one click deeper: training session ID, dataset version, calibration artifact, converter chain (e.g. TFLite quantizer + Neutron compile), validation parameters, and the host hardware description (hostname, kernel version, SoC, NPU, profiler version). The same model file you download from this repository embeds the same chain in its edgefirst.json metadata.
Split decoder — boxes and scores split into separate output tensors so each receives an independent INT8 quantization scale
Smart calibration — calibration samples selected via greedy coverage maximization; the artifact is content-addressed by parameter hash and cached in Studio for deterministic reuse
Full integer INT8 — uint8 input, int8 output, MLIR quantizer
Each tensor has its own quantization scale and zero point. The EdgeFirst HAL handles dequantization and reassembly automatically; no application code change is required across NPU targets.
Embedded metadata
TFLite: edgefirst.json and labels.txt embedded in the ZIP-format model file
ONNX: edgefirst.json embedded in model.metadata_props
No sidecar files required; the model artifact is self-contained.
Quantization loss — integer quantization introduces accuracy loss relative to FP32: INT8 on the NXP i.MX 8M Plus / i.MX 95 Neutron and Hailo NPUs, and a mixed INT8/INT16 scheme on the NXP Ara240 (the box-regression path is promoted to INT16 for localization accuracy). The magnitude per platform is shown in the Δ vs FP32 column above.
Configurations under active investigation — a subset of INT8 results measure below expectations and are marked ⚠ above; these are tracked for resolution, not accepted as final. The main cases are YOLO11 / YOLO26 on the NXP i.MX 8M Plus VeriSilicon NPU (the most constrained accelerator, where the newer architectures quantize poorly) and some NXP Ara240 segmentation runs. YOLO11 / YOLO26 on the NXP i.MX 95 eIQ Neutron NPU are not yet supported (a delegate limitation) and render without numbers. Each next card snapshot reflects any recovered accuracy.
Input resolution — all models expect 640×640 input; other resolutions require letterboxing.
The validation results, this model card, and its metadata are Au-Zone Technologies' own contribution, licensed CC BY-NC 4.0 (Attribution — NonCommercial) — see the repository LICENSE for the full text and citation requirements.
Citation
bibtex
1@software{edgefirst_yolo26_det,
2 title = { {YOLO26 Detection — EdgeFirst Model Zoo} },
3 author = {Au-Zone Technologies},
4 url = {https://huggingface.co/EdgeFirst/yolo26-det},
5 year = {2026},
6 license = {CC-BY-NC-4.0},
7}
