EdgeFirst/yolov8-det

YOLOv8 Detection — EdgeFirst Model Zoo

YOLOv8 Detection models trained on COCO 2017 (80 classes) and validated on real edge hardware through the EdgeFirst Profiler + Validator pipeline. Each row in the tables below cites the EdgeFirst Studio validation session (v-XXXX) that produced the measurement.

Part of the EdgeFirst Model Zoo.

Training experiment: View on EdgeFirst Studio — dataset, training configuration, metrics, and exported artifacts.

Anchor-free DFL detection head. Detection and instance-segmentation variants.


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.

Size	Params	GFLOPs	mAP@0.5	mAP@0.5-0.95	mAP@0.75	Source
Nano	3.2M	8.9	50.49%	35.83%	38.84%	v-a88
Small	11.2M	28.8	59.40%	43.22%	46.68%	v-a8f
Medium	25.9M	79.3	64.68%	48.45%	52.62%	v-a96
Large	43.7M	165.7	—	—	—	—
XLarge	68.2M	258.5	—	—	—	—

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), stock pycocotools AP@[maxDets=100], 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.

Reconciling nano detection (COCO val2017, mAP@0.5:0.95, FP32):

Source	Nano mAP@0.5:0.95	What it measures
EdgeFirst (this zoo)	35.83%	Full deployment path — fixed-input ONNX + pycocotools
Ultralytics-validator proxy	36.71%	Portable re-implementation of the Ultralytics validator
Ultralytics (official)	37.3%	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.
• 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. The table headlines the accuracy-recovering ones: smart (per-tensor rescaling — best accuracy, extra CPU ops add some latency) and, where a smart run is absent, logical (the latency-optimized default — no CPU overhead, slightly lower accuracy). The combined decoder is the standard-quantization baseline (equivalent to typical single-scale INT8, and how the reference numbers are produced); it loses the most accuracy — especially on segmentation, where box/mask dynamic range collapses under one scale — so it is published only as a downloadable reference artifact and in the metrics export, never headlined here. Smart and logical exist precisely to recover that loss. Full converter documentation: EdgeFirst model conversion — these are the converters used by this Model Zoo and the EdgeFirst Performance Index report.
• 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.

