Trening policy

Trening bez własnego GPU

Trenowanie policy manipulacyjnej to obciążenie dla GPU, a nowoczesne modele vision-language-action potrzebują więcej VRAM, niż ma typowa stacja robocza. Na AY-Robots trening odbywa się na chmurowych GPU zarządzanych przez platformę: wybierasz dataset i typ policy, uruchamiasz przebieg i śledzisz postęp z przeglądarki. Bez konfiguracji CUDA, bez dopasowywania sterowników i bez środowiska do utrzymania.

Wejściem jest zawsze dataset w chmurze z Dashboard > Datasets. Kwalifikuje się wszystko, co nagrałeś podczas sesji teleoperacji lub przesłałeś w formacie LeRobot, w tym datasety połączone. Uporządkuj dane przed treningiem: epizody oznaczone jako Failure zwykle powinny zostać poza zbiorem treningowym, a dziesięć minut przeglądu w przeglądarce epizodów oszczędza godziny czasu GPU spędzonego na uczeniu się ze złych demonstracji.

Obsługiwane policy

Obsługiwane są cztery rodziny policy. Różnią się rozmiarem, kosztem treningu i tym, ile potrafią wchłonąć z Twoich danych, więc właściwy wybór zależy bardziej od Twojego zadania i datasetu niż od jakiegokolwiek ogólnego rankingu.

Uruchamianie przebiegu

1. 1
   Wybierz dataset

   Otwórz Dashboard > Training i wybierz dataset, na którym chcesz trenować. Liczba epizodów i typ robota są pokazane, żebyś mógł potwierdzić, że wybrałeś właściwy.

2. 2
   Wybierz policy

   Wybierz jeden z obsługiwanych typów policy. Jeśli nie masz pewności, zacznij od ACT: to najtańszy sposób, by sprawdzić, czy Twój dataset jest wystarczająco dobry, by cokolwiek na nim wytrenować.

3. 3
   Uruchom

   Uruchom przebieg. Otrzymuje job id i własną stronę przebiegu, a Ty możesz zamknąć przeglądarkę: trening trwa dalej po stronie serwera, a strona pokazuje stan na żywo, gdy wrócisz.

Strona przebiegu treningu

Każdy przebieg ma własną stronę, która odpowiada na dwa pytania, które naprawdę masz podczas treningu: czy się uczy i czy maszyna jest sprawna. Postęp uczenia jest pokazywany jako wykresy loss, harmonogramu learning rate i normy gradientu. Loss, który natychmiast się stabilizuje, albo norma gradientu, która eksploduje, wcześnie mówi, że nie warto czekać na ten przebieg.

Obok pokazany jest stan maszyny: wykorzystanie i pamięć GPU, plus metryki hosta maszyny treningowej. Oś czasu faz pokazuje, na jakim etapie aktualnie jest przebieg, od przygotowania środowiska przez wczytywanie danych i samą pętlę treningową po przesyłanie checkpointu. Gdy coś wygląda podejrzanie, wbudowana przeglądarka logów daje Ci surowe logi treningowe bez żadnego dostępu SSH, co zwykle wystarcza, by zobaczyć, czy problem leży w Twoim datasecie, czy w samym przebiegu.

Checkpointy i wznawianie

Checkpointy są przechowywane osobno dla każdego przebiegu, nie we wspólnej puli, więc checkpointy widoczne na stronie przebiegu zawsze należą dokładnie do tego przebiegu i jego konfiguracji. Ma to większe znaczenie, niż się wydaje: mieszanie checkpointów między przebiegami o różnych ustawieniach to klasyczne źródło po cichu zepsutych policy.

Jeśli przebieg zostanie przerwany, możesz wznowić go od ostatniego checkpointu zamiast zaczynać od nowa. Pośrednie checkpointy są przydatne też same w sobie: gdy długi przebieg zaczyna nadmiernie dopasowywać się pod koniec, wcześniejszy checkpoint często działa lepiej na prawdziwym ramieniu niż ten końcowy.

Uruchamianie wytrenowanej policy na własnym ramieniu

Gotową policy można wdrożyć bezpośrednio z powrotem na Twojego robota. W kokpicie wybierz wytrenowaną policy dla podłączonego ramienia i uruchom inferencję: policy teraz produkuje polecenia przegubów, które wcześniej produkowałeś przez teleoperację. Ramię musi być tego samego typu robota, na którym nagrano dataset, a scena powinna przypominać sceny treningowe, w tym ustawienie kamer.

Traktuj pierwsze przebiegi inferencji jak eksperymenty, nie jak pokazy. Trzymaj wyłącznik awaryjny w zasięgu ręki, zacznij od stanu początkowego zbliżonego do tego, co demonstrowałeś, i spodziewaj się, że policy będzie wrażliwa na rzeczy, których byś nie zauważył: przesunięta kamera, inne oświetlenie albo obiekt, którego dataset nigdy nie zawierał.

Ile epizodów potrzebujesz

Najczęstszym błędem treningowym na platformie nie jest zły hiperparametr, tylko trenowanie na zbyt małej ilości danych i wniosek, że dany typ policy nie działa. Jako zasada kciuka dla jednego zadania na blacie stołu: około 50 epizodów daje policy o wąskiej generalizacji, która radzi sobie ze stanów początkowych bliskich tym, które demonstrowałeś. Około 100 do 200 epizodów daje użyteczną odporność w całej przestrzeni roboczej dla tego jednego zadania, pod warunkiem że urozmaicałeś rozmieszczenie obiektów między epizodami.

Bardziej zaawansowane typy policy nie uchylają tej zasady. Fine-tune GR00T na 20 epizodach wciąż będzie generalizować słabo; to, co dają większe modele, to wyższy sufit, gdy dane już są. Jeśli Twój budżet jest ograniczony, wydaj go najpierw na więcej zróżnicowanych epizodów, zanim wydasz go na większy model.

Najczęściej zadawane pytania