Policytraining

Trainen zonder eigen GPU

Een manipulatiepolicy trainen is een GPU-taak, en moderne vision-language-action-modellen hebben meer VRAM nodig dan een typische werkstation heeft. Op AY-Robots draait de training op cloud-GPU's die het platform beheert: u kiest een dataset en een policytype, start de run en volgt de voortgang vanuit de browser. Geen CUDA-installatie, geen drivers afstemmen, geen omgeving te onderhouden.

De invoer is altijd een clouddataset uit Dashboard > Datasets. Alles wat u via teleoperatiesessies hebt opgenomen of in LeRobot-formaat hebt geüpload, komt in aanmerking, inclusief samengevoegde datasets. Cureer voordat u traint: episodes met het label Failure horen doorgaans niet in de trainingsset thuis, en tien minuten beoordelen in de episodeverkenner bespaart uren GPU-tijd die anders wordt besteed aan leren van slechte demonstraties.

Ondersteunde policies

Er worden vier policyfamilies ondersteund. Ze verschillen in grootte, trainingskosten en hoeveel ze uit uw data kunnen opnemen, dus de juiste keuze hangt meer af van uw taak en dataset dan van enige algemene rangorde.

Een run starten

1. 1
   Kies de dataset

   Open Dashboard > Training en selecteer de dataset om op te trainen. Het episodetal en het robottype worden getoond zodat u kunt bevestigen dat u de juiste hebt gekozen.

2. 2
   Kies de policy

   Selecteer een van de ondersteunde policytypes. Twijfelt u, begin dan met ACT: het is de goedkoopste manier om te ontdekken of uw dataset goed genoeg is om überhaupt iets te trainen.

3. 3
   Start

   Start de run. Deze krijgt een job-id en een eigen runpagina, en u kunt de browser sluiten: de training gaat serverzijdig door en de pagina toont de live status wanneer u terugkomt.

De trainingsrunpagina

Elke run heeft een eigen pagina die de twee vragen beantwoordt die u tijdens het trainen echt hebt: leert het, en is de machine gezond. De leervoortgang wordt getoond als grafieken van de loss, het learning-rate-schema en de gradiëntnorm. Een loss die meteen stagneert of een gradiëntnorm die explodeert, laat vroeg zien dat het wachten op deze run niet loont.

Machinegezondheid wordt ernaast getoond: GPU-gebruik en -geheugen, plus de hostmetrieken van de trainingsmachine. Een fasetijdlijn toont waar de run zich op dat moment bevindt, van omgevingsvoorbereiding via het laden van data en de trainingslus zelf tot de checkpoint-upload. Ziet iets er vreemd uit, dan geeft de ingebouwde logviewer u de ruwe trainingslogs zonder enige SSH-toegang, wat meestal genoeg is om te zien of een storing aan uw dataset of aan de run zelf ligt.

Checkpoints en hervatten

Checkpoints worden per run opgeslagen, niet in een gedeelde pool, dus de checkpoints op een runpagina behoren altijd precies bij die run en zijn configuratie. Dit weegt zwaarder dan het klinkt: checkpoints mengen tussen runs met verschillende instellingen is een klassieke oorzaak van stilletjes kapotte policies.

Wordt een run onderbroken, dan kunt u hervatten vanaf het laatste checkpoint in plaats van opnieuw te beginnen. Tussentijdse checkpoints zijn ook op zichzelf nuttig: begint een lange run tegen het einde te overfitten, dan presteert een eerder checkpoint op de echte arm vaak beter dan het laatste.

De getrainde policy op uw arm draaien

Een voltooide policy kan direct terug naar uw robot worden gebracht. Selecteer in de cockpit de getrainde policy voor uw verbonden arm en start de inferentie: de policy produceert nu de gewrichtscommando's die u eerder door teleoperatie produceerde. De arm moet hetzelfde robottype zijn als waarop de dataset is opgenomen, en de scène moet lijken op de trainingsscènes, inclusief cameraplaatsing.

Behandel de eerste inferentieruns als experimenten, niet als demo's. Houd de noodstop binnen bereik, begin vanuit een starttoestand die dicht bij wat u demonstreerde ligt, en verwacht dat de policy gevoelig is voor dingen die u zelf niet zou opmerken: een verplaatste camera, ander licht of een object dat nooit in de dataset voorkwam.

Hoeveel episodes u nodig hebt

De meest voorkomende trainingsfout op het platform is geen verkeerde hyperparameter, maar trainen op te weinig data en vervolgens concluderen dat het policytype niet werkt. Als vuistregel voor één taak op tafelniveau: ongeveer 50 episodes geven u een policy met beperkte generalisatie die slaagt vanuit starttoestanden dicht bij wat u demonstreerde. Ongeveer 100 tot 200 episodes geven bruikbare robuustheid over de hele werkruimte voor die ene taak, mits u de objectplaatsing tussen episodes hebt gevarieerd.

Krachtigere policytypes heffen deze regel niet op. Een GR00T-fine-tune op 20 episodes generaliseert nog steeds slecht; wat de grotere modellen u opleveren, is een hoger plafond zodra de data er is. Is uw budget beperkt, besteed het dan eerst aan meer gevarieerde episodes voordat u het aan een groter model besteedt.

Veelgestelde vragen