Planifier des TPU dans GKE


Cette page explique comment planifier l'utilisation des unités de traitement Tensor (TPU) dans Google Kubernetes Engine (GKE) afin de réduire le risque de configuration incorrecte des TPU, d'erreurs de non-disponibilité ou d'interruptions dues à un dépassement de quota.

Avant d'utiliser des TPU dans GKE, assurez-vous de bien connaître les définitions et la terminologie des TPU dans GKE.

Planifier la configuration TPU

Pour utiliser des TPU dans des clusters GKE, vous devez planifier leur configuration. Nous vous recommandons d'effectuer les opérations suivantes:

  1. Choisissez un mode de fonctionnement GKE: exécutez vos charges de travail sur des TPU dans un cluster GKE Autopilot ou GKE Standard.

    Bonne pratique:

    Utilisez un cluster Autopilot pour une expérience Kubernetes entièrement gérée.

  2. Choisissez la version de TPU: les différents types de TPU présentent des caractéristiques différentes, telles que les ratios prix-performances, le débit d'entraînement et la latence de diffusion. Les types de TPU affectent les capacités de processeur et de mémoire disponibles.

  3. Vérifier la disponibilité des TPU: les TPU sont disponibles dans des régions Google Cloudspécifiques. Pour utiliser un type de TPU dans votre charge de travail GKE, votre cluster doit se trouver dans une région compatible avec ce type.

  4. Choisissez la topologie de TPU: disposition physique des TPU dans une tranche de TPU. Sélectionnez une topologie qui correspond aux exigences de parallélisme de votre modèle.

Utilisez les tableaux de référence de cette page pour identifier si vos pools de nœuds sont des nœuds de tranche de TPU à hôte unique ou multi-hôte.

Choisir un mode de fonctionnement GKE

Vous pouvez utiliser des TPU dans les modes de fonctionnement GKE disponibles pour les clusters:

  • Mode Autopilot (recommandé) : GKE gère l'infrastructure sous-jacente (configuration des nœuds, autoscaling, mises à niveau automatiques, configurations de sécurité de référence et configuration de mise en réseau de référence, entre autres). Dans Autopilot, vous choisissez un type et une topologie de TPU, puis vous les spécifiez dans votre fichier manifeste Kubernetes. GKE gère le provisionnement des nœuds avec des TPU et la planification de vos charges de travail.
  • Mode standard : vous gérez l'infrastructure sous-jacente, y compris la configuration des nœuds individuels.

Pour choisir le mode de fonctionnement GKE le mieux adapté à vos charges de travail, consultez la section Choisir un mode de fonctionnement GKE.

Choisir la version de TPU

Les VM d'une tranche de TPU présentent les caractéristiques techniques suivantes :

Autopilot

Version du TPU Type de machine Nombre de processeurs virtuels Mémoire (Gio) Nombre de nœuds NUMA Nombre maximal de puces TPU dans un nœud de tranche TPU
TPU Trillium (v6e) tpu-v6e-slice Entre 44 et 180 Entre 176 et 1 440 Entre 1 et 2 256
TPU v5p
tpu-v5p-slice 208 448 2 6 144
TPU v5e
tpu-v5-lite-podslice Entre 24 et 224 Entre 48 et 384 1 256
TPU v4
tpu-v4-podslice 240 407 2 4 096
TPU v3 (hôte unique uniquement)
tpu-v3-device 96 340 2 8
TPU v3
tpu-v3-slice 48 340 1 256

Standard

Version du TPU Type de machine Nombre de processeurs virtuels Mémoire (Gio) Nombre de nœuds NUMA Probabilité de préemption
TPU Trillium (v6e) ct6e-standard-1t 44 448 2 Plus élevé
TPU Trillium (v6e) ct6e-standard-4t 180 720 1 Moyenne
TPU Trillium (v6e) ct6e-standard-8t 180 1440 2 Inférieur
TPU v5p
ct5p-hightpu-4t 208 448 2
TPU v5e
ct5lp-hightpu-1t 24 48 1 Plus élevé
TPU v5e
ct5lp-hightpu-4t 112 192 1 Moyenne
TPU v5e
ct5lp-hightpu-8t 224 384 1 Faible
TPU v4
ct4p-hightpu-4t 240 407 2
TPU v3 (hôte unique uniquement)
ct3-hightpu-4t 96 340 2
TPU v3
ct3p-hightpu-4t 48 340 1

