World Action Models vs VLAs: Cosmos 3, VLA-JEPA and FastWAM Compared

A vision-language-action policy that folds a towel in your lab will often fail on the same towel in a different light. The usual diagnosis is “not enough data”. The architectural diagnosis is sharper: a vision-language backbone is trained to describe a scene, not to predict how it changes. World action models replace that backbone with a pretrained video world model, so the policy inherits a physics prior instead of a captioning prior. Two shipping events in the last ten weeks turned this from a research talking point into something you can install: NVIDIA released Cosmos 3 with post-trained DROID policies on 4 August 2026, and LeRobot v0.6.0 landed three world-model policies as first-class trainable classes on 7 July 2026. The catch is that “WAM” now covers three genuinely different architectures with a 10x spread in inference cost.

What this covers: the three WAM formulations, how Cosmos 3, VLA-JEPA, LingBot-VA and FastWAM each instantiate one, what the compute asymmetry actually costs, and a decision matrix for choosing between them.

Context and Background

The dominant recipe for a generalist manipulation policy has been to take a pretrained vision-language model, bolt on an action head, and fine-tune on demonstrations. That is the vision-language-action (VLA) pattern behind Pi-0, GR00T N1.x, OpenVLA and the current generation of VLA models we compared earlier this year. It works, and it generalises well semantically — a VLA that has never seen a mango will often still pick one up when you ask for fruit.

The failure mode is physical rather than semantic. As NVIDIA’s own write-up puts it, a VLM “does not learn what happens to a mug when the gripper closes, how a towel folds, where an object lands when released.” Those are dynamics questions, and nothing in image-caption pretraining answers them. So when a task depends on anticipating a change rather than recognising an object, the VLA is doing that reasoning from demonstration data alone.

The alternative is to start from a model that was already trained to predict the next frame. Video generation models have absorbed enormous quantities of physical behaviour, badly and implicitly, but at a scale no robot dataset approaches. A world action model reuses that video or world-model backbone as the policy’s trunk and adds an action interface. The claimed payoff is three-fold: any interaction footage becomes useful training signal rather than only near-identical demonstrations; physical generalisation transfers where semantic generalisation does not; and a new embodiment needs fewer demonstrations to specialise.

That framing is now backed by a formal literature. World-Action Models for Robot Learning and Control: A Survey (arXiv 2609.16074, September 2026), from a group spanning MBZUAI, Caltech, Georgia Tech and NYU, is the first survey to give the class a unified taxonomy across representations, transition modelling, action interfaces and scaling. Read alongside NVIDIA’s taxonomy post on the rise of world-action models, it gives you two independent vocabularies for the same design space — and the places where they disagree are the interesting ones.

The Three Formulations, and Where Each Drops the Video Model

A world action model is a robot policy built on a pretrained video or world-model backbone rather than a vision-language backbone, so that predicting how the scene evolves is part of the policy itself. The three formulations differ at one place only: the inference boundary. Whether the model still generates video when the robot is actually running determines its latency, its hardware tier, and most of its practical character.

Figure 1: The three WAM formulations differ by what survives to inference — full video generation, joint denoising, or nothing at all.

Figure 1 traces the same input — a language instruction plus the current observation — down three paths. In the inverse-dynamics path, a video model produces future frames or latents first, and a separate head infers the actions that would produce that transition. In the joint-prediction path, one network denoises video tokens and action tokens in a single pass. In the representation-only path, the world model shapes the representation during training and is deleted before deployment. All three converge on the same output: an action chunk, a short horizon of joint commands or end-effector deltas emitted in one policy call.

Inverse dynamics: imagine first, then read off the action

Inverse dynamics is the easiest recipe to reason about and the oldest. Given the current observation and a predicted future observation, infer the action sequence that would take you from one to the other. UniPi pioneered the modern form of this in 2023, and it is worth noting why it did not immediately catch on: UniPi used a CNN-based video diffusion stack from the Imagen Video era and had to pretrain the video generator from scratch. NVIDIA’s rough estimate puts that pretraining near 167 ZFLOPs — outside the budget of essentially every robotics lab.

