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

Diffuser un LLM à l'aide de TPU Trillium sur GKE avec vLLM

Standard Autopilot

Ce tutoriel explique comment diffuser des grands modèles de langage (LLM) à l'aide des TPU (Tensor Processing Units) sur Google Kubernetes Engine (GKE) avec le framework de diffusion vLLM. Dans ce tutoriel, vous allez diffuser Llama 3.1 70b, utiliser TPU Trillium et configurer l'autoscaling horizontal des pods à l'aide de métriques de serveur vLLM.

Ce document est un bon point de départ si vous avez besoin du contrôle précis, de l'évolutivité, de la résilience, de la portabilité et de la rentabilité des services Kubernetes gérés lors du déploiement et de la diffusion de vos charges de travail d'IA/de ML.

Contexte

En utilisant TPU Trillium sur GKE, vous pouvez mettre en œuvre une solution de diffusion robuste et prête pour la production avec tous les avantages de Kubernetes géré, y compris une évolutivité efficace et une meilleure disponibilité. Cette section décrit les principales technologies utilisées dans ce guide.

TPU Trillium

Les TPU sont des circuits intégrés propres à une application (ASIC) développés par Google. Les TPU permettent d'accélérer le machine learning et les modèles d'IA créés à l'aide de frameworks tels que TensorFlow, PyTorch et JAX. Ce tutoriel utilise TPU Trillium, le TPU de sixième génération de Google.

Avant d'utiliser des TPU dans GKE, nous vous recommandons de suivre le parcours de formation suivant :

Découvrez l'architecture système des TPU Trillium.
Apprenez-en plus sur les TPU dans GKE.

vLLM

vLLM est un framework Open Source hautement optimisé pour la diffusion de LLM. vLLM peut augmenter le débit de diffusion sur les GPU, avec des fonctionnalités telles que:

Implémentation optimisée du transformateur avec PagedAttention.
Traitement par lots continu pour améliorer le débit global de diffusion
Parallélisme des Tensors et diffusion distribuée sur plusieurs TPU

Pour en savoir plus, consultez la documentation de vLLM.

Cloud Storage FUSE

Cloud Storage FUSE permet à votre cluster GKE d'accéder à Cloud Storage pour les poids de modèle qui se trouvent dans des buckets de stockage d'objets. Dans ce tutoriel, le bucket Cloud Storage créé sera initialement vide. Lorsque vLLM démarre, GKE télécharge le modèle à partir de Hugging Face et met en cache les poids dans le bucket Cloud Storage. Lors du redémarrage du pod ou de l'augmentation de l'échelle de déploiement, les chargements de modèles ultérieurs téléchargeront les données mises en cache à partir du bucket Cloud Storage, en exploitant les téléchargements parallèles pour des performances optimales.

Pour en savoir plus, consultez la documentation du pilote CSI Cloud Storage FUSE.

Objectifs

Ce tutoriel est destiné aux ingénieurs MLOps ou DevOps ou aux administrateurs de plate-forme qui souhaitent utiliser les fonctionnalités d'orchestration GKE pour obtenir des inférences à partir d'un LLM.

Ce tutoriel couvre les étapes suivantes :

Créez un cluster GKE avec la topologie TPU Trillium recommandée en fonction des caractéristiques du modèle.
Déployez le framework vLLM sur un pool de nœuds de votre cluster.
Utilisez le framework vLLM pour diffuser Llama 3.1 70b à l'aide d'un équilibreur de charge.
Configurez l'autoscaling horizontal des pods à l'aide des métriques de serveur vLLM.
Diffuser le modèle

Avant de commencer

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the required API.

Enable the API

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the required API.

Enable the API

Make sure that you have the following role or roles on the project: roles/container.admin, roles/iam.serviceAccountAdmin, roles/iam.securityAdmin, roles/artifactregistry.writer, roles/container.clusterAdmin
Check for the roles
1. In the Google Cloud console, go to the IAM page.
  Go to IAM
2. Select the project.
3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.
4. For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.
Grant the roles
1. In the Google Cloud console, go to the IAM page.
  Accéder à IAM
