Fine-Tuning NVIDIA Isaac GR00T N1.7 on a Jetson AGX Thor for the Seeed Studio reBot Arm B601-RS
I always assumed any form of model tuning meant a big hardware investment, or renting a huge compute instance in the cloud.
Then, in a separate project with nothing to do with this arm, I used supervised fine-tuning and distillation on Amazon Bedrock to build custom Amazon Nova models. It cost far less than I expected. First assumption gone.
The second one lasted longer: I was sure my Jetson AGX Thor couldn't train GR00T. Not enough hardware.
So I wanted one question answered: can this hardware train the model at all?
That's why I borrowed someone else's dataset rather than recording my own — it keeps my arm, my calibration and my teleoperation out of the experiment, so the only thing being tested is the Thor.
It worked.
One machine, not two
The workstation and the 23 GB checkpoint copy both drop out. Everything runs from NVIDIA/Isaac-GR00T on the Thor, against nvidia/GR00T-N1.7-3B.
The dataset
I borrowed prateeks-iu/rebot_b601_rs_sugar off HuggingFace — Apache-2.0, published July 2026.
| Task | "Pick up one sugar cube and put it in the cup" |
| Episodes | 103 |
| Frames | 77,694 at 60 fps — 21.6 minutes of robot time |
| Robot type | seeed_b601_rs_follower |
| State / action | 7-dim each |
| Cameras | scene, wrist, plus depth for both |
| Format | LeRobot v3.0, converted to v2.1 for GR00T |
| Size on disk | 1.0 GB without the raw depth .mkv files |
robot_type is the exact string the Seeed Studio LeRobot fork writes, and the joint names line up with my arm one for one — shoulder_pan, shoulder_lift, elbow_flex, wrist_flex, wrist_yaw, wrist_roll, gripper. A dataset from a different arm, or with a different state shape, needs the modality config rewritten first. I trained on scene + wrist and ignored the depth streams.
Does it actually learn?
Loss 1.155 → 0.022 across 10,000 steps, mean 0.059.
Step time is flat — 2.31 s median across 11,000 samples, never drifting. The two red lines are the checkpoint writes at steps 5,000 and 10,000, each stalling the run for about 84 seconds while 24 GB goes to disk.
Gradient norm settles at 0.31 after an early spike to 3.6 and never diverges, which is the other thing worth checking before trusting a loss curve.
open_loop_eval.py replays trajectories from the dataset and scores predicted joint actions against ground truth. No robot required.
| Checkpoint | MSE | MAE |
|---|---|---|
| 20 steps (smoke test) | 4,225.4 | 39.96 |
| 5,000 steps | 4.31 | 1.39 |
| 10,000 steps | 4.36 | 1.16 |
20 steps: predictions are noise.
Finished model: predictions track ground truth. MSE 969x lower than the floor.
What the model actually outputs
One inference doesn't return a command. It returns a chunk of 16 future actions, seven joints each, in degrees. Here are the first three steps:
| Joint | t+0 | t+1 | t+2 |
|---|---|---|---|
shoulder_pan | 0.27 | 0.27 | 0.39 |
shoulder_lift | −85.78 | −84.13 | −83.27 |
elbow_flex | 1.56 | −0.10 | 2.91 |
wrist_flex | 3.24 | 2.36 | 2.40 |
wrist_yaw | 1.90 | 1.04 | 1.19 |
wrist_roll | 0.74 | 0.78 | 0.66 |
gripper | 0.00 | 0.00 | 0.00 |
I handed it a neutral pose with shoulder_lift at −90°. It came back with −85.78, −84.13, −83.27 — a trajectory that starts where the arm already is and lifts from there. It reads the current pose and continues it.
The gripper is 0.00 on all 16 steps. In this dataset the gripper only closes once the arm is over the cube, so from a neutral start there's nothing to grip. But a row that never moves also looks exactly like a dead output head, and I can't separate those two without the arm.
A chunk takes 129 ms at the default 4 denoising steps. Sixteen actions out of that chunk is 8.1 ms each — 124 Hz, against a dataset recorded at 60 Hz. The Thor can run this model at twice the rate the demonstrations were captured.
Denoising steps buy smoothness and cost rate. Eight steps still clears 60 Hz; sixteen doesn't. So there's quality left to spend before real time is at risk — on the same machine that did the training.
The hardware was never the constraint
Thor throttles at 109 °C, not the ~95 °C usually quoted. Fan steps start at 80 °C, shutdown is 114 °C. Read the trip points off the device yourself — they are in /sys/devices/virtual/thermal/thermal_zone*/trip_point_*_temp, and tegrastats reports the live values. The run peaked at 83 °C junction — 26 °C of margin.
Spot checks lie. Across 1,787 samples it caught an 82 GB memory peak, a CPU load spike of 9.2 across 14 cores, and a 192 W total draw — 1.5× the devkit's 130 W nominal. None of those showed up in a single reading.
The whole run, sampled every 10 seconds. The sawtooth in all five is the same cycle: the data loader caches the next shard, CPU load and memory climb, GPU utilisation drops to as low as 3% while it waits, then everything snaps back. Step time never moved off 2.29 s through any of it.
Junction, GPU and CPU against the real 109 °C throttle point.
What it costs to run
| GPU | Blackwell, 2,560-core, sm_110 |
| Memory | 122 GB unified · 82 GB peak |
| Bandwidth | 273 GB/s |
| Throughput | 2.29 s/step · 13.5 samples/s |
| 10,000 steps | 6 h 34 m |
| Energy | 0.63 kWh (~NZ$0.19) |
GPU sat at 92–98% throughout, dipping only while the data loader cached the next shard. Training occupies the Thor completely — it can't serve inference while it trains.
The GPU rail is only 40 W of the 95 W mean — 42%. More than half the draw is CPU, SoC and the rest of the board, which is worth knowing before sizing a supply around GPU figures alone.
Output came to 60 GB: two checkpoints at 24 GB each, plus the final model.
That changes how I'll use the cloud rather than whether I use it. Experiments run locally now, with no instance to spin up and no meter running. The cloud becomes what I reach for when I'm genuinely bottlenecked — several configs in parallel, a job too big for 122 GB, or Cosmos3-Super augmentation needing 4× A100. Offloading when I hit a wall, rather than renting by default.
What this does not prove: the checkpoint has never driven a motor. It was scored against recorded trajectories, not on the arm. Proving the Thor can train the model and proving the model can do the task are two different things, and only the first one is done.
Both assumptions were wrong. The Thor on my desk could do it all along. All I had to do was start the job and wait 6 h 34 m. It trained GR00T N1.7 for 10,000 steps, on about NZ$0.19 of electricity. No x86 box, no rented GPU, and no reflash of JetPack 7.1.