Présentation des TPU dans GKE

Les clients Google Kubernetes Engine (GKE) peuvent désormais créer Pools de nœuds Kubernetes contenant des tranches TPU v4 et v5e. Pour plus d'informations sur les TPU, consultez la page Architecture du système.

Lorsque vous utilisez GKE, vous devez d'abord créer Cluster GKE. Vous ajoutez ensuite des pools de nœuds à votre cluster. Les pools de nœuds GKE sont des ensembles de VM qui partagent les mêmes attributs. Pour les charges de travail TPU, les pools de nœuds sont constitués de VM TPU.

Types de pools de nœuds

GKE est compatible avec deux types de pools de nœuds TPU:

Pool de nœuds des tranches TPU multi-hôtes

Un pool de nœuds de tranches TPU multi-hôtes est un pool de nœuds contenant au moins deux des VM TPU interconnectées. Un appareil TPU est connecté à chaque VM. Les TPU une tranche à hôtes multiples sont connectés via une interconnexion à haut débit (ICI). Une fois qu'un un pool de nœuds de tranches à hôtes multiples est créé, vous ne pouvez pas y ajouter de nœuds. Par exemple, vous ne pouvez pas créer un pool de nœuds v4-32, puis ajouter par la suite un autre pool de nœuds Kubernetes (VM TPU) au pool de nœuds. Pour ajouter une tranche TPU supplémentaire à une cluster GKE, vous devez créer un pool de nœuds.

Les hôtes d'un pool de nœuds de tranches TPU multi-hôtes sont traités comme une seule unité atomique. Si GKE n'est pas en mesure de déployer un nœud de la tranche, aucune les nœuds de la tranche seront déployés.

Si un nœud d'une tranche TPU multi-hôte doit être réparé, GKE toutes les VM TPU de la tranche, forçant ainsi tous les pods Kubernetes du charge de travail doit être évincée. Une fois que toutes les VM TPU de la tranche sont opérationnelles, Les pods Kubernetes peuvent être programmés sur les VM TPU de la nouvelle tranche.

Le schéma suivant montre un exemple de TPU à plusieurs hôtes v5litepod-16 (v5e) tranche. Cette tranche comporte quatre VM TPU. Chaque VM TPU est dotée de quatre puces TPU v5e connectées avec des interconnexions à haut débit (ICI), et chaque puce TPU v5e est dotée d'un TensorCore.

Schéma des tranches de TPU multi-hôte

Le schéma suivant montre un cluster GKE contenant un cluster Tranche de TPU v5litepod-16 (v5e) (topologie: 4x4) et un TPU v5litepod-8 (v5e) tranche (topologie: 2x4):

Schéma du pod TPU v5e

Pour obtenir un exemple d'exécution d'une charge de travail sur une tranche TPU à hôtes multiples, consultez Exécutez votre charge de travail sur des TPU.

Pools de nœuds de tranches TPU à hôte unique

Une tranche à hôte unique est un pool de nœuds contenant un ou plusieurs des VM TPU indépendantes. Un appareil TPU est connecté à chaque VM. Alors que les VM au sein d'un pool de nœuds de tranches à hôte unique peuvent communiquer via le centre de données (DCN), les TPU associés aux VM ne sont pas interconnectés.

Le schéma suivant montre un exemple de tranche TPU à hôte unique avec sept ensembles de données Machines v4-8:

Diagramme du pool de nœuds de tranches à hôte unique

Pour obtenir un exemple d'exécution d'une charge de travail sur une tranche TPU à un seul hôte, reportez-vous à la section Exécutez votre charge de travail sur des TPU.

Types de machines TPU pour les pools de nœuds GKE

Avant de créer des pools de nœuds, vous devez choisir la version et la taille du TPU Tranche TPU requise par votre charge de travail. TPU v4 est compatible avec GKE Version standard 1.26.1-gke.1500 et ultérieure, v5e dans GKE Version standard 1.27.2-gke.2100 ou ultérieure, et v5p dans GKE Standard 1.28.3-gke.1024000 et versions ultérieures.

Les TPU v4, v5e et v5p sont compatibles avec GKE Autopilot les versions 1.29.2-gke.1521000 et ultérieures.

Pour en savoir plus sur les caractéristiques matérielles des différents TPU, consultez la page Architecture du système. Quand ? créant un pool de nœuds TPU, sélectionnez une taille de tranche TPU (topologie de TPU) en fonction de la la taille de modèle et la quantité de mémoire requise. Type de machine que vous spécifiez lors de la création de vos pools de nœuds dépend de la version et de la taille de vos tranches.

V5E

Vous trouverez ci-dessous les topologies et types de machines TPU v5e compatibles. pour les cas d'utilisation d'entraînement et d'inférence:

Type de machine Topology Nombre de puces TPU Nombre de VM Cas d'utilisation recommandé
ct5lp-hightpu-1t 1x1 1 1 Entraînement, inférence à hôte unique
ct5lp-hightpu-4t 2x2 4 1 Entraînement, inférence à hôte unique
ct5lp-hightpu-8t 2x4 8 1 Entraînement, inférence à hôte unique
ct5lp-hightpu-4t 2x4 8 2 Entraînement, inférence multi-hôte
ct5lp-hightpu-4t 4x4 16 4 Entraînement à grande échelle, inférence sur plusieurs hôtes
ct5lp-hightpu-4t 4x8 32 8 Entraînement à grande échelle, inférence sur plusieurs hôtes
ct5lp-hightpu-4t 8x8 64 16 Entraînement à grande échelle, inférence sur plusieurs hôtes
ct5lp-hightpu-4t 8x16 128 32 Entraînement à grande échelle, inférence sur plusieurs hôtes
ct5lp-hightpu-4t 16x16 256 64 Entraînement à grande échelle, inférence sur plusieurs hôtes

Cloud TPU v5e est un produit combiné d'entraînement et d'inférence. Les jobs d'entraînement optimisé pour le débit et la disponibilité, tandis que les jobs d'inférence sont optimisés la latence. Pour en savoir plus, consultez la page Types d'accélérateurs d'entraînement v5e. et les types d'accélérateurs d'inférence v5e.

Les machines TPU v5e sont disponibles dans us-west4-a, us-east5-b et us-east1-c. Les clusters GKE Standard doivent exécuter le plan de contrôle version 1.27.2-gke.2100 ou ultérieure. GKE Autopilot devez exécuter le plan de contrôle 1.29.2-gke.1521000 ou une version ultérieure. Pour plus d'informations consultez la page Entraînement Cloud TPU v5e.

