GR00T on Jetson Thor or Orin: the run guide

Yes, GR00T runs on Jetson hardware, and the path is official. NVIDIA's Isaac GR00T N1.7 repo ships installers for Jetson AGX Thor and Jetson Orin, tested on JetPack 7.2. The stated floor for inference is one GPU with 16 GB of memory or more. On Thor, published control speeds run from about 10.7 to about 28 Hz by setup, and an NVIDIA recipe reaches 25 Hz. On Orin the published ceiling is 4.6 Hz, and the fastest Thor options do not exist there. This page walks the run steps on both parts, and ties every speed number to the table it came from.

Every fact below comes from NVIDIA's own material, read on October 27, 2026. The sources: the GR00T repo, its deploy guide, the N1.7 model card, the Jetson AI Lab recipe for Thor, and the Jetson product pages. Where NVIDIA printed no number, this page prints a dash, not a guess. The version choice, N1 against N1.5 against N1.7, has its own page: the version chooser. This page owns the run itself.

What GR00T asks of the hardware

The repo states its floors in two lines. Inference wants one GPU with 16 GB of memory or more. The named parts include an RTX 4090, an L40, an H100, the Jetson AGX Thor, the Jetson Orin, and the DGX Spark. Fine-tuning wants 40 GB or more per GPU. The preferred parts are H100 and L40 nodes.

Those two numbers settle half of the Thor-versus-Orin question before you type a command. The Thor developer kit carries 128 GB of shared memory, per the NVIDIA Thor page. It clears the inference floor eight times over. It also holds fine-tune runs that smaller parts cannot fit. The Orin family, per the NVIDIA Orin page, tops out at 64 GB on the AGX part. The smaller Orin NX and Orin Nano parts carry 16, 8, or 4 GB. A 16 GB Orin NX sits on the floor with nothing spare. An 8 GB Orin Nano never reaches the floor.

One spec drives speed more than memory size: memory bandwidth. Thor moves 273 GB per second. AGX Orin moves 204.8, and the smaller Orin parts sit at 102.4 or less. The bandwidth gap alone does not explain the speed gap. The GPU generation does. Thor carries a Blackwell GPU with native NVFP4 support. That four-bit format is the base of the fastest published Thor recipe. Orin predates it. The rule is simple. Memory decides whether GR00T fits. The GPU generation decides how fast it runs. Only Thor has both in the current published path.

The two Jetson families, side by side

These are the published module facts. All values come from the two NVIDIA product pages read on October 27, 2026.

Use the table as a placement tool. GR00T inference needs the 16 GB row or better. That means any Thor part, AGX Orin in either memory size, or the 16 GB Orin NX at the bare minimum. Everything below the 16 GB NX is outside the published path for N1.7.

For budget context: NVIDIA's own developer price table, read on October 27, 2026, lists the AGX Thor developer kit at 5,499 and the AGX Orin developer kit at 3,499. The Orin Nano Super developer kit lists at 399. Whether buying any of these makes sense against other options is a separate question. That math lives in the local versus hosted break-even guide and the Jetson versus cloud guide.

The steps on Jetson Thor

NVIDIA supports two install routes on Thor: Docker, which the deploy guide calls recommended, and bare metal. Both start from the same base. JetPack 7.2 brings Jetson Linux 39.2, CUDA 13.2, and Python 3.12. Older JetPack releases no longer work with this repo. Check what the board runs before anything else.

The order that works, with the reasons attached.

First, set the board to full power and lock the clocks. Every published Thor number assumes this state.

sudo nvpmodel -m 0
sudo jetson_clocks
sudo jetson_clocks --show

Second, install git LFS, then clone the repo with its submodules. The demo datasets and the Thor video wheel travel as LFS objects. A plain clone fetches pointer files instead. That failure only shows up later, as a Docker build that cannot read a wheel.

sudo apt-get update && sudo apt-get install -y git-lfs
git lfs install
git clone --recurse-submodules https://github.com/NVIDIA/Isaac-GR00T

Third, run the Thor installer and turn on its environment.

bash scripts/deployment/thor/install_deps.sh
source .venv/bin/activate
source scripts/activate_thor.sh

The installer checks the JetPack version. It installs FFmpeg and the CUDA 13.2 dev packages when needed. It builds the flash-attention wheel on the board when no cached wheel exists. That last step takes time. That is normal.

Fourth, the trap the repo prints in bold, and which still catches people. On Thor, Orin, and Spark, run everything with plain python and torchrun. Never use uv run python. The uv command re-syncs against the x86_64 project file and wrecks the platform setup. Every command below uses plain python.

Fifth, get Hugging Face access before the first run. Every GR00T checkpoint loads a gated backbone, nvidia/Cosmos-Reason2-2B. Request access on the model page, then log in with your token. Without access, model loading fails with a GatedRepoError or a 401 Client Error. Approval is automatic, so this costs minutes. It must happen first.

Sixth, run the zero-shot check. This is the smallest complete run: the base model, an included DROID demo set, plain PyTorch, no TensorRT.

