Jetson T3000 vs T4000 vs T5000: Choosing a Thor Module on Bandwidth, MIG, and Power

Most module-selection spreadsheets rank Jetson Thor parts by TFLOPS, and most of them pick the wrong SKU. The Jetson T3000 that NVIDIA announced on 15 July 2026 publishes 865 FP4 TFLOPS against the T5000’s 2,070 — a 2.4× gap that looks decisive on a slide. Yet NVIDIA’s own claim is that the T3000 delivers “similar inference performance” to the T5000 for LLMs, vision-language models, vision-language-action policies and world foundation models. Both statements are true, and the reason they are both true is the single most useful thing an embedded architect can know about this lineup: the number that governs token throughput is not FLOPS, it is memory bandwidth, and three of the four Thor modules share exactly the same 273 GB/s.

This post derives that arithmetic so you can compute your own numbers, then works outward to GPU partitioning, sensor ingest, carrier-board cost and the schedule risk of designing around silicon that ships in Q1 2027.

What this covers: the roofline math behind 273 GB/s versus 137 GB/s, when mixed-criticality separation genuinely forces a partitionable GPU, what 25 GbE buys you over 10 GbE in camera terms, and an honest decision matrix — including where the published specs are still unconfirmed.

Context and Background

Until July 2026 the Jetson Thor family was two modules. NVIDIA’s Jetson Thor product page lists the T5000 at 2,070 FP4 sparse TFLOPS with a 2,560-core Blackwell GPU, 96 fifth-generation Tensor Cores, a 14-core Arm Neoverse-V3AE CPU, 128 GB of 256-bit LPDDR5X at 273 GB/s, four 25 GbE interfaces and a 40–130 W envelope. The T4000 sits below it at 1,200 FP4 sparse TFLOPS, a 1,536-core GPU with 64 Tensor Cores, a 12-core CPU, 64 GB at the same 273 GB/s, three 25 GbE interfaces and 40–70 W. Both are 100 mm × 87 mm on a 699-pin board-to-board connector.

That was a fine lineup for humanoid research platforms and a poor one for anything shipping in volume. A 128 GB module is an expensive way to run a 4-billion-parameter policy network, and 2026 made it worse: DRAM contract pricing moved sharply upward through the year as wafer capacity shifted toward HBM for data-centre accelerators. Connect Tech’s launch commentary cites TrendForce at 50–55% quarter-over-quarter DRAM price growth and IDC at roughly 16% supply growth for 2026; treat those as reported third-party figures rather than verified NVIDIA data, but the direction is not in dispute if you have priced a bill of materials this year.

NVIDIA’s answer was to extend the same Thor SoC downward. The announcement introduced the T3000 — 865 FP4 TFLOPS, an eight-core Neoverse Arm CPU, 32 GB of LPDDR5X at 273 GB/s and 25 GbE — plus an IGX T3000 variant that adds integrated functional safety and runs NVIDIA’s Halos for Robotics stack. The T2000 arrives with 400 FP4 TFLOPS and 16 GB. NVIDIA states both are “about half the size and power” of the T5000 and scheduled for Q1 2027. That gives the platform a continuous range from the 70-TOPS Orin Nano to the 2,070-TFLOPS T5000, which is exactly the range in which most robotics programmes actually live — and exactly the range in which a wrong module choice costs you a carrier-board respin.

The Bandwidth Roofline That Actually Decides the Module

For single-stream autoregressive decode — one robot, one policy, one token at a time — throughput is bounded by how fast the module can stream model weights and KV cache out of LPDDR5X, not by how many FLOPS the Blackwell GPU can issue. Because the T3000, T4000 and T5000 all publish 273 GB/s, they land within a small factor of each other on that workload, and the real bandwidth cliff in this lineup is the step down to the T2000.

Figure 1: Workload shape, not headline TFLOPS, selects the Thor tier.

