Jean Zay : partitions Slurm GPU

Tous les projets DARI ou Accès Dynamique (AD) ayant des heures GPU ont à leur disposition des partitions Slurm définies sur Jean Zay.

Les projets ayant des heures GPU V100 ont accès par défaut à une partition permettant d'utiliser tous types de nœuds accélérés quadri-GPU à 160 Go de mémoire. Par défaut, le temps d'exécution est de 10 minutes et il ne peut dépasser 100 heures (soit --time=HH:MM:SS ≤ 100:00:00 c.f. les QoS pour V100 ci-dessous).

Cette partition comprenant à la fois des GPU Nvidia V100 ayant 16 Go de mémoire et des GPU Nvidia V100 ayant 32 Go de mémoire, si vous désirez vous limiter à un seul type de GPU, vous devez le spécifier en ajoutant dans vos scripts l'une des directives SLURM suivantes :

• #SBATCH -C v100-16g # pour sélectionner des nœuds ayant des GPU à 16 Go de mémoire (i.e. gpu_p3)
• #SBATCH -C v100-32g # pour sélectionner des nœuds ayant des GPU à 32 Go de mémoire (i.e. gpu_p1)

Remarque importante : Si votre travail peut s'exécuter indifféremment sur des GPU ayant 16 Go ou 32 Go de mémoire, il est préférable de ne pas cibler spécifiquement un type de nœud donné (i.e. ne pas spécifier d'option -C v100-16g ou -C v100-32g) afin de limiter le temps d'attente en queue de vos travaux.

La partition gpu_p2 est accessible à tous les chercheurs disposant d'heures GPU V100. Elle permet de lancer des calculs sur les nœuds accélérés octo-GPU de Jean Zay. Ces nœuds sont équipés de GPU Nvidia V100 avec 32 Go de mémoire. Par défaut, le temps d'exécution est de 10 minutes et il ne peut dépasser 100 heures (soit --time=HH:MM:SS ≤ 100:00:00 c.f. les QoS pour V100 ci-dessous).
Cette partition comporte des nœuds ayant 360 Go de mémoire RAM et d'autres en ayant 720 Go. Suivant la quantité de mémoire requise par votre code, vous pouvez ciblez l'une des deux sous-partitions suivantes :

• La sous-partition gpu_p2s donne accès au nœuds octo-GPU V100 à 360 Go de mémoire.
• La sous-partition gpu_p2l donne accès au nœuds octo-GPU V100 à 720 Go de mémoire.

Remarque importante : Si votre travail n'a pas besoin de plus de 360 Go de mémoire, il est préférable de ne pas cibler spécifiquement un type de nœud donné en spécifiant l'option –partition=gpu_p2 afin de limiter le temps d'attente en queue de vos travaux.

La partition gpu_p5 est accessible à tous les chercheurs ayant obtenu des heures GPU A100 via les Accès Dynamiques (AD) ou les Accès Réguliers (projets DARI). Elle permet de lancer des calculs sur les 52 nœuds accélérés octo-GPU de Jean Zay qui sont équipés de GPU Nvidia A100 reliés par une interconnexion SXM4 et ayant 80 Go de mémoire par GPU. Par défaut, le temps d'exécution est de 10 minutes et il ne peut dépasser 20 heures (soit --time=HH:MM:SS ≤ 20:00:00 c.f. les QoS pour A100 ci-dessous). Pour utiliser cette partition, vous devez spécifier la directive SLURM #SBATCH -C a100 dans vos scripts.
Attention : ces nœuds sont équipés de processeurs AMD Milan EPYC 7543 (64 cœurs par nœud) contrairement aux autres nœuds qui comportent des processeurs Intel. Il est donc nécessaire de charger le module arch/a100 (module load arch/a100) en premier pour avoir accès aux modules compatibles avec cette partition et de recompiler vos codes.