Les types de machines ct5lp- multi-hôtes sont plus adaptés à la diffusion de modèles volumineux ou à l'entraînement. Les machines ct5lp- à hôtes multiples sont interconnectées avec des liaisons à haut débit.

Consultez les spécifications et les tarifs des TPU dans la documentation sur les tarifs de Cloud TPU pour choisir la configuration de TPU à utiliser.

Limites

Tenez compte des limites suivantes lorsque vous choisissez le TPU à utiliser:

  • TPU Trillium est disponible dans les versions suivantes :
    • Clusters standards en version 1.31.1-gke.1846000 ou ultérieure.
    • Clusters Autopilot version 1.31.2-gke.1115000 ou ultérieure
  • TPU Trillium n'est pas compatible avec la configuration de SMT sur 2 sur ct6e-standard-8t.
  • La répartition des coûts et la mesure de l'utilisation de GKE n'incluent aucune donnée sur l'utilisation ou les coûts des TPU v4 réservés.
  • L'autoscaling TPU v5p est compatible avec les clusters GKE dont les plans de contrôle exécutent au moins la version 1.29.2-gke.1035000 ou 1.28.7-gke.1020000.
  • Pour les réservations de capacité, utilisez une réservation spécifique.
  • Vous pouvez exécuter un maximum de 256 pods dans une seule VM TPU.
  • La répartition des coûts et la mesure de l'utilisation de GKE n'incluent aucune donnée sur l'utilisation ou les coûts des TPU.
  • L'autoscaler de cluster annule les opérations d'ajustement à la hausse des pools de nœuds TPU qui restent en attente pendant plus de 10 heures. L'autoscaler de cluster relance ces opérations de scaling à la hausse lorsque des ressources sont disponibles. Ce comportement peut réduire la capacité d'obtention des TPU si vous n'utilisez pas les réservations.
  • Les nœuds Ubuntu ne sont pas acceptés.
  • L'architecture de nœud TPU est obsolète. La version v3 est la seule version de TPU qui est toujours compatible avec l'architecture de nœud TPU dans GKE.

Valider la disponibilité des TPU dans GKE

Les TPU sont disponibles dans des régions Google Cloud spécifiques. Pour utiliser un type de TPU dans votre cluster GKE, celui-ci doit se trouver dans une région compatible avec ce type.

Autopilot

Version du TPU cloud.google.com/gke-tpu-accelerator Version GKE minimale Disponibilité Zone
TPU Trillium (v6e) tpu-v6e-slice 1.31.2-gke.1384000 DG
  • asia-northeast1-b
  • europe-west4-a
  • us-central1-b
  • us-east1-d
  • us-east5-a
  • us-east5-b
  • southamerica-west1-a
TPU v5e tpu-v5-lite-podslice 1.27.2-gke.2100 DG
  • europe-west4-b
  • us-central1-a
  • us-east5-a
  • us-east5-b
  • us-east5-c
  • us-south1-a
  • us-west1-c
  • us-west4-a
TPU v5p tpu-v5p-slice 1.28.3-gke.1024000 DG
  • europe-west4-b
  • us-central1-a
  • us-east5-a
TPU v4 tpu-v4-podslice 1.26.1-gke.1500 DG
  • us-central2-b
TPU v3 tpu-v3-slice 1.31.1-gke.1146000 DG
  • us-central1-a
  • us-central1-b
  • europe-west4-a
TPU v3 tpu-v3-device 1.31.0-gke.1500 DG
  • us-central1-a
  • us-central1-b
  • europe-west4-a

Standard

Version du TPU Type de machine commençant par Version GKE minimale Disponibilité Zone
TPU Trillium (v6e) ct6e- 1.31.2-gke.1115000 DG
  • asia-northeast1-b
  • europe-west4-a
  • us-central1-b
  • us-east1-d
  • us-east5-a
  • us-east5-b
  • southamerica-west1-a
TPU v5e ct5lp- 1.27.2-gke.2100 DG
  • europe-west4-b
  • us-central1-a
  • us-east5-a
  • us-east5-b
  • us-east5-c
  • us-south1-a
  • us-west1-c
  • us-west4-a
TPU v5p ct5p- 1.28.3-gke.1024000 DG
  • europe-west4-b
  • us-central1-a
  • us-east5-a