The flow starts by classifying the hot path. A decode-dominated workload (an LLM planner, a VLA policy emitting action tokens) is bandwidth-bound and needs the 273 GB/s tier. A vision-dominated pipeline is usually bound by the image signal processor and the video encode/decode engines. A control-dominated loop is bound by CPU cores and deterministic scheduling. Only after that classification does capacity — how much LPDDR you need resident — choose between T3000, T4000 and T5000.

Why decode is bandwidth-bound, from first principles

Autoregressive generation with batch size one is a sequence of matrix-vector products. Every weight in the model is read from memory, multiplied by one activation value, and accumulated. That gives an arithmetic intensity of roughly two floating-point operations per parameter. If the parameter is stored at 4 bits, that is 2 FLOP per 0.5 byte — about 4 FLOP per byte moved.

Now compute the ridge point of the roofline for each module: peak FLOPS divided by peak bandwidth. For the T3000 that is 865 × 10¹² ÷ 273 × 10⁹ ≈ 3,170 FLOP per byte. For the T5000, ≈ 7,580. For the T2000, using the reported 137 GB/s, ≈ 2,920. A kernel at 4 FLOP per byte is three orders of magnitude below every one of those ridge points. It is not close to the compute roof. It is sitting on the memory roof with room to spare.

That is the whole explanation for NVIDIA’s “similar inference performance” claim. Handing a batch-size-one decode kernel 2.4× more FLOPS changes almost nothing, because the tensor cores were already idle waiting on DRAM.

Plugging in real numbers so you can compute yours

The bound is straightforward:

tokens/second ≤ effective bandwidth ÷ (weight bytes + KV bytes read per token)

Effective bandwidth is not peak bandwidth. A well-tuned GEMV kernel on LPDDR typically achieves somewhere between 60% and 85% of the theoretical figure once refresh, page misses and read/write turnaround are accounted for. I will use 70% throughout as a planning assumption — measure yours rather than inheriting mine.

Take an 8-billion-parameter transformer in a typical 4-bit packing, which lands near 4.7 GB on disk once you account for embeddings and norms kept at higher precision. Assume a grouped-query attention configuration with 32 layers, 8 key-value heads and a head dimension of 128, with the cache in FP16. Per token per layer the cache holds 2 × 8 × 128 × 2 bytes = 4,096 bytes; across 32 layers that is 128 KiB per token. At 4,096 tokens of context the cache is 0.54 GB; at 32,768 tokens it is 4.29 GB. Decode reads the whole cache every step.

Module	Peak BW	Effective at 70%	4k context	32k context
T5000 / T4000 / T3000	273 GB/s	191 GB/s	~36 tok/s	~21 tok/s
T2000 (reported 137 GB/s)	137 GB/s	96 GB/s	~18 tok/s	~11 tok/s

These are ceilings derived from the transformer shape above, not measured benchmarks — substitute your own layer count, KV head count and quantization and the same three lines of arithmetic give you your ceiling. Two conclusions fall straight out. First, the T2000 is exactly half the decode throughput of every other Thor module, because 137 is half of 273. Second, context length is as powerful a lever as module choice: going from 4k to 32k of context costs you more throughput on a T5000 than dropping from a T5000 to a T3000 does.

That second point is the one teams miss. If your VLA policy is carrying 32k tokens of observation history, trimming the context window or switching to a smaller KV footprint buys back more tokens per second than upgrading the module class — at zero BOM cost.

Where the cliff actually is

The naive reading of the lineup is a smooth ladder: T2000 → T3000 → T4000 → T5000, each step better. The bandwidth reading is a step function. Three modules share one memory configuration and one drops to half.

ServeTheHome’s launch analysis reached the same structural conclusion, noting that the T3000 “retains the full memory bandwidth of the Thor SoC” on a 256-bit bus while the T2000 runs “half of the memory bus.” Note one discrepancy worth flagging: ServeTheHome’s comparison table prints 237 GB/s for T3000/T4000/T5000 while the body text of the same article says 273 GB/s. NVIDIA’s own page and NVIDIA’s own launch blog both say 273 GB/s, so the table figure is a transposition error. The same table lists 2,048 CUDA cores for the T5000; NVIDIA specifies 2,560. Where secondary tables and NVIDIA disagree, NVIDIA wins.

