Jetson Thor T3000 and T2000 vs T5000: which module to pick

NVIDIA has filled out the Jetson Thor lineup downward: the T3000 (865 FP4 TFLOPS, 32GB) and T2000 (400 FP4 TFLOPS, 16GB) bring the Blackwell-based Thor architecture into mainstream robotics and edge-AI price and power territory, joining the existing T5000 flagship and T4000. Hardware ships Q1 2027, with T3000 emulation available in JetPack 7.2.1 from late July 2026. The headline engineering fact: the T3000 keeps the T5000’s full 273GB/s memory bandwidth, which is why NVIDIA can claim similar multimodal inference performance at roughly half the size and power.

Key Insights

• T3000 = the LLM value pick on paper: 865 FP4 TFLOPS but the same 273GB/s bandwidth as the T5000, and token generation is bandwidth-bound, not TFLOPS-bound
• T2000 is the volume play: 400 FP4 TFLOPS / 16GB for visual AI agents, AMRs, and industrial manipulators, but its full datasheet is not published yet
• Nothing ships until Q1 2027: plan current designs on Orin or T5000/T4000; start Thor software work in emulation on JetPack 7.2.1
• Jetson Agent Skills are real repos, not marketing: jetson-device-skills and jetson-bsp-skills on GitHub, executable by coding agents for Linux customization, memory optimization, and benchmarking
• The memory-optimization story is an Orin story today: published results reclaim 4–15GB on Orin-class devices, letting designs drop one memory SKU

What did NVIDIA announce?

Two new modules on the Thor (Blackwell GPU + Arm Neoverse) architecture, positioned below the T5000 and T4000:

• Jetson T3000: 865 FP4 teraflops, 32GB LPDDR5X at 273GB/s, eight-core Arm Neoverse CPU, 25GbE, at “roughly half the size and power of the T5000.” NVIDIA states it achieves similar inference performance to the T5000 for multimodal workloads: LLMs, VLMs, vision-language-action models, and world foundation models.
• Jetson T2000: 400 FP4 teraflops and 16GB of memory, the entry point for visual AI agents, autonomous mobile robots, and industrial manipulators. Detailed specifications (CPU configuration, bandwidth, power range) have not been published; NVIDIA says the datasheet and design guide come closer to release.

With these, the Jetson platform now spans “70 TOPS to 2,000 teraflops”, from Orin Nano to T5000, on one software stack.

Jetson Thor lineup: full spec comparison

	T2000	T3000	T4000	T5000
AI compute (FP4)	400 TFLOPS	865 TFLOPS	1,200 TFLOPS (sparse)	2,070 TFLOPS (sparse)
GPU	Blackwell	Blackwell	1,536-core Blackwell, 5th-gen Tensor Cores	2,560-core Blackwell, 5th-gen Tensor Cores
CPU	not yet published	8-core Arm Neoverse	12-core Neoverse-V3AE	14-core Neoverse-V3AE
Memory	16GB	32GB LPDDR5X	64GB 256-bit LPDDR5X	128GB 256-bit LPDDR5X
Memory bandwidth	not yet published	273GB/s	273GB/s	273GB/s
Power	not yet published	~half of T5000	40–70W	40–130W
Networking	not yet published	25GbE	3x 25GbE	4x 25GbE
Availability	Q1 2027	Q1 2027	shipping	shipping

Specs as published by NVIDIA at announcement; T2000 rows marked “not yet published” are exactly that: treat any number you see elsewhere for them as speculation.

Why can the T3000 match the T5000 on LLM inference?

This is the part of the announcement worth an engineer’s attention. The T3000 has well under half the T5000’s FP4 compute, yet NVIDIA claims similar inference performance on multimodal workloads. That claim is credible for a specific reason: LLM token generation is memory-bandwidth-bound. Every generated token walks the full weight set, so decode throughput scales with GB/s, not TFLOPS, and NVIDIA lists both modules at the same 273GB/s.

We see the same physics constantly in LLM work on Jetson Orin: quantization tiers and memory bandwidth dominate tokens-per-second; raw compute sits idle during decode. What the T5000’s extra compute (and 128GB) buys you instead:

