Cette page a été traduite par l'API Cloud Translation.

Déployer des charges de travail TPU dans GKE Standard

Standard

Cette page vous explique comment accélérer les charges de travail de machine learning (ML) à l'aide de TPU dans Google Kubernetes Engine (GKE). Les TPU sont conçus pour le traitement des multiplications matricielles, comme l'entraînement de modèles de deep learning à grande échelle. Les TPU sont optimisés pour gérer les énormes ensembles de données et les modèles complexes de ML. Ils sont donc plus rentables et plus économes en énergie pour les charges de travail de ML en raison de leurs performances supérieures. Dans ce guide, vous allez apprendre à déployer des charges de travail de ML à l'aide d'accélérateurs Cloud TPU, à configurer des quotas pour les TPU, à configurer des mises à niveau pour les pools de nœuds qui exécutent des TPU et à surveiller les métriques des charges de travail TPU.

Ce tutoriel est destiné aux ingénieurs en machine learning (ML), ainsi qu'aux administrateurs et opérateurs de plate-forme qui souhaitent utiliser l'orchestration de conteneurs Kubernetes pour gérer les charges de travail d'entraînement, de réglage et d'inférence de modèles à grande échelle à l'aide de TPU. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Avant de lire cette page, assurez-vous de connaître les éléments suivants :

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
Remarque : Pour les installations de la gcloud CLI existantes, veillez à définir la propriété compute/region. Si vous utilisez principalement des clusters zonaux, définissez plutôt compute/zone. En définissant un emplacement par défaut, vous pouvez éviter les erreurs gcloud CLI de ce type : One of [--zone, --region] must be supplied: Please specify location. Vous devrez peut-être spécifier l'emplacement dans certaines commandes si celui de votre cluster diffère de l'emplacement par défaut que vous avez défini.

Planifier la configuration TPU

Planifiez la configuration de votre TPU en fonction de votre modèle et de la quantité de mémoire dont il a besoin. Avant d'utiliser ce guide pour déployer vos charges de travail sur TPU, suivez les étapes de planification décrites dans Planifier la configuration TPU.

Vérifier que vous disposez d'un quota de TPU

Les sections suivantes vous aident à vous assurer que vous disposez d'un quota suffisant lorsque vous utilisez des TPU dans GKE.

Quota pour les VM Spot ou à la demande

Si vous créez un pool de nœuds de tranche TPU avec des VM à la demande ou Spot, vous devez disposer d'un quota de TPU suffisant dans la région que vous souhaitez utiliser.

La création d'un pool de nœuds de tranche TPU qui consomme une réservation TPU ne nécessite pas de quota de TPU¹. Vous pouvez ignorer cette étape en toute sécurité pour les TPU réservés.

La création d'un pool de nœuds de tranche TPU à la demande ou Spot dans GKE nécessite un quota d'API Compute Engine. Le quota de l'API Compute Engine (compute.googleapis.com) est différent de celui de l'API Cloud TPU (tpu.googleapis.com), qui est nécessaire lors de la création de TPU avec l'API Cloud TPU.

Pour vérifier la limite et l'utilisation actuelle de votre quota d'API Compute Engine pour les TPU, procédez comme suit :

Accédez à la page Quotas dans la console Google Cloud :

Accéder à la section "Quotas"

Dans la zone Filtre, procédez comme suit :

Utilisez le tableau suivant pour sélectionner et copier la propriété du quota en fonction de la version du TPU et du type de machine. Par exemple, si vous envisagez de créer des nœuds TPU v5e à la demande dont le type de machine commence par ct5lp-, saisissez Name: TPU v5 Lite PodSlice chips.

Version du TPU, type de machine commençant par	Propriété et nom du quota pour les instances à la demande	Propriété et nom du quota pour les instances Spot²
TPU v3, `ct3-`	Dimensions (e.g. location): tpu_family:CT3	Non applicable
TPU v3, `ct3p-`	Dimensions (e.g. location): tpu_family:CT3P	Non applicable
TPU v4, `ct4p-`	Name: TPU v4 PodSlice chips	Name: Preemptible TPU v4 PodSlice chips
TPU v5e, `ct5lp-`	Name: TPU v5 Lite PodSlice chips	Name: Preemptible TPU v5 Lite Podslice chips
TPU v5p, `ct5p-`	Name: TPU v5p chips	Name: Preemptible TPU v5p chips
TPU Trillium, `ct6e-`	Dimensions (e.g. location): tpu_family:CT6E	Name: Preemptible TPU slices v6e

Sélectionnez la propriété Dimensions (par exemple, emplacements) et saisissez region: suivi du nom de la région dans laquelle vous prévoyez de créer des TPU dans GKE. Par exemple, saisissez region:us-west4 si vous envisagez de créer des nœuds de tranche TPU dans la zone us-west4-a. Le quota de TPU est régional. Par conséquent, toutes les zones d'une même région consomment le même quota de TPU.

Si aucun quota ne correspond au filtre que vous avez saisi, le projet ne dispose d'aucun quota pour la région dont vous avez besoin et vous devez demander un ajustement de quota TPU.

Lors de la création d'une réservation TPU, les valeurs de limite et d'utilisation actuelle du quota correspondant augmentent du nombre de puces dans la réservation TPU. Par exemple, lorsqu'une réservation est créée pour 16 puces TPU v5e dont le type de machine commence par ct5lp-, les valeurs Limite et Utilisation actuelle pour le quota TPU v5 Lite PodSlice chips dans la région concernée augmentent de 16.

Lorsque vous créez un pool de nœuds de tranche TPU, utilisez les options --reservation et --reservation-affinity=specific pour créer une instance réservée. Les réservations TPU sont disponibles lors de la souscription d'un engagement. ↩
Lorsque vous créez un pool de nœuds de tranche TPU, utilisez le flag --spot pour créer une instance Spot. ↩

Quotas pour les ressources GKE supplémentaires

Vous devrez peut-être augmenter les quotas suivants liés à GKE dans les régions où GKE crée vos ressources.

Quota SSD Persistent Disk (Go) : le disque de démarrage de chaque nœud Kubernetes nécessite 100 Go par défaut. Par conséquent, ce quota doit être défini au moins aussi haut que le produit du nombre maximal de nœuds GKE que vous prévoyez de créer et 100 Go (nœuds * 100 Go).
Quota d'adresses IP en cours d'utilisation : chaque nœud Kubernetes consomme une adresse IP. Par conséquent, ce quota doit être défini au moins aussi haut que le nombre maximal de nœuds GKE que vous prévoyez de créer.
Assurez-vous que max-pods-per-node correspond à la plage de sous-réseau : chaque nœud Kubernetes utilise des plages d'adresses IP secondaires pour les pods. Par exemple, max-pods-per-node sur 32 nécessite 64 adresses IP, ce qui se traduit par un sous-réseau /26 par nœud. Notez que cette plage ne doit pas être partagée avec un autre cluster. Pour éviter d'épuiser la plage d'adresses IP, utilisez l'option --max-pods-per-node pour limiter le nombre de pods pouvant être planifiés sur un nœud. Le quota pour max-pods-per-node doit être défini au moins aussi haut que le nombre maximal de nœuds GKE que vous prévoyez de créer.

Pour demander une augmentation de quota, consultez Demander un ajustement de quota.

S'assurer de la disponibilité des réservations

Pour créer un pool de nœuds de tranche TPU à l'aide d'une réservation, celle-ci doit comporter suffisamment de puces TPU disponibles au moment de la création du pool de nœuds.

Pour afficher les réservations d'un projet et le nombre de puces TPU disponibles dans une réservation TPU, affichez la liste de vos réservations.

Options de provisionnement des TPU dans GKE

GKE vous permet d'utiliser des TPU directement dans des charges de travail individuelles en utilisant des nodeSelectors Kubernetes dans le fichier manifeste de votre charge de travail ou en créant des pools de nœuds en mode Standard avec des TPU.

Vous pouvez également demander des TPU à l'aide de classes de calcul personnalisées. Les classes de calcul personnalisées permettent aux administrateurs de plate-forme de définir une hiérarchie de configurations de nœuds pour que GKE puisse les hiérarchiser lors des décisions de scaling des nœuds. Les charges de travail s'exécutent ainsi sur le matériel de votre choix.