Vision pipelines obey a different constraint entirely

None of the above governs a multi-camera perception stack. A detector running at 30 fps on eight streams is a throughput problem with a fixed deadline, and the binding resources are usually the ISP, the hardware video decode units, the DLA where one is used, and the PCIe or Ethernet path feeding frames in. NVIDIA publishes two NVENC and two NVDEC blocks on the T5000 against one of each on the T4000. Encode and decode unit counts for the T3000 and T2000 have not been published, which matters enormously if your pipeline records or transcodes — that is a gap you must close with NVIDIA before you commit.

For these pipelines, the FLOPS number is more meaningful than it is for decode, because batched convolution and attention over many frames does reach respectable arithmetic intensity. A T2000 at 400 TFLOPS is genuinely a quarter of a T5000 for that work, in a way it is not for single-stream decode.

Capacity, Not Throughput, Is the T3000 vs T5000 Decision

Once you accept that the 273 GB/s tier performs alike on decode, the choice between T3000, T4000 and T5000 collapses to a single question: does your resident working set fit in 32 GB, 64 GB or 128 GB? This is a much easier question to answer honestly, and it is answerable today, before the hardware ships.

Figure 2: What actually consumes the 32 GB on a Jetson T3000 — weights are rarely the largest line.

The stack is weights, KV cache, vision buffers and ISP scratch, the ROS 2 graph and its middleware, and the operating system plus page cache. On a unified-memory SoC every one of those lines draws from the same LPDDR pool; there is no separate GPU framebuffer to hide in.

Working the budget

Using the 8B model above: 4.7 GB of weights plus 4.29 GB of KV at 32k context is 9 GB. An eight-camera perception graph with double-buffered 4K frames and intermediate tensors will plausibly occupy 4–8 GB depending on how aggressively you reuse allocations. ROS 2 with a dozen nodes, a costmap and a point-cloud pipeline is comfortably 2–4 GB. Ubuntu plus page cache is another 2–3 GB. That totals roughly 17–24 GB against a 32 GB module — tight but workable, with the caveat that fragmentation on a unified-memory device is a real failure mode and you should size for the peak, not the mean.

Now change one variable. A 70-billion-parameter model at 4 bits is roughly 35 GB of weights alone. It does not fit on a T3000 at any context length. That is the honest boundary: the T3000 is not a slower T5000, it is a T5000 with a smaller ceiling on model size. If your product roadmap has a larger policy model in it, you are buying capacity, and you should buy the T4000 or T5000 for that reason and say so explicitly in the design review — not because it has more TFLOPS.

The software lever NVIDIA is pushing

Alongside the modules, NVIDIA shipped Jetson agent skills aimed at memory optimisation, and was unusually blunt about the purpose: to let customers “move down one memory SKU within the same product tier without compromising performance.” The cited results include UBTech, Agile Robots and Connect Tech reducing usage by up to 15 GB and dropping from a 64 GB AGX Orin to a 32 GB module. Those are vendor-supplied customer figures, so weigh them accordingly — but the architectural implication is sound. If a two-week memory-optimisation pass moves you from 34 GB resident to 28 GB, it changes your module class and your unit economics.

The related pattern is decomposition. A set of small specialised models orchestrated as agents holds less resident memory than one monolithic model doing everything, at the cost of orchestration complexity and more context switching. NVIDIA’s Cosmos 3 Edge, a 4-billion-parameter world model targeted at Thor, is built for exactly that shape. If you are quantizing and serving these on-device, our comparison of TensorRT-LLM versus llama.cpp on Jetson covers the runtime trade-offs that determine how close you actually get to the roofline ceilings above.

