Not in the servo loop
Nobody credible puts a language model inside a servo loop, so the argument is about the tier above it — and that tier is decided by a memory bus, not by TFLOPS. NVIDIA partitions Jetson Thor so reasoning and control can coexist, and its own manual says memory bandwidth is proportional to the instance size: MIG rations one 273 GB/s bus in thirds rather than widening it. We wrote that nobody had measured two tasks sharing a Thor. Somebody had, in March, on a real humanoid — and the isolated baseline took 1030 ms against a 333 ms window. The 72 percent duty cycle we had been reading as a ceiling is NVIDIA saying the approach works, and the 19 Hz we quoted as a measurement is a roofline model, which our own page called a measurement until 12 September.
Figure's Helix page, dated 20 February 2025, publishes two rates for the same robot: "System 2 (S2): An onboard internet-pretrained VLM operating at 7-9 Hz", and "System 1 (S1): A fast reactive visuomotor policy… at 200 Hz." One set of weights — 7B for S2, 80M for S1 — coordinating a 35-DoF action space.
Seven to nine hertz is the fastest published semantic tier in the set of placements we checked, against 200 Hz of control and against our own published servo band of 500 to 1,000 Hz, which is a design target and not a measurement. Nobody credible proposes putting a language model inside a servo loop. No serious argument in robotics turns on whether they should.
The live question is which tier above the loop the semantic layer sits on, and how often it is allowed back in. On Jetson Thor that is settled by a memory bus. The module's headline number is 2,070 TFLOPS. The number that decides the architecture is 273 GB/s.
We own no Thor and have measured none of this. That sentence is live on our own Brain page in our own voice, and it is the only reason this article can be written: two of our pages published other people's Thor measurements as ours until 11 September, the correction we shipped that day introduced a second error, and in the research behind this piece we asserted that nobody had measured two large models running concurrently on a Thor. Somebody had, in March, on a real humanoid.
The number that decides it
NVIDIA's Jetson Thor page, fetched 11 September 2026, lists two modules beside each other. The T5000: 2070 TFLOPS (FP4—Sparse), a 2560-core Blackwell GPU, 128 GB 256-bit LPDDR5X at 273 GB/s, 40 to 130 W. The T4000: 1200 TFLOPS (FP4—Sparse), 1536 cores, 64 GB at 273 GB/s, 40 to 70 W. Half the memory, 58 percent of the TFLOPS [inference, 1200 ÷ 2070], and an identical bus.
Which matters because of what NVIDIA Research published in February. VLA-Perf — Jiang, Clemons, Sankaralingam and Kozyrakis, all four NVIDIA Research, arXiv 2602.18397v1, 20 February 2026 — is in the paper's own words "an analytical performance model". Its authors ran nothing on a Thor. Its only hardware validation is somebody else's tuned implementation on an RTX 4090, where "an optimized system can achieve 73.3∼82.6% of the theoretical roofline reported by VLA-Perf", and the paper says why it runs optimistic: "VLA-Perf assumes that the maximum theoretical compute capability and memory bandwidth are attainable for every operator executed." Every Thor figure in it is a modelled upper bound.
What the roofline finds is the mechanism. Takeaway 2, verbatim: "Action prediction is memory-bound across hardware, while vision and VLM inference are compute-bound on most GPUs except from Jetson Thor." The reason is on the same page. Thor "relies on LPDDR memory… (270 GB/s) than GDDR on RTX 4090 (1 TB/s) and HBM on B100 (8 TB/s). As a result, even the vision encoder and VLM backbone become memory-bound on Jetson Thor." The operator intensities behind that are 321.4 FLOPs per byte for the vision encoder, 542.8 for the VLM backbone and 54.0 for the action expert [modelled]. VLA-Perf's own figure for the bus is 270 GB/s, three below NVIDIA's published 273; both appear here and neither is averaged away.
Then the rates, which arrive in three kinds our own corpus had been flattening into one.
NVIDIA measured GR00T N1.7, a 3B policy, on an AGX Thor at 8.9 Hz in PyTorch eager and 12.4 Hz with TensorRT, under a qualification we had never carried: "4 denoising steps, 1 camera".
NVIDIA measured π₀.₅ too, in its Jetson AI Lab tutorial, and that rung is the best-specified one available to anyone: the pi05_libero checkpoint at action horizon 10, on a Jetson AGX Thor Developer Kit running JetPack 7.2. 132.00 ± 0.89 ms at PyTorch BF16 with torch.compile in MAXN mode, which is 7.6 Hz; 48.84 ± 0.16 ms with TensorRT at FP8 + NVFP4 in MAXN, which is 20.5 Hz [inference, arithmetic from the milliseconds]. A factor of 2.7 between BF16 and 4-bit on real silicon, with the accuracy cost stated: FP8 alone runs about 53 ms at "Most stable accuracy (cosine ≈ 0.9995)", against roughly 0.99 for FP8+NVFP4.
VLA-Perf models π₀ — a 2.7B model, not a 3B one — at 52.57 ms, or 19.0 Hz, at BF16 with chunk size 50 and 10 denoising steps [modelled]. Its larger rungs are not products: π₀-L, π₀-XL and π₀-XXL are, in the paper's words, "hypothetical larger VLA models" the authors built by swapping in SigLIP-Giant and the Llama2 family, π₀-XL being SigLIP-Giant 1.1B plus Llama2-13B plus a 2.9B action expert. Physical Intelligence does not make it, and its modelled rate is nobody's product performance.
And one independent developer measured π₀.₅ at 44 ms (23 Hz) and π₀ at 46 ms (22 Hz) on an AGX Thor [single source]: one poster, 7thuniversels, one thread dated 2 May 2026, precision and power mode never stated, the figures reached with "hand-written CUDA kernels" in his own inference engine after an MLIR-TRT build had got only to about 70 ms — and an NVIDIA moderator replied in the thread without verifying any of it, pointing to NVIDIA's own tutorial instead.
Read down that list and the discipline shows itself. The forum developer's measured 22 to 23 Hz sits above VLA-Perf's modelled 19.0 Hz roofline for the same model class, and above NVIDIA's own measured 20.5 Hz. Different chunk sizes, denoising steps and precisions: the rungs do not lie on one scale, and our published 10 to 25 Hz policy band envelopes the optimised rungs and nothing more. It does not contain the two unoptimised ones, and both of those are NVIDIA's own: 8.9 Hz for GR00T N1.7 in PyTorch eager, 7.6 Hz for π₀.₅ at BF16.
- A Tidewell design target — published, and measured on nothing
- Measured by the vendor named, on the hardware named
- Not a measurement of this part: a roofline model, or one unverified forum post
The vendor's own bar, at its true scope
The document carrying that GR00T table also carries three sufficiency bars. We had been quoting one of them with its ending cut off. All three, in full:
"10+ Hz — recommended minimum (Thor, Spark with TRT; most dGPUs with torch.compile): sufficient inference rate for typical manipulation tasks (paired with action chunking to reach ~30 FPS execution)."
"30+ Hz — high-frequency (H100, RTX Pro 6000 with TensorRT): headroom for reactive, low-latency closed-loop control where sub-30 ms per-step latency matters."
"< 10 Hz (Orin with TensorRT): only suitable for slow, non-reactive tasks."
And the paragraph from the same page that qualifies the whole reading: "Because each inference returns a multi-step action chunk, a ~10 Hz inference rate can sustain ~30 FPS execution via action chunking + asynchronous inference — you do not need 30 Hz inference to execute at 30 FPS." VLA-Perf says the same thing independently.
The plain reading — NVIDIA places its own robot module at its own recommended minimum and reserves the reactive tier for parts that are not robot modules — survives at one scope and fails at another. It is true of per-step reactivity: sub-30 ms per step is what the 30 Hz bar is about, and NVIDIA's own fastest measured Thor figure is 48.84 ± 0.16 ms per inference, at TensorRT FP8 + NVFP4 in MAXN mode. It is false as a claim that a Thor-borne policy cannot drive a robot at 30 FPS, which NVIDIA says chunking delivers from around 10 Hz. Our Brain page carried the wider version until 11 September and now carries the narrow one.
Seventy-two percent, and whose number it is
The figure this argument has leaned on hardest comes out of one sentence on NVIDIA's Cosmos 3 Edge blog of 19 August 2026, and the sentence after it is the one we left behind:
"On an NVIDIA Jetson AGX Thor T5000, it generates each action chunk in about 1.53 seconds (running at 640×540 resolution and 15 Hz), while a single chunk covers roughly 2.13 seconds of robot motion. Because the next chunk is ready before the current one finishes, the arm moves continuously, with no data-center GPU in the loop."
1.53 ÷ 2.13 is 0.7183 [inference, arithmetic]. The chunk shape corroborates on the same page: 32 actions at 15 Hz is 2.133 seconds.
Four things travel with that number. Both figures are in one sentence of one page, so it is not a cross-source splice. It is wall-clock occupancy of the reasoning tier, not GPU utilisation, memory occupancy or bandwidth. It is one model at one resolution at one rate, and dropping the resolution changes it. And NVIDIA is reporting a success: the continuity sentence is the point of the paragraph. Reading the same arithmetic as a ceiling — 2.13 seconds of motion less 1.53 seconds of compute leaves about six-tenths of a second per cycle for anything else [inference, arithmetic] — is our reading and not NVIDIA's, and this article argues against the source that produced its own number. An article that used the figure without the framing sentence would be misquoting by omission.
One further observation, and it needs care. NVIDIA's own deployment snippet further down that page is synchronous and executes half the chunk — result["action"][:16], annotated "first 16 of 32, then replan", under the prose "Executing only a prefix and replanning is standard practice." Sixteen actions at 15 Hz is 1.067 seconds of motion against 1.53 seconds to produce the next chunk [inference, arithmetic from two statements on one page], so the continuity claim depends on consuming a whole chunk while the recommended practice consumes half of one, and the page never says which of the two the 1.53 seconds is meant to sit inside.
- Cosmos 3 Edge on AGX Thor T5000 — 1.53–2.13 s — 32 actions at 15 Hz, 640×540
- The snippet: first 16 of 32 — 1.067 s — NVIDIA replans after half a chunk
- 1.53 s to make the next chunk — 1.53 s
- NVIDIA's measurement
- The half-chunk prefix
- Motion one chunk covers
- Time to the next chunk
The objection, taken at full strength
The strongest objection shipped on 1 June 2026. NVIDIA's JetPack 7.2 announcement: "JetPack 7.2 on Jetson Thor introduces support for MIG, allowing the integrated NVIDIA Blackwell GPU to be partitioned into two isolated GPU instances with dedicated compute, cache, and memory bandwidth." A larger partition of "12 SMs, 1536 CUDA cores" for AI and graphics, and "A second isolated compute partition for robotics, control, perception, or safety-critical workloads (8 SMs, 1024 CUDA cores)". The rationale is written for exactly the reader of this article: "control loops, AI perception, and generative AI reasoning must reliably coexist on a single embedded platform."
Take it at full strength: partitioning is real, it is shipped, and "dedicated … memory bandwidth" is NVIDIA's own phrase. If MIG gave each tenant its own bus, the argument above would be over. The blog carries no benchmark, though. Not one number, for any workload, on Thor or anywhere.
NVIDIA settles the bandwidth question itself, in the MIG User Guide's Thor section, page last updated 11 September 2026 and re-read on 12 September:
"The Thor iGPU uses unified system memory shared with the CPU. There is no dedicated video memory, so all profiles report 0 GB. Memory bandwidth is proportional to the instance size. At most two MIG instances can coexist simultaneously: one compute instance and one graphics (+gfx) instance. The full 3g.0gb profile cannot coexist with any other instance."
The profile table beside it says the same thing in a column. Where the H100 rows give a Fraction of Memory of 1/8, 1/4, 2/8, 4/8 and Full, every Thor profile reports Fraction of Memory = N/A against a Fraction of SMs of roughly one third or two thirds. The guide's mechanism section explains why those are the same question: "A GPU memory slice is roughly one eighth of the total GPU memory resources, including both capacity and bandwidth", and "Partitioning of the GPU happens using memory slices."
So what MIG guarantees is quality of service. It carves an existing memory system into isolated shares so that one tenant cannot starve another, which on Thor is roughly 91 GB/s and roughly 182 GB/s of one 273 GB/s bus [inference, arithmetic from "proportional to the instance size"]. MIG makes coexistence deterministic, and it makes it deterministically slower. It rations the bus. It does not widen it.
Two constraints ride along. That documented two-instance maximum is one compute and one graphics, not two equal compute partitions, although the +gfx instance does run CUDA, as the Jetson Linux Developer Guide's worked example shows. And NVIDIA's blog and NVIDIA's shipped tooling disagree about the second partition's size: the blog says 12 SMs plus 8 SMs, the whole 20-SM T5000, while the Developer Guide pastes real nvidia-smi mig -lgip output from a Thor listing SM counts of 6, 12 and 20 with no 8-SM profile in it, and recommends pairing the 12-SM profile with the 6-SM one, 18 of 20. The device output is closer to origin than the announcement is. We are not resolving it, and both are printed.
Then the answer that is not an argument at all. Figure runs the two-tier architecture on its own robots, and the Helix page says how: "each equipped with dual low-power-consumption embedded GPUs. The inference pipeline splits across S2… and S1…, each running on dedicated GPUs." The one company that has published a 7B semantic model running onboard beside a 200 Hz controller did not partition one module. It gave each tier its own.
That retires a sentence of ours, and we would rather retire it here than have it retired for us. The general form — no second large model fits beside the policy on a Thor — was never true as stated, is less true after MIG, and is now contradicted by a published measurement. What survives is the narrower thing our Brain page already says: a 30 to 70 billion parameter task planner and verifier cannot fit beside the policy on the robot, and anything larger than the local planner competes with the policy for Thor's memory bus. A second model fits. The question is what it costs the first one, and the cost is paid in bandwidth.
One Jetson Thor T5000 iGPU — 2,560 Blackwell cores, 20 SMs — partitioned into at most two instances, one compute and one graphics
The full 20-SM profile cannot coexist with any other instance, so partitioning is a choice to run two tenants smaller, not a way to run two tenants whole.
- A MIG instance — an ordinary partition of the compute
- The one memory bus both instances draw from, which MIG rations rather than widens
- The single module both instances live on
What we said nobody had measured
We wrote that no published measurement of two large models running concurrently on a Jetson Thor existed — not a paper, not a vendor benchmark, not a forum thread. We were wrong. One had existed for six months, and the next pass found it on the second search.
OxyGen — Li, Tang, Ding, Wang, Cao and Liu, arXiv 2603.14371, v1 15 March 2026, v2 18 May 2026, a preprint not stated as peer reviewed — implements multi-task inference for π₀.₅, evaluates it on an RTX 4090 and a Jetson AGX Thor, and "further validate the gains on a real humanoid robot with on-board Jetson AGX Thor." Concurrent language generation and action generation, both rates published.
The concession first, because it is the more useful half. What OxyGen measures as its baseline is the configuration this argument predicts: two inference paths on one module, each of which, in the paper's words, "runs independently and sequentially within each frame" — so the 1030 ms below is a sum of two passes, not a contention figure. On the robot, with 3-way RGB observations at 224×224, an action horizon of 10, 10 denoising steps and 30 decoding steps at 5 per frame — "baseline on-device inference (1030 ms) far exceeds the 333 ms action-execution window and blocks the next control cycle." That is 3.1× over budget [inference, arithmetic], measured, on the exact part, on a real humanoid.
Their second baseline is the naive fix, and it is close to the one anybody reaches for after reading the MIG announcement — close, not the same, because MPS shares one undivided GPU rather than partitioning it, and nobody has run this under MIG: "each task runs on an individual process in parallel, sharing one GPU. We implement this for openpi via CUDA Multi-Process Service (MPS). Results show that this naive parallelization provides very limited speedup from the main baseline."
They name the mechanism and then measure it: "Naive parallelization, in contrast, nearly doubles peak memory and even increases energy per request by 3% because of redundant computation and memory bandwidth contention." Resource contention is the second of the two defects the paper sets out to remove, and it charges that defect a 2.6× slowdown in its own ablation. Neither of those is a Thor number: the 2.6× is stated for the RTX 4090, whose baseline falls from 49.9 Hz to 19.1 Hz as decoding steps grow, and the memory and energy table is not labelled by hardware, but its power draw is beyond anything a 40 to 130 W module can produce [inference]. That is our argument, measured by people who were not making it — on a desktop part, with a wider bus than the one this article is about.
Now the result, at full strength, because it runs the other way. With OxyGen's unified KV cache the two tasks do coexist on one module: over 200 tokens per second of language throughput at 27 Hz action frequency on a Jetson AGX Thor. Those two rates are from the LIBERO configuration; the paper's headline speedup of up to 3.7× over isolated execution is its maximum across three configurations and both GPUs, not a Thor figure; and the accompanying quality claim is a simulation result — with the π₀.₅-LIBERO checkpoint the system reproduces openpi's reported success rates within ±0.8 percent, which is the paper's evidence that the speedup costs nothing, not a success rate on the robot.
On the robot, total inference falls from 1030 ms to 393 ms, of which the action-critical prefill and denoise stage takes 198 ms and fits inside the execution window, while the remaining 195 ms of language generation runs afterwards and hides behind the motion.
Read what did the work, because that is the whole transfer question. OxyGen is not two large models sharing a module. It is one Mixture-of-Transformers VLA whose language and action experts share a backbone, and the gain comes from removing the separation: one prefill fanned out to both experts, one KV cache, and language decoding deliberately deferred behind the action. The architecture that works here is the opposite of running a second model alongside the first. We cannot borrow the result: our semantic tier is a different model with different weights doing a different job, and there is no shared prefill to fan out.
The negative that replaces ours is narrower and it points both ways. Searched on 11 September 2026 across NVIDIA's MIG User Guide and Jetson Linux Developer Guide r39.2, developer.nvidia.com/blog, the NVIDIA Developer Forums JSON API, arXiv and four web searches: there is no published measurement of any workload on a MIG-partitioned Jetson Thor, by anyone, with a number attached, and no published measurement of a 30 to 70 billion parameter reasoning model running concurrently with a control policy on one Thor, partitioned or not. On that question nothing supports our conclusion and nothing refutes it.
The spec sheet that breaks first
Our Brain page publishes a local planner of 7 to 8 billion parameters at 40 to 80 tokens per second, as a design target. A batch-of-one autoregressive decode reads every weight once per token, so the ceiling is the bus divided by the bytes per weight. At 273 GB/s that gives 19.5, 39.0 and 78.0 tokens per second for 7B at BF16, FP8 and FP4, and 17.1, 34.1 and 68.2 for 8B [inference, arithmetic] — an upper bound that ignores attention, the KV cache, activations, the CPU's share of the same unified memory and every co-tenant.
And there is a discount to apply. A developer measured about 200 GB/s on a Thor with a kernel written to do nothing but copy memory, on 29 October 2025 — eight months before JetPack 7.2, on software nobody has re-run it against — and an NVIDIA moderator replied without disputing it [single source]. At 200 GB/s the same arithmetic gives 14.3, 28.6 and 57.1 for 7B, and 12.5, 25.0 and 50.0 for 8B.
So our own published band is reachable only at 4-bit weights, only with the whole bus to itself, and the page states a rate without stating the precision it assumes. At BF16 the top of our band is four times what the bus can deliver. The one reassuring part is that 4-bit is the operating point rather than a cheat: NVIDIA's own tutorial needed FP8 plus NVFP4 to get 132 ms down to 49 ms on the same module, and paid for it in cosine similarity.
Anyone deciding where to put a semantic tier gets three questions out of this, all of them about provenance rather than hertz. Was the figure measured or modelled, and on what hardware. If measured, at what precision and in which power mode. And is the second model a second model, or an expert sharing a backbone with the first — because 1030 ms and 393 ms are the same two tasks on the same part.
Our own placement — planner and verifier on a site server, called at task boundaries or on exception — is a design decision taken from bandwidth reasoning. It is ours to defend, not the literature's to support. Two of our sentences have needed correcting in two days: "measured on Thor" on 11 September, and "VLA-Perf measures" on 12 September, where a correction written to remove one error introduced a smaller one in the clause replacing it. That is the part of this piece we would most like to have left out. We will own a Thor, run the policy and the planner on it together, and publish both rates under the ten rules. No date, and no number until there is one.