Building the next compute layer for physical AI

Physical AI will be the largest driver of compute demand of the next decade, and the infrastructure being built today is the wrong shape for it. Grey Materia exists to build the right one, from the ground up: the compute layer that physical AI is built on.

We are not a robot company; we will never compete with the teams we serve. We are not a chip company; the chips exist. We are not a generic GPU cloud with a robotics landing page, and we are not a data-labeling shop. We are the infrastructure in between.

For a decade, the infrastructure of artificial intelligence has been shaped by one workload: models that read and write text. Walk into a frontier AI data center in 2026 and you see one object repeated thousands of times: an eight-GPU HGX server, or a GB200 NVL72 rack with seventy-two Blackwell GPUs and thirty-six Grace CPUs on a single NVLink domain. InfiniBand or Spectrum-X Ethernet ties the racks together in topologies built for one job: averaging gradients across every GPU as fast as physics allows. The storage is fast but, by the standard of what comes next, small. The scheduler knows two shapes of work: a months-long training job that holds the whole cluster, and stateless inference that answers a request and forgets it. The economics are dollars per GPU-hour going in and dollars per million tokens coming out.

None of this is a mistake. It is a precise answer to a precise question: how do you teach a transformer the internet, then let a billion people talk to it? Hyperscalers and neoclouds answered that question well, and answering it produced one of the largest private buildouts in history. Some of us spent years inside them helping.

Physical AI asks a different question. The AI arriving now doesn't just read and write; it sees, moves, grips, balances, and acts. It has to learn to do those things, and the way it learns is different enough that the new compute architecture behind it has to be built differently too.

A language model learns from a corpus that existed before anyone thought to train on it: the written record of humanity, scraped and filtered. There is no equivalent for robots. There is no internet of actions — no archive of a billion hours of lifting boxes, threading cables, and stepping onto wet tile, recorded from the inside with joint torques and camera frames attached. Real robots collecting real data are slow and expensive, and the data they collect is thinnest exactly where it matters most: the failures, the near misses, the rare cases nobody wants to reproduce with a two-hundred-pound machine standing next to a person.

So the data corpus has to be synthetically generated. You build a world in software. You render it the way a camera would see it and simulate it the way physics would treat it. You drop a robot in and let it try — millions of times, in thousands of variations, faster than real time. You evaluate what it learned against thousands more scenarios you also had to build. You deploy, collect what the real world disagrees with, rebuild the world, and go again.

That is the central fact about physical AI infrastructure: simulation is the internet of robotics. It is where the training data comes from. And unlike the internet, it has to be generated. Generation is compute — a great deal of compute, but not the compute we have been building.

1. Physical AI is characterized as a loop of interrelated workloads. Rendering, physics, reinforcement learning, multimodal model training, large-scale evaluation, and edge inference each ask something different of silicon. A language cluster runs one kind of math extremely well.
2. It is closed-loop and stateful. In reinforcement learning, the simulator and the learner talk to each other every step: the policy acts, the physics responds, the policy updates. Latency between the two matters more than aggregate bandwidth. An interconnect built for all-reduce across ten thousand GPUs is solving a problem this workload mostly doesn't have, while the problem it does have — keeping environments and learner on the same device, sharing the same memory — goes unaddressed.
3. The data is different in kind and vastly larger in volume. Text is light. Sensor data is not. A humanoid with six 1080p cameras at thirty frames per second produces about a gigabyte of raw pixels every second, before you count lidar, depth, and joint state. Even compressed a hundredfold, that is a few hundred gigabytes per eight-hour shift, per robot. A fleet of a hundred robots produces something the size of a frontier LLM's entire text corpus every day or two. At that scale the constraint is not FLOPs. It is ingest, storage, and the bandwidth between where the data lives and where the GPUs are.
4. The unit economics are different. Dollars per token is the wrong denominator. What matters is the cost of a simulated hour, a rendered frame, an evaluated scenario — and the number everyone actually cares about, which is how far the simulation is from reality. Today's AI infrastructure was never designed to measure any of these, so it cannot be optimized for them.
5. The loop never closes. A language model's training run ends. A robot's doesn't. Every deployment produces disagreements between the world as simulated and the world as it is, and those disagreements are the most valuable data in the system. The new infrastructure we envisage has to be built as a flywheel, not as a batch job.

Put physical AI on infrastructure built for tokens and the mismatch is not subtle. An H100 or a B200 has no RT cores — the fixed-function hardware that traces rays. NVIDIA's own requirements for Isaac Sim, the most widely used robotics simulator, state plainly that GPUs without RT cores are not supported.^[1] The most expensive processors in the world cannot generate the data the robot needs. Turn it around, and the RTX PRO workstation that renders beautifully cannot train a world model over petabytes of video at any reasonable scale. CPU-bound physics starves the GPUs it feeds. Renting B200s for a rendering job means paying tensor prices for a visual-computing workload. So teams end up where most of them are today: a workstation under a desk, a rented cluster in a cloud built for language models rather than robots, and a data pipeline made of scripts, spreadsheets, and shipped hard drives.

