Why a 10 TOPS NPU Does Not Guarantee High FPS¶
TOPS is a theoretical operation rate under particular precision and workload assumptions. Product frame rate is an end-to-end property of the whole data path.
TOPS is not end-to-end FPS¶
Camera → colour conversion / resize → tensor preparation → NPU inference
→ decode / NMS → OSD, display, encoding, or reporting
Even with 10 ms inference, another 30 ms in capture, preprocessing, buffer synchronization, postprocessing, and display yields 40 ms end-to-end—about 25 FPS. Time every stage rather than recording only inference time.
A model may not run entirely on the NPU¶
Unsupported or slow operators, dynamic shapes, incompatible quantization, and pre/post-processing can fall back to the CPU. Detection backbones may execute on an NPU while decoding, coordinate transforms, filtering, and NMS remain on the CPU. Confirm operator placement and fallbacks with runtime logs or profiling.
Moving data can cost more than computing¶
Camera output such as NV12, YUYV, or MJPEG commonly needs conversion to a model's RGB/BGR format, size, and layout. A path through application, conversion, NPU, and display/encoder buffers repeatedly reads and writes DDR.
DMA-BUF, buffer reuse, and fewer format conversions reduce copies. Zero-copy still has costs: cache synchronization, stride and format alignment, fences, and buffer lifetime management.
Concurrency magnifies bottlenecks¶
In isolation, camera, NPU, GPU, VPU, and display do not compete much. In a product they contend for DDR and the SoC interconnect. CPU and NPU utilization can look modest while FPS stalls because the real wait is memory bandwidth, synchronization, or arbitration.
| Stage | Check first |
|---|---|
| Input | Frame rate, resolution, format, drops |
| Preprocessing | Colour conversion, resize, normalization time |
| Buffers | memcpy count, DMA-BUF, cache synchronization |
| NPU | Inference time, operator placement, CPU fallback |
| Postprocessing | Decode, NMS, sorting, filtering |
| System | DDR, IRQs, concurrent camera/VPU/GPU/display load |
A higher TOPS number is not always the answer. Fewer copies, hardware-friendly formats and quantization, smaller input, lower CPU postprocessing, and deliberate buffer reuse often improve the actual bottleneck.