Configuration des Clusters

Ce guide explique comment exécuter NeMo RL avec Ray sur Slurm ou Kubernetes.

Utilisation de Slurm pour les Travaux par Lots et Interactifs

Le code suivant fournit des instructions sur la façon d’utiliser Slurm pour soumettre des travaux par lots et exécuter des travaux de manière interactive.

Soumission de Travaux par Lots

# Run from the root of NeMo RL repo
NUM_ACTOR_NODES=1  # Total nodes requested (head is colocated on ray-worker-0)
COMMAND="uv run ./examples/run_grpo_math.py" \
CONTAINER=YOUR_CONTAINER \
MOUNTS="$PWD:$PWD" \
sbatch \
    --nodes=${NUM_ACTOR_NODES} \
    --account=YOUR_ACCOUNT \
    --job-name=YOUR_JOBNAME \
    --partition=YOUR_PARTITION \
    --time=1:0:0 \
    --gres=gpu:8 \
    ray.sub

Selon la configuration de votre cluster Slurm, vous devrez peut-être inclure ou non l’option --gres=gpu:8 dans la commande sbatch.

Lors d’une soumission réussie, Slurm imprimera le SLURM_JOB_ID :

Submitted batch job 1980204

Notez le numéro de soumission du travail. Une fois le travail commencé, vous pouvez suivre son processus dans les journaux du pilote que vous pouvez tail :

tail -f 1980204-logs/ray-driver.log

Lancement Interactif

Un avantage clé de l’exécution interactive sur le nœud principal est la possibilité d’exécuter plusieurs travaux multi-nœuds sans avoir besoin de replacer dans la file d’attente de travaux Slurm. Cela signifie que pendant les sessions de débogage, vous pouvez éviter de soumettre une nouvelle commande sbatch à chaque fois. Au lieu de cela, vous pouvez déboguer et re-soumettre votre travail NeMo RL directement depuis la session interactive.

Pour exécuter de manière interactive, lancez la même commande que Soumission de Travaux par Lots, mais omettez la ligne COMMAND :

# Run from the root of NeMo RL repo
NUM_ACTOR_NODES=1  # Total nodes requested (head is colocated on ray-worker-0)
CONTAINER=YOUR_CONTAINER \
MOUNTS="$PWD:$PWD" \
sbatch \
    --nodes=${NUM_ACTOR_NODES} \
    --account=YOUR_ACCOUNT \
    --job-name=YOUR_JOBNAME \
    --partition=YOUR_PARTITION \
    --time=1:0:0 \
    --gres=gpu:8 \
    ray.sub

Lors d’une soumission réussie, Slurm imprimera le SLURM_JOB_ID :

Submitted batch job 1980204

Une fois le cluster Ray opérationnel, un script sera créé pour se connecter au nœud principal Ray. Exécutez ce script pour lancer des expériences :

bash 1980204-attach.sh

Maintenant que vous êtes sur le nœud principal, vous pouvez lancer la commande comme suit :

uv run ./examples/run_grpo_math.py

Variables d’Environnement Slurm

Toutes les variables d’environnement Slurm décrites ci-dessous peuvent être ajoutées à l’invocation sbatch de ray.sub. Par exemple, GPUS_PER_NODE=8 peut être spécifié comme suit :

GPUS_PER_NODE=8 \
... \
sbatch ray.sub \
   ...

Configuration d’Environnement Commune

:header-rows: 1
* - Variable d'Environnement
  - Explication
* - `CONTAINER`
  - (Requis) Spécifie l'image de conteneur à utiliser pour le cluster Ray.
    Utilisez soit une image docker à partir d'un registre, soit un squashfs (si vous utilisez enroot/pyxis).
* - `MOUNTS`
  - (Requis) Définit les chemins à monter dans le conteneur. Exemples :
    ```md
    * `MOUNTS="$PWD:$PWD"` (monter le répertoire de travail actuel (CWD))
    * `MOUNTS="$PWD:$PWD,/nfs:/nfs:ro"` (monte le répertoire de travail actuel et `/nfs`, avec `/nfs` monté en lecture seule)
    ```