What changed is that open DiT-based video backbones now exist, so the expensive part can be inherited. LingBot-VA is the modern instance: it turns Wan 2.2-5B into a causal video-action model through 16,000 hours of cross-embodiment pretraining, using a Mixture-of-Transformers layout with separate video and action experts coupled by shared self-attention. Crucially it is trained on long visual histories for closed-loop rollouts, not open-loop video generation — which is what makes it usable as a controller rather than a planner.

The structural cost is unavoidable: the video stage runs at inference. Every control cycle pays for a video denoise. That is why LingBot-VA needs a 24–32 GB GPU rather than an embedded module.

Joint prediction: one denoising process, two modalities

Joint prediction collapses the two stages. One model, conditioned on the observation and instruction, predicts both the future observations and the actions. There is no separate inverse-dynamics module; the action is simply another generated modality inside the same denoising process.

GR-1 established the policy-level version of this in 2024 with a GPT-2-style transformer and an L2 objective over future frames and action chunks. DreamZero is the scaled modern version, initialising a monolithic DiT from Wan 2.1-I2V-14B-480P and denoising video and action tokens together with a flow-matching objective. The two share an idea and almost nothing else — backbone, scale, objective, text encoder and VAE all differ — so treating GR-1 versus DreamZero as evidence about joint prediction specifically would be a mistake.

The argument for joint prediction is that coupling forces the model to learn what should happen and how to cause it in the same step, rather than letting an action head paper over a bad imagination. The argument against is that you still carry the video generation cost at runtime.

Representation-only: dream in training, delete at deployment

The third formulation is the one that makes WAMs deployable. Use the video backbone purely as a representation-shaping device during training, then skip video generation entirely at inference.

Fast-WAM is the reference example. It uses a Wan/MoT-style setup close to LingBot-VA’s and, per NVIDIA’s analysis, closely matches its performance on simulated benchmarks without the 16,000 hours of large-scale robot pretraining — while running several times faster at test time because the dream step is gone. VLA-JEPA arrives at the same place from the other direction: it starts from a compact VLA and adds a world model as training supervision, rather than starting from a video model and removing it.

Be careful with the evidence here. NVIDIA’s own author is explicit that Fast-WAM is “one of the few public pieces of evidence for the representation-only hypothesis, and current simulation evidence is not enough to really convince me of this idea.” That is an unusually honest line in a vendor blog and you should carry the caveat forward. Representation-only is the most attractive formulation commercially and the least validated empirically.

How Actions Actually Enter the Model

The formulation axis tells you when video generation happens. It says nothing about the harder engineering problem underneath: a pretrained video backbone knows how to denoise visual tokens, and knows nothing about continuous robot actions. Every WAM has to bridge that modality mismatch, and the three ways of doing it have different failure characteristics.

Default action tokens

The straightforward option is to add action tokens — continuous or discrete — plus an action head, treating actions as one more modality alongside video. UniPi, GR-1, DreamZero, LingBot-VA, VPP, mimic-video and Fast-WAM all use some version of this. It is the default because it is the least invasive: the backbone’s pretrained weights are left doing what they already do, and the new tokens learn to live alongside them.

The risk is the mismatch itself. An action chunk has completely different statistics from the visual tokens the backbone was pretrained on, so the model must adapt its representation during action fine-tuning. If the action fine-tune is short or the learning rate conservative, you can end up with a model whose video expert is excellent and whose action expert is under-trained — which looks, from the outside, like a policy that understands the task and cannot execute it.

Action as image

The second option encodes actions as visual targets inside the video denoising interface, so the action lives in the modality the backbone already understands. GENIMA did this with Stable Diffusion and ControlNet in 2024, and NVIDIA’s classification table places Cosmos Policy in this row as well, paired with a monolithic DiT.

