Policy training

Training without your own GPU

Training a manipulation policy is a GPU workload, and modern vision-language-action models need more VRAM than a typical workstation has. On AY-Robots the training runs on cloud GPUs managed by the platform: you pick a dataset and a policy type, start the run, and watch its progress from the browser. There is no CUDA setup, no driver matching, and no environment to maintain.

The input is always a cloud dataset from Dashboard > Datasets. Anything you recorded through teleoperation sessions or uploaded in the LeRobot format is eligible, including merged datasets. Curate before you train: episodes labeled Failure usually belong out of the training set, and ten minutes of review in the episode browser saves hours of GPU time spent learning from bad demonstrations.

Supported policies

Four policy families are supported. They differ in size, training cost, and how much they can absorb from your data, so the right choice depends on your task and dataset more than on any general ranking.

Starting a run

1. 1
   Pick the dataset

   Open Dashboard > Training and select the dataset to train on. The episode count and robot type are shown so you can confirm you picked the right one.

2. 2
   Choose the policy

   Select one of the supported policy types. If you are unsure, start with ACT: it is the cheapest way to find out whether your dataset is good enough to train anything at all.

3. 3
   Launch

   Start the run. It gets a job id and its own run page, and you can close the browser: training continues server-side and the page shows the live state whenever you come back.

The training run page

Every run has a dedicated page that answers the two questions you actually have during training: is it learning, and is the machine healthy. Learning progress is shown as charts of the loss, the learning rate schedule, and the gradient norm. A loss that plateaus immediately or a gradient norm that explodes tells you early that the run is not worth waiting for.

Machine health is shown alongside: GPU utilization and memory, plus the host metrics of the training machine. A phase timeline shows where the run currently is, from environment preparation through data loading, the training loop itself, and checkpoint upload. When something looks off, the built-in log viewer gives you the raw training logs without any SSH access, which is usually enough to see whether a failure is your dataset or the run itself.

Checkpoints and resuming

Checkpoints are stored per run, not in a shared pool, so the checkpoints listed on a run page always belong to exactly that run and its configuration. This matters more than it sounds: mixing checkpoints across runs with different settings is a classic source of silently broken policies.

If a run is interrupted, you can resume from its latest checkpoint instead of starting over. Intermediate checkpoints are also useful on their own: when a long run starts overfitting near the end, an earlier checkpoint often runs better on the real arm than the final one.

Running the trained policy on your arm

A finished policy can be deployed straight back to your robot. In the cockpit, select the trained policy for your connected arm and start inference: the policy now produces the joint commands that you previously produced by teleoperation. The arm must be the same robot type the dataset was recorded on, and the scene should resemble the training scenes, including camera placement.

Treat the first inference runs like experiments, not demos. Keep the emergency stop within reach, start from a starting state close to what you demonstrated, and expect the policy to be sensitive to things you would not notice: a moved camera, different lighting, or an object the dataset never contained.

How many episodes you need

The most common training mistake on the platform is not a wrong hyperparameter, it is training on too little data and concluding the policy type does not work. As a rule of thumb for a single tabletop task: around 50 episodes gives you a policy with narrow generalization that succeeds from starting states close to the ones you demonstrated. Around 100 to 200 episodes gives usable robustness across the workspace for that one task, provided you varied object placement between episodes.

More capable policy types do not repeal this. A GR00T fine-tune on 20 episodes will still generalize poorly; what the larger models buy you is a better ceiling once the data is there. If your budget is limited, spend it on more varied episodes before spending it on a bigger model.

Frequently asked questions