Comparaison des types de machines :

Type de machine ct5lp-hightpu-1t ct5lp-hightpu-4t ct5lp-hightpu-8t
Nombre de puces v5e 1 4 8
Nombre de vCPU 24 112 224
Mémoire RAM (Go) 48 192 384
Nombre de nœuds NUMA 1 1 2
Probabilité de préemption Élevée Moyenne Faible

Pour libérer de l'espace pour les VM comportant plus de puces, le programmeur GKE peut préempter et replanifier des VM avec moins de puces. Les VM à 8 puces sont donc plus susceptibles pour préempter des VM à 1 ou 4 puces.

v4 et v5p

Voici les types de machines TPU v4 et v5p:

Type de machine Nombre de processeurs virtuels Mémoire (Go) Nombre de nœuds NUMA
ct4p-hightpu-4t 240 407 2
ct5p-hightpu-4t 208 448 2

Lors de la création d'une tranche TPU v4, utilisez le type de machine ct4p-hightpu-4t qui a un hôte et contient 4 chips. Consultez la page Topologies v4. et l'architecture du système TPU des informations. Les types de machines de tranches TPU v4 sont disponibles dans us-central2-b. Votre Les clusters GKE Standard doivent exécuter le plan de contrôle version 1.26.1-gke.1500 ou ultérieure. GKE Autopilot les clusters doivent exécuter le plan de contrôle 1.29.2-gke.1521000 ou une version ultérieure.

Lorsque vous créez une tranche TPU v5p, utilisez le type de machine ct5p-hightpu-4t qui a un hôte et contient 4 chips. Les types de machines des tranches TPU v5p sont disponibles en us-west4-a et us-east5-a. GKE Standard les clusters doivent exécuter le plan de contrôle 1.28.3-gke.1024000 ou une version ultérieure. GKE Autopilot doit exécuter 1.29.2-gke.1521000 ou plus tard. Pour en savoir plus sur v5p, consultez la présentation de l'entraînement v5p.

Limites et problèmes connus

  • Nombre maximal de pods Kubernetes: vous pouvez exécuter jusqu'à 256 pods Pods Kubernetes dans une VM TPU unique.
  • Réservations SPÉCIFIQUES uniquement: lorsque vous utilisez des TPU dans GKE, SPECIFIC est la seule valeur acceptée pour l'option --reservation-affinity. de la commande gcloud container node-pools create.
  • Seule la variante de VM Spot des TPU préemptifs est compatible: VM Spot sont semblables aux VM préemptives et soumises à la même disponibilité , mais la durée maximale n'est pas de 24 heures.
  • Aucune compatibilité avec la répartition des coûts: répartition des coûts GKE et mesure de l'utilisation n'incluent aucune donnée sur l'utilisation ou les coûts des TPU.
  • L'autoscaler peut calculer la capacité: l'autoscaler de cluster peut calculer la capacité. la capacité est incorrecte pour les nouveaux nœuds contenant des VM TPU avant que ces nœuds ne soient disponibles. L'autoscaler de cluster peut ensuite effectuer un scaling à la hausse créent plus de nœuds que nécessaire. L'autoscaler de cluster effectue un scaling à la baisse des nœuds supplémentaires, s'ils ne sont pas nécessaires, après une opération de scaling à la baisse régulière.
  • L'autoscaler annule le scaling à la hausse: l'autoscaler de cluster annule le scaling à la hausse du TPU. les pools de nœuds qui restent en attente pendant plus de 10 heures. Cluster L'autoscaler relancera ces opérations de scaling à la hausse ultérieurement. Ce comportement peut réduire l'obtention de TPU pour les clients qui n'utilisent pas de réservations.
  • La teinte peut empêcher le scaling à la baisse: les charges de travail non-TPU qui ont une tolérance pour Le rejet TPU peut empêcher le scaling à la baisse du pool de nœuds s'il est recréé pendant le drainage du pool de nœuds TPU.

Assurez-vous que les quotas TPU et GKE sont suffisants

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

Les quotas suivants ont des valeurs par défaut que vous devrez probablement augmenter:

  • Quota de disques persistants SSD (Go): le disque de démarrage de chaque nœud Kubernetes nécessite 100 Go par défaut. Ce quota doit donc être défini au moins sur au nombre maximal de nœuds GKE que vous prévoyez création) * 100 Go.
  • Quota d'adresses IP en cours d'utilisation: chaque nœud Kubernetes utilise une adresse IP. Ce quota doit donc être au moins égal au nombre maximal nœuds GKE que vous prévoyez de créer.

Pour demander une augmentation du quota, consultez la section Demander un quota supérieur. Pour en savoir plus sur les types de quotas TPU, consultez la section Quotas TPU.

L'approbation de vos demandes d'augmentation de quota peut prendre quelques jours. Si vous rencontrer des difficultés pour faire approuver vos demandes d'augmentation de quota dans un délai quelques jours avant, contactez l'équipe chargée de votre compte Google.

Migrer votre réservation TPU

Si vous ne prévoyez pas d'utiliser une réservation TPU existante avec des TPU dans GKE, ignorez cette section et accédez à la section Créer un cluster Google Kubernetes Engine.

Pour utiliser des TPU réservés avec GKE, vous devez d'abord migrer votre réservation TPU vers une nouvelle réservation basée sur Compute Engine ; du système d'exploitation.

Il y a plusieurs points importants à connaître sur cette migration:

  • Capacité TPU migrée vers la nouvelle réservation basée sur Compute Engine ne peut pas être utilisé avec l'API Queued Resource de Cloud TPU. Si vous avez l'intention d'utiliser des ressources en file d'attente TPU avec votre réservation, vous devez vous devez migrer une partie de votre réservation TPU un système de réservation basé sur Compute Engine.
  • Aucune charge de travail ne peut s'exécuter activement sur les TPU lorsqu'elles sont migrées vers le un nouveau système de réservation basé sur Compute Engine.
  • Sélectionnez l'heure à laquelle effectuer la migration et travaillez avec votre chargée de votre compte pour planifier la migration. La période de migration doit être pendant les heures de bureau (du lundi au vendredi, de 9 h 00 à 17 h 00 heure du Pacifique).

Créer un cluster Google Kubernetes Engine

Consultez la section Créer un cluster dans la documentation Google Kubernetes Engine.