The elegance is real: if you can draw the action, the pretrained denoiser needs no new modality. The limit is equally real — spatial precision is bounded by image resolution, and anything not naturally visual, like gripper force or a torque command, has to be encoded awkwardly or dropped.

Latent plans and latent actions

The third option compresses behaviour into a latent plan or latent action learned from video. The survey calls these Latent Action Models: they learn abstract action representations from state transitions rather than raw controls, which decouples action modelling from embodiment-specific hardware and — the important part — makes action-free video usable as training data.

That last property is why this line matters even though its current instances are less mature. Every other approach needs paired observation-action data, and paired data is exactly what is scarce. A model that can learn an action abstraction from unlabelled video has a fundamentally different data curve.

Architecture families, and why MoT keeps winning

Cutting across all of this is the question of how many networks are actually involved. Three patterns are in use. Hierarchical stacks run a video generator and then a separate action decoder, which is how UniPi, VPP and mimic-video are built — simple, debuggable, and one-way. Monolithic transformers denoise everything in one network with shared weights, the DreamZero and Cosmos Policy approach. Mixture-of-Transformers keeps modality-specific experts with separate weights, connected through shared attention in each layer.

The 2026 systems cluster hard on MoT: LingBot-VA, Fast-WAM, Being-H0.7 and Cosmos 3 all use it. The reason is structural rather than fashionable. Separate weights per modality let the video expert stay close to its pretrained distribution while the action expert trains freely, which directly addresses the mismatch problem above — and shared attention still lets the two condition each other every layer. It is the design that gets you coupling without forcing one set of weights to serve two very different token distributions.

Where the survey and the vendor taxonomy disagree

Worth flagging if you are reading both: the MBZUAI-led survey recognises only two transition-modelling paradigms, joint prediction and inverse dynamics, and treats them as the complete factorisation. Representation-only is NVIDIA’s third axis, and it is not a transition paradigm at all — it is a statement about what you delete before deployment.

Neither is wrong. The survey is classifying what the model learns; NVIDIA is classifying what the model costs. If you only read one, you will consistently misjudge either the research lineage or the deployment bill. Read both and the FastWAM ambiguity above resolves immediately.

Four Systems, Four Different Bets

Figure 2: Cosmos 3 routes discrete reasoning tokens and continuous action tokens through separate experts joined by shared attention.

Figure 2 shows the Cosmos 3 data path in detail. Multi-camera frames and a language instruction enter an autoregressive transformer that handles discrete tokens and produces reasoning text and plan tokens by next-token decoding. Those tokens, the raw observation and the robot’s proprioceptive state all meet at a shared attention layer that joins the Mixture-of-Transformers experts. A diffusion transformer then handles every continuous modality — image, video, audio and action — by iterative denoising. Actions and predicted frames fall out of the same denoising pass, and the action chunk reaches the controller.

Cosmos 3: a full omni-model that never stops being one

Cosmos 3 is an omni-model world foundation model on a Mixture-of-Transformers architecture, released in three sizes: 4B Cosmos Edge, 16B Cosmos Nano and 64B Cosmos 3 Super. Pretraining used roughly 767M images, 348M videos of real-world dynamics and 8M action samples spanning robot manipulation, autonomous driving, camera motion and egocentric motion.

Two policy checkpoints are post-trained for the DROID platform — a Franka Panda arm with a Robotiq gripper. Cosmos3-Nano-Policy-DROID is the 16B version; Cosmos3-Edge-Policy-DROID is the 4B version post-trained the same way for on-device use.

The architecturally unusual property is that post-training removes nothing. The policy checkpoint still has the full omni architecture and can still reason and generate video — it is not reduced to a joint-position emitter. In practice that means the model can output, at the same moment and from the same forward pass, both the action it intends and the video its cameras would see if that action were executed. For debugging and for operator trust, having the intent and its predicted consequence come from one model rather than two is a materially different proposition.

