docs/source/hardware_guide.mdx
Rough sizing for training a LeRobot policy: how much VRAM each policy needs, what training time looks like, and where to run when local hardware isn't enough.
The numbers below are indicative — order-of-magnitude figures for picking hardware, not exact predictions. Throughput depends heavily on dataset I/O, image resolution, batch size, and number of GPUs.
Policies cluster by backbone size; the groupings below give a single VRAM envelope per group instead of repeating numbers per policy. Memory scales roughly linearly with batch size; AdamW (the LeRobot default) carries optimizer state that adds ~30–100% over a forward+backward pass alone.
| Group | Policies | Peak VRAM (BS 8, AdamW) | Suitable starter GPUs |
|---|---|---|---|
| Light BC | act, vqbet, tdmpc | ~2–6GB | Laptop GPU (RTX 3060), L4, A10G |
| Diffusion | diffusion, multi_task_dit | ~8–14GB | RTX 4070+ / L4 / A10G |
| Small VLA | smolvla | ~10–16GB | RTX 4080+ / L4 / A10G |
| Large VLA | pi0, pi0_fast, pi05, xvla, wall_x | ~24–40GB | A100 40 GB+ (24 GB tight at BS 1) |
| Multimodal | groot, eo1 | ~24–40GB | A100 40 GB+ |
| RL | sac | config-dep. | See HIL-SERL guide |
Memory-bound? Drop the batch size (~linear), use gradient accumulation to recover effective batch, or for SmolVLA leave freeze_vision_encoder=True.
Robotics imitation learning typically converges in 5–10 epochs over the dataset, not hundreds of thousands of raw steps. Once you know your epoch count, wall-clock is essentially:
total_frames = sum of frames over all episodes # 50 ep × 30 fps × 30 s ≈ 45,000
steps_per_epoch = ceil(total_frames / (num_gpus × batch_size))
total_steps = epochs × steps_per_epoch
wall_clock ≈ total_steps × per_step_time
Per-step time depends on the policy and the GPU. The numbers in the table below are anchors — pick the row closest to your setup and scale linearly with total_steps if you train longer or shorter.
Indicative wall-clock for 5 epochs on a ~50-episode dataset (~45k frames at 30 fps × 30 s), default optimizer (AdamW), 640×480 images:
| Setup | Policy | Batch | Wall-clock |
|---|---|---|---|
| Single RTX 4090 / RTX 3090 (24 GB) | act | 8 | ~30–60min |
| Single RTX 4090 / RTX 3090 (24 GB) | diffusion | 8 | ~2–4h |
| Single L4 / A10G (24 GB) | act | 8 | ~1–2h |
| Single L4 / A10G (24 GB) | smolvla | 4 | ~3–6h |
| Single A100 40 GB | smolvla | 16 | ~1–2h |
| Single A100 40 GB | pi0 / pi05 | 4 | ~4–8h |
4× H100 80 GB cluster (accelerate) | diffusion | 32 | ~30–60min |
4× H100 80 GB cluster (accelerate) | smolvla | 32 | ~1–2h |
| Apple Silicon M1/M2/M3 Max (MPS) | act | 4 | ~6–14h |
These are order-of-magnitude figures. Real runs deviate by ±50% depending on image resolution, dataset I/O, dataloader threading, and exact GPU SKU. They are useful as "is this run going to take an hour or a day?" intuition, not as SLAs.
accelerate launch --num_processes=N is the easiest way to cut training time. Each optimizer step processes N × batch_size samples in roughly the same wall-clock as a single-GPU step, so 4 GPUs ≈ 4× speedup for compute-bound runs. See the Multi GPU training guide for the full setup.
Reference data points on a 4×H100 80 GB cluster (accelerate launch --num_processes=4), 5000 steps, batch 32, AdamW, dataset imstevenpmwork/super_poulain_draft (~50 episodes, ~640×480 images):
| Policy | Wall-clock | update_s | dataloading_s | GPU util | Notable flags |
|---|---|---|---|---|---|
diffusion | 16m 17s | 0.167 | 0.015 | ~90% | defaults (training from scratch) |
smolvla | 27m 49s | 0.312 | 0.011 | ~80% | --policy.path=lerobot/smolvla_base, freeze_vision_encoder=false, train_expert_only=false |
pi05 | 3h 41m | 2.548 | 0.014 | ~95% | --policy.pretrained_path=lerobot/pi05_base, gradient_checkpointing=true, dtype=bfloat16, vision encoder + expert trained |
The dataloading_s vs. update_s ratio is the diagnostic that matters: when dataloading_s approaches update_s, more GPUs stop helping — your dataloader is the bottleneck and you should look at --num_workers, image resolution, and disk speed before adding compute.
If you shorten training (e.g. 5k–10k steps on a small dataset), also shorten the LR schedule with --policy.scheduler_decay_steps≈--steps. Otherwise the LR stays near its peak and never decays. Same for --save_freq.
VRAM is the first filter. Within a tier, pick by budget and availability — the $–$$$$ columns are relative; check current pricing on the provider you actually use.
| Class | VRAM | Tier | Comfortable for |
|---|---|---|---|
| RTX 3090 / 4090 (consumer) | 24 GB | $ | Light BC, Diffusion, SmolVLA. Tight for VLAs at batch 1. |
| L4 / A10G (cloud) | 24 GB | $–$$ | Same envelope; common on Google Cloud, RunPod, AWS g5/g6. |
| A100 40 GB | 40 GB | $$$ | Any policy at reasonable batch sizes. |
| A100 80 GB / H100 80 GB | 80 GB | $$$$ | Multi-GPU clusters; large batches for VLAs. |
| CPU only | — | — | Don't train. Use Colab or rent a GPU. |
Hugging Face Jobs lets you run training on managed HF infrastructure, billed by the second, without owning a GPU. lerobot-train submits and streams the job for you — just add --job.target=<flavor> to a normal training command:
lerobot-train \
--policy.type=act --dataset.repo_id=<USER>/<DATASET> \
--policy.repo_id=<USER>/act_<task> \
--job.target=a10g-large
Notes:
hf auth login once before submitting, the job runs under your token.--job.target maps onto the table above: t4-small/t4-medium (T4, ACT only), l4x1/l4x4 (L4 24 GB), a10g-small/large/largex2/largex4 (A10G 24 GB scaled out), a100-large (A100). List the current catalogue with pricing via hf jobs hardware, or see https://huggingface.co/docs/hub/jobs.2d (48h) timeout. Override it with --job.timeout=4h (or any other valid duration string) to shorten or extend the timeout. The job automatically stops when the command completes.