Jetson Thor vs Jetson Orin AGX comes down to one question: does your workload need Thor’s 128 GB of memory and FP4 compute, or does it already fit inside Orin’s 64 GB and 275 INT8 TOPS? NVIDIA positions Jetson AGX Thor at up to 7.5x the AI compute and 3.5x the energy efficiency of AGX Orin, built on a 2560-core Blackwell GPU with 96 Tensor Cores and 128 GB of LPDDR5X at about 273 GB/s. For large vision-language-action policies, multimodal models and several concurrent models, Thor is the only one of the two that fits.
The picture changed in July 2026, when NVIDIA quietly raised Jetson prices across the range. The Jetson AGX Thor Developer Kit went from $3,499 to $5,499, and the AGX Orin Developer Kit from $1,999 to $3,499. At 1,000-unit volumes the Thor T5000 module moved from $2,999 to $4,999, while the AGX Orin 64GB module rose from $1,599 to $2,999. The gap between the two platforms narrowed in relative terms, which makes the upgrade question more interesting than it was at launch, but both are materially more expensive than the figures in older guides.
This refreshed edition keeps the full architectural comparison below and adds what has moved since: current pricing, the lower-cost T4000 variant, and the buying realities of late 2026. Supply is uneven, with NVIDIA’s own marketplace listing both developer kits as out of stock in late October and directing buyers to distributors. The rule from the original guide still holds: choose from your model’s memory footprint and required precision, compare at matched precision, and validate sustained performance in your real enclosure before committing a fleet.
Short answer: Choose Jetson AGX Thor when your models need more than 64 GB of memory or benefit from FP4, such as VLA policies and large multimodal models. Choose Jetson AGX Orin when classic vision and small-to-mid networks already meet latency, since it costs less and draws 15 to 60 W versus Thor’s 40 to 130 W.
Last Updated: October 24, 2026
Jetson Thor vs Jetson Orin AGX: The 2026 Edge AI Upgrade Guide
For four years the NVIDIA Jetson AGX Orin was the default “serious” edge AI module: enough compute to run real perception stacks, a mature software base, and a price teams learned to plan around. Then Jetson AGX Thor arrived on a Blackwell GPU and reset the ceiling. Jetson Thor vs Jetson Orin AGX is now the central hardware decision for any team building robots, autonomous machines, or edge inference boxes in 2026 — and it is not a simple “buy the newer one” call.
Thor is dramatically more powerful, but power you cannot use is just cost and heat. The right question is whether your workload — its model sizes, its precision, its memory footprint — actually consumes what Thor offers, or whether Orin still hits your targets for a fraction of the budget.
What this covers: the architectural gap between the two modules, the verified specs that matter, how workloads map to each, the power and cost trade-offs, and a clear rule for when the Thor upgrade pays for itself.
Context and Background
Jetson AGX Orin, launched in 2022, is built on NVIDIA’s Ampere GPU architecture. It delivers up to 275 INT8 TOPS, offers up to 64 GB of LPDDR5 memory at about 204.8 GB/s, and carries up to 2048 CUDA cores with 64 Tensor Cores. It became the workhorse for robotics and edge vision precisely because it balanced capability, a stable JetPack software stack, and a predictable price.
Jetson AGX Thor is the generational leap. It uses NVIDIA’s Blackwell GPU architecture and introduces FP4, a new lower-precision datatype that roughly doubles throughput over INT8 for models that support it. Thor is positioned as “datacenter-class compute at the edge” for physical AI — humanoid robots, autonomous machines, and large multimodal or vision-language-action (VLA) models running on-device. Our Hailo-10H vs Jetson Orin Nano comparison covers the low-power end of the edge spectrum; this article is the high-end AGX decision. For running large language models specifically on these boards, see TensorRT-LLM vs llama.cpp on Jetson. NVIDIA’s own Jetson product documentation is the authority for exact SKUs.
The Architectural Gap and the Specs That Matter
The one-line answer: Jetson Thor delivers on the order of 7x more AI compute than Jetson Orin AGX with double the memory and much higher bandwidth, but Orin remains the right pick when your models fit its memory and hit your latency at a far lower cost and power draw. The gap is real; whether you need it is the actual decision.