The prior is also measurable, which is rare. The Cosmos 3 technical report compares two DROID policies trained with identical recipe, data and compute — one from the base checkpoint, one from an omni checkpoint trained on multi-domain action data. RoboLab success went from 28.1% to 36.8%. That is a genuine controlled ablation, and it is the single strongest number in this entire post precisely because everything else was held fixed.

VLA-JEPA: the cleanest illustration of representation-only

VLA-JEPA, shipped in LeRobot v0.6.0, teaches a compact VLA built on a Qwen3-VL-2B backbone to predict the future in latent space while it learns to act. During training, a JEPA world model must anticipate upcoming frames from the model’s own actions. At inference the world model disappears entirely.

The phrase to sit with is “world-model supervision at zero extra inference cost.” Everything expensive about a WAM — the video tokens, the denoising steps, the memory footprint of a 5B-plus video expert — exists only in the training loop. What ships is a 2B-backbone VLA with the same latency profile as any other compact VLA. Three checkpoints are on the Hub, including a DROID-pretrained base for fine-tuning.

This is the formulation to reach for if your constraint is a fixed control rate on fixed hardware and you want to know whether world-model supervision buys you anything at all. It costs you nothing at deployment to find out.

LingBot-VA: imagination you can inspect

LingBot-VA in LeRobot is described as an autoregressive video-action model predicting future video and actions chunk by chunk, feeding real observations back in to keep its imagination grounded. Inference runs on a single 24–32 GB GPU.

The feature worth stealing regardless of which policy you adopt is --policy.save_predicted_video=true, which dumps what the robot imagined so you can compare it against what actually happened. Robot policy debugging is normally a matter of staring at a failed trajectory and guessing. Here you get the model’s own forecast as an artefact. When a grasp fails, you can distinguish “the model predicted the right outcome and the controller could not achieve it” from “the model imagined the gripper closing on air.” Those are completely different bugs with completely different fixes, and no VLA gives you the evidence to tell them apart.

FastWAM: the training objective and the inference path disagree on purpose

FastWAM pairs a roughly 5B video-generation expert with a compact action expert in a single network. It learns to dream its own rollouts during training and then skips the dreaming entirely at inference, directly denoising action chunks. The lerobot/fastwam_base checkpoint is 6B parameters.

This is where the taxonomies diverge, and the divergence is instructive. LeRobot describes FastWAM’s training as joint video-and-action learning. NVIDIA’s classification table places Fast-WAM squarely in the representation-only row, alongside a note that its backbone is a Wan 5.5B video diffusion model in an MoT architecture. Both are right, because the formulation axis is defined at the inference boundary, not the training objective. FastWAM trains jointly and infers representation-only.

That distinction is the most useful thing in this article. The training objective tells you what the model learned; the inference path tells you what it costs. Papers advertise the former and deployments pay for the latter. When you read a new WAM release, find the inference path first.

A second boundary case: NVIDIA’s table lists LingBot-VA under inverse dynamics, while its own comparison table notes the action-video coupling is two-way — video conditions actions and generated actions condition video. LeRobot’s description reads like joint prediction. The honest summary is that the categories are a useful lens rather than a partition, and several 2026 systems sit on the line.

The Compute Asymmetry and the Deployment Tiers

Figure 3: What each formulation pays for at training time versus what survives into the control loop.

What the video prior costs

WAMs trade robot-data efficiency for compute cost, and the trade is steep. NVIDIA published a set of lower-bound estimates using the standard dense-transformer approximation C ≈ 6NT, where N is trainable dense parameters and T is tokens. Every number below is an estimate reconstructed from papers and repositories, not a vendor-reported compute budget — treat them as order-of-magnitude, and note that NVIDIA labels them that way itself.

