Policytrening

Trening uten egen GPU

Å trene en manipulasjonspolicy er en GPU-arbeidslast, og moderne vision-language-action-modeller trenger mer VRAM enn en typisk arbeidsstasjon har. På AY-Robots kjører treningen på skybaserte GPU-er som plattformen administrerer: du velger et datasett og en policytype, starter løpet, og følger fremdriften fra nettleseren. Ingen CUDA-oppsett, ingen driversamsvar, og ingen miljø å vedlikeholde.

Inndataen er alltid et skydatasett fra Dashboard > Datasets. Alt du har tatt opp gjennom teleoperasjonsøkter eller lastet opp i LeRobot-format er kvalifisert, inkludert sammenslåtte datasett. Kurater før du trener: episoder merket Failure hører vanligvis ikke hjemme i treningssettet, og ti minutters gjennomgang i episodeutforskeren sparer timer med GPU-tid brukt på å lære av dårlige demonstrasjoner.

Støttede policyer

Fire policy-familier støttes. De skiller seg i størrelse, treningskostnad og hvor mye de kan absorbere fra dataene dine, så det riktige valget avhenger mer av oppgaven og datasettet ditt enn av noen generell rangering.

Starte et løp

1. 1
   Velg datasettet

   Åpne Dashboard > Training og velg datasettet du vil trene på. Episodeantall og robottype vises slik at du kan bekrefte at du valgte riktig.

2. 2
   Velg policyen

   Velg en av de støttede policytypene. Er du usikker, start med ACT: det er den billigste måten å finne ut om datasettet ditt er godt nok til å trene noe som helst.

3. 3
   Start

   Start løpet. Det får en jobb-ID og en egen løp-side, og du kan lukke nettleseren: treningen fortsetter på serversiden, og siden viser den direkte tilstanden når du kommer tilbake.

Treningslopp-siden

Hvert løp har en egen side som svarer på de to spørsmålene du faktisk har under trening: lærer den, og er maskinen sunn. Læringsfremdrift vises som grafer for loss, learning rate-skjemaet og gradientnormen. En loss som flater ut umiddelbart, eller en gradientnorm som eksploderer, forteller deg tidlig at løpet ikke er verdt å vente på.

Maskinhelse vises ved siden av: GPU-utnyttelse og -minne, pluss vertsmetrikkene til treningsmaskinen. En fasetidslinje viser hvor løpet befinner seg akkurat nå, fra miljøforberedelse gjennom datainnlasting, selve treningsløkken, og checkpoint-opplasting. Ser noe rart ut, gir den innebygde loggviseren deg de rå treningsloggene uten SSH-tilgang, noe som vanligvis er nok til å se om en feil ligger i datasettet ditt eller i løpet selv.

Checkpoints og gjenopptak

Checkpoints lagres per løp, ikke i en delt pool, så checkpointene listet på en løp-side hører alltid til nøyaktig det løpet og konfigurasjonen dets. Dette veier tyngre enn det høres ut: å blande checkpoints på tvers av løp med ulike innstillinger er en klassisk kilde til stille ødelagte policyer.

Blir et løp avbrutt, kan du gjenoppta fra siste checkpoint i stedet for å starte på nytt. Mellomliggende checkpoints er også nyttige på egen hånd: begynner et langt løp å overtilpasse mot slutten, kjører ofte en tidligere checkpoint bedre på den ekte armen enn den endelige.

Kjøre den trente policyen på armen din

En ferdig policy kan settes rett tilbake på roboten din. I cockpit velger du den trente policyen for den tilkoblede armen din og starter inferens: policyen produserer nå leddkommandoene du tidligere produserte gjennom teleoperasjon. Armen må være samme robottype som datasettet ble tatt opp på, og scenen bør ligne treningsscenene, inkludert kameraplassering.

Behandle de første inferensløpene som eksperimenter, ikke demonstrasjoner. Hold nødstoppen innen rekkevidde, start fra en starttilstand nær det du demonstrerte, og forvent at policyen er følsom for ting du ikke ville lagt merke til: et flyttet kamera, annet lys, eller et objekt datasettet aldri inneholdt.

Hvor mange episoder du trenger

Den vanligste treningsfeilen på plattformen er ikke en feil hyperparameter, det er trening på for lite data og deretter konklusjonen om at policytypen ikke fungerer. Som en tommelfingerregel for én bordoppgave: rundt 50 episoder gir deg en policy med snever generalisering som lykkes fra starttilstander nær dem du demonstrerte. Rundt 100 til 200 episoder gir brukbar robusthet på tvers av arbeidsområdet for den ene oppgaven, forutsatt at du varierte objektplasseringen mellom episodene.

Mer kapable policytyper opphever ikke dette. En GR00T-finjustering på 20 episoder generaliserer fortsatt dårlig; det de større modellene kjøper deg, er et høyere tak når dataene først finnes. Er budsjettet begrenset, bruk det først på flere og mer varierte episoder, deretter på en større modell.

Ofte stilte spørsmål