TPU v4 ct4p- 1.26.1-gke.1500 DG
  • us-central2-b
TPU v3 ct3p- 1.31.1-gke.1146000 DG
  • us-central1-a
  • us-central1-b
  • europe-west4-a
TPU v3 ct3- 1.31.0-gke.1500 DG
  • us-central1-a
  • us-central1-b
  • europe-west4-a
Tenez compte des mises en garde suivantes lorsque vous configurez un TPU :
  • Vous pouvez créer un pool de nœuds TPU v5e à hôte unique avec un type de machine commençant par ct5lp- dans certaines zones (europe-west4-a, us-east5-b et us-west4-b). Vous pouvez utiliser ct5lp-hightpu-4t avec une topologie d'au moins 2x4 ou plus dans ces zones.
  • Pour créer un TPU v5e à hôte unique dans la région us-west4, choisissez la zone us-west4-a et utilisez des types de machines commençant par ct5lp-, comme ct5lp-hightpu-1t.

Choisir une topologie

Après avoir choisi une version de TPU, sélectionnez une topologie compatible avec ce type de TPU. En fonction du type de TPU, la topologie est bidimensionnelle ou tridimensionnelle. Les exigences de parallélisme de votre modèle vous aident à choisir une topologie. Vous pouvez identifier le nombre de puces TPU dans la tranche en calculant le produit de chaque taille dans la topologie. Exemple :

  • 2x2x2 est une tranche de TPU multi-hôte v4 à huit puces
  • 2x2 est une tranche de TPU v5e à hôte unique à quatre puces

Si une topologie spécifique est compatible avec les nœuds de tranche TPU à hôte unique et multi-hôte, le type d'hôte est déterminé par le nombre de puces TPU demandées par votre charge de travail.

Par exemple, les TPU v5e (tpu-v5-lite-podslice) acceptent la topologie 2x4 en tant que TPU unique et multi-hôte. Plusieurs situations sont possibles :

  • Si vous demandez quatre puces dans votre charge de travail, vous obtenez un nœud multi-hôte avec quatre puces TPU.
  • Si vous demandez huit puces dans votre charge de travail, vous obtenez un nœud à hôte unique avec huit puces TPU.

Utilisez le tableau suivant pour choisir le type de machine et la topologie TPU pour votre cas d'utilisation:

  • Pour l'entraînement ou l'inférence de modèles à petite échelle, utilisez des TPU v4 ou des TPU v5e avec des pools de nœuds de tranche de pod TPU à hôte unique.
  • Pour l'entraînement ou l'inférence de modèles à grande échelle, utilisez des TPU v4 ou des TPU v5e avec des pools de nœuds de tranche de pod TPU à hôtes multiples.
  • Pour l'entraînement ou l'inférence à grande échelle, utilisez Pathways. Pathways simplifie les calculs de machine learning à grande échelle en permettant à un seul client JAX d'orchestrer des charges de travail sur plusieurs grandes tranches de TPU. Pour en savoir plus, consultez la section Parcours.

Autopilot

Après avoir choisi un type et une topologie de TPU, spécifiez-les dans le fichier manifeste de votre charge de travail. Pour obtenir des instructions, consultez la page Déployer des charges de travail TPU sur GKE Autopilot.

Version du TPU Type de machine Type de pool de nœuds Spécifications techniques
TPU Trillium (v6e) tpu-v6e-slice Un seul hôte
  • Topologie: 1x1
  • Nombre de puces TPU: 1
  • Nombre de VM: 1
TPU Trillium (v6e) tpu-v6e-slice Un seul hôte
  • Topologie: 2x2
  • Nombre de puces TPU: 4
  • Nombre de VM: 4
TPU Trillium (v6e) tpu-v6e-slice Un seul hôte
  • Topologie : 2x4
  • Nombre de puces TPU: 8
  • Nombre de VM: 8
TPU Trillium (v6e) tpu-v6e-slice Hôte multiple
  • Topologie: 4x4
  • Nombre de puces TPU: 16
  • Nombre de VM: 4
TPU Trillium (v6e) tpu-v6e-slice Hôte multiple
  • Topologie: 4x8
  • Nombre de puces TPU: 32
  • Nombre de VM: 8
