Which NVIDIA Jetson Module Should You Choose? Nano vs NX vs AGX vs Thor

Choose the Jetson Orin Nano for entry-level, low-power vision; the Jetson Orin NX for mid-range, multi-camera AI; the Jetson AGX Orin for demanding multi-sensor workloads; and Jetson Thor for generative and physical AI. The right module is the smallest one that covers your AI workload inside your power, I/O, and lifecycle budget.

NVIDIA Jetson is not one product but a family that now spans roughly a 30x range of AI performance, from the pocket-sized Orin Nano to the data-centre-class Thor. That breadth is the point: it lets you put exactly as much compute at the edge as the application needs, and no more.

It also makes “which Jetson?” a real engineering question rather than a default to the top of the range. The right answer is rarely the most powerful module; it is the one that matches your AI workload, your power and thermal envelope, your I/O and cameras, and how long you need the platform supported. This guide walks the current lineup and the way we size it with customers.

Orin figures are INT8 TOPS; Thor is quoted in FP4 TFLOPS on the new Blackwell architecture, so the headline numbers are not a like-for-like comparison. In NVIDIA’s own terms, Thor delivers around 7.5x the AI compute of AGX Orin.

Two points cause most of the confusion. First, a developer kit is not a production module: the kit is a reference carrier board plus a module, meant for evaluation, while a deployed system pairs the bare module with a carrier board built for your I/O and environment. Second, the Super refresh did not change the silicon — a software update lifted the Orin Nano from 40 to 67 TOPS and the Orin NX to 157 TOPS by unlocking higher clocks and power, so existing designs gained performance without new hardware.

All current modules run the same JetPack and Linux for Tegra (L4T) software stack, which is what lets you move an application up or down the range as requirements change. For the underlying datasheets, NVIDIA publishes full specifications for each Jetson module. For systems already on Orin, what JetPack 7.2 and supported Yocto builds mean for production Orin fleets explains where that software stack is heading.

A sealed outdoor sensor running a single detection model needs little compute and no fan: an Orin Nano at 10 to 15 W fits a passively cooled, sealed enclosure.

A four-camera autonomous mobile robot fusing vision and navigation in real time is an Orin NX job — enough headroom for several concurrent pipelines without the size, power, and cost of the largest module.

A multi-sensor autonomous machine, or a generative model at the edge, is where AGX Orin and Thor earn their place: 32 GB and up of memory and the compute to fuse many real-time streams, or to run a large model locally on Thor. Each step up the range adds heat to remove, so keeping a Jetson module inside its thermal limits is part of the sizing decision rather than an afterthought.

Specifications only take the decision so far; the rest comes from having built these systems. In our own deployments, AGX Orin powers autonomous spot-spraying for agriculture and AI surveillance for transit; Orin NX runs vision-based human-robot safety on the factory floor; and the previous-generation AGX Xavier still ships in counter-drone optical tracking and IP67 waterproof aquaculture systems.

In each case the module followed the application — the camera count, the environment, the power budget, and the lifecycle decided it, not the headline TOPS figure.

Plenty of fielded systems still run the previous generation. The Jetson Xavier family (AGX Xavier and Xavier NX) and the older Jetson TX2 remain in production designs, but NVIDIA has now brought their end-of-life forward. If you are refreshing one, the usual path is Xavier NX to Orin NX, or AGX Xavier to AGX Orin: the same class of module with a large generational jump in AI performance per watt. The software stack carries across, so the application generally moves with it.

The right module is the one that disappears into the application: enough compute for the workload, inside the power and thermal budget, with the I/O the system needs and a lifecycle that matches the program. Over-specifying wastes power, budget, and thermal headroom; under-specifying caps the application before it ships.

As your system integrator, that sizing is our job. Tell us what the system has to do and where it has to run, and we will recommend the module and the platform around it, often starting from a carrier board and rugged computer we already build, so the decision is about your application rather than the datasheet.