The number looks ridiculous at first. NVIDIA says Jetson AGX Thor can deliver up to 2,070 FP4 TFLOPS of AI compute, carry 128GB of LPDDR5X memory, and operate between 40W and 130W. Put those numbers next to the size of the module and it starts sounding like somebody squeezed part of an AI server into a robot.
Then you look at the product itself and the story gets less simple. Jetson Thor is not a mini gaming PC. It is not a cheap local LLM box either. The current Jetson AGX Thor Developer Kit uses a T5000 module with a Blackwell GPU, a 14 core Arm Neoverse V3AE CPU, 128GB of memory at 273GB/s, a 1TB NVMe drive, 4 x 25GbE through QSFP28, camera and automation interfaces, and a power range that can climb to 130W. NVIDIA’s current US Marketplace lists the kit at $5,499 as of August 17, 2026. NVIDIA’s current Jetson Thor page gives the full hardware breakdown.
That price made me stop for a second because older launch coverage says $3,499. I spent longer than I expected checking whether I had mixed up two products. I hadn’t. NVIDIA’s August 2025 launch post still carries the old starting price, while the current Marketplace and Jetson FAQ list $5,499. So if you remember Thor being cheaper, you remember correctly. The box changed from an interesting expensive dev kit into a very expensive dev kit.
The 2,070 TFLOPS Number Needs a Big Asterisk
Let’s deal with the headline number first because it is the easiest part to misunderstand.
NVIDIA rates the T5000 at up to 2,070 TFLOPS using sparse FP4 operations. The company also says that figure is measured at the 130W performance setting. FP4 means four bit floating point data, and sparse means the hardware is taking advantage of zeros or skipped work in a way that lifts the advertised operation count. This is useful for modern transformer inference, but you cannot put 2,070 FP4 sparse TFLOPS beside an FP32 desktop GPU number and declare Thor faster. They are measuring different work.
That sounds boring, I know. It matters a lot.
The Blackwell GPU inside the T5000 has 2,560 CUDA cores and fifth generation Tensor Cores. It also has a Transformer Engine that can move between FP4 and FP8 depending on the workload. NVIDIA says Thor can speed up prefill and decoding in generative AI workloads through this lower precision path. For a robot running a vision language model or a vision language action model, low precision inference is exactly the sort of job NVIDIA wants those Tensor Cores doing.
And 130W is still 130W. In a desktop tower that would barely get attention. Inside a mobile robot, heat, battery size, fan noise, enclosure design and power delivery become part of the engineering problem. A humanoid robot has motors pulling power too. Cameras, lidar, radar, microphones and other electronics are also drinking from the same battery. You don’t get to treat the compute module like it is plugged into the wall forever.
NVIDIA gives developers a 40W to 130W range for the T5000. That is more useful than one fixed power target because robot makers can choose how much performance they can afford thermally. But it also means the 2,070 figure should be read as the top of the box, not what every robot will sit at all day.
The 273GB/s memory bandwidth tells another story. That is plenty for an embedded computer, but 128GB capacity does not magically make every huge model fast. Large LLM inference often leans hard on memory bandwidth. Thor can fit models that smaller edge systems cannot fit at all, then still take time moving those weights through memory. Capacity and speed are different problems, they just happen to sit next to each other on the spec sheet.
I Think the 128GB Memory Is More Interesting Than 2,070 TFLOPS
This is the part I would watch if I were building around Thor.
A 70 billion parameter model stored at a clean four bits per parameter needs about 35GB just for its raw weights. A 120 billion parameter model comes to about 60GB. A 200 billion parameter model is around 100GB before runtime overhead, temporary buffers, the operating system, KV cache and everything else starts taking space. Real quantized files are not always that neat, but the rough math is enough to show why 128GB changes the type of work an edge computer can attempt.
A 16GB robot computer forces you toward smaller models. That can be fine. In fact, a lot of production robots should use smaller models because they are cheaper and easier to control. Move to 32GB or 64GB and you can run larger vision models, longer context, more concurrent models and fatter perception stacks. At 128GB, something else happens. You can start asking whether the robot can keep a serious vision language model in memory at the same time as perception networks, planning code, a local language model, sensor buffers and other services.
That is much closer to the way a modern robot is expected to work. It doesn’t do one AI task, finish, and politely start the next one. A warehouse robot may be reading cameras while localizing itself, tracking people, planning a route, checking an object, answering a task request and logging data. A humanoid adds manipulation and body control on top. Some of those jobs have tight timing requirements. Others can wait a little.
So 128GB is less about bragging that a robot can load one giant LLM. The better use is giving several systems enough room to stay alive together.
And this is where NVIDIA’s Multi Instance GPU support gets interesting. JetPack 7.2, released in June 2026, brought MIG support on Jetson Thor with a real time kernel. NVIDIA describes a setup where developers can reserve GPU resources for deterministic work such as perception, so an unrelated inference job cannot steal all the compute at the wrong moment. That is a very robot problem. Your chat agent being 300 milliseconds late is annoying. Your obstacle detector being late is a different category of bad day.
I like this design direction more than the giant TFLOPS headline. A robot computer should be judged by what it can keep running at once and how predictable those jobs stay under load. Peak math is one part of that.
So What Does Jetson Thor Actually Do Inside a Robot?
A robot is basically a moving pile of deadlines.
It receives sensor data. It needs to understand what is around it. It estimates where it is. It decides what to do next. It controls motors. It may also need to understand a human instruction such as, “Pick up the red tote from the second shelf and bring it to packing station four.” Now add the messy part: the shelf is partly blocked, another worker walks past, the tote has moved, and the robot’s camera sees a label it has never seen before.
Old style robotics often split these jobs into many hand built systems. Modern AI does not remove those systems, but it can add models that reason over images, text, actions and sensor history. NVIDIA is aiming Thor at this mix. Its own software stack includes Isaac for robotics, GR00T models for humanoids, Metropolis for video AI and Holoscan for sensor processing. The hardware also has dedicated blocks for vision, video encode and decode, optical flow and other jobs that do not need to burn GPU cycles every time.
Sensor input matters here more than people coming from desktop AI usually expect. The developer kit has a QSFP28 port that can carry four 25GbE links, plus a 5GbE RJ45 connection. NVIDIA also works with Holoscan Sensor Bridge to move camera, radar, lidar and other sensor data toward GPU memory with low delay. The T5000 module itself supports high speed camera paths and a long list of embedded interfaces.
That plumbing is why I would not compare Jetson Thor directly with a random small form factor PC containing a fast GPU. A desktop box may win some model benchmarks for less money. It may also be a total headache when you need deterministic sensor timing, CAN connections, compact carrier boards, long product life, camera inputs and a software stack meant for robots.
Here is a more concrete example. Say a warehouse humanoid gets told to move a blue tote from aisle seven to a packing bench. Its cameras first need to find the tote. A perception model has to separate that tote from similar boxes around it. The robot needs to work out whether a person or trolley is blocking the path. Its planner then chooses a route and keeps updating it as the scene moves. Near the shelf, another model may guide hand placement and grip. A local language or vision language model can interpret a changed instruction from a worker. The control system still has to keep balance and joint movement within limits the whole time. None of those jobs cares that the marketing slide says 2,070 TFLOPS; they care that compute, memory and timing stay available when several jobs hit at once.
The dev kit itself is 243.19mm by 112.40mm by 56.88mm. The production T5000 module is much smaller at 100mm by 87mm. Robot companies prototype on the kit, then build around production modules and their own carrier boards. NVIDIA is very clear that Jetson developer kits are for development and testing, not something you bolt into a finished product and ship forever.
That distinction gets missed in a lot of hardware coverage. The $5,499 box on a desk is not the final robot computer. It is the place where you make the software work before moving it into a product design.
The Real Workload Is Several AI Models Fighting for the Same Box
Imagine a humanoid sorting mixed items on a workbench. One model handles visual understanding. Another system tracks hands and objects. A VLA model maps an instruction to actions. A local agent may check a task database or ask for help when confidence drops. The robot still needs localization, motion planning, safety checks and motor control. That is already more than one model, and I am probably still leaving something out.
This is why NVIDIA keeps talking about “physical AI” instead of treating Thor as an LLM appliance. The computer is meant to sit at the point where AI meets sensors and motors. It has to take in the physical world and send decisions back out before the scene changes too much.
There is another reason to keep this on the robot: network failure. A cloud model can be bigger. It can also disappear when Wi Fi drops in the wrong corner of a warehouse. Sending live camera feeds to the cloud adds bandwidth cost and delay. Medical systems or factory cameras may have privacy rules that make cloud processing awkward. Local inference lets the machine keep working with less dependence on a remote data center.
But local does not mean disconnected forever. A sane design will probably mix edge and cloud. Fast perception and control stay local. Bigger planning tasks, fleet learning, software updates and heavy training can happen elsewhere. Some robot vendors will push more to cloud, others will keep more onboard. I don’t think there is one neat answer here.
The funny part is that Thor is almost the opposite of how people first learned to think about edge AI. Edge AI used to mean tiny models squeezed into tiny hardware. Thor says the edge can now carry 128GB of memory and a Blackwell GPU. That is a fairly wild change in only a few Jetson generations.
NVIDIA says Thor offers up to 7.5 times the AI compute and 3.5 times the energy efficiency of AGX Orin. Its 2025 launch material also said Thor had twice the memory and 3.1 times the CPU performance of Orin. Those are NVIDIA comparisons, so I would not treat them like third party lab results. Still, the direction is obvious from the hardware itself. The company has moved Jetson from compact inference boards toward something that can host transformer heavy robot stacks.
JetPack May Matter More Than the Chip
Hardware people hate hearing this, but software can decide whether a robotics computer is useful.
A 2,070 TFLOPS box with bad drivers is a fancy heater.
Jetson Thor runs JetPack 7, with Ubuntu 24.04 LTS, Linux kernel 6.8, CUDA 13 and NVIDIA’s AI runtime libraries. NVIDIA moved Jetson Thor toward Server Base System Architecture support, which makes the Arm platform look more like standard Arm server systems at the firmware and operating system level. JetPack 7.2 then added more work around agents, memory tuning and MIG.
This matters because a robotics company does not want to spend six months discovering that one camera driver, one CUDA library and one real time process all hate each other. NVIDIA has spent years building Isaac, CUDA, TensorRT, Holoscan and the rest of its Jetson software around the hardware. There are plenty of complaints you can make about being tied closely to NVIDIA, but the company does give developers one connected stack from model deployment down to embedded I/O.
And lock in is part of the deal. If your robot is built around CUDA kernels, TensorRT models, Isaac ROS packages and Jetson specific tuning, moving to another hardware vendor later is not a weekend job. The better the software stack becomes, the harder it can be to leave. That is not unique to NVIDIA, it is just easy to forget when everything works nicely on day one.
JetPack 7.2 also added agent skills that can help with Linux setup, memory optimization, system configuration and model benchmarking. NVIDIA said in July that some customers had cut memory use enough to move to smaller Jetson modules. UBTech, Agile Robots and Connect Tech reportedly saved up to 15GB in certain workloads, and NoTraffic reported a 30 percent memory reduction on an older Jetson TX2 NX setup. These are company supplied examples, but they show what NVIDIA is trying to sell now. The pitch covers more compute and software that helps squeeze workloads into cheaper hardware.
That leads to the newest twist in the Thor story.
NVIDIA Is Already Making Smaller Thor Modules
On July 15, 2026, NVIDIA introduced the Jetson T3000 and T2000. That is less than a month before I am writing this.
The T3000 drops to 32GB of LPDDR5X memory and 865 FP4 TFLOPS, with an eight core Arm CPU and the same listed 273GB/s memory bandwidth. NVIDIA says it is roughly half the size and power of the T5000 and claims similar inference performance for some multimodal workloads. The T2000 goes further down to 16GB and 400 FP4 TFLOPS for visual AI agents, mobile robots and industrial machines.
This is more revealing than another benchmark chart.
My read is that NVIDIA knows full T5000 class Thor is too much computer for a lot of products. A factory camera does not need 128GB. A small mobile robot may care more about battery life and price. A humanoid research platform running multiple transformer models has a much better reason to pay for the T5000.
The new modules also put the 2,070 TFLOPS number in proper context. Thor is not one fixed computer. It is turning into a range that goes from high end robot reasoning down toward smaller edge systems. That is how embedded platforms usually grow up. The expensive developer toy gets siblings that fit actual product budgets.
And budgets matter. NVIDIA’s current FAQ lists the T5000 production module at $4,999 in quantities of 1,000 or more. That is not a small line item if you are building thousands of machines. The current developer kit is $5,499. Even before cameras, motors, batteries, safety hardware and mechanical parts, the compute bill is serious.
The older $3,499 launch price makes this a little messy. Prices can change, distributor pricing can vary, and volume deals are their own world. I would check the live NVIDIA Marketplace and distributor quote before putting Thor into any 2026 budget spreadsheet.
What Jetson Thor Is Bad At
It is easy to get carried away with this thing.
First, it is expensive. If your project is a home robot prototype that needs basic object detection, speech and a small local model, Thor can be ridiculous. Jetson Orin products cost far less, and plenty of x86 or Apple systems can run local AI without a $5,499 developer kit.
Second, FP4 performance does not solve every workload. Some models do not like aggressive low precision. Some robotics code is CPU bound. Some systems are limited by memory bandwidth, sensor latency or poorly written software. A huge Tensor Core number does nothing for a process that is waiting on I/O.
Third, 128GB can encourage bad habits. If a team has loads of memory, it becomes tempting to keep throwing larger models onto the robot instead of asking whether a 4B or 8B model can do the job. NVIDIA’s own July 2026 move toward T3000 and T2000 is a useful reality check. Smaller models and better memory tuning can save real money and power.
Fourth, the thermal job is not small. Designing a robot that can run near 130W compute for long periods is different from testing a dev kit on a desk with a fan and a power brick. The production module gives teams flexibility, but the product designer still has to do the needful with heat pipes, airflow, enclosure temperatures and battery planning. Sorry, that phrase was sitting there waiting for me.
And there is safety. Jetson Thor is a general robotics compute platform. A fast AI model does not become safe because it runs locally. Industrial and medical designs may need separate safety systems, certification work and hardware that can keep dangerous motion under control even when the main AI stack does something stupid. NVIDIA has IGX Thor and its Halos safety work for that side of the market, which itself tells you that raw Jetson compute is not the whole safety answer.
Who Is This Actually For?
Jetson Thor makes sense first for teams building robots that need several heavy AI jobs on the machine at the same time.
Humanoid developers are the obvious group. NVIDIA names companies such as 1X, Amazon Robotics and Boston Dynamics among the organizations building on or evaluating Thor class systems. Research labs working on perception, path planning, manipulation and control also fit. High speed industrial inspection, medical imaging systems, autonomous machines and multi camera edge systems can use the same hardware for different reasons.
A local LLM hobbyist can buy one, of course. I wouldn’t. If your main goal is running a big text model on a desk, you are paying for robot I/O, sensor paths, embedded features and a software stack you may never touch. A desktop AI workstation or one of the newer 128GB mini AI PCs makes more sense for that job.
For robotics, though, the strange combination starts to click. 128GB lets several models live together. MIG can keep time sensitive GPU work separate. Dedicated media and vision blocks take pressure off the main GPU. High speed networking feeds sensors into the box. The Arm CPU handles general system work. A 40W to 130W range lets the same module fit more than one thermal target.
That is what Jetson Thor is for.
The 2,070 TFLOPS headline gets people to look at it. The less flashy