Compute for machines that act
We started Grey Materia to build the compute infrastructure that robots need to learn. Machines that act in the physical world learn through simulation, testing, and experience. Their infrastructure must support that entire cycle, from constructing a virtual environment to improving a robot already at work.
We believe physical AI will become the largest new driver of compute demand in the coming decade. Today's GPU cloud was shaped by the rise of language models. Robotics adds workloads with different requirements, and teams need a way to run them together.
Some of us spent years inside hyperscalers and GPU clouds building the last generation of AI infrastructure. We are applying that experience to physical AI. Our name joins grey matter, the brain tissue involved in thinking, with materia, Latin for matter.
Experience has to be built
Language models inherited an enormous training corpus: the written record of humanity. Robotics has no comparable archive of physical experience, with camera frames and joint torques attached. Collecting it with real machines is slow and expensive. Failures and near misses are especially scarce because nobody wants to recreate them with a two-hundred-pound robot standing beside a person.
Much of that experience must therefore be generated. Teams construct worlds in software, simulate their physics, and render what a robot's sensors would see. Robots practice millions of times as conditions change. Deployment reveals where simulation differs from reality, and those observations shape the next round of training.
Producing this experience requires several kinds of compute. Rendering and physics have different requirements from foundation model training. Evaluation introduces thousands of short jobs. Deployment imposes the limits of the robot's own computer.
Those differences reach down to the chip. H100 and B200 GPUs lack the ray-tracing cores Isaac Sim requires. RTX hardware can render the world a robot needs to practice in, but a workstation cannot train a foundation model across petabytes of video at scale. Teams end up joining a workstation under a desk to a rented cluster, moving data between them through scripts and shipped hard drives.
The robotics development cycle
1. Build scenes
Before a robot can practice, someone has to build the room. Teams reconstruct environments from photographs, video, and lidar, then assemble digital twins in formats such as OpenUSD. Procedural generation creates variations of a warehouse aisle with different pallets or lighting. This work needs graphics memory, ray tracing, and CPUs for the asset pipelines.
2. Generate data
Sensor simulation renders lighting and materials as a camera would see them, alongside depth, segmentation masks, and lidar returns. The simulation supplies the labels. Varying object positions and camera settings helps a model learn beyond a single scene. World models such as NVIDIA Cosmos add visual variations. Rendering needs RTX-class hardware; generating those variations also calls for tensor compute.
3. Train models
Training contains two distinct workloads. Foundation models such as GR00T, π0, and Gemini Robotics learn from video, language, and action together. Their training resembles language-model training and uses the same tightly connected GPU systems. Data pipelines must decode, shard, and stream petabytes of video fast enough to keep those systems busy.
Reinforcement learning depends on repeated exchanges between the policy and the simulator. Isaac Lab runs thousands of physics environments on one GPU with the learner beside them. Keeping both on the same device reduces delays between taking an action, simulating its result, and learning from it. GPU physics engines such as PhysX and MuJoCo Warp support this approach. For these workloads, memory and proximity matter more than the network used to synchronize a vast training cluster.
In 2021, researchers trained a quadruped to walk on flat ground in under four minutes and on rough terrain in twenty, using one workstation GPU. Simulating thousands of robots in parallel made that speed possible.
4. Evaluate behavior
Evaluation tests whether learned behavior holds up across thousands of scenarios, including dangerous situations a fleet could rarely collect safely. Testing perception brings sensor rendering back into the workload. Teams need software that can schedule many short jobs across graphics and tensor hardware, so they can expand their testing without assembling a new pipeline for each sweep.
5. Validate on hardware
A policy must work within the memory and timing limits of the robot's own computer, such as Jetson Thor. Quantization and distillation help it fit. Hardware-in-the-loop testing connects the real controller to a simulated robot so teams can check behavior within the timing constraints of deployment.
6. Learn from fleets
Deployed robots return telemetry, failures, and human interventions. When a robot drops a cup, its team should be able to reconstruct the scene, generate variations, and practice the task thousands of times before deploying a revised policy. Infrastructure must preserve the connection between the original failure and the training and evaluation that follow.
Build hardware and software together
The hardware mix must reflect the work. HGX systems train models. RTX systems render environments. CPUs process assets and prepare data, while edge hardware provides the target for validation. Our software will assign each job to suitable hardware and manage the handoffs between stages.
Data deserves as much attention as the processors. A humanoid with six 1080p cameras at thirty frames per second produces about a gigabyte of raw pixels each second, before other sensors are counted. Even compressed a hundredfold, an eight-hour shift can produce hundreds of gigabytes.
For comparison, Llama 3's roughly fifteen trillion training tokens amount to about sixty terabytes of text at four bytes per token. A hundred robots can produce comparable sensor data in a day or two. A fleet makes storage and data movement central engineering problems. Compute must stay close to that data, with enough bandwidth to keep the machines busy.
We are building software that keeps simulators and learners together, preserves simulator state so work can resume, and expands evaluation as demand grows. Its data systems must record how a real observation becomes a reconstructed scene, synthetic training data, and a model checkpoint. Teams should be able to trace an improvement back to the experience that produced it.
The last infrastructure buildout taught us that operating machines matters as much as owning them. Reliable networking, storage, and scheduling made GPU clouds useful. Physical AI requires the same operational discipline across a more varied set of workloads.
Why now
Foundation models are learning skills that transfer across tasks and robot bodies. GPU physics lets thousands of environments run on one card. Rendering and world models give teams more ways to generate useful visual experience. The gap between simulation and reality remains, but teams have better tools for measuring and reducing it.
Hardware now spans the development cycle. Blackwell appears in HGX systems for model training, RTX PRO systems for visual computing, and Jetson Thor for the robot. Competition among GPU clouds has also made capacity easier to rent.
Together, these developments give robotics teams more ways to train and test their machines. They also increase the work of coordinating those systems. We see an opportunity to make the full cycle easier to run and cheaper to repeat.
Demand grows with deployment
Our estimate puts annual robotics and physical AI compute spending at roughly $5 billion. We estimate that $3 billion to $3.5 billion is addressable by an outside provider after excluding aerospace, defense, and programs that will build their own infrastructure.
We expect spending to grow as fleets expand and keep learning. Each deployment creates demand for further simulation and evaluation. Against IDC's projected $1.21 trillion AI infrastructure market in 2030, a two to three percent share for physical AI would imply roughly $25 billion to $35 billion a year.
These are estimates: the current figures derive from robotics research and development budgets, while the 2030 range describes a possible share of the wider market. We will publish the methodology and assumptions behind both. Our immediate opportunity is the money teams already spend on systems that are difficult to scale and expensive to join together.
The gap in today's GPU clouds
Large clouds are beginning to address the workload. NVIDIA's physical AI reference architecture, and the plans announced by Azure and Nebius to integrate it, show that the need is becoming visible. We welcome that investment. Customers will judge how well those systems support their complete development cycle.
Hyperscalers operate vast fleets of similar machines, with language models accounting for much of their demand. Scheduling graphics hardware alongside tensor systems, while preserving simulator state and managing heavy sensor data, adds complexity. GPU clouds also have strong incentives to fill the H100 and B200 capacity they have financed. Some will adapt well. Grey Materia is being designed around robotics workloads from the beginning.
Robotics companies can build their own infrastructure, and many have. Maintaining it takes engineering time that could go toward improving the robot. We will manage the handoffs between simulation, training, evaluation, and deployment, where teams now do so much of the work themselves.
What customers should expect
We will measure progress in units roboticists can use: simulated hours, rendered frames, and scenarios evaluated. Those measures must come with evidence of how well simulation matches reality. Our work should reduce the time and cost of turning a failure in the field into a validated improvement.
Evaluation must be part of ordinary development. Machines that work beside people need testing against rare failures before those failures happen in the field. Running thousands of scenarios requires rendering capacity and software to coordinate the tests. We will build that capability into the infrastructure.
Customers should be free to change their simulator, framework, or model family without rebuilding the systems around it. NVIDIA's ecosystem provides a foundation, including Isaac Sim, Isaac Lab, and OpenUSD. MuJoCo, Genesis, Gazebo, ROS 2, and teams' own pipelines also belong in the system. Our infrastructure must support the tools researchers choose.
What we are here to build
Grey Materia will serve the companies building robots. We will never compete with them. Our job is to run the infrastructure that supports their work, from the first simulated environment through learning from a deployed fleet.
We want robotics teams to spend more of their time improving what machines can do. That means taking responsibility for the hardware, software, and data movement their development depends on, and being judged by how reliably we run it.
If you helped build the last generation of compute infrastructure, we want to work with you on this one. If you are building robots, show us where your development cycle slows down. We want to help you move from a failure in the field to a validated improvement.