Hoe SmolVLA te trainen op een 24 GB GPU (lerobot 0.6.1)

De meeste mensen die een visie-taal-actie-model op een echte arm willen, stoppen bij de hardwaregrens. GR00T N1.7 en Pi0.5 hebben elk ongeveer drie miljard parameters en vereisen een A100 80 GB of een H100. Als je een gaming-pc met een RTX 4090 bezit, is dat het einde van de weg. SmolVLA is de uitzondering: 450 M parameters, binnen LeRobot, gebouwd om te fine-tunen op één consumentenkaart en te serveren vanaf een CPU.

Eerst de handmatige route: installeer lerobot, haal het lerobot/smolvla_base checkpoint op, voer het echte commando uit, lees de run terwijl deze plaatsvindt. Daarna de platformroute, en waar deze niet helpt.

Wat SmolVLA is, in cijfers die je kunt controleren

SmolVLA is een flow matching beleid dat is gekoppeld aan een klein visueel taalmodel. De ruggengraat is SmolVLM2-500M-Video-Instruct; de paper behoudt alleen de eerste 16 lagen van het taalmodel, beperkt elk cameraframe tot 64 visuele tokens met een pixel shuffle in plaats van beeldtegels, en wisselt cross-attention af met een self-attention laag om de tweede blok. Inferencekosten waren een ontwerpbeperking, geen bijzaak.

De benchmarks zijn de reden waarom mensen zich bezighouden met een 450 M model. Op LIBERO behaalt het gemiddeld 87,3 procent tegen 76,5 voor OpenVLA op 7 B en 86,0 voor een robotica-voorgetrainde Pi0 op 3,3 B; op Meta-World, 57,3 tegen 47,9. Op echte SO-100 hardware levert multi-task training 75 procent op bij pick and place, 90 bij stapelen, 70 bij sorteren, met een gemiddelde van 78,3, waar ACT per taak getraind gemiddeld 48,3 behaalde. Dezelfde rijen staan naast elke gepubliceerde VLA in de SmolVLA arena-vermelding en de ACT versus SmolVLA vergelijking.

Waarom een 24 GB kaart de juiste eerste run is

LeRobot levert een rekencapaciteitsgids, de meest nuttige pagina in de repository hiervoor. Het groepeert beleidsregels op basis van backbone-grootte en geeft één VRAM-envelop per groep, gemeten bij batchgrootte 8 met AdamW, de standaard van lerobot. De optimizer-status alleen voegt 30 tot 100 procent toe bovenop een kale forward- en backward-pass, dus dit zijn geen cijfers die alleen op gewichten gebaseerd zijn.

Tien tot zestien gigabytes bij batch 8 is het argument: een 24 GB kaart past daarbij, plus de dataloader. AY-Robots plaatst SmolVLA op de RTX 4090 of elke 24 GB kaart, minimaal 30 afleveringen, LeRobot v3.0 data, 245 ms per actiestap. Gehuurd, dat is 2 tot 5 uur à 0.30 tot 0.60 USD per uur, ongeveer 1 tot 3 USD per een fijnafstemming run, tegen 4 tot 12 USD op de 80 GB tier die GR00T en Pi0.5 nodig hebben (prijzen). Een mislukte SmolVLA run is een kop koffie; een mislukte GR00T run, lunch.

Stap 0: de dataset bepaalt de run, niet de flags

Niets hieronder is van belang als de opname slecht is. De LeRobot SmolVLA-pagina is duidelijk: de referentiedataset bestond uit 50 afleveringen verdeeld over 5 kubusposities, 10 per positie, en dezelfde taak met 25 afleveringen presteerde slecht. Herhaling per variatie generaliseert, het ruwe aantal afleveringen niet. Nog nooit een opgenomen? Begin bij neem je eerste dataset op, met de desktopclient, die LeRobot-formaat schrijft vanuit een teleoperatie-sessie, of leen er een uit de datasetmap.

• Minimaal 30 afleveringen op AY-Robots, ongeveer 50 voor het LeRobot referentierecept.
• Elke variatie die je verwacht bij de uitrol, meerdere keren herhaald.
• Eén taakstring, identiek gespeld tijdens opname en uitrol. Het model is geconditioneerd op die tekst.
• Vaste camera's. Een camera die is verplaatst tussen opname en uitrol is de meest voorkomende reden dat een schone verliescurve resulteert in een bewegingloze arm.
• Een achtergehouden variatie waarop je nooit hebt getraind, zodat je iets eerlijks hebt om tegen te testen.