Pour obtenir des instructions, consultez la section Provisionner des TPU à l'aide de classes de calcul personnalisées.

Créer un cluster

Créez un cluster GKE en mode Standard dans une région où des TPU sont disponibles.

Bonne pratique:

Utilisez des clusters régionaux, qui offrent une haute disponibilité du plan de contrôle Kubernetes.

gcloud container clusters create CLUSTER_NAME \
  --location LOCATION \
  --cluster-version VERSION

Remplacez les éléments suivants :

CLUSTER_NAME : nom du nouveau cluster
LOCATION : région dans laquelle votre capacité de TPU est disponible.
VERSION : version de GKE, qui doit être compatible avec le type de machine que vous souhaitez utiliser. Notez que la version de GKE par défaut peut ne pas avoir de disponibilité pour votre TPU cible. Pour connaître les versions minimales de GKE disponibles par type de machine TPU, consultez la page Disponibilité des TPU dans GKE.

Créer un pool de nœuds

Vous pouvez créer un pool de nœuds de tranche TPU à hôte unique ou multi-hôte.

Créer un pool de nœuds de tranche TPU à hôte unique

Vous pouvez créer un pool de nœuds de tranche de TPU à hôte unique à l'aide de Google Cloud CLI, de Terraform ou de la console Google Cloud .

gcloud

gcloud container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE \
    [--sandbox=type=gvisor]

Remplacez les éléments suivants :

NODE_POOL_NAME : nom du nouveau pool de nœuds.
LOCATION : nom de la zone basé sur la version de TPU que vous souhaitez utiliser. Pour identifier un emplacement disponible, consultez Disponibilité des TPU dans GKE.
CLUSTER_NAME : nom du cluster.
NODE_ZONES : liste d'une ou de plusieurs zones, séparées par une virgule, dans lesquelles GKE crée le pool de nœuds.
MACHINE_TYPE : type de machine à utiliser pour les nœuds. Pour en savoir plus sur les types de machines compatibles avec les TPU, utilisez le tableau de la section Choisir la version de TPU.

Vous pouvez également utiliser les options suivantes :

--num-nodes=NUM_NODES : nombre initial de nœuds dans le pool de nœuds de chaque zone. Si vous omettez cette option, GKE attribue la valeur par défaut 3.

Bonne pratique:
Si vous utilisez le flag enable-autoscaling pour le pool de nœuds, définissez num-nodes sur 0 afin que l'autoscaler provisionne des nœuds supplémentaires dès que vos charges de travail en ont besoin.
--reservation=RESERVATION_NAME : nom de la réservation utilisée par GKE lors de la création du pool de nœuds. Si vous omettez ce flag, GKE utilise les TPU disponibles. Pour en savoir plus sur les réservations de TPU, consultez À propos des réservations Cloud TPU.
--node-labels cloud.google.com/gke-workload-type=HIGH_AVAILABILITY : indique à GKE que le pool de nœuds de tranche TPU à hôte unique fait partie d'une collection. Utilisez cette option si les conditions suivantes s'appliquent :
- Le pool de nœuds exécute la charge de travail d'inférence dans le nouveau pool de nœuds.
- Le pool de nœuds utilise TPU Trillium.
- Le pool de nœuds n'utilise pas de VM Spot.
Pour en savoir plus sur la gestion de la planification de la collecte, consultez Gérer la planification de la collecte dans les tranches TPU à hôte unique.
--enable-autoscaling : Ajouter un pool de nœuds avec l'autoscaling activé. Requiert les options supplémentaires suivantes :
- --total-min-nodes=TOTAL_MIN_NODES : nombre minimal de nœuds dans le pool de nœuds.
- --total-max-nodes=TOTAL_MAX_NODES : nombre maximal de nœuds dans le pool de nœuds.
- --location-policy=ANY : donne la priorité à l'utilisation des réservations inutilisées et réduit le risque de préemption des VM Spot.
--spot : définit le pool de nœuds de sorte qu'il utilise des VM Spot pour les nœuds du pool de nœuds. Ce paramètre ne peut pas être modifié après la création du pool de nœuds.
--flex-start : définit le pool de nœuds de sorte qu'il utilise des VM à démarrage flexible. Les VM à démarrage flexible sont créées à l'aide de l'option de consommation flex-start, qui est compatible avec GKE version 1.33.0-gke.1712000 ou ultérieure.
--sandbox=type=gvisor : provisionne un nœud avec GKE Sandbox activé. Nécessite un TPU v4 ou une version ultérieure. Pour en savoir plus, consultez GKE Sandbox.

Pour obtenir la liste complète de toutes les options que vous pouvez spécifier, consultez la documentation de référence sur gcloud container clusters create.

Terraform

Assurez-vous d'utiliser la version 4.84.0 ou ultérieure du fournisseur google.
Ajoutez le bloc suivant à votre configuration Terraform :

resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]

  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    spot = true
    flex_start = false
  }
}

Remplacez les éléments suivants :

NODE_POOL_RESOURCE_NAME : nom de la ressource du pool de nœuds dans le modèle Terraform.
PROJECT_ID : ID de votre projet
CLUSTER_NAME : nom du cluster existant.
POOL_NAME : nom du pool de nœuds à créer
CLUSTER_LOCATION : zone de calcul du cluster. Spécifiez la région dans laquelle la version de TPU est disponible. Pour en savoir plus, consultez la section Sélectionner une version et une topologie de TPU.
NODE_ZONES : liste d'une ou de plusieurs zones, séparées par une virgule, dans lesquelles GKE crée le pool de nœuds.
MACHINE_TYPE : type de machine TPU à utiliser. Pour afficher les types de machines TPU compatibles, utilisez le tableau de la section Choisir la version de TPU.

Vous pouvez également utiliser les variables suivantes :

autoscaling : Ajouter un pool de nœuds avec l'autoscaling activé. Pour une tranche de TPU à hôte unique, GKE effectue l'ajustement entre les valeurs TOTAL_MIN_NODES et TOTAL_MAX_NODES.
- TOTAL_MIN_NODES : nombre minimal de nœuds dans le pool de nœuds. Ce champ est facultatif, sauf si l'auto-scaling est également spécifié.
- TOTAL_MAX_NODES : nombre maximal de nœuds dans le pool de nœuds. Ce champ est facultatif, sauf si l'auto-scaling est également spécifié.
RESERVATION_NAME : si vous utilisez À propos des réservations Cloud TPU, il s'agit de la liste des libellés des ressources de réservation à utiliser lors de la création du pool de nœuds. Pour en savoir plus sur la spécification de RESERVATION_LABEL_VALUES dans le champ reservation_affinity, consultez la page Fournisseur Terraform.
spot : définit le pool de nœuds de sorte qu'il utilise des VM Spot pour les nœuds TPU. Ce paramètre ne peut pas être modifié après la création du pool de nœuds. Pour en savoir plus, consultez la page VM Spot.
flex_start : définit le pool de nœuds de sorte qu'il utilise l'option de consommation flex-start. Ne peut pas être défini sur true si spot est activé. Le démarrage flexible est compatible avec la version 1.33.0-gke.1712000 ou ultérieure de GKE.

Console

Pour créer un pool de nœuds à l'aide de TPU, exécutez la commande suivante :

Accédez à la page Google Kubernetes Engine dans la console Google Cloud .

Accéder à Google Kubernetes Engine
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.
Cliquez sur Ajouter un pool de nœuds.
Dans la section Détails du pool de nœuds, cochez la case Spécifier les emplacements de nœud.
Sélectionnez la zone en fonction de la version de TPU que vous souhaitez utiliser. Pour identifier une zone disponible, consultez Disponibilité des TPU dans GKE.
Dans le volet de navigation, cliquez sur Nœuds.
Dans la section Configuration de la machine, sélectionnez TPU.
Dans le menu déroulant Série, sélectionnez l'une des options suivantes :
- CT3 : TPU v3, appareil à hôte unique
- CT3P : TPU v3, tranche de pod multi-hôte
- CT4P : TPU v4
- CT5LP : TPU v5e
- CT5P : TPU v5p
- CT6E : TPU Trillium (v6e)
Dans le menu déroulant Type de machine, sélectionnez le nom de la machine à utiliser pour les nœuds. Utilisez le tableau Choisir la version du TPU pour apprendre à définir le type de machine et la topologie TPU qui créent un pool de nœuds de tranche TPU à hôte unique.
Dans le menu déroulant Topologie TPU, sélectionnez la topologie physique de la tranche de TPU.
Dans la boîte de dialogue Modifications requises, cliquez sur Apporter des modifications.
Assurez-vous d'avoir défini le champ Type de disque de démarrage sur Disque persistant standard ou Disque persistant SSD.
Vous pouvez éventuellement cocher la case Activer les nœuds sur les VM Spot afin d'utiliser des VM Spot pour les nœuds du pool de nœuds.
Cliquez sur Créer.