2. Sélectionnez le projet.
3. Cliquez sur Accorder l'accès.
4. Dans le champ Nouveaux comptes principaux, saisissez votre identifiant utilisateur. Il s'agit généralement de l'adresse e-mail d'un compte Google.
5. Dans la liste Sélectionner un rôle, sélectionnez un rôle.
6. Pour attribuer des rôles supplémentaires, cliquez sur Ajouter un autre rôle et ajoutez chaque rôle supplémentaire.
7. Cliquez sur Enregistrer.

Créez un compte Hugging Face si vous n'en possédez pas.
Assurez-vous que votre projet dispose d'un quota suffisant pour Cloud TPU dans GKE.

Préparer l'environnement

Dans cette section, vous provisionnez les ressources dont vous avez besoin pour déployer vLLM et le modèle.

Accéder au modèle

Vous devez signer le contrat de consentement pour utiliser Llama 3.1 70b dans le dépôt Hugging Face.

Générer un jeton d'accès

Si vous n'en possédez pas déjà un, générez un nouveau jeton Hugging Face:

Cliquez sur Your Profile > Settings > Access Tokens (Votre profil > Paramètres > Jetons d'accès).
Sélectionnez New Token (Nouveau jeton).
Spécifiez le nom de votre choix et un rôle d'au moins Read.
Sélectionnez Générer un jeton.

Lancer Cloud Shell

Dans ce tutoriel, vous utilisez Cloud Shell pour gérer les ressources hébergées surGoogle Cloud. Cloud Shell est préinstallé avec les logiciels dont vous avez besoin pour ce tutoriel, y compris kubectl et la gcloud CLI.

Pour configurer votre environnement avec Cloud Shell, procédez comme suit :

Dans la console Google Cloud, lancez une session Cloud Shell en cliquant sur Activer Cloud Shell dans la console Google Cloud. Une session s'ouvre dans le volet inférieur de la console Google Cloud.
Définissez les variables d'environnement par défaut :
```
gcloud config set project PROJECT_ID && \
export PROJECT_ID=$(gcloud config get project) && \
export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)") && \
export CLUSTER_NAME=CLUSTER_NAME && \
export ZONE=ZONE && \
export HF_TOKEN=HUGGING_FACE_TOKEN && \
export CLUSTER_VERSION=CLUSTER_VERSION && \
export GSBUCKET=GSBUCKET && \
export KSA_NAME=KSA_NAME && \
export NAMESPACE=NAMESPACE \
export IMAGE_NAME=IMAGE_NAME
```
Remplacez les valeurs suivantes :
- PROJECT_ID: votre Google Cloud ID de projet.
- CLUSTER_NAME : nom de votre cluster GKE.
- ZONE: zone compatible avec TPU Trillium (v6e).
- CLUSTER_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. TPU Trillium est compatible avec les versions GKE 1.31.2-gke.1115000 et ultérieures.
- GSBUCKET: nom du bucket Cloud Storage à utiliser pour Cloud Storage FUSE.
- KSA_NAME: nom du compte de service Kubernetes utilisé pour accéder aux buckets Cloud Storage. L'accès au bucket est nécessaire pour que Cloud Storage FUSE fonctionne.
- NAMESPACE: espace de noms Kubernetes dans lequel vous souhaitez déployer les composants vLLM.
- IMAGE_NAME: image du TPU vLLM. Vous pouvez utiliser l'image publique docker.io/vllm/vllm-tpu:2e33fe419186c65a18da6668972d61d7bbc31564 ou créer la vôtre.

Créer un cluster GKE

Vous pouvez diffuser des LLM sur des TPU dans un cluster GKE Autopilot ou GKE Standard. Nous vous recommandons d'utiliser un cluster GKE Autopilot pour une expérience Kubernetes entièrement gérée. Pour choisir le mode de fonctionnement GKE le mieux adapté à vos charges de travail, consultez la section Choisir un mode de fonctionnement GKE.

Autopilot

Créez un cluster GKE Autopilot :
```
gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION
```
Remplacez PROJECT_ID par votre Google Cloud ID de projet.

Remarque : Si votre instance Cloud Shell se déconnecte tout au long de l'exécution du tutoriel, répétez l'étape précédente.

Standard

Créez un cluster GKE standard:

gcloud container clusters create CLUSTER_NAME \
    --project=PROJECT_ID \
    --zone=ZONE \
    --cluster-version=CLUSTER_VERSION \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --addons GcsFuseCsiDriver

Créez un pool de nœuds de tranche TPU:
```
gcloud container node-pools create tpunodepool \
    --zone=ZONE \
    --num-nodes=1 \
    --machine-type=ct6e-standard-8t \
    --cluster=CLUSTER_NAME \
    --enable-autoscaling --total-min-nodes=1 --total-max-nodes=2
```
GKE crée les ressources suivantes pour le LLM :
- Un cluster GKE Standard qui utilise la fédération d'identité de charge de travail pour GKE et dont le pilote CSI Cloud Storage FUSE est activé.
- Un pool de nœuds TPU Trillium avec un type de machine ct6e-standard-8t. Ce pool de nœuds comporte un nœud, huit puces TPU et l'autoscaling est activé.

Configurer kubectl pour communiquer avec votre cluster

Pour configurer kubectl de manière à communiquer avec votre cluster, exécutez la commande suivante:

  gcloud container clusters get-credentials CLUSTER_NAME --location=ZONE

Créer un secret Kubernetes pour les identifiants Hugging Face

Créez un espace de noms. Vous pouvez ignorer cette étape si vous utilisez l'espace de noms default:
```
kubectl create namespace NAMESPACE
```

Créez un secret Kubernetes contenant le jeton Hugging Face, puis exécutez la commande suivante:

kubectl create secret generic hf-secret \
    --from-literal=hf_api_token=HUGGING_FACE_TOKEN \
    --namespace NAMESPACE

Créer un bucket Cloud Storage

Dans Cloud Shell, exécutez la commande suivante :

gcloud storage buckets create gs://GSBUCKET \
    --uniform-bucket-level-access

Cette opération crée un bucket Cloud Storage pour stocker les fichiers de modèle que vous téléchargez depuis Hugging Face.

Configurer un compte de service Kubernetes pour accéder au bucket

Créez le compte de service Kubernetes:

kubectl create serviceaccount KSA_NAME --namespace NAMESPACE

Accordez un accès en lecture/écriture au compte de service Kubernetes pour accéder au bucket Cloud Storage:

gcloud storage buckets add-iam-policy-binding gs://GSBUCKET \
  --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \
  --role "roles/storage.objectUser"

Vous pouvez également accorder un accès en lecture/écriture à tous les buckets Cloud Storage du projet:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \
--role "roles/storage.objectUser"
```
GKE crée les ressources suivantes pour le LLM :
1. Un bucket Cloud Storage pour stocker le modèle téléchargé et le cache de compilation. Un pilote CSI Cloud Storage FUSE lit le contenu du bucket.
2. Volumes avec la mise en cache des fichiers activée et la fonctionnalité de téléchargement parallèle de Cloud Storage FUSE.
Bonne pratique :
Utilisez un cache de fichiers basé sur tmpfs ou Hyperdisk / Persistent Disk en fonction de la taille attendue du contenu du modèle, par exemple les fichiers de poids. Dans ce tutoriel, vous allez utiliser le cache de fichiers Cloud Storage FUSE basé sur la RAM.

(Facultatif) Créer et déployer l'image TPU

Si vous avez besoin d'un contrôle plus précis sur le contenu de votre image Docker, choisissez cette option.

Conteneurisez votre serveur vLLM:

Clonez le dépôt vLLM et créez l'image:

git clone https://github.com/vllm-project/vllm && cd vllm && git reset --hard 2e33fe419186c65a18da6668972d61d7bbc31564 && docker build -f Dockerfile.tpu . -t vllm-tpu

Transférez l'image vers Artifact Registry :

gcloud artifacts repositories create vllm-tpu --repository-format=docker --location=REGION_NAME && \
gcloud auth configure-docker REGION_NAME-docker.pkg.dev && \
docker image tag vllm-tpu REGION_NAME-docker.pkg.dev/PROJECT_ID/vllm-tpu/vllm-tpu:latest && \
docker push REGION_NAME-docker.pkg.dev/PROJECT_ID/vllm-tpu/vllm-tpu:latest

Déployer le serveur de modèles vLLM

Pour déployer le serveur de modèle vLLM, ce tutoriel utilise un déploiement Kubernetes. Un déploiement est un objet d'API Kubernetes qui vous permet d'exécuter plusieurs réplicas de pods répartis entre les nœuds d'un cluster.

Examinez le fichier manifeste de déploiement enregistré sous le nom vllm-llama3-70b.yaml:


apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-tpu
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm-tpu
  template:
    metadata:
      labels:
        app: vllm-tpu
      annotations:
        gke-gcsfuse/volumes: "true"
        gke-gcsfuse/cpu-limit: "0"
        gke-gcsfuse/memory-limit: "0"
        gke-gcsfuse/ephemeral-storage-limit: "0"
    spec:
      serviceAccountName: KSA_NAME
      nodeSelector:
        cloud.google.com/gke-tpu-topology: 2x4
        cloud.google.com/gke-tpu-accelerator: tpu-v6e-slice
      containers:
      - name: vllm-tpu
        image: IMAGE_NAME
        command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]
        args:
        - --host=0.0.0.0
        - --port=8000
        - --tensor-parallel-size=8
        - --max-model-len=8192
        - --model=meta-llama/Meta-Llama-3.1-70B
        - --download-dir=/data
        env: 
        - name: HUGGING_FACE_HUB_TOKEN
          valueFrom:
            secretKeyRef:
              name: hf-secret
              key: hf_api_token
        - name: VLLM_XLA_CACHE_PATH
          value: "/data"
        ports:
        - containerPort: 8000
        resources:
          limits:
            google.com/tpu: 8
        readinessProbe:
          tcpSocket:
            port: 8000
          initialDelaySeconds: 15
          periodSeconds: 10
        volumeMounts:
        - name: gcs-fuse-csi-ephemeral
          mountPath: /data
        - name: dshm
          mountPath: /dev/shm
      volumes:
      - name: gke-gcsfuse-cache
        emptyDir:
          medium: Memory
      - name: dshm
        emptyDir:
          medium: Memory
      - name: gcs-fuse-csi-ephemeral
        csi:
          driver: gcsfuse.csi.storage.gke.io
          volumeAttributes:
            bucketName: GSBUCKET
            mountOptions: "implicit-dirs,file-cache:enable-parallel-downloads:true,file-cache:parallel-downloads-per-file:100,file-cache:max-parallel-downloads:-1,file-cache:download-chunk-size-mb:10,file-cache:max-size-mb:-1"
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm-tpu
  type: LoadBalancer	
  ports:
    - name: http
      protocol: TCP
      port: 8000  
      targetPort: 8000

Appliquez le fichier manifeste en exécutant la commande suivante:
```
kubectl apply -f vllm-llama3-70b.yaml -n NAMESPACE
```

Affichez les journaux du serveur de modèles en cours d'exécution:

kubectl logs -f -l app=vllm-tpu -n NAMESPACE

Le résultat doit ressembler à ce qui suit :

INFO:     Started server process [1]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)

Diffuser le modèle

Exécutez la commande suivante pour obtenir l'adresse IP externe du service:

export vllm_service=$(kubectl get service vllm-service -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

Dans un nouveau terminal, interagissez avec le modèle à l'aide de curl:

curl http://$vllm_service:8000/v1/completions \
-H "Content-Type: application/json" \
-d '{
    "model": "meta-llama/Meta-Llama-3.1-70B",
    "prompt": "San Francisco is a",
    "max_tokens": 7,
    "temperature": 0
}'

La sortie devrait ressembler à ce qui suit :

{"id":"cmpl-6b4bb29482494ab88408d537da1e608f","object":"text_completion","created":1727822657,"model":"meta-llama/Meta-Llama-3-8B","choices":[{"index":0,"text":" top holiday destination featuring scenic beauty and","logprobs":null,"finish_reason":"length","stop_reason":null,"prompt_logprobs":null}],"usage":{"prompt_tokens":5,"total_tokens":12,"completion_tokens":7}}

Configurer l'autoscaler personnalisé

Dans cette section, vous allez configurer l'autoscaling horizontal des pods à l'aide de métriques Prometheus personnalisées. Vous utilisez les métriques Google Cloud Managed Service pour Prometheus à partir du serveur vLLM.

Pour en savoir plus, consultez la section Google Cloud Managed Service pour Prometheus. Cette option doit être activée par défaut sur le cluster GKE.

Configurez l'adaptateur de métriques personnalisées Stackdriver sur votre cluster:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml

Ajoutez le rôle "Lecteur de surveillance" au compte de service utilisé par l'adaptateur de métriques personnalisées Stackdriver:
```
gcloud projects add-iam-policy-binding projects/PROJECT_ID \
    --role roles/monitoring.viewer \
    --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/custom-metrics/sa/custom-metrics-stackdriver-adapter
```
Remarque :Assurez-vous que le compte de service utilisé par votre cluster GKE dispose du rôle Rédacteur de métriques Monitoring. Ce tutoriel utilise le compte de service Compute Engine par défaut.

Enregistrez le manifeste suivant sous le nom vllm_pod_monitor.yaml :


apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
 name: vllm-pod-monitoring
spec:
 selector:
   matchLabels:
     app: vllm-tpu
 endpoints:
 - path: /metrics
   port: 8000
   interval: 15s

Appliquez-le au cluster:
```
kubectl apply -f vllm_pod_monitor.yaml
```

Créer une charge sur le point de terminaison vLLM

Créez une charge sur le serveur vLLM pour tester l'autoscaling automatique de GKE avec une métrique vLLM personnalisée.

Exécutez un script bash (load.sh) pour envoyer un nombre N de requêtes parallèles au point de terminaison vLLM:

#!/bin/bash
N=PARALLEL_PROCESSES
export vllm_service=$(kubectl get service vllm-service -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
for i in $(seq 1 $N); do
  while true; do
    curl http://$vllm_service:8000/v1/completions -H "Content-Type: application/json" -d '{"model": "meta-llama/Meta-Llama-3.1-70B", "prompt": "Write a story about san francisco", "max_tokens": 100, "temperature": 0}'
  done &  # Run in the background
done
wait

Remplacez PARALLEL_PROCESSES par le nombre de processus parallèles que vous souhaitez exécuter.

Exécutez le script bash:
```
nohup ./load.sh &
```

Vérifier que Google Cloud Managed Service pour Prometheus ingère les métriques

Une fois que Google Cloud Managed Service pour Prometheus a extrait les métriques et que vous ajoutez de la charge au point de terminaison vLLM, vous pouvez afficher les métriques dans Cloud Monitoring.

Dans la console Google Cloud, accédez à la page Explorateur de métriques.

Accéder à l'explorateur de métriques
Cliquez sur < > PromQL.

Saisissez la requête suivante pour observer les métriques de trafic:

vllm:avg_generation_throughput_toks_per_s{cluster='CLUSTER_NAME_HERE'}

Dans le graphique linéaire, la métrique vLLM passe de 0 (préchargement) à une valeur (postchargement). Ce graphique confirme que vos métriques vLLM sont ingérées dans Google Cloud Managed Service pour Prometheus.

L'image suivante est un exemple de graphique après l'exécution du script de chargement. Dans ce cas, le serveur de modèle diffuse environ 2 000 jetons de génération par seconde.

test

Déployer la configuration de l'autoscaler horizontal des pods

Pour choisir la métrique sur laquelle effectuer l'autoscaling, nous vous recommandons les métriques suivantes pour les TPU vLLM:

num_requests_waiting: cette métrique concerne le nombre de requêtes en attente dans la file d'attente du serveur de modèle. Ce nombre commence à augmenter de manière notable lorsque le cache kv est plein.
gpu_cache_usage_perc: cette métrique concerne l'utilisation du cache kv, qui est directement corrélée au nombre de requêtes traitées pour un cycle d'inférence donné sur le serveur de modèle. Notez que cette métrique fonctionne de la même manière sur les GPU et les TPU, bien qu'elle soit liée au schéma de dénomination des GPU.

Nous vous recommandons d'utiliser num_requests_waiting lorsque vous optimisez le débit et les coûts, et lorsque vos objectifs de latence sont réalisables avec le débit maximal de votre serveur de modèles.

Nous vous recommandons d'utiliser gpu_cache_usage_perc si vous avez des charges de travail sensibles à la latence où le scaling basé sur la file d'attente n'est pas assez rapide pour répondre à vos besoins.

Pour en savoir plus, consultez Bonnes pratiques pour l'autoscaling des charges de travail d'inférence de grands modèles de langage (LLM) avec des TPU.

Lorsque vous sélectionnez une cible averageValue pour votre configuration HPA, vous devez le déterminer de manière expérimentale. Consultez l'article de blog Économiser sur les GPU: autoscaling plus intelligent pour vos charges de travail d'inférence GKE pour obtenir d'autres idées sur l'optimisation de cette partie. Le profile-generator utilisé dans cet article de blog fonctionne également pour le TPU vLLM.

Pour déployer la configuration de l'autoscaler horizontal de pods à l'aide de num_requests_waiting, procédez comme suit:

Enregistrez le manifeste suivant sous le nom vllm-hpa.yaml :


apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
 name: vllm-hpa
spec:
 scaleTargetRef:
   apiVersion: apps/v1
   kind: Deployment
   name: vllm-tpu
 minReplicas: 1
 maxReplicas: 2
 metrics:
   - type: Pods
     pods:
       metric:
         name: prometheus.googleapis.com|vllm:num_requests_waiting|gauge
       target:
         type: AverageValue
         averageValue: 10

Les métriques vLLM de Google Cloud Managed Service pour Prometheus suivent le format vllm:metric_name.

Bonne pratique:

Utilisez num_requests_waiting pour faire évoluer le débit. Utilisez gpu_cache_usage_perc pour les cas d'utilisation des TPU sensibles à la latence.

Déployez la configuration de l'autoscaler horizontal des pods:
```
kubectl apply -f vllm-hpa.yaml
```
GKE planifie le déploiement d'un autre pod, ce qui déclenche l'autoscaler du pool de nœuds pour ajouter un deuxième nœud avant de déployer le deuxième réplica vLLM.

Suivez la progression de l'autoscaling du pod:

kubectl get hpa --watch

Le résultat ressemble à ce qui suit :

NAME       REFERENCE             TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
vllm-hpa   Deployment/vllm-tpu   <unknown>/5   1         2         0          6s
vllm-hpa   Deployment/vllm-tpu   34972m/5      1         2         1          16s
vllm-hpa   Deployment/vllm-tpu   25112m/5      1         2         2          31s
vllm-hpa   Deployment/vllm-tpu   35301m/5      1         2         2          46s
vllm-hpa   Deployment/vllm-tpu   25098m/5      1         2         2          62s
vllm-hpa   Deployment/vllm-tpu   35348m/5      1         2         2          77s

Patientez 10 minutes, puis répétez les étapes de la section Vérifier que Google Cloud Managed Service pour Prometheus ingère les métriques. Google Cloud Managed Service pour Prometheus ingère les métriques des deux points de terminaison vLLM.

test2

Effectuer un nettoyage

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Supprimer les ressources déployées

Pour éviter que les ressources que vous avez créées dans ce guide ne soient facturées sur votre compte Google Cloud , exécutez les commandes suivantes:

ps -ef | grep load.sh | awk '{print $2}' | xargs -n1 kill -9

gcloud container clusters delete CLUSTER_NAME \
  --location=ZONE

Étape suivante

Apprenez-en plus sur les TPU dans GKE.
Découvrez les métriques disponibles pour configurer votre autoscaler horizontal de pods.
Explorez le dépôt GitHub et la documentation de vLLM.

Diffuser un LLM à l'aide de TPU Trillium sur GKE avec vLLM

Contexte

TPU Trillium

vLLM

Cloud Storage FUSE

Objectifs

Avant de commencer

Check for the roles

Grant the roles

Préparer l'environnement

Accéder au modèle

Générer un jeton d'accès

Lancer Cloud Shell

Créer un cluster GKE

Autopilot

Standard

Configurer kubectl pour communiquer avec votre cluster

Créer un secret Kubernetes pour les identifiants Hugging Face

Créer un bucket Cloud Storage

Configurer un compte de service Kubernetes pour accéder au bucket

(Facultatif) Créer et déployer l'image TPU

Déployer le serveur de modèles vLLM

Diffuser le modèle

Configurer l'autoscaler personnalisé

Créer une charge sur le point de terminaison vLLM

Vérifier que Google Cloud Managed Service pour Prometheus ingère les métriques

Déployer la configuration de l'autoscaler horizontal des pods

Effectuer un nettoyage

Supprimer les ressources déployées

Étape suivante