À propos de la consommation de GPU, de TPU et de H4D avec le mode de provisionnement à démarrage flexible

Cette page décrit le démarrage flexible dans Google Kubernetes Engine (GKE). Le démarrage flexible, optimisé par le planificateur de charges de travail dynamique, offre une technique flexible et économique pour consommer des ressources de calcul spécialisées, telles que des GPU ou des TPU, lorsque vous devez exécuter des charges de travail d'IA/de ML.

Le démarrage flexible vous permet de provisionner de manière dynamique des VM à démarrage flexible pour les GPU, les TPU et la série de machines H4D selon vos besoins, pendant sept jours maximum, sans être lié à une heure de début spécifique et sans avoir à gérer des réservations à long terme. Par conséquent, le démarrage flexible est adapté aux charges de travail de petite à moyenne taille dont les exigences en termes de demande sont fluctuantes ou dont la durée est courte. Par exemple, le pré-entraînement de petits modèles, l'ajustement de modèles ou les modèles de diffusion évolutifs.

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

  • Comprendre le fonctionnement du démarrage flexible dans GKE.
  • Déterminer si le démarrage flexible est adapté à votre charge de travail.
  • Déterminer quelle configuration de démarrage flexible est adaptée à votre charge de travail.
  • Gérer les interruptions lorsque vous utilisez des VM à démarrage flexible.
  • Comprendre les limites des VM à démarrage flexible dans GKE.

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

Quand utiliser le démarrage flexible

Nous vous recommandons d'utiliser le démarrage flexible 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 qui s'exécutent dans des pools de nœuds de tranche de TPU à hôte unique.
  • Vos charges de travail nécessitent d'autres matériels spécialisés, tels que la série de machines H4D optimisée pour le HPC.
  • 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.

Tarification du démarrage flexible