Créer un pool de nœuds de tranche TPU multi-hôtes

Vous pouvez créer un pool de nœuds tranche de TPU multi-hôte à l'aide de Google Cloud CLI, de Terraform ou de la console Google Cloud .

gcloud

gcloud container node-pools create POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE \
    --tpu-topology=TPU_TOPOLOGY \
    [--num-nodes=NUM_NODES] \
    [--spot \]
    [--flex-start \]
    [--enable-autoscaling \
      --max-nodes MAX_NODES]
    [--reservation-affinity=specific \
    --reservation=RESERVATION_NAME] \
    [--node-labels cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME,cloud.google.com/gke-workload-type=HIGH_AVAILABILITY]
    [--placement-type=COMPACT]

Remplacez les éléments suivants :

POOL_NAME : nom du nouveau pool de nœuds.
LOCATION : nom de la zone basé sur la version de TPU que vous souhaitez utiliser. Pour identifier un emplacement disponible, consultez Disponibilité des TPU dans GKE.
CLUSTER_NAME : nom du cluster.
NODE_ZONES : liste d'une ou de plusieurs zones, séparées par une virgule, dans lesquelles GKE crée le pool de nœuds.
MACHINE_TYPE : type de machine à utiliser pour les nœuds. Pour en savoir plus sur les types de machines disponibles, consultez Choisir la version de TPU.
TPU_TOPOLOGY : Topologie physique de la tranche de TPU. Le format de la topologie dépend de la version du TPU. Pour en savoir plus sur les topologies TPU, utilisez le tableau de la section Choisir une topologie.

Pour en savoir plus, consultez la section Topologie.

Vous pouvez également utiliser les options suivantes :

NUM_NODES : Nombre de nœuds dans le pool de nœuds. Doit être égal à zéro ou au produit des valeurs définies dans TPU_TOPOLOGY ({A}x{B}x{C}) divisé par le nombre de puces dans chaque VM. Pour les TPU multi-hôtes v4 et v5e, le nombre de puces dans chaque VM est de quatre. Par conséquent, si votre TPU_TOPOLOGY est 2x4x4 (TPU v4 avec quatre puces dans chaque VM), la valeur de NUM_NODES est 32/4, ce qui correspond à 8. Si vous omettez cet indicateur, le nombre de nœuds est calculé et défini par défaut en fonction de la topologie et du type de machine.
RESERVATION_NAME : nom de la réservation utilisée par GKE lors de la création du pool de nœuds. Si vous omettez cette option, GKE utilise les pools de nœuds de tranche TPU disponibles. Pour en savoir plus sur les réservations TPU, consultez la page Réservations TPU.
--spot : définit le pool de nœuds de sorte qu'il utilise des VM Spot pour les nœuds de tranche TPU. Ce paramètre ne peut pas être modifié après la création du pool de nœuds. Pour en savoir plus, consultez la page VM Spot.
--flex-start : définit le pool de nœuds de sorte qu'il utilise des VM à démarrage flexible. Les VM à démarrage flexible sont créées à l'aide de l'option de consommation flex-start, qui est compatible avec GKE version 1.33.0-gke.1712000 ou ultérieure.
--enable-autoscaling : Ajouter un pool de nœuds avec l'autoscaling activé. Lorsque GKE met à l'échelle un pool de nœuds de tranche TPU multi-hôte, il effectue un scaling de façon atomique du pool de nœuds de zéro à la taille maximale.
- MAX_NODES : taille maximale du pool de nœuds. L'option --max-nodes est obligatoire si --enable-autoscaling est fourni. Elle doit être égale au produit des valeurs définies dans TPU_TOPOLOGY ({A}x{B}x{C}) divisée par le nombre de puces dans pour chaque VM.
--node-label=cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME, cloud.google.com/gke-workload-type=HIGH_AVAILABILITY : indique à GKE que le pool de nœuds de tranche TPU multi-hôte est une collection. Utilisez cette option si les conditions suivantes s'appliquent :
- Le pool de nœuds exécute les charges de travail d'inférence dans le nouveau pool de nœuds.
- Le pool de nœuds utilise TPU Trillium.
- Les VM Spot ne sont pas compatibles avec la planification de la collecte.
Pour en savoir plus sur la gestion de la planification de la collecte, consultez Gérer la planification de la collecte dans les tranches TPU multi-hôtes.
--placement-type=COMPACT : Ajouter un pool de nœuds avec l'emplacement compact activé. Cette option doit être utilisée avec l'indicateur --tpu-topology. Pour en savoir plus, consultez Créer une stratégie d'emplacement compact et Topologie TPU.

Terraform

Assurez-vous d'utiliser la version 4.84.0 ou ultérieure du fournisseur google.
Ajoutez le bloc suivant à votre configuration Terraform :
```
resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]
  initial_node_count = NUM_NODES

  autoscaling {
    max_node_count = MAX_NODES
    location_policy      = "ANY"
  }
  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    spot = true
    flex_start = false
  }

  placement_policy {
    type = "COMPACT"
    tpu_topology = TPU_TOPOLOGY
  }
}
```
Remplacez les éléments suivants :
- NODE_POOL_RESOURCE_NAME : nom de la ressource de pool de nœuds dans le modèle Terraform.
- PROJECT_ID : ID de votre projet
- CLUSTER_NAME : nom du cluster existant auquel ajouter le pool de nœuds.
- POOL_NAME : nom du pool de nœuds à créer
- CLUSTER_LOCATION : emplacement de calcul du cluster. Nous vous recommandons de disposer d'un cluster régional pour améliorer la fiabilité du plan de contrôle Kubernetes. Vous pouvez également utiliser un cluster zonal. Pour en savoir plus, consultez la section Sélectionner une version et une topologie de TPU.
- NODE_ZONES : liste d'une ou de plusieurs zones, séparées par une virgule, dans lesquelles GKE crée le pool de nœuds.
- NUM_NODES : Nombre de nœuds dans le pool de nœuds. Doit être égal à zéro ou au produit du nombre de puces TPU divisé par quatre, car dans les tranches de TPU à hôtes multiples, chaque nœud de tranche TPU comporte quatre puces. Par exemple, si TPU_TOPOLOGY est défini sur 4x8, il y a 32 puces, ce qui signifie que NUM_NODES doit être égal à 8. Pour en savoir plus sur les topologies TPU, utilisez le tableau de la section Choisir la version de TPU.
- TPU_TOPOLOGY : indique la topologie physique souhaitée pour la tranche de TPU. Le format de la topologie dépend de la version de TPU que vous utilisez. Pour en savoir plus sur les topologies TPU, consultez le tableau de la section Choisir une topologie.
Vous pouvez également utiliser les variables suivantes :
- RESERVATION_NAME : si vous utilisez la réservation TPU, il s'agit de la liste des libellés des ressources de réservation à utiliser lors de la création du pool de nœuds. Pour en savoir plus sur la spécification de RESERVATION_LABEL_VALUES dans le champ reservation_affinity, consultez la page Fournisseur Terraform.
- autoscaling : Ajouter un pool de nœuds avec l'autoscaling activé. Lorsque GKE met à l'échelle un pool de nœuds de tranche TPU multi-hôte, il effectue un scaling de façon atomique du pool de nœuds de zéro à la taille maximale.
  - MAX_NODES : taille maximale du pool de nœuds. Elle doit être égale au produit des valeurs définies dans TPU_TOPOLOGY ({A}x{B}x{C}) divisée par le nombre de puces dans chaque VM.