When GPU Partitioning Is a Hard Requirement — and When It Isn’t

This is where the T3000 decision gets genuinely contested, and where I have to be careful about what is confirmed.

Figure 3: Three ways to keep a safety-rated perception path from being starved by a best-effort planner.

What NVIDIA has and has not confirmed about MIG

NVIDIA’s Jetson Thor specification page explicitly lists Multi-Instance GPU for the T5000 (MIG with 10 TPCs) and the T4000 (MIG with six TPCs). The T3000 and T2000 are not yet on that specification table at all. Partner and press tables reproduce the same pattern — CNX Software’s preliminary comparison lists MIG and Tensor Core counts for T4000 and T5000 and lists neither for T3000 and T2000 — but that article states outright that NVIDIA had not published full specifications for the new modules, so the omission is preliminary reporting, not a documented exclusion.

So: the MIG status of the T3000 and T2000 is unconfirmed as of 21 September 2026. Several secondary write-ups assert that the new modules do not support MIG. I could not confirm that against NVIDIA’s own documentation, and there is a structural reason to be sceptical: the T3000 is reported to carry the same 1,536-core GPU as the T4000, which would put it at the same six TPCs that NVIDIA cites as the T4000’s MIG granularity. If the T3000 genuinely lacks MIG it would be a segmentation decision rather than a hardware limitation. Do not put that assumption on a critical path — ask NVIDIA directly under NDA before it constrains your architecture.

MIG on Thor is a technology preview, and it does not partition bandwidth

Two things about MIG on Thor matter more than which SKUs list it.

First, the JetPack 7.2.1 release notes, published 12 August 2026, state plainly that “MIG support on Jetson Thor T5000 remains a technology preview feature.” A technology preview is not something you certify a safety function against. If your architecture requires hardware-enforced GPU isolation today, MIG on Thor is not yet the answer regardless of module.

Second, and more interesting: MIG on Thor does not appear to partition memory the way it does on a discrete data-centre GPU. The Jetson Linux Developer Guide MIG page walks through enabling MIG on a Thor system and shows the output of nvidia-smi mig -lgip. Every listed profile — 1g, 2g and 3g, with and without graphics and media extensions — reports 0.00 GiB of memory. The profiles differ in SM count (6, 12 and 20 respectively), in decoder, encoder, JPEG and optical-flow engine counts, and in whether graphics is available. They do not differ in framebuffer, because on a unified-memory SoC there is no separate framebuffer to carve up.

The inference I draw from that — and I am labelling it an inference, not a documented guarantee — is that a MIG partition on Thor isolates streaming multiprocessors and fixed-function engines, but the partitions still contend for one LPDDR5X controller. If that is right, MIG does not protect a safety-rated perception path from a best-effort planner that saturates memory bandwidth. It protects it from being starved of SMs, which is a different and lesser guarantee. NVIDIA does not publish a per-instance bandwidth reservation for Thor; if your hazard analysis depends on one, get that in writing. We cover the partitioning mechanics in more depth in our Jetson Thor MIG and mixed-criticality partitioning guide.

The three real options

Time-slicing with stream priorities is the default and is fine for soft real-time. CUDA stream priorities and careful kernel sizing keep a 20 ms perception deadline healthy as long as the competing work is well-behaved. The failure mode is a long-running kernel from the best-effort path blocking the priority stream until it retires — jitter grows under load, and it grows exactly when the robot is busiest. Measure tail latency at P99.9, not mean.

GPU partitioning is the middle option: better isolation of compute resources, still-shared memory, and today a technology-preview status on the one module where it is confirmed. It is the right target for a 2027–2028 programme and the wrong thing to certify against in 2026.

A second SoC is the answer when you need genuine fault containment — a separate power domain, a separate failure domain, and an independent path that keeps working when the AI stack panics. This is also what the IGX T3000 is addressing from the other direction: NVIDIA describes it as delivering the same performance “with integrated functional safety” alongside the Halos for Robotics stack. If your requirement is a safety rating rather than merely predictable latency, a functional-safety variant or a physically separate controller is the architecture, and GPU partitioning is an optimisation you add later.

