À propos du provisionnement de GPU et de TPU avec le mode de provisionnement "démarrage flexible"

Cette page décrit le mode de provisionnement flex-start dans Google Kubernetes Engine (GKE). Flex-start, basé sur le programmeur de charge de travail dynamique, fournit une technique flexible et rentable pour obtenir des GPU et des TPU lorsque vous devez exécuter des charges de travail d'IA/ML.

Flex-start vous permet de provisionner de manière dynamique des GPU et des TPU selon vos besoins, pendant une durée maximale de sept jours, sans limite de date de début et sans gérer les réservations à long terme. Par conséquent, le démarrage flexible convient aux charges de travail de petite à moyenne envergure avec des exigences de demande fluctuantes ou de courte durée. Par exemple, pré-entraînement de petits modèles, affinage de modèles ou modèles de diffusion évolutifs.

Les informations de cette page peuvent vous aider à effectuer les opérations suivantes:

• Découvrez le fonctionnement de flex-start dans GKE.
• Déterminez si le lancement flexible est adapté à votre charge de travail.
• Déterminez la configuration de démarrage flexible la plus adaptée à votre charge de travail.
• Gérer les interruptions lors de l'utilisation de flex-start
• Découvrez les limites de flex-start dans GKE.

Cette page s'adresse aux administrateurs et opérateurs de plate-forme et aux ingénieurs en machine learning (ML) qui souhaitent optimiser l'infrastructure d'accélérateur pour leurs charges de travail.

Quand utiliser flex-start ?

Nous vous recommandons d'utiliser flex-start si vos charges de travail répondent à toutes les conditions suivantes:

• Vos charges de travail nécessitent des ressources GPU.
• Vos charges de travail nécessitent des ressources TPU exécutées dans des pools de nœuds de tranche de TPU à hôte unique.
• Vous disposez d'une capacité de GPU ou de TPU réservée limitée ou inexistante, et vous avez besoin d'un accès plus fiable à ces accélérateurs.
• Votre charge de travail est flexible en termes d'horaires et votre cas d'utilisation peut tolérer d'attendre pour obtenir toute la capacité demandée, par exemple lorsque GKE alloue les ressources GPU en dehors des heures de pointe.

Conditions requises

Pour utiliser flex-start dans GKE, votre cluster doit répondre aux exigences suivantes:

• Pour exécuter des GPU, utilisez GKE version 1.32.2-gke.1652000 ou ultérieure.

• Pour exécuter des TPU, utilisez GKE version 1.33.0-gke.1712000 ou ultérieure. Flex-start est compatible avec les versions et zones suivantes:

  • TPU Trillium (v6e) dans asia-northeast1-b et us-east5-a.
  • TPU v5e dans us-west4-a.
  • TPU v5p dans us-east5-a.

  Les TPU v3 et v4 ne sont pas compatibles.

Fonctionnement du modèle de provisionnement Démarrage flexible

Avec flex-start, vous spécifiez la capacité de GPU ou de TPU requise dans vos charges de travail. De plus, avec les clusters standards, vous configurez flex-start sur des pools de nœuds spécifiques. GKE provisionne automatiquement les VM en procédant comme suit lorsque la capacité devient disponible:

1. La charge de travail demande une capacité qui n'est pas immédiatement disponible. Cette requête peut être effectuée directement par la spécification de la charge de travail ou via des outils de planification tels que les classes de calcul personnalisées ou Kueue.
2. GKE identifie que le démarrage flexible est activé sur votre nœud et que la charge de travail peut attendre pendant une durée indéterminée.
3. L'autoscaler de cluster accepte votre requête et calcule le nombre de nœuds nécessaires, en les traitant comme une seule unité.
4. L'autoscaler de cluster provisionne les nœuds nécessaires lorsqu'ils sont disponibles. Ces nœuds s'exécutent pendant sept jours maximum, ou pendant une durée plus courte si vous spécifiez une valeur dans le paramètre maxRunDurationSeconds. Ce paramètre est disponible avec GKE version 1.28.5-gke.1355000 ou ultérieure. Si vous ne spécifiez pas de valeur pour le paramètre maxRunDurationSeconds, la valeur par défaut est de sept jours.
5. Une fois la durée d'exécution que vous avez définie dans le paramètre maxRunDurationSeconds terminée, les nœuds et les pods sont préemptés.
6. Si les pods terminent plus tôt et que les nœuds ne sont plus utilisés, l'autoscaler de cluster les supprime conformément au profil d'autoscaling.

