Les clusters d'entraînement Gemini Enterprise Agent Platform utilisent Simple Linux Utility for Resource Management (Slurm) comme orchestrateur pour gérer et planifier les jobs sur votre cluster.
Slurm est un système de gestion de clusters et de planification de jobs Open Source très utilisé, connu pour son évolutivité et sa tolérance aux pannes.
Fonctionnalités clés de Slurm
- Slurm alloue un ensemble de nœuds de calcul à l'usage exclusif d'un job spécifique pendant une période définie. Cela garantit qu'un job dispose d'un accès dédié aux ressources dont il a besoin pour s'exécuter sans interférence.
- Slurm fournit un framework permettant de gérer l'intégralité du cycle de vie d'un job, de l'envoi et de l'exécution à la surveillance et à l'achèvement. Ce système est spécifiquement conçu pour gérer les jobs parallèles qui s'exécutent sur un ensemble de nœuds alloués.
- Slurm gère une file d'attente des jobs en attente à l'aide d'un moteur de hiérarchisation sophistiqué pour arbitrer l'accès aux ressources de calcul. En tenant compte de facteurs tels que la taille du job, la priorité de l'utilisateur et le temps d'attente, ce système garantit une utilisation équitable et efficace des ressources dans l'ensemble du cluster.
Configuration de base du cluster
Avant de pouvoir exécuter des jobs, vous devez définir la structure fondamentale de votre cluster Slurm. Cette section décrit en détail les paramètres de configuration essentiels, y compris comment organiser les nœuds de calcul en partitions, spécifier un pool de nœuds de connexion dédié et configurer un répertoire personnel partagé pour vos utilisateurs.
Partitions
Les partitions regroupent les nœuds en ensembles logiques, ce qui peut être utile pour gérer différents types de machines ou niveaux d'accès. Elles sont définies sous forme de liste dans le champ "partitions" de slurm_spec.
Chaque objet de partition comporte les champs obligatoires suivants :
id: identifiant unique de la partition.node_pool_ids: liste contenant les ID d'un ou de plusieurs pools de nœuds appartenant à cette partition.
Exemple :
"partitions": [
{
"id": "a4",
"node_pool_ids": [ "a4" ]
}
]
Les jobs envoyés sans --partition s'exécutent sur la partition par défaut. Pour spécifier la partition par défaut, définissez default_partition_id dans slurm_spec sur le id de l'une de vos partitions. Si vous ne la définissez pas, la première partition de la liste est celle par défaut.
Nœuds de connexion
Le pool de nœuds de connexion fournit des nœuds dédiés qui servent de point d'entrée principal pour les utilisateurs qui souhaitent interagir avec le cluster. Le champ login_node_pool_id spécifie l'identifiant unique de ce pool.
Exemple :
"login_node_pool_id": "login"
Stockage du répertoire d'accueil
Le champ home_directory_storage spécifie l'instance Filestore à monter en tant que répertoire /home sur tous les nœuds du cluster. Cela fournit un répertoire personnel partagé et persistant pour tous les utilisateurs.
Pour cette valeur, vous devez indiquer le nom complet de la ressource de l'instance Filestore.
Exemple :
"home_directory_storage": "projects/PROJECT_ID/locations/REGION-ZONE/instances/FILESTORE_INSTANCE_NAME"
Configuration Slurm avancée
Les clusters d'entraînement Gemini Enterprise Agent Platform vous permettent de définir des paramètres slurm.conf et de les modifier sur un cluster en cours d'exécution. Consultez Cartes de configuration Slurm.
Comptabilité, préemption et priorité
La comptabilité Slurm est activée sur chaque cluster. Vous pouvez ainsi suivre l'utilisation des ressources par job, comme le temps CPU et la mémoire. Vous pouvez également appliquer des limites de comptabilité, pondérer la priorité des jobs et activer la préemption via config, comme dans l'exemple de spécification de cluster. Pour en savoir plus sur leur fonctionnement, consultez la documentation Slurm sur la comptabilité, le plug-in de priorité multifactorielle et la préemption.
Scripts de prologue et d'épilogue
Vous pouvez configurer des scripts Bash personnalisés pour qu'ils s'exécutent automatiquement au début (prologue) et à la fin (épilogue) de chaque job à l'aide des champs suivants :
prolog_bash_scripts: liste de chaînes, où chaque chaîne contient l'intégralité du contenu d'un script Bash à exécuter avant le début du job.epilog_bash_scripts: liste de chaînes, où chaque chaîne contient l'intégralité du contenu d'un script Bash à exécuter une fois le job terminé.
Cela est utile pour configurer un environnement de job unique ou effectuer des tâches de nettoyage automatisées.
Exemple de spécification de cluster
L'exemple suivant montre une configuration JSON pour créer un cluster d'entraînement. Vous pouvez adapter cette spécification à vos propres besoins.
{ // ... other cluster configurations ... "orchestratorSpec": { "slurmSpec": { "partitions": [ { "id": "a4", "node_pool_ids": ["a4"] } ], "login_node_pool_id": "login", "home_directory_storage": "projects/PROJECT_ID/locations/REGION-ZONE/instances/FILESTORE_INSTANCE_ID", "config": { "AccountingStorageEnforce": "associations,limits,qos", "PriorityType": "priority/multifactor", "PriorityWeightAge": "1000", "PriorityWeightFairshare": "10000", "PreemptType": "preempt/partition_prio", "PreemptMode": "REQUEUE", "PreemptExemptTime": "00:10:00" }, "prolog_bash_scripts": [ "#!/bin/bash\necho 'First prolog script running'", "#!/bin/bash\necho 'Second prolog script running'" ], "epilog_bash_scripts": [ "#!/bin/bash\necho 'Epilog script running'" ] // ... other Slurm settings ... } } }
Gestion et opérations des clusters
Gérer un cluster en cours d'exécution
Une fois votre cluster créé avec les paramètres de comptabilité et de préemption choisis, vous pouvez utiliser les outils en ligne de commande de Slurm pour gérer les comptes utilisateur et surveiller la planification des jobs.
Gérer les comptes avec sacctmgr
La commande sacctmgr est l'outil principal pour gérer les informations sur les utilisateurs et les comptes dans la base de données Slurm. Par exemple, pour ajouter un nouvel utilisateur à un compte et lui accorder l'accès à une partition, exécutez la commande suivante :
sudo sacctmgr add User Accounts=<account> Partition=<partition> <user>
Pour obtenir la liste complète de toutes les options sacctmgr, consultez la documentation officielle sur la comptabilité Slurm.
Vérifier la priorité d'un job
Pour vérifier les composants de priorité de chaque job dans la file d'attente, utilisez l'utilitaire sprio. Cela permet de comprendre pourquoi certains jobs sont planifiés avant d'autres.
Pour en savoir plus sur l'utilisation, consultez la documentation de l'utilitaire sprio.
Exemples de préemption
La documentation officielle de Slurm fournit plusieurs exemples concrets de différentes stratégies de préemption. Vous les trouverez sur la page Préemption Slurm.
Étapes suivantes
La suite se concentre sur les dernières étapes du cycle de vie du machine learning : la gestion, le déploiement et la surveillance de vos modèles entraînés.
- Déployez votre modèle pour l'inférence : déployez votre modèle entraîné sur un point de terminaison Gemini Enterprise Agent Platform pour répondre aux demandes d'inférence en ligne à grande échelle.
- Gérez le cycle de vie de votre modèle : utilisez Gemini Enterprise Agent Platform Model Registry pour gérer les versions de vos modèles, les comparer et les gérer. Un pipeline peut être configuré pour enregistrer automatiquement un nouveau modèle une fois l'entraînement réussi.
- Surveillez les exécutions de votre pipeline et les performances de votre modèle :
- Surveillance des pipelines : suivez le graphique d'exécution, les artefacts et les performances de vos exécutions de pipeline pour déboguer les problèmes et optimiser votre orchestration.
- Surveillance du modèle : après le déploiement, configurez la surveillance pour détecter les dérives et les anomalies dans les performances de prédiction de votre modèle. Cela vous aidera à maintenir la justesse du modèle au fil du temps.
- Optimisez les coûts et gérez le cycle de vie du cluster : lorsque vous utilisez des pipelines automatisés, gérez le cycle de vie du cluster en tenant compte de la fréquence d'exécution.
- Pour les exécutions peu fréquentes, ajoutez une dernière étape de pipeline pour supprimer le cluster et réduire ainsi les coûts. Cela implique généralement de créer un composant de pipeline personnalisé qui appelle la fonction de suppression.
- Pour les exécutions fréquentes, laissez le cluster actif afin de réduire le temps de démarrage des jobs.