Gestisci un LLM utilizzando TPU Trillium su GKE con vLLM

Standard Autopilot

---

Questo tutorial mostra come gestire modelli linguistici di grandi dimensioni (LLM) utilizzando le unità di elaborazione tensoriale (TPU) su Google Kubernetes Engine (GKE) con il framework di gestione vLLM. In questo tutorial utilizzerai Llama 3.1 70b, TPU Trillium e configurerai la scalabilità automatica pod orizzontale utilizzando le metriche del server vLLM.

Questo documento è un buon punto di partenza se hai bisogno del controllo granulare, della scalabilità, della resilienza, della portabilità e dell'economicità di Kubernetes gestito quando esegui il deployment e il servizio dei tuoi carichi di lavoro di AI/ML.

Sfondo

Utilizzando TPU Trillium su GKE, puoi implementare una soluzione di serving affidabile e pronta per la produzione con tutti i vantaggi di Kubernetes gestito, tra cui scalabilità efficiente e maggiore disponibilità. Questa sezione descrive le tecnologie chiave utilizzate in questa guida.

TPU Trillium

Le TPU sono circuiti integrati specifici per le applicazioni (ASIC) sviluppati da Google. Le TPU vengono utilizzate per accelerare i modelli di machine learning e AI creati utilizzando framework come TensorFlow, PyTorch e JAX. Questo tutorial utilizza la TPU Trillium, la TPU di sesta generazione di Google.

Prima di utilizzare le TPU in GKE, ti consigliamo di completare il seguente percorso di apprendimento:

1. Scopri di più sull'architettura di sistema di TPU Trillium.
2. Scopri di più sulle TPU in GKE.

vLLM

vLLM è un framework open source altamente ottimizzato per l'erogazione di LLM. vLLM può aumentare la velocità effettiva di erogazione sulle TPU, con funzionalità come le seguenti:

• Implementazione ottimizzata di Transformer con PagedAttention.
• Batching continuo per migliorare la velocità effettiva complessiva della pubblicazione.
• Parallelismo dei tensori e servizio distribuito su più TPU.

Per saperne di più, consulta la documentazione di vLLM.

Cloud Storage FUSE

Cloud Storage FUSE fornisce l'accesso dal cluster GKE a Cloud Storage per i pesi del modello che si trovano nei bucket di archiviazione di oggetti. In questo tutorial, il bucket Cloud Storage creato inizialmente sarà vuoto. All'avvio di vLLM, GKE scarica il modello da Hugging Face e memorizza nella cache i pesi nel bucket Cloud Storage. Al riavvio del pod o all'aumento delle dimensioni del deployment, i carichi successivi del modello scaricheranno i dati memorizzati nella cache dal bucket Cloud Storage, sfruttando i download paralleli per prestazioni ottimali.

Per saperne di più, consulta la documentazione del driver CSI di Cloud Storage FUSE.

Obiettivi

Questo tutorial è rivolto a ingegneri MLOps o DevOps o amministratori di piattaforme che vogliono utilizzare le funzionalità di orchestrazione di GKE per pubblicare LLM.

Questo tutorial illustra i seguenti passaggi:

1. Crea un cluster GKE con la topologia TPU Trillium consigliata in base alle caratteristiche del modello.
2. Esegui il deployment del framework vLLM in un pool di nodi del cluster.
3. Utilizza il framework vLLM per pubblicare Llama 3.1 70b utilizzando un bilanciatore del carico.
4. Configura scalabilità automatica orizzontale dei pod utilizzando le metriche del server vLLM.
5. Pubblica il modello.

