Three ways a policy can produce numbers
| How the actions are produced | Model here | Cost per action step |
|---|---|---|
| One forward pass, regressed directly | ACT | about 20 ms |
| Iterative refinement with a diffusion action head | GR00T N1.7 | about 152 ms |
| Iterative refinement along a learned velocity field | Pi0.5 | about 485 ms |
The ordering in that table is not a coincidence. Refinement means running the action head several times for every chunk the arm receives, so the method that produces the most carefully shaped trajectories is also the one that makes the arm wait longest between decisions.
What a continuous output buys on a servo bus
Two properties matter once the gripper is close to the object. There is no quantization floor under the commanded trajectory, so the arm can ease into contact instead of stepping between fixed positions, which on hardware with no force sensing is the difference between seating a part and bouncing off it. And refinement can carry more than one answer, so if your demonstrations approached from the left half the time and from the right the other half, those survive as two modes instead of collapsing into a straight-ahead average that knocks the object over.
Batch size 1 with 16 gradient accumulation steps, learning rate 5e-5, 30,000 steps, on an 80 GB card. The effective batch is 16, and a long schedule at a low rate is what a small batch needs. Expect a slow run in wall-clock terms even though the step count sits between SmolVLA and ACT.
Flow matching earns its latency when the last few millimeters decide the outcome and the motion is deliberate anyway: inserting, stacking, seating, closing a latch. It is the wrong trade for fast pick and place, where a comparable result is available at roughly a third of the time per action step. /policies/pi0-5 has the full treatment, and /train/pi0-5-on-so-100 is the run itself.