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:
- Scopri di più sull'architettura di sistema di TPU Trillium.
- 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:
- Crea un cluster GKE con la topologia TPU Trillium consigliata in base alle caratteristiche del modello.
- Esegui il deployment del framework vLLM in un pool di nodi del cluster.
- Utilizza il framework vLLM per pubblicare Llama 3.1 70b utilizzando un bilanciatore del carico.
- Configura scalabilità automatica orizzontale dei pod utilizzando le metriche del server vLLM.
- 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.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the required API.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the required 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.clusterAdminCheck for the roles
-
In the Google Cloud console, go to the IAM page.
Go to IAM - Select the project.
-
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.
- 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
-
In the Google Cloud console, go to the IAM page.
Vai a IAM - Seleziona il progetto.
- Fai clic su Concedi l'accesso.
-
Nel campo Nuove entità, inserisci il tuo identificatore utente. In genere si tratta dell'indirizzo email di un Account Google.
- Nell'elenco Seleziona un ruolo, seleziona un ruolo.
- Per concedere altri ruoli, fai clic su Aggiungi un altro ruolo e aggiungi ogni ruolo aggiuntivo.
- 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:
- Fai clic su Il tuo profilo > Impostazioni > Token di accesso.
- Seleziona Nuovo token.
- Specifica un nome a tua scelta e un ruolo di almeno
Read. - 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:
Nella console Google Cloud , avvia una sessione di Cloud Shell facendo clic su
Attiva Cloud Shell nella consoleGoogle Cloud . Viene avviata una sessione nel riquadro inferiore della console Google Cloud .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 ZONE=ZONE && \ export REGION=REGION && \ export HF_TOKEN=HUGGING_FACE_TOKEN && \ export CLUSTER_VERSION=CLUSTER_VERSION && \ export GSBUCKET=GSBUCKET && \ export KSA_NAME=KSA_NAME && \ export NAMESPACE=NAMESPACESostituisci i seguenti valori:
- PROJECT_ID : il tuo Google Cloud ID progetto.
- CLUSTER_NAME : il nome del tuo cluster GKE.
- ZONE : una zona che supporta TPU Trillium (v6e).
- REGION : una regione 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 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
Crea un cluster GKE Autopilot:
gcloud container clusters create-auto ${CLUSTER_NAME} \ --cluster-version=${CLUSTER_VERSION} \ --region=${REGION}
Standard
Crea un cluster GKE Standard:
gcloud container clusters create ${CLUSTER_NAME} \ --project=${PROJECT_ID} \ --region=${REGION} \ --node-locations=${ZONE} \ --cluster-version=${CLUSTER_VERSION} \ --workload-pool=${PROJECT_ID}.svc.id.goog \ --addons GcsFuseCsiDriverCrea un pool di nodi slice TPU:
gcloud container node-pools create tpunodepool \ --region=${REGION} \ --node-locations=${ZONE} \ --num-nodes=1 \ --machine-type=ct6e-standard-8t \ --cluster=${CLUSTER_NAME} \ --enable-autoscaling --total-min-nodes=1 --total-max-nodes=2GKE 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} --region=${REGION}
Crea un secret di Kubernetes per le credenziali di Hugging Face
Crea uno spazio dei nomi. Puoi saltare questo passaggio se utilizzi lo spazio dei nomi
default:kubectl create namespace ${NAMESPACE}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
Crea il ServiceAccount Kubernetes:
kubectl create serviceaccount ${KSA_NAME} --namespace ${NAMESPACE}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"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:
- 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.
- 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
tmpfsoHyperdisk / Persistent Diska 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.
Ispeziona il manifest del deployment salvato come
vllm-llama3-70b.yaml:Applica il manifest eseguendo questo comando:
kubectl apply -f vllm-llama3-70b.yaml -n ${NAMESPACE}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
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})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}}
Configurare 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.
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.yamlAggiungi 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-adapterSalva il seguente manifest come
vllm_pod_monitor.yaml:Applica il file al cluster:
kubectl apply -f vllm_pod_monitor.yaml -n ${NAMESPACE}
Crea carico sull'endpoint vLLM
Crea carico sul server vLLM per testare la scalabilità automatica di GKE con una metrica vLLM personalizzata.
Esegui uno script bash (
load.sh) per inviareNrichieste 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 waitSostituisci PARALLEL_PROCESSES con il numero di processi paralleli che vuoi eseguire.
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.
Nella console Google Cloud , vai alla pagina Esplora metriche.
Vai a Esplora metriche
Fai clic su < > PromQL.
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 del modello linguistico di grandi dimensioni (LLM) con le TPU.
Quando selezioni un target averageValue per la configurazione 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:
Salva il seguente manifest come
vllm-hpa.yaml:Le metriche vLLM in Google Cloud Managed Service per Prometheus seguono il formato
vllm:metric_name.Best practice: Utilizza
num_requests_waitingper scalare la velocità effettiva. Utilizzagpu_cache_usage_percper i casi d'uso della TPU sensibili alla latenza.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.
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 77sAttendi 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} \
--region=${REGION}
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.