We think about robotics development as a loop of six stages. Each one wants different silicon, and that is the whole point.

Scene construction. Before a robot can practice, someone has to build the environment. Scenes come from the real world — photogrammetry, neural radiance fields, 3D Gaussian splats reconstructed from phone video and lidar scans — and get assembled into digital twins in OpenUSD, the open scene description that NVIDIA's Omniverse is built on. Procedural generation fills in the rest: a thousand variations of one warehouse aisle, each with different pallets, lighting, and clutter. This is a visual-computing workload. It wants RT cores for ray tracing, large frame buffers for large scenes, and a fair amount of CPU for asset pipelines. It is RTX PRO 6000 Blackwell territory, with ninety-six gigabytes of memory on the card, and no amount of HGX substitutes for it.

Data generation. With scenes built, you render. Path-traced sensor simulation produces images that look the way a camera would actually see them — correct lighting, materials, motion blur, lens distortion — and produces depth, segmentation masks, and lidar returns alongside them, perfectly labeled, for free. Domain randomization varies lighting, textures, object poses, and camera intrinsics so the policy learns what is invariant instead of memorizing what is incidental. Isaac Sim's Replicator does this at scale. On top of it sits a newer layer: world foundation models like NVIDIA Cosmos, which take a rendered simulation and generate photoreal variations of it — weather, time of day, wear and tear, crowds — at video scale. The two halves want different machines. Rendering demands ray-tracing throughput: many RTX-class GPUs running in parallel. Hyper-realistic generative augmentation wants tensor cores and memory bandwidth: HGX. One stage, two architectures.

Training. Two different things live here, and people conflate them.

The first is robotic foundation model training. Vision-language-action models — NVIDIA's GR00T, Physical Intelligence's π0, Google DeepMind's Gemini Robotics, and the models robot companies are training on top of them — learn from video, language, and action data together. This looks most like LLM training: HGX B200 or GB300 NVL72, NVLink domains, InfiniBand fabrics. The difference is the data. Frontier labs building LLMs never had to decode, shard, and stream petabytes of video fast enough to keep the GPUs busy.

The second is policy training through reinforcement learning, and it looks nothing like LLM training. Isaac Lab runs thousands of physics environments on a single GPU with the learner beside them. Rudin and colleagues showed in 2021 that a quadruped could learn to walk on flat ground in under four minutes and on rough terrain in twenty, on one workstation GPU, by simulating thousands of robots in parallel — a speedup of several orders of magnitude over what came before.^[2] GPU-resident physics is what made this possible, and the engines are converging on it: PhysX, MuJoCo Warp, and the open-source Newton engine NVIDIA is building with Google DeepMind and Disney Research. This workload wants FP32 throughput, memory, and co-location. It does not want, and cannot use, a ten-thousand-GPU all-reduce fabric, which is classically found in current AI infrastructure deployments.

Policy evaluation. A policy that trains is not a policy that works. Before it touches hardware it has to be run through thousands of closed-loop scenarios — including the long-tail ones no fleet could ever capture safely — with perception in the loop, which means sensor-accurate rendering again. This stage is embarrassingly parallel and orchestration-bound: the hard part is scheduling ten thousand short jobs across a mix of RT and tensor silicon, not running any one of them. It is also where safety lives. You cannot deploy what you have not evaluated, and you cannot evaluate at scale without infrastructure built to do it.

On-target validation. Eventually the policy has to run on the robot's own computer — Jetson Thor-class silicon — inside real-time budgets. That means quantization and distillation, hardware-in-the-loop rigs where the real controller drives the simulated robot, and latency measured in milliseconds rather than throughput measured in tokens.

Fleet feedback. Deployed robots stream back telemetry, failures, and human interventions. That data has to be ingested, curated, and turned back into simulation: reconstructing the exact scene where the robot dropped the cup so it can practice there ten thousand times before breakfast. That is where the loop closes, and where it starts again.

Lay the six stages side by side and no single SKU serves them. HGX for the models. RTX for the worlds. CPU for the physics and the pipelines. Edge silicon for the target. And software that knows which is which. This is not a Blackwell-specific accident: the split between tensor-first data center parts and RT-equipped visual-computing parts has held for three generations — A100 and A40, H100 and L40S, B200 and RTX PRO 6000 — and nothing on the roadmap collapses it. So the question for physical AI is not which GPU to buy. It is how to assemble all of them in the proportions the loop demands and run them as one system.

Silicon without the proper software stack is a parts bin.