TPU Trillium (v6e) tpu-v6e-slice Hôte multiple
  • Topologie: 8x8
  • Nombre de puces TPU: 64
  • Nombre de VM: 16
TPU Trillium (v6e) tpu-v6e-slice Hôte multiple
  • Topologie: 8x16
  • Nombre de puces TPU: 128
  • Nombre de VM: 32
TPU Trillium (v6e) tpu-v6e-slice Hôte multiple
  • Topologie: 16x16
  • Nombre de puces TPU: 256
  • Nombre de VM: 64
TPU v5p tpu-v5p-slice Un seul hôte
  • Topologie: 2x2x1
  • Nombre de puces TPU: 4
  • Nombre de VM: 1
TPU v5p tpu-v5p-slice Hôte multiple
  • Topologie: 2x2x2
  • Nombre de puces TPU: 8
  • Nombre de VM: 2
TPU v5p tpu-v5p-slice Hôte multiple
  • Topologie : 2x2x4
  • Nombre de puces TPU: 16
  • Nombre de VM: 4
TPU v5p tpu-v5p-slice Hôte multiple
  • Topologie: 2x4x4
  • Nombre de puces TPU: 32
  • Nombre de VM: 8
TPU v5p tpu-v5p-slice Hôte multiple
  • Topologie: 4x4x4
  • Nombre de puces TPU: 64
  • Nombre de VM: 16
TPU v5p tpu-v5p-slice Hôte multiple
  • Topologie: {A}x{B}x{C}
  • Nombre de puces TPU: {A}*{B}*{C}
  • Nombre de VM: (A*B*C/4)1
TPU v5e tpu-v5-lite-podslice Un seul hôte
  • Topologie: 1x1
  • Nombre de puces TPU: 1
  • Nombre de VM: 1
TPU v5e tpu-v5-lite-podslice Un seul hôte
  • Topologie: 2x2
  • Nombre de puces TPU: 4
  • Nombre de VM: 1
TPU v5e tpu-v5-lite-podslice Un seul hôte
  • Topologie : 2x4
  • Nombre de puces TPU: 8
  • Nombre de VM: 1
TPU v5e tpu-v5-lite-podslice Hôte multiple
  • Topologie : 2x4
  • Nombre de puces TPU: 8
  • Nombre de VM: 2
TPU v5e tpu-v5-lite-podslice Hôte multiple
  • Topologie: 4x4
  • Nombre de puces TPU: 16
  • Nombre de VM: 4
TPU v5e tpu-v5-lite-podslice Hôte multiple
  • Topologie: 4x8
  • Nombre de puces TPU: 32
  • Nombre de VM: 8
TPU v5e tpu-v5-lite-podslice Hôte multiple
  • Topologie: 8x8
  • Nombre de puces TPU: 64
  • Nombre de VM: 16
TPU v5e tpu-v5-lite-podslice Hôte multiple
  • Topologie: 8x16
  • Nombre de puces TPU: 128
  • Nombre de VM: 32
TPU v5e tpu-v5-lite-podslice Hôte multiple
  • Topologie: 16x16
  • Nombre de puces TPU: 256
  • Nombre de VM: 64
TPU v5e (hôte unique uniquement) tpu-v5-lite-device Un seul hôte
  • Topologie: 1x1
  • Nombre de puces TPU: 1
  • Nombre de VM: 1
TPU v5e (hôte unique uniquement) tpu-v5-lite-device Un seul hôte
  • Topologie: 2x2
  • Nombre de puces TPU: 4
  • Nombre de VM: 1
TPU v5e (hôte unique uniquement) tpu-v5-lite-device Un seul hôte
  • Topologie : 2x4
  • Nombre de puces TPU: 8
  • Nombre de VM: 1
TPU v4 tpu-v4-podslice Un seul hôte
  • Topologie: 2x2x1
  • Nombre de puces TPU: 4
  • Nombre de VM: 1
TPU v4 tpu-v4-podslice Hôte multiple
  • Topologie: 2x2x2
  • Nombre de puces TPU: 8
  • Nombre de VM: 2
TPU v4 tpu-v4-podslice Hôte multiple
  • Topologie : 2x2x4
  • Nombre de puces TPU: 16
  • Nombre de VM: 4
TPU v4 tpu-v4-podslice Hôte multiple
  • Topologie: 2x4x4
  • Nombre de puces TPU: 32
  • Nombre de VM: 8
