OpenVLA vs pi0 vs SmolVLA vs GR00T: Which VLA to Fine-Tune

OpenVLA (arXiv:2406.09246) is a 7B model built on a Prismatic vision language backbone, pretrained on 970,000 real robot demonstrations drawn from Open X-Embodiment. Its headline result is a parameter efficiency argument: 16.5 points of absolute improvement over RT-2-X across 29 tasks, against a model with 55B parameters, and 20.4 points over a diffusion policy baseline. Pretraining cost 64 A100s for 15 days, which is the number that tells you this is a checkpoint you fine-tune, not one you reproduce.

pi0 (arXiv:2410.24164) is 3.3B total: a 3B PaliGemma vision language model with a 300M action expert attached, trained with flow matching to emit an action chunk of 50 steps at up to 50 Hz. Its pretraining mix is over 10,000 hours across 7 robot configurations and 68 tasks. The open implementation, openpi, is Apache-2.0 and ships from main with no tagged releases, so you pin a commit hash or you have no version to cite.

SmolVLA (arXiv:2506.01844) is 450M parameters, pretrained on 487 community-contributed datasets totalling roughly 10 million frames and fewer than 30,000 episodes. That corpus is smaller than any of the others by a wide margin, and it is entirely community data rather than lab data. On real SO-100 hardware it reports 51.7% success without pretraining and 78.3% with it.

GR00T N1 (arXiv:2503.14734) is the dual system design: the paper's GR00T-N1-2B checkpoint carries 2.2B parameters, of which 1.34B is an Eagle-2 vision language model, with a diffusion transformer action head on top and an action horizon of 16. At 100 demonstrations per task it reports 32.1% on RoboCasa, 66.5% on DexMimicGen, 50.0% on GR-1 Tabletop and a 76.8% average across its real-world evaluation. The repository has since moved on, shipping a 3B checkpoint at the n1.7 release tag with the action horizon widened from 16 to 40, so the paper's benchmark table is not a property of what you download today.

On a fine-tuning corpus of a few hundred episodes from one embodiment you are not training capacity, you are measuring how much of a pretraining prior survives the transfer to your gripper, your camera placement and your lighting. Two published results make the point. OpenVLA at 7B beat a 55B model by 16.5 points, so parameter count was not the deciding variable even at that scale. SmolVLA moved 26.6 points, from 51.7% to 78.3% on the same real hardware, purely by adding pretraining while holding 450M fixed.

The corollary is uncomfortable for anyone provisioning around the largest model they can afford. If the prior is what transfers, the question is which pretraining mixture looks most like your robot: SmolVLA's is community arms, mostly SO-100 class, pi0's is 7 robot configurations of real manipulation hours, GR00T's is real, simulated and human video across embodiments including humanoids. A 450M model pretrained on hardware identical to yours will often beat a 7B model pretrained on hardware that is not.

Each stack has a training format it ingests without argument, and the gap between that and your raw capture is real engineering nobody puts in the comparison.

Three of the four converge on LeRobot, the most useful fact here for anyone still choosing a working format. LeRobot is Apache-2.0 and at v0.6.1 as of early August 2026. If your corpus is already there, two of the four models need no conversion at all and a third needs a metadata file describing which state and action keys mean what.

GR00T's extra file is small but load bearing. meta/modality.json maps your state and action vector slices onto named modalities, and an EmbodimentTag tells the model which embodiment head to use at fine-tune and inference time. That is the mechanism that lets one checkpoint serve several robot morphologies, and it is also a place where a silent misconfiguration produces a policy that trains cleanly and moves the wrong joint. One level up sits the question those slices answer, since choosing between a joint-space and an end-effector action space sets what the numbers in the action column are supposed to command and what each shipped checkpoint already expects.

OpenVLA is the outlier, and the RLDS requirement is a genuine tax rather than a preference. You end up owning an RLDS builder, and that script becomes part of your reproducibility surface: it has to be versioned, and the corpus has to be regenerable from raw at any point. The trade-offs across the three formats are in LeRobot vs RLDS vs HDF5 for robot data, and the principle that survives every one of these stacks is that the pipeline is the asset, not its output.

Here are the floors each project documents, not community folklore.

The spread between the cheapest documented LoRA path (above 22.5 GB on a consumer card, openpi) and the most expensive documented full fine-tune (a node of eight A100s, OpenVLA) is not a tuning detail, it is a procurement decision. Note also that LeRobot publishes no VRAM number for SmolVLA. Figures circulate, but they are community reports, so plan against what the project does document: 20,000 steps in roughly 4 hours on a single A100 at batch size 64.

pip install -e ".[smolvla]"

lerobot-train \
  --policy.path=lerobot/smolvla_base \
  --dataset.repo_id=${HF_USER}/mydataset \
  --batch_size=64 \
  --steps=20000 \
  --output_dir=outputs/train/my_smolvla \
  --job_name=my_smolvla_training \
  --policy.device=cuda \
  --wandb.enable=true

Set --wandb.enable=false on any machine inside a controlled perimeter. That flag is the difference between a local training run and one that ships metrics, config and run metadata to a third party by default.

On LoRA versus full, OpenVLA's paper is the useful data point across all four: LoRA updates 1.4% of parameters and matches full fine-tuning on their evaluation. That is the same result the text model ecosystem converged on, and the practical guidance transfers directly from Unsloth vs Axolotl vs LLaMA-Factory vs TRL: start with LoRA, prove the task is learnable, and only reach for a full fine-tune when you have evidence that the adapter is the constraint. Start full and you will spend a node of A100s to discover a data problem.