python scripts/deployment/standalone_inference_script.py \
    --model-path nvidia/GR00T-N1.7-3B \
    --dataset-path demo_data/droid_sample \
    --embodiment-tag OXE_DROID_RELATIVE_EEF_RELATIVE_JOINT \
    --traj-ids 1 2 \
    --inference-mode pytorch \
    --execution-horizon 8

The base model downloads about 6 GB on first run. If this step passes, the software stack is sound. Any later failure is then model-specific, not a broken install.

Seventh, for real speed, build TensorRT engines. One command runs the whole pipeline: export to ONNX, compile engines, check accuracy, and benchmark.

python scripts/deployment/build_trt_pipeline.py \
    --model-path checkpoints/GR00T-N1.7-LIBERO/libero_10 \
    --dataset-path demo_data/libero_demo \
    --embodiment-tag LIBERO_PANDA \
    --flat-e2e

Three engine facts save grief later. Engines are bound to one GPU design, so a Thor engine set does not run on Orin. The batch size is baked in as a fixed size, so a batch change means a new export and a new build. The full-pipeline build wants about 16 GB of GPU memory. Thor has that. Smaller parts do not.

Eighth, for deployment, the repo offers a server-client shape. The policy runs as a server. A light client sends camera frames and state, and gets actions back, over ZMQ on port 5555 by default. One caveat: the bundled policy server takes the PyTorch model only. It takes no engine path. To serve accelerated engines, wrap the standalone script's runtime in your own process.

The Thor speed recipe: quantization

The steps above end at the baseline TensorRT path. The Jetson AI Lab recipe goes further. It holds the fastest published Thor number: 39.9 ms per complete policy call, 25.1 Hz, a 3.1x speedup over PyTorch, with task success holding.

The recipe mixes two mechanisms. The first is per-part quantization. Its vision tower runs FP8. The language model and the action head run NVFP4. The touchy layers inside them, two projection layers and the attention, stay at FP8. The second is an optimized run profile. Cross-attention keys and values are computed once, then reused across all four denoise steps. The fixed timestep math is computed at export time. Projections that share an input are fused. The whole action head is captured as a CUDA graph. Neither mechanism alone reaches 39.9 ms.

The recipe needs what the tutorial asks for. An NVMe SSD with about 60 GB free. The checkpoint, about 6.5 GB. A calibration set, about 614 MB. And ModelOpt at the pinned version. The accuracy check after the build should print a cosine similarity above 0.999 against the PyTorch reference. In the tutorial's own closed-loop check, the quantized engine's error matched the PyTorch baseline within noise.

One dated footnote from the tutorial itself. JetPack 7.2 runs roughly 13 percent faster than 7.1 across the plain setups. So speedups quoted against a 7.1 baseline look larger than they are on current software.

The steps on Jetson Orin

Orin uses the same repo, the same JetPack 7.2 rule, and the same installer pattern.

bash scripts/deployment/orin/install_deps.sh
source .venv/bin/activate
source scripts/activate_orin.sh

The same bold warning applies: plain python, never uv run python. Orin and Thor even share one flash-attention wheel with kernels for both designs. JetPack 6.x on Orin is out of support for this repo. A board still on JetPack 6 upgrades first, or stops here. One tip from the deploy guide: if the internal storage is tight, point the Hugging Face cache at an NVMe drive before you download checkpoints.

The hard gap is the acceleration path. The model card's benchmark note says it plainly. Orin runs the DiT-only TensorRT mode, because its TensorRT build does not support the backbone engine. The full-pipeline mode that makes Thor fast is not there. That published Orin row, 4.6 Hz with DiT-only TensorRT, is the honest ceiling for GR00T N1.7 on Orin today. The quantization options above it, FP8 and mixed NVFP4, are Blackwell features. Community reports on Orin NX hardware describe the FP8 and NVFP4 engine builds failing outright. That matches the silicon story: those formats do not exist on that chip.

What is Orin good for in a GR00T program? The 64 GB AGX part holds the model and its tools with room to spare. It is a fine place for data work, teleoperation, and evaluation. The skill loop at 4.6 Hz covers some manipulation tasks and not others. A robot that needs faster output on Orin either shrinks the model or moves the policy off the part. The placement rules for that call are worked in the Jetson versus cloud guide.

The speed numbers and their conditions

Every published number, one table, conditions attached. Read the conditions column before you quote any row. The two Thor rows differ by nearly three times, and both are correct.

Why the spread? Three causes, all visible in the sources. The readme's 28 Hz and the model card's 10.7 Hz measure different things under different setups, and both printed their own. The deploy guide's flat runs use two cameras where the model card used one. More vision input costs time. And every Jetson row assumes MAXN power mode with locked clocks. A board left in its default state runs slower than every number here. The version chooser page carries the same lesson: comparing across setups is how readers get burned.

A third-party project has also published Thor numbers for other model families, and they set useful context. One pi0.5 class policy answers a chunk in 62.2 ms with tuned kernels. A larger MolmoAct2 class policy takes 113.4 ms (vla-edge benchmarks). Those are not GR00T numbers and not NVIDIA numbers. They show what a Thor kit does for this model class when someone outside NVIDIA tunes for it.

Where it hurts