- spot : permet au pool de nœuds d'utiliser des VM Spot pour les nœuds de tranche TPU. Ce paramètre ne peut pas être modifié après la création du pool de nœuds. Pour en savoir plus, consultez VM Spot.
- flex_start : définit le pool de nœuds de sorte qu'il utilise l'option de consommation flex-start. Ne peut pas être défini sur true si spot est activé.

Console

Pour créer un pool de nœuds à l'aide de TPU, exécutez la commande suivante :

Accédez à la page Google Kubernetes Engine dans la console Google Cloud .

Accéder à Google Kubernetes Engine
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.
Cliquez sur Ajouter un pool de nœuds.
Dans la section Détails du pool de nœuds, cochez la case Spécifier les emplacements de nœud.
Sélectionnez le nom de la zone en fonction de la version de TPU que vous souhaitez utiliser. Pour identifier un emplacement disponible, consultez Disponibilité des TPU dans GKE.
Dans le volet de navigation, cliquez sur Nœuds.
Dans la section Configuration de la machine, sélectionnez TPU.
Dans le menu déroulant Série, sélectionnez l'une des options suivantes :
- CT3P : pour les TPU v3.
- CT4P : pour les TPU v4.
- CT5LP : pour les TPU v5e
Dans le menu déroulant Type de machine, sélectionnez le nom de la machine à utiliser pour les nœuds. Utilisez le tableau Choisir la version du TPU pour apprendre à définir le type de machine et la topologie TPU qui créent un pool de nœuds de tranche TPU multi-hôtes.
Dans le menu déroulant Topologie TPU, sélectionnez la topologie physique de la tranche de TPU.
Dans la boîte de dialogue Modifications requises, cliquez sur Apporter des modifications.
Assurez-vous d'avoir défini le champ Type de disque de démarrage sur Disque persistant standard ou Disque persistant SSD.
Vous pouvez éventuellement cocher la case Activer les nœuds sur les VM Spot afin d'utiliser des VM Spot pour les nœuds du pool de nœuds.
Cliquez sur Créer.

Gestion des problèmes de capacité par GKE

Si GKE ne peut pas créer votre pool de nœuds de tranche TPU en raison d'une capacité TPU insuffisante, il renvoie un message d'erreur indiquant que les nœuds de tranche TPU ne peuvent pas être créés en raison d'un manque de capacité.

Si vous créez un pool de nœuds de tranche TPU à hôte unique, le message d'erreur se présente comme suit :

2 nodes cannot be created due to lack of capacity. The missing nodes will be
created asynchronously once capacity is available. You can either wait for the
nodes to be up, or delete the node pool and try re-creating it again later.

Si vous créez un pool de nœuds de tranche TPU multi-hôte, le message d'erreur se présente comme suit :

The nodes (managed by ...) cannot be created now due to lack of capacity. They
will be created asynchronously once capacity is available. You can either wait
for the nodes to be up, or delete the node pool and try re-creating it again
later.

Votre requête de provisionnement TPU peut rester dans la file d'attente pendant une longue période et reste à l'état "Provisionnement" tant qu'elle est dans la file d'attente.

Une fois la capacité disponible, GKE crée les nœuds restants qui n'ont pas été créés.

Si vous avez besoin de capacité plus tôt, envisagez d'essayer des VM Spot. Notez toutefois que les VM Spot consomment un quota différent de celui des instances à la demande.

Vous pouvez supprimer la requête TPU en file d'attente en supprimant le pool de nœuds de tranche TPU.

Exécuter votre charge de travail sur des nœuds de tranche TPU

Cette section explique comment préparer vos charges de travail et fournit des exemples d'exécution.

Préparer vos charges de travail

Les charges de travail TPU présentent les exigences de préparation suivantes.

Les frameworks tels que JAX, PyTorch et TensorFlow accèdent aux VM des TPU à l'aide de la bibliothèque partagée libtpu. libtpu inclut le compilateur XLA, le logiciel d'environnement d'exécution TPU et le pilote TPU. Chaque version de PyTorch et de JAX nécessite une certaine version de libtpu.so. Pour éviter les conflits de version de package, nous vous recommandons d'utiliser une image JAX AI. Pour utiliser des TPU dans GKE, veillez à utiliser les versions suivantes :

Type de TPU	Version de `libtpu.so`
TPU Trillium (v6e) `tpu-v6e-slice`	Image JAX AI recommandée : jax0.4.35-rev1 ou version ultérieure Version jax[tpu] recommandée : v0.4.9 ou version ultérieure Version de torchxla[tpuvm] recommandée : v2.1.0 ou version ultérieure
TPU v5e `tpu-v5-lite-podslice`	Image JAX AI recommandée : jax0.4.35-rev1 ou version ultérieure Version jax[tpu] recommandée : v0.4.9 ou version ultérieure Version de torchxla[tpuvm] recommandée : v2.1.0 ou version ultérieure
TPU v5p `tpu-v5p-slice`	Image JAX AI recommandée : jax0.4.35-rev1 ou version ultérieure Version jax[tpu] recommandée : 0.4.19 ou version ultérieure. Version de torchxla[tpuvm] recommandée : il est suggéré d'utiliser une version nocturne du 23 octobre 2023.
TPU v4 `tpu-v4-podslice`	Image JAX AI recommandée : jax0.4.35-rev1 ou version ultérieure Version jax[tpu] recommandée : v0.4.4 ou version ultérieure Version torchxla[tpuvm] recommandée : v2.0.0 ou version ultérieure
TPU v3 `tpu-v3-slice` `tpu-v3-device`	Image JAX AI recommandée : jax0.4.35-rev1 ou version ultérieure Version jax[tpu] recommandée : v0.4.4 ou version ultérieure Version torchxla[tpuvm] recommandée : v2.0.0 ou version ultérieure

Définissez les variables d'environnement suivantes pour le conteneur qui demande les ressources TPU suivantes :
- TPU_WORKER_ID : entier unique pour chaque pod. Cet ID indique un ID de nœud de calcul unique dans la tranche de TPU. Les valeurs acceptées pour ce champ sont comprises entre zéro et le nombre de pods moins un.
- TPU_WORKER_HOSTNAMES : liste de noms d'hôtes ou d'adresses IP de VM TPU séparés par une virgule qui doivent communiquer entre eux au sein de la tranche. Il doit y avoir un nom d'hôte ou une adresse IP pour chaque VM TPU de la tranche. La liste d'adresses IP ou de noms d'hôte est classée et indexée par zéro par le paramètre TPU_WORKER_ID.
- Dans le fichier manifeste de votre charge de travail, ajoutez des sélecteurs de nœuds Kubernetes pour vous assurer que GKE planifie votre charge de travail TPU sur le type de machine et la topologie de TPU que vous avez définis :
```
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
    cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
  
```
  Remplacez les éléments suivants :
  - TPU_ACCELERATOR : nom de l'accélérateur TPU.
  - TPU_TOPOLOGY : topologie physique de la tranche TPU. Le format de la topologie dépend de la version du TPU. Pour en savoir plus, consultez Planifier des TPU dans GKE.

Une fois la préparation de la charge de travail terminée, vous pouvez exécuter un job qui utilise des TPU.

Les sections suivantes montrent des exemples d'exécution d'un job qui effectue des calculs de base avec des TPU.

Exemple 1 : Exécuter une charge de travail qui affiche le nombre de puces TPU disponibles dans un pool de nœuds de tranche TPU

La charge de travail suivante renvoie le nombre de puces TPU sur tous les nœuds d'une tranche TPU multi-hôte. Pour créer une tranche multi-hôte, la charge de travail comporte les paramètres suivants :

Version du TPU : TPU v4
Topologie : 2x2x4

Cette version et cette sélection de topologie génèrent une tranche multi-hôte.

Enregistrez le manifeste suivant sous le nom available-chips-multihost.yaml :

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-available-chips
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-available-chips
spec:
  backoffLimit: 0
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice # Node selector to target TPU v4 slice nodes.
        cloud.google.com/gke-tpu-topology: 2x2x4 # Specifies the physical topology for the TPU slice.
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        securityContext:
          privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())' # Python command to count available TPU chips.
        resources:
          requests:
            cpu: 10
            memory: 407Gi
            google.com/tpu: 4 # Request 4 TPU chips for this workload.
          limits:
            cpu: 10
            memory: 407Gi
            google.com/tpu: 4 # Limit to 4 TPU chips for this workload.