Créer un pool de nœuds TPU

Consultez la section Créer un pool de nœuds. dans la documentation Google Kubernetes Engine.

Exécuter sans le mode privilégié

Si vous souhaitez réduire le champ d'application des autorisations sur votre conteneur, consultez Mode privilège TPU.

Exécuter des charges de travail dans des pools de nœuds TPU

Consultez la page Exécuter vos charges de travail GKE sur des TPU. dans la documentation Google Kubernetes Engine.

Sélecteurs de nœuds

Pour que Kubernetes puisse planifier votre charge de travail sur des nœuds contenant des VM TPU, vous devez spécifier deux sélecteurs pour chaque nœud dans votre fichier manifeste Google Kubernetes Engine:

  • Définir cloud.google.com/gke-accelerator-type sur tpu-v5-lite-podslice, tpu-v5p-slice ou tpu-v4-podslice.
  • Définissez cloud.google.com/gke-tpu-topology sur la topologie TPU du nœud.

Les sections Charges de travail d'entraînement et Charges de travail d'inférence contiennent des exemples de fichiers manifestes illustrant l'utilisation de ces sélecteurs de nœuds.

Considérations sur la planification des charges de travail

Les TPU présentent des caractéristiques uniques qui nécessitent une planification et une utilisation spécifiques des charges de travail dans Kubernetes. Pour en savoir plus, consultez la page Considérations relatives à la planification des charges de travail. dans la documentation GKE.

Réparation des nœuds

Si un nœud d'un pool de nœuds de tranches TPU multi-hôtes n'est pas opérationnel, GKE recrée l'intégralité du pool de nœuds. Pour en savoir plus, consultez Réparation automatique des nœuds. dans la documentation GKE.

Tranches multiples : aller au-delà d'une seule tranche

Vous pouvez agréger des tranches plus petites en une multitranche pour traiter de plus grandes les charges de travail d'entraînement. Pour en savoir plus, consultez la page Cloud TPU multi-tranche.

Tutoriels sur les charges de travail d'entraînement

Ces tutoriels se concentrent sur les charges de travail d'entraînement sur une tranche TPU à hôtes multiples (par exemple, (4 machines v5e, par exemple). Elles couvrent les modèles suivants:

  • Modèles FLAX Hugging Face: Train Diffusion sur Pokémon
  • PyTorch/XLA: GPT2 sur WikiText

Télécharger les ressources du tutoriel

Télécharger les scripts Python du tutoriel et les spécifications YAML pour chaque modèle pré-entraîné en exécutant la commande suivante:

git clone https://github.com/GoogleCloudPlatform/ai-on-gke.git

Créer et se connecter au cluster

Créez un cluster GKE régional pour que le cluster Kubernetes plan de contrôle est répliqué dans trois zones, ce qui offre une plus grande disponibilité. Créez votre cluster dans us-west4, us-east1 ou us-central2, en fonction de Version TPU que vous utilisez. Pour en savoir plus sur les TPU et les zones, consultez la page Régions et zones de Cloud TPU.

La commande suivante crée un cluster GKE régional abonné au version disponible rapide avec un pool de nœuds contenant initialement un nœud par zone. Cette commande active également la fédération d'identité de charge de travail pour GKE et fonctionnalités du pilote CSI Cloud Storage FUSE sur votre cluster, car l'exemple les charges de travail d'inférence de ce guide utilisent des buckets Cloud Storage pour stocker des modèles pré-entraînés.

gcloud container clusters create cluster-name \
  --region your-region \
  --release-channel rapid \
  --num-nodes=1 \
  --workload-pool=project-id.svc.id.goog \
  --addons GcsFuseCsiDriver

Pour activer la fédération d'identité de charge de travail pour GKE et les fonctionnalités du pilote CSI Cloud Storage FUSE pour des clusters existants, exécutez la commande suivante:

gcloud container clusters update cluster-name \
  --region your-region \
  --update-addons GcsFuseCsiDriver=ENABLED \
  --workload-pool=project-id.svc.id.goog

Les exemples de charges de travail sont configurés avec les hypothèses suivantes:

  • le pool de nœuds utilise tpu-topology=4x4 avec quatre nœuds
  • le pool de nœuds utilise machine-type ct5lp-hightpu-4t

Exécutez la commande suivante pour vous connecter au cluster que vous venez de créer:

gcloud container clusters get-credentials cluster-name \
--location=cluster-region

Modèles FLAX Hugging Face: Train Diffusion sur Pokémon

Cet exemple entraîne le modèle de diffusion stable à partir de HuggingFace à l'aide de la méthode Pokémon ensemble de données.

Le modèle Stable Diffusion est un modèle texte-image latent qui génère des images réalistes à partir de n'importe quelle entrée de texte. Pour en savoir plus sur la version stable, Diffusion, voir:

Créer une image Docker

Le Dockerfile se trouve dans le dossier ai-on-gke/tutorials-and-examples/tpu-examples/training/diffusion/

Avant d'exécuter la commande suivante, assurez-vous que votre compte dispose du bon autorisations que Docker doit transférer vers le dépôt.

Créez et transférez l'image Docker:

cd ai-on-gke/tutorials-and-examples/tpu-examples/training/diffusion/
docker build -t gcr.io/project-id/diffusion:latest .
docker push gcr.io/project-id/diffusion:latest

Déployer la charge de travail

Créez un fichier avec le contenu suivant et nommez-le tpu_job_diffusion.yaml. Remplissez le champ "Image" avec l'image que vous venez de créer.

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-job-diffusion
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-job-diffusion
spec:
  backoffLimit: 0
  # Completions and parallelism should be the number of chips divided by 4.
  # (e.g. 4 for a v5litepod-16)
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
        cloud.google.com/gke-tpu-topology: 4x4
      containers:
      - name: tpu-job-diffusion
        image: gcr.io/${project-id}/diffusion:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU usage metrics, if supported
        command:
        - bash
        - -c
        - |
          cd examples/text_to_image
          python3 train_text_to_image_flax.py --pretrained_model_name_or_path=duongna/stable-diffusion-v1-4-flax --dataset_name=lambdalabs/pokemon-blip-captions --resolution=128 --center_crop --random_flip --train_batch_size=4 --mixed_precision=fp16 --max_train_steps=1500 --learning_rate=1e-05 --max_grad_norm=1 --output_dir=sd-pokemon-model
        resources:
          requests:
            google.com/tpu: 4
          limits:
            google.com/tpu: 4

