Why steps and not epochs
An epoch is one pass over the dataset, which makes it a moving target: an epoch on 40 episodes and an epoch on 400 are different amounts of work, so two runs described in epochs are comparable in neither learning nor cost. A step is the same size in both cases. Since the GPU is rented by the hour, a step count is also a budget, which is why the training form asks for one. The flag is --steps for the lerobot family and --max-steps for GR00T, and no CLI command starts a run: training happens in the dashboard under Training or through the start_training tool on the MCP server.
Effective batch, and the two models where accumulation counts
Batch size is how many samples fit on the card at once. Gradient accumulation is how many of those batches are summed before the optimizer takes a single step, and where it is in force the product of the two is the effective batch, bought without buying VRAM and paid for with a longer wall-clock step.
On this platform it is in force for exactly two of the five models. Only the GR00T trainers accept an accumulation value; ACT, SmolVLA and Pi0.5 run through lerobot 0.5.1, which has no such setting, so the training form grays the field out for them and marks it as GR00T only. For those three the effective batch is simply the batch size, and the multiplication below has no second factor to apply.
| Model | Batch | Accumulation | Effective batch | Steps | Sample presentations |
|---|---|---|---|---|---|
| ACT | 8 | Not available | 8 | 100,000 | 800,000 |
| SmolVLA | 2 | Not available | 2 | 20,000 | 40,000 |
| GR00T N1.7 | 32 | 1 | 32 | 20,000 | 640,000 |
| GR00T N1.5 | 1 | 16 | 16 | 2,000 | 32,000 |
| Pi0.5 | 1 | Not available | 1 | 30,000 | 30,000 |
The form still shows a number in the disabled field, 8 for SmolVLA and 16 for Pi0.5, and that number is stored with the job. So a recipe copied out of the form can look like it adds up to an effective batch of 16 when the run never had one. Take the accumulation column above rather than the field.
The last column does not move when your dataset grows. Double the episodes and each one is seen half as often, which is the usual reason a second, larger dataset trains into a worse policy than the first. Raise the step count roughly in proportion to the extra data.
That also settles what you can do when a run is short of memory. The 24 GB tier holds ACT and SmolVLA, both on lerobot, so there is no accumulation to raise: batch size is the only lever, and lowering it lowers the effective batch with it. On the 80 GB tier the question rarely comes up, since GR00T N1.7 already runs batch 32 and needs no accumulation to do it, which is how a 20,000 step schedule on a 3 billion parameter model finishes in a few hours. If you genuinely need a large effective batch on a small batch size, GR00T is the family that can give you one, and the GR00T N1.5 row above is what that shape looks like.
/learn/train-your-first-policy covers what the loss curve is saying while those steps run, and /train has the per-model walkthroughs with the numbers in context.
Where this term does the explaining: symptoms whose cause sits in exactly what it describes.