VLA Models Compared: GR00T, Gemini Robotics, Pi0 (2026)
Three robot foundation models now dominate serious engineering conversations, and this VLA model comparison cuts through the hype to show what each one actually is under the hood. NVIDIA’s Isaac GR00T (N1, N1.5, N1.6), Google DeepMind’s Gemini Robotics (including the June 2025 on-device variant), and Physical Intelligence’s π0 — hereafter Pi0 — each makes a credible claim to being a general-purpose robot brain. But they differ sharply in openness, action-generation mechanism, hardware assumptions, and how much Google-shaped infrastructure they require. This post works through architecture first, then deployment realities, and lands on a clear decision framework. The central argument is that the real dividing line is not capability but control: open-and-customizable (GR00T, Pi0) versus integrated-and-managed (Gemini Robotics), and that on-device latency is the axis that forces the choice for any robot that moves in the physical world.
What this covers: a technical architecture walkthrough of all three model families; a side-by-side decision matrix; deployment trade-offs including on-device vs. cloud inference paths; an honest look at where each model breaks down; and practical guidance for teams choosing between them in 2026.
The 2026 VLA Landscape: What Changed and Why It Matters
The term vision-language-action model describes a neural architecture that takes raw visual observations and natural-language task instructions as input and outputs low-level robot actions — joint angles, end-effector poses, gripper commands — without a hand-written intermediate symbolic layer. The concept descends from Google’s RT-2 (2023), which showed that a VLM backbone fine-tuned on robot trajectories could transfer web-scale language and visual knowledge into manipulation policies. What has changed between 2023 and mid-2026 is the sophistication of the action head, the scale and diversity of training data, and — crucially — the emergence of on-device variants capable of running inference on robot-embedded compute rather than a remote data centre.
The 2026 landscape is shaped by three structural forces. First, diffusion and flow-matching action heads have largely displaced the naive next-token-prediction approach for continuous motor commands, because tokenizing joint angles into discrete bins throws away resolution and introduces latency spikes. Second, synthetic data from GPU-accelerated simulation (NVIDIA Isaac Lab, MuJoCo) has made it economically viable to pre-train on billions of robot-hours that no physical fleet could generate. Third, the open-versus-closed split has hardened: some labs publish weights and training code; others deliver a fine-tuning API and keep the full model proprietary. Each choice has downstream consequences for teams that need to modify, debug, or run models on hardware they control.
For a broader foundation-model-in-robotics overview, see our post on foundation models and industrial robotics in 2026 and the companion piece on physical AI and vision-language-action models in robotics.
The Comparison: Decision Matrix and Architecture Overview
The table below maps the three model families across the axes that matter most for deployment decisions. Numbers are cited where attributable; qualitative descriptors are used where comparable benchmarks do not yet exist across all three models.
| Dimension | GR00T N1 / N1.5 / N1.6 | Gemini Robotics | Pi0 / Pi0.5 |
|---|---|---|---|
| VLM Backbone | Eagle-2 VLM (NVIDIA) | Gemini multimodal LLM (Google) | PaliGemma 3B (Google, open weights) |
| Action Head | Diffusion Transformer (DiT) with flow matching | Autoregressive token prediction | Flow matching via action-expert Gemma 300M |
| Dual-Expert Architecture | System 1 (DiT) + System 2 (VLM reasoning) | Unified VLM with action tokens | VLM expert + action expert sharing attention |
| Training Data Mix | Real robot trajectories, human videos, Isaac Lab synthetic data | Real robot trajectories + Gemini web-scale pre-training | Cross-embodiment robot data via openpi |
| Open Weights | Yes — Apache 2.0 on Hugging Face | No — fine-tune API access only (On-Device model is the first available for fine-tuning) | Yes — openpi on GitHub, Apache 2.0 |
| On-Device Capable | Roadmapped for Jetson Thor; N1 variants runnable on Jetson Orin with tuning | Gemini Robotics On-Device (June 2025) explicitly designed for local inference | Runs on moderate GPU; Pi0.5 improved generalisation; no dedicated on-device variant announced |
| Fine-Tuning Data Needed | Works with existing LEROBOT-format datasets; FLARE post-training on human videos | As few as 50–100 demonstrations (On-Device model) | Demonstrated with small demonstration sets via openpi recipes |
| Primary Target Embodiment | Humanoid robots | General manipulation; tested on dexterous tasks | General manipulation; cross-embodiment |
| Ecosystem Lock-in | NVIDIA Isaac stack (Isaac Lab, Jetson Thor, Cosmos) | Google Cloud / DeepMind API | Minimal; PyTorch, runs on commodity hardware |
| Commercial Licence | Apache 2.0 (open) | Proprietary API terms | Apache 2.0 (open) |
Figure 1: The canonical VLA architecture. Camera frames and language instructions feed a shared VLM backbone; the action head — diffusion transformer or autoregressive — converts latent representations into motor commands that close the sensorimotor loop.
The decision matrix makes one structural divide immediately visible: GR00T and Pi0 ship open weights under permissive licences, while Gemini Robotics is proprietary (the On-Device variant, released June 2025, is the first Gemini Robotics model available for fine-tuning, but the weights themselves are not published openly). This is not a criticism — Google DeepMind’s integration with the broader Gemini ecosystem and its MuJoCo simulation SDK deliver real value — but it means the choice involves more than raw performance.
The second visible divide is on the action-generation mechanism. GR00T and Pi0 both use flow matching; Gemini Robotics uses autoregressive token prediction over a discretised action space. These choices have engineering consequences that run through the rest of this post.
Figure 2: Architecture comparison across GR00T (Eagle VLM + DiT flow matching), Gemini Robotics (Gemini VLM + autoregressive action tokens), and Pi0 (PaliGemma VLM expert + action-expert Gemma sharing attention layers with flow matching output).
How Each Model Is Built: A Deeper Walk-Through
GR00T N1, N1.5, and N1.6
NVIDIA’s GR00T family is structured around a dual-system design that explicitly mirrors the fast-and-slow thinking dichotomy from cognitive science. System 2 is the reasoning layer: an Eagle-2 VLM that ingests camera frames and language instructions, converts them into a token sequence, and produces a high-level situational representation. System 1 is the action layer: a Diffusion Transformer (DiT) module that receives the VLM outputs together with robot state tokens and current action encodings, then iteratively denoises a noisy action vector using a flow-matching objective to produce smooth motor commands. Both systems are trained end-to-end jointly, meaning the VLM backbone is not frozen — its representations are shaped by the downstream action-generation loss.
The GR00T N1 paper (arXiv:2503.14734, March 2025) introduced this architecture and described training on a heterogeneous mixture of real robot trajectories, human video demonstrations, and synthetically generated datasets from Isaac Lab. N1.5 followed with FLARE (Flow-matching with Language-Aligned Robot Embeddings) post-training, a technique that introduces action prediction and implicit world modelling objectives applied to human video data containing novel objects. FLARE measurably improved language grounding and generalisation — though NVIDIA reported success rates in qualitative terms rather than publishing a single standardised benchmark number that holds across all tasks, so direct numerical comparisons should be treated with caution. N1.6 refined the MLP connector between the VLM features and the DiT module, and was trained jointly with both flow matching and world-modelling objectives, improving performance on simulation benchmarks according to NVIDIA’s research page.
Weights for GR00T N1, N1.5, and N1.6 are released on Hugging Face under Apache 2.0 (nvidia/GR00T-N1.6-3B is the current canonical checkpoint). The model is designed for humanoid robot embodiments — bipeds with dexterous hands — which is reflected in training data composition and the default action space. Teams working with other morphologies (six-DoF industrial arms, mobile manipulators) need to invest in fine-tuning with embodiment-specific data. Deployment targets include the upcoming NVIDIA Jetson Thor robot computer, though as of mid-2026 production availability of that board has not been widely confirmed — teams currently run smaller GR00T variants on Jetson AGX Orin.
The full Isaac ecosystem context — including how GR00T fits alongside Cosmos world models and Isaac Lab simulation — is covered in depth in our post on NVIDIA Isaac GR00T N1.5 vs Cosmos robot foundation models.
Gemini Robotics and Gemini Robotics On-Device
Google DeepMind announced Gemini Robotics in March 2025 as the robotics application of the Gemini multimodal model family, and released Gemini Robotics On-Device in June 2025. The two variants differ primarily in where inference runs.
The standard Gemini Robotics model runs against DeepMind’s cloud infrastructure. It uses the full Gemini VLM as its language and vision backbone — a model pre-trained on Google’s web-scale multimodal corpus — and generates robot actions as a sequence of discrete tokens from an autoregressive head. This approach benefits from extremely strong semantic grounding: the model can reason about object relationships, parse complex natural-language instructions, and generalise to visual scenarios far outside any robot training distribution, because the backbone has seen an enormous breadth of web imagery and text. The cost is inference latency inherent to remote API calls and the granularity limitations of tokenising a continuous action space.
Gemini Robotics On-Device is architecturally optimised to run locally on robotic hardware, ensuring robust performance in environments with limited or absent network connectivity and providing the low-latency inference that closed-loop manipulation requires. It is the first VLA model from the Gemini Robotics family available for fine-tuning, and DeepMind reported adaptation with as few as 50 to 100 demonstrations — a practically important number for teams that cannot collect thousands of labelled trajectories. The Gemini Robotics SDK provides evaluation tooling and integration with the MuJoCo physics simulator, enabling sim-to-real workflows without requiring NVIDIA’s Isaac stack.
Tested on seven dexterous manipulation tasks including zipping a lunchbox, drawing a card, and pouring salad dressing, Gemini Robotics On-Device showed strong performance on fine-motor operations — but the benchmarks are DeepMind-defined and not yet replicated independently, so extrapolation to arbitrary manipulation tasks should proceed carefully. Weights are not published openly; access is through Google’s API or SDK partner programme. This is a deliberate product choice, not an oversight: Google’s competitive position is partly in the managed-service model, where customers fine-tune against an endpoint rather than deploying raw model files.
Pi0 and the OpenPi Ecosystem
Physical Intelligence’s Pi0 (π0) is architecturally the most elegant of the three in the sense that its dual-expert design is the cleanest expression of the separation between language understanding and motor generation. The VLM expert is PaliGemma — Google’s open-weights 3B VLM built on the Gemma 2B language model and a SigLIP vision encoder — fine-tuned for robot observation understanding. The action expert is a smaller Gemma 300M model. Crucially, these two experts share self-attention layers but use separate feed-forward weights, making the combined architecture function like a mixture-of-experts transformer: the same attention computation propagates context across both language-image tokens and action tokens, while the feed-forward paths specialise independently. The action output is generated with a flow-matching objective over action chunks, meaning Pi0 predicts a short horizon of future actions simultaneously rather than one token at a time.
Flow matching — specifically a continuous normalising flow formulation — maps Gaussian noise to action trajectories by learning a velocity field that transports the noise distribution to the data distribution. This is closely related to diffusion but typically requires fewer denoising steps to achieve high-quality samples, which matters for real-time robot control where inference budget is measured in milliseconds. Physical Intelligence released the openpi repository (Apache 2.0) with model weights, training recipes, and the LEROBOT-compatible data pipeline, making Pi0 one of the most practically accessible models in this comparison.
Pi0.5, released in September 2025, improved open-world generalisation — the capacity to handle objects and environments not seen during pre-training — by augmenting training with a broader distribution of real-world demonstration data. The Multi-Scale Embodied Memory (MEM) work published in March 2026 extends the Pi0 line with long-term and short-term memory modules, enabling tasks that span more than ten minutes of continuous operation. This is architecturally significant: vanilla transformer-based VLAs reset context at episode boundaries, while MEM maintains a compressed episodic store, opening the door to task sequences that require referencing earlier observations.
Pi0’s Achilles heel is that it was originally designed for manipulation tasks on a fixed set of embodiments, and cross-embodiment generalisation — while improving — still requires non-trivial fine-tuning when moving to substantially different robot morphologies. The openpi tooling makes this tractable, but it is not plug-and-play.
Trade-Offs and What Goes Wrong
Understanding where each model fails in practice is as important as knowing where it succeeds. The failure modes cluster around four axes: inference latency under real-world constraints, fine-tuning data economics, embodiment mismatch, and operational control.
Inference latency and on-device viability. This is the axis that decides the most deployments. A cloud-hosted model adds network round-trip latency on top of inference compute time. For pick-and-place tasks with slow dynamics, this is tolerable. For dexterous manipulation — a robot hand executing a complex grasp, a bipedal robot catching itself mid-stumble — control loops typically run at 50 Hz or higher, which means an action must be available within 20 ms. No cloud API reliably delivers that, and wireless link drops are unacceptable mid-task. GR00T is roadmapped for Jetson Thor and already runs on Jetson AGX Orin with reduced parameter counts. Gemini Robotics On-Device addresses this directly with its local-inference design. Pi0 runs on moderate GPU hardware (the openpi repo shows recipes for standard workstation GPUs) but does not have a formally supported edge-compute target yet. Teams optimising Pi0 for on-device deployment need to manage quantisation and serving infrastructure themselves.
Fine-tuning data economics. All three models are generalised foundation models that still require task-specific fine-tuning for reliable production performance on any specific task. The question is how much data is needed. DeepMind’s claim of 50–100 demonstrations for Gemini Robotics On-Device is the most aggressive published figure, and it suggests the model’s pre-training distribution is well-matched to common manipulation tasks. GR00T’s FLARE technique allows post-training from human video (which is far cheaper to collect than robot-labelled trajectories), but the improvement depends on the semantic gap between the human video content and the target task. Pi0 via openpi works well with small demonstration sets in the reported use cases, but generalisation degrades on tasks or embodiments with little coverage in the pre-training corpus. None of these models eliminate the data collection problem — they reduce it, sometimes substantially.
Embodiment mismatch. GR00T is genuinely optimised for humanoid embodiments. Its training data composition, action space definitions, and evaluation benchmarks centre on bipedal robots with multi-fingered hands. Forcing it onto a two-finger parallel-jaw gripper on a fixed six-DoF arm is not impossible — the openpi recipes provide useful analogies — but the out-of-box performance gap is real. Pi0 was designed around manipulation tasks and is more broadly applicable across arm morphologies. Gemini Robotics makes no strong commitments about embodiment; the SDK tests span multiple robot hardware types, but the tested dexterity benchmarks are predominantly manipulation-focused. Teams with non-humanoid fleets considering GR00T should plan for a non-trivial fine-tuning investment.
Operational control and auditability. Open-weights models (GR00T, Pi0) give teams full observability: every layer, every weight, every gradient is inspectable. This matters for safety-critical applications — medical robotics, human-collaborative assembly — where a team may need to verify exactly what the model has learned and guarantee it has not retained training-data artefacts that could produce unexpected behaviour. Proprietary managed models (Gemini Robotics) offer less visibility into the model internals. Google DeepMind provides evaluation tooling and simulator integration, but a team cannot audit the full model weights or training data composition. For regulated industries, this difference alone can be a hard disqualifier for the managed-API approach.
Ecosystem fragility. NVIDIA GR00T is integrated into the Isaac stack — Isaac Lab for simulation, Cosmos for world modelling, Jetson Thor for edge deployment. This integration delivers real workflow benefits, but it also means that teams adopting GR00T are implicitly adopting a significant portion of NVIDIA’s infrastructure roadmap. If Jetson Thor slips, or if Isaac Lab’s sim-to-real gap on a particular task proves hard to close, the whole pipeline is affected. Gemini Robotics similarly carries Google infrastructure dependency. Pi0 via openpi has the lightest ecosystem footprint — PyTorch, standard GPU hardware, MuJoCo or any compatible simulator — which lowers the integration risk at the cost of needing to assemble more of the pipeline yourself.
Practical Recommendations
The framing that clarifies most deployment decisions is this: choose Gemini Robotics if you are building on Google infrastructure, can tolerate the proprietary model boundary, and want the lowest demonstration-to-deployment data requirement; choose GR00T if you are working with humanoid embodiments or deeply integrated into the NVIDIA Isaac ecosystem; and choose Pi0 if you need open weights, cross-embodiment flexibility, and the ability to inspect and modify every component of the model. On-device latency requirements should be assessed first — if your control loop cannot tolerate network round-trips, that immediately narrows the field to on-device-capable options.
Pre-deployment checklist:
- Characterise your control-loop latency budget before evaluating models. Identify whether your task can tolerate API latency or requires on-device inference.
- Map your robot embodiment against each model’s training distribution. Humanoid-optimised models (GR00T) require more fine-tuning work for other morphologies.
- Quantify your demonstration data budget. If you can collect only 50–100 trajectories, Gemini Robotics On-Device’s low-shot adaptation claim is worth testing against your specific task.
- Assess regulatory and auditability requirements. Open weights (GR00T, Pi0) are the only path to full model auditability.
- Evaluate ecosystem fit and lock-in tolerance. GR00T brings NVIDIA Isaac dependencies; Gemini Robotics brings Google Cloud dependencies; Pi0 is the most portable.
- Run sim-to-real gap experiments early. All three models benefit from simulation pre-training, but the gap between simulator and your physical environment is task- and hardware-specific.
- Do not conflate benchmark numbers across different evaluation protocols. Each lab publishes results on its own task suites; cross-model comparisons require common benchmarks that do not yet exist at scale.
Figure 3: Cloud versus on-device inference paths. Cloud routing introduces network latency that is incompatible with high-frequency control loops; on-device inference with quantised or distilled models eliminates the network dependency but requires edge hardware capable of running the model.
Figure 4: A practical decision tree for selecting between GR00T, Gemini Robotics, and Pi0. The primary branch point is whether open weights and full customisation are required; the secondary branch is on-device versus cloud inference; the tertiary branches reflect embodiment type and ecosystem preference.
FAQ
What is a VLA model and how does it differ from a standard robot policy?
A vision-language-action model is a neural network that directly maps visual observations and natural-language instructions to low-level robot action commands, using a large pre-trained VLM as the backbone. A standard robot policy — a trained neural network or a classical controller — typically operates on pre-processed, structured state representations rather than raw images and free-form language. The VLA’s key advantage is that its VLM backbone transfers web-scale semantic knowledge into the policy, enabling generalisation to novel objects and instructions without task-specific engineering of the perception pipeline. The trade-off is significantly higher inference compute and the need to fine-tune on robot demonstration data to close the action-quality gap.
Is GR00T N1.5 better than Pi0 for dexterous manipulation?
That question cannot be answered with a single number because no independent benchmark evaluates both models on a common dexterous manipulation task suite as of mid-2026. NVIDIA and Physical Intelligence each publish results on their own evaluation protocols, which differ in task definition, robot hardware, and success criteria. What can be said is that Pi0’s flow-matching action head is architecturally well-suited to dexterous tasks requiring smooth, continuous trajectories, while GR00T’s dual-system design adds a reasoning layer that may help on tasks requiring multi-step semantic planning. For any specific dexterous task, running both models on your actual hardware with your actual demonstration data is the only reliable evaluation approach.
Can Gemini Robotics On-Device run without internet connectivity?
Yes — that is its explicit design goal. Gemini Robotics On-Device runs locally on robotic hardware, with no network connectivity required at inference time. Google DeepMind released it specifically to address the low-latency and network-reliability requirements of real robot deployments. Fine-tuning and model updates do require connectivity and access to DeepMind’s SDK infrastructure, but once a fine-tuned model is deployed to the device, inference is fully local. The weights, however, are not openly published — the model is distributed through Google’s partner programme rather than as a freely downloadable file.
How much robot demonstration data do I need to fine-tune these models?
The honest answer varies substantially by model and task. Google DeepMind claims Gemini Robotics On-Device can adapt to new tasks with as few as 50 to 100 demonstrations — this is the most aggressive low-shot figure publicly reported. Pi0 via openpi has shown effective adaptation with small demonstration sets in published results, though the number depends heavily on how close the new task is to the pre-training distribution. GR00T with FLARE can leverage human video demonstrations in addition to robot trajectories, which expands the data budget in practical terms. None of these models completely eliminate the demonstration collection requirement, and tasks far outside the pre-training distribution will require substantially more data regardless of the base model.
What hardware do I need to run Pi0 on a physical robot?
Pi0 via the openpi repository runs on standard GPU hardware. The PaliGemma 3B VLM expert plus the Gemma 300M action expert constitute a model in the range of a few billion parameters, which is runnable on a workstation-class GPU. Physical Intelligence has not announced a formally supported edge-compute target equivalent to NVIDIA’s Jetson Thor roadmap. Teams deploying Pi0 on-robot will need to work through quantisation (INT8 or INT4) and model serving to fit within the power and memory envelope of embedded compute. The open-weights nature of the model makes this technically feasible, but it requires engineering investment that the other two models partially abstract away.
Is the autoregressive action head in Gemini Robotics a significant limitation?
It depends on the task dynamics. Autoregressive token prediction over a discretised action space introduces quantisation error relative to the continuous action values that flow-matching models predict. For tasks with slow dynamics and coarse action resolution, this is generally not limiting. For tasks requiring fine motor precision — sub-millimetre positioning, compliant grasping — the discretisation floor matters. Gemini Robotics On-Device’s strong performance on dexterous manipulation tasks (zipping, card drawing, pouring) suggests the discretisation is not a fatal constraint in practice, but independent replication of those results has not yet appeared in the literature. Teams with high-precision requirements should benchmark directly on their specific task rather than relying on reported results.
Further Reading
The three model families sit within a richer context of simulation infrastructure, world models, and foundation-model thinking in robotics. The following resources extend the analysis in this post:
On this site:
– Physical AI and Vision-Language-Action Models in Robotics (2026) — a broader survey of the VLA landscape including RT-2 lineage and embodied AI trends.
– NVIDIA Isaac GR00T N1.5 vs Cosmos: Robot Foundation Models in the Isaac Stack — deep dive into how GR00T fits alongside Cosmos world models and Isaac Lab simulation.
– Foundation Models and Industrial Robotics: State of the Field (2026) — the industrial deployment context, including how foundation models interact with existing automation infrastructure.
Primary sources:
– GR00T N1: An Open Foundation Model for Generalist Humanoid Robots — the NVIDIA GR00T N1 paper (arXiv:2503.14734, March 2025), which describes the dual-system architecture, training data composition, and FLARE post-training technique.
– Gemini Robotics On-Device — Google DeepMind Blog — the official announcement of the on-device variant, describing the low-shot fine-tuning results and SDK tooling.
– Physical Intelligence openpi Repository — the open-source Pi0 implementation, including model weights, training recipes, and data pipeline documentation.
– GR00T N1.6 Research Page — NVIDIA — NVIDIA’s research page for N1.6, describing the architectural refinements and simulation benchmark results.
– GR00T N1.5 Explained — LearnOpenCV — a clear technical walkthrough of the N1.5 architecture and FLARE training methodology.
This post reflects the state of published research and official announcements as of June 2026. The VLA field moves quickly; benchmark results and model capabilities reported here should be verified against the primary sources listed above before making production deployment decisions.