Training stage	Estimated compute	What it excludes
Pi-FAST style VLA DROID action tuning	~0.77 ZFLOPs at 240k steps; ~0.32 ZFLOPs at the current 100k-step config	Not a paper-reported budget; highly sensitive to step count
DreamZero WAM action tuning	~8.6–9.0 ZFLOPs at 100k steps, batch 128	Excludes producing Wan; excludes frozen encoders, VAE, comms
Illustrative Wan-14B full WAM stack	~51 ZFLOPs	Uses a proxy token budget for Wan-scale video pretraining
Summer-22B video pretraining estimate	~66 ZFLOPs over ~500B video tokens	A transparent estimate, not a reported total

The headline is the ratio, not the absolute numbers. Adapting a pretrained video backbone into a policy costs roughly an order of magnitude more than fine-tuning a VLA action head on the same dataset. If you also have to pay for the video pretraining rather than inheriting it, the full stack lands in the tens of ZFLOPs — a different budget category entirely.

The corollary matters more than the numbers: the economics of a WAM depend almost entirely on whether the video backbone is free to you. Cosmos 3, Wan and their open-weight peers make it free. That is the actual reason 2026 is when this class became practical, and it is why the open-weight release cadence matters more to robotics teams than any individual benchmark result.

Deployment tiers

Figure 4: Four deployment tiers, from a 4B on-robot policy to a compact VLA with no world model loaded at all.

Figure 4 lays out the four tiers currently available with published hardware figures. The 4B Cosmos Edge policy runs directly on embedded hardware: it operates at robot-control resolution of 640×360 and generates 32 actions per inference on NVIDIA Jetson Thor while achieving real-time control at 15 Hz. It is supported across NVIDIA edge computers including RTX PRO GPUs, DGX, GeForce RTX GPUs and Jetson, including the new Jetson T2000 and T3000 modules.

The 16B Nano policy runs beside the robot rather than on it. Real-world DROID deployment serves it on a single NVIDIA RTX PRO 6000, with the robot streaming observations over the network and receiving action chunks back. That network hop is a design constraint, not an implementation detail: it puts a wireless link inside your control loop and makes action-chunk length a latency-hiding mechanism rather than a smoothing choice.

LingBot-VA occupies the middle: a single 24–32 GB GPU, which in practice means a workstation card or one cloud GPU. VLA-JEPA sits at the bottom of the cost curve because at inference it is simply a 2B-backbone VLA.

Note what 15 Hz means for manipulation. It is real-time for pick-and-place and quasi-static tasks. It is not real-time for contact-rich work that needs force response inside 20 ms. A 4B WAM on Jetson Thor does not replace a 200 Hz impedance controller; it sits above one. Anyone evaluating these models for assembly or insertion should be planning a two-rate architecture from the start.

The Decision Matrix

Model	Formulation	Inference cost	Hardware tier	Training compute	Checkpoint	Actually good at
Cosmos3-Edge-Policy-DROID (4B)	Joint prediction; retains omni architecture	Full generative model on device; 15 Hz at 640×360	Jetson Thor, Jetson T2000/T3000, RTX PRO	Post-trained from Cosmos 3 Edge; pretraining inherited	nvidia/Cosmos3-Edge-Policy-DROID	On-robot autonomy with no network dependency; DROID-class Franka setups
Cosmos3-Nano-Policy-DROID (16B)	Joint prediction; retains omni architecture	Off-robot serving, observations streamed	One RTX PRO 6000	Post-trained from Cosmos 3 Nano	nvidia/Cosmos3-Nano-Policy-DROID	Highest-capability WAM policy where a network hop is acceptable
VLA-JEPA	Representation-only	Zero extra cost; plain compact VLA at runtime	Whatever runs a Qwen3-VL-2B VLA	Lowest of the four; no video generation to train through	lerobot/VLA-JEPA-Pretrain plus two more	Testing whether world-model supervision helps you, at no deployment cost
LingBot-VA	Inverse dynamics with two-way coupling	Video generated every cycle	Single 24–32 GB GPU	Wan 2.2-5B plus 16k hours cross-embodiment pretraining	LeRobot policy class	Debuggability — you can dump and inspect the imagined rollout
FastWAM	Joint at training, representation-only at inference	Direct action denoise; several times faster than generating video	Mid-tier GPU; 6B checkpoint	~5B video expert co-trained with action expert	lerobot/fastwam_base	Most of the WAM training benefit without the runtime penalty
GR00T N1.7 (VLA baseline)	Not a WAM	Standard VLA latency	3B-class	Cosmos-Reason2-2B backbone into a flow-matching head	nvidia/GR00T-N1.7-3B	The control condition every WAM claim should be measured against