The honest summary: for most AMR and manipulator programmes, time-slicing plus disciplined kernel design is sufficient, and MIG is not a reason to choose one Thor module over another in 2026. For a rated safety function, MIG is not sufficient either.

Networking, Carrier Boards, and Thermals

What 25 GbE versus 10 GbE means in cameras

Thor’s sensor story runs over Ethernet. The T5000 exposes four 25 GbE interfaces, the T4000 three. NVIDIA’s T3000 announcement says “25 GbE connectivity” without stating how many ports are exposed — a meaningful omission for multi-camera designs. The T2000 is reported at 10 GbE.

Convert that to cameras. An uncompressed 1080p30 stream at 12 bits per pixel is 1920 × 1080 × 12 × 30 ≈ 746 Mbit/s. A 4K30 stream at the same depth is ≈ 2.99 Gbit/s. Allowing roughly 90% usable throughput after framing overhead, a single 25 GbE link carries about 30 of the 1080p streams or about 7 of the 4K streams; a 10 GbE link carries about 12 and about 3 respectively.

Figure 4: Sensor ingest and GPU inference contend for the same memory controller.

That is the number that should drive the T2000-versus-T3000 call for a vision product. Three 4K cameras is a common industrial configuration and it consumes a 10 GbE link almost entirely, leaving nothing for telemetry, fleet updates or a second sensor modality. If your camera plan grows, 10 GbE is a wall you hit early.

There is a second-order cost. Every ingested frame is DMA’d into the same LPDDR5X pool that the inference stack is streaming weights from. Seven 4K30 streams write roughly 2.6 GB/s; the ISP reads them back and the inference stage reads them again, so call it 8–10 GB/s of sustained traffic. Against 273 GB/s that is only 3–4% of peak — small, but it is latency-sensitive isochronous traffic sharing a controller with bursty GEMV reads, and it is one of the places where measured decode throughput falls short of the roofline ceiling.

The carrier board is the expensive part of changing your mind

The T4000 and T5000 are 100 mm × 87 mm on a 699-pin board-to-board connector. NVIDIA says the T3000 and T2000 are “about half the size”; CNX Software estimates roughly 50 mm × 87 mm but explicitly flags it as preliminary. The pin count, connector type and pinout for the T3000 and T2000 have not been published.

This is the schedule risk that matters more than any spec on the table. You cannot lay out a production carrier board for a T3000 today, because the mechanical and electrical interface is not public. Emulation mode gives you software parity, not board parity. A team that starts a carrier design now against T5000 geometry and later switches module class is looking at a full respin: new connector, new power tree sized to a different envelope, new thermal solution, new EMC qualification. On a typical industrial programme that is a two-to-four-month slip and a fresh round of certification cost.

The practical mitigation is to decide module class — half-size Thor versus full-size Thor — before you commit to carrier layout, even if you cannot yet decide the exact SKU within the class. The T4000 and T5000 are pin-compatible with each other; the T3000 and T2000 will presumably be pin-compatible with each other. Choosing the class early preserves one upgrade axis and forecloses the expensive one.

Power and thermals

NVIDIA publishes 40–130 W for the T5000 and 40–70 W for the T4000. For the T3000 it says only “about half the power” of the T5000. Secondary sources put a number on that and disagree: ServeTheHome says approximately 65 W, Connect Tech’s comparison table says 70 W, and CNX Software guesses at a 20–65 W range with an explicit question mark. Connect Tech’s table also lists 40 W for the T2000 and 140 W for the T5000, the latter of which is above NVIDIA’s own 130 W ceiling. Treat every T3000/T2000 power figure as reported and unconfirmed, and design your thermal solution against the upper end of the spread.