Déployez-la ensuite à l'aide de la commande suivante:

kubectl apply -f tpu_job_diffusion.yaml

Effectuer un nettoyage

Une fois l'exécution de votre job terminée, vous pouvez la supprimer à l'aide de la commande suivante:

kubectl delete -f tpu_job_diffusion.yaml

PyTorch/XLA: GPT2 sur WikiText

Ce tutoriel explique comment exécuter GPT2 sur des TPU v5e à l'aide de HuggingFace sur PyTorch/XLA à l'aide de l'ensemble de données wikitext.

Créer une image Docker

Le Dockerfile se trouve dans le dossier ai-on-gke/tutorials-and-examples/tpu-examples/training/gpt/.

Avant d'exécuter la commande suivante, assurez-vous que votre compte dispose du bon autorisations que Docker doit transférer vers le dépôt.

Créez et transférez l'image Docker:

cd ai-on-gke/tutorials-and-examples/tpu-examples/training/gpt/
docker build -t gcr.io/project-id/gpt:latest .
docker push gcr.io/project-id/gpt:latest

Déployer la charge de travail

Copiez le fichier YAML suivant et enregistrez-le dans un fichier nommé tpu_job_gpt.yaml. Remplir le champ "image" par l'image que vous venez de créer.

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-job-gpt
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-job-gpt
spec:
  backoffLimit: 0
  # Completions and parallelism should be the number of chips divided by 4.
  # (for example, 4 for a v5litepod-16)
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      volumes:
      # Increase size of tmpfs /dev/shm to avoid OOM.
      - name: shm
        emptyDir:
          medium: Memory
          # consider adding `sizeLimit: XGi` depending on needs
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
        cloud.google.com/gke-tpu-topology: 4x4
      containers:
      - name: tpu-job-gpt
        image: gcr.io/$(project-id)/gpt:latest
        ports:
        - containerPort: 8479
        - containerPort: 8478
        - containerPort: 8477
        - containerPort: 8476
        - containerPort: 8431 # Port to export TPU usage metrics, if supported.
        env:
        - name: PJRT_DEVICE
          value: 'TPU'
        - name: XLA_USE_BF16
          value: '1'
        command:
        - bash
        - -c
        - |
          numactl --cpunodebind=0 python3 -u examples/pytorch/xla_spawn.py   --num_cores 4 examples/pytorch/language-modeling/run_clm.py    --num_train_epochs 3 --dataset_name wikitext     --dataset_config_name wikitext-2-raw-v1 --per_device_train_batch_size 16    --per_device_eval_batch_size 16 --do_train --do_eval  --output_dir /tmp/test-clm     --overwrite_output_dir --config_name my_config_2.json --cache_dir /tmp --tokenizer_name gpt2  --block_size 1024 --optim adafactor --adafactor true --save_strategy no --logging_strategy no --fsdp "full_shard" --fsdp_config fsdp_config.json
        volumeMounts:
        - mountPath: /dev/shm
          name: shm
        resources:
          requests:
            google.com/tpu: 4
          limits:
            google.com/tpu: 4

Déployez le workflow à l'aide de la commande suivante:

kubectl apply -f tpu_job_gpt.yaml

Effectuer un nettoyage

Une fois l'exécution de votre job terminée, vous pouvez la supprimer à l'aide de la commande suivante:

kubectl delete -f tpu_job_gpt.yaml

Tutoriel: Charges de travail d'inférence à hôte unique

Ce tutoriel explique comment exécuter une charge de travail d'inférence à hôte unique sur TPU GKE v5e pour les modèles pré-entraînés avec JAX, TensorFlow, et PyTorch. De manière générale, vous devez effectuer quatre étapes distinctes Cluster GKE:

  1. Créer un bucket Cloud Storage et configurer l'accès à celui-ci Vous utilisez un Le bucket Cloud Storage sert à stocker le modèle pré-entraîné.

  2. Télécharger un modèle pré-entraîné et le convertir en modèle compatible TPU. Appliquer un le pod Kubernetes qui télécharge le modèle pré-entraîné utilise Convertisseur Cloud TPU et stocke les modèles convertis dans un bucket Cloud Storage à l'aide du pilote CSI Cloud Storage FUSE. Le convertisseur Cloud TPU ne nécessite pas de matériel spécialisé. Ce tutoriel vous explique comment télécharger le modèle et exécuter le convertisseur Cloud TPU dans le pool de nœuds CPU.

  3. Lancer le serveur du modèle converti Appliquer un déploiement qui diffuse le modèle à l'aide d'un framework de serveurs reposant sur le volume stocké le volume persistant ReadOnlyMany (ROX). Les instances répliquées de déploiement doivent être exécutées dans un pool de nœuds de tranches v5e avec un pod Kubernetes par nœud. dans un pool de nœuds de tranches v5e avec un pod Kubernetes par nœud.

  4. Déployer un équilibreur de charge pour tester le serveur de modèles Le serveur est exposé Requêtes externes via le service LoadBalancer Un script Python est fourni avec un exemple de requête pour tester le de création de modèles.

Le schéma suivant montre comment les requêtes sont acheminées par l'équilibreur de charge.

Schéma illustrant le routage de l'équilibreur de charge

Exemples de déploiement de serveur

Ces exemples de charges de travail sont configurés selon les hypothèses suivantes:

  • Le cluster est exécuté avec un pool de nœuds TPU v5 comportant trois nœuds
  • Le pool de nœuds utilise le type de machine ct5lp-hightpu-1t où:
    • est de type 1 x 1
    • le nombre de puces TPU est de 1

Le fichier manifeste GKE suivant définit un seul hôte le déploiement du serveur.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: bert-deployment
spec:
  selector:
    matchLabels:
      app: tf-bert-server
  replicas: 3 # number of nodes in node pool
  template:
    metadata:
      annotations:
        gke-gcsfuse/volumes: "true"
      labels:
        app: tf-bert-server
    spec:
      nodeSelector:
        cloud.google.com/gke-tpu-topology: 1x1  # target topology
        cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice  # target version
      containers:
      - name: serve-bert
        image: us-docker.pkg.dev/cloud-tpu-images/inference/tf-serving-tpu:2.13.0
        env:
        - name: MODEL_NAME
          value: "bert"
        volumeMounts:
        - mountPath: "/models/"
          name: bert-external-storage
        ports:
        - containerPort: 8500
        - containerPort: 8501
        - containerPort: 8431 # Port to export TPU usage metrics, if supported.
        resources:
          requests:
            google.com/tpu: 1 # TPU chip request
          limits:
            google.com/tpu: 1 # TPU chip request
      volumes:
      - name: bert-external-storage
        persistentVolumeClaim:
          claimName: external-storage-pvc