GR00T N1.7 belongs in this table precisely because it is not a WAM. It swaps N1.5’s VLM for Cosmos-Reason2-2B, built on Qwen3-VL, feeding a flow-matching action head — the same flow-matching and diffusion action-head lineage that every model here shares. One operational note that will cost you an afternoon otherwise: N1.7 replaces N1.5 in LeRobot, so pin lerobot==0.5.1 if you need N1.5.

Trade-offs, Gotchas, and What Goes Wrong

Almost none of the published comparisons are controlled. This field moves weekly and the numbers you will see quoted are leaderboard standings and single-vendor reports, not ablations. The DreamZero result is the clearest case: in the April 2026 RoboArena leaderboard snapshot, DreamZero sat at 1750 Elo and Pi-0.5 at 1622, with Pi-FAST at 1592 and Pi-0 at 1475. That is a leaderboard standing on a specific date, produced by a distributed real-world evaluation where different evaluators run different tasks — not a head-to-head between two models on one task suite. NVIDIA’s own framing is that it is “not proof that WAMs are the better default” but “a positive signal for their potential.” Quote it that way or not at all. The one properly controlled number in this article is the Cosmos 3 RoboLab 28.1% → 36.8% comparison, which held recipe, data and compute fixed.

The compute figures are estimates, including the flattering ones. The ~9 ZFLOPs and ~51 ZFLOPs numbers come from a C ≈ 6NT reconstruction, explicitly excluding frozen encoders, VAE cost, communication and data-pipeline overhead. They are useful for ratios and useless for budgeting.

Inference is slow and memory is the binding constraint. Policies that generate or denoise future video latents are much slower than simple VLAs, and long video-token sequences stress GPU memory, communication and data loading simultaneously. Running a 10B-plus WAM on a local GPU is an engineering project, not a pip install.

Post-training is per-embodiment, and that has not changed. Every new embodiment — Franka, dual-arm, UR, WidowX — still requires its own post-training run. The WAM claim is that each run needs fewer demonstrations, not that the run disappears. Budget accordingly, and note that your data must be in LeRobotDataset format before any of this starts.

Imagination quality is not correctness. A video model can produce a plausible, physically wrong rollout — and an inverse-dynamics head will faithfully extract actions from it. The representation-only formulations are partly a hedge against exactly this: if the imagination is never rendered, it cannot be confidently wrong in a way that propagates into the controller.

Benchmark transfer is unresolved. Fast-WAM’s parity with LingBot-VA is measured on simulated benchmarks. Simulation parity has repeatedly failed to predict real-world parity in manipulation, and the author of the analysis says as much.

Practical Recommendations

Start by classifying, not by choosing. For any WAM you are evaluating, answer one question first: does it generate video at inference? That single fact predicts your latency, your VRAM, your hardware tier and most of your integration risk. Everything else is secondary.

If you already run a compact VLA on fixed hardware with a fixed control rate, VLA-JEPA is the lowest-risk experiment available. It costs nothing at deployment, so a negative result is cheap and a positive result is free. Run it before you consider anything that generates video.

If you need on-robot autonomy with no network dependency and you are on DROID-class hardware, the 4B Cosmos Edge policy is the only published option with real hardware numbers behind it. Verify 15 Hz is enough for your task before anything else; if you need contact-rich response, plan a two-rate stack immediately.