• Prefill speed: long-context ingestion is compute-heavy
• Vision encoders and CNN pipelines: genuinely TFLOPS-bound
• Bigger models: 128GB holds weight sets the T3000’s 32GB simply cannot
• Concurrency: batching multiple streams shifts the bottleneck back toward compute

If your workload is “run a quantized multimodal model and stream tokens,” the T3000 is the rational pick. If it’s “many camera streams through heavy vision models plus an LLM,” the T4000/T5000 tiers still earn their price.

What are Jetson Agent Skills?

This is the software half of the announcement, and it’s more concrete than the name suggests. NVIDIA published agent-executable skill repositories on GitHub: jetson-device-skills and jetson-bsp-skills. Each skill is a repeatable recipe (which tools to call, what outputs to produce, how to validate) that a coding agent executes against your Jetson. Three categories shipped:

1. Linux customization for custom carrier boards
2. Memory optimization across the stack: bootloader memory carveouts, kernel memory reservation, redundant userspace process cleanup
3. Model benchmarking and inference optimization

The published results are specific: up to 15GB reclaimed (moving a UBTech/Agile Robots/Connect Tech design from Orin 64GB to Orin 32GB), 4GB reclaimed (SandStar, Orin NX 16GB → 8GB), and a 30% reduction on Jetson TX2 NX (NoTraffic). The pattern NVIDIA is selling: reclaim memory in software, drop one memory SKU in hardware, keep the performance tier. Skills-driven agent automation is the same pattern we run internally for BSP work. It’s a genuine productivity shift when the skills encode real platform knowledge, and NVIDIA encoding its own platform knowledge this way is the strongest endorsement of the approach yet.

Worth noting: these support the entire Jetson portfolio, Orin included: you don’t need Thor hardware to benefit. On JetPack 7.2, Orin and Thor also converge on one stack: Ubuntu 24.04, kernel 6.8, CUDA 13.0.

Which module should you pick?

• Shipping a product in the next 12 months → this announcement changes nothing for you: Orin (Nano/NX/AGX) and the shipping T5000/T4000 are the options. See our Orin module comparison for that decision.
• Designing for 2027 with multimodal/LLM workloads → T3000 is the default candidate: T5000-class decode throughput, half the power and size, 32GB. Start software now in T3000 emulation on JetPack 7.2.1.
• Cost-sensitive volume robotics for 2027 → T2000 on paper, but hold hardware decisions until the datasheet lands. 400 FP4 TFLOPS and 16GB is a real tier jump over Orin NX, but power, bandwidth, and I/O are still unpublished.
• Maximum models, maximum streams → T5000 remains the flagship: 128GB and 2,070 TFLOPS have no substitute in the lineup.
• Existing Orin fleet → the immediately actionable part is Agent Skills: if a memory-optimization pass reclaims even 4GB, moving down one memory SKU at fleet scale is real money, available today, no Thor required.

One BSP-side note for Yocto users: Thor support lives in the master-l4t-r38.x line of meta-tegra (JetPack 7.x), separate from the scarthgap (JetPack 6 / Orin) branch most production builds use today. Budget for that branch split when planning a mixed Orin + Thor fleet.

What should you do before Q1 2027?

1. Prototype in emulation: T3000 emulation on JetPack 7.2.1 means the software stack, memory budget, and model selection can be validated months before silicon.
2. Run the memory-optimization skills on your current Orin design: the savings are useful regardless of whether you ever move to Thor.
3. Re-run your model-selection math against 273GB/s: if you sized your module tier by TFLOPS, the bandwidth-bound reality of LLM decode may move you a tier down.

If you’re planning a Jetson platform decision (Orin now, Thor later, or a migration between them), our Jetson engineering team does this for a living: BSP bring-up, camera pipelines, and model deployment under real memory budgets, on a fixed bid.

Sources: NVIDIA’s announcement, the Jetson Thor product page, and the JetPack 7.2 memory-efficiency deep dive.