Treinamento local: instalação e primeira verificação

1. Crie um ambiente separado e com versão.

Use uma máquina com driver NVIDIA compatível e GPU compatível com CUDA. Se você estiver escolhendo um computador, primeiro leia a comparação de ambientes. Instale Git e uv a partir de suas instruções oficiais ↗. Execute o seguinte em um diretório pai onde microduck-rl-first-run ainda não exista.

git clone https://github.com/pollen-robotics/microduck_rl.git microduck-rl-first-run
cd microduck-rl-first-run
git checkout --detach 2b25a48b08f1f17bc38c90bb03144c81fbd9ed07
uv python install 3.12
uv sync --locked --python 3.12

O projeto examinado aceita Python 3.12 e exclui 3.13. A cópia local em modo detached mantém este tutorial em uma única revisão; ela não atualiza um projeto existente. --locked exige que o arquivo de lock corresponda ao projeto, em vez de resolver silenciosamente novas dependências. Se houver divergência, salve o erro em vez de excluir o arquivo de lock. Fontes: Python, versões fixadas das dependências e pacotes ARM ↗, uv: instalar uma versão específica do Python ↗ e uv: bloquear e sincronizar um projeto ↗.

2. Verifique o ambiente que irá realizar o treinamento.

uv run python - <<'PY'
import platform
import torch
print("Python:", platform.python_version())
print("Machine:", platform.system(), platform.machine())
print("PyTorch:", torch.__version__)
print("Built for CUDA:", torch.version.cuda)
print("CUDA available:", torch.cuda.is_available())
print("GPU count:", torch.cuda.device_count())
if torch.cuda.is_available():
    print("GPU:", torch.cuda.get_device_name(0))
PY

Para esta rota CUDA, espere Python 3.12.x, uma versão CUDA do PyTorch, CUDA available: True e pelo menos uma GPU visível. Isso verifica a descoberta, não a capacidade de memória ou a compatibilidade completa do treinamento. Se a importação do PyTorch falhar, mantenha esse rastreamento e use o guia de solução de problemas de dependência. PyTorch: verificando a disponibilidade do CUDA ↗ explica a verificação de disponibilidade.

uv run list-envs

Encontre Mjlab-Velocity-Flat-MicroDuck na saída antes de usá-lo abaixo. Se estiver faltando, verifique o checkout e o projeto instalado em vez de copiar o nome de uma tarefa de outra fork. Início rápido do MicroDuck RL e registro de tarefas ↗.

3. Execute uma breve verificação de instalação.

uv run train Mjlab-Velocity-Flat-MicroDuck \
  --env.scene.num-envs 64 \
  --agent.max_iterations 5

Isso inicia o trabalho real da GPU local. Escolhemos 64 ambientes e 5 iterações para manter a verificação limitada; eles não são um mínimo de hardware publicado. Uma passagem útil é a inicialização da tarefa e os logs de iteração avançando sem exceção. Se a execução parar devido a uma solicitação de conta ou registro em log, conclua a configuração solicitada e repita a mesma verificação. Se falhar, registre o primeiro erro e a última etapa bem-sucedida.

Assim que a pequena execução funcionar, planeje uma execução mais longa em torno da memória da GPU e do orçamento de tempo. O aumento de ambientes paralelos ou iterações altera o experimento; registre essas escolhas. Não se espera que uma política treinada para cinco iterações funcione bem.

4. Mantenha o ponto de verificação e seu contexto.

Salve o caminho do ponto de verificação real ou o caminho da execução W&B impresso pela sua execução, juntamente com o ID da tarefa e a configuração. Um posto de controle de treinamento .pt é um insumo para o exportador; alterar sua extensão não o transforma em um modelo implantável. Continue com o guia de exportação e reprodução ONNX.

Data e objetivo:
URL do repositório e commit completo:
Mudanças ainda não commitadas:
Sistema / arquitetura / Python / uv:
GPU / driver / PyTorch / versão CUDA:
ID da tarefa:
Comando exato:
Número de ambientes / limite de iterações / semente:
URL da execução e caminho do checkpoint:
O que inicializou corretamente:
Resultado observado ou primeiro erro:
Uma mudança para a próxima tentativa:

5. Visualize uma rota de nuvem se a computação local for inadequada.

Em uma cópia local já configurada, o script oficial pode preparar a especificação de uma tarefa sem enviar uma tarefa à GPU. A autenticação está documentada no guia de envio de tarefas do MicroDuck para a nuvem ↗. O exemplo abaixo define um limite de uma hora; isso não é uma promessa de conclusão nesse prazo.

uv run train Mjlab-Velocity-Flat-MicroDuck \
  --env.scene.num-envs 64 \
  --agent.max_iterations 5 \
  --hf-jobs --timeout 1h --dry-run

A visualização prepara um arquivo de origem local e imprime a especificação do trabalho. Inspecione o hardware, o namespace e os arquivos de origem; remova segredos locais de qualquer coisa que seria carregada. Somente a remoção de --dry-run inicia o caminho de envio. Um Mac ainda pode encontrar problemas de dependência ou importação antes de chegar a esse wrapper; um destino na nuvem não ignora os requisitos do iniciador local. Implementação de envio em nuvem e exportação de ponto de verificação ↗.

Antes de enviar, leia Hugging Face Jobs: preços e faturamento atuais ↗. Após o envio, mantenha a URL da vaga. Ctrl-C desanexa o fluxo de log do MicroDuck; isso não cancela o trabalho remoto. Cancele na página de trabalho ou siga Hugging Face: gerenciando e cancelando trabalhos ↗ e verifique seu estado parado.

Continue com seu resultado.