The repo's issue tracker shows a clear pattern of Jetson pain. It is gathered here as community reports, not as cited fact. Most of it matches the traps the official docs warn about.

Install failures cluster on the aarch64 wheel set. TensorRT wheel mismatches. Source builds of video backends. Dependency versions that exist for x86_64 but not for the board. The installers fixed most of this, but only on JetPack 7.2. People on older JetPack releases hit every wall.

The subtle one is accuracy drift. One open report describes the same fine-tuned checkpoint scoring differently on an AGX Orin than on a workstation GPU. Plain PyTorch. No TensorRT involved. The cause is not settled in the thread. The lesson stands. When you move a checkpoint onto a Jetson, rerun your own accuracy check on the board before you trust it.

The Docker boundary leaks in specific ways. One closed report describes an SO-101 arm's port not showing inside the Thor container. That is a device permission problem, not a GR00T one. If your robot talks over a serial port, pass the device into the container, or run on bare metal.

What this page cannot promise

This page has run none of these steps itself. It carries no benchmark of its own. Every speed number above is NVIDIA's or a named third party's, printed under their conditions. Your cameras, your robot, and your denoise settings will move your results. The flat timings in the deploy guide do not cover closed-loop task success. Nobody has checked your robot. Treat the tables as floors and shapes, not promises. Run the one-command benchmark on your own board before you design around a number.

The license and hosting limits

Running GR00T on your own Jetson is allowed. What that use may become is bounded by the license files. The two files disagree in a way worth knowing before it costs you. The GitHub code ships under Apache 2.0. The weights on Hugging Face ship under the NVIDIA license. Its use-limitation section, read on October 27, 2026, permits research and evaluation use only. Commercial rights stay with NVIDIA and its affiliates. The readme, meanwhile, calls N1.7 fully commercially licensable under Apache 2.0, and its own license section lists the split: code Apache 2.0, weights under the NVIDIA Open Model License. What ships with your download is the safer reading. The claim-by-claim analysis is the GR00T license guide.

Hosting has the same shape. No major host serves GR00T weights behind an API. NVIDIA's own hosted portal carries a GR00T-branded data generator, not a policy you can call. If your robot needs a served action route, the Apache-licensed families are the ones to look at; the GR00T license guide names them. The costs of that route are worked in the GR00T API pricing page.

If the Jetson is not the answer

Three honest exits exist, and each has its own page.

Duty first. A robot that runs a few hours a week does not justify any Jetson purchase. The break-even math in the local versus hosted guide draws the line in robot hours per month. For weekend duty the line is low.

Placement second. The physics of where a policy runs does not depend on whose model you use. On the robot, at the site, or in a data center, each layer has its own answer. The Jetson versus cloud guide works that trade layer by layer, with the measured costs on both sides.

Serving third. This platform keeps written records for action-route models in the same class as the ones benchmarked above, including pi05, with per-call metering against a prepaid wallet. The models index shows what the platform offers. The pricing guide carries the listed rates. If that route fits your robot better than a kit on the arm, sign up, create a key, and point your client at it.

Common questions

Can GR00T N1.7 run on a Jetson? Yes. The repo ships Thor and Orin installers, tested on JetPack 7.2, and names both parts in its 16 GB inference floor. Thor publishes control speeds from 10.7 to about 28 Hz. Orin publishes 4.6 Hz.

Which Jetson should I buy for GR00T? The AGX Thor developer kit if the budget allows. Its 128 GB clears every floor, including fine-tuning, and it is the only family with the full published speed path. The AGX Orin 64 GB runs inference with room to spare, at 4.6 Hz. The 16 GB Orin NX sits on the floor. Skip anything smaller for this model.

Does GR00T run on Orin Nano? Not in the published path. The inference floor is 16 GB. The largest Orin Nano carries 8 GB. That floor is the GR00T repo's own hardware rule, not a benchmark.

Why do the Thor speed numbers disagree? Setup. The readme's 28 Hz, the model card's 10.7 Hz, and the AI Lab recipe's 25.1 Hz were printed under different conditions. Camera count, pipeline scope, and clock state all differ. Each source states its own conditions. This page's table carries them side by side.

Is TensorRT required on Jetson? No, but it is the difference between crawl and control. Plain PyTorch on Thor answers a policy call in about 107 ms in the deploy guide's flat table. Full-pipeline TensorRT brings that to 76.8 ms. The quantized recipe brings it to 35.6 ms. On Orin, only the DiT-only mode exists, at 149.0 ms flat.

How much storage does the Thor setup need? Plan about 60 GB free on NVMe for the full recipe. Roughly 26 GB of container, about 13 GB per engine build, and about 7 GB of assets, plus the 6.5 GB checkpoint and the calibration set. Those numbers are the Jetson AI Lab recipe's own budget.

Can I ship a product that runs GR00T on Jetson? The license file shipped with the weights permits research and evaluation use, and keeps commercial rights with NVIDIA. The readme claims broader terms. That conflict is real and unresolved in the repo's own discussions. Read the file in your download and get advice before the product depends on it. The license guide walks every claim.

Last verified: 2026-10-27