La partition gpu_p6 est accessible à tous les chercheurs ayant obtenu des heures GPU H100 via les Accès Dynamiques (AD) ou les Accès Réguliers (projets DARI). Elle permet de lancer des calculs sur les 364 nœuds accélérés quadri-GPU de Jean Zay qui sont équipés de GPU Nvidia H100 reliés par une interconnexion SXM5 et ayant 80 Go de mémoire par GPU. Par défaut, le temps d'exécution est de 10 minutes et il ne peut dépasser 100 heures (soit --time=HH:MM:SS ≤ 100:00:00 c.f. les QoS pour H100 ci-dessous). Pour utiliser cette partition, vous devez spécifier la directive SLURM #SBATCH -C h100 dans vos scripts.
Attention : ces nœuds ayant une architecture matérielle spécifique, il est nécessaire de charger le module arch/h100 (module load arch/h100) en premier pour avoir accès aux modules compatibles avec cette partition et de recompiler vos codes.

D'autres partitions sont disponibles, pour vous permettre de réaliser des compilations, des transferts de fichiers et du pré/post-traitement de données :

• La partition prepost permet de lancer un travail sur l'un des nœuds pré/post-traitement de Jean Zay jean-zay-pp, sur lesquels les calculs ne sont pas déduits de votre allocation. Par défaut, le temps d'exécution est de 2 heures et il ne peut dépasser 20 heures (soit --time=HH:MM:SS ≤ 20:00:00, c.f ci-dessous).
• La partition visu permet de lancer un travail sur l'un des nœuds de visualisation de Jean Zay jean-zay-visu, sur lesquels les heures de calcul ne sont pas déduites de votre allocation. Par défaut, le temps d'exécution est de 10 minutes et il ne peut dépasser 4 heures (soit --time=HH:MM:SS ≤ 4:00:00 c.f. ci-dessous).
• La partition archive est dédiée aux commandes permettant de gérer les données (copies ou déplacements de fichiers, création d'archives) : les heures de calcul ne sont pas déduites de votre allocation. Par défaut, le temps d'exécution est de 2 heures et il ne peut dépasser 20 heures (soit --time=HH:MM:SS ≤ 20:00:00 c.f. ci-dessous).
• La partition compil est dédiée aux compilations des codes et bibliothèques qui ne peuvent se faire sur la frontale car elles requièrent trop de temps cpu : les heures de calcul ne sont pas déduites de votre allocation. Par défaut, le temps d'exécution est de 2 heures et il ne peut dépasser 20 heures (soit --time=HH:MM:SS ≤ 20:00:00 c.f. ci-dessous).

Attention aux limites de temps par défaut des partitions, qui sont délibérément basses. Pour des exécutions plus longues, vous devez spécifier une limite de temps d'exécution, qui doit rester inférieure au maximum autorisé pour la partition et la Qos utilisées. Vous devez alors utiliser :

• soit la directive Slurm #SBATCH --time=HH:MM:SS dans votre job,
• soit l'option --time=HH:MM:SS des commandes sbatch, salloc ou srun.

La partition par défaut n'a pas besoin d'être spécifiée pour être utilisée par les travaux demandant des GPU. Par contre, toutes les autres doivent être spécifiées explicitement pour être utilisées. Par exemple, pour la partition prepost, vous pouvez utiliser :

• soit la directive Slurm #SBATCH --partition=prepost dans votre job,
• soit l'option --partition=prepost des commandes sbatch, salloc ou srun.

Attention : tout travail demandant plus d'un nœud tourne en mode exclusif. Les nœuds ne sont alors pas partagés mais cela implique que les heures facturées sont calculées sur la base de la totalité des nœuds réquisitionnés, y compris ceux qui ne sont que partiellement exploités.
Par exemple, la réservation de 41 cœurs CPU (soit 1 nœud + 1 cœur) sur la partition cpu_p1 entraîne la facturation de 80 cœurs CPU (soit 2 nœuds). De manière analogue sur la partition GPU par défaut, la réservation de 5 GPU (soit 1 nœud quadri-GPU + 1 GPU) entraîne la facturation de 8 GPU (soit 2 nœuds quadri-GPU). Par contre, la totalité de la mémoire des nœuds réservés est disponible dans les deux cas (de l'ordre de 160 Go utiles par nœud).

Pour chaque job soumis sur une partition de calcul (donc autre que archive, compil, prepost et visu), vous pouvez spécifier une QoS (Quality of Service) qui va déterminer les limites et la priorité de votre job.

Pour spécifier une QoS différente de celle par défaut, vous pouvez au choix :

• utiliser la directive Slurm #SBATCH --qos=<qos_choisie> dans votre job par exemple,
• ou spécifier l'option --qos=<qos_choisie> aux commandes sbatch, salloc ou srun

en remplaçant <qos_choisie> par le nom de la QoS désirée.

Notez que les noms des Qos diffèrent suivant les partitions utilisées.

• QoS par défaut pour tous les travaux GPU V100 : qos_gpu-t3
  • durée max : 20h00 de temps Elapsed,
  • 512 GPU maximum par travail,
  • 512 GPU maximum par utilisateur (tous projets confondus),
  • 512 GPU maximum par projet (tous utilisateurs confondus).

• QoS pour des exécutions plus longues qui doit être spécifiée pour être utilisée (c.f. ci-dessus) : qos_gpu-t4
  • durée max : 100h00 de temps Elapsed,
  • 16 GPU maximum par travail,
  • 96 GPU maximum par utilisateur (tous projets confondus),
  • 96 GPU maximum par projet (tous utilisateurs confondus),
  • 256 GPU maximum pour l'ensemble des travaux demandant cette QoS.

• QoS réservée uniquement à des exécutions brèves effectuées dans le cadre de développement des codes ou de tests d'exécutions et qui doit être spécifiée pour être utilisée (c.f. ci-dessus) : qos_gpu-dev
  • un maximum de 10 travaux (running ou pending) simultanément par utilisateur,
  • durée max : 2h00 de temps Elapsed,
  • 32 GPU maximum par travail,
  • 32 GPU maximum par utilisateur (tous projets confondus),
  • 32 GPU maximum par projet (tous utilisateurs confondus),
  • 512 GPU maximum pour l'ensemble des travaux demandant cette QoS.

• QoS par défaut pour tous les travaux GPU A100 : qos_gpu_a100-t3
  • durée max : 20h00 de temps Elapsed,
  • 128 GPU maximum par travail,
  • 256 GPU maximum par utilisateur (tous projets confondus),
  • 256 GPU maximum par projet (tous utilisateurs confondus).

• QoS réservée uniquement à des exécutions brèves effectuées dans le cadre de développement des codes ou de tests d'exécutions et qui doit être spécifiée pour être utilisée (c.f. ci-dessus) : qos_gpu_a100-dev
  • un maximum de 10 travaux (running ou pending) simultanément par utilisateur,
  • durée max : 2h00 de temps Elapsed,
  • 32 GPU maximum par travail,
  • 32 GPU maximum par utilisateur (tous projets confondus),
  • 32 GPU maximum par projet (tous utilisateurs confondus),
  • 128 GPU maximum pour l'ensemble des travaux demandant cette QoS.

• Attention : la partition A100 ne dispose pas d'une QoS permettant l'exécution de travaux de plus de 20h en raison du nombre limité de nœuds A100 disponibles.

• QoS par défaut pour tous les travaux GPU H100 : qos_gpu_h100-t3
  • durée max : 20h00 de temps Elapsed,
  • 512 GPU maximum par travail,
  • 512 GPU maximum par utilisateur (tous projets confondus),
  • 512 GPU maximum par projet (tous utilisateurs confondus).

• QoS pour des exécutions plus longues qui doit être spécifiée pour être utilisée (c.f. ci-dessus) : qos_gpu_h100-t4
  • durée max : 100h00 de temps Elapsed,
  • 16 GPU maximum par travail,
  • 64 GPU maximum par utilisateur (tous projets confondus),
  • 64 GPU maximum par projet (tous utilisateurs confondus),
  • 192 GPU maximum pour l'ensemble des travaux demandant cette QoS.

• QoS réservée uniquement à des exécutions brèves effectuées dans le cadre de développement des codes ou de tests d'exécutions et qui doit être spécifiée pour être utilisée (c.f. ci-dessus) : qos_gpu_h100-dev
  • un maximum de 10 travaux (running ou pending) simultanément par utilisateur,
  • durée max : 2h00 de temps Elapsed,
  • 32 GPU maximum par travail,
  • 32 GPU maximum par utilisateur (tous projets confondus),
  • 32 GPU maximum par projet (tous utilisateurs confondus),
  • 384 GPU maximum pour l'ensemble des travaux demandant cette QoS.