Si vous utilisez un nombre différent de nœuds dans votre pool de nœuds TPU, modifiez le replicas sur le nombre de nœuds.

Si votre cluster Standard exécute GKE version 1.27 ou antérieure, ajoutez le champ suivant à votre fichier manifeste:

spec:
  securityContext:
    privileged: true

Vous n'avez pas besoin d'exécuter les pods Kubernetes en mode privilégié dans GKE version 1.28 ou ultérieure. Pour en savoir plus, consultez Exécutez des conteneurs sans mode privilégié.

Si vous utilisez un autre type de machine:

  • Définissez cloud.google.com/gke-tpu-topology sur la topologie du type de machine. que vous utilisez.
  • Définissez les deux champs google.com/tpu sous resources pour qu'ils correspondent au nombre de pour le type de machine correspondant.

Configuration

Téléchargez les scripts Python du tutoriel et les fichiers manifestes YAML à l'aide des éléments suivants : commande:

git clone https://github.com/GoogleCloudPlatform/ai-on-gke.git

Accédez au répertoire single-host-inference :

cd ai-on-gke/gke-tpu-examples/single-host-inference/

Configurer l'environnement Python

Les scripts Python que vous utilisez dans ce tutoriel nécessitent Python 3.9 ou une version ultérieure. N'oubliez pas d'installer requirements.txt pour chaque tutoriel avant d'exécuter la scripts de test Python.

Si vous n'avez pas la configuration Python appropriée dans votre environnement local, vous pouvez utilisez Cloud Shell pour télécharger et exécuter la dans ce tutoriel.

Configurer le cluster

  1. Créez un cluster en utilisant le type de machine e2-standard-4.

    gcloud container clusters create cluster-name \
--region your-region \
--release-channel rapid \
--num-nodes=1 \
--machine-type=e2-standard-4 \
--workload-pool=project-id.svc.id.goog \
--addons GcsFuseCsiDriver

  2. Créez le pool de nœuds TPU à hôte unique.

Les exemples de charges de travail supposent ce qui suit:

  • Votre cluster s'exécute avec un pool de nœuds TPU v5e comportant trois nœuds.
  • Le pool de nœuds TPU utilise le type de machine ct5lp-hightpu-1t.

Si vous utilisez une configuration de cluster différente de celle décrite précédemment, Modifiez le fichier manifeste de déploiement du serveur.

Pour la démonstration JAX Stable Diffusion, vous aurez besoin d'un pool de nœuds de processeur avec un type de machine disposant de plus de 16 Go de mémoire disponible (par exemple, e2-standard-4) Vous pouvez configurer cela dans la commande gcloud container clusters create ou par en ajoutant un pool de nœuds au cluster existant avec le code suivant : commande:

gcloud beta container node-pools create your-pool-name \
  --zone=your-cluster-zone \
  --cluster=your-cluster-name \
  --machine-type=e2-standard-4 \
  --num-nodes=1

Remplacez les éléments suivants :

  • your-pool-name : nom du pool de nœuds à créer
  • your-cluster-zone: zone dans laquelle votre cluster a été créé.
  • your-cluster-name: nom du cluster dans lequel ajouter le pool de nœuds.
  • your-machine-type: type de machine à créer dans votre pool de nœuds.

Configurer le stockage de modèle

Il existe plusieurs façons de stocker votre modèle en vue de son inférence. Dans ce tutoriel, nous utiliserons l'approche suivante:

  • Pour convertir le modèle pré-entraîné afin qu'il fonctionne sur des TPU, nous allons utiliser un Cloud privé virtuel reposant sur un disque persistant avec un accès ReadWriteMany (RWX).
  • Pour diffuser le modèle sur plusieurs TPU à un seul hôte, nous utiliserons le même VPC reposant sur le bucket Cloud Storage.

Exécutez la commande suivante pour créer un bucket Cloud Storage.

gcloud storage buckets create gs://your-bucket-name \
  --project=your-bucket-project-id \
  --location=your-bucket-location

Remplacez les éléments suivants :

  • your-bucket-name: nom du bucket Cloud Storage.
  • your-bucket-project-id: ID du projet dans lequel vous avez créé le bucket Cloud Storage bucket.
  • your-bucket-location: emplacement de votre bucket Cloud Storage. Pour améliorer les performances, spécifiez l'emplacement où votre cluster GKE est en cours d'exécution.

Suivez les étapes ci-dessous pour autoriser votre cluster GKE à accéder à dans le bucket. Pour simplifier la configuration, les exemples suivants utilisent la valeur par défaut et le compte de service Kubernetes par défaut. Pour en savoir plus, consultez Configurez l'accès aux buckets Cloud Storage à l'aide de la fédération d'identité de charge de travail GKE pour GKE.

  1. Créez un compte de service IAM pour votre application ou utilisez un compte de service IAM existant. Vous pouvez utiliser Compte de service IAM dans le projet de votre bucket Cloud Storage.

    gcloud iam service-accounts create your-iam-service-acct \
--project=your-bucket-project-id

    Remplacez les éléments suivants :

    • your-iam-service-acct: nom du nouveau service IAM Google Cloud.
    • your-bucket-project-id: ID du projet dans lequel vous avez créé votre Cloud IAM. Le compte de service IAM doit se trouver dans le même projet que votre bucket Cloud Storage.

  2. Assurez-vous que votre compte de service IAM dispose des rôles de stockage que vous besoin.

    gcloud storage buckets add-iam-policy-binding gs://your-bucket-name \