TPU v4 tpu-v4-podslice Hôte multiple
  • Topologie: 4x4x4
  • Nombre de puces TPU: 64
  • Nombre de VM: 16
TPU v4 tpu-v4-podslice Hôte multiple
  • Topologie: {A}x{B}x{C}
  • Nombre de puces TPU: {A}*{B}*{C}
  • Nombre de VM: (A*B*C/4)1
TPU v3 tpu-v3-slice Hôte multiple
  • Topologie: 4x4
  • Nombre de puces TPU: 16
  • Nombre de VM: 2
TPU v3 tpu-v3-slice Hôte multiple
  • Topologie: 4x8
  • Nombre de puces TPU: 32
  • Nombre de VM: 4
TPU v3 tpu-v3-slice Hôte multiple
  • Topologie: 8x8
  • Nombre de puces TPU: 64
  • Nombre de VM: 8
TPU v3 tpu-v3-slice Hôte multiple
  • Topologie: 8x16
  • Nombre de puces TPU: 128
  • Nombre de VM: 16
TPU v3 tpu-v3-slice Hôte multiple
  • Topologie: 16x16
  • Nombre de puces TPU: 256
  • Nombre de VM: 32
TPU v3 tpu-v3-device Un seul hôte
  • Topologie: 2x2
  • Nombre de puces TPU: 4
  • Nombre de VM: 1
  1. Calcul effectué en divisant le produit de topologie par quatre.

    Les topologies personnalisées pour plus de 64 puces sont acceptées. Les conditions suivantes s'appliquent :

    • Pour plus de 64 puces, {A}, {B} et {C} doivent être des multiples de 4.
    • La topologie la plus grande est 16x16x24
    • Les valeurs doivent être {A}{B}{C}, par exemple 8x12x16.
  2. Les topologies personnalisées ne sont pas acceptées.

Standard

Après avoir choisi un type et une topologie de TPU, spécifiez-les dans le fichier manifeste de votre charge de travail. Pour obtenir des instructions, consultez la section Déployer des charges de travail TPU sur GKE Standard.

Version du TPU Type de machine Type de pool de nœuds Spécifications techniques
TPU Trillium (v6e) ct6e-standard-1t Un seul hôte
  • Topologie: 1x1
  • Nombre de puces TPU: 1
  • Nombre de VM: 1
TPU Trillium (v6e) ct6e-standard-8t Un seul hôte
  • Topologie : 2x4
  • Nombre de puces TPU: 8
  • Nombre de VM: 1
TPU Trillium (v6e) ct6e-standard-4t Un seul hôte
  • Topologie: 2x2
  • Nombre de puces TPU: 4
  • Nombre de VM: 1
TPU Trillium (v6e) ct6e-standard-4t Hôte multiple
  • Topologie : 2x4
  • Nombre de puces TPU: 8
  • Nombre de VM: 2
TPU Trillium (v6e) ct6e-standard-4t Hôte multiple
  • Topologie: 4x4
  • Nombre de puces TPU: 16
  • Nombre de VM: 4
TPU Trillium (v6e) ct6e-standard-4t Hôte multiple
  • Topologie: 4x8
  • Nombre de puces TPU: 32
  • Nombre de VM: 8
TPU Trillium (v6e) ct6e-standard-4t Hôte multiple
  • Topologie: 8x8
  • Nombre de puces TPU: 64
  • Nombre de VM: 16
TPU Trillium (v6e) ct6e-standard-4t Hôte multiple
  • Topologie: 8x16
  • Nombre de puces TPU: 128
  • Nombre de VM: 32
TPU Trillium (v6e) ct6e-standard-4t Hôte multiple
  • Topologie: 16x16
  • Nombre de puces TPU: 256
  • Nombre de VM: 64
TPU v5p ct5p-hightpu-4t Un seul hôte
  • Topologie: 2x2x1
  • Nombre de puces TPU: 4
  • Nombre de VM: 1
TPU v5p ct5p-hightpu-4t Hôte multiple
  • Topologie: 2x2x2
  • Nombre de puces TPU: 8
  • Nombre de VM: 2
TPU v5p ct5p-hightpu-4t Hôte multiple
  • Topologie : 2x2x4
  • Nombre de puces TPU: 16
  • Nombre de VM: 4
