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 d'ordonnancement de jobs Open Source très utilisé, connu pour son évolutivité et sa tolérance aux pannes.
Principales fonctionnalité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écialement 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 de jobs en attente, en utilisant un moteur de priorisation 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étaille 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 d'accueil 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 l'id de l'une de vos partitions. Si vous ne définissez pas cette valeur, la première partition de la liste est utilisée 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 permettre aux utilisateurs d'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 à installer en tant que répertoire /home sur tous les nœuds du cluster. Cela fournit un répertoire d'accueil partagé et persistant pour tous les utilisateurs.
Vous devez fournir le nom complet de la ressource de l'instance Filestore pour cette valeur.
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 ConfigMaps Slurm.
Comptabilité, préemption et priorité
La comptabilité Slurm est activée sur chaque cluster, ce qui vous permet de suivre l'utilisation des ressources par tâche, 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 tâche à l'aide des champs suivants :
prolog_bash_scripts: liste de chaînes, où chaque chaîne contient le contenu complet 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 permettant de 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 de ligne de commande de Slurm pour gérer les comptes utilisateur et surveiller la planification des tâches.
Gestion des 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 tâche de 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 de différentes stratégies de préemption. Vous les trouverez sur la page Préemption Slurm.
Étapes suivantes
La section suivante 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éployer 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 requêtes d'inférence en ligne à grande échelle.
- Gérer 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 après un 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 des modèles Gemini Enterprise Agent Platform : 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, ce qui permet de maintenir sa précision 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 étape finale au pipeline pour supprimer le cluster afin de réduire 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.