LeRobot's SmolVLA documentation is the most concrete published guidance of the four, and it is specific in the right way. It recommends about 50 episodes of your task as a starting point. Its reference dataset is 50 episodes across 5 distinct cube positions, 10 episodes per position. And it states that a similar dataset with 25 episodes was not enough and led to bad performance.

Read the structure rather than the total. The 50 is 5 variations repeated 10 times, and the documentation attributes the generalization to that repetition. GR00T's benchmark numbers sit at 100 demonstrations per task, the same order of magnitude and the same shape of claim. Neither pi0 nor OpenVLA publishes a starting point for a new embodiment.

None of this changes the underlying finding that episode count is the wrong unit. The published scaling work on imitation learning shows distinct environment and object pairs improving generalization on a power law while demonstrations per pair saturate past a threshold, which is why 1,600 well-spread episodes can reach roughly 90% success on unseen objects in unseen environments. We work through those bands in how much data you need to train a robot policy, and where the episodes should come from in teleoperation vs simulation vs human video. The same instinct applies here as on the text side, where practitioners consistently over-order examples and under-order coverage, as in how much data to fine-tune an LLM.

Practical consequence for model selection: if you have 50 episodes, the only recipe among these four with a documented result at that scale is SmolVLA. Fine-tune it first as your control, not because it will win, but because it tells you within four hours whether your data is the problem, and if that first run evaluates at 0% success, work through the checks to run before blaming the model.

This is the section that decides whether any of this reaches production in a regulated environment, and it is the one most comparisons skip entirely.

Take the OpenVLA row seriously. The checkpoint's model card carries an MIT tag and states that all OpenVLA checkpoints and the training codebase are MIT. The repository README says pretrained models inherit restrictions from their base models and points at the Llama Community License, which follows from the checkpoint being finetuned from a Prismatic VLM whose language model is Llama-2. Both statements come from the project. A procurement reviewer reading only the model card will approve an MIT component; a reviewer reading the repository will not. That discrepancy is something to put in front of counsel before you make it the foundation of a product, not after.

GR00T's split is cleaner but not simpler: Apache 2.0 on the code, NVIDIA Open Model License on the weights. It is not an OSI approved licence, so an approval process that pattern matches on "Apache-2.0, cleared" waves through something it never assessed.

The other thing an air-gapped deployment changes is distribution. openpi's base checkpoints are addressed as gs://openpi-assets/checkpoints/pi0_base and pi05_base, not as a model hub entry with a card, a licence tag and a revision hash. Fine for a lab, awkward where every artifact needs a provenance record.

# what a controlled deployment pins, per model
openpi        commit sha (no tags exist) + mirrored gs:// checkpoint, sha256 recorded
smolvla       lerobot==0.6.1 + checkpoint revision hash from the hub
gr00t         repo tag n1.7-release + weights under NVIDIA Open Model License
openvla       repo commit + RLDS builder script version + base model licence answer

Mirror the weights into your own registry once, record the digest, and never let a training job resolve a checkpoint over the internet at run time. The general trade-offs of keeping the whole stack inside the perimeter are in cloud vs on-premise AI: security and cost, and for robot policies the argument is stronger than usual, because the training corpus is video of your factory floor.

Policy quality and throughput are separable, and the second one is often the cheaper fix.

GR00T's asymmetry is the design pattern worth stealing: a slow semantic backbone at 10 Hz feeding a fast action head at 120 Hz, with an execution horizon deciding how many of the predicted actions actually run before the next policy call. Widen the execution horizon and you make fewer expensive calls; widen it too far and the policy acts on a stale view of the world.

SmolVLA's asynchronous inference is the clearest published measurement of what that lever is worth. Same task, same policy: 9.7 seconds asynchronously against 13.75 seconds synchronously, and 19 cubes handled against 9 in a fixed time window, at roughly 78% success in both modes. Success rate held while throughput roughly doubled. Nothing about the policy changed, only when the next chunk was computed relative to when the current one was executing.

In LeRobot the lever is split across two processes, a policy server and a robot client, and it is exposed as two flags on the client rather than as anything inside the policy:

python -m lerobot.async_inference.robot_client \
    --server_address=127.0.0.1:8080 \
    --robot.type=so100_follower \
    --policy_type=smolvla \
    --pretrained_name_or_path=user/model \
    --actions_per_chunk=50 \
    --chunk_size_threshold=0.5 \
    --aggregate_fn_name=weighted_average

actions_per_chunk is how many actions the policy emits per call, typically 10 to 50. chunk_size_threshold is the fraction of the queue remaining when the client sends the next observation, so 0.5 means the next chunk is requested while half the current one is still executing. That overlap is the entire trick: lower the threshold and you make fewer, later calls at the cost of acting on a staler observation, raise it and you pay for more inference to stay current. Tune those two before you conclude a policy is too slow for your control rate.

OpenVLA sits at the other end, decoding autoregressively with one token per action dimension and no chunk at all, which is why the follow-on literature on faster action tokenizers exists. If control rate is a hard requirement, that architectural fact outweighs any benchmark table.

The pattern across the table: two constraints, format and licence, eliminate more candidates than any capability argument does, and they are both knowable before you download a single weight file. The rest is a memory floor you can read off each project's documentation. Our wider view of this stack sits on the physical AI pillar.

This week, do the cheap thing. Take 50 episodes you already have, confirm they cover at least 5 distinct variations rather than 50 repeats of one, put them in LeRobot format, and run the 20,000 step SmolVLA fine-tune. Four hours on one GPU gives you a control result, and every larger model you evaluate afterwards has to beat it to justify its memory floor, its conversion script and its licence review.