NVIDIA frames its robotics tools as “three computers”. With so many product names, it is easy to lose track of what runs where. This article uses NVIDIA’s official blog, product pages and the GR00T repository to map each computer to its role and software, then suggests an adoption order for a small team.
What each of the three computers does
NVIDIA’s blog splits robot development into training, simulation and runtime, with a computer for each.
| Stage | Computer | Main software and models | Job |
|---|---|---|---|
| Training | DGX | Cosmos, post-training on GR00T | Pre-train and fine-tune robot foundation models |
| Simulation and synthetic data | RTX PRO servers | Omniverse, Isaac Sim, Isaac Lab, Cosmos | Test policies, run RL and imitation learning, generate synthetic data |
| Runtime on the robot | Jetson AGX Thor | Control policies, vision and language models | Real-time inference and control onboard |
The point of the split is that each stage has completely different needs. Training wants massive parallel compute and memory; simulation wants physics and rendering; onboard runtime wants real-time behavior in a small, low-power package. Trying to do everything on one machine makes every stage inefficient.
Simulation: Isaac Sim and Isaac Lab
The blog describes testing robot policies in Isaac Sim, built on Omniverse libraries, and running reinforcement and imitation learning in Isaac Lab. The Isaac Lab documentation says it builds on Isaac Sim’s photorealistic scenes and PhysX physics, supports domain randomization, and is released under BSD-3-Clause, with some parts under Apache-2.0. Moving simulated policies onto real robots is covered in Closing the Sim-to-Real gap.
World models: Cosmos 3 and earlier generations
The NVIDIA Cosmos page introduces its latest model, Cosmos 3, as “The Open Physical AI Foundation Model” and lists four uses:
- Visual AI reasoning (a vision-language model)
- A backbone for robot policy models
- A controllable world simulator
- Scaling synthetic video data
The page’s FAQ explains that the previous generations, Cosmos 2.5 and 2, kept perception and generation as separate models, and it also describes tools such as Cosmos Transfer, which turns Omniverse simulation video into photorealistic synthetic data, and Cosmos Curator, which filters, annotates and deduplicates sensor data. It states that Cosmos world foundation models are available under the Linux Foundation’s OpenMDW 1.1 license. How world models predict the next scene is explained in How world models work.
The robot foundation model: Isaac GR00T
The Isaac GR00T page presents GR00T as an open reference platform for general-purpose humanoids: open data and pipelines, an open robot foundation model, simulation frameworks built on Omniverse and Cosmos, middleware, and Jetson Thor for real-time inference and control.
According to the GR00T repository README, the current generally available version is GR00T N1.7. The base checkpoint nvidia/GR00T-N1.7-3B has 3B parameters, and the release adds a Cosmos-Reason2-2B backbone and 20,000 hours of human video to pre-training. The stated requirements:
- Inference — one GPU with 16 GB+ VRAM (examples: RTX 4090, L40, H100, Jetson AGX Thor or Orin, DGX Spark)
- Fine-tuning — one or more GPUs with 40 GB+ VRAM recommended (H100 or L40 preferred; A6000-class works but may be slower)
- License — Apache 2.0 for code, NVIDIA Open Model License for weights; the README also contains a line about commercial licensing, so check the weight terms directly
The on-robot computer: Jetson AGX Thor
Per the Jetson Thor specifications, the Jetson AGX Thor developer kit (T5000) has a 2560-core Blackwell GPU, a 14-core Arm CPU, 128 GB of LPDDR5X, 273 GB/s of memory bandwidth and a 40–130 W power range; the smaller T4000 module has 64 GB and a 40–70 W range. How to estimate memory needs and speed ceilings before loading a model is covered step by step in Sizing VRAM and TOPS for on-device models.
How data circulates between the three computers
The three computers are not one-off stages but a loop through which data keeps flowing. The Jetson on the robot records camera footage and joint logs during work; that data is filtered and annotated into training datasets — NVIDIA positions Cosmos Curator for this step. The training computer fine-tunes models on the curated data plus synthetic data, the simulation computer tests the new policy first, and only policies that pass are deployed back to the robots.
Three decisions are worth making up front when designing this loop. First, what data the robot uploads and how often: uploading everything is expensive to store and transfer, so teams usually prioritize failures and rare situations. Second, the threshold a new policy must clear in simulation before deployment. Third, whether a policy version running on a robot can be traced back to the exact training data and settings that produced it.
An adoption order for a small team
- Get the on-robot computer first. Running real sensor inputs and existing control on the actual robot comes before anything else.
- Test inference with an open model. Run a public checkpoint such as GR00T on a 16 GB+ GPU and check that it fits your robot’s action space.
- Build the simulation. Recreate the robot and workspace in Isaac Sim and Isaac Lab; cloud GPUs are fine to start.
- Fine-tune on your own data. Mix teleoperated demonstrations and synthetic data and fine-tune on 40 GB+ GPUs.
- Grow training infrastructure only when needed. Consider dedicated training hardware when pre-training-scale work appears.
The three-computer framing is most useful as a design principle — keep training, simulation and on-robot inference separate — rather than as a product bundle. Any stage can be replaced with tools from other vendors; what matters is that data and model formats flow cleanly between the stages.
Questions to ask before committing to the stack
Before standardizing on any vendor’s stack, it is worth answering a few practical questions. Can the simulation assets you build be exported in an open format such as OpenUSD if you change tools later? Do the model weights’ terms allow the deployment you plan, including redistribution inside a product? How will you version datasets and checkpoints so that a policy running on a robot can be traced back to the exact data and settings that produced it? Teams that settle these questions early avoid painful migrations once fleets and datasets grow.