YOLOv8 Segmentation — EdgeFirst Model Zoo

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

[!NOTE] Anchor-free DFL detection head. Detection and instance-segmentation variants.

---

Reference accuracy — ONNX FP32

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

---

On-target validation results

• 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 — 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.

---

Validation pipeline

1. 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.
2. 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.
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.

---

Downloads

---

Inference example (Python)

EdgeFirst HAL — Hardware abstraction layer with accelerated inference delegates. The n-seg INT8 artifact loaded above is the default (logical) decoder; the accuracy-optimized smart decoder benchmarked in the tables ships alongside it as yolov8n-seg-int8-smart.tflite.

Traceability

---

See also

---

Train your own 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

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, scores, and mask coefficients 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

• boxes — (1, 4, 8400) normalized [0, 1] coordinates
• scores — (1, 80, 8400) per-class probabilities
• mask_coefs — (1, 32, 8400) per-anchor mask coefficients
• protos — (1, 160, 160, 32) prototype masks

Embedded metadata

• TFLite: edgefirst.json and labels.txt embedded in the ZIP-format model file
• ONNX: edgefirst.json embedded in model.metadata_props

---

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

---

Citation

---