# v2.1 -> v3.0: aggregates per-episode files into shards and writes the episode offsets
python -m lerobot.scripts.convert_dataset_v21_to_v30 --repo-id=${HF_USER}/so100_pick_place

Meer hierover in hoe je hoogwaardige VLA-trainingsdata verzamelt. De korte versie: 30 tot 50 schone afleveringen van één taak met opzettelijke variatie verslaan 200 slordige afleveringen van drie, met een marge die geen enkele hyperparameter dicht.

Installeer lerobot 0.6.1

# LeRobot needs Python 3.12 or newer as of 0.6.x
conda create -y -n lerobot python=3.12
conda activate lerobot

# TorchCodec decodes the dataset videos and wants ffmpeg
conda install ffmpeg -c conda-forge

# Base package is deliberately thin; extras pull the rest
pip install 'lerobot[smolvla,training,core_scripts]'

# Sanity check: prints the lerobot version, the GPU torch sees, and the console scripts you got
lerobot-info

De basis lerobot installatie is licht en plaatst zware afhankelijkheden achter extra's: smolvla voegt transformers, num2words en accelerate toe, training de dataset-stack en wandb, core_scripts de hardware- en visualisatie-afhankelijkheden. Op Linux bepaalt het installatiepad ook je CUDA-wheel: de PyPI-standaard is een cu130-wheel met een driververeiste van minimaal 580.65, dus installeer bij een oudere driver eerst torch vanaf de cu128-index, en daarna lerobot.

De trainingsrun, commando voor commando

1. 1
   Authenticeer tegen de Hub

   Het basischeckpoint komt van de Hub, en je dataset waarschijnlijk ook.

   bash

   hf auth login

2. 2
   Lees de opties één keer

   Elk veld van de pipeline- en beleidsconfiguratie is een vlag. Scan het voordat je in de bron duikt.

   bash

   lerobot-train --help

3. 3
   Start de fine-tune

   Het voorbeeld in de documentatie draait batch 64 op een enkele A100; de eigen A100 40 GB anker van de compute-gids is batch 16, en 8 is het 24 GB equivalent. Geen scheduler-vlag hier met opzet, zie hieronder.

   bash

   lerobot-train \
     --policy.path=lerobot/smolvla_base \
     --dataset.repo_id=${HF_USER}/so100_pick_place \
     --batch_size=8 \
     --steps=20000 \
     --save_freq=2000 \
     --log_freq=200 \
     --seed=1000 \
     --output_dir=outputs/train/smolvla_pick_place \
     --job_name=smolvla_pick_place \
     --policy.device=cuda \
     --wandb.enable=true

4. 4
   Lees de logregel, niet alleen het verlies

   Elke --log_freq stappen print lerobot loss, grdn, lr, updt_s, data_s, smp/s en, op CUDA, mem_gb. mem_gb geeft aan of de batch past, lr of de scheduler afneemt, en data_s die updt_s nadert betekent dat de dataloader de bottleneck is, niet de GPU.

   bash

   # if data_s creeps toward updt_s
   lerobot-train ... --num_workers=8

5. 5
   Verzamel checkpoints die je kunt vergelijken

   save_freq is standaard 20000, dus een run van 20000 stappen laat één checkpoint achter en niets om het mee te vergelijken. Stel 2000 in. Pushen naar de Hub vereist --policy.repo_id.

   bash

   --save_freq=2000 \
   --policy.repo_id=${HF_USER}/smolvla_pick_place \
   --save_checkpoint_to_hub=true

6. 6
   Hervat als de machine uitvalt

   Wijs --config_path naar de train_config.json naast het checkpoint. lerobot weigert te starten in een bestaande output_dir tenzij je hervat, zodat je een run niet per ongeluk kunt overschrijven.

   bash

   lerobot-train \
     --config_path=<path to the saved train_config.json> \
     --resume=true

De vlaggen die het resultaat daadwerkelijk veranderen

De standaardinstellingen die je overneemt als je niets aanraakt

Een beleid configuratie in lerobot heeft zijn eigen optimizer en scheduler preset, en tenzij je use_policy_training_preset=false instelt, winnen die presets. De helft van de vragen die mensen stellen over SmolVLA-training worden beantwoord door een standaardinstelling waarvan ze het bestaan niet wisten.

De twee regels die mensen verrassen zijn freeze_vision_encoder en train_expert_only, beide waar. Standaard train je ongeveer 100 M parameters, niet 450 M, daarom past het op 24 GB. LeRobot's eigen referentierun op een vier-GPU H100 cluster zet beide op onwaar; op één 24 GB kaart verandert dat een werkende run in .

