Pi0.5 vs SmolVLA: when flow-matching precision pays for the extra hours

How close these two really are

Both are lerobot-family trainers, so both expose seed and logFreq and both start from a LeRobot v3.0 upload. Both are language conditioned. And, less obviously, both inherit the same limitation from that shared trainer: lerobot 0.5.1 has no gradient accumulation control, so the field is grayed out in the training form for both and the numbers it proposes, 8 for SmolVLA and 16 for Pi0.5, never reach the run. Their effective batches are therefore 2 and 1, the two smallest in the catalog, and neither can be raised by anything except the batch size itself. What differs is model size, the objective, the card, and the length of the schedule. That short list makes the comparison unusually clean: hold everything else fixed and ask one question, whether flow matching at three billion parameters solves the problem you actually have.

Side by side

The failure taxonomy that decides this

Run twenty attempts with your current SmolVLA policy and sort the failures into the rows below before renting an 80 GB card. Most people who upgrade too early are looking at a data problem and hoping a bigger model absorbs it. It will not, and the run costs four times as much to say so.

Only the last two rows are Pi0.5 problems. Flow matching produces smooth, continuous action trajectories instead of discretized jumps, and that difference becomes visible on the final approach, where a small error in the commanded position separates seating a part from pushing it over.

What the upgrade costs you

Two things, and only one is money. The run moves from about 1 to 3 USD to about 4 to 12, and from a two to five hour estimate to a three to six hour one. You pay the 80 GB rate for every hour of it while presenting the model one sample per optimizer step, and the accumulation field that would normally soften that is disabled on this trainer. The other cost is permanent: 485 ms against 245 ms means the loop closes roughly twice a second instead of four times. On a deliberate task that is invisible. Where the object can shift after contact, you can spend part of the precision you bought on reacting late.

                SmolVLA        Pi0.5
  batch                 2            1
  gradient accum  8, ignored  16, ignored
  effective batch       2            1
  learning rate      1e-4         5e-5
  steps            20 000       30 000
  seed              set it       set it
  logFreq           set it       set it
  GPU tier           24 GB        80 GB

Sample views: 20 000 x 2 = 40 000 for SmolVLA against
30 000 x 1 = 30 000 for Pi0.5, on a model roughly six times larger.

Pick SmolVLA if

• You are on your first or second pass over a dataset. A 450 million parameter model is perfectly capable of telling you your episodes are inconsistent, and it does so for a couple of dollars.
• The task involves motion the arm must keep up with: something rolling, something handed over, anything where half a second of staleness becomes a miss.
• You want the policy on your own hardware. SmolVLA fits a 24 GB card outside the cloud pool; Pi0.5 does not.

Pick Pi0.5 if

• Your task is an insertion, a stack, a lid or a connector. These are the tasks where the last centimeters carry all the difficulty.
• You have fifty or more episodes and a SmolVLA policy that already gets to the right place. Upgrading a policy that works is a different proposition from upgrading one that does not.
• The motion is quasi-static. If the scene holds still until the gripper touches it, 485 ms costs only evaluation patience and the precision comes free.

What SmolVLA still does better, even after you upgrade

Keep it rather than retiring it. Once Pi0.5 is your production policy, the question you ask most often is not whether the architecture is right but whether the episodes you recorded this week are consistent with the ones you had. A SmolVLA run answers that in two to five hours on the same dataset id, which makes it a cheap regression check rather than a second project. It is also the model you can hand to a colleague without a budget conversation.

The upgrade, in order

1. 1
   Establish the SmolVLA baseline properly

   Defaults, a fixed seed, twenty evaluation attempts written down. Without a baseline you cannot tell an improvement from a different random outcome.

2. 2
   Sort the failures into the taxonomy above

   Count contact failures against everything else. If contact failures are the minority, stop and record data for the majority.

3. 3
   Get to fifty episodes if you are not there

   Pi0.5 becomes useful at around fifty, twenty above SmolVLA’s threshold. Running it on thirty is paying the 80 GB rate for a comparison that will not mean much.

4. 4
   Start Pi0.5 on the same dataset id

   Select Pi0.5 in Training, leave 30 000 steps and 5e-5 alone, and set the same seed you used for SmolVLA.

5. 5
   Re-run the identical evaluation

   Same placements, same order, same lighting. Compare contact failures specifically. If those did not drop, the upgrade did not do the job you bought it for.

The dataset is what you actually own

A checkpoint is the output of a few rented hours. Your episodes are hours of your own time and they outlive every model in this catalog. Because both trainers read LeRobot v2.x and v3.0, moving between them never touches the data: the second job takes the same dataset id and the same task strings, and the first checkpoint stays available for comparison. Plan spending around recording sessions and treat every training run as an experiment you are allowed to discard.

Where to go next

• /policies/pi0-5: flow matching, defaults, and the documented limits
• /policies/smolvla: the 24 GB starting point
• /train/pi0-5-on-so-100: the upgrade run in full
• /train/smolvla-on-so-100: the baseline run in full
• /learn/run-your-first-policy for the evaluation protocol used above

Frequently asked questions