Figure 1: The architectural gap — Thor’s Blackwell GPU, FP4 datatype, 128 GB LPDDR5X, and PCIe Gen5 and 25GbE interfaces against Orin’s Ampere GPU, INT8 compute, up-to-64 GB LPDDR5, and earlier interfaces.
Figure 1 lays the two modules side by side on the dimensions that change how you architect a system: compute precision, memory capacity and bandwidth, and I/O. Each of these can be the binding constraint depending on your workload.
Compute and precision
Orin AGX tops out around 275 INT8 TOPS on its Ampere GPU with up to 2048 CUDA cores and 64 Tensor Cores. Thor’s Blackwell GPU carries 2560 CUDA cores and 96 Tensor Cores and reports on the order of 2070 FP4 TFLOPS. The key nuance is precision: Thor’s headline throughput is measured at FP4, a datatype Orin does not support, which roughly doubles throughput over INT8 for models that tolerate it. NVIDIA positions Thor at roughly 7.5x the AI compute and about 3.5x the energy efficiency of AGX Orin. Comparing a Thor FP4 number directly to an Orin INT8 number overstates the gap for models that cannot use FP4, so always compare at the precision your model actually runs.
Memory capacity and bandwidth
This is often the real deciding factor. Thor ships with 128 GB of LPDDR5X at about 273 GB/s — double Orin’s maximum 64 GB and roughly 1.33x the bandwidth of Orin’s ~204.8 GB/s. For large multimodal models, VLA policies, or several models resident at once, memory capacity is frequently the wall you hit before compute. A model that will not fit in 64 GB simply cannot run on Orin regardless of TOPS.
Interfaces
Thor adds modern I/O — PCIe Gen5 and 25GbE networking — that matters for sensor-dense robots and for streaming high-bandwidth data off the module. Orin’s earlier interfaces are adequate for many designs but can become a bottleneck in multi-camera, multi-LiDAR platforms.
Mapping Workloads to the Right Module
Specs only matter through the lens of a workload. The decision splits cleanly by what you are actually running and how much memory it needs.

Figure 2: Workload-to-module mapping — classic CV and small-to-mid models fit Orin comfortably, while large multimodal, VLA, and on-device LLM workloads push into Thor’s memory and FP4 territory.
Figure 2 turns the spec sheet into a routing decision: start from your model, not from the module, and let memory footprint and required precision select the board.
Where Orin AGX still wins
Classic computer vision — detection, segmentation, pose, multi-stream video analytics — and small-to-mid neural networks run comfortably on Orin AGX within 64 GB and 275 INT8 TOPS. If your product ships today on Orin and meets latency, the upgrade may buy you nothing but cost. Orin also has years of field-proven deployments and a mature JetPack stack, which reduces integration risk.
Where Thor is the answer
Thor is the answer when memory or precision is the constraint: large multimodal models, VLA policies for humanoid and general-purpose robots, several concurrent models, or on-device LLMs beyond what 64 GB allows. FP4 support meaningfully accelerates transformer inference for models that adopt it. If you are designing for physical AI over the next several years, Thor’s headroom protects against model-size growth.
Here is the decision matrix:
| Dimension | Jetson Thor (AGX) | Jetson Orin (AGX) |
|---|---|---|
| GPU architecture | Blackwell | Ampere |
| Peak AI compute | ~2070 FP4 TFLOPS | ~275 INT8 TOPS |
| CUDA / Tensor cores | 2560 / 96 | up to 2048 / 64 |
| Memory | 128 GB LPDDR5X (~273 GB/s) | up to 64 GB LPDDR5 (~204.8 GB/s) |
| New interfaces | PCIe Gen5, 25GbE | earlier PCIe/Ethernet |
| Best fit | Large multimodal, VLA, on-device LLM | CV, small-mid models, cost-sensitive |
Figures reflect vendor-reported specs; verify the exact SKU against NVIDIA documentation before purchase.
The Software Stack: Where the Upgrade Really Lands
Hardware is only half of a Jetson decision; the software stack determines whether the silicon’s headline numbers turn into shipped product. Both modules run NVIDIA’s JetPack SDK, which bundles the Linux for Tegra base, CUDA, cuDNN, TensorRT, and the multimedia and camera stacks. The version of JetPack that supports a given module — and which framework versions it pins — is often the real gating factor on a timeline.
TensorRT is the component most teams live and die by, because it is what converts a trained model into an optimized engine for the device. Thor’s FP4 advantage is only realized if your model is quantized and compiled to exploit it; a model left in FP16 will run well but will not show the headline multiplier. Budget engineering time for the quantization-and-calibration loop, because moving a model to a new precision without accuracy loss is real work, not a compiler flag. For vision pipelines, DeepStream provides hardware-accelerated decode, inference, and tracking; for robotics, Isaac ROS packages GPU-accelerated perception. Confirm the versions you depend on are validated for your target module before committing.
Precision and quantization in practice
The precision story is the crux of the whole comparison. Orin’s strength is INT8, a precision with mature tooling and well-understood accuracy behavior across vision models. Thor adds FP4, which roughly doubles throughput over INT8 for models that tolerate it — chiefly large transformers and multimodal networks. But not every model quantizes cleanly to 4 bits; accuracy-sensitive workloads may need mixed precision, keeping some layers at higher bit-width. The practical implication is that Thor’s advantage is largest for modern generative and VLA workloads and smallest for classic CNN vision, which is exactly the axis on which the buy decision should turn.
Power modes and sustained performance
Both modules expose configurable power modes (via nvpmodel) that cap clocks and cores to fit a power budget, and both can be tuned with jetson_clocks. The number that matters for a product is not peak throughput at maximum power but sustained throughput within your thermal and battery envelope. A module that hits its rated figure for thirty seconds and then throttles is not delivering that figure in production. Thor’s higher ceiling means a wider gap between peak and sustained if cooling is inadequate, so thermal design is more consequential on Thor, not less. Always benchmark at the power mode and enclosure you will actually ship.
Three Workload Walk-throughs
Abstract specs get concrete when mapped to real deployments, so consider three representative workloads and how the decision falls for each.

