GR00T N1.7 vs Pi0.5: speed against contact precision

The short answer

On paper these two are the same class of model: around three billion parameters each, both on the 80 GB tier, both reading LeRobot v2.1, both useful from about fifty episodes. The choice is not about capability in the abstract. It is about a control loop that closes in 152 ms against one that closes in 485 ms, and a recipe that pushes a batch of 32 through in one pass against one that assembles every optimizer step out of sixteen single-sample passes. GR00T N1.7 is the default. Pi0.5 answers two specific problems: tasks where the last centimeters decide success, and runs somebody else has to repeat.

Side by side

What 152 ms against 485 ms means on the arm

Latency here is the time to turn one observation into one action step. At 152 ms the loop closes six to seven times a second. At 485 ms it closes about twice a second, and every command the arm executes rests on a picture of the world that is roughly half a second old.

If nothing in your scene moves except the arm, that staleness costs cycle time and nothing else. It starts costing success the moment something changes without the arm having caused it: an object that rolls after a nudge, a part that settles differently on contact, a hand entering the frame. You cannot buy the time back with a longer action horizon either, because chunkSize and nActionSteps are ACT-only controls. What the table says is what the arm gets.

Batch 32 against batch 1 with sixteen accumulation steps

Gradient accumulation imitates a large batch on a card that cannot hold one: several small passes, gradients added up, then one optimizer step. Pi0.5 defaults to batch 1 with 16 accumulation steps, an effective batch of 16 built from sixteen sequential passes. GR00T N1.7 defaults to batch 32 with no accumulation, so one pass is one optimizer step.

Multiply that out. GR00T runs 20 000 optimizer steps, so 20 000 passes and about 640 000 sample views. Pi0.5 runs 30 000 steps at sixteen passes each, roughly 480 000 passes for about 480 000 sample views. Similar sample budgets, very different demands on the GPU, and a batch of one leaves most of an 80 GB card idle. Both runs still fall inside the 80 GB estimate of three to six hours at 1.20 to 2.00 USD per hour, with GR00T toward the bottom of that band and Pi0.5 toward the top.

Pick GR00T N1.7 if

• Cycle time is part of the point: pick and place, sorting, handovers. Six to seven action steps a second is the difference between an arm that looks like it is working and one that looks like it is thinking about it.
• Objects do not always land where you demonstrated them. Pretraining on a multi-robot corpus is the thing you are renting the 80 GB card for.
• You plan to iterate this week. A run at the bottom of the band lets you evaluate, record for the failures you found, and start again the same day.

Pick Pi0.5 if

• Your task is contact-rich: seating a lid, inserting a peg, stacking blocks that have to stay stacked. Flow matching produces continuous trajectories instead of discretized jumps, and the final approach is where that shows.
• Somebody has to repeat the run. Pi0.5 exposes seed and logFreq. GR00T has no seed field at all, on either version.
• The task is quasi-static. If the object sits still until the gripper touches it, 485 ms costs you patience during evaluation and nothing on the outcome.

What Pi0.5 does better, said plainly

Reproducibility is not a small thing to give up. Two GR00T runs launched with identical settings on identical data can come out different, and no field in the form prevents it. For a thesis chapter or anything a colleague will try to repeat next month, that outweighs 333 ms of latency.

The Pi0.5 recipe is also the more cautious one: 5e-5 over 30 000 steps against 1e-4 over 20 000. A lower rate applied for longer is more forgiving of a dataset with a few sloppy episodes, because no single batch moves the weights far. That is not a benchmark claim, it is what the two sets of defaults describe. And logFreq earns its place: GR00T only lets you control checkpoint frequency through saveSteps, while the lerobot-family trainers let you raise logging density and watch the curve when something looks wrong early.

Run both instead of arguing about it

1. 1
   Upload once, as LeRobot v2.1

   Both trainers read the same format, so one upload feeds both jobs. GR00T rejects v3.0, and finding that out after fifty episodes is a bad afternoon.

2. 2
   Start GR00T N1.7 at its defaults

   Open Training, pick the dataset, choose GR00T N1.7, leave batch 32 and 20 000 steps alone. Lower saveSteps for more checkpoints to compare.

3. 3
   Start Pi0.5 on the same dataset with a fixed seed

   Second job, same dataset. Write the seed down next to the job id, because this is the run you will be asked to repeat.

4. 4
   Evaluate both with one protocol

   Twenty attempts each, same placements in the same order, same lighting, written down as you go. Do not evaluate one policy before and one after rearranging the desk.

5. 5
   Classify the failures, not just the count

   Confidently wrong location is a data or camera problem and neither model fixes it. Correct arrival with a fumbled grasp is the precision case Pi0.5 exists for.

# Streamable HTTP + JSON-RPC 2.0 at /api/mcp, protocol version 2025-06-18.
# Dataset and training tools take your API key as a Bearer token.
curl -s https://www.ay-robots.com/api/mcp \
  -H "Authorization: Bearer $AY_ROBOTS_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "start_training",
      "arguments": {
        "dataset_id": "ds_7f31c0a4",
        "policy_name": "cube pick, groot n1.7 baseline",
        "model_id": "groot1.7",
        "max_steps": 20000,
        "confirm_spend": true
      }
    }
  }'

# Second job, same dataset_id: "model_id": "pi0" and "max_steps": 30000.
# confirm_spend rents a GPU by the hour and bills the account, so the call
# is refused unless you set it on purpose.

Switching later costs one more run

The dataset is the asset. A checkpoint is a few hours of rented GPU and you can throw it away without losing anything you worked for. The episodes are what cost you an afternoon: the fixed cameras, the identical task string, the fifty resets, the failures you had the discipline to discard. Both trainers read LeRobot v2.1, so changing your mind means a new job against the same dataset id, not a new recording session.

Where to go next

• /policies/groot-n1-7 for the full GR00T N1.7 fact sheet: defaults, limits, dataset requirements
• /policies/pi0-5 for the same on Pi0.5, including what flow matching changes about the action output
• /train/groot-n1-7-on-so-100 for the step by step training guide on an SO-100
• /train/pi0-5-on-so-100 for the Pi0.5 version of that guide
• /compare/groot-n1-7-vs-smolvla if the 80 GB rental is the part you are unsure about

Frequently asked questions