What Is NVIDIA Jetson? The Edge AI Platform Explained

NVIDIA Jetson is NVIDIA’s family of compact, low-power computers for running AI at the edge, close to where data is created rather than in a data centre. Each Jetson is a system-on-module that puts an NVIDIA GPU, Arm CPU cores, memory and dedicated AI and video engines on one small board, paired with NVIDIA’s JetPack software.

That is the short answer to what NVIDIA Jetson is. The modules drop onto a carrier board that provides the connectors a product needs, and the result goes into robots, smart cameras, vehicles, drones, medical devices and industrial machines that have to see, decide and act in real time. The current range runs from the Orin Nano at 7 W to the Jetson Thor T5000 at up to 130 W, and all of it runs the same software stack. Our NVIDIA Jetson range covers the systems built on it.

This guide explains the platform end to end: the module lineup with NVIDIA’s published figures, what is inside a module, how modules, carrier boards and complete systems relate, the software stack and JetPack versions, the history of the generations and their lifecycle, how Jetson compares with other ways to run AI, and what it is used for.

The current range has two generations: Jetson Orin, on the NVIDIA Ampere GPU architecture, and Jetson Thor, on NVIDIA Blackwell. The table sets out NVIDIA’s published module figures, with the Orin Nano and Orin NX in their Super modes.

Orin figures are sparse INT8 TOPS and Thor figures are sparse FP4 TFLOPS, so the two are not a like-for-like comparison; NVIDIA rates Thor at up to 7.5 times the AI compute of AGX Orin. Our explainer on TFLOPS and TOPS covers why precision changes the number.

Within Orin, the Jetson Orin family spans a wide range on one architecture, and the Orin Nano and Orin NX share the same connector. At the entry end, the Super software update lifted the Orin Nano from 40 to 67 TOPS without any change to the silicon. To choose between the modules, our guide to the Jetson lineup sizes them by workload, power and lifecycle.

Industrial and commercial modules

Most Jetson modules are rated for a commercial operating range at the module, with the system’s rating set by its carrier and enclosure. The AGX Orin Industrial is the exception in the current range: NVIDIA rates it from −40 °C to 85 °C, adds ECC on the memory and gives it a longer production life, at the cost of a slightly lower AI rating than the commercial AGX Orin 64GB. It suits rail, defense and outdoor systems where the module itself has to cover the full temperature range.

Not in the sense of a graphics card. A Jetson module contains an NVIDIA GPU, but it also carries the CPU cores, the memory, the storage controller, the camera and video engines and the power management for a complete computer. It boots its own operating system and runs on its own; it does not plug into a PC. The GPU is what makes it fast at AI, and it shares memory with the CPU, so models do not have to be copied over a PCIe link.

That integration is the reason Jetson exists. Our guide to the GPU vs CPU explains why AI runs on GPUs, CUDA cores vs Tensor Cores covers the two kinds of GPU core, and the explainer on a system-on-module sets Jetson alongside other module standards.

If the cloud can run any model, why run one on a small computer in the field? Because many systems cannot wait for a round trip, cannot stream all their data away or cannot rely on a connection. Our explainer on edge AI vs cloud AI goes further; in short, there are four reasons: latency, bandwidth, privacy and resilience.

A robot or vehicle has to react in milliseconds, on the device, not after a round trip to a server. Twenty cameras on a production line or a rail vehicle produce far more video than most sites can send away. Keeping images on the device means only results leave it, which matters in retail, healthcare and public spaces. And a system on a farm, a mine or a ship has to keep working when the network does not.

Jetson makes local inference fast enough and efficient enough to embed in the product itself, which is why it has become the default choice for GPU-accelerated AI in robots and autonomous machines.

A Jetson project usually involves four pieces of hardware, and confusing them is the most common early mistake. We cover the module versus a developer kit in a separate explainer; the table sets out all four.

The developer kit is where a project starts, not what ships. A deployed system pairs the bare module with a Jetson carrier board built for its I/O, power input and environment. Our guide to choosing between an off-the-shelf, adapted or custom Jetson carrier board covers that half of the pairing, and the Jetson Orin carrier boards range shows the variety, from compact boards for drones to I/O-rich designs for machines.