What is not in dispute is that all Thor modules carry an integrated thermal transfer plate and expect the carrier and enclosure to take the heat away. At 65–70 W in a sealed IP65 robot enclosure with no fan, conduction path design is the binding constraint on sustained clocks — and a module that thermally throttles delivers neither its FLOPS nor its bandwidth. If you are building the production image and boot chain around this, our comparison of Yocto OE4T versus Ubuntu L4T for Jetson production images covers the power-model and device-tree work that goes with a custom carrier.

Program Timing: Designing Around Q1 2027 Silicon

The T3000 and T2000 are scheduled for Q1 2027. That is two quarters out from today, and every embedded engineer has watched a Q1 slip into Q3.

NVIDIA’s bridge is emulation. JetPack 7.2.1, released 12 August 2026, “brings the support for NVIDIA Jetson T3000 emulation.” The mechanism is a flash configuration on an AGX Thor Developer Kit: manual flashing with the configuration file p3834-0008-as-p5767-0000-nvme presents the developer kit as a T3000. T2000 emulation is deferred to a future release. What emulation gives you is a machine that behaves like a T3000 for software bring-up, model sizing and camera integration. What it does not give you is a production module, a carrier-board pinout, a thermal profile or a real power measurement.

The other half of the bridge runs backwards. JetPack 7.2, announced at GTC Taipei on 1 June 2026, extended the 7.x line to the full Orin family — AGX Orin, Orin NX and Orin Nano — bringing Ubuntu 24.04, kernel 6.8 and CUDA 13 to hardware you can buy today. Reported alongside it is a Super Mode for the AGX Orin 32 GB that lifts GPU clocks from 930 MHz to 1.3 GHz at up to 60 W, taking it from roughly 200 to 241 TOPS. Those Orin figures come from JetPack coverage rather than an NVIDIA specification page I verified this run; confirm them on NVIDIA’s Orin module pages before you plan against them. Notably, partner comparison tables disagree on AGX Orin memory bandwidth — one prints 102 GB/s for the 64 GB module — so do not take Orin bandwidth from a third-party table either.

The strategic consequence is real. If you need silicon in hand for a 2026 pilot, Orin under JetPack 7.2 is a supported, shipping platform on the same 7.x software line, and you migrate to Thor later on a common stack rather than a common board. If you need Thor-class bandwidth in 2026, the T4000 and T5000 are the only options and you pay for capacity you may not use. If your production ramp is H2 2027 or later, the T3000 is the module the lineup was reorganised around — and you should be doing bring-up on emulation now while holding carrier layout until the mechanical spec publishes.

For teams making that Orin-now decision, our ROS 2 on Jetson Orin warehouse robotics walkthrough covers the stack that ports forward.

The Decision Matrix

Criterion	T2000	T3000	T4000	T5000
FP4 sparse TFLOPS	400	865	1,200	2,070
GPU cores	1,024 (reported)	1,536 (reported)	1,536	2,560
CPU cores (Neoverse-V3AE)	6 (reported)	8	12	14
Memory	16 GB	32 GB	64 GB	128 GB
Memory bandwidth	137 GB/s (reported)	273 GB/s	273 GB/s	273 GB/s
MIG	Unconfirmed	Unconfirmed	Yes, 6 TPCs	Yes, 10 TPCs
Networking	10 GbE (reported)	25 GbE, port count unstated	3× 25 GbE	4× 25 GbE
Power	Reported ~40 W	Reported 65–70 W	40–70 W	40–130 W
Footprint	~half size, pinout unpublished	~half size, pinout unpublished	100×87 mm, 699-pin	100×87 mm, 699-pin
Available	Q1 2027	Q1 2027	Shipping	Shipping

Read that table by row, not by column. The MIG row and the memory-bandwidth row are the two that create genuine discontinuities; the TFLOPS row is the one most likely to mislead.

