Jetson Thor Specs: T5000 and T4000 vs AGX Orin

Jetson Thor vs Orin is the step from NVIDIA’s Ampere generation to Blackwell. On Jetson Thor specs, the T5000 module is rated at up to 2,070 FP4 TFLOPS with 128 GB of memory, against 275 INT8 TOPS and 64 GB on the AGX Orin 64GB. NVIDIA puts the gain at up to 7.5 times the AI compute and 3.5 times the energy efficiency, at a power envelope that rises from 60 W to 130 W.

Jetson Thor combines a 14-core Arm Neoverse-V3AE CPU with a Blackwell GPU and its transformer engine, and it is built for the workloads Orin struggles to hold: humanoid robots, mobile manipulators and machines that run perception, planning and language models at once. Jetson AGX Orin remains in production and is still the right module for a great deal of edge AI.

This guide compares the two generations side by side, explains why the TFLOPS and TOPS figures are not like-for-like, and covers what changes in the carrier board, power, cooling and software when a design moves up. For where both sit in the wider lineup, start with what NVIDIA Jetson is and why it runs AI at the edge.

The table sets the two Thor modules beside the two commercial AGX Orin modules, using NVIDIA’s published figures. Interface counts differ between modules and carriers, so treat the I/O rows as module capability and check the datasheet for the exact numbers.

Two rows matter more than the AI figures. Memory doubles from 64 GB to 128 GB on the T5000, with about a third more bandwidth, and that decides which models fit at all. Power more than doubles at the top end, and that decides the carrier, the supply and the enclosure. Our answer on Jetson T5000 vs T4000 compares the two Thor modules in more detail, and our Jetson modules comparison places all nine current modules side by side.

NVIDIA quotes the T5000 at up to 7.5 times the AI compute of AGX Orin and 3.5 times the energy efficiency. Both figures are real, but the headline compares different precisions, so it needs reading carefully.

Precision is the key. Blackwell Tensor Cores run FP4 natively, and NVIDIA quotes Thor at that precision; Orin is quoted at INT8. A model quantised to INT8 on both gains less than the 7.5× headline suggests, while a transformer that would not fit in 64 GB, or ran too slowly to be useful, can go from impractical on Orin to real time on Thor. Our explainers on TFLOPS and how they differ from TOPS and on NVIDIA Blackwell cover the background.

Worked example. A mobile manipulator runs a detector on four cameras, a depth network and a vision language action model. On AGX Orin 64GB the detector and depth network fit comfortably, but the language model has to be cut down to fit beside them, and it answers in seconds rather than fractions of one. On a T5000 the full model, the perception stack and their buffers fit in 128 GB with room to spare, and FP4 inference brings the response into the control loop. The same robot running only the detector and depth network would see a much smaller gain, and AGX Orin would be the more efficient choice.

Which Thor module: T5000 or T4000?

Memory usually decides. The T5000’s 128 GB allows the largest generative and vision language models, longer context or several large models side by side, and suits humanoids and multi-sensor fusion with many high-resolution cameras. Where the models fit comfortably in 64 GB, the T4000 gives Blackwell performance in 40–70 W, which is far easier to cool in a compact or sealed enclosure and kinder to a battery. The two share a form factor and software, so development can start on the T5000 developer kit and production can use either; benchmark the real model on both before fixing the choice.

Perception is where autonomy starts, and Thor is built to move far more sensor data than AGX Orin. The difference shows up as soon as the camera count and resolution rise.

The rates assume uncompressed 8-bit YUV video at about 1 Gb/s per 1080p30 stream; compressed IP cameras need far less bandwidth but add decode load and latency. With four 25GbE links and the Holoscan Sensor Bridge, Thor can take raw sensor data into GPU memory without a CPU copy, and MIG keeps the perception, mapping and planning pipelines from competing for the same GPU resources. On AGX Orin the same sensor set usually means compressing at the camera, adding a frame grabber or splitting the work across two computers.

For camera links, our guide to GMSL technology for industrial edge AI explains why automotive cameras dominate robots and vehicles, and our answer on Precision Time Protocol covers how Ethernet sensors stay in time with each other.

Thor and Orin lifecycle