Figure 2 (workload lens): multi-stream CV sits comfortably on Orin, a single large VLA policy or multimodal model pushes into Thor’s 128 GB and FP4, and on-device LLM serving depends on model size relative to Orin’s 64 GB ceiling.
Multi-camera computer vision. A warehouse robot running four to eight camera streams with detection, segmentation, and tracking is a classic Orin workload. These models are INT8-friendly and fit comfortably in 64 GB. Orin AGX handles this today in the field, and Thor would add cost without changing the outcome. Unless you are adding a large on-device language or VLA component, Orin is the disciplined choice here.
A vision-language-action policy. A general-purpose or humanoid robot running a single large VLA policy that fuses vision, language, and action is where Thor becomes necessary. These models are large, benefit from FP4 acceleration, and often exceed 64 GB when combined with perception. Thor’s 128 GB and Blackwell FP4 throughput are the enabling features, and its efficiency per operation helps battery-powered platforms. This is the workload the module was designed for.
On-device LLM serving. Running a mid-size language model locally — for a kiosk, a private assistant, or an offline agent — depends entirely on model size. A quantized model that fits in Orin’s 64 GB and meets your tokens-per-second target runs fine on Orin. A larger model, or one you want to serve at higher throughput with FP4, needs Thor. Profile the specific model at the specific precision; the answer is a memory-and-latency calculation, not a brand preference.
Procurement and lifecycle
Finally, weigh lifecycle. Orin has years of field history, a deep base of validated carrier boards and peripherals, and predictable supply — valuable for a product shipping now. Thor is newer, so the ecosystem of carrier boards, camera drivers, and validated peripherals is still maturing, and long-term availability windows should be confirmed with NVIDIA for any multi-year program. For a product with a five-to-seven-year service life, availability and support horizon can outweigh raw performance.
Trade-offs, Gotchas, and What Goes Wrong
The most common mistake is comparing Thor’s FP4 throughput to Orin’s INT8 throughput and concluding Thor is “7x faster” for your workload. That multiplier only materializes for models that actually run in FP4. A vision model pinned to INT8 will see a far smaller gain, and paying for Thor to run it is wasted budget.