Do not pick the biggest module by reflex. The reflex is defensible when compute is cheap relative to programme risk, and it is exactly wrong here for three reasons. A T5000 costs you 128 GB of LPDDR in a market where DRAM is the volatile line item in your BOM. A 130 W envelope forces a thermal solution — and often a fan — that a 65 W module does not, which cascades into enclosure size, ingress rating and acoustic requirements on a robot that shares space with people. And the performance you are buying is FLOPS you will not use if your hot path is batch-size-one decode, because that path was bandwidth-bound on all three of the 273 GB/s modules before you spent the money.

The inverse reflex is also wrong. Do not drop to a T2000 to save cost without checking the two things it actually loses: half the memory bandwidth, which halves decode throughput, and 10 GbE, which caps your camera count. If neither binds your design, it is the right module and the savings are real.

Trade-offs, Gotchas, and What Goes Wrong

The 70% bandwidth-efficiency assumption is doing a lot of work. Real achieved bandwidth depends on quantization format, kernel implementation, KV-cache layout and how much other traffic is on the controller. Teams routinely see 50–60% with a naive runtime and are then surprised the module “underperforms.” Measure with a memory-bandwidth microbenchmark before you blame the silicon.

Unified memory means there is no safe headroom. Every allocation — CUDA, ISP, ROS 2, page cache — competes in one pool. A perception graph that peaks 3 GB above its steady state during a burst will OOM-kill something, and on a 32 GB T3000 the margin for that is thin. Size for peak with fragmentation headroom, and pin your critical allocations early in boot.

FP4 sparse is the headline number and rarely the operating number. NVIDIA’s published TFLOPS figures are FP4 with structured sparsity. Dense throughput and higher-precision throughput are lower, and NVIDIA does not publish those for every module. If your model is not sparsity-friendly and you are running FP8 or BF16 layers, the ratio between modules stays roughly proportional, but the absolute numbers you plan against should not be the marketing figure.

Emulation validates software, not hardware. T3000 emulation on an AGX Thor developer kit runs the right software stack with the right memory configuration. It does not tell you the module’s real power draw, its thermal behaviour in your enclosure, or whether your connector footprint is right. Teams that treat emulation results as hardware validation discover the gap at EVT.

Encode and decode unit counts for the new modules are unpublished. If your product records video, streams to a fleet backend, or transcodes for a VLM, a reduction from the T5000’s two NVENC/NVDEC blocks would be a hard functional limit, not a performance taper. Get this confirmed before design freeze.

Specification tables in circulation contain errors. Within this research pass I found a bandwidth figure transposed as 237 instead of 273, a CUDA-core count of 2,048 instead of 2,560, a T5000 power ceiling of 140 W instead of 130 W, and two mutually inconsistent AGX Orin bandwidth figures — all in reputable outlets. Verify against NVIDIA’s own module pages and datasheets before any number enters a design document.

Practical Recommendations

Start by profiling, not by shopping. Instrument your existing pipeline on whatever Jetson you have and determine whether the critical path is bounded by memory bandwidth, by fixed-function engines, or by CPU. That single measurement eliminates two of the four modules for most teams. Then compute your resident memory budget at peak — weights, KV at your real context length, vision buffers, middleware, OS — and add 25% for fragmentation. Capacity picks the SKU; bandwidth picks the tier.

Treat every T3000 and T2000 number as provisional until NVIDIA publishes the module datasheets, and design the carrier board around the module class rather than the SKU so that a late change stays within one connector family.

A working checklist:

• Measure achieved memory bandwidth on your current module with a microbenchmark; do not assume 70%.
• Compute the decode ceiling from weight bytes plus KV bytes at your real context length, and compare it with your control-loop deadline.
• Budget resident memory at peak, including ISP and middleware, then add fragmentation headroom.
• Count your cameras in Gbit/s, not in units, and check the total against 10 GbE or 25 GbE with 90% usable throughput.
• Ask NVIDIA under NDA for T3000/T2000 MIG status, NVENC/NVDEC counts, exposed Ethernet port count, pinout and the power curve.
• Do not certify a safety function against MIG while it remains a technology preview; use a functional-safety variant or a second SoC.
• If you need silicon in 2026, evaluate Orin under JetPack 7.2 as the bridge and plan the Thor migration on the shared 7.x stack.
• Hold carrier-board layout until the half-size module mechanical specification is public, or commit deliberately to the full-size class.

