Why AI Infrastructure Giants Are Racing Into Robotics

At CoreWeave’s Fully Connected conference, Anu Vatsa described a robot that had found an excellent way to avoid mistakes: do nothing.

His team was adapting NVIDIA’s DreamZero world-action model from a single-arm setup to a robot with two arms. The video predictions adapted relatively easily. Getting useful movements out of the machine was much harder. At one point, Vatsa explained, it hovered because avoiding mistakes also earned favorable feedback.

His slide showed four attempts to first success. Then Vatsa chuckled: “Four attempts that actually got evaluated,” he said. There were also 233 failed experiments that were never evaluated.

That got me thinking. AI infrastructure companies are moving almost aggressively into robotics and physical AI. They are buying research labs, building development platforms, and putting their own engineers to work teaching machines.

Yes, robots need GPUs. But supplying those GPUs does not require an infrastructure company to acquire a model lab or spend months figuring out why a robot refuses to move. Something more is happening.

On September 28, AMD announced an agreement to acquire World Labs, Fei-Fei Li’s spatial-intelligence company, for approximately $8.2 billion in stock. Earlier that month, CoreWeave launched Physical AI Field Engineering, putting specialists alongside customers to build applications from their engineering data. NVIDIA already supplies models, simulation tools, and computing systems for robotics, with Spencer Huang leading its robotics software product work. We spoke with him about that ambition.

These companies occupy different parts of the infrastructure business. Yet all are getting closer to the work of building the intelligence their systems will run.

Why go that far? And why does this belong in our “AI Builds AI” series?

AI can help build another model, and it can also help build a bigger business for the company supplying the tools. The acquisitions, the engineering teams, and the experiments suggest that infrastructure companies are willing to spend considerably to find out if that’s true. So AI builds AI that way too.

To go beyond “everything needs GPUs”, let’s follow the money and the engineering.

In today’s episode:

Robotics gives infrastructure companies more than another customer for GPUs. By helping build the applications, they learn what future hardware and software must do. They can also turn that experience into tools and services for other teams. The opportunity reaches beyond computing budgets into the money companies already spend on engineering, testing, and robot development.

First, let’s clarify a few things. NVIDIA, AMD, and CoreWeave all benefit when more AI computation happens. Their businesses overlap, but what they sell to the robotics team is different.

Once the robot starts working, it may make its immediate decisions locally, as AMD’s arm does. There is a lot before that though: all the preparation, simulation, training, checking, and trying again. Models can be working throughout this process, captioning footage or inspecting results while the team figures out how to make the machine useful.

For an infrastructure provider, the customer relationship can begin years before the triumphant factory video. But selling today’s compute explains only part of the interest. Working on the application gives each company a chance to discover requirements that a hardware benchmark never asks about.

AMD’s cube experiment and Vatsa’s 237 attempts let us examine that idea. What do they reveal about the work, which parts can AI take over, and how might the supplier turn what it learns into something worth paying for?

AMD’s example seems to be so modest: a UFactory arm picks up a cube. The deployed controller is a small neural network, with conventional camera processing supplying the object’s position. We can look past the spectacle and see the engineering.

Robotics demands precision, even when the learned behavior is hard to explain. Meticulous and detailed. And brutally hard.

To pick up that cube, the robot has to know where its own joints are, where the cube is, how the gripper is oriented, and what movement will bring the two together without knocking the cube away. It has to approach at the right angle, close the gripper with enough force to hold the object, then lift while continuously correcting for small errors.

And those errors are everywhere. This is the reason sim-to-real is such a central problem in robotics. You want to train cheaply and quickly in simulation, where a robot can attempt the same movement millions of times without breaking hardware or requiring a human to reset the scene. But the resulting policy has to survive contact with a much messier world.

So engineers deliberately make the simulated world less reliable. They vary block position, initial joint configuration, block mass, and actuation delay during training. The controller learns across these variations rather than memorizing one immaculate virtual cube.

The final neural network can therefore be surprisingly small. Much of the intelligence is in everything that happened before deployment: the simulation, the reward design, the choice of observations and actions, the randomized environments, and the engineering required to make the virtual robot resemble the physical one closely enough.

This is an enormous amount of work devoted to making that little pick up boringly repeatable.

Consider how different AMD’s small controller is from DreamZero. The latter jointly predicts future video and robot actions using a 14-billion-parameter model built on a pretrained video diffusion backbone.

These are different approaches with different ambitions. But that’s precisely what makes the supplier’s problem interesting. “Robotics” is not one settled workload for which somebody can simply design the ideal chip.

For a chip designer, the questions include what to accelerate and how to balance computation, memory, and power. For a cloud provider, they include how to provision, connect, and operate the components so researchers can make progress. You only really learn how to make those trade-offs by building the application yourself.