* - `COMMAND`
  - Commande à exécuter après le démarrage du cluster Ray. Si vide, le cluster est inactif et passe en mode interactif (voir les [instructions interactives Slurm](#lancement-interactif)).
* - `HF_HOME`
  - Définit le répertoire de cache pour les ressources huggingface-hub (par exemple, modèles/tokenizers).
* - `WANDB_API_KEY`
  - Définir cela vous permet d'utiliser le logger wandb sans avoir à exécuter `wandb login`.
* - `HF_TOKEN`
  - Définit le jeton utilisé par huggingface-hub. Évite d'avoir à exécuter `huggingface-cli login`
* - `HF_DATASETS_CACHE`
  - Définit le répertoire de cache pour les datasets Huggingface téléchargés.

Lorsque HF_TOKEN, WANDB_API_KEY, HF_HOME et HF_DATASETS_CACHE sont définis dans votre environnement shell en utilisant export, ils sont automatiquement transmis à ray.sub. Par exemple, si vous définissez :

export HF_TOKEN=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ce jeton sera disponible pour votre exécution NeMo RL. Pensez à ajouter ces exports à votre fichier de configuration shell, comme ~/.bashrc.

Configuration d’Environnement Avancée

:header-rows: 1
* - Variable d'Environnement
    (et valeur par défaut)
  - Explication
* - `UV_CACHE_DIR_OVERRIDE`
  - Par défaut, cette variable n'a pas besoin d'être définie. Si non définie, `ray.sub` utilise le `UV_CACHE_DIR` défini dans le conteneur (par défaut `/root/.cache/uv`). 
    `ray.sub` évite intentionnellement d'utiliser le `UV_CACHE_DIR` de l'environnement hôte pour empêcher l'interférence du cache de l'hôte avec le cache du conteneur. 
    Définissez `UV_CACHE_DIR_OVERRIDE` si vous avez un environnement `uv` personnalisé (par exemple, avec des packages pré-téléchargés ou des configurations spécifiques) que vous souhaitez conserver 
    et réutiliser entre les exécutions de conteneur. Cette variable doit pointer vers un chemin sur un système de fichiers partagé accessible par tous les nœuds (principal et workers). 
    Ce chemin sera monté dans le conteneur et remplacera le `UV_CACHE_DIR` par défaut du conteneur.
* - `CPUS_PER_WORKER=128`
  - CPUs que chaque nœud worker Ray revendique. Par défaut `16 * GPUS_PER_NODE`.
* - `GPUS_PER_NODE=8`
  - Nombre de GPUs que chaque nœud worker Ray revendique. Pour déterminer cela, exécutez `nvidia-smi` sur un nœud worker.
* - `BASE_LOG_DIR=$SLURM_SUBMIT_DIR`
  - Répertoire de base pour stocker les journaux Ray. Par défaut, le répertoire de soumission Slurm ([SLURM_SUBMIT_DIR](https://slurm.schedmd.com/sbatch.html#OPT_SLURM_SUBMIT_DIR)).
* - `NODE_MANAGER_PORT=53001`
  - Port pour le gestionnaire de nœuds Ray sur les nœuds workers.
* - `OBJECT_MANAGER_PORT=53003`
  - Port pour le gestionnaire d'objets Ray sur les nœuds workers.
* - `RUNTIME_ENV_AGENT_PORT=53005`
  - Port pour l'agent d'environnement d'exécution Ray sur les nœuds workers.
* - `DASHBOARD_AGENT_GRPC_PORT=53007`
  - Port gRPC pour l'agent de tableau de bord Ray sur les nœuds workers.
* - `METRICS_EXPORT_PORT=53009`
  - Port pour l'exportation des métriques depuis les nœuds workers.
* - `PORT=6379`
  - Port principal pour le nœud principal Ray.
* - `RAY_CLIENT_SERVER_PORT=10001`
  - Port pour le serveur client Ray sur le nœud principal.
* - `DASHBOARD_GRPC_PORT=52367`
  - Port gRPC pour le tableau de bord Ray sur le nœud principal.
* - `DASHBOARD_PORT=8265`
  - Port pour l'interface utilisateur du tableau de bord Ray sur le nœud principal. C'est également le port
    utilisé par le débogueur distribué Ray.
* - `DASHBOARD_AGENT_LISTEN_PORT=52365`
  - Port d'écoute pour l'agent de tableau de bord sur le nœud principal.
* - `MIN_WORKER_PORT=54001`
  - Port minimum dans la plage pour les processus workers Ray.
* - `MAX_WORKER_PORT=54257`
  - Port maximum dans la plage pour les processus workers Ray.

Dans la plupart des cas, vous n’aurez pas besoin de modifier les ports sauf s’ils sont déjà utilisés par un autre service en arrière-plan sur votre cluster.

Kubernetes

À définir