Sharing a measurement in case it saves someone else the confusion, and because it changes how you would size a deployment.
Setup: Metis M.2 (metis-0:3:0, firmware 1.7.0, bc 7.4, 800 MHz), Voyager SDK 1.7.0, driver metis-dkms 1.5.5, yolov8n-coco-onnx, --aipu-cores 4 --pipe gst, Ubuntu 24.04.
┌─────────────────────────────────────────────┬───────────┬───────────┐
│ │ 1080p │ 4K │
├─────────────────────────────────────────────┼───────────┼───────────┤
│ inference.py … --output out.mp4 (16 clips) │ 34–61 FPS │ 13–16 FPS │
├─────────────────────────────────────────────┼───────────┼───────────┤
│ Headless app on create_inference_stream() │ 740 FPS │ 238 FPS │
├─────────────────────────────────────────────┼───────────┼───────────┤
│ SDK stage table, Metis element (both cases) │ ~840 FPS │ ~840 FPS │
└─────────────────────────────────────────────┴───────────┴───────────┘The headless 1080p figure (740) sits just under the AIPU stage rate (~840), which is what you would expect once inference is the actual limiter. The gap scales with pixel count rather than model complexity, which points at decode/annotate/encode rather than inference.
To be clear, this is not a defect: the SDK already exposes both numbers. The stage table shows the Metis element rate, and the launch tooling classifies the case correctly as bottleneck.category = output_encode_or_pipeline_queueing. It is just easy to miss when the headline figure is end-to-end FPS — and a first-time benchmark run leaves you thinking the M.2 does ~40 FPS on 1080p.
Practical takeaway: if your application consumes metadata (counting, tracking, alerting, analytics) rather than a rendered video, benchmark the headless path. The multi-stream sizing that follows is an order of magnitude different.
Full measurements, interpretation and reproduction: https://github.com/fxd0h/Axelera-Voyager-Local-Assistant/blob/master/FINDINGS.md
The app used for the headless numbers: https://github.com/fxd0h/Axelera-Voyager-Local-Assistant/tree/master/examples/metis-live-stats
While measuring this I also open-sourced the tooling I used: a local MCP server with semantic search over the public Axelera sources (SDK, driver, Yocto layers, AI SBC docs) plus the Voyager workflow skills, so an AI coding agent can work against the SDK offline with no account. MIT, runs in Claude Code or any MCP client: https://github.com/fxd0h/Axelera-Voyager-Local-Assistant