Size	Platform	mAP@0.5	Δ vs FP32 (pp)	mAP@0.5-0.95	Inference (ms)	End-to-end (ms)	Realized FPS	Core-throughput ceiling (FPS)	Source
Nano	ONNX FP32 (Intel Core i9-13900F · 32-core)	50.49%	+0.00	35.83%	38.01	49.96	71.6	~72	v-a46
Nano	ONNX FP32 (CUDA)	50.49%	ref	35.83%	8.04	13.22	350.5	~350	v-a88
Nano	ONNX FP16 (CUDA)	50.49%	+0.00	35.79%	6.23	11.70	457.3	~457	v-a9d
Nano	Apple M2 Max — CoreML Neural Engine (FP16)	50.12%	-0.37	35.52%	1.80	5.26	791.0	~744	v-9cd
Nano	Apple M2 Max — CoreML Metal GPU (FP16)	50.13%	-0.36	35.52%	6.00	9.73	445.0	~445	v-9ce
Nano	Apple M2 Max — CoreML CPU (FP16)	50.14%	-0.35	35.50%	15.93	19.96	117.5	~117	v-9cf
Nano	NXP i.MX 8M Plus + VeriSilicon NPU (FRDM)	49.36%	-1.13	34.78%	61.10	113.47	13.9	~16	v-8c7
Nano	NXP i.MX 95 + eIQ Neutron NPU — throughput	48.77%	-1.72	34.34%	45.47	73.31	76.5	~62	v-79e
Nano	NXP i.MX 95 + eIQ Neutron NPU (FRDM) — latency	47.38%	-3.11	32.08%	44.44	59.21	21.6	~22	v-a3d
Nano	NXP i.MX 95 + eIQ Neutron NPU (FRDM) — throughput	47.38%	-3.11	32.08%	60.72	80.24	62.6	~63	v-a3e
Nano	NXP Ara240 (FRDM) — latency	46.63%	-3.86	32.13%	6.46	18.54	127.9	~131	v-a12
Nano	NXP Ara240 (FRDM) — throughput	46.63%	-3.86	32.13%	6.87	49.38	210.8	~298	v-a13
Nano	Raspberry Pi 5 + Hailo-8L NPU	49.80%	-0.69	35.22%	13.20	24.86	64.9	~65	v-8df
Nano	NVIDIA Jetson Orin Nano (TensorRT FP16)	50.50%	+0.01	35.79%	11.93	26.90	259.7	~259	v-91a
Small	ONNX FP32 (Intel Core i9-13900F · 32-core)	59.40%	+0.00	43.22%	94.66	106.27	29.8	~30	v-a4d
Small	ONNX FP32 (CUDA)	59.40%	ref	43.22%	15.48	20.84	204.5	~204	v-a8f
Small	ONNX FP16 (CUDA)	59.37%	-0.03	43.19%	10.64	16.31	299.3	~299	v-aa4
Small	Apple M2 Max — CoreML Neural Engine (FP16)	58.80%	-0.60	42.78%	5.01	8.46	342.6	~344	v-9ed
Small	Apple M2 Max — CoreML Metal GPU (FP16)	58.82%	-0.58	42.73%	15.93	19.52	178.9	~179	v-9ee
Small	Apple M2 Max — CoreML CPU (FP16)	58.83%	-0.57	42.70%	32.00	36.09	60.1	~60	v-9ef
Small	NXP i.MX 8M Plus + VeriSilicon NPU (FRDM)	58.80%	-0.60	42.45%	116.71	168.28	7.8	~8	v-93f
Small	NXP i.MX 95 + eIQ Neutron NPU (FRDM) — latency	58.62%	-0.78	42.29%	39.46	74.22	23.4	~24	v-902
Small	NXP i.MX 95 + eIQ Neutron NPU (FRDM) — throughput	58.62%	-0.78	42.29%	146.86	182.46	26.4	~26	v-903
Small	NXP i.MX 95 + eIQ Neutron NPU (Phytec) — throughput	58.62%	-0.78	42.29%	141.60	174.37	27.4	~27	v-8f3
Small	NXP Ara240 (FRDM) — latency	56.72%	-2.68	39.83%	10.12	22.27	87.4	~88	v-a20
Small	NXP Ara240 (FRDM) — throughput	56.70%	-2.70	39.81%	10.27	24.17	142.4	~142	v-a21
Small	Raspberry Pi 5 + Hailo-8L NPU	58.52%	-0.88	42.34%	30.36	45.07	28.8	~29	v-8ec
Small	NVIDIA Jetson Orin Nano (TensorRT FP16)	59.38%	-0.02	43.15%	24.62	37.12	157.5	~157	v-922
Medium	ONNX FP32 (Intel Core i9-13900F · 32-core)	64.68%	+0.00	48.44%	243.22	255.15	11.8	~12	v-a54
Medium	ONNX FP32 (CUDA)	64.68%	ref	48.45%	43.49	49.46	78.5	~78	v-a96
Medium	ONNX FP16 (CUDA)	64.68%	+0.00	48.40%	23.13	29.44	147.7	~148	v-aab
Medium	Apple M2 Max — CoreML Neural Engine (FP16)	63.82%	-0.86	47.68%	13.41	17.27	140.9	~142	v-75e
Medium	Apple M2 Max — CoreML Metal GPU (FP16)	63.82%	-0.86	47.70%	37.93	42.15	77.0	~77	v-768
Medium	Apple M2 Max — CoreML CPU (FP16)	63.87%	-0.81	47.68%	61.61	65.71	31.8	~32	v-9dd
Medium	NXP i.MX 8M Plus + VeriSilicon NPU (FRDM)	63.49%	-1.19	47.22%	222.33	274.39	4.3	~4	v-983
Medium	NXP i.MX 95 + eIQ Neutron NPU (FRDM) — latency	63.51%	-1.17	47.11%	101.26	135.73	9.5	~10	v-974
Medium	NXP i.MX 95 + eIQ Neutron NPU (FRDM) — throughput	63.51%	-1.17	47.11%	393.79	429.57	10.0	~10	v-976
Medium	NXP i.MX 95 + eIQ Neutron NPU (Phytec) — throughput	63.51%	-1.17	47.11%	387.27	419.61	10.2	~10	v-94f
Medium	NXP Ara240 (FRDM) — latency	60.01%	-4.67	42.67%	21.57	33.60	43.8	~44	v-a2e
Medium	NXP Ara240 (FRDM) — throughput	59.99%	-4.69	42.66%	21.56	34.45	54.1	~54	v-a2f
Medium	Raspberry Pi 5 + Hailo-8L NPU	63.88%	-0.80	47.67%	56.26	71.51	16.9	~17	v-90a
Medium	NVIDIA Jetson Orin Nano (TensorRT FP16)	64.67%	-0.01	48.41%	52.44	64.24	75.3	~75	v-92b

