Robot Foundation Models Got Smart Fast. Hardware and Inference Are the New Bottleneck.

A robot foundation model that clears a countertop in a demo and a robot that works a full shift are not the same product. The first one only has to look convincing on camera. The second one has to hit a control cycle on time, share its processor with sensor fusion and motion control, satisfy a safety case an integrator will sign, and survive a bill-of-materials review a manufacturer will accept. An EE Times industry analysis makes that gap the central problem: getting a capable Physical AI model onto a real robot is now a systems-engineering problem, not a modeling problem.

Physical AI is the loose industry label for systems that perceive the physical world and act on it in a closed loop. The dominant model class behind the label is the Vision-Language-Action model, or VLA: a single neural network that takes camera frames and a natural-language instruction, and outputs motor commands for a robot. Instead of stitching together a separate perception module, a planner, and a low-level controller, a VLA collapses all three into one model. Physical Intelligence's π0.5 is one of the better-known open examples; the primary paper and the openpi reference implementation put the architecture, the training data, and a hosted checkpoint into the open.

The capability curve on those models has been steep. In research settings, a VLA can fold a shirt, stack dishes, or pick up unfamiliar objects from a bin, all from a single language prompt and a camera feed. The same models, running on the same weights, have to be deployed on hardware that is doing several other things at once: reading force-torque sensors, fusing depth, talking to a motion controller, and running a safety monitor. The control loop on a robotic arm typically runs at hundreds of hertz, and missing a cycle is not a soft failure. It is a dropped part, a stalled conveyor, or a hard e-stop.

That mismatch is what the EE Times piece calls the demo-to-shift gap, and it is the part of the story where the bottleneck now lives. The research community is producing capable open models faster than the industry is producing ways to run them on a real machine, and the slow surface is not the network. It is inference optimization, heterogeneous compute scheduling, real-time control integration, and the unglamorous work of keeping one software stack consistent across many robot platforms. Whoever solves those four surfaces will decide which of today's demo videos become the products that ship next year.

Intel's OpenVINO team has published one worked attempt at the deployment half of the problem. The post positions OpenVINO as a runtime for the same π0.5 model, with the explicit goal of cutting model preparation complexity for teams that want to move from a research checkpoint to a production system. That is a useful proof point, but it is also a vendor-side artifact, and the deployment numbers it cites should be read as a vendor's own benchmark until independent measurements catch up. The structural point survives the caveat: an open VLA and a vendor runtime are now the two pieces the industry is trying to bolt together, and the bolts are where the engineering goes.

Three constraints make this harder than it looks. A VLA on a GPU is not a real-time system by default: a control cycle that misses its deadline is a hazard rather than a slowdown, and the inference graph has to be scheduled alongside the rest of the robot's software with bounded latency. The standard tools in the deep-learning stack were not built for that. A modern robot is also a heterogeneous computer, with a CPU for motion control, an accelerator for perception, and sometimes a separate chip for safety monitoring, and the VLA has to land on one of those resources without starving the others while the scheduler stays aware of the safety case. And the model has to run on the hardware the manufacturer is already buying, not on the hardware the lab prefers. That is a software-stack problem as much as a model problem, and it is the part that does not show up in a paper.

The same dynamic is what the open-source ecosystem is trying to buy down. The openpi repository and the lerobot/pi05_base checkpoint make it possible for outside teams to load the same model the lab used, without retraining. That is a precondition for the rest of the stack to settle, because vendors and integrators can only target a model that the rest of the world can also run.

The watch item for the next 18 to 24 months is not whether the next VLA will be smarter. It will be. The watch item is which deployment stack, and which pairings of accelerator, scheduler, and safety monitor, actually land in a working line. The teams that can answer that question with measured numbers, on hardware a manufacturer will buy, are the ones that turn the next round of demo footage into shipped product.