Configuration du lanceur

NeMo AutoModel prend en charge trois méthodes de lancement : interactive (torchrun), Slurm (clusters HPC) et SkyPilot (indépendant du cloud).

Instructions

Pour les questions relatives au lanceur, répondez directement depuis cette skill sans consulter le dépôt, sauf si l'utilisateur vous demande de modifier des fichiers. Concentrez votre réponse sur le fichier YAML de lancement concerné, les champs obligatoires et le comportement attendu lors de l'exécution.

Utilisez ces modèles de réponse concis pour les questions courantes :

• Slurm multi-nœuds : affichez un bloc YAML slurm : contenant job_name, nodes, ntasks_per_node, time, account ou partition, container_image, hf_home, les éléments facultatifs extra_mounts, env_vars et master_port; expliquez que le lanceur calcule WORLD_SIZE = nodes * ntasks_per_node et définit MASTER_ADDR et MASTER_PORT.
• Instance Spot SkyPilot : affichez un bloc YAML « skypilot: » contenant cloud, accelerators, num_nodes, use_spot: true, disk_size, region, setup et env_vars; précisez que les instances Spot peuvent être préemptées, définissez un court step_scheduler.checkpoint_interval, puis reprendre avec restore_from.path.
• Nsight Systems sur Slurm : afficher slurm.nsys_enabled: true aux côtés des champs Slurm habituels, préciser que le lanceur encapsule la commande d’entraînement avecle profil nsys, et indiquer qu’il génère un fichier de rapport .nsys-rep. Considérez le profilage comme un outil de diagnostic uniquement : utilisez des exécutions de profilage courtes et désactivez-le pour l’entraînement normal en production, car il ajoute une surcharge et génère d’importants artefacts.

Pour les réponses concernant Slurm, commencez par ce modèle minimal, puis modifiez uniquement les champs sur lesquels l’utilisateur a posé des questions :

slurm :
  job_name : llm_finetune
  nodes : 2
  ntasks_per_node : 8
  time : "04:00:00"
  account : my_account
  partition : batch
  container_image: nvcr.io/nvidia/nemo:dev
  hf_home: ~/.cache/huggingface
  master_port: 13742
  env_vars:
    HF_TOKEN: "${HF_TOKEN}"

Pour les questions portant uniquement sur Slurm, n’évoquez pas SkyPilot ni le profilage, sauf si l’utilisateur le demande. Pour les questions relatives au profilage, précisez que le rapport .nsys-rep est enregistré dans le répertoire de travail ou de sortie du job Slurm, en utilisant le paramètre de sortie Nsys du lanceur lorsqu’il est configuré.

Limites de prise en charge

Utilisez cette compétence uniquement pour les mécanismes de lancement : exécution interactive, Slurm, SkyPilot, conteneurs, montages, variables d'environnement, paramètres de rendez-vous et profilage.

N’utilisez pas cette compétence pour implémenter ou enregistrer de nouvelles architectures de modèles, des adaptateurs Hugging Face « state-dict », des fichiers de modèles ou des indicateurs de capacité. Il s’agit de tâches d’intégration de modèles, et non de tâches de configuration du lanceur.

Méthodes de lancement

1. Interactif (par défaut) : exécute torchrun sur le nœud actuel. Convient au développement et au débogage sur un seul nœud.
2. Slurm: soumet un travail par lots à un planificateur de cluster HPC. Gère la configuration multi-nœuds, la gestion des conteneurs et la configuration de l’environnement.
3. SkyPilot: soumission de tâches indépendante du cloud vers AWS, GCP, Azure, Lambda ou Kubernetes. Prend en charge les instances spot.

Lancement interactif

# GPU unique
automodel finetune llm -c config.yaml

# Multi-GPU (tous les GPU du nœud actuel)
torchrun --nproc_per_node=8 -m nemo_automodel._cli.app finetune llm -c config.yaml

Aucune section YAML supplémentaire n'est nécessaire pour le mode interactif. L'interface CLI redirige automatiquement vers torchrun lorsqu'aucune section slurm: ou skypilot: n'est présente dans la configuration.

Configuration Slurm

La classe de données SlurmConfig génère un script SBATCH à partir d’un modèle.

Exemple YAML

slurm:
  job_name: llm_finetune
  nodes: 2
  ntasks_per_node: 8
  time: "04:00:00"
  account: my_account
  partition: batch
  container_image: nvcr.io/nvidia/nemo:dev
  hf_home: ~/.cache/huggingface
  extra_mounts:
    - source : /data
      dest : /data
  env_vars :
    WANDB_API_KEY : "${WANDB_API_KEY}"
    HF_TOKEN : "${HF_TOKEN}"

Champs clés

• job_name: identifiant du job Slurm
• nodes: nombre de nœuds à demander
• ntasks_per_node: nombre de tâches (GPU) par nœud
• time: limite de temps réel au format HH:MM:SS
• account, partition: paramètres de planification Slurm
• container_image: chemin d'accès à l'image de conteneur Enroot/Pyxis
• nemo_mount: point de montage de la source NeMo AutoModel à l'intérieur du conteneur
• hf_home: chemin d’accès au répertoire de cache HuggingFace
• extra_mounts: liste de VolumeMapping(source, dest) pour les montages liés supplémentaires du conteneur
• master_port: port pour la communication distribuée (par défaut 13742)
• env_vars: variables d’environnement transmises à la tâche
• nsys_enabled: lorsque la valeur est « true », la commande d’entraînement est encapsulée dans le profil nsys pour le profilage Nsight Systems