If you are doing research rather than deployment, LingBot-VA’s predicted-video dump is worth the GPU. The ability to separate “wrong imagination” from “wrong control” is a genuine methodological advantage.

Checklist before committing:

• Confirm the inference path — video generated at runtime, or not.
• Measure your current VLA baseline on your own tasks first; without it, no WAM number means anything.
• Convert your data to LeRobotDataset format early; every published recipe assumes it.
• Check the licence for commercial use — Cosmos 3’s base model, datasets, recipe, weights and serving stack are released under a commercially permissive licence, but verify per checkpoint.
• Budget one post-training run per embodiment, not one total.
• Pin your LeRobot version. 0.6.0 replaced GR00T N1.5 with N1.7 without a compatibility shim.

Frequently Asked Questions

What is a world action model?

A world action model is a robot policy built on a pretrained video or world-model backbone instead of a vision-language backbone. Because the backbone was trained to predict how scenes evolve, the policy inherits a physics prior rather than a captioning prior. Post-training then specialises that prior into actions. The three formulations — inverse dynamics, joint prediction and representation-only — differ in whether video generation still happens when the robot is running.

How is a WAM different from a VLA?

A VLA adds an action module to a pretrained vision-language model, so it generalises well semantically but learns dynamics only from demonstrations. A WAM starts from a video world model, so dynamics are already partly learned. The practical consequences are that WAMs can extract signal from varied interaction data rather than near-identical demos, and that they typically cost roughly an order of magnitude more compute to adapt.

Does Cosmos 3 run on a Jetson?

Yes. The 4B Cosmos3-Edge-Policy-DROID runs directly on NVIDIA Jetson Thor, operating at 640×360 observation resolution and generating 32 actions per inference while achieving real-time control at 15 Hz. It is also supported on the new Jetson T2000 and T3000 modules and across RTX PRO, DGX and GeForce RTX hardware. The 16B Nano policy is served off-robot on a single RTX PRO 6000 instead.

Is FastWAM a joint-prediction or representation-only model?

Both descriptions appear in the literature, and the distinction is by convention drawn at inference. FastWAM trains a roughly 5B video-generation expert jointly with a compact action expert, so its training objective is joint. At inference it skips the dreaming and directly denoises action chunks, which makes it representation-only by the formulation axis NVIDIA uses. Its published classification is representation-only.

Are world action models actually better than VLAs?

The evidence is suggestive, not settled. The one controlled comparison — identical recipe, data and compute, base checkpoint versus omni checkpoint — raised RoboLab success from 28.1% to 36.8%. The widely quoted DreamZero 1750 versus Pi-0.5 1622 figure is an April 2026 RoboArena leaderboard standing, not a head-to-head. Most other published numbers are single-vendor reports on different benchmarks with different backbones.

What hardware do I need to try one?

It depends entirely on the formulation. VLA-JEPA needs whatever runs a Qwen3-VL-2B VLA, because the world model is removed before deployment. LingBot-VA needs a single 24–32 GB GPU. FastWAM’s lerobot/fastwam_base is a 6B checkpoint. Cosmos 3 policies need a Jetson Thor for the 4B edge version or a single RTX PRO 6000 for the 16B off-robot version.

Further Reading

• VLA models compared: GR00T, Gemini Robotics and Pi-0 — the VLA baseline this architecture class is measured against.
• NVIDIA Isaac GR00T N1.5 vs Cosmos robot foundation models — how the GR00T and Cosmos lines diverged before Cosmos 3.
• LeRobot dataset v3: chunked Parquet and streaming robot data — the format every recipe here assumes.
• Diffusion policy for robot manipulation and imitation learning — the denoising action-head lineage shared by all of these models.
• Beyond VLAs: How World Action Models Reshape Robot Manipulation — NVIDIA’s Cosmos 3 policy announcement and deployment figures.
• World-Action Models for Robot Learning and Control: A Survey — the academic taxonomy, independent of any vendor.

By Riju — about