How should you choose an edge device for computer vision? The embedded edge device selection for CV deployment is not primarily a performance benchmarking exercise. The right device depends on the inference model, the required throughput, the power budget, the integration constraints, and — often decisive — what model optimisation work your team can realistically execute and maintain. A device with twice the raw TOPS may be the wrong choice if its toolchain demands graph-level surgery your team is not staffed for. This article compares the four embedded CV platforms we see most often in production: NVIDIA Jetson, Google Coral TPU, Hailo, and OAK-D. For the broader trade-off space — latency budgets, accuracy targets, and architectural patterns — see our companion piece on how to deploy computer vision models on edge devices. Platform comparison overview Platform Compute Type Peak Performance Power Model Format Ecosystem Maturity NVIDIA Jetson Orin Nano GPU + CPU + DLA 40 TOPS 7–15W TensorRT, ONNX, PyTorch High NVIDIA Jetson Orin NX GPU + CPU + DLA 100 TOPS 10–25W TensorRT, ONNX, PyTorch High Google Coral Dev Board Edge TPU 4 TOPS (TPU) 2–4W TFLite (INT8) Moderate Hailo-8 M.2 Neural processor 26 TOPS 2.5W Hailo Dataflow Compiler Moderate Hailo-8L Neural processor 13 TOPS 1.5W Hailo Dataflow Compiler Moderate OAK-D (Myriad X VPU) VPU 4 TOPS 2–4W OpenVINO IR Moderate One caveat the table cannot show: TOPS comparisons across different hardware architectures are not directly comparable. A GPU TOPS does not equal a TPU TOPS for the same model, because utilisation depends on operator coverage, memory bandwidth, and how well the model graph maps to the device’s compute primitives. The only honest number is the one you measure on your model on the device you intend to ship. This is an observed pattern across our edge engagements — we treat published peak TOPS as a rough screening filter, not a deployment specification. NVIDIA Jetson Jetson is the most flexible embedded CV platform and carries the most mature ecosystem. It runs standard PyTorch and TensorFlow, supports CUDA, and provides TensorRT for optimised deployment. Models developed in a standard GPU training environment deploy to Jetson with minimal code changes — the same ONNX export and TensorRT engine build path that works on a desktop RTX card works on an Orin module. Strengths: Full CUDA support — standard GPU deep learning code runs with minimal modification. TensorRT provides a substantial throughput improvement (we typically observe 3–5× over native PyTorch, depending on the model and precision; this is a planning heuristic from our engagements, not a vendor benchmark). JetPack SDK ships a complete environment (CUDA, cuDNN, TensorRT, DeepStream). Wide model support — virtually any architecture that runs on a desktop GPU runs on Jetson. Camera and sensor integration is well-supported (CSI cameras, USB cameras, RTSP streams). Weaknesses: Higher power consumption than TPU/NPU alternatives (7–25W vs 1.5–4W for Coral and Hailo). Higher unit cost: the Jetson Orin Nano module is roughly $150–200 at list; a carrier board adds further cost. Thermal management required — sustained inference loads need active cooling or the device will thermally throttle. Jetson is the right choice when you need model flexibility, when power is not severely constrained, when the team develops in PyTorch, or when the application requires running multiple models simultaneously (detection plus tracking plus classification on the same frame, for instance). Google Coral TPU The Coral Edge TPU is a purpose-built inference accelerator optimised for INT8-quantised TFLite models. It is extremely power-efficient — 2–4W for the development board — and that single property is the reason most teams choose it. Strengths: Very low power consumption, making it the best option for battery-powered or solar-powered applications. Fast inference for models that fit fully on-chip (sub-5ms for MobileNet-class detectors is a frequently cited operational figure from Coral’s own published examples). The USB Accelerator form factor allows bolt-on acceleration to existing compute (Raspberry Pi, industrial PC, laptop). Low cost: the USB accelerator is roughly $60 at list. Weaknesses: Hard requirement for INT8-quantised TFLite models — FP32 models are simply not supported. Models must fit entirely within the TPU’s 8MB SRAM to hit peak throughput; larger models spill to CPU execution and lose most of the speed advantage. Limited to TFLite-supported operations — custom operators are not supported. The toolchain is more constrained than Jetson’s — not every architecture compiles efficiently. Coral is the right choice for lightweight inference (MobileNet, EfficientDet-Lite, lightweight YOLO variants) on power-constrained hardware, when INT8 quantisation is acceptable, and when the model fits comfortably within TPU memory. Hailo Hailo produces dedicated neural processing units (NPUs) available as M.2 modules that add AI acceleration to existing compute. The Hailo-8 offers 26 TOPS at 2.5W — competitive power efficiency with substantially higher throughput than Coral. Strengths: Outstanding TOPS-per-watt — among the best available for embedded AI today. The M.2 form factor integrates cleanly with standard single-board computers (Raspberry Pi 5 with an M.2 HAT, industrial computers with M.2 slots). Supports a wider architectural range than Coral, including YOLOv5/v8, ResNet, and EfficientDet families. Weaknesses: The Hailo Dataflow Compiler is more complex than TensorRT or TFLite — it requires graph compilation and optimisation specific to the Hailo architecture, and the abstraction layer is thinner. Ecosystem is less mature than Jetson’s — fewer pre-compiled models, a smaller community, and less Stack Overflow lifeline when something breaks. Debugging deployment issues is harder than on Jetson because documentation is thinner and the toolchain is younger. Hailo is the right choice for high-throughput, power-constrained deployments — solar-powered cameras, edge nodes with limited power infrastructure, smart camera appliances — where Coral’s throughput is insufficient and Jetson’s power envelope is prohibitive. OAK-D (OpenCV AI Kit with Depth) The OAK-D combines a Myriad X VPU with an RGB camera and a stereo depth pair in a single integrated unit. It exists to collapse the hardware integration challenge for depth-aware computer vision. Strengths: Integrated RGB plus stereo depth in one device — useful for 3D detection, obstacle avoidance, and spatial AI. DepthAI SDK simplifies model deployment relative to working with bare OpenVINO. OpenVINO-based inference with hardware acceleration. USB connectivity — simple to integrate with a host computer. Weaknesses: Fixed camera configuration — not suitable when you need a custom optical setup or non-standard sensor placement. The Myriad X VPU has lower throughput than Hailo or Jetson for most workloads. OpenVINO IR adds a conversion step in the model pipeline. Platform development has slowed as Intel restructures its edge AI portfolio, which is worth factoring into long-horizon roadmap decisions. OAK-D is the right choice when the application genuinely requires integrated depth alongside RGB detection — robotics, pick-and-place automation, obstacle detection in autonomous mobile robots. It is not the right choice for high-throughput video analytics where depth is not a requirement. INT8 quantisation checklist INT8 quantisation is mandatory for Coral and strongly recommended for Hailo and Jetson when latency or power matters. The checklist below is the one we run before signing off on an edge deployment: Calibration dataset prepared — a representative subset of deployment imagery, typically 100–1,000 samples drawn from the actual deployment environment. Post-training quantisation (PTQ) applied and accuracy validated on a held-out test set. Accuracy drop assessed — we plan around <1–2% mAP drop for detection and <1% accuracy drop for classification as the acceptable envelope; tighter budgets need negotiation upfront. If PTQ accuracy drop is unacceptable, quantisation-aware training (QAT) applied. Model exported to the target format (TFLite for Coral, ONNX → TensorRT for Jetson, HEF for Hailo via the Dataflow Compiler). Inference outputs validated against the FP32 baseline on the same inputs — pixel-level diff for segmentation, IoU spot-check for detection. Platform selection decision guide In our experience, embedded CV platform selection reduces to four questions: Is the team working in PyTorch and does the application need model flexibility? → Jetson. Is power the primary constraint and is the model lightweight (MobileNet-class)? → Coral TPU. Is power the primary constraint and does the model require higher throughput than Coral can deliver? → Hailo-8. Does the application require integrated depth sensing? → OAK-D. Across our deployments, Jetson is the most common choice for industrial and commercial CV applications where power and cost allow it, because the lower deployment friction and larger ecosystem reduce project risk more than the power and cost savings of alternatives justify. This is a portability-limited observation, not a universal recommendation — Coral and Hailo are the right choices for deployments that genuinely require their power efficiency: high-volume camera networks, battery-powered systems, and scenarios where dozens or hundreds of devices must be deployed at low unit cost. The wrong move is to default to the cheapest or most efficient device on a spec sheet and discover, mid-integration, that the toolchain consumes the savings. FAQ How do I deploy computer vision models on edge devices reliably? Reliable edge deployment starts with characterising the trade-off envelope — latency budget, accuracy floor, power ceiling — before choosing hardware. Validate the model on the target device under realistic load, not peak burst, and verify INT8 accuracy drop against the FP32 baseline on representative data. What is the latency / accuracy / power trade-off for edge CV, and how do I navigate it? The three are coupled: smaller models are faster and lower-power but less accurate; quantisation buys latency and power at a small accuracy cost; specialised accelerators (Coral, Hailo) win on power but constrain which architectures you can ship. Navigate by fixing the hardest constraint first and treating the others as adjustable. Jetson Nano vs Intel Neural Compute Stick vs Coral — which edge target fits my constraints? Jetson fits PyTorch-first teams that need model flexibility and can spend 7–25W. Coral fits power-constrained deployments running INT8-quantised TFLite models that fit in 8MB SRAM. Intel’s Neural Compute Stick (and its OAK-D successor) fits depth-aware applications and prototyping but trails Hailo and Jetson on throughput. What does edge inference cost compared to cloud inference for a video-analytics workload? Edge inference shifts cost from recurring cloud GPU bills to upfront hardware and integration. At scale — hundreds of cameras streaming continuously — edge is usually cheaper per stream-hour because cloud bandwidth and GPU time dominate. At low volume or for bursty workloads, cloud is often cheaper because edge hardware sits idle. How do I size models so they hit latency targets on the chosen edge hardware? Measure FP32 latency on the target device first, then quantise to INT8 and remeasure. If the INT8 latency still misses the budget, the path is architectural — smaller backbone, lower input resolution, or a different model family. Do not assume vendor peak TOPS translate to your model’s throughput. Which architectural patterns (on-device-only, hybrid, cloud-fallback) survive real-world deployment? On-device-only survives when connectivity is unreliable and latency is hard. Hybrid (on-device detection, cloud-side analytics) survives when you need device-class economics but cloud-class reasoning. Cloud-fallback (on-device by default, escalate on uncertainty) survives when accuracy on edge cases matters more than steady-state cost. We have walked teams through the on-device-versus-hybrid choice more times than the hardware choice itself — see how to deploy computer vision models on edge devices for the architectural side of the decision.
