Configuration du lanceur

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

Instructions

Pour les questions sur le lanceur, répondez directement à partir de cette compétence sans inspecter le référentiel, sauf si l'utilisateur vous demande de modifier des fichiers. Maintenez la réponse concentrée sur le YAML de lancement pertinent, les champs obligatoires et le comportement runtime attendu.

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

• Multi-nœuds Slurm : montrez un bloc YAML slurm: avec job_name, nodes, ntasks_per_node, time, account ou partition, container_image, hf_home, optionnellement extra_mounts, env_vars et master_port ; expliquez que le lanceur dérive WORLD_SIZE = nodes * ntasks_per_node et définit MASTER_ADDR et MASTER_PORT.
• SkyPilot spot : montrez un bloc YAML skypilot: avec cloud, accelerators, num_nodes, use_spot: true, disk_size, region, setup et env_vars ; avertissez que les instances spot peuvent être préemptées, définissez un court step_scheduler.checkpoint_interval et reprenez avec restore_from.path.
• Nsight Systems sur Slurm : montrez slurm.nsys_enabled: true aux côtés des champs Slurm normaux, dites que le lanceur encapsule la commande d'entraînement avec nsys profile et indiquez qu'il produit un fichier rapport .nsys-rep. Traitez le profilage comme étant diagnostic uniquement : utilisez des exécutions de profilage courtes et désactivez-le pour l'entraînement en production normal car il ajoute une surcharge et de gros artefacts.

Pour les réponses Slurm, commencez par ce modèle minimal, puis ajustez uniquement les champs sur lesquels l'utilisateur a demandé :

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 Slurm uniquement, ne discutez pas de SkyPilot ou du profilage sauf si l'utilisateur le demande. Pour les questions de profilage, dites que le rapport .nsys-rep est écrit dans le répertoire de travail ou de sortie du job Slurm, en utilisant le paramètre de sortie Nsys du lanceur quand l'un est configuré.

Limite de routage

Utilisez cette compétence uniquement pour la mécanique de lancement : exécution interactive, Slurm, SkyPilot, conteneurs, montages, variables d'environnement, paramètres de rendezvous et profilage.

N'utilisez pas cette compétence pour implémenter ou enregistrer de nouvelles architectures de modèles, des adaptateurs state-dict Hugging Face, des fichiers de modèles ou des drapeaux de capacité. Ce sont des tâches d'intégration de modèles, pas des tâches de configuration de lanceur.

Méthodes de lancement

1. Interactive (par défaut) : exécute torchrun sur le nœud actuel. Convient pour le développement et le débogage sur un seul nœud.
2. Slurm : soumet un travail batch à 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 travaux agnostique du cloud vers AWS, GCP, Azure, Lambda ou Kubernetes. Supporte les instances spot.

Lancement interactive

# GPU unique
automodel finetune llm -c config.yaml

# Multi-GPU (tous les GPUs sur le 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 interactive. Le CLI s'achemine vers torchrun automatiquement quand aucune section slurm: ou skypilot: n'est présente dans la configuration.

Configuration Slurm

La dataclass 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 travail Slurm
• nodes : nombre de nœuds à demander
• ntasks_per_node : nombre de tâches (GPUs) par nœud
• time : limite de temps d'exécution au format HH:MM:SS
• account, partition : paramètres de planification Slurm
• container_image : chemin d'image conteneur Enroot/Pyxis
• nemo_mount : point de montage de la source NeMo AutoModel à l'intérieur du conteneur
• hf_home : chemin du répertoire cache HuggingFace
• extra_mounts : liste de VolumeMapping(source, dest) pour les montages bind conteneur supplémentaires
• master_port : port pour la communication distribuée (par défaut 13742)
• env_vars : variables d'environnement transmises au travail
• nsys_enabled : quand true, encapsule la commande d'entraînement avec nsys profile pour le profilage Nsight Systems

Configuration SkyPilot

La dataclass SkyPilotConfig définit les paramètres de travail 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 cloud cible (aws, gcp, azure, lambda, kubernetes)
• accelerators : type et nombre de GPUs (p. ex. "H100:8", "A100-80GB:4")
• num_nodes : nombre d'instances cloud
• use_spot : utiliser des instances préemptibles/spot pour réduire les coûts
• disk_size : taille du disque en GB par nœud
• region : région cloud pour le placement des instances
• setup : commandes shell à exécuter avant le travail d'entraînement (p. ex. installer des dépendances)
• env_vars : variables d'environnement pour le travail

Liste de vérification SkyPilot spot

Lors de l'utilisation d'instances spot ou préemptibles :

• Définissez use_spot: true dans la section skypilot:.
• Incluez accelerators, num_nodes, disk_size, region, setup et les 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 préemption avec le paramètre restore_from de la recette.

Clés minimales de 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 pour le rendezvous (par défaut 13742)
• WORLD_SIZE : nombre total de processus (nodes * ntasks_per_node)
• Variables d'environnement NCCL pour la communication collective optimisée

Profilage Nsys

Activez le profilage Nsight Systems dans les travaux 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

C'est un paramètre du lanceur Slurm. Les champs Slurm normaux tels que job_name, nodes, ntasks_per_node, time, account ou partition et container_image s'appliquent toujours.

Quand nsys_enabled: true, le lanceur encapsule la commande d'entraînement avec nsys profile et écrit un fichier rapport .nsys-rep pour l'analyse des performances dans le répertoire de travail ou de sortie du job Slurm. Le profilage est diagnostic uniquement : exécutez-le pour une investigation courte, attendez une surcharge et de gros artefacts, et désactivez-le pour l'entraînement en production normal.

Ancres de code

• components/launcher/slurm/config.py - dataclass SlurmConfig, VolumeMapping
• components/launcher/slurm/template.py - génération de modèle de script SBATCH
• components/launcher/slurm/utils.py - utilitaires de soumission Slurm
• components/launcher/skypilot/config.py - dataclass SkyPilotConfig
• _cli/app.py - point d'entrée CLI et logique de routage du lanceur

Pièges

• Collisions de ports : si le master_port par défaut (13742) est utilisé par un autre travail sur le même nœud, changez-le pour éviter les défaillances de connexion.
• Montages de conteneurs : le chemin source dans extra_mounts doit exister sur tous les nœuds de l'allocation. Les chemins manquants causent les défaillances de démarrage du conteneur.
• Tolérance aux pannes Slurm : le plugin de tolérance aux pannes est spécifique à Slurm et ne fonctionne pas avec SkyPilot ou le mode interactive.
• Préemption spot SkyPilot : les instances spot (use_spot: true) peuvent être préemptées par le fournisseur cloud. Activez les points de contrôle avec des intervalles courts pour minimiser le travail perdu.
• Syntaxe des variables d'environnement : utilisez la syntaxe ${VAR} en YAML pour l'expansion de variables shell. Les noms de variables nus ne seront pas développés.
• Limite de temps vs point de contrôle asynchrone : si la limite time de Slurm est trop courte, une écriture de point de contrôle asynchrone en cours peut être tuée avant la fin, entraînant un point de contrôle corrompu. Laissez au moins 5 à 10 minutes de marge.