Entraînement local : installation et premier essai

1. Créez un environnement versionné distinct.

Utilisez une machine avec un pilote NVIDIA compatible et un GPU compatible CUDA. Si vous choisissez un ordinateur, lisez d'abord la comparaison des environnements. Installez Git et uv à partir de ses instructions officielles ↗. Exécutez ce qui suit à partir d'un répertoire parent où microduck-rl-first-run n'existe pas déjà.

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

Le projet examiné accepte Python 3.12 et exclut 3.13. La copie locale en mode detached maintient ce tutoriel sur une seule révision ; elle ne met pas à jour un projet existant. --locked exige que le fichier de verrouillage corresponde au projet, au lieu de résoudre silencieusement un nouvel ensemble de dépendances. S’il signale une différence, conservez l’erreur plutôt que de supprimer le fichier de verrouillage. Sources : Python, versions figées des dépendances et paquets ARM ↗, uv : installer une version précise de Python ↗ et uv : verrouiller et synchroniser un projet ↗.

2. Vérifiez l’environnement qui exécutera l’entraînement.

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

Pour cette route CUDA, attendez-vous à Python 3.12.x, une version CUDA de PyTorch, CUDA available: True et au moins un GPU visible. Cela vérifie la découverte, pas la capacité de mémoire ou la compatibilité complète de l’entraînement. Si l'importation de PyTorch lui-même échoue, conservez cette trace et utilisez le guide de dépannage des dépendances. PyTorch : vérifier la disponibilité de CUDA ↗ explique le contrôle de disponibilité.

uv run list-envs

Recherchez Mjlab-Velocity-Flat-MicroDuck dans la sortie avant de l'utiliser ci-dessous. S'il est manquant, vérifiez l'extraction et le projet installé plutôt que de copier un nom de tâche à partir d'un autre fork. Démarrage rapide et registre des tâches MicroDuck RL ↗.

3. Exécutez une brève vérification de l'installation.

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

Cela démarre un véritable travail de GPU local. Nous avons choisi 64 environnements et 5 itérations pour limiter le contrôle ; il ne s'agit pas d'un minimum matériel publié. Une passe utile est l'initialisation de la tâche et l'avancement des journaux d'itérations sans exception. Si l'exécution s'arrête pour une invite de compte ou de journalisation, terminez la configuration demandée et répétez la même vérification. En cas d'échec, enregistrez la première erreur et la dernière étape réussie.

Une fois la petite exécution réussie, prévoyez une exécution plus longue en fonction de votre mémoire GPU et de votre budget temps. L'augmentation des environnements ou des itérations parallèles modifie l'expérience ; enregistrez ces choix. On ne s’attend pas à ce qu’une politique entraînée pour cinq itérations fonctionne bien.

4. Conservez le point de contrôle et son contexte.

Enregistrez le chemin du point de contrôle réel ou le chemin d'exécution W&B imprimé par votre exécution, ainsi que l'ID de la tâche et la configuration. Un point de contrôle d’entraînement .pt est une entrée pour l'exportateur ; changer son extension ne le transforme pas en un modèle déployable. Continuez avec le guide d'exportation et de relecture ONNX.

Date et objectif :
URL du dépôt et commit complet :
Modifications non commitées :
Système / architecture / Python / uv :
GPU / pilote / PyTorch / version CUDA :
Identifiant de tâche :
Commande exacte :
Nombre d’environnements / limite d’itérations / graine :
URL de l’exécution et chemin du checkpoint :
Éléments initialisés correctement :
Résultat observé ou première erreur :
Une modification pour le prochain essai :

5. Prévisualisez une route cloud si le calcul local n'est pas adapté.

Dans une copie locale déjà configurée, le script officiel peut préparer la description d’une tâche sans envoyer de tâche GPU. L’authentification est expliquée dans le guide d’envoi des tâches MicroDuck dans le cloud ↗. L’exemple ci-dessous fixe un plafond d’une heure ; ce n’est pas une promesse de durée d’exécution.

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

L'aperçu prépare une archive source locale et imprime la spécification du travail. Inspecter le matériel, l'espace de noms et les fichiers sources ; supprimez les secrets locaux de tout ce qui serait téléchargé. Seule la suppression de --dry-run démarre le chemin de soumission. Un Mac peut encore rencontrer des problèmes de dépendance ou d'importation avant d'atteindre ce wrapper ; une destination cloud ne contourne pas les exigences du lanceur local. Implémentation de la soumission dans le cloud et de l'exportation des points de contrôle ↗.

Avant de soumettre, lisez Hugging Face Jobs : tarifs et facturation actuels ↗. Après la soumission, conservez l'URL du travail. Ctrl-C détache le flux de journal MicroDuck ; cela n'annule pas le travail à distance. Annulez depuis la page du travail ou suivez Hugging Face : gestion et annulation des travaux ↗, et vérifiez son état d'arrêt.

Continuez avec votre résultat.