Set up a fair comparison

NCNN is a general-purpose inference runtime for mobile and embedded devices. Export the same YOLO26n checkpoint on your Pi, then validate both runtimes with the following data and settings:

  • Ultralytics 8.4.108
  • 640 × 640 input
  • Batch one
  • The Arm coco-128-by-sa dataset

Keep other CPU workloads stopped and use the same power, cooling, and CPU settings for both runs.

NCNN was selected because its performance came closest to the Arm Runtime in testing. You can use the same process to compare other runtimes.

Measure Arm Runtime for YOLO26 on Raspberry Pi 5

From the Optimized-Runtimes/yolo26-raspberry-pi-5 directory, run the Arm Runtime benchmark:

    

        
        
make ultralytics-benchmark

    

The first run downloads the Arm coco-128-by-sa dataset and prepares its validation configuration, alongside the model and benchmark environment. The custom backend is installed into benchmarks/ultralytics/.venv. Check that the log names ArmYolo26nPi5Backend.

Record the reported inference time. The command also saves its log and host observations under benchmarks/reporting/output/.

Export and measure NCNN

Use the same environment and the checkpoint already downloaded for your first run. Install NCNN and the exporter, then export on the Pi:

    

        
        
benchmarks/ultralytics/.venv/bin/python -m pip install ncnn==1.0.20260526 pnnx==20260526
benchmarks/ultralytics/.venv/bin/yolo export \
  model=downloads/checkpoints/yolo26n.pt format=ncnn imgsz=640 batch=1 device=cpu

    
Note

The exporter warns that end-to-end detection is being disabled for NCNN. This is expected; Ultralytics handles the remaining detection postprocessing. No action is needed—continue once the export succeeds.

The export creates downloads/checkpoints/yolo26n_ncnn_model/. Both runtimes use the same YOLO26n detection head and the same Ultralytics postprocessing and accuracy evaluation.

Use the validation configuration generated by the Arm benchmark so that NCNN reads the same images and labels:

    

        
        
DATASET_REVISION=97d6ea181e9dd0784db880b705e426ad23d424e1
DATASET_YAML="$PWD/downloads/datasets/coco-128-by-sa-$DATASET_REVISION/benchmark.yaml"
test -f "$DATASET_YAML"

    

Validate it with the same dataset and input settings, saving the terminal output:

    

        
        
set -o pipefail
benchmarks/ultralytics/.venv/bin/yolo val \
  model=downloads/checkpoints/yolo26n_ncnn_model \
  data="$DATASET_YAML" task=detect imgsz=640 batch=1 device=cpu \
  workers=0 plots=False 2>&1 | tee ncnn-validation.log

    

The model is exported with FP32 weights and runs on the CPU without Vulkan. On the test Pi, the pinned NCNN version defaults to four CPU threads with FP16 arithmetic enabled.

Both runs use the same checkpoint, dataset, and input size. They also use the same batch size and Ultralytics preprocessing and scoring pipeline. Internal precision and operation fusion can still differ between runtimes.

Compare the inference milliseconds per image reported by each validation run. Calculate the latency reduction as 100 × (NCNN time − Arm time) / NCNN time.

For reference, the Arm YOLO26n results were recorded on Raspberry Pi 5 at 640 × 640, batch one, using coco-128-by-sa (128 images, 1,025 instances). Inference time excludes preprocessing and postprocessing:

RuntimeInference (ms/image)mAP50–95
Arm Runtime for YOLO26 on Raspberry Pi 536.600.4863
NCNN67.200.4902

In these published results, the Arm runtime reduces inference latency by 45.5%, with a small difference in detection accuracy. Your results depend on software versions and hardware conditions.

For the full results table, see the repository performance results across runtimes . For the recorded software revision and host conditions, see the Arm runtime baseline .

What you’ve accomplished

You’ve deployed YOLO26n on Raspberry Pi 5, and seen how a runtime tailored to one model and CPU can reduce inference latency. You’ve learned how the application loads the compiled library and where inference fits within the wider detection pipeline. You’ve also exported the model to NCNN and compared both runtimes using the same validation workload.

Next, you can use that workflow with your own representative images to check whether the latency improvement and detection accuracy meet your needs. You can then measure the complete pipeline with your video or camera input.

Back
Next