The GPU cloud did not become real the day the first eight-GPU server shipped. It became real when NCCL, InfiniBand operations, parallel file systems, and cluster schedulers caught up with the chips. The neoclouds that won the last three years did not win by owning H100s. They won by running them well. The same will be true here, and the software has more to do.

It needs a scheduler that understands stages: scene construction to RT parts, foundation model training to NVLink domains, reinforcement learning to co-located GPUs, evaluation sweeps to whatever is idle. It needs a data plane built for sensor and simulation data — petabyte ingest, video-native storage, and lineage that runs from a real observation to the scene reconstructed from it, to the synthetic frames rendered from that, to the checkpoint trained on those. It needs simulation-native primitives: environments and learners on one device, simulator state that can be checkpointed and resumed, elastic scale-out for evaluation. And it needs to report cost and utilization in the units roboticists think in — simulated hours, rendered frames, scenarios evaluated — not GPU-hours alone.

It also has to speak the languages the field already speaks. NVIDIA's stack — Isaac Sim, Isaac Lab, Omniverse and OpenUSD, Cosmos, GR00T, Jetson — is where adoption is, and we build on it rather than reinvent it. But the loop is bigger than any one vendor. MuJoCo, Genesis, Gazebo, game-engine simulators, ROS 2, and the custom pipelines every serious team eventually writes all belong inside it. We design our infrastructure so that the loop is the abstraction and the tools are interchangeable. Nothing we build locks a team into a particular simulator, framework, or model family — including the ones we run today.

Physical AI has been ten years away for thirty years. Five things changed in the last two years.

Robot foundation models crossed from demos to viability. GR00T, π0, Gemini Robotics, Helix, and their successors learn general skills from video and simulation and transfer them across tasks and bodies — the first time robotics has had something that behaves like a foundation model rather than a controller.

Simulation got good enough. GPU-resident physics runs thousands of environments per card. Path tracing produces images a perception model cannot distinguish from a camera's. World foundation models fill the gap between what a simulator can render and what the world actually looks like. The sim-to-real gap did not close, but it became an engineering problem instead of a research problem.

One silicon generation now spans the whole loop. Blackwell ships in HGX for the models, in RTX PRO for the worlds, and in Jetson Thor for the robot. The parts exist. Nobody has assembled them in the right proportions.

Capital arrived. Humanoids are the most visible segment, and the money there tells the story: humanoid startups raised roughly six billion dollars in 2025 and had passed five billion again by June of this year,^[3] and every bank that revised its humanoid forecast between 2024 and 2026 revised it upward: Goldman Sachs raised its 2035 estimate from $6 billion to $38 billion in 2024 and to $138 billion this month,^[4] and Morgan Stanley doubled its 2026 China shipment forecast twice in the first half of this year.^[5] The machines are being built — vehicles, arms, drones, humanoids — and every one of them needs a loop.

And the generic GPU-hour commoditized. The neocloud price war put H100 and B200 capacity within reach of anyone with a credit card, which means the next infrastructure company will not be differentiated by owning GPUs. It will be differentiated by the workload it is built for.

This has happened before. In 2012 a neural network trained on two consumer graphics cards won ImageNet, and within five years the data center had been rebuilt around GPUs. In the late 1990s, generic web hosting could not keep up with traffic spikes and rich media, and a content-delivery layer grew up between the hosts and the users that still carries much of the internet today. Film studios built render farms because no general-purpose cluster was shaped like a movie. In each case a new workload arrived that the incumbent infrastructure served badly, and a purpose-built layer captured the value of serving it well.

Physical AI compute today is where language-model compute was in 2019: a few dozen serious teams, spend measured in single-digit billions, and no infrastructure built specifically for it. It looks small. In hindsight, 2019 did too.

Our view of this market starts from a structural claim: physical AI consumes more compute per dollar of end market than language AI does, and it will keep doing so, because the loop never closes.

Although language models are indeed retrained, in between generations, the world they model holds still. Text written last year is still text. A robot's world does not hold still. Every new facility, every new object, every new task, and every failure in the field changes what the model has to know, and the fix is not a prompt. It is another pass through the loop: rebuild the scene, regenerate the data, retrain the policy, re-evaluate at scale. Robot foundation models therefore go through large-scale retraining far more often than language models do, and every pass carries rendering, physics, and evaluation compute on top of the training itself. A deployed robot is not a finished model being served. It is a standing demand for simulation.