Frequently Asked Questions

Is the Jetson T3000 slower than the T5000?

For batch-size-one LLM or VLA decode, barely — both modules run at 273 GB/s and that workload is bandwidth-bound, which is why NVIDIA claims similar inference performance for multimodal models. For batched vision work, parallel model serving or anything that genuinely saturates the tensor cores, the T5000’s 2,070 FP4 TFLOPS against the T3000’s 865 is a real 2.4× advantage. The T5000’s decisive edge is capacity: 128 GB versus 32 GB sets a hard ceiling on model size.

Does the Jetson T3000 support MIG?

Unconfirmed as of 21 September 2026. NVIDIA’s specification page lists Multi-Instance GPU for the T5000 with 10 TPCs and the T4000 with six TPCs, and has not yet published a full specification table for the T3000 or T2000. Secondary sources assert the new modules lack MIG, but NVIDIA’s documentation neither confirms nor denies it. Note also that JetPack 7.2.1 describes MIG on the T5000 as a technology preview, so it is not yet a feature to certify against on any module.

When will the Jetson T3000 and T2000 be available?

NVIDIA has scheduled both modules for Q1 2027. Development can start earlier through emulation: JetPack 7.2.1, released 12 August 2026, supports T3000 emulation on the Jetson AGX Thor Developer Kit using the flash configuration p3834-0008-as-p5767-0000-nvme. T2000 emulation is planned for a later release. Emulation covers software bring-up and model sizing only — module pinout, power and thermal behaviour are not represented.

How much memory bandwidth does each Jetson Thor module have?

NVIDIA specifies 273 GB/s over a 256-bit LPDDR5X bus for the T5000 (128 GB), the T4000 (64 GB) and the T3000 (32 GB). The T2000 is reported at 137 GB/s on 16 GB, consistent with running half the memory bus, though NVIDIA has not published that figure on its own specification pages. Treat 137 GB/s as reported by ServeTheHome, CNX Software and Connect Tech rather than vendor-confirmed.

Should I choose the T2000 to reduce cost?

Only if two specific constraints do not bind. The T2000 halves memory bandwidth, which roughly halves single-stream decode throughput, and it drops to a reported 10 GbE, which caps sustained uncompressed camera ingest at roughly three 4K30 streams. For a light visual-AI agent or a single-camera AMR, neither is a problem and the saving is real. For a multi-camera robot running a language-conditioned policy, both bind hard.

Can I design a carrier board for the T3000 now?

No. NVIDIA has described the T3000 and T2000 as roughly half the size of the 100 mm × 87 mm T4000/T5000 modules, but has not published the pin count, connector type or pinout. Any carrier layout started today would be speculative. The practical approach is to decide module class early, prototype on an AGX Thor Developer Kit in T3000 emulation mode, and hold the mechanical design until NVIDIA publishes the module datasheet.

Further Reading

• Jetson Thor MIG and GPU partitioning for mixed-criticality workloads — the partitioning internals this post deliberately does not repeat.
• Yocto OE4T versus Ubuntu L4T for Jetson production images — the BSP and boot-chain work a custom carrier implies.
• TensorRT-LLM versus llama.cpp on Jetson — how close each runtime gets to the bandwidth roofline.
• ROS 2 on Jetson Orin for warehouse robotics — the bridge platform if you need silicon before Q1 2027.
• NVIDIA Jetson Thor module specifications — the authoritative T4000 and T5000 figures used throughout.
• NVIDIA Jetson Linux Developer Guide: Multi-Instance GPU — the MIG profile table showing 0.00 GiB per instance on Thor.

By Riju — about