Entraînement de politiques

Entraîner sans votre propre GPU

Entraîner une politique de manipulation est une charge de travail GPU, et les modèles vision-langage-action modernes ont besoin de plus de VRAM qu'une station de travail classique n'en possède. Sur AY-Robots, l'entraînement s'exécute sur des GPU cloud gérés par la plateforme : vous choisissez un jeu de données et un type de politique, lancez le run et suivez sa progression depuis le navigateur. Aucune installation CUDA, aucun pilote à faire correspondre, aucun environnement à maintenir.

L'entrée est toujours un jeu de données cloud provenant de Dashboard > Datasets. Tout ce que vous avez enregistré via des sessions de téléopération ou envoyé au format LeRobot est éligible, y compris les jeux de données fusionnés. Curez avant d'entraîner : les épisodes labellisés Failure n'ont généralement pas leur place dans l'ensemble d'entraînement, et dix minutes de relecture dans l'explorateur d'épisodes économisent des heures de GPU passées à apprendre à partir de mauvaises démonstrations.

Politiques prises en charge

Quatre familles de politiques sont prises en charge. Elles diffèrent par leur taille, leur coût d'entraînement et ce qu'elles peuvent absorber de vos données ; le bon choix dépend donc davantage de votre tâche et de votre jeu de données que d'un classement général.

Démarrer un run

1. 1
   Choisir le jeu de données

   Ouvrez Dashboard > Training et sélectionnez le jeu de données à utiliser pour l'entraînement. Le nombre d'épisodes et le type de robot s'affichent pour que vous puissiez confirmer avoir choisi le bon.

2. 2
   Choisir la politique

   Sélectionnez l'un des types de politique pris en charge. En cas de doute, commencez par ACT : c'est le moyen le moins coûteux de savoir si votre jeu de données est assez bon pour entraîner quoi que ce soit.

3. 3
   Lancer

   Démarrez le run. Il reçoit un identifiant de job et sa propre page de run, et vous pouvez fermer le navigateur : l'entraînement se poursuit côté serveur et la page affiche l'état en direct chaque fois que vous revenez.

La page du run d'entraînement

Chaque run dispose d'une page dédiée qui répond aux deux questions que vous vous posez réellement pendant l'entraînement : est-ce que ça apprend, et la machine est-elle en bonne santé. La progression de l'apprentissage s'affiche sous forme de graphiques de la loss, du calendrier du taux d'apprentissage et de la norme du gradient. Une loss qui plafonne immédiatement ou une norme de gradient qui explose vous indique tôt que le run ne vaut pas la peine d'être attendu.

L'état de la machine s'affiche à côté : utilisation et mémoire du GPU, plus les métriques hôte de la machine d'entraînement. Une frise chronologique des phases montre où en est le run actuellement, de la préparation de l'environnement au chargement des données, en passant par la boucle d'entraînement elle-même et l'envoi des checkpoints. Quand quelque chose semble anormal, le visualiseur de logs intégré vous donne les logs d'entraînement bruts sans aucun accès SSH, ce qui suffit généralement à voir si l'échec vient de votre jeu de données ou du run lui-même.

Checkpoints et reprise

Les checkpoints sont stockés par run, pas dans un pool partagé, si bien que les checkpoints listés sur une page de run appartiennent toujours exactement à ce run et à sa configuration. Cela compte plus qu'il n'y paraît : mélanger des checkpoints entre des runs aux réglages différents est une source classique de politiques discrètement cassées.

Si un run est interrompu, vous pouvez reprendre depuis son dernier checkpoint au lieu de tout recommencer. Les checkpoints intermédiaires sont aussi utiles en eux-mêmes : quand un long run commence à overfitter vers la fin, un checkpoint plus ancien fonctionne souvent mieux sur le vrai bras que le dernier.

Exécuter la politique entraînée sur votre bras

Une politique terminée peut être redéployée directement sur votre robot. Dans le cockpit, sélectionnez la politique entraînée pour votre bras connecté et démarrez l'inférence : la politique produit désormais les commandes articulaires que vous produisiez auparavant par téléopération. Le bras doit être du même type de robot que celui sur lequel le jeu de données a été enregistré, et la scène doit ressembler aux scènes d'entraînement, y compris le positionnement des caméras.

Traitez les premières exécutions d'inférence comme des expériences, pas comme des démonstrations. Gardez l'arrêt d'urgence à portée de main, partez d'un état de départ proche de ce que vous avez démontré, et attendez-vous à ce que la politique soit sensible à des choses que vous ne remarqueriez pas : une caméra déplacée, un éclairage différent, ou un objet que le jeu de données n'a jamais contenu.

Combien d'épisodes vous faut-il

L'erreur d'entraînement la plus courante sur la plateforme n'est pas un mauvais hyperparamètre, c'est d'entraîner sur trop peu de données et d'en conclure que le type de politique ne fonctionne pas. Règle empirique pour une seule tâche de table : environ 50 épisodes vous donnent une politique à généralisation étroite qui réussit depuis des états de départ proches de ceux que vous avez démontrés. Environ 100 à 200 épisodes donnent une robustesse exploitable sur l'ensemble de l'espace de travail pour cette tâche, à condition d'avoir varié le placement des objets entre les épisodes.

Des types de politiques plus performants n'abolissent pas cette règle. Un fine-tune de GR00T sur 20 épisodes généralisera quand même mal ; ce que les modèles plus grands vous apportent, c'est un meilleur potentiel une fois les données réunies. Si votre budget est limité, dépensez-le d'abord dans des épisodes plus variés, puis dans un modèle plus grand.

Questions fréquentes