This is where “AI Builds AI” goes back to being technical. The robot is learning a task, but there is a lot of engineering involved in deciding how it should learn. Increasingly, models can help with that work too.

Take reward functions. In reinforcement learning, the reward tells the system what counts as success. Writing a good one is surprisingly difficult: reward the wrong behavior and the robot may become very good at doing exactly the wrong thing. (This sentence also explains a remarkable number of AI incidents, just FYI.)

In 2023, NVIDIA researchers introduced Eureka, which used an LLM to write reward functions, train policies with them, inspect the results, and try again. Across 29 simulated environments, its rewards outperformed human-written ones on 83% of the evaluated tasks.

Then DrEureka went further. It used a language model to help choose both rewards and the variations introduced during simulation so that a learned behavior had a better chance of working on a physical robot. One demonstration involved a quadruped balancing and walking on a yoga ball.

And the loop keeps expanding. CoreWeave’s ARIA is designed to read experiment records, investigate results, form hypotheses and help launch the next runs.

Look at what is gradually moving into the model’s territory: What should we reward? What training conditions should we try? What happened in the last experiment? What should we test next?

Humans still design the system, verify the results and deal with everything that goes wrong in the physical world. But parts of the expensive trial-and-error loop can now be automated.

And that is probably the right way to measure “AI Builds AI”: by asking how many human engineering hours it removed from the path to a working one.

That brings us back to the business. If teaching a robot takes this much work, a supplier has two possible customers: the team that knows how to do it and needs compute, and the team that has a useful problem but has no idea where to start.

The second customer needs considerably more help. And it also might be the reason to hire mechanical engineers.

For example, CoreWeave sends engineers to work with customer teams, drawing on the expertise it acquired with Monolith. They use the customer’s engineering data to build AI tools. The customer keeps control of the data and the models.

Nissan’s work with Monolith shows what this can look like. Their system helped engineers decide how tightly to fasten bolts in a vehicle’s chassis and which tests to run next. They reported a 17% reduction in physical testing on that project and extended the partnership through 2027.

Testing bolts is already part of Nissan’s work, with a budget and a process to compare against. If AI helps the team do that work with fewer tests, Nissan has a clear reason to use it.

For the supplier, the next question is: can it use what it learned to help another customer?

Customers have different data and equipment, but some of the work will be similar. A tool for tracking experiments can serve several teams. A way to check a model’s performance may be useful on another project. Reusing that work can save time for both the customer and the supplier.

That’s huge financially. If every project needs a large team of specialists starting from scratch, serving more customers also means hiring more people. Better AI can let the same team support more projects.

Nebius’s Physical AI Workbench and CoreWeave’s Forge aim to bring development tools together so teams spend less time setting up and connecting them.

Other providers supply individual parts of the process. Baseten offers NVIDIA’s Cosmos 3 Nano for deployment. Together AI provides services for running and fine-tuning models, along with GPU clusters. Robotics teams can use these services, and I believe this is a major trend. If these companies realize that potential, physical AI could become a meaningful new business for them.

These companies are getting involved at different levels. Some develop models, some work directly with customers, and others provide the computing services. What they learn – and what they can reuse – will depend on how closely they participate in the work.

There is a business opportunity here, but it looks different depending on what the company sells.

For chipmakers, the potential return is a better product sold to many customers. AMD’s stated reason for acquiring World Labs is to use model research to help shape future hardware, software, and systems. If that research leads to improvements other developers need, AMD can spread the cost of learning across a much larger business. That is the attraction of bringing researchers inside the company. The acquisition announcement establishes the intention; future products will show what comes of it.

For cloud providers, the question is how much it costs to make each customer successful. CoreWeave can earn revenue from the experiments and from helping teams run them. But if every project requires months of custom engineering, growth also requires more specialists. The more attractive outcome is that experience becomes software and methods many customers can use. Then the provider can serve more teams without repeating all the work for each one.

For inference providers, physical AI offers another source of demand. A model generating training experience or inspecting experiments needs somewhere to run. Serving it reliably and cheaply can be valuable. The harder question is why a customer would stay with a particular provider when competitors can serve the same model. Performance, cost, and how well the service fits the customer’s work will matter more than having “physical AI” on the product page.

This is why I’m bullish on Physical AI. These companies can go after budgets that have never been AI budgets: vehicle testing, factory engineering, robot development. AI helps them do enough of the work to enter those markets.

“AI Builds AI” is also a business expansion strategy. The supplier helps create the application, then sells the infrastructure it needs.

The valuation question gets more interesting when the companies we price as GPU suppliers start competing for industrial engineering budgets.

The talk

Research

Platforms and implementation

Company strategy and deployment evidence

← AI Builds AI, Episode 2: What Happens After You Tell an AI Agent It’s Wrong?