Policyträning

Träning utan egen GPU

Att träna en manipulationspolicy är en GPU-arbetslast, och moderna vision-language-action-modeller behöver mer VRAM än en typisk arbetsstation har. På AY-Robots körs träningen på molnbaserade GPU:er som hanteras av plattformen: du väljer ett dataset och en policytyp, startar körningen och följer dess framsteg från webbläsaren. Ingen CUDA-installation, ingen drivrutinsmatchning och ingen miljö att underhålla.

Indatat är alltid ett molndataset från Dashboard > Datasets. Allt du spelat in via teleopereringssessioner eller laddat upp i LeRobot-format är kvalificerat, inklusive sammanslagna dataset. Kuratera innan du tränar: episoder märkta Failure hör vanligtvis inte hemma i träningsuppsättningen, och tio minuters granskning i episodbläddraren sparar timmar av GPU-tid som annars går åt till att lära sig av dåliga demonstrationer.

Policyer som stöds

Fyra policyfamiljer stöds. De skiljer sig i storlek, träningskostnad och hur mycket de kan ta upp från ditt data, så rätt val beror mer på din uppgift och ditt dataset än på någon generell rankning.

Starta en körning

1. 1
   Välj datasetet

   Öppna Dashboard > Training och välj datasetet att träna på. Episodantalet och robottypen visas så att du kan bekräfta att du valde rätt.

2. 2
   Välj policyn

   Välj en av de policytyper som stöds. Är du osäker, börja med ACT: det är det billigaste sättet att ta reda på om ditt dataset är tillräckligt bra för att träna någonting alls.

3. 3
   Starta

   Starta körningen. Den får ett job-id och en egen körningssida, och du kan stänga webbläsaren: träningen fortsätter serversidan och sidan visar det aktuella läget när du kommer tillbaka.

Träningskörningens sida

Varje körning har en dedikerad sida som svarar på de två frågor du faktiskt har under träning: lär den sig, och är maskinen frisk. Träningsframsteg visas som grafer över förlusten, schemat för inlärningshastigheten och gradientnormen. En förlust som planar ut omedelbart eller en gradientnorm som exploderar berättar tidigt att körningen inte är värd att vänta på.

Maskinens hälsa visas bredvid: GPU-användning och minne, plus värdmaskinens systemmått. En fastidslinje visar var körningen befinner sig just nu, från miljöförberedelse genom dataladdning, själva träningsloopen, och checkpoint-uppladdning. När något ser fel ut ger den inbyggda loggvisaren dig de råa träningsloggarna utan någon SSH-åtkomst, vilket vanligtvis räcker för att se om ett fel beror på ditt dataset eller körningen själv.

Checkpoints och återupptagning

Checkpoints lagras per körning, inte i en delad pool, så checkpointerna listade på en körningssida hör alltid till exakt den körningen och dess konfiguration. Det spelar större roll än det låter: att blanda checkpoints mellan körningar med olika inställningar är en klassisk källa till tyst trasiga policyer.

Avbryts en körning kan du återuppta från dess senaste checkpoint i stället för att börja om. Mellanliggande checkpoints är också värdefulla på egen hand: när en lång körning börjar överanpassa mot slutet fungerar en tidigare checkpoint ofta bättre på den riktiga armen än den slutgiltiga.

Köra den tränade policyn på din arm

En färdig policy kan distribueras direkt tillbaka till din robot. I cockpiten väljer du den tränade policyn för din anslutna arm och startar inferens: policyn producerar nu ledkommandona du tidigare producerade genom teleoperering. Armen måste vara samma robottyp som datasetet spelades in på, och scenen bör likna träningsscenerna, inklusive kameraplacering.

Behandla de första inferenskörningarna som experiment, inte demos. Håll nödstoppet inom räckhåll, starta från ett starttillstånd nära det du demonstrerade, och förvänta dig att policyn är känslig för saker du inte skulle lägga märke till: en flyttad kamera, annorlunda belysning, eller ett objekt datasetet aldrig innehöll.

Hur många episoder du behöver

Det vanligaste träningsmisstaget på plattformen är inte en felaktig hyperparameter, det är att träna på för lite data och dra slutsatsen att policytypen inte fungerar. Som tumregel för en enskild bordsuppgift: runt 50 episoder ger dig en policy med smal generalisering som lyckas från starttillstånd nära dem du demonstrerade. Runt 100 till 200 episoder ger användbar robusthet över arbetsytan för den ena uppgiften, förutsatt att du varierade objektplaceringen mellan episoderna.

Mer kapabla policytyper upphäver inte detta. En GR00T-finjustering på 20 episoder generaliserar fortfarande dåligt; vad de större modellerna köper dig är ett bättre tak när datat väl finns där. Är din budget begränsad, spendera den på fler varierade episoder innan du spenderar den på en större modell.

Vanliga frågor