Déployez le fichier manifeste :
```
kubectl create -f available-chips-multihost.yaml
```
GKE exécute une tranche de TPU v4 avec quatre VM (tranche TPU multi-hôte). La tranche comporte 16 puces TPU interconnectées.

Vérifiez que la tâche a créé quatre pods :

kubectl get pods

Le résultat ressemble à ce qui suit :

NAME                       READY   STATUS      RESTARTS   AGE
tpu-job-podslice-0-5cd8r   0/1     Completed   0          97s
tpu-job-podslice-1-lqqxt   0/1     Completed   0          97s
tpu-job-podslice-2-f6kwh   0/1     Completed   0          97s
tpu-job-podslice-3-m8b5c   0/1     Completed   0          97s

Obtenez les journaux de l'un des pods :
```
kubectl logs POD_NAME
```
Remplacez POD_NAME par le nom de l'un des pods créés. Par exemple, tpu-job-podslice-0-5cd8r.

Le résultat ressemble à ce qui suit :
```
TPU cores: 16
```

Facultatif : Supprimez la charge de travail :

kubectl delete -f available-chips-multihost.yaml

Exemple 2 : Exécuter une charge de travail qui affiche le nombre de puces TPU disponibles dans la tranche TPU

La charge de travail suivante est un pod statique qui affiche le nombre de puces TPU associées à un nœud spécifique. Pour créer un nœud à hôte unique, la charge de travail comporte les paramètres suivants :

Version du TPU : TPU v5e
Topologie : 2x4

Cette version et cette sélection de topologie génèrent une tranche à hôte unique.

Enregistrez le manifeste suivant sous le nom available-chips-singlehost.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: tpu-job-jax-v5
spec:
  restartPolicy: Never
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice # Node selector to target TPU v5e slice nodes.
    cloud.google.com/gke-tpu-topology: 2x4 # Specify the physical topology for the TPU slice.
  containers:
  - name: tpu-job
    image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
    ports:
    - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
    securityContext:
      privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
    command:
    - bash
    - -c
    - |
      python -c 'import jax; print("Total TPU chips:", jax.device_count())'
    resources:
      requests:
        google.com/tpu: 8 # Request 8 TPU chips for this container.
      limits:
        google.com/tpu: 8 # Limit to 8 TPU chips for this container.

Déployez le fichier manifeste :
```
kubectl create -f available-chips-singlehost.yaml
```
GKE provisionne des nœuds avec huit tranches de TPU à hôte unique qui utilisent les TPU v5e. Chaque nœud TPU possède huit puces TPU (tranche de TPU à hôte unique).
Récupérez les journaux du pod :
```
kubectl logs tpu-job-jax-v5
```
Le résultat ressemble à ce qui suit :
```
Total TPU chips: 8
```

Facultatif : Supprimez la charge de travail :

  kubectl delete -f available-chips-singlehost.yaml

Mettre à niveau des pools de nœuds à l'aide d'accélérateurs (GPU et TPU)

GKE met automatiquement à niveau les clusters standards, y compris les pools de nœuds. Vous pouvez également mettre à jour manuellement les pools de nœuds si vous souhaitez que vos nœuds passent plus rapidement à la nouvelle version. Pour contrôler le fonctionnement des mises à niveau de votre cluster, utilisez les versions disponibles, les intervalles et exclusions de maintenance et le séquençage du déploiement.

Vous pouvez également configurer une stratégie de mise à niveau des nœuds pour votre pool de nœuds, telle que des mises à niveau de la surutilisation, des mises à niveau bleu-vert ou des mises à niveau de courte durée. En configurant ces stratégies, vous pouvez vous assurer que les pools de nœuds sont mis à niveau de manière à trouver l'équilibre optimal entre la vitesse et les interruptions pour votre environnement. Pour les pools de nœuds de tranches TPU multi-hôtes, au lieu d'utiliser la stratégie de mise à niveau des nœuds configurée, GKE recrée de manière atomique l'ensemble du pool de nœuds en une seule étape. Pour en savoir plus, consultez la définition de l'atomicité dans la section Terminologie relative aux TPU dans GKE.

L'utilisation d'une stratégie de mise à niveau des nœuds nécessite temporairement que GKE provisionne des ressources supplémentaires, en fonction de la configuration. Si Google Clouddispose d'une capacité limitée pour les ressources de votre pool de nœuds, par exemple, si des erreurs de disponibilité des ressources s'affichent lorsque vous essayez de créer d'autres nœuds avec des GPU ou des TPU, consultez la section Effectuer une mise à niveau dans un environnement à ressources limitées.

Effectuer un nettoyage

Pour éviter que les ressources utilisées dans ce guide soient facturées sur votre compte Google Cloud , envisagez de supprimer les pools de nœuds de tranche TPU qui n'ont plus de charges de travail programmées. Si les charges de travail en cours d'exécution doivent être arrêtées progressivement, utilisez kubectl drain pour nettoyer les charges de travail avant de supprimer le nœud.

Supprimez un pool de nœuds de tranche TPU :
```
gcloud container node-pools delete POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME
```
Remplacez les éléments suivants :
- POOL_NAME : nom du pool de nœuds.
- CLUSTER_NAME : nom du cluster.
- LOCATION : emplacement de calcul du cluster.

Configurer des paramètres supplémentaires

Les sections suivantes décrivent les configurations supplémentaires que vous pouvez appliquer à vos charges de travail TPU.

Gérer la planification de la collecte

Dans TPU Trillium, vous pouvez utiliser la planification de la collecte pour regrouper les nœuds de tranche TPU. Le regroupement de ces nœuds de tranche TPU permet d'ajuster plus facilement le nombre de répliques pour répondre à la demande de charge de travail. Google Cloud contrôle les mises à jour logicielles pour s'assurer que suffisamment de tranches de la collection sont toujours disponibles pour traiter le trafic.

TPU Trillium est compatible avec la planification de la collecte pour les pools de nœuds à hôte unique et multi-hôtes qui exécutent des charges de travail d'inférence. La section suivante décrit comment le comportement de planification des collections dépend du type de tranche TPU que vous utilisez :

Tranche de TPU multi-hôte : GKE regroupe les tranches de TPU multi-hôtes pour former une collection. Chaque pool de nœuds GKE est une réplique de cette collection. Pour définir une collection, créez une tranche TPU multi-hôtes et attribuez-lui un nom unique. Pour ajouter d'autres tranches de TPU à la collection, créez un autre pool de nœuds de tranche TPU multi-hôte avec le même nom de collection et le même type de charge de travail.
Tranche de TPU à hôte unique : GKE considère l'ensemble du pool de nœuds de tranche de TPU à hôte unique comme une collection. Pour ajouter des tranches de TPU à la collection, vous pouvez redimensionner le pool de nœuds de tranche de TPU à hôte unique.

Pour gérer une collection, effectuez l'une des actions suivantes en fonction du type de pool de nœuds que vous utilisez.

Gérer la planification de la collecte dans les pools de nœuds de tranche de TPU multi-hôtes

Utilisez les tâches suivantes pour gérer les pools de nœuds de tranche TPU multi-hôtes.

Pour vérifier si un pool de tranches TPU multi-hôte fait partie d'une collection, exécutez la commande suivante :

gcloud container node-pools describe NODE_POOL_NAME \
    --location LOCATION \
    --cluster CLUSTER_NAME \
    --format="json" | jq -r \
    '"nodepool-group-name: \(.config.labels["cloud.google.com/gke-nodepool-group-name"] // "")\ngke-workload-type: \(.config.labels["cloud.google.com/gke-workload-type"] // "")"'

Le résultat ressemble à ce qui suit :

nodepool-group-name: <code><var>NODE_POOL_COLLECTION_NAME</var></code>
gke-workload-type: HIGH_AVAILABILITY

Si le pool de tranches TPU multi-hôtes fait partie d'une collection, la sortie comporte les libellés suivants :

cloud.google.com/gke-workload-type: HIGH_AVAILABILITY
cloud.google.com/gke-nodepool-group-name: <code><var>COLLECTION_NAME</var></code>

Pour obtenir la liste des collections du cluster, exécutez la commande suivante :

#!/bin/bash

