Policytræning

Træning uden din egen GPU

At træne en manipulationspolicy er en GPU-arbejdsbyrde, og moderne vision-language-action-modeller kræver mere VRAM, end en typisk arbejdsstation har. På AY-Robots kører træningen på cloud-GPU'er, som administreres af platformen: du vælger et datasæt og en policytype, starter kørslen og følger dens fremskridt fra browseren. Ingen CUDA-opsætning, ingen drivermatch, og intet miljø at vedligeholde.

Inputtet er altid et skydatasæt fra Dashboard > Datasets. Alt, du har optaget gennem teleoperationssessioner eller uploadet i LeRobot-formatet, er kvalificeret, inklusive flettede datasæt. Kurater, før du træner: episoder mærket Failure hører normalt ikke hjemme i træningssættet, og ti minutters gennemgang i episodebrowseren sparer timers GPU-tid brugt på at lære af dårlige demonstrationer.

Understøttede policyer

Fire policyfamilier understøttes. De adskiller sig i størrelse, træningsomkostning og hvor meget de kan optage fra dine data, så det rette valg afhænger mere af din opgave og dit datasæt end af nogen generel rangering.

Start en kørsel

1. 1
   Vælg datasættet

   Åbn Dashboard > Training, og vælg det datasæt, du vil træne på. Episodeantal og robottype vises, så du kan bekræfte, at du valgte det rigtige.

2. 2
   Vælg policyen

   Vælg én af de understøttede policytyper. Er du i tvivl, start med ACT: det er den billigste måde at finde ud af, om dit datasæt er godt nok til at træne overhovedet noget.

3. 3
   Start

   Start kørslen. Den får et job-id og sin egen kørselsside, og du kan lukke browseren: træningen fortsætter serverside, og siden viser den aktuelle tilstand, når du kommer tilbage.

Siden om træningskørsler

Hver kørsel har en dedikeret side, der besvarer de to spørgsmål, du reelt har under træning: lærer den, og er maskinen sund. Læringsfremskridt vises som grafer over tabet, læringsratens skema og gradientnormen. Et tab, der straks flader ud, eller en gradientnorm, der eksploderer, fortæller dig tidligt, at kørslen ikke er værd at vente på.

Maskinens sundhed vises ved siden af: GPU-udnyttelse og hukommelse, plus værtsmaskinens systemmetrikker. En fasetidslinje viser, hvor kørslen aktuelt befinder sig, fra miljøforberedelse gennem dataindlæsning, selve træningsløkken og checkpoint-upload. Når noget ser skævt ud, giver den indbyggede logviewer dig de rå træningslogfiler uden nogen SSH-adgang, hvilket normalt er nok til at se, om en fejl skyldes dit datasæt eller kørslen selv.

Checkpoints og genoptagelse

Checkpoints gemmes per kørsel, ikke i en delt pulje, så de checkpoints, der er listet på en kørselsside, hører altid til netop den kørsel og dens konfiguration. Det betyder mere, end det lyder til: at blande checkpoints på tværs af kørsler med forskellige indstillinger er en klassisk kilde til stille ødelagte policyer.

Bliver en kørsel afbrudt, kan du genoptage fra dens seneste checkpoint i stedet for at starte forfra. Mellemliggende checkpoints er også nyttige i sig selv: når en lang kørsel begynder at overtilpasse mod slutningen, kører et tidligere checkpoint ofte bedre på den rigtige arm end det endelige.

Kør den trænede policy på din arm

En færdig policy kan udrulles direkte tilbage til din robot. I cockpittet vælger du den trænede policy til din tilsluttede arm og starter inferens: policyen producerer nu de ledkommandoer, du tidligere producerede ved teleoperation. Armen skal være samme robottype, som datasættet blev optaget på, og scenen bør ligne træningsscenerne, inklusive kameraplacering.

Betragt de første inferenskørsler som eksperimenter, ikke demoer. Hold nødstoppet inden for rækkevidde, start fra en starttilstand tæt på det, du demonstrerede, og forvent, at policyen er følsom over for ting, du ikke ville lægge mærke til: et flyttet kamera, anderledes belysning eller et objekt, datasættet aldrig indeholdt.

Hvor mange episoder du har brug for

Den mest almindelige træningsfejl på platformen er ikke en forkert hyperparameter, det er at træne på for lidt data og konkludere, at policytypen ikke virker. Som tommelfingerregel for én bordopgave: omkring 50 episoder giver dig en policy med snæver generalisering, der lykkes fra starttilstande tæt på dem, du demonstrerede. Omkring 100 til 200 episoder giver brugbar robusthed på tværs af arbejdsområdet for netop den opgave, forudsat at du varierede objektplaceringen mellem episoderne.

Mere kapable policytyper ophæver ikke dette. En GR00T-finjustering på 20 episoder vil stadig generalisere dårligt; det, de større modeller giver dig, er et bedre loft, når dataene først er der. Er dit budget begrænset, så brug det på flere varierede episoder, før du bruger det på en større model.

Ofte stillede spørgsmål