Treino de policies

Treino sem GPU própria

Treinar uma policy de manipulação é uma carga de trabalho para GPU, e os modelos vision-language-action modernos precisam de mais VRAM do que uma workstation típica tem. Na AY-Robots o treino corre em GPUs na cloud geridas pela plataforma: escolhe um dataset e um tipo de policy, inicia a execução e acompanha o progresso a partir do browser. Não há configuração de CUDA, nem correspondência de drivers, nem ambiente para manter.

A entrada é sempre um dataset na cloud de Dashboard > Datasets. Tudo o que gravou através de sessões de teleoperação ou carregou no formato LeRobot é elegível, incluindo datasets combinados. Cure antes de treinar: episódios rotulados como Failure geralmente devem ficar fora do conjunto de treino, e dez minutos de revisão no explorador de episódios poupam horas de tempo de GPU gastas a aprender com demonstrações más.

Policies suportadas

São suportadas quatro famílias de policy. Diferem em tamanho, custo de treino e quanto conseguem absorver dos seus dados, por isso a escolha certa depende mais da sua tarefa e do seu dataset do que de qualquer classificação geral.

Iniciar uma execução

1. 1
   Escolha o dataset

   Abra Dashboard > Training e selecione o dataset a usar no treino. A contagem de episódios e o tipo de robô são mostrados para que possa confirmar que escolheu o certo.

2. 2
   Escolha a policy

   Selecione um dos tipos de policy suportados. Se tiver dúvidas, comece pela ACT: é a forma mais barata de descobrir se o seu dataset é suficientemente bom para treinar alguma coisa.

3. 3
   Inicie

   Inicie a execução. Recebe um job id e a sua própria página de execução, e pode fechar o browser: o treino continua no servidor e a página mostra o estado em direto sempre que voltar.

A página de execução de treino

Cada execução tem uma página dedicada que responde às duas perguntas que realmente tem durante o treino: está a aprender, e a máquina está saudável. O progresso da aprendizagem é mostrado como gráficos do loss, do agendamento da learning rate e da norma do gradiente. Um loss que estagna imediatamente ou uma norma do gradiente que explode indicam cedo que não vale a pena esperar por essa execução.

A saúde da máquina é mostrada ao lado: utilização e memória da GPU, mais as métricas de host da máquina de treino. Uma linha temporal de fases mostra em que ponto a execução está, desde a preparação do ambiente, passando pelo carregamento de dados e o próprio ciclo de treino, até ao upload do checkpoint. Quando algo parece estranho, o visualizador de logs integrado dá-lhe os logs de treino em bruto sem qualquer acesso SSH, o que costuma ser suficiente para perceber se uma falha vem do seu dataset ou da própria execução.

Checkpoints e retomar

Os checkpoints são armazenados por execução, não numa reserva partilhada, pelo que os checkpoints listados numa página de execução pertencem sempre exatamente a essa execução e à sua configuração. Isto pesa mais do que parece: misturar checkpoints entre execuções com definições diferentes é uma fonte clássica de policies silenciosamente avariadas.

Se uma execução for interrompida, pode retomar a partir do seu checkpoint mais recente em vez de recomeçar do zero. Os checkpoints intermédios também são úteis por si só: quando uma execução longa começa a sofrer overfitting perto do fim, um checkpoint anterior corre muitas vezes melhor no braço real do que o final.

Correr a policy treinada no seu braço

Uma policy concluída pode ser implementada diretamente de volta no seu robô. No cockpit, selecione a policy treinada para o seu braço ligado e inicie a inferência: a policy passa agora a produzir os comandos de junta que antes vinham da sua teleoperação. O braço tem de ser do mesmo tipo de robô em que o dataset foi gravado, e a cena deve parecer-se com as cenas de treino, incluindo o posicionamento das câmaras.

Trate as primeiras execuções de inferência como experiências, não como demonstrações. Mantenha a paragem de emergência ao alcance, comece a partir de um estado inicial próximo do que demonstrou, e conte com a policy ser sensível a coisas que não notaria: uma câmara deslocada, iluminação diferente ou um objeto que o dataset nunca continha.

Quantos episódios precisa

O erro de treino mais comum na plataforma não é um hiperparâmetro errado, é treinar com poucos dados e concluir que o tipo de policy não funciona. Como regra prática para uma única tarefa de tabuleiro: cerca de 50 episódios dão-lhe uma policy com generalização estreita que tem sucesso a partir de estados iniciais próximos dos que demonstrou. Cerca de 100 a 200 episódios dão robustez utilizável em todo o espaço de trabalho para essa tarefa, desde que tenha variado a colocação dos objetos entre episódios.

Tipos de policy mais capazes não revogam esta regra. Um fine-tune do GR00T com 20 episódios continua a generalizar mal; o que os modelos maiores lhe dão é um teto mais alto assim que os dados existirem. Se o seu orçamento for limitado, gaste-o primeiro em mais episódios variados antes de o gastar num modelo maior.

Perguntas frequentes