Le démarrage flexible est recommandé si votre charge de travail nécessite des ressources provisionnées de manière dynamique selon vos besoins, pendant sept jours maximum, avec des réservations à court terme, sans gestion complexe des quotas et avec un accès économique. Le démarrage flexible est optimisé par le planificateur de charges de travail dynamique et est facturé selon la tarification du planificateur de charges de travail dynamique :

  • Remise (jusqu'à 53 %) sur les vCPU, les GPU et les TPU.
  • Paiement à l'usage.

Conditions requises

Pour utiliser le démarrage flexible 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, consultez les exigences de version de GKE dans Planifier des TPU dans GKE. Le démarrage flexible est compatible avec les versions et zones suivantes :

    • Ironwood (TPU7x) dans us-central1-c.
    • TPU Trillium (v6e) dans asia-northeast1-b, us-east5-a et us-east5-b.
    • TPU v5e dans us-west4-a.
    • TPU v5p dans us-east5-a.

    Les TPU v3 et v4 ne sont pas compatibles.

Fonctionnement du mode de provisionnement Démarrage flexible

Avec le démarrage flexible, vous spécifiez la capacité de calcul requise (telle que les GPU ou les TPU) dans vos charges de travail. De plus, avec les clusters Standard, vous configurez le démarrage flexible sur des pools de nœuds spécifiques. GKE provisionne automatiquement les VM à démarrage flexible en effectuant le processus suivant 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 d'orchestration tels que des 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. 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 le délai d'exécution défini dans le maxRunDurationSeconds paramètre écoulé, 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 de démarrage flexible au niveau d'un 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 de démarrage flexible.

Configurations de démarrage flexible

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

  • Démarrage flexible, où GKE alloue les ressources nœud par nœud. Cette configuration ne nécessite que la définition de l'option --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 Démarrage flexible 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émarrage flexible :

Démarrage flexible Démarrage flexible avec provisionnement en file d'attente
Disponibilité Aperçu

Disponibilité générale

Remarque : Le démarrage flexible est compatible avec les options flex-start et enable-queued-provisioning en version preview.
Accélérateurs compatibles
  • GPU
  • TPU dans les pools de nœuds de tranche de TPU multi-hôtes
Taille de charge de travail recommandée Petite à moyenne, ce qui signifie que la charge de travail peut s'exécuter sur un seul nœud. Par exemple, cette configuration est adaptée si vous exécutez de petits jobs d'entraînement, une inférence hors connexion ou des jobs par lots. Moyenne à grande, ce qui signifie que la charge de travail peut s'exécuter sur plusieurs nœuds. Votre charge de travail nécessite plusieurs ressources et ne peut pas commencer à s'exécuter tant que tous les nœuds ne sont pas provisionnés et prêts en même temps. Par exemple, cette configuration est adaptée si vous exécutez des charges de travail d'entraînement de machine learning distribué.
Type de provisionnement GKE provisionne un nœud à la fois lorsque des ressources sont disponibles. Pour les TPU, GKE crée un nœud à la fois dans les pools de nœuds de tranche de TPU à hôte unique, et la tranche complète à la fois dans les pools de nœuds de tranche de TPU multi-hôtes. GKE alloue toutes les ressources demandées simultanément.
Complexité de configuration Moins complexe. Cette configuration est semblable aux VM à la demande et Spot. Plus complexe. Nous vous recommandons vivement d'utiliser un outil de gestion des quotas, tel que Kueue.
Compatibilité avec les classes de calcul personnalisées Oui Non
Recyclage des nœuds Oui Non
Prix SKU de démarrage flexible SKU de démarrage flexible
Quota
  • Quota préemptif de GPU
  • Quota préemptif de TPU
  • Quota préemptif de GPU
  • Quota préemptif de TPU
Stratégie de mise à niveau des nœuds Mises à niveau de courte durée Mises à niveau de courte durée
gcloud container node pool create option --flex-start
  • --flex-start
  • --enable-queued-provisioning
Commencer GPU : TPU : Exécuter une charge de travail à grande échelle avec le démarrage flexible et le provisionnement en file d'attente

Optimiser la configuration du démarrage flexible

Pour créer une infrastructure d'IA/de ML robuste et économique, vous pouvez combiner des configurations de démarrage flexible avec les fonctionnalités GKE disponibles. Nous vous recommandons d'utiliser des classes de calcul pour définir une liste priorisée de 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é que vous avez définie.

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

Les charges de travail nécessitant 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, ce qui les empêche de s'exécuter.

Tous les nœuds utilisant des VM à démarrage flexible, 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 le démarrage flexible, 1.32.2-gke.1652000 ou 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 interrompre 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 le démarrage flexible ni les mises à niveau de courte durée, nécessitent d'autres bonnes pratiques.

Bonnes pratiques pour minimiser les interruptions de charge de travail pour les nœuds utilisant des mises à niveau de courte durée

Les nœuds qui utilisent des VM à démarrage flexible et ceux 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 interruptions des charges de travail s'exécutant sur des nœuds qui utilisent des mises à niveau de courte durée, procédez comme suit :

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

Bonnes pratiques pour minimiser les interruptions de charge de travail pour les nœuds de provisionnement en file d'attente sans mises à niveau de courte durée

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 de 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 :

Considérations à prendre en compte lors de la migration de votre cluster 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 d'envisager d'appliquer les bonnes pratiques suivantes maintenant que vos pools de nœuds utilisent des mises à niveau de courte durée :

Recyclage des nœuds dans le démarrage flexible

Pour faciliter la transition des nœuds et éviter les temps d'arrêt pour vos jobs en cours d'exécution, le démarrage flexible est compatible avec le recyclage des nœuds. Lorsqu'un nœud atteint 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 des 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 la rentabilité. Ce paramètre spécifie le délai (en secondes) avant qu'un nœud n'atteigne la fin de sa durée de sept jours pour qu'un nouveau processus de provisionnement de nœud commence à le remplacer. Un délai plus long augmente la probabilité que le nouveau nœud soit prêt avant la suppression de l'ancien, 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 valide qu'un nœud provisionné par démarrage flexible comporte 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'option 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 et est défini par défaut sur sept jours.

  2. Création de nœuds : le processus de création du nouveau nœud commence, en 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é d'accélérateur spécifique.

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

  4. Déprovisionnement des nœuds : 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 migré vers le nouveau nœud.

L'exemple suivant de configuration de classe de calcul 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 des nœuds, essayez le tutoriel Diffuser des LLM sur GKE avec une stratégie de provisionnement de GPU économique et à haute disponibilité.

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.
  • Les réservations ne sont pas compatibles avec le planificateur de charges de travail dynamique. Vous devez spécifier l'option --reservation-affinity=none lorsque vous créez le pool de nœuds. Le planificateur de charges de travail dynamique nécessite et n'accepte que les ANY règles d'emplacement 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 ACTIVE_RESIZE_REQUESTS de Compute Engine 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 du planificateur de charges 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 la section Gérer les interruptions dans les charges de travail qui utilisent le planificateur de charges de travail dynamique.
  • Il est possible que la console liste des VM supplémentaires de courte durée. Google Cloud 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 planificateur de charges 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 des 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.
  • Un seul objet ProvisioningRequest n'accepte qu'une seule entrée dans la liste podSets. Les requêtes comportant plusieurs entrées podSet échouent.

Étape suivante