GKE comptabilise la durée de chaque requête flex-start au niveau du nœud. Le temps disponible pour l'exécution des pods peut être légèrement inférieur en raison des retards au démarrage. Les nouvelles tentatives d'exécution d'un pod partagent cette durée, ce qui réduit le temps de disponibilité des pods après une nouvelle tentative. GKE comptabilise séparément la durée de chaque requête flex-start.

Configurations de démarrage Flex

GKE est compatible avec les configurations de début flexible suivantes:

• Flex-start, où GKE alloue des ressources par nœud. Cette configuration ne nécessite que de définir l'indicateur --flex-start lors de la création du nœud.

• Démarrage flexible avec provisionnement en file d'attente, où GKE alloue toutes les ressources demandées en même temps. Pour utiliser cette configuration, vous devez ajouter les options --flex-start et enable-queued-provisioning lorsque vous créez le pool de nœuds. GKE suit le processus décrit dans la section Fonctionnement du mode de provisionnement flex-start de ce document, mais applique également les conditions suivantes:

  • Le planificateur attend que toutes les ressources demandées soient disponibles dans une seule zone.
  • Tous les pods de la charge de travail peuvent s'exécuter ensemble sur des nœuds qui viennent d'être provisionnés.
  • Les nœuds provisionnés ne sont pas réutilisés entre les exécutions de la charge de travail.

Le tableau suivant compare les configurations de début flexible:

Optimiser la configuration de flex-start

Pour créer une infrastructure d'IA/ML robuste et optimisée en termes de coûts, vous pouvez combiner des configurations de démarrage flexible avec les fonctionnalités GKE disponibles. Nous vous recommandons d'utiliser les classes de calcul pour définir une liste hiérarchisée des configurations de nœuds en fonction des exigences de votre charge de travail. GKE sélectionnera la configuration la plus adaptée en fonction de la disponibilité et de la priorité définie.

Gérer les perturbations dans les charges de travail qui utilisent le planificateur de charges de travail dynamique

Les charges de travail qui nécessitent la disponibilité de tous les nœuds ou de la plupart des nœuds d'un pool de nœuds sont sensibles aux évictions. De plus, les nœuds provisionnés à l'aide de requêtes du planificateur de charges de travail dynamique ne sont pas compatibles avec la réparation automatique. La réparation automatique supprime toutes les charges de travail d'un nœud et les empêche ainsi de s'exécuter.

Tous les nœuds utilisant Flex Start, le provisionnement en file d'attente ou les deux utilisent des mises à niveau de courte durée lorsque le plan de contrôle du cluster exécute la version minimale pour Flex Start, 1.32.2-gke.1652000 ou une version ultérieure.

Les mises à niveau de courte durée mettent à jour un pool de nœuds standard ou un groupe de nœuds dans un cluster Autopilot sans perturber les nœuds en cours d'exécution. De nouveaux nœuds sont créés avec la nouvelle configuration, remplaçant progressivement les nœuds existants avec l'ancienne configuration au fil du temps. Les versions antérieures de GKE, qui ne sont pas compatibles avec les mises à niveau flex-start ou de courte durée, nécessitent des bonnes pratiques différentes.

Bonnes pratiques pour réduire les perturbations de la charge de travail pour les nœuds utilisant des mises à niveau de courte durée

Les nœuds Flex-start et les nœuds qui utilisent le provisionnement en file d'attente sont automatiquement configurés pour utiliser des mises à niveau de courte durée lorsque le cluster exécute la version 1.32.2-gke.1652000 ou ultérieure.

Pour minimiser les perturbations des charges de travail exécutées sur des nœuds qui utilisent des mises à niveau de courte durée, procédez comme suit:

• Configurez des intervalles et des exclusions de maintenance pour définir les moments où GKE doit et ne doit pas effectuer des opérations de mise à jour, telles que les mises à niveau de nœuds, tout en vous assurant que GKE a toujours le temps d'effectuer la maintenance automatique.
• Désactivez la réparation automatique de nœuds.

Pour les nœuds de clusters exécutant des versions antérieures à la version 1.32.2-gke.1652000 et qui n'utilisent donc pas de mises à niveau de courte durée, consultez les conseils spécifiques à ces nœuds.

Bonnes pratiques pour réduire les perturbations de la charge de travail pour les nœuds de provisionnement en file d'attente sans mises à niveau temporaires

