Entrenamiento local: instalación y primera prueba

1. Cree un entorno versionado independiente.

Utilice una máquina con un controlador NVIDIA compatible y una GPU compatible con CUDA. Si elige una computadora, primero lea la comparación de entornos. Instale Git y uv desde sus instrucciones oficiales ↗. Ejecute lo siguiente desde un directorio principal donde microduck-rl-first-run aún no existe.

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

El proyecto examinado admite Python 3.12 y excluye 3.13. La copia local en modo detached mantiene este tutorial en una única revisión; no actualiza un proyecto existente. --locked exige que el archivo de bloqueo coincida con el proyecto, en lugar de resolver silenciosamente nuevas dependencias. Si indica una discrepancia, guarda el error y no borres el archivo de bloqueo. Fuentes: Python, versiones fijadas de dependencias y paquetes ARM ↗, uv: instalar una versión concreta de Python ↗ y uv: bloquear y sincronizar un proyecto ↗.

2. Comprueba el entorno que ejecutará el entrenamiento.

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 ruta CUDA, espere Python 3.12.x, una compilación CUDA de PyTorch, CUDA available: True y al menos una GPU visible. Esto verifica el descubrimiento, no la capacidad de memoria o la compatibilidad completa del entrenamiento. Si la importación de PyTorch falla, conserve ese rastreo y use la guía de solución de problemas de dependencias. PyTorch: verificar la disponibilidad de CUDA ↗ explica la verificación de disponibilidad.

uv run list-envs

Busque Mjlab-Velocity-Flat-MicroDuck en la salida antes de usarlo a continuación. Si falta, verifique la copia local del repositorio y el proyecto instalado en lugar de copiar el nombre de una tarea de otra fork. Inicio rápido y registro de tareas de MicroDuck RL ↗.

3. Ejecute una breve verificación de la instalación.

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

Esto inicia el trabajo real de la GPU local. Elegimos 64 entornos y 5 iteraciones para mantener la verificación limitada; no son un mínimo de hardware publicado. Un paso útil es la inicialización de la tarea y el avance de los registros de iteración sin excepción. Si la ejecución se detiene para una cuenta o un mensaje de registro, complete la configuración solicitada y repita la misma verificación. Si falla, registre el primer error y la última etapa exitosa.

Una vez que la tirada pequeña funcione, planifique una tirada más larga según la memoria de su GPU y su presupuesto de tiempo. El aumento de entornos paralelos o iteraciones cambia el experimento; registrar esas elecciones. No se espera que una política entrenada para cinco iteraciones funcione bien.

4. Mantenga el punto de control y su contexto.

Guarde la ruta del punto de control real o la ruta de ejecución de W&B impresa por su ejecución, junto con el ID de la tarea y la configuración. Un punto de control de entrenamiento .pt es un insumo para el exportador; cambiar su extensión no lo convierte en un modelo desplegable. Continúe con la guía de reproducción y exportación de ONNX.

Fecha y objetivo:
URL del repositorio y commit completo:
Cambios sin confirmar:
Sistema / arquitectura / Python / uv:
GPU / controlador / PyTorch / versión CUDA:
ID de tarea:
Comando exacto:
Número de entornos / límite de iteraciones / semilla:
URL de ejecución y ruta del checkpoint:
Qué se inicializó correctamente:
Resultado observado o primer error:
Un cambio para el siguiente intento:

5. Obtenga una vista previa de una ruta en la nube si la computación local no es adecuada.

En una copia local ya configurada, el script oficial puede preparar la especificación de una tarea sin enviar una tarea a la GPU. La configuración de autenticación se explica en la guía de envío de tareas de MicroDuck a la nube ↗. El ejemplo siguiente fija un límite de una hora; no promete que la tarea termine en ese tiempo.

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

La vista previa prepara un archivo fuente local e imprime la especificación del trabajo. Inspeccionar el hardware, el espacio de nombres y los archivos fuente; eliminar secretos locales de cualquier cosa que se cargue. Solo al eliminar --dry-run se inicia la ruta de envío. Una Mac aún puede encontrar problemas de dependencia o de importación antes de llegar a este contenedor; un destino en la nube no pasa por alto los requisitos del iniciador local. Envío a la nube e implementación de exportación de puntos de control ↗.

Antes de enviar, lea Trabajos de cara de abrazo: precios y facturación actuales ↗. Después del envío, conserve la URL del trabajo. Ctrl-C desconecta el flujo de registro de MicroDuck; no cancela el trabajo remoto. Cancelar desde la página de trabajos o seguir Hugging Face: administrar y cancelar trabajos ↗, y verificar su estado detenido.

Continúe con su resultado.