Physical AI is not one market. It is every machine that has to perceive and act: autonomous vehicles, industrial arms and mobile robots, defense systems, drones, and humanoids. The segments differ in body and in buyer, but they run the same loop, and each is already large on its own. Factories installed 542,000 industrial robots in 2024, more than double the count of ten years earlier, bringing the operating fleet to roughly 4.7 million.^[6] Waymo alone now provides more than 500,000 robotaxi rides a week, and Goldman Sachs projects the U.S. robotaxi market growing from about $3 billion next year to $19 billion in 2030 and $48 billion in 2035.^[7] The U.S. Department of Defense gave autonomy its own budget line for the first time in fiscal 2026: $13.4 billion for autonomous systems.^[8] Humanoids are the newest segment and the fastest growing; Goldman Sachs now projects a $138 billion market and 6.5 million units shipped a year by 2035,^[4] and Morgan Stanley $5 trillion by 2050.^[9] NVIDIA puts the physical AI opportunity across these industries at fifty trillion dollars.^[10] Those numbers describe the destination. The loop is the road, and every mile of it is compute.

The machines that will demand physical intelligence are already landing. But the fundamental compute infrastructure they need does not exist yet, and it cannot be bolted on after the fleets are in the field; it has to be built ahead of them. That is why we are building it today, while it still looks early — because by the time it looks obvious, the window will have closed.

The workload has now been named. In March 2026 NVIDIA published an open reference architecture for physical AI data generation, augmentation, and evaluation, and Microsoft Azure and Nebius announced they would integrate it into their clouds.^[11][12] We think this is the best possible news. It confirms that the loop is real, that it is distinct from the token workload, and that it is worth building for. It is also a starting line, not a finish line.

Hyperscalers optimize homogeneous fleets, because at their scale homogeneity is the whole game. They sell instances, not workflows. Their demand — and their attention — will be dominated by language models for the foreseeable future, and a heterogeneous, stateful, data-heavy workload that needs RT parts and tensor parts scheduled together is operationally awkward inside a machine built to sell identical GPU-hours by the million. A reference architecture layered on top of that machine inherits its economics.

Incumbent neoclouds are racing to fill homogeneous H100 and B200 capacity they have already financed. The product is a GPU-hour. Adding RTX servers and a data pipeline to an LLM cloud is possible, and some may even attempt it. But bolting a loop onto a cluster is not the same as building a cluster around a loop. A few racks of RTX beside an LLM fabric does not change what the cloud is. The scheduler still thinks in GPU-hours, not stages. The data plane was sized for text, not for petabytes of video. The network was tuned for all-reduce, not for keeping a simulator and a learner on the same device. The billing, the capacity planning, and the debt behind the hardware are all indexed to a single SKU. Every one of those has to change for the loop to run well, and changing all of those is not an add-on; it is a rebuild. The incentives point the other way, too: every dollar spent on the loop is a dollar not spent filling the homogeneous capacity already on the balance sheet. A retrofit inherits all of those assumptions.

We started without them.

Robot companies building their own infrastructure is the 2005 problem of every startup running its own data center: possible, distracting, and eventually a competitive disadvantage against the teams that don't have to.

The gap between the incumbent clouds and the robot companies is a layer. We know what that layer has to look like because we have built the previous version of it — inside hyperscalers, and inside the neoclouds that followed. We know exactly what those machines are designed to do, and exactly what they are not.

The corpus must be manufactured. There is no internet of actions. Simulation, rendering, and synthetic data are not preprocessing for robotics; they are the data source. Infrastructure that treats them as a side job has its priorities backwards.

Heterogeneity is the design, not a compromise. The right silicon for each stage — HGX, RTX, CPU, edge — is the architecture. A single SKU scaled to infinity is the wrong answer to this question no matter how good the SKU.

The loop is the unit of work. Not the job, not the instance. Infrastructure should be measured by how fast a team can go around the loop — from a failure in the field to a scene, to data, to a policy, to a validated deployment — and how many times.

Build for the data, not just the FLOPs. Petabytes of sensor and simulation data are the largest thing in the loop. Ingesting, storing, and feeding them to the GPUs is where infrastructure earns its keep.

Measure what roboticists measure. Simulated hours, rendered frames, scenarios evaluated, sim-to-real gap. GPU-hours are an input, not an outcome.

Build on what is adopted; lock into nothing. NVIDIA's ecosystem is the foundation because it is where the field is. Every other simulator, framework, and model family is welcome, and no team should have to rebuild its loop to leave.

Evaluation at scale is a safety requirement. Machines that act in the world will be judged by their worst day. The ability to run ten thousand scenarios before a policy touches a robot is not a luxury feature. It is the responsible minimum.

Grey matter is the tissue in the brain that does the thinking. Materia is the Latin word for matter — the physical stuff of the world. Grey Materia is intelligence for machines that work in matter, and the substrate that intelligence is built on.

If you are building machines that move, we would like to hear what your loop looks like — where it is slow, where it is expensive, and where it breaks. If you have spent your career building the last generation of infrastructure and want to build the next one, we would like to talk.

Contact our founders: [email protected] [email protected]