---

Validation pipeline

These results are produced by the EdgeFirst on-target validation pipeline:

1. EdgeFirst Profiler runs on the target hardware, executes the full inference pipeline (image load → decode → preprocess → inference → postprocess), and emits per-image predictions in EdgeFirst Arrow/Parquet plus a Perfetto trace.
2. EdgeFirst Validator consumes the predictions and trace, computes pycocotools accuracy metrics and per-stage timing summaries, and publishes the results to the Studio validation session.
3. 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.

See EdgeFirst Studio for the full validation pipeline.

---

Downloads

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 yolov8{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

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)

from edgefirst.hal import Model, TensorImage

# Load the model — embedded edgefirst.json carries labels and decoder config
model = Model("yolov8n-det-int8.tflite")

# Run inference on an image
image = TensorImage.from_file("image.jpg")
results = model.predict(image)

# Iterate detections
for det in results.detections:
    print(f"{det.label}: {det.confidence:.2f} at {det.bbox}")

EdgeFirst HAL

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:

https://edgefirst.studio/public/validation/v-XXXX/details?mode=charts

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.

---

See also

Other model families in the EdgeFirst Model Zoo:

Model	Task	Link
YOLOv5 Detection	Detection	EdgeFirst/yolov5-det
YOLOv8 Segmentation	Segmentation	EdgeFirst/yolov8-seg
YOLO11 Detection	Detection	EdgeFirst/yolo11-det
YOLO11 Segmentation	Segmentation	EdgeFirst/yolo11-seg
YOLO26 Detection	Detection	EdgeFirst/yolo26-det
YOLO26 Segmentation	Segmentation	EdgeFirst/yolo26-seg

---

Train your own with EdgeFirst Studio

Train on your own dataset with EdgeFirst Studio:

• Free tier includes YOLO training with automatic INT8 quantization and edge deployment.
• Upload datasets via EdgeFirst Recorder or COCO/YOLO format.
• AI-assisted annotation with auto-labeling.
• CameraAdaptor integration for native sensor format training.
• Deploy trained models to edge devices via EdgeFirst Client.

---

Technical notes

Quantization pipeline

All TFLite INT8 models are produced by EdgeFirst's quantization pipeline (details):

1. ONNX export — standard Ultralytics export with simplify=True
2. TF-wrapped ONNX — box coordinates normalized to [0, 1] inside DFL decode
3. Split decoder — boxes and scores split into separate output tensors so each receives an independent INT8 quantization scale
4. Smart calibration — calibration samples selected via greedy coverage maximization; the artifact is content-addressed by parameter hash and cached in Studio for deterministic reuse
5. Full integer INT8 — uint8 input, int8 output, MLIR quantizer

Split decoder output format

Detection (e.g. yolov8n):

• boxes — (1, 4, 8400) normalized [0, 1] coordinates
• scores — (1, 80, 8400) per-class probabilities

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.

---

Limitations

• COCO bias — models trained on COCO (80 classes) inherit the dataset's biases (Western-centric scenes, particular object distributions, limited weather/lighting diversity).
• 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.

---

License

Model weights in this repository are derived from Ultralytics YOLO and remain © Ultralytics Inc., licensed AGPL-3.0 — use requires AGPL-3.0 compliance or an Ultralytics Enterprise License.

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

@software{edgefirst_yolov8_det,
  title = { {YOLOv8 Detection — EdgeFirst Model Zoo} },
  author = {Au-Zone Technologies},
  url = {https://huggingface.co/EdgeFirst/yolov8-det},
  year = {2026},
  license = {CC-BY-NC-4.0},
}

---

_{EdgeFirst Studio · GitHub · Docs · Au-Zone Technologies
Model weights © Ultralytics Inc. (AGPL-3.0) · Validation results & card © 2026 Au-Zone Technologies (CC BY-NC 4.0)
NXP^®, i.MX, eIQ^®, Neutron, and Ara240 are trademarks or products of NXP Semiconductors. Hailo is a trademark of Hailo Technologies Ltd. Jetson is a trademark of NVIDIA Corporation. All other trademarks are the property of their respective owners.}