--member "serviceAccount:your-iam-service-acct@your-bucket-project-id.iam.gserviceaccount.com" \
--role "roles/storage.objectAdmin"

    Remplacez les éléments suivants :

    • your-bucket-name : nom du bucket Cloud Storage.
    • your-iam-service-acct: nom du nouveau service IAM Google Cloud.
    • your-bucket-project-id: ID du projet dans lequel vous avez créé votre Cloud IAM.

  3. Autoriser le compte de service Kubernetes à emprunter l'identité de l'IAM compte de service en ajoutant une liaison de stratégie IAM entre deux comptes de service. Cette liaison permet au compte de service Kubernetes agir en tant que compte de service IAM.

    gcloud iam service-accounts add-iam-policy-binding your-iam-service-acct@your-bucket-project-id.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:your-project-id.svc.id.goog[default/default]"

    Remplacez les éléments suivants :

    • your-iam-service-acct: nom du nouveau service IAM Google Cloud.
    • your-bucket-project-id: ID du projet dans lequel vous avez créé votre Cloud IAM.
    • your-project-id: ID du projet dans lequel vous avez créé votre cluster GKE. Vos buckets Cloud Storage et Le cluster GKE peut se trouver dans le même projet ou dans des projets différents.

  4. Annotez le compte de service Kubernetes avec l'adresse e-mail du compte de service IAM.

    kubectl annotate serviceaccount default \
  --namespace default \
  iam.gke.io/gcp-service-account=your-iam-service-acct@your-bucket-project-id.iam.gserviceaccount.com

    Remplacez les éléments suivants :

    • your-iam-service-acct: nom du nouveau service IAM Google Cloud.
    • your-bucket-project-id: ID du projet dans lequel vous avez créé votre Cloud IAM.

  5. Exécutez la commande suivante pour renseigner le nom de votre bucket dans les fichiers YAML de cette démonstration:

    find . -type f -name "*.yaml" | xargs sed -i "s/BUCKET_NAME/your-bucket-name/g"

    Remplacez your-bucket-name par le nom de votre bucket Cloud Storage.

  6. Créez la demande de volume persistant et de volume persistant avec les éléments suivants : commande:

    kubectl apply -f pvc-pv.yaml

Inférence et inférence de modèle JAX

Installez des dépendances Python pour exécuter des scripts Python du tutoriel qui envoient de requêtes envoyées au service de modèle JAX.

pip install -r jax/requirements.txt

Exécutez la démonstration de l'inférence JAX BERT E2E:

Cette démonstration utilise un modèle BERT pré-entraîné de Hugging Face.

Le pod Kubernetes effectue les étapes suivantes:

  1. Télécharge et utilise le script Python export_bert_model.py de l'exemple pour télécharger le modèle BERT pré-entraîné dans un répertoire temporaire.
  2. Elle utilise l'image du convertisseur Cloud TPU pour convertir le modèle pré-entraîné CPU à TPU et stocke le modèle dans le bucket Cloud Storage que vous créés lors de la configuration.

Ce pod Kubernetes est configuré pour s'exécuter sur le processeur de pool de nœuds par défaut. Exécutez la en exécutant la commande suivante:

kubectl apply -f jax/bert/install-bert.yaml

Vérifiez que le modèle a été correctement installé à l'aide des éléments suivants:

kubectl get pods install-bert

STATUS peut mettre quelques minutes à lire Completed.

Lancer le serveur de modèles TF pour le modèle

Les exemples de charges de travail présentés dans ce tutoriel supposent ce qui suit:

  • Le cluster est exécuté avec un pool de nœuds TPU v5 comportant trois nœuds
  • Le pool de nœuds utilise le type de machine ct5lp-hightpu-1t qui contient un puce TPU.

Si vous utilisez une configuration de cluster différente de celle décrite précédemment, Modifiez le fichier manifeste de déploiement du serveur.

Appliquer le déploiement
kubectl apply -f jax/bert/serve-bert.yaml

Vérifiez que le serveur est en cours d'exécution à l'aide de la commande suivante:

kubectl get deployment bert-deployment

AVAILABLE peut mettre une minute à lire 3.

Appliquer le service d'équilibrage de charge
kubectl apply -f jax/bert/loadbalancer.yaml

Pour vérifier que l'équilibreur de charge est prêt pour le trafic externe, procédez comme suit:

kubectl get svc tf-bert-service

Il peut s'écouler quelques minutes avant que EXTERNAL_IP ne dispose d'une adresse IP.

Envoyer la requête au serveur de modèles

Obtenez une adresse IP externe à partir du service d'équilibrage de charge:

EXTERNAL_IP=$(kubectl get services tf-bert-service --output jsonpath='{.status.loadBalancer.ingress[0].ip}')

Exécutez un script permettant d'envoyer une requête au serveur:

python3 jax/bert/bert_request.py $EXTERNAL_IP

Résultat attendu :

For input "The capital of France is [MASK].", the result is ". the capital of france is paris.."
For input "Hello my name [MASK] Jhon, how can I [MASK] you?", the result is ". hello my name is jhon, how can i help you?."
Effectuer un nettoyage

Pour nettoyer les ressources, exécutez kubectl delete dans l'ordre inverse.

kubectl delete -f jax/bert/loadbalancer.yaml
kubectl delete -f jax/bert/serve-bert.yaml
kubectl delete -f jax/bert/install-bert.yaml

Lancer une démonstration de diffusion E2E Stable Diffusion JAX

Cette démonstration utilise le modèle de diffusion stable pré-entraîné de Hugging Face.

Exporter un modèle enregistré TF2 compatible TPU à partir du modèle Flax Stable Diffusion

L'exportation des modèles de diffusion stables nécessite que le cluster dispose d'un nœud de processeur avec un type de machine disposant de plus de 16 Go de mémoire disponible, comme décrit dans Configurer le cluster

Le pod Kubernetes exécute les étapes suivantes:

  1. Télécharge et utilise le script Python export_stable_diffusion_model.py à partir de les exemples de ressources pour télécharger le modèle de diffusion stable pré-entraîné un répertoire temporaire.
  2. Elle utilise l'image du convertisseur Cloud TPU pour convertir le modèle pré-entraîné CPU vers TPU et stocke le modèle dans le bucket Cloud Storage que vous avez créé pendant la configuration du stockage.

Ce pod Kubernetes est configuré pour s'exécuter sur le pool de nœuds CPU par défaut. Exécutez la en exécutant la commande suivante:

kubectl apply -f jax/stable-diffusion/install-stable-diffusion.yaml

Vérifiez que le modèle a été correctement installé à l'aide des éléments suivants:

kubectl get pods install-stable-diffusion

STATUS peut mettre quelques minutes à lire Completed.

Lancer le conteneur du serveur de modèles TF pour le modèle

Les exemples de charges de travail ont été configurés avec les hypothèses suivantes:

  • Le cluster s'exécute avec un pool de nœuds TPU v5 comportant trois nœuds
  • le pool de nœuds utilise le type de machine ct5lp-hightpu-1t, où:
    • est de type 1 x 1
    • le nombre de puces TPU est de 1