# Replace with your cluster name, project, and location
CLUSTER_NAME=CLUSTER_NAME
PROJECT=PROJECT_ID
LOCATION=LOCATION

declare -A collection_names

node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")

# Iterate over each node pool
for pool in $node_pools; do
    # Describe the node pool and extract labels using jq
    collection_name=$(gcloud container node-pools describe "$pool" \
        --cluster "$CLUSTER_NAME" \
        --project "$PROJECT" \
        --location "$LOCATION" \
        --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')

    # Add the collection name to the associative array if it's not empty
    if [[ -n "$collection_name" ]]; then
        collection_names["$collection_name"]=1
    fi
done

# Print the unique node pool collection names
echo "Unique cloud.google.com/gke-nodepool-group-name values:"
for name in "${!collection_names[@]}"; do
    echo "$name"
done

Le résultat ressemble à ce qui suit :

Unique cloud.google.com/gke-nodepool-group-name values: {COLLECTION_NAME_1}, {COLLECTION_NAME_2}, {COLLECTION_NAME_3}

Pour obtenir la liste des pools de nœuds appartenant à une collection, exécutez la commande suivante :

#!/bin/bash

TARGET_COLLECTION_NAME=COLLECTION_NAME
CLUSTER_NAME=CLUSTER_NAME
PROJECT=PROJECT_ID
LOCATION=LOCATION

matching_node_pools=()

# Get the list of all node pools in the cluster
node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")

# Iterate over each node pool
for pool in $node_pools; do
    # Get the value of the cloud.google.com/gke-nodepool-group-name label
    collection_name=$(gcloud container node-pools describe "$pool" \
        --cluster "$CLUSTER_NAME" \
        --project "$PROJECT" \
        --location "$LOCATION" \
        --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')

    # Check if the group name matches the target value
    if [[ "$collection_name" == "$TARGET_COLLECTION_NAME" ]]; then
        matching_node_pools+=("$pool")
    fi
done

# Print the list of matching node pools
echo "Node pools with collection name '$TARGET_COLLECTION_NAME':"
for pool in "${matching_node_pools[@]}"; do
    echo "$pool"
done

Le résultat ressemble à ce qui suit :

Node pools with collection name 'COLLECTION_NAME':
{NODE_POOL_NAME_1}
{NODE_POOL_NAME_2}
{NODE_POOL_NAME_3}

Pour augmenter la taille de la collection, créez un autre pool de nœuds de tranche TPU multi-hôte et ajoutez cloud.google.com/gke-workload-type et cloud.google.com/gke-nodepool-group-name. Utilisez le même nom de collection dans cloud.google.com/gke-nodepool-group-name et exécutez le même type de charge de travail. Si le provisionnement automatique des nœuds est activé sur le cluster, GKE crée automatiquement des pools en fonction des exigences des charges de travail.
Pour réduire la taille de la collection, supprimez le pool de nœuds.
Pour supprimer la collection, supprimez tous les pools de nœuds associés. Vous pouvez supprimer le pool de nœuds ou supprimer le cluster. La suppression du cluster entraîne la suppression de toutes les collections qu'il contient.

Gérer la planification de la collecte dans les pools de nœuds de tranche de TPU à hôte unique

Utilisez les tâches suivantes pour gérer les pools de nœuds de tranche de TPU à hôte unique.

Pour vérifier si la planification de la collecte est activée pour un pool de tranches de TPU à hôte unique, exécutez la commande suivante :
```
gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --project PROJECT_NAME \
    --location LOCATION \
    --format="json" | jq -r '.config.labels["cloud.google.com/gke-workload-type"]'
```
Le résultat ressemble à ce qui suit :
```
gke-workload-type: HIGH_AVAILABILITY
```
Si le pool de tranches de TPU à hôte unique fait partie d'une collection, la sortie comporte le libellé cloud.google.com/gke-workload-type: HIGH_AVAILABILITY.
Pour augmenter la taille de la collection, redimensionnez le pool de nœuds manuellement ou automatiquement avec le provisionnement automatique de nœuds.
Pour réduire la taille de la collection, supprimez le pool de nœuds.
Pour supprimer la collection, supprimez tous les pools de nœuds associés. Vous pouvez supprimer le pool de nœuds ou supprimer le cluster. La suppression du cluster entraîne la suppression de toutes les collections qu'il contient.

Utiliser Multislice

Vous pouvez agréger des tranches plus petites dans une tranche multicouche pour gérer des charges de travail d'entraînement plus volumineuses. Pour en savoir plus, consultez la section TPU multicouche dans GKE.

Migrer votre réservation TPU

Si vous avez déjà effectué des réservations TPU, vous devez d'abord les migrer vers un nouveau système de réservation basé sur Compute Engine. Vous pouvez également créer un système de réservation basé sur Compute Engine sans avoir à effectuer de migration. Pour savoir comment migrer vos réservations TPU, consultez la section Réservation TPU.

Activer la journalisation

Les journaux émis par les conteneurs s'exécutant sur des nœuds GKE, y compris les VM TPU, sont collectés par l'agent de journalisation GKE, envoyés à Logging et visibles dans Logging.

Utiliser le provisionnement automatique des nœuds GKE

Vous pouvez configurer GKE pour créer et supprimer automatiquement des pools de nœuds afin de répondre aux exigences de ressources de vos charges de travail TPU. Pour en savoir plus, consultez la page Configurer Cloud TPU.

Provisionner des TPU à l'aide de classes de calcul personnalisées

Vous pouvez également configurer GKE pour qu'il demande des TPU lors des opérations de scaling qui créent des nœuds à l'aide de classes de calcul personnalisées.

Vous pouvez spécifier des options de configuration de TPU dans la spécification de votre classe de calcul personnalisée. Lorsqu'une charge de travail GKE utilise cette classe de calcul personnalisée, GKE tente de provisionner des TPU qui utilisent la configuration que vous avez spécifiée lors de la mise à l'échelle.

Pour provisionner des TPU avec une classe de calcul personnalisée qui suit les règles TPU et déployer la charge de travail, procédez comme suit :

Enregistrez le manifeste suivant sous le nom tpu-compute-class.yaml :

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: tpu-v5-lite-podslice
      count: 4
      topology: 2x4
  - spot: true
    tpu:
      type: tpu-v5-lite-podslice
      count: 4
      topology: 2x4
  - flexStart:
      enabled: true
    tpu:
      type: tpu-v6e-slice
      count: 4
      topology: 2x4
  nodePoolAutoCreation:
    enabled: true

Déployez la classe de calcul :
```
kubectl apply -f tpu-compute-class.yaml
```
Pour en savoir plus sur les classes de calcul personnalisées et les TPU, consultez Configuration des TPU.

Enregistrez le manifeste suivant sous le nom tpu-job.yaml :

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-job
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-job
spec:
  backoffLimit: 0
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/compute-class: tpu-class
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())'
        resources:
          requests:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS
          limits:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS

Remplacez les éléments suivants :

NUMBER_OF_CHIPS : nombre de puces TPU que le conteneur doit utiliser. La valeur doit être identique pour limits et requests, et égale à la valeur du champ tpu.count dans la classe de calcul personnalisée sélectionnée.
MEMORY_SIZE : quantité maximale de mémoire utilisée par le TPU. Les limites de mémoire dépendent de la version et de la topologie de TPU que vous utilisez. Pour en savoir plus, consultez Valeurs minimales et maximales pour les accélérateurs.
NUMBER_OF_CHIPS : nombre de puces TPU que le conteneur doit utiliser. La valeur doit être identique pour limits et requests.

Déployez le job :
```
kubectl create -f tpu-job.yaml
```
Lorsque vous créez ce job, GKE effectue automatiquement les opérations suivantes :
- Il provisionne des nœuds pour exécuter les pods. Selon le type de TPU, la topologie et les demandes de ressources que vous avez spécifiés, ces nœuds sont des tranches à hôte unique ou à plusieurs hôtes. En fonction de la disponibilité des ressources TPU dans la priorité la plus élevée, GKE peut revenir à des priorités inférieures pour maximiser la disponibilité.
- Il ajoute des rejets aux pods et des tolérances aux nœuds pour éviter que vos autres charges de travail s'exécutent sur les mêmes nœuds que les charges de travail TPU.
Pour en savoir plus, consultez À propos des classes de calcul personnalisées.
Une fois que vous avez terminé cette section, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées :
```
kubectl delete -f tpu-job.yaml
```

Configurer la réparation automatique pour les nœuds de tranche TPU

Si un nœud de tranche TPU dans un pool de nœuds de tranche TPU multi-hôte n'est pas opérationnel, l'intégralité du pool de nœuds est recréé. Dans un pool de nœuds de tranche TPU à hôte unique, seul le nœud TPU non opérationnel est réparé automatiquement.

Les conditions qui entraînent des nœuds de tranche TPU non opérationnels sont les suivantes :

Tout nœud de tranche TPU avec des conditions de nœud communes.
Tout nœud de tranche TPU dont le nombre de TPU non allouables est supérieur à zéro.
Toute instance de VM dans une tranche TPU arrêtée (en raison de la préemption) ou terminée.
Maintenance des nœuds : si un nœud de tranche TPU d'un pool de nœuds de tranche TPU multi-hôte est défaillant pour la maintenance de l'hôte, GKE recrée l'ensemble du pool de nœuds de tranche TPU.

Vous pouvez consulter l'état de la réparation (y compris la raison de l'échec) dans l'historique des opérations. Si l'échec est causé par un quota insuffisant, contactez votre responsable de compteGoogle Cloud pour augmenter le quota correspondant.

