GR00T N1.5: the previous generation, and when to still use it

Why this page is short

N1.5 and N1.7 are the same family. Same datasets, same form, same class of GPU, same deployment to the arm. Restating all of that would make this look like a decision you should be weighing, and it is not one. What a GR00T fine-tune is and does is explained at /policies/groot-n1-7. This page covers only what differs.

What changed in N1.7

From inside the training form, the differences are the recipe and the measured inference time. The recipe is not cosmetic: it reflects what each checkpoint tolerated when it was integrated into the backend.

The first four rows belong together. N1.5 builds an effective batch of 16 by accumulating sixteen single samples, then stops after 2000 optimizer steps at a tenth of the newer learning rate. N1.7 pushes 32 samples through at once with no accumulation and runs ten times as many steps. Per rented hour, the newer recipe puts far more of your dataset through the model.

Why the N1.5 defaults are so conservative

Batch size 1 with 16 accumulation steps is what you configure when you cannot predict how much memory one forward pass needs and would rather be slow than crash twenty minutes into a paid run. It survives any dataset regardless of how many camera streams the episodes carry. The price is throughput, on a tier that bills by the hour either way.

2000 steps at an effective batch of 16 is also a short schedule for a 50 episode dataset, closer to a smoke test than to a finished fine-tune. That is why an old N1.5 result is not a fair ceiling on what GR00T can do with your data. If you ran N1.5 once, were unimpressed and blamed the dataset, the schedule is the first suspect to eliminate.

The one case where N1.5 is the right choice

You already have a result from an N1.5 run and need a second one comparable to it. That covers more real work than it sounds like: an ablation table in a thesis chapter, a demo trained months ago whose checkpoint needs rebuilding, a regression check against a dataset you have since extended. In each case, swapping the model changes the thing you are measuring.

Everything else is N1.7, including the instinct that the old one worked so why risk it. The risk runs the other way: the same hourly rate buys the weaker checkpoint and a schedule that sees a fraction of your data.

Reproducing an older N1.5 run

1. 1
   Read the original job, do not trust your memory

   Open Training and find the finished run in the job list. Its page holds the dataset, the model, the step count and the hyperparameters actually used, usually the only reliable copy of that.

2. 2
   Train on the same dataset, not a newer version of it

   If you added episodes since, that is a different experiment with two variables moving. Use the dataset the original run used, or state plainly that both changed.

3. 3
   Copy steps, learning rate and accumulation across

   Type the numbers from the old job into the form instead of accepting the defaults, which describe a fresh run rather than the one you are matching.

4. 4
   Match saveSteps as well

   Checkpoint spacing decides which intermediate weights exist to compare. If the earlier result came from a mid-training checkpoint, you need one at the same step.

5. 5
   Expect a close match, not an identical one

   The GR00T fine-tune entry point takes no seed, on N1.5 exactly as on N1.7, so data order and head initialization differ between runs. Compare success rates from the same evaluation protocol, not weights.

curl -X POST https://www.ay-robots.com/api/mcp \
  -H "Authorization: Bearer $AY_ROBOTS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "get_training_job",
      "arguments": { "job_id": "job_5c19be" }
    }
  }'

# The response carries modelType and configJson, which is where the step
# count, learning rate and accumulation of that run are recorded.

Moving a project to N1.7

The dataset does not change, the arm does not change, the task string does not change. Picking GR00T N1.7 in the same form is the entire migration, and the recording side never learns anything happened: the client at /download writes LeRobot v2.1 for both, and /live is still a real SO-100 in the browser if you want the teleoperation loop without unpacking hardware. Budget more wall-clock time, because 20 000 steps at batch 32 is a much longer run than 2000 at batch 1.

Then re-measure instead of assuming. Same twenty attempts, same reset procedure, same object positions as the N1.5 evaluation. Skip that and you have a new policy plus no statement about what the switch bought, which was the point. The protocol is in /learn/run-your-first-policy and the general walkthrough at /learn/train-your-first-policy; the arm-specific newer run is at /train/groot-n1-7-on-so-100.

Frequently asked questions