Si vous utilisez une configuration de cluster différente de celle décrite précédemment, Modifiez le fichier manifeste de déploiement du serveur.

Appliquez le déploiement:

kubectl apply -f jax/stable-diffusion/serve-stable-diffusion.yaml

Vérifiez que le serveur fonctionne comme prévu:

kubectl get deployment stable-diffusion-deployment

AVAILABLE peut mettre une minute à lire 3.

Appliquez le service d'équilibrage de charge:

kubectl apply -f jax/stable-diffusion/loadbalancer.yaml

Pour vérifier que l'équilibreur de charge est prêt pour le trafic externe, procédez comme suit:

kubectl get svc tf-stable-diffusion-service

Il peut s'écouler quelques minutes avant que EXTERNAL_IP ne dispose d'une adresse IP.

Envoyer la requête au serveur de modèles

Obtenez une adresse IP externe à partir de l'équilibreur de charge:

EXTERNAL_IP=$(kubectl get services tf-stable-diffusion-service --output jsonpath='{.status.loadBalancer.ingress[0].ip}')

Exécuter un script pour envoyer une requête au serveur

python3 jax/stable-diffusion/stable_diffusion_request.py $EXTERNAL_IP

Résultat attendu :

La requête est Painting of a squirrel skating in New York et l'image de sortie sera enregistré sous le nom stable_diffusion_images.jpg dans votre répertoire actuel.

Effectuer un nettoyage

Pour nettoyer les ressources, exécutez kubectl delete dans l'ordre inverse.

kubectl delete -f jax/stable-diffusion/loadbalancer.yaml
kubectl delete -f jax/stable-diffusion/serve-stable-diffusion.yaml
kubectl delete -f jax/stable-diffusion/install-stable-diffusion.yaml

Exécutez la démonstration de l'inférence TensorFlow ResNet-50 E2E:

Installez des dépendances Python pour exécuter des scripts Python du tutoriel qui envoient au service de modèle TF.

pip install -r tf/resnet50/requirements.txt
Étape 1: Convertissez le modèle

Appliquez la conversion du modèle:

kubectl apply -f tf/resnet50/model-conversion.yml

Vérifiez que le modèle a été correctement installé à l'aide des éléments suivants:

kubectl get pods resnet-model-conversion

STATUS peut mettre quelques minutes à lire Completed.

Étape 2: Inférer le modèle avec TensorFlow Serving

Appliquez le déploiement d'inférence du modèle:

kubectl apply -f tf/resnet50/deployment.yml

Vérifiez que le serveur fonctionne comme prévu à l'aide de la commande suivante:

kubectl get deployment resnet-deployment

AVAILABLE peut mettre une minute à lire 3.

Appliquez le service d'équilibrage de charge:

kubectl apply -f tf/resnet50/loadbalancer.yml

Pour vérifier que l'équilibreur de charge est prêt pour le trafic externe, procédez comme suit:

kubectl get svc resnet-service

Il peut s'écouler quelques minutes avant que EXTERNAL_IP ne dispose d'une adresse IP.

Étape 3: Envoyer une requête de test au serveur de modèles

Obtenez l'adresse IP externe de l'équilibreur de charge:

EXTERNAL_IP=$(kubectl get services resnet-service --output jsonpath='{.status.loadBalancer.ingress[0].ip}')

Exécutez le script de requête de test (HTTP) pour envoyer la requête au serveur de modèle.

python3 tf/resnet50/request.py --host $EXTERNAL_IP

La réponse doit se présenter sous la forme suivante:

Predict result: ['ImageNet ID: n07753592, Label: banana, Confidence: 0.94921875',
'ImageNet ID: n03532672, Label: hook, Confidence: 0.0223388672', 'ImageNet ID: n07749582,
Label: lemon, Confidence: 0.00512695312
Étape 4: Effectuez un nettoyage

Pour nettoyer les ressources, exécutez les commandes kubectl delete suivantes:

kubectl delete -f tf/resnet50/loadbalancer.yml
kubectl delete -f tf/resnet50/deployment.yml
kubectl delete -f tf/resnet50/model-conversion.yml

Veillez à supprimer le pool de nœuds GKE. et cluster lorsque vous n'en avez plus besoin.

Inférence et inférence de modèles PyTorch

Installez des dépendances Python pour exécuter des scripts Python du tutoriel qui envoient au service de modèle PyTorch:

pip install -r pt/densenet161/requirements.txt

Exécutez la démonstration de l'inférence TorchServe Densenet161 E2E:

  1. Générer une archive de modèle

    1. Appliquer l'archive du modèle:
    kubectl apply -f pt/densenet161/model-archive.yml
    1. Vérifiez que le modèle a été correctement installé à l'aide des éléments suivants:
    kubectl get pods densenet161-model-archive

    STATUS peut mettre quelques minutes à lire Completed.

  2. Diffuser le modèle avec TorchServe:

    1. Appliquez le déploiement du modèle d'inférence:

      kubectl apply -f pt/densenet161/deployment.yml

    2. Vérifiez que le serveur fonctionne comme prévu à l'aide de la commande suivante:

      kubectl get deployment densenet161-deployment

      AVAILABLE peut mettre une minute à lire 3.

    3. Appliquez le service d'équilibrage de charge:

      kubectl apply -f pt/densenet161/loadbalancer.yml

      Vérifiez que l'équilibreur de charge est prêt pour le trafic externe à l'aide du la commande suivante:

      kubectl get svc densenet161-service

      Il peut s'écouler quelques minutes avant que EXTERNAL_IP ne dispose d'une adresse IP.

  3. Envoyez une requête de test au serveur de modèles:

    1. Obtenez l'adresse IP externe de l'équilibreur de charge:

      EXTERNAL_IP=$(kubectl get services densenet161-service --output jsonpath='{.status.loadBalancer.ingress[0].ip}')

    2. Exécutez le script de requête de test pour envoyer la requête (HTTP) au serveur de modèle :

      python3 pt/densenet161/request.py --host $EXTERNAL_IP

      Vous devriez obtenir une réponse semblable à celle-ci:

      Request successful. Response: {'tabby': 0.47878125309944153, 'lynx': 0.20393909513950348, 'tiger_cat': 0.16572578251361847, 'tiger': 0.061157409101724625, 'Egyptian_cat': 0.04997897148132324

  4. Nettoyez les ressources en exécutant les commandes kubectl delete suivantes:

    kubectl delete -f pt/densenet161/loadbalancer.yml
kubectl delete -f pt/densenet161/deployment.yml
kubectl delete -f pt/densenet161/model-archive.yml

    Veillez à supprimer le pool de nœuds GKE. et cluster lorsque vous vous en avez fini avec eux.

Résoudre les problèmes courants

Vous trouverez des informations sur le dépannage de GKE à l'adresse Résolvez les problèmes liés à TPU dans GKE.

Échec de l'initialisation du TPU

Si vous rencontrez l'erreur suivante, assurez-vous d'exécuter votre TPU en mode privilégié, ou si vous avez augmenté le ulimit dans votre conteneur. Pour en savoir plus, consultez la section Exécuter sans mode privilégié.

TPU platform initialization failed: FAILED_PRECONDITION: Couldn't mmap: Resource
temporarily unavailable.; Unable to create Node RegisterInterface for node 0,
config: device_path:      "/dev/accel0" mode: KERNEL debug_data_directory: ""
dump_anomalies_only: true crash_in_debug_dump: false allow_core_dump: true;
could not create driver instance

Planifier un interblocage

Supposons que vous ayez deux jobs (Job A et Job B) programmés sur un TPU tranches avec une topologie de TPU donnée (par exemple, v4-32). Supposons également que vous avez deux tranches TPU v4-32 dans le cluster GKE ; nous allons appelez ces tranches X et Y. Comme votre cluster dispose d'une capacité suffisante pour planifier les deux jobs, mais en théorie les deux doivent être programmés rapidement. Une seule tâche chacune des deux tranches de TPU v4-32.

Cependant, sans une planification minutieuse, il est possible d'établir une planification interblocage. Supposons que le programmeur Kubernetes planifie un pod Kubernetes à partir du job A sur la tranche X, puis programme un pod Kubernetes du job B sur la tranche X. Dans compte tenu des règles d'affinité de pods Kubernetes pour la tâche A, l'ordonnanceur de planifier tous les pods Kubernetes restants pour la tâche A sur la tranche X. Identique pour Job B. Par conséquent, ni la tâche A, ni la tâche B ne peuvent être entièrement planifiées sur une tranche unique. Il en résulte un interblocage de la planification.

Pour éviter tout blocage de la planification, vous pouvez utiliser anti-affinité avec cloud.google.com/gke-nodepool comme topologyKey, comme indiqué dans l'exemple suivant:

apiVersion: batch/v1
kind: Job
metadata:
 name: pi
spec:
 parallelism: 2
 template:
   metadata:
     labels:
       job: pi
   spec:
     affinity:
       podAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: job
               operator: In
               values:
               - pi
           topologyKey: cloud.google.com/gke-nodepool
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: job
               operator: NotIn
               values:
               - pi
           topologyKey: cloud.google.com/gke-nodepool
           namespaceSelector:
             matchExpressions:
             - key: kubernetes.io/metadata.name
               operator: NotIn
               values:
               - kube-system
     containers:
     - name: pi
       image: perl:5.34.0
       command: ["sleep",  "60"]
     restartPolicy: Never
 backoffLimit: 4

Créer des ressources de pool de nœuds TPU avec Terraform

Vous pouvez également utiliser Terraform. pour gérer vos ressources de cluster et de pool de nœuds.

Créer un pool de nœuds de tranches TPU multi-hôtes dans un cluster GKE existant

Si vous disposez d'un cluster existant dans lequel vous souhaitez créer un TPU multi-hôtes vous pouvez utiliser l'extrait Terraform suivant:

resource "google_container_cluster" "cluster_multi_host" {
  …
  release_channel {
    channel = "RAPID"
  }
  workload_identity_config {
    workload_pool = "my-gke-project.svc.id.goog"
  }
  addons_config {
    gcs_fuse_csi_driver_config {
      enabled = true
    }
  }
}

resource "google_container_node_pool" "multi_host_tpu" {
  provider           = google-beta
  project            = "${project-id}"
  name               = "${node-pool-name}"
  location           = "${location}"
  node_locations     = ["${node-locations}"]
  cluster            = google_container_cluster.cluster_multi_host.name
  initial_node_count = 2

  node_config {
    machine_type = "ct4p-hightpu-4t"
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = ["${reservation-name}"]
    }
    workload_metadata_config {
      mode = "GKE_METADATA"
    }
  }

  placement_policy {
    type = "COMPACT"
    tpu_topology = "2x2x2"
  }
}

Remplacez les valeurs suivantes :

  • your-project: projet Google Cloud dans lequel vous exécutez votre charge de travail.
  • your-node-pool: nom du pool de nœuds que vous créez.
  • us-central2: région dans laquelle vous exécutez votre charge de travail.
  • us-central2-b: zone dans laquelle vous exécutez votre charge de travail.
  • your-reservation-name : nom de votre réservation.

Créer un pool de nœuds de tranches TPU à hôte unique dans un cluster GKE existant

Utilisez l'extrait Terraform suivant:

resource "google_container_cluster" "cluster_single_host" {
  …
  cluster_autoscaling {
    autoscaling_profile = "OPTIMIZE_UTILIZATION"
  }
  release_channel {
    channel = "RAPID"
  }
  workload_identity_config {
  workload_pool = "${project-id}.svc.id.goog"
  }
  addons_config {
    gcs_fuse_csi_driver_config {
      enabled = true
    }
  }
}

resource "google_container_node_pool" "single_host_tpu" {
  provider           = google-beta
  project            = "${project-id}"
  name               = "${node-pool-name}"
  location           = "${location}"
  node_locations     = ["${node-locations}"]
  cluster            = google_container_cluster.cluster_single_host.name
  initial_node_count = 0
  autoscaling {
    total_min_node_count = 2
    total_max_node_count = 22
    location_policy      = "ANY"
  }

  node_config {
    machine_type = "ct4p-hightpu-4t"
    workload_metadata_config {
      mode = "GKE_METADATA"
    }
  }
}

Remplacez les valeurs suivantes :

  • your-project: projet Google Cloud dans lequel vous exécutez votre charge de travail.
  • your-node-pool: nom du pool de nœuds que vous créez.
  • us-central2: région dans laquelle vous exécutez votre charge de travail.
  • us-central2-b: zone dans laquelle vous exécutez votre charge de travail.