Every edge AI datasheet leads with a TOPS figure, and most comparison tables line those figures up as if they were horsepower. They are the least useful number on the page. TOPS are vendor peak figures, measured at a specific numeric precision, often with sparsity, on idealized work. They do not predict how many frames per second your model will run at, on your images, inside a sealed enclosure at 50 °C.
Choose edge compute by workload first, then by power and thermal envelope, temperature range, toolchain maturity, model portability, lifecycle, and the engineering time it will take to get a model running well. In 2026 that usually points to one of four families: NVIDIA Jetson Orin, NVIDIA Jetson Thor, Hailo accelerators or Qualcomm Dragonwing.
Why peak TOPS mislead
A TOPS number is the theoretical maximum of the accelerator’s arithmetic units at one precision. Real throughput depends on everything around those units:
- Precision. INT8, INT4 and FP4 figures are not comparable. A model that loses accuracy at INT4 will run at INT8 or FP16, at a fraction of the headline number.
- Sparsity. Some headline figures assume structured sparsity in the weights. NVIDIA’s 2,070 FP4 TFLOPS for the Jetson T5000, for example, is quoted with sparsity, which most production vision models don’t have unless you train for it.
- Memory bandwidth. Large models, high-resolution inputs and especially language models are often limited by how fast data moves, not by arithmetic.
- Operator support. Layers the accelerator can’t execute fall back to the CPU, and one unsupported operator in the middle of a network can cut throughput sharply.
- The rest of the pipeline. Video decode, resizing, color conversion and post-processing on the CPU can take longer than inference itself.
The only reliable number is the one you measure: your model, at your input resolution, with your pre- and post-processing, at the sustained clock your enclosure allows.
Start from the workload
Classification and detection on one to four cameras
Most single-station inspection is a convolutional or small transformer model running at INT8 on one to four streams. Here power efficiency matters more than raw capacity. The Hailo-8, which Hailo rates at 26 TOPS with typical power around 2.5 W, pairs with a modest host processor in a small fanless box. Models go through Hailo’s Dataflow Compiler, which quantizes the network and maps it onto the chip. Mainstream detection and classification architectures usually compile cleanly; unusual layers need checking early.
Multi-camera lines and mixed pipelines
When a cell has eight cameras, hardware-synchronized triggers, several models and tracking logic, flexibility matters more than watts. The Jetson Orin family, from about 7 W in the lowest Orin Nano power mode to 60 W on AGX Orin, combines a GPU, CPU and hardware video engines with the most mature edge software stack available: CUDA, TensorRT, DeepStream and GStreamer, backed by a very large developer community. If your pipeline does something unusual, someone has probably done it on a Jetson already.
Vision-language models and generative workloads
Vision-language models and other generative workloads are bound by memory capacity and bandwidth. NVIDIA’s Jetson Thor modules are built for this. The T5000 pairs a Blackwell-architecture GPU with 128 GB of LPDDR5X and a power envelope configurable from 40 W to 130 W; the T4000 is a smaller sibling with 64 GB. That is room for a multi-billion-parameter VLM alongside several inspection models.
At the other end of the scale, the Hailo-10H adds a direct DDR memory interface to a Hailo accelerator so that small language and vision-language models can run in a few watts. Hailo rates it at 40 TOPS INT4 with typical power around 2.5 W. It suits compact models and short answers, not large models or many concurrent users.
Harsh environments and long-lived products
Outdoor cabinets, substations and cold stores need wide temperature ranges and long availability more than peak performance. Qualcomm’s Dragonwing IQ9 series (the IQ-9075, for example) integrates CPU, GPU, NPU, image signal processing and video engines in one industrial-grade processor, rated by Qualcomm at up to 100 TOPS depending on configuration, with an ambient rating of −40 to 85 °C for the module. Its AI toolchain (Qualcomm AI Runtime, an ONNX Runtime execution provider, and pre-optimized models through AI Hub) is younger and smaller than NVIDIA’s ecosystem. The NPU expects quantized models, and layers it can’t run fall back to the CPU.
Side by side
| Jetson Orin | Jetson Thor | Hailo-8 / Hailo-10H | Qualcomm Dragonwing IQ9 | |
|---|---|---|---|---|
| Best fit | Multi-camera, mixed pipelines | VLMs, many cameras, heavy models | One to four camera CNNs; small generative models on 10H | Integrated, wide-temperature, long-life designs |
| Power envelope | About 7 W (Orin Nano) to 60 W (AGX Orin) | 40–130 W configurable (T5000) | Around 2.5 W typical for the accelerator, plus host | Single processor; check the module datasheet for your configuration |
| Temperature | Commercial modules; AGX Orin Industrial rated −40 to 85 °C at the thermal plate | Check module and carrier ratings | Industrial-grade parts (Hailo-10H: −40 to 85 °C) | −40 to 85 °C ambient (IQ-9075 module) |
| Toolchain maturity | Most mature: CUDA, TensorRT, DeepStream | Same stack on a newer release line (JetPack 7) | Dataflow Compiler and HailoRT; narrower operator coverage | Qualcomm AI Runtime, ONNX Runtime, AI Hub; NPU runs quantized models |
| ONNX path | ONNX to TensorRT engine | ONNX to TensorRT engine | ONNX to compiled Hailo binary | ONNX to Qualcomm runtime, or ONNX Runtime with NPU offload |
| Published lifecycle | Commercial modules listed to January 2032; AGX Orin Industrial to July 2033 | T5000 listed to August 2035; T4000 to January 2036 | Confirm with Hailo and your module maker | Covered by Qualcomm’s IoT product longevity program |
Lifecycle dates come from vendor pages at the time of writing and do change, so check them again before you commit a product design.
Portability: treat ONNX as the contract
Every platform above compiles models differently, and the compiled artifact (a TensorRT engine, a Hailo binary, a Qualcomm context binary) is tied to that chip and often to one SDK version. Keep a portable source of truth:
- Train in a standard framework and export to ONNX with a pinned opset.
- Keep a reference: the full-precision ONNX model, a fixed set of real validation images, and the reference outputs for each.
- Compile per target, and calibrate quantization with images drawn from production, not only from the training set.
- Compare every compiled model against the reference on the validation set, using per-class recall and false-reject rate rather than overall accuracy.
- Avoid custom operators unless you are prepared to implement them on every target.
This is also why we hand clients their trained models as ONNX. A model that only runs on one vendor’s runtime is a lock-in you pay for at the next hardware refresh.
Count engineering time, not just the bill of materials
Hypothetical numbers to show the arithmetic: a cheaper module saves $300 per unit across 20 stations, or $6,000. If getting your model to full accuracy on that platform takes four extra engineer-weeks of quantization debugging and operator workarounds, the saving is gone before the first unit ships, and every future model change pays the same tax again. Across 500 units, the arithmetic flips. Volume, how often your models change, and your team’s experience with each toolchain decide which side you are on.
Thermal design decides sustained performance
Datasheet performance assumes the module stays cool. In a sealed IP67 enclosure beside an oven, a fanless module will reach its thermal limit and throttle unless the enclosure was designed for its sustained power. Pick a power mode that leaves headroom, design the heat path from module to enclosure wall, and measure sustained frame rate at the highest ambient you expect, in a thermal chamber rather than on a bench. Check the power budget as well: the 24 V DC supply, PoE for cameras, and the transients when strobes fire.
How this maps to Gatepoint
Our Gatepoint gateways are built on these same families, so the choice mostly follows the workload:
- Gatepoint G2 (Hailo-8-class, fanless, about 15 W typical): one to four cameras running classification or detection.
- Gatepoint G4 (Jetson Orin-class, fanless): up to 12 camera streams and mixed pipelines.
- Gatepoint G8 (Jetson Thor-class): multi-camera lines and the on-device vision-language copilot.
- Gatepoint XT (Qualcomm Dragonwing-class, −40 to 70 °C): outdoor, substation and cold-storage sites.
Because the same ONNX model compiles for each, moving a station from G2 to G4 when a line adds cameras is usually a recompile and a revalidation, not a retraining project. The hardware page lists the full specifications.
A selection checklist
- Which models, at what input resolution, on how many streams, at what frame rate?
- Is a language or generative model part of the plan now, or likely within the product’s life?
- What is the highest ambient temperature inside the enclosure, and is a fan acceptable?
- What is the total power budget, including cameras and lighting?
- Which operators in your models are unsupported or slow on each candidate?
- How long must the hardware stay available, and what does the vendor’s published lifecycle say?
- Who on your team knows each toolchain, and how many weeks will the first port take?
If you want help working through it, edge AI hardware integration covers selection, thermal design, ruggedization and commissioning. Our post on VLMs on the production line explains why language models change the sizing question.