Lifecycle points the same way as performance. Thor is NVIDIA’s newest Jetson generation, from 2025, and AGX Orin is listed in production into the early 2030s, so both are sound choices for a new design. Our answer on how long NVIDIA Jetson is supported sets out the lifecycle of each generation; confirm dates on NVIDIA’s lifecycle page before committing a long programme.

No. Thor uses a new module connector, a higher power envelope and new high-speed I/O, so an AGX Orin carrier board cannot take a Thor module. Our answer on whether Jetson Thor needs a new carrier board sets out why. The T4000 and T5000 share the Thor form factor, so a Thor carrier is usually designed for both, within the power and cooling it was built for.

Our Jetson Thor carrier boards include boards with QSFP28 25GbE, CAN FD and camera expansion, and military-grade boards with quad 10GbE and PCIe Gen 5 NVMe. Existing Orin systems stay supported on AGX Orin carrier boards, so there is no need to move before the workload calls for it.

Thor raises the cooling job more than any previous Jetson step. AGX Orin tops out at 60 W on the commercial module; the T5000 runs to 130 W, and a complete system draws more. Catalogue ratings from our range show what that means in practice.

Power budget example. A T5000 robot computer at its top mode, plus eight GMSL2 cameras, two NVMe drives and a 5G modem, can approach 170–200 W at the input. On a 48 V robot battery that is around 4 A continuous before the motors; on a 24 V vehicle supply, around 8 A. A capped mode, such as 70 W or 90 W, often keeps most of the performance with far less heat and current.

The lower power modes are the main design lever. Running a T5000 in a capped mode, or choosing the T4000 at up to 70 W, can make a fanless or sealed design practical. Our Jetson thermal design guide covers heatsinks, fans and conduction cooling, and our answer on conduction cooling explains the sealed-enclosure route.

Thor runs JetPack 7, built on Ubuntu 24.04 with CUDA 13, current TensorRT, a PREEMPT_RT real-time kernel option and support for Triton inference serving. JetPack 7.2 then brought AGX Orin and Orin NX onto the same software line, so a fleet can run one generation of software across both. Our guide to NVIDIA JetPack explains the stack, and JetPack 7.2 and Yocto for production Orin fleets covers how the two lines meet.

Two features change how a Thor system is designed. Multi-Instance GPU lets perception, mapping and planning each run in their own GPU slice with dedicated compute and memory, so one workload cannot starve another. And NVIDIA Holoscan with its sensor bridge moves camera, lidar and radar data over Ethernet straight into GPU memory, cutting CPU hand-offs and latency. Robotics stacks build on ROS through Isaac ROS, and the larger memory makes vision language models practical on board.

CUDA code usually carries across from Orin with little change. What has to be redone is the operating system image, the carrier’s board support package and every TensorRT engine, because engines are built for one GPU and one TensorRT version.

Thor consolidates perception, sensor fusion and AI reasoning on one module, so a robot or machine can process more sensors in parallel and run larger models without an external server. That pays off in some applications far more than others.

Choose AGX Orin where the models are classic detection, segmentation and tracking, where the power budget is tight, or where a mature, proven carrier and long field history matter more than headroom. Choose Thor where generative models, many high-resolution sensors or several large models at once are part of the design, or will be within the product’s life.

Our robot computer guide sizes onboard compute by robot class, and Orin NX vs AGX Orin covers the step below.

Developer kits are invaluable for bringing up software, but they are not built for long-life operation in a vehicle, a factory or outdoors. Deployed Thor systems need a carrier board and enclosure designed for the environment, wide-temperature components, shock and vibration resistance and a cooling design matched to the power mode.

Two routes are open. A finished computer, such as the Vecow EAC-7000 for robots and autonomous machines, suits most projects. A rugged carrier board, such as the Forecr MILBOARD‑THR mil-grade Jetson Thor carrier board, suits programmes that build their own enclosure. Either way, we pair the module with the carrier, storage and cooling the application needs, then configure, image and test the system before it ships, so what arrives is a validated computer rather than a board on a bench.

The facts below come from each product’s own specification.

Each runs JetPack 7. We fit the storage, wireless and camera options, set the power mode to suit the enclosure and image the system with the release your application is validated on.