Les nœuds utilisant le provisionnement en file d'attente sur un cluster exécutant une version de GKE antérieure à 1.32.2-gke.1652000 n'utilisent pas les mises à niveau de courte durée. Les clusters mis à niveau vers la version 1.32.2-gke.1652000 ou ultérieure avec des nœuds de provisionnement en file d'attente existants sont automatiquement mis à jour pour utiliser des mises à niveau de courte durée.

Pour les nœuds exécutant ces versions antérieures, consultez les conseils suivants:

• En fonction de l'inscription à un canal de publication de votre cluster, suivez les bonnes pratiques ci-dessous pour empêcher les mises à niveau automatiques des nœuds d'interrompre vos charges de travail :
  • Si votre cluster est inscrit à un version disponible, utilisez des intervalles de maintenance et des exclusions pour empêcher GKE de mettre à niveau automatiquement vos nœuds pendant l'exécution de votre charge de travail.
  • Si votre cluster n'est pas inscrit à un canal de publication, désactivez les mises à niveau automatiques des nœuds. Toutefois, nous vous recommandons d'utiliser des canaux de publication, dans lesquels vous pouvez utiliser des exclusions de maintenance avec des champs d'application plus précis.
• Désactivez la réparation automatique de nœuds.
• Utilisez des intervalles et des exclusions de maintenance pour minimiser les perturbations des charges de travail en cours d'exécution, tout en veillant à ce que GKE ait toujours le temps d'effectuer la maintenance automatique. Veillez à planifier cette heure lorsque aucune charge de travail n'est en cours d'exécution.
• Pour vous assurer que votre pool de nœuds reste à jour, mettez-le à niveau manuellement lorsqu'aucune requête du planificateur de charges de travail dynamique n'est active et que le pool de nœuds est vide.

Éléments à prendre en compte lorsque votre cluster migre vers des mises à niveau de courte durée

GKE met à jour les nœuds existants à l'aide du provisionnement en file d'attente pour utiliser des mises à niveau de courte durée lorsque le cluster est mis à niveau vers la version 1.32.2-gke.1652000 ou ultérieure. GKE ne met pas à jour d'autres paramètres, tels que l'activation des mises à niveau automatiques des nœuds si vous les avez désactivées pour un pool de nœuds spécifique.

Nous vous recommandons de mettre en œuvre les bonnes pratiques suivantes maintenant que vos pools de nœuds utilisent des mises à niveau de courte durée:

• Si vous avez désactivé les mises à niveau automatiques des nœuds à l'aide de l'indicateur --no-enable-autoupgrade, cette migration ne réactive pas les mises à niveau automatiques des nœuds pour le pool de nœuds. Nous vous recommandons d'activer la mise à niveau automatique des nœuds, car les mises à niveau de courte durée n'entravent pas les nœuds existants ni les charges de travail qui y sont exécutées. Pour en savoir plus, consultez la section Mises à niveau de courte durée.
• Si votre cluster n'était pas déjà inscrit à un canal de publication, nous vous recommandons également de l'inscrire afin de pouvoir utiliser des champs d'exclusion de maintenance plus précis.

Recyclage de nœuds en mode démarrage flexible

Pour faciliter la transition des nœuds et éviter les temps d'arrêt de vos tâches en cours d'exécution, flex-start est compatible avec le recyclage de nœuds. Lorsqu'un nœud arrive à la fin de sa durée, GKE le remplace automatiquement par un nouveau pour préserver vos charges de travail en cours d'exécution.

Pour utiliser le recyclage de nœuds, vous devez créer un profil de classe de calcul personnalisé et inclure le champ nodeRecycling dans la spécification flexStart avec le paramètre leadTimeSeconds.

Le paramètre leadTimeSeconds vous permet d'équilibrer la disponibilité des ressources et l'efficacité des coûts. Ce paramètre spécifie à quel moment (en secondes) avant qu'un nœud n'atteigne la fin de sa durée de sept jours un nouveau processus de provisionnement de nœud doit commencer à le remplacer. Un délai plus long augmente la probabilité que le nouveau nœud soit prêt avant que l'ancien ne soit supprimé, mais peut entraîner des coûts supplémentaires.

Le processus de recyclage des nœuds comprend les étapes suivantes:

