EdgeFirst · Model Zoo / models · platforms · benchmarks · validation

AP_S is the COCO-style AP over small objects (area under 32² pixels), which make up most of VisDrone. Each variant trades input resolution against time per image; the Resolution & Tiling tab compares them platform by platform.

Each point is a public validation session: color = platform, shape = model family (● YOLOv5 · ■ YOLOv8 · ▲ YOLO11 · ◆ YOLO26). X axis is the realized sustained throughput on a log scale — the measured rate at which finished results leave the full validation pipeline. ⚠ flagged sessions are shown at their measured accuracy.

Each point is a public validation session: color = platform, shape = model family (● YOLOv5 · ■ YOLOv8 · ▲ YOLO11 · ◆ YOLO26). X axis is end-to-end per-image latency, from a frame being available to its results being ready (preprocess → inference → postprocess; image load and decode excluded), on a log scale — lower is better, so the top-left is the sweet spot. For the NXP i.MX 95 Neutron runner the latency-optimized pipeline (--serialize-core) is shown here; its throughput-optimized counterpart is on the chart above.

VisDrone latency is always time per image, whatever the image strategy: one 640² pass, one 1280² pass, one 1344×768 pass, or every tile of a tiled 640² pass plus slicing and merging. That keeps the four input variants directly comparable.

VisDrone is drone footage: most objects are a few pixels across, so small-object AP (AP_S) is the headline. Each model is published in four input variants, and each one buys AP_S with time per image:

• 640 is the baseline: one 640×640 pass over the whole frame.
• 1280 shows what a bigger input alone buys: one 1280×1280 pass.
• 1344x768 gives the best result: weights trained on tiles run natively on the whole frame, where memory allows.
• tiled (SAHI) slices the frame into 640×640 tiles and merges the detections. It serves constrained targets, and images larger than VisDrone's ~8 MP, while keeping the benefit of tiled training.

Every latency here is end-to-end per image, whatever the strategy, so the four variants compare directly. Each chart is one platform; each line is one configuration of the selected model, with one point per variant (● 640 · ■ 1280 · ▲ 1344x768 · ◆ tiled). Up and to the left is better.

⚠ Model accuracy on this platform is below our expectations — we are investigating the results to make improvements.

⚠ Model accuracy on this platform is below our expectations — we are investigating the results to make improvements.

Both leaderboards rank one input strategy at a time. Mixed together, the 640×640 pass would take every throughput slot, since it is the cheapest per image.

Top 20 fastest validated configurations · every runtime, precision and decode variant ranks on its own · realized FPS over the full validation pipeline · click a metric header to re-rank

Realized FPS is the measured steady-state throughput — stages overlap across frames, so it exceeds 1000 ÷ end-to-end latency. End-to-end latency runs from a frame being available to its results being ready (preprocess → inference → postprocess; image load and decode excluded). Measured by the EdgeFirst Profiler.

Ranked by COCO val2017 mAP@0.5-0.95 as measured on each platform by the EdgeFirst Profiler. Each entry links to its public validation session on EdgeFirst Studio.

⚠ Model accuracy on this platform is below our expectations — we are investigating the results to make improvements.