I Ran a 100-Step OpenVLA LoRA Fine-Tune on Colab. Here's What I Learned

A reproducible 100-step OpenVLA LoRA fine-tune on Colab shows how to verify a robot AI training run actually works before scaling it up.

axonn bots
axonn bots
·3 min read
The author ran a small, reproducible 100-step LoRA fine-tune of the OpenVLA-7B robot vision-language-action model on Google Colab, using the LIBERO spatial benchmark dataset, specifically to verify that the training pipeline itself works correctly rather than to measure task performance. Training loss, action error, and action-token accuracy all moved in the expected direction over the 100 steps, and GPU telemetry confirmed real sustained compute during the run. The piece stresses that a short LoRA run like this proves the pipeline is wired correctly, not that the resulting policy is ready for simulation or real-robot deployment, positioning it as a verifiable first step before scaling to longer training.

Fine-tuning a large vision-language-action model sounds expensive, fragile, and hard to verify from the outside. I wanted a smaller, honest test of that assumption: could I run a real OpenVLA LoRA fine-tune inside a single Colab notebook, confirm the dataset actually loaded correctly, prove the GPU did genuine training work, and leave behind evidence someone else could inspect rather than just take my word for it.

OpenVLA is a 7-billion-parameter open-source vision-language-action model trained on roughly 970,000 real-world robot demonstrations, according to its release paper. Given an image from a robot's camera and a natural-language instruction like putting a cup on a plate, it predicts the next action the robot should take, represented as a normalized seven-value command covering position, orientation, and gripper state.

Rather than fine-tuning the full 7-billion-parameter model, I used Low-Rank Adaptation, which trains a small set of new adapter weights while leaving most of the original checkpoint frozen. OpenVLA's own reported experiments found LoRA matched full fine-tuning performance while updating only about 1.4 percent of the parameters, which made it a practical choice for keeping the whole experiment inside one notebook session on an A100 High-RAM Colab runtime.

For training data I used the libero_spatial_no_noops split of the LIBERO benchmark, stored in Robot Learning Dataset Standard format, which captures each demonstration episode as a sequence of camera observations, a language instruction, and 7-DoF actions. The spatial split specifically tests whether a robot can correctly follow spatial relationships between objects, such as moving one item relative to another.

The run itself was intentionally conservative: LoRA rank 32, a learning rate of 0.0005, a small physical batch size of 2 with gradient accumulation bringing the effective batch size to 16, and only 100 training steps, enough to confirm the pipeline works end to end rather than to produce a deployable policy. Metrics were logged to Weights & Biases, first offline within the OpenVLA training environment, then synced afterward through a separate environment to avoid dependency conflicts with the authentication library.

The results were a genuine, if modest, learning signal. Training loss dropped sharply in the first ten steps before stabilizing between roughly 3.2 and 3.6. The L1 action loss, which measures how far predicted continuous actions land from the demonstrated ones, fell from about 0.46 at the start to a range around 0.18 to 0.29. Action-token accuracy, meaning how often the model's predicted action tokens matched the demonstrated ones exactly, climbed from around 9 percent at the outset to a peak near 35 percent around step 90. System telemetry showed sustained GPU power draw in the 165 to 195 watt range throughout training, confirming the notebook was doing real compute rather than idling.

I want to be clear about what this run does and does not prove. A 100-step LoRA fine-tune tells you nothing about whether the resulting policy would succeed at the task in simulation or on a real robot; that would require held-out rollouts or physical evaluation. What it does prove is that the training path itself is wired correctly: the right dataset loads, the official fine-tuning script runs without silent failures, the adapter actually updates, the GPU does verifiable work, and the resulting metrics survive being inspected outside the notebook.

That distinction matters more than it might sound. Before committing to a longer, more expensive training and evaluation cycle, having a compact, reproducible, and honestly-scoped baseline is what lets you trust the next, bigger step is built on something real.