GR00T N1.7 vs GR00T N1.5: which version to select

The short version

N1.5 is kept available so a project started on it can be finished on it. Same family, same dataset format, same 80 GB tier, same workflow, and behind its successor on the things you would actually choose a model for. If you are here to decide what to train tomorrow, the answer is N1.7. The rest of this page is for two situations: you inherited an N1.5 run and have to decide whether to port it, or you tried both and got a result that made N1.7 look implausibly far ahead. The second case is almost always the defaults trap below.

Side by side

The defaults are the real difference on this page

Multiply the two recipes out before comparing anything. N1.7 defaults to batch 32 with no accumulation over 20 000 steps, about 640 000 sample views. N1.5 defaults to batch 1 with 16 accumulation steps over 2000 steps, about 32 000. That is a factor of twenty in how much data the optimizer ever sees.

N1.7  batch 32 x accum 1  = effective 32  x 20 000 steps = ~640 000 sample views
N1.5  batch 1  x accum 16 = effective 16  x  2 000 steps = ~ 32 000 sample views

Ratio: about 20 to 1, before either architecture has been considered.

For a comparison that means something, raise the N1.5 step count until the
sample budgets are in the same range, and keep everything else identical.

So if you run both at their defaults and conclude N1.7 is dramatically stronger, you have mostly measured schedule length. The architectures may differ too, but that experiment cannot tell you by how much.

When N1.5 is the right selection

• You are extending an experiment series that began on N1.5 and the comparison across runs has to hold. Changing the model mid-series invalidates every earlier data point.
• A report or thesis chapter already states N1.5 results and you need another checkpoint under the same configuration rather than a better one under a different model.
• You are bisecting a regression. Running the older model on the same dataset is a legitimate way to work out whether the model or the data changed underneath you.

All three are about consistency with the past. There is no forward-looking reason to start something new on N1.5: it is superseded on every axis that matters, and it carries none of the improvements that came with the newer version.

What N1.5 still does better

One thing, and it is narrower than it sounds: its default recipe is the memory-lightest shape in the GR00T family. Batch 1 with 16 accumulation steps holds far less in VRAM at any moment than batch 32, at the cost of sixteen sequential passes per optimizer step. Both versions request the same 80 GB tier, so this is not a way to escape the tier, but it is the shape to copy if you ever need to shrink an N1.7 run: lower the batch, raise the accumulation by the same factor, and the optimizer still sees the same effective batch. Beyond that, N1.5 matches its own history and nothing else.

Neither version gives you a seed

This bounds what reproducing an older run can mean. The GR00T fine-tuning entry point has no seed field on either version, so two runs launched with identical settings on identical data are not guaranteed to produce identical weights. What you can reproduce is a configuration and an evaluation, which is usually what a report needs. Write down at least:

1. The dataset id and its version, so the second run reads exactly the same episodes
2. The model version, N1.7 or N1.5, exactly as selected in the form
3. Batch size, gradient accumulation, learning rate and the step count you actually used
4. The saveSteps value and the checkpoint step you evaluated, not just the last one
5. The evaluation protocol: how many attempts, which placements, what lighting

If you need genuine seeded determinism, the GR00T family cannot provide it. Pi0.5 sits on the same 80 GB tier and exposes seed and logFreq, which is the practical alternative when reproducibility is a hard requirement.

Migrating an N1.5 project to N1.7

1. 1
   Keep the dataset exactly as it is

   Both versions read LeRobot v2.1 and reject v3.0, so nothing needs re-recording or converting. The dataset id stays the same across the migration.

2. 2
   Do not port the old hyperparameters

   Start N1.7 at its own defaults. Copying batch 1, 16 accumulation steps and 2000 steps across gives it a twentieth of the exposure it expects, and the run will look like a failure of the new version.

3. 3
   Set saveSteps so the checkpoints line up

   Choose a value that produces checkpoints at points comparable to the ones you evaluated on N1.5. Comparing a final checkpoint against a mid-training one is a common way to draw the wrong conclusion.

4. 4
   Re-run the old evaluation protocol unchanged

   Same placements, same count, same lighting, same person doing the reset. A migration is informative only if the measurement stays still while the model moves.

5. 5
   Keep the N1.5 checkpoint until the new one wins on hardware

   Loss curves do not settle this. Retire the old policy when the new one beats it on the arm, and not before.

curl -s 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":"start_training",
        "arguments":{
          "dataset_id":"ds_7f31c0a4",
          "policy_name":"cube pick, n1.5 series continuation",
          "model_id":"groot1.5",
          "max_steps":20000,
          "confirm_spend":true}}}'

# max_steps is set explicitly rather than accepting the N1.5 default of
# 2000, so the exposure is comparable to an N1.7 run.
# For anything new, use "model_id":"groot1.7".

Switching versions changes nothing on disk

Of all the choices on this site, this is the cheapest one to get wrong. The two versions share a dataset format, a GPU tier, a workflow and a set of exposed knobs, so moving between them is a field in the training form and one more rented run. Your episodes, camera positions and task strings are untouched by any of it. Train N1.7, keep the old checkpoint while you compare, and delete it once the comparison is settled.

Where to go next

• /policies/groot-n1-7: the version to select for new work
• /policies/groot-n1-5: what the older entry is kept for
• /train/groot-n1-7-on-so-100: the current guide on the reference arm
• /train/groot-n1-5-on-so-100: the same steps against the older version
• /policies for every supported model in one list

Frequently asked questions