A language model produces text for a person to read. If it comes out wrong, the person rereads it, fixes the prompt, moves on. The cost of the error is embarrassment.
An action model produces numbers that go to a motor. If it comes out wrong, the gripper closes on somebody's hand. The cost of the error is different.
That difference changes everything — the architecture, the training data, the evaluation and the liability. It is the subject of this final part.
🌍 Series "World Models" — 5 parts
1. What a world model is · 2. Cosmos 3 inside · 3. Synthetic data · 4. Splitting across GPUs · 5. From text to action ← you are here
What a VLA model is
VLA stands for Vision-Language-Action. The idea in one line: the model receives what the robot is seeing plus an instruction in plain language, and returns what the motors should do — directly, with no intermediate programming.
| Classical robotics | VLA model | |
|---|---|---|
| How you teach a task | by programming the trajectory | by demonstrating and describing it |
| A new task | a new program | a new instruction in text |
| An object it has never seen | fails | sometimes generalises |
| Predictability | total | statistical |
| Where the effort goes | control engineering | collecting demonstrations |
The last row is what most surprises people coming from industrial automation: the work does not disappear, it moves. You stop writing trajectories and start curating demonstration data — which is the subject of part 3.
Why "action" is harder than "text"
1. The output is continuous, not a symbol. Text comes from a closed vocabulary — the model picks among N known tokens. An action is a vector of real numbers: joint angle, velocity, gripper aperture. There is no "37.4 degrees token". The output has to be discretised into bins or generated by diffusion, and both solutions bring their own problems.
2. There is no undo. An LLM can correct itself in the next sentence. An arm that knocked the glass over does not un-knock it. This forces the model to operate at high frequency — dozens of decisions per second — because correction only exists if it is fast enough to happen before the consequence.
3. The body is part of the problem. And this is the most underestimated part.
The embodiment problem
A language model trained on English works with any keyboard. An action model trained on one arm does not work on another arm — because the output vector describes that body.
The Cosmos 3 card makes this brutally explicit in the dimensions it accepts:
| Body | Action vector dimensions |
|---|---|
| One Franka Panda arm with RobotiQ gripper | 10 |
| Two Franka Panda arms with grippers | 20 |
| AgiBot platform | 29 |
| Egocentric motion (head-mounted camera) | 57 |
| Autonomous vehicle · camera motion | 9 |
A model that learned to produce 10 numbers does not produce 29. And it is not just the count: the number in position 3 means different things on different bodies. Changing robot model is, to a large extent, starting over.
💡 Which is why "foundation model for robots" is still a promise
In language, a pretrained model transfers to virtually any new task. In robotics, it transfers to new tasks on the same body — and transfer across different bodies is an open research area, not a product feature.
When evaluating any announcement in this category, the first question is always: on which body?
The trick that breaks the labelling bottleneck: inverse dynamics
This is the most beautiful idea in the field, and the one that gets the least coverage.
An action-conditioned world model can do forward dynamics: given the state and the action, what is the next state? That is the obvious mode — simulate.
But it can also do the reverse — inverse dynamics: given two states, which action took us from one to the other?
Stop for a second on what that means. You have hours of video of somebody performing a task, with no sensors and no annotation — just the video. Inverse dynamics infers the commands that would produce that motion. Unlabelled video becomes labelled training data.
It is the way out of part 3's bottleneck: the expensive data is not the video — it is the action label attached to the video, which normally requires teleoperating a real robot. If the label can be inferred, the world's video archive comes into play.
⚠️ And the limit of that, which is serious
The inferred action is the one that would explain the video according to the model — not the one that actually happened. Where the model's approximate physics diverges from real physics, the label comes out plausible and wrong.
A wrong label is worse than a missing one: missing data you notice, wrong data you train on. The same protocol from part 3 applies — tag provenance and keep an evaluation set with real, actually-measured labels.
What you can use today
| Model | Size | Availability |
|---|---|---|
| OpenVLA | 7B | Open weights, Apache 2.0 licence. From Stanford with the Toyota Research Institute. Fine-tuning fits on a consumer card — the natural starting point. |
| GR00T N1 | — | NVIDIA's open foundation model for humanoid robots, with a dual-system design. |
| Cosmos3-Nano-Policy-DROID | 16B | Language instruction + visual observation → action trajectory. Tied to the DROID platform. |
| π0 (Physical Intelligence) | — | Among the most capable in the category, but not downloadable: access by API or partnership. You cannot self-host it. |
That last row is why open weights matter so much here. A robot that depends on a remote API to decide its next movement has the network in the critical path of control — bad for latency and unacceptable for reliability. A robot that must keep working when the internet drops needs the model locally.
Where to actually start
The good news is that the entry step is low. A 7B VLA is orders of magnitude cheaper than a 64B world model:
| Stage | What runs | Card | Price/h |
|---|---|---|---|
| Run OpenVLA as-is, see what comes out | 7B inference | 24 GB | R$ 3.18 |
| Light fine-tune (LoRA) on your robot | partial 7B training | 48 GB | R$ 7.08 |
| Full fine-tune | 7B training | 80 GB | R$ 14.31 |
| Generate synthetic data for that fine-tune | world model | see part 4 | — |
Catalogue prices as of 1 September 2026, per single GPU, no scheduled interruption. Prices are in Brazilian reais (BRL), the billing currency. The catalogue moves within the same day — check the live one before committing to a number.
Note that the most expensive stage is not running the action model — it is manufacturing the data for it. That is the inversion running through this entire series: in physical AI, the bill is in the data, not the model.
Liability, without hedging
Worth closing the series with what NVIDIA writes on the Cosmos 3 card itself: outputs should not be treated as physically accurate simulation or as a basis for safety-critical decision making, and applications in robotics or autonomous systems require additional validation, external constraints and system-level safety analysis.
Translated into practice: the model is the suggestion layer. The safety layer — force limits, emergency stop, virtual fencing, plausibility checks before actuation — is classical, deterministic engineering, and it remains mandatory. Nothing in this series replaces it.
Anyone who builds in the reverse order will find out the expensive way.
End of the series
Five parts, one thesis: world models are the attempt to teach consequence rather than appearance. The technology is real, the weights are open, the licence permits commercial use — and the limitations are exactly the ones the authors document, no fewer and no more.
If you got this far wondering whether it is worth investing: the cheap way to find out is to start small. A 7B action model on a 24 GB card answers, in an afternoon, whether the category solves your problem.
Start on the low step
A 7B VLA runs on a 24 GB card for R$ 3.18 an hour. Billed by the hour, in Brazilian reais, no contract and no minimum commitment — you can prove the concept before sizing anything.
See the catalogue →Keep reading: part 3: synthetic data · part 1: what a world model is