Migrer depuis Slurm
Aperçu
Cette fonctionnalité est en Aperçu public.
Ce guide montre comment migrer des workloads d'entraînement distribué de Slurm vers AI Runtime. Il explique les concepts fondamentaux, montre comment surveiller et contrôler les exécutions, et détaille la traduction d'un script batch Slurm.
Dans AI Runtime, vous définissez le type de GPU, le nombre total de GPU, l’environnement et la commande à exécuter sur chaque nœud dans une configuration de charge de travail YAML. Lorsque vous soumettez cette configuration avec databricks air run --file train.yaml, AI Runtime gère la planification, le provisionnement et le nettoyage des ressources pour l'exécution.
Avant de vous start, installez la CLI Databricks, configurez l’authentification et suivez le guide de démarrage rapide.
Concepts Slurm et AI Runtime
Ressources GPU
Dans Slurm, un job reçoit une attribution de nœuds et de GPU provenant d'une partition. Avec AI Runtime, vous demandez un type de GPU et un nombre total de GPU pour chaque exécution. Par default, le service provisionne ce compute à la demande.
Définissez compute.num_accelerators sur le nombre total de GPU . Le paramètre compute.accelerator_type détermine le nombre de GPU par nœud . Par exemple, GPU_8xH100 fournit 8 GPU H100 par nœud, de sorte qu’en demandant 16 GPU, vous obtenez 2 nœuds. Le total doit être un multiple du nombre de GPU par nœud.
Processus d’entraînement
Dans Slurm, sbatch soumet un job qui demande des nœuds et des GPU, et srun lance des tâches sur les nœuds alloués. Pour l'entraînement PyTorch distribué, un schéma courant consiste à utiliser srun pour start un torchrun lanceur par nœud. Chaque lanceur lance un processus d'entraînement par GPU.
AI Runtime exécute le même command une fois sur chaque nœud. Utilisez torchrun dans cette commande pour lancer les processus d'entraînement. AI Runtime fournit le rang de chaque nœud ainsi que les informations de connexion dont les nœuds ont besoin pour se coordonner. torchrun attribue à chaque processus d'entraînement son RANK, son LOCAL_RANK et son WORLD_SIZE. Avec 2 nœuds et 8 GPU par nœud, cela vous donne 2 lanceurs et 16 processus d'entraînement.
Stockage et nouvelles tentatives
Utilisez les volumes Unity Catalog (/Volumes/<catalog>/<schema>/<volume>/...) pour les datasets partagés et les points de contrôle qui doivent persister après une exécution. Traitez le disque local de chaque nœud comme un espace de travail temporaire.
timeout_minutes limite chaque tentative, et max_retries contrôle le nombre de nouvelles tentatives pour une charge de travail ayant échoué. Chaque tentative start la commande again. Pour continuer l’entraînement à partir d'un point de contrôle, votre code d'entraînement doit charger l'état sauvegardé. Consultez la section Améliorer les performances et la résilience de l'entraînement sur AI Runtime pour en savoir plus sur les points de contrôle et les schémas de récupération.
Surveiller et contrôler les exécutions
Slurm | AI Runtime |
|---|---|
|
|
|
|
|
|
|
|
Chaque workload dispose d'une exécution MLflow avec des logs et des métriques système collectées automatiquement. Utilisez MLflow dans votre code d'entraînement pour consigner les parameters, les métriques d'entraînement et les artefacts. Consultez Suivre les exécutions avec MLflow et la page d'exécution des jobs.
Exemple : traduire un script sbatch
Un script de lancement Slurm pour 2 nœuds dotés de 8 GPU chacun (16 GPU au total) :
#!/bin/bash
#SBATCH --job-name=llama-sft
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=1
#SBATCH --gpus-per-node=8
#SBATCH --time=02:00:00
srun bash -c '
torchrun \
--nnodes="$SLURM_NNODES" \
--node_rank="$SLURM_NODEID" \
--nproc_per_node=8 \
--master_addr="$(scontrol show hostnames "$SLURM_JOB_NODELIST" | head -n1)" \
--master_port=29500 \
train.py
'
L’équivalent AI Runtime train.yaml:
experiment_name: llama-sft
environment:
version: '4'
dependencies:
- transformers>=4.45
- datasets>=3.0
# 16 GPUs across 2 nodes (GPU_8xH100 = 8 H100 per node).
compute:
num_accelerators: 16
accelerator_type: GPU_8xH100
code_source:
type: snapshot
snapshot:
root_path: .
command: |
cd "$CODE_SOURCE_PATH"
# AI Runtime sets these rendezvous variables on each node.
torchrun \
--nnodes="$NUM_NODES" \
--node_rank="$NODE_RANK" \
--nproc_per_node="${LOCAL_WORLD_SIZE:-8}" \
--master_addr="$MASTER_ADDR" \
--master_port="$MASTER_PORT" \
train.py
timeout_minutes: 120
max_retries: 1
Envoyez et suivez-le :
databricks air run --file train.yaml --watch
Pour obtenir une version exécutable complète incluant le script d’entraînement, consultez Affinement de LLM multinoeud avec FSDP.
Considérations relatives à la migration
- Remplacez
module loadet les étapes d'activation de l'environnement par une configurationenvironment. Sélectionnez une version d'environnement gérée et déclarez des packages supplémentaires dansenvironment.dependencies, en ligne ou via une référence-rvers un fichierrequirements.txt. Pour une pile personnalisée, utilisez une image Docker personnalisée. - Définissez
code_source.snapshot.root_pathsur votre répertoire de projet local. La CLI Databricks l'upload lorsque vous soumettez la charge de travail. Référencez les fichiers upload avec$CODE_SOURCE_PATH. - Utilisez
env_variablespour les variables d’environnement etsecretspour les références de secret Databricks. - Soumettez une exécution distincte pour chaque configuration, en utilisant
databricks air run --override key=valuepour varier les champs entre les soumissions.