TPU v5p ct5p-hightpu-4t Hôte multiple
  • Topologie: 2x4x4
  • Nombre de puces TPU: 32
  • Nombre de VM: 8
TPU v5p ct5p-hightpu-4t Hôte multiple
  • Topologie: {A}x{B}x{C}
  • Nombre de puces TPU: A*B*C
  • Nombre de VM: (A*B*C/4)1
TPU v5e ct5lp-hightpu-1t Un seul hôte
  • Topologie: 1x1
  • Nombre de puces TPU: 1
  • Nombre de VM: 1
TPU v5e ct5lp-hightpu-4t Un seul hôte
  • Topologie: 2x2
  • Nombre de puces TPU: 4
  • Nombre de VM: 1
TPU v5e ct5lp-hightpu-8t Un seul hôte
  • Topologie : 2x4
  • Nombre de puces TPU: 8
  • Nombre de VM: 1
TPU v5e ct5lp-hightpu-4t Hôte multiple
  • Topologie : 2x4
  • Nombre de puces TPU: 8
  • Nombre de VM: 2
TPU v5e ct5lp-hightpu-4t Hôte multiple
  • Topologie: 4x4
  • Nombre de puces TPU: 16
  • Nombre de VM: 4
TPU v5e ct5lp-hightpu-4t Hôte multiple
  • Topologie: 4x8
  • Nombre de puces TPU: 32
  • Nombre de VM: 8
TPU v5e ct5lp-hightpu-4t Hôte multiple
  • Topologie: 8x8
  • Nombre de puces TPU: 64
  • Nombre de VM: 16
TPU v5e ct5lp-hightpu-4t Hôte multiple
  • Topologie: 8x16
  • Nombre de puces TPU: 128
  • Nombre de VM: 32
TPU v5e ct5p-hightpu-4t Hôte multiple
  • Topologie: 2x4x4
  • Nombre de puces TPU: 32
  • Nombre de VM: 8
TPU v5e ct5p-hightpu-4t Un seul hôte
  • Topologie: 2x2x1
  • Nombre de puces TPU: 4
  • Nombre de VM: 1
TPU v4 ct4p-hightpu-4t Hôte multiple
  • Topologie: 2x2x2
  • Nombre de puces TPU: 8
  • Nombre de VM: 2
TPU v4 ct4p-hightpu-4t Hôte multiple
  • Topologie : 2x2x4
  • Nombre de puces TPU: 16
  • Nombre de VM: 4
TPU v4 ct4p-hightpu-4t Hôte multiple
  • Topologie: 2x4x4
  • Nombre de puces TPU: 32
  • Nombre de VM: 8
TPU v4 ct4p-hightpu-4t Hôte multiple
  • Topologie: {A}x{B}x{C}
  • Nombre de puces TPU: A*B*C
  • Nombre de VM: (A*B*C/4)1
TPU v3 ct3-hightpu-4t Un seul hôte
  • Topologie: 2x2
  • Nombre de puces TPU: 4
  • Nombre de VM: 1
TPU v3 ct3p-hightpu-4t Hôte multiple
  • Topologie: 4x4
  • Nombre de puces TPU: 16
  • Nombre de VM: 4
TPU v3 ct3p-hightpu-4t Hôte multiple
  • Topologie: 4x8
  • Nombre de puces TPU: 32
  • Nombre de VM: 8
TPU v3 ct3p-hightpu-4t Hôte multiple
  • Topologie: 8x8
  • Nombre de puces TPU: 64
  • Nombre de VM: 16
TPU v3 ct3p-hightpu-4t Hôte multiple
  • Topologie: 8x16
  • Nombre de puces TPU: 128
  • Nombre de VM: 32
TPU v3 ct3p-hightpu-4t Hôte multiple
  • Topologie: 16x16
  • Nombre de puces TPU: 256
  • Nombre de VM: 64
TPU v3 ct3p-hightpu-4t Hôte multiple
  • Topologie: 16x32
  • Nombre de puces TPU: 512
  • Nombre de VM: 128
TPU v3 ct3p-hightpu-4t Hôte multiple
  • Topologie: 32x32
  • Nombre de puces TPU: 1 024
  • Nombre de VM: 256
  1. Calcul effectué en divisant le produit de topologie par quatre.

Configurations avancées