Prima di iniziare

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.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify 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.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify 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.

     Vai a IAM
  2. Seleziona il progetto.
  3. Fai clic su Concedi l'accesso.

  4. Nel campo Nuove entità, inserisci il tuo identificatore utente. In genere si tratta dell'indirizzo email di un Account Google.

  5. Nell'elenco Seleziona un ruolo, seleziona un ruolo.
  6. Per concedere altri ruoli, fai clic su Aggiungi un altro ruolo e aggiungi ogni ruolo aggiuntivo.
  7. Fai clic su Salva.
  • Crea un account Hugging Face, se non ne hai già uno.
  • Assicurati che il tuo progetto disponga di una quota sufficiente per Cloud TPU in GKE.

  Prepara l'ambiente

  In questa sezione, esegui il provisioning delle risorse necessarie per il deployment di vLLM e del modello.

  Ottenere l'accesso al modello

  Per utilizzare Llama 3.1 70b nel repository Hugging Face, devi firmare il contratto di consenso.

  Generare un token di accesso

  Se non ne hai già uno, genera un nuovo token Hugging Face:

  1. Fai clic su Il tuo profilo > Impostazioni > Token di accesso.
  2. Seleziona Nuovo token.
  3. Specifica un nome a tua scelta e un ruolo di almeno Read.
  4. Seleziona Genera un token.

  Avvia Cloud Shell

  In questo tutorial utilizzerai Cloud Shell per gestire le risorse ospitate su Google Cloud. Cloud Shell include il software necessario per questo tutorial, tra cui kubectl e gcloud CLI.

  Per configurare l'ambiente con Cloud Shell:

  1. Nella console Google Cloud , avvia una sessione di Cloud Shell facendo clic su Attiva Cloud Shell nella Google Cloud console. Viene avviata una sessione nel riquadro inferiore della console Google Cloud .

  2. Imposta le variabili di ambiente predefinite:

     gcloud config set project PROJECT_ID && \
     gcloud config set billing/quota_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 CONTROL_PLANE_LOCATION=CONTROL_PLANE_LOCATION && \
     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
     

     Sostituisci i seguenti valori:

     • PROJECT_ID : il tuo Google Cloud ID progetto.
     • CLUSTER_NAME : il nome del tuo cluster GKE.
     • CONTROL_PLANE_LOCATION: la regione di Compute Engine del control plane del cluster. Fornisci una regione che supporti TPU Trillium (v6e).
     • ZONE : una zona che supporta TPU Trillium (v6e).
     • CLUSTER_VERSION : la versione di GKE, che deve supportare il tipo di macchina che vuoi utilizzare. Tieni presente che la versione GKE predefinita potrebbe non essere disponibile per la tua TPU di destinazione. TPU Trillium (v6e) è supportata nelle versioni di GKE 1.31.2-gke.1115000 o successive.
     • GSBUCKET : il nome del bucket Cloud Storage da utilizzare per Cloud Storage FUSE.
     • KSA_NAME : il nome di Kubernetes ServiceAccount utilizzato per accedere ai bucket Cloud Storage. Per il funzionamento di Cloud Storage FUSE è necessario l'accesso al bucket.
     • NAMESPACE : lo spazio dei nomi Kubernetes in cui vuoi eseguire il deployment degli asset vLLM.

  Crea un cluster GKE

  Puoi gestire LLM su TPU in un cluster GKE Autopilot o Standard. Ti consigliamo di utilizzare un cluster Autopilot per un'esperienza Kubernetes completamente gestita. Per scegliere la modalità operativa GKE più adatta ai tuoi carichi di lavoro, consulta Scegliere una modalità operativa GKE.

  Autopilot

  1. Crea un cluster GKE Autopilot:

     gcloud container clusters create-auto ${CLUSTER_NAME} \
         --cluster-version=${CLUSTER_VERSION} \
         --location=${CONTROL_PLANE_LOCATION}
     

     Nota: se la tua istanza Cloud Shell si disconnette durante l'esecuzione del tutorial, ripeti il passaggio precedente.

  Standard

  1. Crea un cluster GKE Standard:

     gcloud container clusters create ${CLUSTER_NAME} \
         --project=${PROJECT_ID} \
         --location=${CONTROL_PLANE_LOCATION} \
         --node-locations=${ZONE} \
         --cluster-version=${CLUSTER_VERSION} \
         --workload-pool=${PROJECT_ID}.svc.id.goog \
         --addons GcsFuseCsiDriver
     

  2. Crea un pool di nodi slice TPU:

     gcloud container node-pools create tpunodepool \
         --location=${CONTROL_PLANE_LOCATION} \
         --node-locations=${ZONE} \
         --num-nodes=1 \
         --machine-type=ct6e-standard-8t \
         --cluster=${CLUSTER_NAME} \
         --enable-autoscaling --total-min-nodes=1 --total-max-nodes=2
     

     GKE crea le seguenti risorse per l'LLM:

     • Un cluster GKE Standard che utilizza Workload Identity Federation for GKE e ha il driver CSI di Cloud Storage FUSE abilitato.
     • Un pool di nodi TPU Trillium con un tipo di macchina ct6e-standard-8t. Questo pool di nodi ha un nodo, otto chip TPU e la scalabilità automatica abilitata.

  Configura kubectl per comunicare con il cluster

  Per configurare kubectl in modo che comunichi con il tuo cluster, esegui questo comando:

    gcloud container clusters get-credentials ${CLUSTER_NAME} --location=${CONTROL_PLANE_LOCATION}
  

  Crea un secret di Kubernetes per le credenziali di Hugging Face

  1. Crea uno spazio dei nomi. Puoi saltare questo passaggio se utilizzi lo spazio dei nomi default:

     kubectl create namespace ${NAMESPACE}
     

  2. Crea un secret Kubernetes che contenga il token Hugging Face eseguendo il seguente comando:

     kubectl create secret generic hf-secret \
         --from-literal=hf_api_token=${HF_TOKEN} \
         --namespace ${NAMESPACE}
     

  Crea un bucket Cloud Storage

  In Cloud Shell, esegui questo comando:

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

  In questo modo viene creato un bucket Cloud Storage per archiviare i file del modello che scarichi da Hugging Face.

  Configura un service account Kubernetes per accedere al bucket

  1. Crea il ServiceAccount Kubernetes:

     kubectl create serviceaccount ${KSA_NAME} --namespace ${NAMESPACE}
     

  2. Concedi l'accesso in lettura/scrittura al service account Kubernetes per accedere al 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"
     

  3. In alternativa, puoi concedere l'accesso in lettura e scrittura a tutti i bucket Cloud Storage nel progetto:

     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 crea le seguenti risorse per l'LLM:

     1. Un bucket Cloud Storage per archiviare il modello scaricato e la cache di compilazione. Un driver CSI di Cloud Storage FUSE legge il contenuto del bucket.
     2. Volumi con memorizzazione nella cache dei file abilitata e la funzionalità di download parallelo di Cloud Storage FUSE.
     Best practice:

     Utilizza una cache di file supportata da tmpfs o Hyperdisk / Persistent Disk a seconda delle dimensioni previste dei contenuti del modello, ad esempio i file di peso. In questo tutorial, utilizzi la cache dei file Cloud Storage FUSE supportata dalla RAM.

  Esegui il deployment del server del modello vLLM

  Per eseguire il deployment del server del modello vLLM, questo tutorial utilizza un deployment Kubernetes. Un deployment è un oggetto API Kubernetes che consente di eseguire più repliche di pod distribuite tra i nodi di un cluster.

  1. Esamina il seguente manifest di Deployment salvato come vllm-llama3-70b.yaml, che utilizza una singola replica:

     
     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: docker.io/vllm/vllm-tpu:73aa7041bfee43581314e6f34e9a657137ecc092
             command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]
             args:
             - --host=0.0.0.0
             - --port=8000
             - --tensor-parallel-size=8
             - --max-model-len=4096
             - --model=meta-llama/Llama-3.1-70B
             - --download-dir=/data
             - --max-num-batched-tokens=512
             - --max-num-seqs=128
             env: 
             - name: HUGGING_FACE_HUB_TOKEN
               valueFrom:
                 secretKeyRef:
                   name: hf-secret
                   key: hf_api_token
             - name: VLLM_XLA_CACHE_PATH
               value: "/data"
             - name: VLLM_USE_V1
               value: "1"
             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
     

     Se aumenti lo scale up del deployment a più repliche, le scritture simultanee in VLLM_XLA_CACHE_PATH causeranno l'errore: RuntimeError: filesystem error: cannot create directories. Per evitare questo errore, hai due opzioni:

     1. Rimuovi la posizione della cache XLA rimuovendo il seguente blocco dal file YAML di deployment. Ciò significa che tutte le repliche ricompileranno la cache.

        - name: VLLM_XLA_CACHE_PATH
          value: "/data"
        

     2. Scala il deployment a 1 e attendi che la prima replica diventi pronta e scriva nella cache XLA. Poi esegui lo scale up a repliche aggiuntive. Ciò consente alle repliche rimanenti di leggere la cache senza tentare di scriverla.

  2. Applica il manifest eseguendo questo comando:

     kubectl apply -f vllm-llama3-70b.yaml -n ${NAMESPACE}
     

  3. Visualizza i log del server del modello in esecuzione:

     kubectl logs -f -l app=vllm-tpu -n ${NAMESPACE}
     

     L'output dovrebbe essere simile al seguente:

     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)
     

  Pubblica il modello

  1. Per ottenere l'indirizzo IP esterno del servizio VLLM, esegui questo comando:

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

  2. Interagisci con il modello utilizzando curl:

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

     L'output dovrebbe essere simile al seguente:

     {"id":"cmpl-6b4bb29482494ab88408d537da1e608f","object":"text_completion","created":1727822657,"model":"meta-llama/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}}
     

  Configura lo scalatore automatico personalizzato

  In questa sezione configurerai la scalabilità automatica orizzontale dei pod utilizzando metriche Prometheus personalizzate. Utilizzi le metriche di Google Cloud Managed Service per Prometheus dal server vLLM.

  Per saperne di più, consulta Google Cloud Managed Service per Prometheus. Questa opzione dovrebbe essere abilitata per impostazione predefinita sul cluster GKE.

  1. Configura l'adattatore Stackdriver delle metriche personalizzate sul tuo cluster:

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

  2. Aggiungi il ruolo Visualizzatore Monitoring al account di servizio utilizzato dall'adattatore Stackdriver per le metriche personalizzate:

     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
     

     Nota :assicurati che il account di servizio utilizzato dal tuo cluster GKE disponga del ruolo Scrittore metriche di monitoraggio. Questo tutorial utilizza il service account predefinito di Compute Engine.

  3. Salva il seguente manifest come 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
     

  4. Applica il file al cluster:

     kubectl apply -f vllm_pod_monitor.yaml -n ${NAMESPACE}
     

  Operazione riuscita: Google Cloud Managed Service per Prometheus è ora configurato per eseguire lo scraping delle metriche del server vLLM e renderle visibili al controller di scalabilità automatica orizzontale dei pod.

  Crea carico sull'endpoint vLLM

  Crea un carico sul server vLLM per testare la scalabilità automatica di GKE con una metrica vLLM personalizzata.

  1. Esegui uno script bash (load.sh) per inviare N richieste parallele all'endpoint vLLM:

     #!/bin/bash
     N=PARALLEL_PROCESSES
     export vllm_service=$(kubectl get service vllm-service -o jsonpath='{.status.loadBalancer.ingress[0].ip}' -n ${NAMESPACE})
     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/Llama-3.1-70B", "prompt": "Write a story about san francisco", "max_tokens": 1000, "temperature": 0}'
       done &  # Run in the background
     done
     wait
     

     Sostituisci PARALLEL_PROCESSES con il numero di processi paralleli che vuoi eseguire.

  2. Esegui lo script bash:

     chmod +x load.sh
     nohup ./load.sh &
     

  Verifica che Google Cloud Managed Service per Prometheus acquisisca le metriche

  Dopo che Google Cloud Managed Service per Prometheus ha eseguito lo scraping delle metriche e stai aggiungendo carico all'endpoint vLLM, puoi visualizzare le metriche in Cloud Monitoring.

  1. Nella console Google Cloud , vai alla pagina Esplora metriche.

     Vai a Esplora metriche

  2. Fai clic su < > PromQL.

  3. Inserisci la seguente query per osservare le metriche sul traffico:

     vllm:num_requests_waiting{cluster='CLUSTER_NAME'}
     

  Un grafico a linee mostra la metrica vLLM (num_requests_waiting) misurata nel tempo. La metrica vLLM aumenta da 0 (precaricamento) a un valore (post-caricamento). Questo grafico conferma che le metriche vLLM vengono importate in Google Cloud Managed Service per Prometheus. Il seguente grafico di esempio mostra un valore di precaricamento iniziale pari a 0, che raggiunge un valore massimo post-caricamento di quasi 400 entro un minuto.

  

  Esegui il deployment della configurazione di Horizontal Pod Autoscaler

  Quando decidi su quale metrica eseguire la scalabilità automatica, ti consigliamo le seguenti metriche per le TPU vLLM:

  • num_requests_waiting: questa metrica si riferisce al numero di richieste in attesa nella coda del server del modello. Questo numero inizia a crescere in modo significativo quando la cache KV è piena.

  • gpu_cache_usage_perc: questa metrica si riferisce all'utilizzo della cache KV, che è direttamente correlato al numero di richieste elaborate per un determinato ciclo di inferenza sul server del modello. Tieni presente che questa metrica funziona allo stesso modo su GPU e TPU, anche se è legata allo schema di denominazione delle GPU.

  Ti consigliamo di utilizzare num_requests_waiting quando esegui l'ottimizzazione per il throughput e il costo e quando i tuoi target di latenza sono raggiungibili con il throughput massimo del server del modello.

  Ti consigliamo di utilizzare gpu_cache_usage_perc quando hai carichi di lavoro sensibili alla latenza in cui lo scaling basato sulla coda non è abbastanza veloce per soddisfare i tuoi requisiti.

  Per ulteriori spiegazioni, consulta Best practice per la scalabilità automatica dei workload di inferenza di modelli linguistici di grandi dimensioni (LLM) con le TPU.

  Quando selezioni un target averageValue per la configurazione di HPA, devi determinarlo in modo sperimentale. Consulta il post del blog Risparmia sulle GPU: scalabilità automatica più intelligente per i carichi di lavoro di inferenza GKE per ulteriori idee su come ottimizzare questa parte. profile-generator utilizzato in questo post del blog funziona anche per vLLM TPU.

  Nelle istruzioni riportate di seguito, esegui il deployment della configurazione HPA utilizzando la metrica num_requests_waiting. A scopo dimostrativo, imposta la metrica su un valore basso in modo che la configurazione HPA aumenti le repliche vLLM a due. Per eseguire il deployment della configurazione di Horizontal Pod Autoscaler utilizzando num_requests_waiting, segui questi passaggi:

  1. Salva il seguente manifest come 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
     

     Le metriche vLLM in Google Cloud Managed Service per Prometheus seguono il formato vllm:metric_name.

     Best practice:

     Utilizza num_requests_waiting per scalare la velocità effettiva. Utilizza gpu_cache_usage_perc per i casi d'uso della TPU sensibili alla latenza.

  2. Esegui il deployment della configurazione di Horizontal Pod Autoscaler:

     kubectl apply -f vllm-hpa.yaml -n ${NAMESPACE}
     

     GKE pianifica il deployment di un altro pod, il che attiva il gestore della scalabilità automaticapool di nodil per aggiungere un secondo nodo prima di eseguire il deployment della seconda replica vLLM.

  3. Monitora l'avanzamento della scalabilità automatica dei pod:

     kubectl get hpa --watch -n ${NAMESPACE}
     

     L'output è simile al seguente:

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

     Operazione riuscita: GKE esegue lo scale up del server vLLM utilizzando metriche Prometheus personalizzate.

  4. Attendi 10 minuti e ripeti i passaggi della sezione Verifica che Google Cloud Managed Service per Prometheus importi le metriche. Google Cloud Managed Service per Prometheus ora acquisisce le metriche da entrambi gli endpoint vLLM.

  Esegui la pulizia

  Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

  Elimina le risorse di cui è stato eseguito il deployment

  Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse che hai creato in questa guida, esegui i seguenti comandi:

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

  gcloud container clusters delete ${CLUSTER_NAME} \
    --location=${CONTROL_PLANE_LOCATION}
  

  Passaggi successivi

  • Scopri di più sulle TPU in GKE.
  • Scopri di più sulle metriche disponibili per configurare il gestore della scalabilità automatica orizzontale dei pod.
  • Esplora il repository GitHub e la documentazione di vLLM.