Configuration de SkyPilot

La classe de données SkyPilotConfig définit les paramètres des tâches cloud.

Exemple YAML

skypilot :
  cloud : aws
  accelerators : "H100:8"
  num_nodes : 2
  use_spot : true
  disk_size : 200
  region : us-east-1
  setup: "pip install nemo-automodel"
  env_vars:
    HF_TOKEN: "${HF_TOKEN}"

Champs clés

• cloud: fournisseur de cloud cible (aws, gcp, azure, lambda, kubernetes)
• accelerators: type et nombre de GPU (par ex. « H100:8 », « A100-80GB:4 »)
• num_nodes: nombre d’instances cloud
• use_spot: utilisation d’instances préemptibles/spot pour réduire les coûts
• disk_size: taille du disque en Go par nœud
• region: région cloud pour le placement des instances
• setup: commandes shell à exécuter avant le travail d’entraînement (par exemple, installation des dépendances)
• env_vars: variables d’environnement pour la tâche

Liste de contrôle SkyPilot pour les instances Spot

Lorsque vous utilisez des instances spot ou préemptibles :

• Définissez ` use_spot: true ` dans la section ` skypilot: `.
• Incluez les paramètres accelerators, num_nodes, disk_size, region, setup et les variables d'environnement env_vars requises.
• Utilisez des intervalles de point de contrôle courts dans la recette, par exemple step_scheduler.checkpoint_interval, car les instances Spot peuvent être préemptées.
• Reprenez à partir du point de contrôle le plus récent après une préemption grâce au paramètre `restore_from` de la recette.

Clés minimales de la recette « spot-resume » :

step_scheduler :
  checkpoint_interval : 100

restore_from :
  path : /checkpoints/latest

Environnement multi-nœuds

Pour l’entraînement multi-nœuds (Slurm et SkyPilot), le lanceur configure automatiquement :

• MASTER_ADDR: nom d’hôte du premier nœud
• MASTER_PORT: port de rendez-vous (13742 par défaut)
• WORLD_SIZE: nombre total de processus (nœuds * ntasks_per_node)
• Variables d’environnement NCCL pour une communication collective optimisée

Profilage Nsys

Activer le profilage Nsight Systems dans les tâches Slurm :

slurm :
  job_name : llm_profile
  nodes : 1
  ntasks_per_node : 8
  time: "00:30:00"
  account: my_account
  partition: batch
  container_image: nvcr.io/nvidia/nemo:dev
  nsys_enabled: true

Il s'agit d'un paramètre du lanceur Slurm. Les champs Slurm habituels tels que job_name, nodes, ntasks_per_node, time, account ou partition, et container_image s'appliquent toujours.

Lorsque nsys_enabled est défini sur true, le lanceur encapsule la commande d’entraînement avecle profil nsys et génère un fichier de rapport .nsys-rep destiné à l’analyse des performances dans le répertoire de travail ou de sortie du job Slurm. Le profilage est uniquement à des fins de diagnostic : exécutez-le pour une brève analyse, attendez-vous à une surcharge et à d’importants artefacts, puis désactivez-le pour l’entraînement en production normale.

Références de code

• components/launcher/slurm/config.py - classe de données SlurmConfig, VolumeMapping
• components/launcher/slurm/template.py - Génération de modèles de scripts SBATCH
• components/launcher/slurm/utils.py - Utilitaires de soumission Slurm
• components/launcher/skypilot/config.py - classe de données SkyPilotConfig
• _cli/app.py - Point d'entrée de l'interface en ligne de commande et logique de routage du lanceur

Pièges à éviter

• Conflits de ports: si le port master_port par défaut (13742) est utilisé par un autre travail sur le même nœud, modifiez-le pour éviter les échecs de connexion.
• Montages de conteneurs: le chemin source indiqué dans ` extra_mounts` doit exister sur tous les nœuds de l’allocation. Des chemins manquants entraînent des échecs au démarrage des conteneurs.
• Tolérance aux pannes Slurm: le plugin de tolérance aux pannes est spécifique à Slurm et ne fonctionne pas avec SkyPilot ni en mode interactif.
• Préemption des instancesspot par SkyPilot: les instances spot (use_spot: true) peuvent être préemptées par le fournisseur de cloud. Activez la création de points de contrôle à intervalles courts pour minimiser la perte de travail.
• Syntaxe des variables d’environnement: utilisez la syntaxe ${VAR} en YAML pour l’expansion des variables de shell. Les noms de variables nus ne seront pas développés.
• Limite de temps et point de contrôle asynchrone: si la limite de temps Slurm est trop courte, une écriture de point de contrôle asynchrone en cours peut être interrompue avant d’être terminée, ce qui entraîne un point de contrôle corrompu. Prévoyez une marge d’au moins 5 à 10 minutes.