Les sections suivantes décrivent les bonnes pratiques de planification pour les configurations avancées de TPU.

Réservation TPU

Les réservations TPU sont disponibles lors de la souscription d'un engagement. Toute réservation TPU peut être utilisée avec GKE.

Lorsque vous créez un pool de nœuds des tranches TPU, utilisez les options --reservation et --reservation-affinity=specific pour consommer une instance TPU réservée.

Autoscaling des TPU dans GKE

GKE est compatible avec les TPU (Tensor Processing Units) pour accélérer les charges de travail de machine learning. Le pool de nœuds de tranche TPU à hôte unique et le pool de nœuds de tranche TPU multi-hôte sont tous deux compatibles avec l'autoscaling et le provisionnement automatique.

Avec l'option --enable-autoprovisioning sur un cluster GKE, GKE crée ou supprime des pools de nœuds de tranche TPU à hôte unique ou multi-hôte avec une version et une topologie de TPU qui répondent aux exigences des charges de travail en attente.

Lorsque vous utilisez --enable-autoscaling, GKE procède au scaling du pool de nœuds en fonction de son type, comme suit :

  • Pool de nœuds de tranche TPU à hôte unique : GKE ajoute ou supprime des nœuds TPU dans le pool de nœuds existant. Le pool de nœuds peut contenir un nombre de nœuds TPU compris entre zéro et la taille maximale du pool de nœuds, tel que déterminé par les options --max-nodes et --total-max-nodes. Lorsque le pool de nœuds effectue un scaling, tous les nœuds TPU du pool de nœuds ont le même type de machine et la même topologie. Pour en savoir plus sur la création d'un pool de nœuds de tranche TPU à hôte unique, consultez la section Créer un pool de nœuds.

  • Pool de nœuds de tranche TPU multi-hôte : GKE effectue un scaling du pool de nœuds de façon atomique, de zéro jusqu'au nombre de nœuds requis pour satisfaire la topologie TPU. Par exemple, pour un pool de nœuds TPU avec un type de machine ct5lp-hightpu-4t et une topologie 16x16, le pool de nœuds contient 64 nœuds. L'autoscaler GKE s'assure que ce pool de nœuds comporte exactement 0 ou 64 nœuds. Lors d'un nouveau scaling à la baisse, GKE supprime tous les pods planifiés et draine l'intégralité du pool de nœuds jusqu'à zéro. Pour en savoir plus sur la création d'un pool de nœuds de tranche TPU multi-hôte, consultez la section Créer un pool de nœuds.

Provisionner un espace de stockage supplémentaire pour une tranche de TPU

Une VM dans une tranche de TPU inclut un disque de démarrage de 100 Go. Si votre tranche de TPU nécessite un espace de stockage supplémentaire pour l'entraînement ou le prétraitement, ou si vous devez enregistrer des points de contrôle, vous pouvez utiliser l'espace de stockage Google Cloud Hyperdisk ou Balanced Persistent Disk, s'il est disponible pour votre TPU. Pour en savoir plus sur les types de disques compatibles avec chaque version de TPU, consultez la section Compatibilité des TPU avec Hyperdisk et Persistent Disk.

Processeur pour les clusters standards

Cette section ne s'applique pas aux clusters Autopilot, car GKE place chaque tranche TPU sur son propre nœud. Pour en savoir plus, consultez Fonctionnement des TPU en mode Autopilot.

Pour les clusters standards, tenez compte des bonnes pratiques de planification suivantes.

Pour planifier une charge de travail non TPU sur une VM dans un nœud de tranche de TPU, assurez-vous que votre pod GKE peut tolérer le rejet google.com/tpu. Si vous souhaitez que la charge de travail soit déployée sur des nœuds spécifiques, utilisez des sélecteurs de nœuds.

La gestion et la priorité des ressources Kubernetes traitent les VM sur les TPU de la même manière que les autres types de VM. Pour attribuer aux pods nécessitant des TPU une priorité de planification sur les autres pods des mêmes nœuds, demandez la quantité maximale de processeurs ou de mémoire de ces tranches de TPU. Les segments de TPU de faible priorité doivent effectuer les opérations suivantes:

  1. Définissez un nombre faible de demandes de ressources mémoire et de processeur pour vous assurer que le nœud dispose de suffisamment de ressources pouvant être allouées aux charges de travail TPU. Pour en savoir plus, consultez la section Comment Kubernetes applique les demandes et les limites de ressources.
  2. Définissez aucune limite de processeur (illimité) pour vous assurer que les pods peuvent s'étendre et utiliser tous les cycles inutilisés.
  3. Définissez des limites de mémoire appropriées pour que les pods fonctionnent correctement sans risquer d'éviction en cas de pression sur le nœud.