Connectors differ between families. The Orin Nano and Orin NX use a 260-pin SO-DIMM connector, so one carrier can usually take either; the AGX Orin uses a larger 699-pin connector; and Jetson Thor uses its own connector and power design, so it needs Jetson Thor carrier boards rather than an AGX Orin board.

Most Jetson systems exist to process camera or sensor data, so the input path matters as much as the module. The main options:

• MIPI CSI-2: short, direct camera links inside a compact device, native to the module but limited in cable length.
• GMSL2: automotive-style cameras over long, vibration-tolerant coax runs, through a carrier or frame grabber with deserialisers.
• USB 3: development and depth cameras and simple installs; easy to add, but connectors can loosen under vibration.
• GigE Vision and PoE: IP and industrial cameras on Ethernet, often powered over the cable, scaling to many cameras.
• 10GbE and 25GbE: high-resolution camera arrays, lidar and sensor bridges; multi-gigabit Ethernet is standard on Thor modules.

For robots and vehicles, GMSL2 is the usual answer: our explainer on GMSL2 covers how it works, and the range of GMSL cameras shows what connects to it. Systems with many IP cameras often use Jetson PoE systems that power the cameras over Ethernet. On Thor, NVIDIA’s Holoscan Sensor Bridges bring camera and sensor data in over Ethernet straight into GPU memory.

Hardware is half of Jetson. The other half is JetPack, NVIDIA’s software development kit for the platform, and the libraries above it. Our guide to the JetPack software stack covers each layer in depth; this is the map.

Our explainers on CUDA, TensorRT and Linux for Tegra go deeper on the core layers, and ROS covers the robotics framework most Jetson robots run.

JetPack versions and the modules they support

The version fixes the kernel, the CUDA release and the AI libraries an application is built against, so it is a design decision rather than a detail. For production fleets on Orin, what JetPack 7.2 and supported Yocto builds mean for production Orin fleets explains where the stack is heading. Always confirm the exact module list in NVIDIA’s release notes before fixing a version.

Jetson is not new. NVIDIA has shipped edge AI modules since the Jetson TK1 in 2014, and each generation has tracked the GPU architecture of its time. For designers the result is a long, predictable platform with a clear upgrade path, which is part of why Jetson is trusted in industrial and defense programs.

NVIDIA brought the LPDDR4-based Xavier and TX2 modules to an accelerated end of life, and our guide to Xavier and TX2 end-of-life and migration to Orin sets out the options for fielded systems: Xavier NX usually moves to Orin NX, and AGX Xavier to AGX Orin. Our answer on what replaced the Jetson Xavier gives the short version.

At the newest end, what Jetson Thor adds over AGX Orin for robotics and sensor fusion shows how large the latest step is: a Blackwell GPU, a much faster CPU, up to 128 GB of memory and multi-gigabit networking. Dates move, so confirm the current position on NVIDIA’s Jetson lifecycle page before committing a long program.

Jetson is not the only way to run AI at the edge. It sits between small accelerators and full PCs with discrete graphics cards, and the right choice depends on the workload, the power budget and the software.

Where a project needs the most GPU compute per system, a PC with a full-size card is the better form factor; our industrial GPU computers cover that route. Where the AI is light and the rest of the software is x86, a processor with a built-in NPU can be simpler; our comparison of GPU vs NPU for edge AI sets out the trade-offs, and x86 vs Arm covers the processor side. For GPU-accelerated AI in a compact, embeddable, long-life form, Jetson is usually the default.

Jetson goes wherever AI has to run in real time on the device. In our own deployments that has meant autonomous agriculture, factory human-robot safety, smart surveillance for transit and counter-drone tracking. The table maps common applications to the module tier that usually fits.

Our guides go deeper on several of these: the robot computer guide sizes compute by robot class, Jetson for drones covers companion computers, and our explainer on machine vision covers inspection. For the toughest sites, a rugged Jetson computer adds wide-temperature ratings, wide-range DC input, locking connectors and shock and vibration testing.

A Jetson module is the start, not the finish. To become a product it needs a carrier board for the right I/O, storage rated for the temperature and write load, cooling sized for the chosen power mode, an enclosure for the environment, a configured software image and validation. The systems in our range show how that comes together:

That integration is what we do. We choose the module to suit the workload, build it into a system with the right carrier, storage and cooling, image it with the JetPack release and application the project needs, and test it before it ships, so what you deploy is a finished computer rather than a board on a bench.