1. Phase de recyclage:GKE vérifie qu'un nœud provisionné avec flex-start contient le champ nodeRecycling avec le paramètre leadTimeSeconds défini. Si c'est le cas, GKE démarre la phase de recyclage des nœuds lorsque la date actuelle est supérieure ou égale à la différence entre les valeurs des champs suivants:

   • creationTimestamp plus maxRunDurationSeconds
   • leadTimeSeconds

   L'indicateur creationTimeStamp inclut l'heure à laquelle le nœud a été créé. Le champ maxRunDurationSeconds peut être spécifié dans la classe de calcul personnalisée. Sa valeur par défaut est de sept jours.

2. Création de nœud:le processus de création du nouveau nœud commence, passant par les phases de mise en file d'attente et de provisionnement. La durée de la phase de mise en file d'attente peut varier de manière dynamique en fonction de la zone et de la capacité spécifique de l'accélérateur.

3. Marquez le nœud qui arrive à la fin de sa durée de sept jours:une fois le nouveau nœud en cours d'exécution, l'ancien nœud est marqué. Cette action empêche la planification de nouveaux pods sur ce nœud. Les pods existants de ce nœud continuent de s'exécuter.

4. Déprovisionnement de nœud:le nœud qui arrive à la fin de sa durée de sept jours est finalement déprovisionné après une période appropriée, ce qui permet de s'assurer que les charges de travail en cours d'exécution ont été migrées vers le nouveau nœud.

L'exemple de configuration de classe de calcul suivant inclut les champs leadTimeSeconds et maxRunDuration:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: dws-model-inference-class
spec:
  priorities:
    - machineType: g2-standard-24
      spot: true
    - machineType: g2-standard-24
      maxRunDurationSeconds: 72000
      flexStart:
        enabled: true
        nodeRecycling:
          leadTimeSeconds: 3600
  nodePoolAutoCreation:
    enabled: true

Pour en savoir plus sur l'utilisation du recyclage de nœuds, consultez le tutoriel Diffuser des LLM sur GKE avec une stratégie de provisionnement de GPU à haute disponibilité et optimisée pour les coûts.

Limites

• L'anti-affinité entre les pods n'est pas prise en charge. L'autoscaler de cluster ne prend pas en compte les règles d'anti-affinité entre les pods lors du provisionnement des nœuds, ce qui peut entraîner des charges de travail non programmables. Cette situation peut se produire lorsque deux nœuds ou plus sont provisionnés dans le même pool de nœuds.
• Seuls les nœuds GPU sont compatibles.
• Les réservations ne sont pas compatibles avec le planificateur de charges de travail dynamique. Vous devez spécifier l'option --reservation-affinity=none lors de la création du pool de nœuds. Le planificateur de charges de travail dynamique nécessite et n'accepte que les règles d'emplacement ANY pour l'autoscaling de cluster.
• Une seule requête du planificateur de charges de travail dynamique peut créer jusqu'à 1 000 machines virtuelles (VM), ce qui correspond au nombre maximal de nœuds par zone pour un seul pool de nœuds.
• GKE utilise le quota Compute Engine ACTIVE_RESIZE_REQUESTS pour contrôler le nombre de requêtes du planificateur de charges de travail dynamique en attente dans une file d'attente. Par défaut, ce quota est limité à 100 requêtes par Google Cloud projet. Si vous essayez de créer une requête de planificateur de charge de travail dynamique supérieure à ce quota, la nouvelle requête échoue.
• Les pools de nœuds qui utilisent le planificateur de charges de travail dynamique sont sensibles aux perturbations, car les nœuds sont provisionnés ensemble. Pour en savoir plus, consultez Gérer les perturbations dans les charges de travail qui utilisent le planificateur de charges de travail dynamique.
• Il est possible que la console Google Cloud liste des VM supplémentaires de courte durée. Ce comportement est intentionnel, car Compute Engine peut créer et supprimer rapidement des VM jusqu'à être en mesure de provisionner toutes les machines requises.
• Les VM Spot ne sont pas compatibles.
• Le programmeur de charge de travail dynamique n'est pas compatible avec les volumes éphémères. Vous devez utiliser des volumes persistants pour le stockage. Pour sélectionner le meilleur type de stockage qui utilise des volumes persistants, consultez la section Présentation du stockage pour les clusters GKE.
• Si la charge de travail utilise le recyclage de nœuds et qu'elle est déployée par un job, configurez le job avec le mode d'achèvement défini sur Indexed.

Étapes suivantes

• Sélectionner un type de GPU
• Déployez des GPU avec le planificateur de charges de travail dynamique.