Si un pod Kubernetes ne demande pas de ressources processeur et de mémoire (même s'il demande des TPU), Kubernetes le considère comme un pod "best effort", et rien ne garantit qu'il ait besoin de processeur et de mémoire. Seuls les pods qui demandent explicitement des ressources de processeur et de mémoire disposent de ces garanties. Pour une planification Kubernetes spécifique, configurez les besoins du pod avec une requête de processeur et de mémoire explicite. Pour en savoir plus, consultez Gestion des ressources pour les pods et les conteneurs.

Pour en savoir plus sur les bonnes pratiques, consultez Bonnes pratiques Kubernetes: demandes de ressources et limites.

Réduire les interruptions de la charge de travail

Si vous utilisez des TPU pour entraîner un modèle de machine learning et que votre charge de travail est interrompue, tous les travaux effectués depuis le dernier point de contrôle sont perdus. Pour réduire la probabilité d'interruption de votre charge de travail, procédez comme suit :

  • Définissez une priorité plus élevée pour cette tâche que pour toutes les autres tâches : si les ressources sont peu nombreuses, le programmeur GKE préempte les tâches de priorité inférieure pour planifier une tâche de priorité supérieure. Cela garantit également que votre charge de travail prioritaire reçoit toutes les ressources dont elle a besoin (jusqu'à la quantité totale de ressources disponibles dans le cluster). Pour en savoir plus, consultez Priorité et préemption des pods.
  • Configurez l'exclusion de maintenance : une exclusion de maintenance est une période non récurrente pendant laquelle la maintenance automatique est interdite. Pour en savoir plus, consultez la section Exclusions de maintenance.
  • Utiliser des pods à durée d'exécution prolongée dans Autopilot : utilisez des pods à durée d'exécution prolongée pendant un délai de grâce allant jusqu'à sept jours avant que GKE n'arrête vos pods pour effectuer des scalings à la baisse ou les mises à niveau de nœuds.
  • Utiliser la planification de collection dans TPU Trillium: utilisez des collections pour indiquer qu'un pool de nœuds de tranche TPU fait partie d'une charge de travail de diffusion. Google Cloud limite et simplifie les interruptions des opérations des charges de travail d'inférence. Pour en savoir plus, consultez Fonctionnement de la planification des collectes.

Ces recommandations permettent de minimiser les interruptions, mais ne les empêchent pas. Par exemple, une préemption due à une défaillance matérielle ou une préemption pour défragmentation peut toujours se produire. De même, la définition d'une exclusion de maintenance GKE n'empêche pas les événements de maintenance Compute Engine.

Bonne pratique:

Enregistrez fréquemment les points de contrôle et ajoutez du code à votre script d'entraînement pour commencer à partir du dernier point de contrôle lors de la reprise.

Gérer les perturbations dues à la maintenance des nœuds

Les nœuds GKE qui hébergent les TPU sont soumis à des événements de maintenance ou à d'autres perturbations susceptibles d'entraîner l'arrêt du nœud. Dans les clusters GKE dont le plan de contrôle exécute les versions 1.29.1-gke.1425000 et ultérieures, vous pouvez réduire les perturbations sur les charges de travail en configurant GKE pour qu'il arrête correctement vos charges de travail.

Pour comprendre, configurer et surveiller les événements d'interruption pouvant se produire sur les nœuds GKE exécutant des charges de travail d'IA/ML, consultez la section Gérer les interruptions des nœuds GKE pour les GPU et les TPU.

Maximiser l'utilisation du TPU

Pour optimiser votre investissement dans les TPU, planifiez un mélange de priorités de tâches et mettez-les en file d'attente afin de maximiser le temps de fonctionnement de vos TPU. Pour la planification et la préemption au niveau des tâches, vous devez utiliser un module complémentaire de Kubernetes qui organise les tâches en files d'attente.

Bonne pratique:

Utilisez Kueue pour organiser les tâches en files d'attente.

Étapes suivantes