Choosing an Edge AI Board: What Separates Jetson, Coral and Raspberry Pi 5

Sending video to the cloud for inference runs into three walls: latency, bandwidth cost and privacy. Continuously uploading footage from dozens of cameras is unaffordable on connectivity alone, and there are plenty of environments — factories, retail floors — where external transmission is restricted.

That is why edge AI, inferring on the device itself, becomes necessary. The problem is choosing a board, and here picking by the compute number (TOPS) usually fails. The real wall is not performance but constraints.

The structural differences between the three candidates

The crux is the precision and framework rows. That is where a project succeeds or fails.

Jetson: the fewest constraints

It carries an integrated GPU using CUDA, so a PyTorch model developed on a desktop loads almost unchanged. Convert with TensorRT and it is optimised to FP16 or INT8 for more performance.

# ONNX 모델을 FP16 TensorRT 엔진으로 변환
trtexec --onnx=model.onnx --saveEngine=model.plan --fp16

The advantage is freedom. Models with custom operators, the newest architectures, and running several models at once are all possible. Hardware video decoding is built in too, which helps pipelines handling multiple cameras.

The disadvantages are cost, power and heat. In environments running on battery or sealed inside an enclosure, those items can be decisive.

Coral TPU: cheap and fast, with a threshold

The Edge TPU runs only fully INT8-quantised TFLite models. That condition is stricter than it sounds.

# 양자화된 TFLite 모델을 Edge TPU용으로 컴파일
edgetpu_compiler model_int8.tflite

When the compiler meets an operator it does not support, every operation after that point falls back to the CPU. That is the common reason compilation succeeds and you get less than half the speed you expected. Always check the compile log for how many operations were mapped to the TPU.

When it fits: running classification or detection models from validated families such as MobileNet or EfficientNet-Lite at low power. Meet that condition and performance per watt is excellent.

When it does not: newer architectures, custom layers, models that lose significant accuracy when quantised. In that case you spend a lot of time and still cannot ship it.

Raspberry Pi 5 alone: how far without an accelerator

Inference runs on the CPU only. The CPU is much faster than the previous generation, so light models have become usable.

When it fits: work where a few frames per second is enough (periodic capture then classification, presence detection), prototypes, and the stage of checking first whether you can manage without an accelerator.

When it does not: real-time video object detection, several simultaneous streams.

The advantage is the ecosystem. There is the most material, the widest peripheral compatibility, and overwhelmingly more search results when something goes wrong. If you are starting out, beginning here and moving up once you have confirmed what is missing wastes the least.

The order to choose in

This order is more practical than comparing numbers.

1. Is the model already decided?
2. Decided and in the MobileNet family → look at Coral first
3. A custom model, or one still liable to change → Jetson

4. Not sure yet → prototype on a Raspberry Pi 5

5. Are there power constraints? On battery or solar, the Coral combination; on mains power, Jetson is also a candidate

6. What throughput do you need? Real-time multiple streams means Jetson; a few frames per second leaves the others open

7. How much developer time do you have? Coral costs time in quantisation and compilation. On a tight schedule, the option with fewer constraints can win on total cost

Development time is often more expensive than the board. Saving a few tens of dollars in hardware and then spending two weeks fighting quantisation is a net loss.

What trips people up in deployment

• Pin your versions: framework and driver version combinations are finicky on edge boards. When you find a combination that works, back it up as an image
• Containerise: Docker makes it easy to deploy the same environment to many units. GPU and TPU access needs extra configuration, though
• Remote updates: design from the start how you will update devices once they are in the field. Bolting it on later is far harder
• Heat and enclosures: measured performance depends heavily on cooling. In a sealed enclosure, throttling drops performance below benchmark figures

⚠️ Board specifications, prices and supported framework versions are as of August 2026 and may change. Real performance varies a great deal with the model, cooling and power conditions, so measure with your own target model before committing.