When Should You Choose a ~3 TOPS NPU SoM for Embedded Vision on Debian?

One-line answer: Choose a ~3 TOPS SoM when the camera is fixed and one quantized vision model runs on the vendor’s Debian rootfs after the ISP. Use an SBC until you are ready to design the carrier. Prices and sample lead times stay out of this post.

“3 TOPS” is a label silicon vendors print on the NPU. The public example checked here is the Rockchip RV1126B class. The brief datasheet marks the NPU as 3TOPS and lists INT4, INT8, INT16, FP16, BF16, TF32, plus multimodal large-model support. Throughput, latency, module price, and sample dates are not in this post. The product page and the brief disagree on camera count and encode lines. Match the PDF for the revision you would buy, and the module pinout, instead of the larger number on a landing page.

Which camera workloads fit 3 TOPS local inference?

One-line answer: The ISP and the codec own the pixels. The NPU owns one quantized detect or classify graph behind them.

This label fits edge vision with a camera that stays fixed for the life of the product: faces, plates, objects, and other inputs you can quantize into a vendor graph such as RKNN. The RV1126B brief lists a 12M AI-ISP and MIPI CSI (2×4-lane or 4×2-lane, up to four sensors) on different lines from the NPU. Pixel rate and the NPU label are separate budgets. The codec’s 4K-class encode line is not the NPU line either.

The product page lists more cameras, a higher encode mode, and a “up to 2B” sentence. The brief does not give a parameter count. Do not adopt 2B, or a frame rate, as the acceptance test in this post. Whether it fits is a measurement of your quantized model at your resolution on the board. A published demo’s milliseconds are not a spec to copy.

WorkloadWhy this class comes up
One detect or classify graph after the ISP, with a stable inputThe NPU label is written for that graph
A small, fixed camera count inside the module pinoutCheck both the brief’s sensor cap and the lanes the board breaks out
Encode and storage booked on the codec and storage budgetA nicer video format does not enlarge the NPU label
An interactive large model is the productThe brief only says MLMs are supported. Parameter count and response time are unchecked

Stacking several models on one frame, or handing the sensor to the NPU with no ISP, is outside the default seat for this label. Attaching the sensor is part of what the BSP image is supposed to bring with it.

What should you check first in the Debian BSP?

One-line answer: Split “Debian” into an official ARM image and a rootfs on a vendor kernel. The NPU opens when the runtime matches that kernel, not when apt succeeds.

Module pages in the RV1126B class do list a Debian 12 rootfs next to Buildroot. That means the vendor ships a userspace. It does not mean a distro-stock kernel binds the ISP and the NPU. The RKNN-Toolkit2 README puts conversion on a PC and inference on the board through the RKNN C or Python API. It also says the RKNPU kernel driver is open source in the Rockchip kernel tree. Do not read that as “already merged in mainline.”

Check these before anything else:

  1. Which Debian release the rootfs is, and who rebuilds updates. Either the vendor reships images or you rebuild the rootfs.
  2. Whether the kernel and DTB are published with that module. A /dev/video* node shows up after the BSP binds the sensor.
  3. Whether the NPU runtime is in the image and matches the toolkit that baked the .rknn. Installing the converter on the board’s Debian is not the toolkit’s default flow. The host is a PC. The device is the runtime.
  4. Whether the graph names that chip. For RV1126B the conversion target is that platform. Leave another Rockchip chip’s .rknn behind.

The check that belongs here is whether Debian userspace, the vendor kernel, and a matching runtime arrive as one set.

What separates a SoM from an SBC?

One-line answer: The same NPU label can be either. A SoM is for when you design the carrier. An SBC is for proving the model and the Debian userspace before that.

RV1126B-class parts show up as modules and as vendor dev boards. Do not break the tie by comparing the TOPS label again.

SoMSBC or dev board
CarrierCamera connector, power, and enclosure I/O sit on your boardYou keep the vendor board
WhenAfter the production pinout and mechanics are realBefore you know the quantized model and Debian userspace run
BSPYou integrate the module DTB and kernel onto the carrierYou start from the vendor image, tied to that board’s connectors
What remainsCarrier design, pinning the runtime version, naming who ships updatesPut that board in a product case and the connector and thermal path stay the board’s

After .rknn runs on an SBC, moving to a SoM keeps the chip name and moves camera lanes and power sequencing onto the carrier. Sample dates and module price are quotes, not something this post fixes. Nothing here is a log from a board on the bench.

Sources