Figure 3: The upgrade is not free — Thor’s higher performance comes with higher power draw, higher module cost, and greater thermal design demands, which ripple into enclosure, battery, and BOM decisions across a fleet.
Figure 3 captures the second-order costs that a spec-sheet comparison hides: a more powerful module changes your power budget, thermal solution, and per-unit cost, all multiplied across a fleet.
Power and thermals are the second gotcha. Thor’s higher ceiling means higher peak draw and more heat to dissipate. On a battery-powered robot, that affects runtime and cooling design; a module that throttles under thermal limits will not deliver its rated numbers. Validate sustained, not peak, performance in your actual enclosure.
Cost at fleet scale is the third. The per-module price delta multiplied across hundreds or thousands of units is often larger than the engineering cost of making Orin work. If Orin meets your targets, the disciplined choice is to ship on Orin and reserve Thor for the SKUs that need it.
Finally, software and ecosystem timing. New platforms take time for every framework, driver, and third-party package to fully support. Confirm that your inference runtime, camera drivers, and robotics middleware are validated on Thor’s JetPack before committing a product timeline to it.

Figure 4: A decision path — if the model fits Orin’s memory and hits latency at the needed precision, ship on Orin; if memory, FP4 acceleration, or future model growth is the constraint, move to Thor.
Figure 4 reduces the whole comparison to two gates: does it fit, and does it hit latency at your precision. If both are yes on Orin, upgrading is optional.
Total Cost of Ownership and Mixed Fleets
The purchase price of a module is only the first line of its cost. A serious comparison weighs total cost of ownership across the product’s life: module and carrier-board cost, power draw over years of operation, cooling and enclosure engineering, and the software effort to hit performance targets on a given precision. Orin often wins on acquisition and power for workloads it can serve; Thor wins on capability-per-watt for large models that would otherwise need a bigger, hotter, or simply infeasible solution. The honest calculation is per-workload, not per-datasheet.
For teams shipping a product family, a mixed fleet is frequently the right answer rather than a single standard module. A vendor might ship a cost-optimized SKU on Orin for the classic-vision configuration and a flagship SKU on Thor for the configuration that runs a large on-device model, sharing as much of the software stack as possible across both. The cost of maintaining two hardware targets is real, but it is often smaller than the cost of over-provisioning every unit with Thor or under-serving the high-end configuration with Orin. Decide the split by looking at the distribution of your actual deployed workloads, and revisit it as models grow — the memory wall that makes Thor necessary tends to arrive sooner than teams expect as multimodal and agentic models become standard on robots.
Practical Recommendations
Decide from the workload, not the datasheet. Profile your actual models at the precision you will deploy, measure memory footprint, and check whether Orin already meets latency. If it does and future model growth is modest, ship on Orin and save the budget. If memory capacity, FP4 acceleration, or multi-model concurrency is your wall, move to Thor.
Always compare at matched precision, validate sustained performance inside your real thermal enclosure, and confirm software support for your full stack on Thor before committing a timeline. At fleet scale, weigh the per-unit price delta against the engineering cost of optimizing for Orin.
A short checklist:
- Profile real models at deployment precision on both, if possible.
- Confirm memory footprint fits the target module (the hard wall).
- Compare Thor FP4 to Orin INT8 only if your model runs FP4.
- Validate sustained (not peak) performance in the production enclosure.
- Verify runtime, driver, and middleware support on Thor’s JetPack.
- Multiply the price delta across the fleet before deciding.
Frequently Asked Questions
How much faster is Jetson Thor than Jetson Orin AGX?
NVIDIA positions Thor at roughly 7.5x the AI compute and about 3.5x the energy efficiency of AGX Orin. However, Thor’s headline throughput (~2070 FP4 TFLOPS) is measured at FP4, a precision Orin does not support, while Orin’s ~275 TOPS is INT8. For a model that runs in FP4 the gap is large; for one pinned to INT8 it is much smaller. Always compare at the precision your model actually uses.
Does Jetson Orin AGX still make sense in 2026?
Yes. For classic computer vision, small-to-mid models, and cost-sensitive products that already meet latency within 64 GB of memory, Orin AGX remains an excellent, field-proven choice with a mature software stack. The Thor upgrade only pays off when memory capacity, FP4 acceleration, or future model growth is your binding constraint. If Orin hits your targets, upgrading may add cost without benefit.
What is the biggest practical difference between the two?
Memory is often the deciding factor. Thor offers 128 GB LPDDR5X at about 273 GB/s versus Orin’s maximum 64 GB at about 204.8 GB/s. A large multimodal model, a vision-language-action policy, or several concurrent models may simply not fit in 64 GB, making Thor the only option regardless of raw TOPS. When models fit Orin, the compute gap matters less.
What is FP4 and why does it matter?
FP4 is a 4-bit floating-point datatype introduced with Thor’s Blackwell GPU that roughly doubles throughput over INT8 for models that support it. It is central to Thor’s headline performance for transformer and multimodal inference. Orin does not support FP4, so any Thor-versus-Orin comparison should use matched precision; otherwise the FP4 figure overstates the real-world gap for models that cannot use it.
Is Thor worth it for a battery-powered mobile robot?
It depends on thermals and runtime. Thor delivers more performance and better efficiency per operation, but its higher peak power draw and heat output affect battery life and cooling design. If your perception and control stack fits Orin’s envelope, Orin may give better runtime for the same enclosure. If you run large on-device models, Thor’s efficiency per token can justify the move — validate sustained performance in the real chassis.
Will my existing Orin software run on Thor?
Broadly, the Jetson and JetPack software model carries forward, but new platforms take time for full framework, driver, and third-party support. Before committing a product timeline to Thor, confirm that your inference runtime, camera and sensor drivers, and robotics middleware are validated on Thor’s current JetPack. Treat ecosystem readiness as a gating item, not an afterthought.
Further Reading
- Hailo-10H vs Jetson Orin Nano for edge CV (2026) — the low-power end of the edge spectrum.
- TensorRT-LLM vs llama.cpp on Jetson (2026) — running LLMs on these modules.
- INT4 vs INT8 vs FP8 on edge NPUs (2026) — the quantization context behind FP4.
- ROS 2 Jazzy on Jetson Orin warehouse robotics (2026) — Orin in a real robotics deployment.
- External: NVIDIA Jetson modules documentation.
By Riju — about
Jetson Thor vs Orin AGX: October 2026 Questions Answered
How much does Jetson AGX Thor cost in 2026?
As of the July 2026 price increase, the Jetson AGX Thor Developer Kit lists at $5,499, up from the $3,499 launch price. The T5000 production module is $4,999 at 1,000-unit volumes, up from $2,999, and the smaller T4000 module is $2,999. NVIDIA made the change without a separate announcement, so prices appeared in its developer FAQ first. Distributors may add their own margins or bundles, so always confirm the current figure with an authorized reseller before budgeting a project.
What is the difference between Jetson T5000 and T4000?
Both are Blackwell-based Thor modules. The T5000 has a 2560-core GPU with 96 Tensor Cores, a 14-core Arm Neoverse-V3AE CPU, 128 GB of LPDDR5X and about 2070 sparse FP4 TFLOPS, with a 40 to 130 W power range. The T4000 steps down to a 1536-core GPU with 64 Tensor Cores, 12 CPU cores, 64 GB of memory and about 1200 FP4 TFLOPS at 40 to 70 W. NVIDIA listed the T4000 as preliminary at launch, so confirm final specifications before designing around it.
What power range do Thor and Orin AGX support?
Jetson AGX Orin 64GB is configurable from roughly 15 W to 60 W, which suits battery-powered robots and fanless enclosures. Jetson AGX Thor’s T5000 runs from 40 W up to 130 W, and the T4000 from 40 W to 70 W. Thor’s performance per watt is better, but its floor and ceiling are both higher, so it needs a stronger power supply and thermal design. Benchmark at the power mode and enclosure you will actually ship, not at the peak rating.
Is the Jetson AGX Orin being discontinued?
No discontinuation of AGX Orin was found in current NVIDIA sources, and it remains on sale through the NVIDIA marketplace and distributors, though stock has been tight. NVIDIA did phase out several other Jetson modules earlier in 2026 because of high LPDDR4 prices, so supply risk is real across the family. For a multi-year product, ask NVIDIA or your distributor for the committed availability window of the exact module and plan a second-source or last-time-buy strategy.
Should I buy a Jetson Thor now or wait?
If your roadmap includes large VLA, multimodal or on-device LLM workloads, prototype on Thor now, because software maturity and model growth matter more than a hoped-for price drop. NVIDIA raised prices in July 2026 and gave no sign of reversing them, and developer kits are frequently out of stock at the marketplace. If your current stack runs well on Orin, there is little reason to pay the premium: profile first, then decide per workload and per SKU.

Pingback: MIG on Jetson Thor: Mixed-Criticality GPUs (2026)
Pingback: MLPerf Edge Agentic Inference 2026: Thor vs llama.cpp
Pingback: FPGA vs GPU vs NPU for Edge Inference: Latency, Power and HL