Configurer l'arrêt optimal pour les nœuds de tranche TPU

Dans les clusters GKE dont le plan de contrôle exécute la version 1.29.1-gke.1425000 ou ultérieure, les nœuds de tranche TPU acceptent les signaux SIGTERM qui avertissent le nœud d'un arrêt imminent. La notification d'arrêt imminent peut être configurée jusqu'à cinq minutes dans les nœuds TPU.

Pour configurer GKE afin qu'il arrête correctement vos charges de travail dans ce délai de notification, suivez la procédure décrite dans la section Gérer les interruptions des nœuds GKE pour les GPU et les TPU.

Exécuter des conteneurs sans mode privilégié

Le mode privilégié n'est pas nécessaire pour que les conteneurs s'exécutant dans des nœuds dans GKE version 1.28 ou ultérieure puissent accéder aux TPU. Les nœuds dans GKE version 1.28 et antérieures nécessitent le mode privilégié.

Si le nœud de tranche TPU exécute une version antérieure à 1.28, lisez la section suivante :

Un conteneur s'exécutant sur une VM dans une tranche de TPU doit avoir accès à des limites plus élevées sur la mémoire verrouillée, afin que le pilote puisse communiquer avec les puces TPU via l'accès direct à la mémoire (DMA). Pour activer cette fonctionnalité, vous devez configurer un ulimit plus élevé. Si vous souhaitez réduire le champ d'application des autorisations sur votre conteneur, procédez comme suit :

Modifiez le fichier securityContext afin d'inclure les champs suivants :
```
securityContext:
  capabilities:
    add: ["SYS_RESOURCE"]
```
Augmentez ulimit en exécutant la commande suivante dans le conteneur avant de configurer vos charges de travail pour qu'elles utilisent des ressources TPU :
```
ulimit -l 68719476736
```

Pour les TPU v5e, l'exécution de conteneurs sans mode privilégié est disponible dans les clusters en version 1.27.4-gke.900 et ultérieure.

Observabilité et métriques

Tableau de bord

L'observabilité des pools de nœuds dans la consoleGoogle Cloud est en disponibilité générale. Pour afficher l'état de vos pools de nœuds TPU multi-hôtes sur GKE, accédez au tableau de bord État des pools de nœuds TPU GKE fourni par Cloud Monitoring :

Accéder à l'état du pool de nœuds TPU GKE

Ce tableau de bord vous fournit des informations complètes sur l'état de vos pools de nœuds TPU multi-hôtes. Pour en savoir plus, consultez Surveiller les métriques d'état des nœuds et des pools de nœuds TPU.

Sur la page Clusters Kubernetes de la consoleGoogle Cloud , l'onglet Observabilité affiche également les métriques d'observabilité des TPU, telles que l'utilisation des TPU, sous l'en-tête Accélérateurs > TPU. Pour en savoir plus, consultez Afficher les métriques d'observabilité.

Le tableau de bord TPU n'est renseigné que si les métriques système sont activées dans votre cluster GKE.

Métriques d'exécution

Dans GKE version 1.27.4-gke.900 ou ultérieure, les charges de travail TPU qui utilisent la version JAX 0.4.14 ou ultérieure et spécifient containerPort: 8431 exportent les métriques d'utilisation des TPU en tant que métriques système GKE. Les métriques suivantes sont disponibles dans Cloud Monitoring pour surveiller les performances d'exécution de votre charge de travail TPU :

Cycle d'utilisation : durée exprimée en pourcentage de la dernière période d'échantillonnage (60 secondes) pendant laquelle les TensorCores ont traité activement les données sur une puce TPU. Un pourcentage plus élevé signifie une meilleure utilisation du TPU.
Mémoire utilisée : quantité de mémoire d'accélérateur allouée, en octets. Cette valeur est échantillonnée toutes les 60 secondes.
Mémoire totale : mémoire totale de l'accélérateur, en octets. Échantillonné toutes les 60 secondes.

Ces métriques se trouvent dans le schéma de nœud Kubernetes (k8s_node) et de conteneur Kubernetes (k8s_container).

Conteneur Kubernetes :

kubernetes.io/container/accelerator/duty_cycle
kubernetes.io/container/accelerator/memory_used
kubernetes.io/container/accelerator/memory_total

Nœud Kubernetes :

kubernetes.io/node/accelerator/duty_cycle
kubernetes.io/node/accelerator/memory_used
kubernetes.io/node/accelerator/memory_total

Surveiller les métriques d'état des nœuds et des pools de nœuds TPU

Lorsqu'une tâche d'entraînement présente une erreur ou se termine par un échec, vous pouvez vérifier les métriques liées à l'infrastructure sous-jacente pour déterminer si l'interruption est due à un problème avec le nœud ou le pool de nœuds sous-jacents.

État du nœud

Dans GKE version 1.32.1-gke.1357001 ou ultérieure, la métrique système GKE suivante expose l'état d'un nœud GKE :

kubernetes.io/node/status_condition

Le champ condition indique les conditions du nœud, telles que Ready, DiskPressure et MemoryPressure. Le champ status indique l'état signalé de la condition, qui peut être True, False ou Unknown. Il s'agit d'une métrique avec le type de ressource surveillée k8s_node.

Cette requête PromQL indique si un nœud particulier est Ready :

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    node_name="NODE_NAME",
    condition="Ready",
    status="True"}

Pour résoudre les problèmes dans un cluster, vous pouvez examiner les nœuds qui ont présenté d'autres conditions :

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition!="Ready",
    status="True"}

Vous pouvez examiner plus précisément les nœuds qui ne sont pas Ready :

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition="Ready",
    status="False"}

Si aucune donnée n'est disponible, les nœuds sont prêts. L'état est échantillonné toutes les 60 secondes.

Vous pouvez utiliser la requête suivante pour comprendre l'état des nœuds dans l'ensemble du parc :

avg by (condition,status)(
  avg_over_time(
    kubernetes_io:node_status_condition{monitored_resource="k8s_node"}[${__interval}]))

État du pool de nœuds

La métrique système GKE suivante pour la ressource surveillée k8s_node_pool expose l'état d'un pool de nœuds GKE :

kubernetes.io/node_pool/status

Cette métrique n'est signalée que pour les pools de nœuds TPU multi-hôtes.

Le champ status indique l'état du pool de nœuds, par exemple Provisioning, Running, Error, Reconciling ou Stopping. Les mises à jour d'état se produisent une fois les opérations de l'API GKE terminées.

Pour vérifier si un pool de nœuds particulier présente l'état Running, utilisez la requête PromQL suivante :

kubernetes_io:node_pool_status{
    monitored_resource="k8s_node_pool",
    cluster_name="CLUSTER_NAME",
    node_pool_name="NODE_POOL_NAME",
    status="Running"}

Pour surveiller le nombre de pools de nœuds dans votre projet, regroupés par état, utilisez la requête PromQL suivante :

