By Sarah Xiao 
Embodied AI is moving its centre of gravity from the benchmark to the shop floor. The question is no longer whether a model can complete a task in a video, but whether the system runs stably for a shift — which changes the subject from models to infrastructure.
The useful way to frame that infrastructure is a three-by-three grid: compute, communications and control on one axis; cloud, edge and device on the other. Nine cells, each of which is a real engineering problem. When a VLA model has to drive physical motors on a hundred-millisecond cycle, the weakest cell decides whether the task succeeds. Not the average cell. The weakest one.
What the grid makes visible
Compute is the obvious one: can the model run at the required rate within a power and thermal budget a mobile robot can carry.
Communications is the underrated one. A cloud-hosted policy that answers in 300 milliseconds is fine for a chatbot and useless for a hand that must catch a slipping object. Every round trip has to be inside the control deadline, or the architecture has to keep the loop local.
Control is the one robotics people already know: real-time closure at millisecond scale, deterministic, and safe when it fails.
Cross those with cloud, edge and device and the failures become specific. Model on device, weights in the cloud, telemetry over Wi-Fi: the device cell for communications is the one that breaks, and it breaks in the customer’s building, not in the lab.
Toward a decoupled stack
The engineering response being pursued in the open-source ecosystem is not a better single tool but a layered stack where each layer can be replaced:
- Cross-chip adaptation — a unified operator interface with heterogeneous scheduling, so the same model is not rewritten per SoC.
- Compiler toolchain — graph lowering and code generation on MLIR.
- Quantisation and inference — 4-bit weights and activations in multiple formats, with low-latency streaming output.
- Motion control — millisecond-scale real-time closed loop.
- On-device safety and evaluation tooling.
The design constraint is compatibility — with existing operator libraries, compiler stacks and ROS 2 — because a stack that solves the problem by creating another ecosystem has not solved it.
Why quantisation is different here
For a language model, compression is measured in token accuracy. For an embodied model, the output is a continuous action sequence, and a small numerical deviation compounds through time until the task fails. The objective function has to be rewritten.
The framing that follows is behaviour preservation: action fidelity ahead of token accuracy, temporal stability and semantic alignment weighted together, and closed-loop task success rate as the acceptance criterion. A model that loses 0.5% of tokens and 3% of grasp success is not a 0.5% problem.
That is also the practical reason to distrust compression claims quoted in perplexity. Ask for the success rate on your task, measured on the device, after quantisation.
Three tiers, and what belongs in each
Single-machine deployment is the minimum viable form. As soon as tasks expand to multiple robots, the architecture reorganises:
Device holds real-time inference and the control loop. Edge fuses multi-modal sensing streams and provides deterministic low-latency transport. Cloud does task orchestration, elastic compute scheduling and the data loop back into training.
The value is not summed compute. It is graded data governance: high-frequency, low-dimensional control signals stay local; low-frequency, high-dimensional learning signals go up. That division is what keeps the perceive–understand–predict–plan–act loop closed under real network conditions.
What this means if you are buying the robot
A demo can hide a two-hundred-millisecond network dependency indefinitely. Six questions expose the architecture:
- Control loop period, and measured jitter. Not the nominal rate — the distribution, on a loaded system, over an hour.
- Does the policy run on the device, or round-trip? And if it rounds trips, what happens to the loop when the link degrades.
- Degraded-mode behaviour. What the robot does in the 500 milliseconds after the network drops. Stop, hold, or complete the current motion — and is that safe in your cell.
- Task success rate after quantisation, on your task. Measured on the shipped device, not on a developer kit.
- Update and rollback. Whether models ship OTA, whether a bad update can be reverted, and how long a rollback takes on a fleet.
- Chip and module supply. Edge inference silicon has its own lead times and allocation. Ask which SoC, from whom, and what the second source is.
That last one is a sourcing question, not a technical one — and it belongs in the same due diligence as the mechanics. A robot whose onboard compute depends on a single allocated part has a supply risk that will not appear in any benchmark.
The quiet conclusion
Every cell in the grid is an engineering problem, and none of them is solved by a better model. The constraint on embodied AI reaching production is not intelligence; it is a hundred-millisecond loop that has to close the same way ten thousand times, on a device that costs what a device can cost, over a network nobody controls.
That is a less exciting claim than a new benchmark record. It is also the one that decides which robots are still running in a year.
Related reading
- Robots building robots: one a day, one an hour — why the production side of this industry is also a systems problem.
- Robot tactile sensors compared: flexible arrays, magnetic Hall, vision-based — the sensing layer that feeds the control loop.
- Humanoid robot market H1 2026: 36,000 units, top five all Chinese — the volumes that make these infrastructure questions commercial.
Sources: the 3×3 constraint framing, the layered open stack, the behaviour-preserving quantisation argument and the three-tier architecture follow RadixRoot (20 October 2026). The buyer questions, the degraded-mode concern and the silicon-sourcing note are Latest Robot News editorial.