Hoe lang de run duurt, en hoeveel stappen voldoende zijn

LeRobot publiceert 'wall-clock' ankers voor vijf epochs over een dataset van ongeveer 50 afleveringen, ongeveer 45000 frames bij 30 fps. Ordegrootte cijfers, zeggen de documenten, maar ze maken het verschil tussen het verwachten van een uur en een dag.

Het verfijnde beleid opnieuw uitvoeren op de arm

lerobot-rollout \
  --strategy.type=base \
  --robot.type=so100_follower \
  --robot.port=/dev/ttyACM0 \
  --robot.id=my_follower_arm \
  --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}" \
  --task="Grasp the cube and put it in the box." \
  --policy.path=${HF_USER}/smolvla_pick_place

De 245 ms per actiestap is gemakkelijk verkeerd te interpreteren: het beleid zendt chunk_size = 50 acties uit per forward pass en voert er n_action_steps = 50 van uit, dus hoe vaak je die kosten betaalt, wordt bepaald door die instellingen, niet door hoe vaak de servo's een commando krijgen. Dat is wat actie-chunking oplevert, en waarom een model van 245 ms een arm van 30 Hz kan aansturen. Wat overblijft is inferentielatentie aan het einde van de chunk.

Die derde rij is wat de meeste verslagen overslaan. Asynchrone inferentie is ongeveer 30 procent sneller en verdubbelt ruwweg de doorvoer in een vast tijdsvenster, en het artikel noemt de succespercentages vergelijkbaar, wat ze gemiddeld ook zijn. Daaronder daalde sorteren van 70 naar 50 procent, terwijl pick-and-place er 5 bij kreeg. lerobot 0.6.1 bevat de andere hendel in dezelfde binary: --inference.type=rtc schakelt de rollout over naar real-time chunking, wat het eigen gebruiksblok van het script aanbeveelt voor de langzame VLA's, Pi0, Pi0.5 en SmolVLA.

Twee routes naar hetzelfde checkpoint

pip install 'lerobot[smolvla,training,core_scripts]'
hf auth login

lerobot-train \
  --policy.path=lerobot/smolvla_base \
  --dataset.repo_id=${HF_USER}/so100_pick_place \
  --batch_size=8 --steps=20000 \
  --save_freq=2000 --seed=1000 \
  --output_dir=outputs/train/smolvla_pick_place \
  --job_name=smolvla_pick_place \
  --policy.device=cuda --wandb.enable=true

Wanneer SmolVLA de verkeerde keuze is

De test of SmolVLA de juiste eerste run was, is niet of het werkte, maar of de mislukking je iets vertelde. Bereik 60 of 70 procent en een groter model is een redelijke volgende investering: de data bevat een signaal. Bereik 10 procent en een 3 B model bereikt hoogstwaarschijnlijk ook 10 procent, wat je zojuist hebt geleerd voor drie dollar in plaats van twaalf.

Lees dit voordat u meer uitgeeft: Pi0.5 tegen SmolVLA voor meer capaciteit op basis van hetzelfde idee, en GR00T N1.7 tegen SmolVLA voor de NVIDIA-route, beide 80 GB tier voor 4 tot 12 USD per run. De andere optie, ACT is de goedkopere basislijn: 80 M parameters, 20 ms per actiestap, geen taalconditionering. Alle vijf staan op de beleidspagina; de arena heeft 85 modellen en 332 benchmarkresultaten.

De checklist voordat je iets opschaalt

1. Heeft de lr zijn ondergrens van 2.5e-6 bereikt? Onder 30000 stappen herschaalt lerobot de decay en meldt dit bij het opstarten; daarboven stel je --policy.scheduler_decay_steps zelf in.
2. Meer dan één checkpoint, en episodes apart gehouden met --dataset.eval_split zodat de eval loss iets betekent.
3. Beweegt het beleid überhaupt? Een dalend verlies met een bewegingloze arm heeft specifieke oorzaken: verlies daalt, beleid doet niets.
4. Overleeft het een verandering van scène? Zo niet: beleid werkt alleen in één opstelling.
5. Heb je de seed genoteerd? lerobot gebruikt standaard 1000, zodat twee ongewijzigde runs vergelijkbaar blijven.
6. Pas dan: meer episodes, meer variatie, of een groter model. In die volgorde.

Voor waarom deze modellen bestaan en wat ze doen met de taalinput, is de achtergrond; leidt de assemblage door naar de eerste run. Voor het voltooide checkpoint, ; als de arm nooit verschijnt, .