count by (status)(
  count_over_time(
    kubernetes_io:node_pool_status{monitored_resource="k8s_node_pool"}[${__interval}]))

Disponibilité du pool de nœuds

La métrique système GKE suivante indique si un pool de nœuds TPU multi-hôte est disponible :

kubernetes.io/node_pool/multi_host/available

La métrique a une valeur de True si tous les nœuds du pool de nœuds sont disponibles et False dans le cas contraire. Cette métrique est échantillonnée toutes les 60 secondes.

Pour vérifier la disponibilité des pools de nœuds TPU multi-hôtes dans votre projet, utilisez la requête PromQL suivante :

avg by (node_pool_name)(
  avg_over_time(
    kubernetes_io:node_pool_multi_host_available{
      monitored_resource="k8s_node_pool",
      cluster_name="CLUSTER_NAME"}[${__interval}]))

Nombre d'interruptions de nœuds

La métrique système GKE suivante indique le nombre d'interruptions pour un nœud GKE depuis le dernier échantillon (la métrique est échantillonnée toutes les 60 secondes) :

kubernetes.io/node/interruption_count

Les champs interruption_type (par exemple, TerminationEvent, MaintenanceEvent ou PreemptionEvent) et interruption_reason (par exemple, HostError, Eviction ou AutoRepair) peuvent aider à expliquer pourquoi un nœud a été interrompu.

Pour obtenir une répartition des interruptions et de leurs causes dans les nœuds TPU des clusters de votre projet, utilisez la requête PromQL suivante :

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

Pour n'afficher que les événements de maintenance de l'hôte, mettez à jour la requête afin de filtrer la valeur HW/SW Maintenance pour interruption_reason. Utilisez la requête PromQL suivante :

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

Pour afficher le nombre d'interruptions agrégé par pool de nœuds, utilisez la requête PromQL suivante :

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

Temps de restauration (TTR) du pool de nœuds

La métrique système GKE suivante indique la distribution des durées de période de récupération pour les pools de nœuds TPU multi-hôte GKE :

kubernetes.io/node_pool/accelerator/times_to_recover

Chaque échantillon enregistré dans cette métrique indique un seul événement de récupération du pool de nœuds après une période d'indisponibilité.

Cette métrique est utile pour suivre le temps de récupération et le temps entre les interruptions des pools de nœuds TPU multi-hôte.

Vous pouvez utiliser la requête PromQL suivante pour calculer le délai moyen de rétablissement (MTTR) des sept derniers jours dans votre cluster :

sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_sum{
    monitored_resource="k8s_node_pool", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_count{
    monitored_resource="k8s_node_pool",cluster_name="CLUSTER_NAME"}[7d]))

Temps entre interruptions (TBI) du pool de nœuds

Le temps entre les interruptions du pool de nœuds mesure la durée de fonctionnement de votre infrastructure avant qu'elle ne subisse une interruption. Il est calculé comme la moyenne sur une période donnée, où le numérateur mesure la durée totale pendant laquelle votre infrastructure était opérationnelle et le dénominateur mesure le nombre total d'interruptions de votre infrastructure.

L'exemple PromQL suivant montre le temps moyen entre les interruptions (MTBI) sur sept jours pour le cluster donné :

sum(count_over_time(
  kubernetes_io:node_memory_total_bytes{
    monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_interruption_count{
    monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))

Métriques d'hôte

Dans GKE version 1.28.1-gke.1066000 ou ultérieure, les VM dans une tranche TPU exportent les métriques d'utilisation des TPU en tant que métriques système GKE. Les métriques suivantes sont disponibles dans Cloud Monitoring pour surveiller les performances de votre hôte TPU :

Utilisation de TensorCore : pourcentage actuel du TensorCore utilisé. La valeur TensorCore correspond à la somme des unités de multiplication matricielle (MXU) plus l'unité vectorielle. La valeur d'utilisation TensorCore correspond à la division des opérations TensorCore effectuées au cours de la période d'échantillonnage précédente (60 secondes) par le nombre d'opérations TensorCore compatibles sur la même période. Plus la valeur est élevée, plus l'utilisation est optimale.
Utilisation de la bande passante mémoire : pourcentage actuel de bande passante mémoire utilisée par l'accélérateur. Calculé en divisant la bande passante mémoire utilisée sur une période d'échantillonnage (60 secondes) par la bande passante maximale acceptée sur la même période d'échantillonnage.

Ces métriques se trouvent dans le schéma de nœud Kubernetes (k8s_node) et de conteneur Kubernetes (k8s_container).

Conteneur Kubernetes :

kubernetes.io/container/accelerator/tensorcore_utilization
kubernetes.io/container/accelerator/memory_bandwidth_utilization

Nœud Kubernetes :

kubernetes.io/node/accelerator/tensorcore_utilization
kubernetes.io/node/accelerator/memory_bandwidth_utilization

Pour en savoir plus, consultez Métriques de Kubernetes et Métriques système de GKE.

Problèmes connus

L'autoscaler de cluster peut mal calculer la capacité des nouveaux nœuds de tranche TPU avant que ces nœuds ne signalent les TPU disponibles. L'autoscaler de cluster peut alors effectuer un scaling à la hausse supplémentaire et créer ainsi plus de nœuds que nécessaire. L'autoscaler de cluster effectue le scaling à la baisse des nœuds supplémentaires, s'ils ne sont pas nécessaires, après une opération de scaling à la baisse standard.
L'autoscaler de cluster annule le scaling à la hausse des pools de nœuds de tranche TPU qui restent en attente pendant plus de 10 heures. L'autoscaler de cluster relance ces opérations de scaling à la hausse ultérieurement. Ce comportement peut réduire la capacité d'obtention des TPU pour les clients qui n'utilisent pas les réservations.
Les charges de travail non TPU ayant une tolérance pour le rejet TPU peuvent empêcher la réduction de capacité du pool de nœuds si elles sont recréées lors du drainage du pool de nœuds de tranche TPU.
La métrique d'utilisation de la bande passante de mémoire n'est pas disponible pour les TPU v5e.

Déployer des charges de travail TPU dans GKE Standard Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Avant de commencer

Planifier la configuration TPU

Vérifier que vous disposez d'un quota de TPU

Quota pour les VM Spot ou à la demande

Quotas pour les ressources GKE supplémentaires

S'assurer de la disponibilité des réservations

Options de provisionnement des TPU dans GKE

Créer un cluster

Créer un pool de nœuds

Créer un pool de nœuds de tranche TPU à hôte unique

gcloud

Terraform

Console

Créer un pool de nœuds de tranche TPU multi-hôtes

gcloud

Terraform

Console

Gestion des problèmes de capacité par GKE

Exécuter votre charge de travail sur des nœuds de tranche TPU

Préparer vos charges de travail

Exemple 1 : Exécuter une charge de travail qui affiche le nombre de puces TPU disponibles dans un pool de nœuds de tranche TPU

Exemple 2 : Exécuter une charge de travail qui affiche le nombre de puces TPU disponibles dans la tranche TPU

Mettre à niveau des pools de nœuds à l'aide d'accélérateurs (GPU et TPU)

Effectuer un nettoyage

Configurer des paramètres supplémentaires

Gérer la planification de la collecte

Gérer la planification de la collecte dans les pools de nœuds de tranche de TPU multi-hôtes

Gérer la planification de la collecte dans les pools de nœuds de tranche de TPU à hôte unique

Utiliser Multislice

Migrer votre réservation TPU

Activer la journalisation

Utiliser le provisionnement automatique des nœuds GKE

Provisionner des TPU à l'aide de classes de calcul personnalisées

Configurer la réparation automatique pour les nœuds de tranche TPU

Configurer l'arrêt optimal pour les nœuds de tranche TPU

Exécuter des conteneurs sans mode privilégié

Observabilité et métriques

Tableau de bord

Métriques d'exécution

Surveiller les métriques d'état des nœuds et des pools de nœuds TPU

État du nœud

État du pool de nœuds

Disponibilité du pool de nœuds

Nombre d'interruptions de nœuds

Temps de restauration (TTR) du pool de nœuds

Temps entre interruptions (TBI) du pool de nœuds

Métriques d'hôte

Problèmes connus

Étapes suivantes

Déployer des charges de travail TPU dans GKE Standard