Se usó la API de Cloud Translation para traducir esta página.

Entrega un LLM con TPU Trillium en GKE con vLLM

Estándar Autopilot

En este instructivo, se muestra cómo entregar modelos de lenguaje grandes (LLM) con unidades de procesamiento tensorial (TPU) en Google Kubernetes Engine (GKE) con el framework de entrega vLLM. En este instructivo, publicarás Llama 3.1 70b, usarás TPU Trillium y configurarás el ajuste de escala automático horizontal de Pods con métricas del servidor de vLLM.

Este documento es un buen punto de partida si necesitas el control detallado, la escalabilidad, la resiliencia, la portabilidad y la rentabilidad de Kubernetes administrado cuando implementas y entregas tus cargas de trabajo de IA/AA.

Contexto

Si usas TPU Trillium en GKE, puedes implementar una solución de entrega sólida y lista para la producción con todos los beneficios de Kubernetes administrado, incluida la escalabilidad eficiente y la mayor disponibilidad. En esta sección, se describen las tecnologías clave que se usan en este instructivo.

TPU Trillium

Las TPU son circuitos integrados personalizados específicos de aplicaciones (ASIC) de Google. Las TPU se usan para acelerar el aprendizaje automático y los modelos de IA compilados con frameworks como TensorFlow, PyTorch yJAX. En este instructivo, se usa TPU Trillium, que es la TPU de sexta generación de Google.

Antes de usar las TPU en GKE, te recomendamos que completes la siguiente ruta de aprendizaje:

Obtén información sobre la arquitectura del sistema de TPU Trillium.
Obtén información sobre las TPU en GKE.

vLLM

vLLM es un framework de código abierto altamente optimizado para la entrega de LLM. vLLM puede aumentar la capacidad de procesamiento de entrega en GPUs, con funciones como las siguientes:

Implementación optimizada de transformadores con PagedAttention.
Agrupación en lotes continua para mejorar la capacidad de procesamiento general de la entrega
Paralelismo de tensor y entrega distribuida en varias TPU

Para obtener más información, consulta la documentación de vLLM.

Cloud Storage FUSE

Cloud Storage FUSE proporciona acceso desde tu clúster de GKE a Cloud Storage para los pesos del modelo que residen en buckets de almacenamiento de objetos. En este instructivo, el bucket de Cloud Storage creado estará vacío al principio. Cuando se inicia vLLM, GKE descarga el modelo de Hugging Face y almacena en caché los pesos en el bucket de Cloud Storage. Cuando se reinicie el pod o se aumente la escala de la implementación, las cargas de modelos posteriores descargarán datos almacenados en caché del bucket de Cloud Storage y aprovecharán las descargas en paralelo para obtener un rendimiento óptimo.

Para obtener más información, consulta la documentación del controlador de CSI de Cloud Storage FUSE.

Objetivos

Este instructivo está dirigido a administradores de plataforma o ingenieros de MLOps o DevOps que deseen usar las funciones de organización de GKE para entregar LLM.

En este instructivo, se abarcan los siguientes pasos:

Crea un clúster de GKE con la topología de TPU Trillium recomendada según las características del modelo.
Implementa el framework de vLLM en un grupo de nodos de tu clúster.
Usa el framework de vLLM para entregar Llama 3.1 70b con un balanceador de cargas.
Configura el ajuste de escala automático horizontal de Pods con las métricas del servidor de vLLM.
Entrega el modelo.

Antes de comenzar

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 colunn 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.
  Ir a IAM
2. Selecciona el proyecto.
3. Haz clic en Grant access.
4. En el campo Principales nuevas, ingresa tu identificador de usuario. Esta suele ser la dirección de correo electrónico de una Cuenta de Google.
5. En la lista Seleccionar un rol, elige un rol.
6. Para otorgar funciones adicionales, haz clic en Agregar otro rol y agrega cada rol adicional.
7. Haz clic en Guardar.

Crea una cuenta de Hugging Face, si todavía no la tienes.
Asegúrate de que tu proyecto tenga la cuota suficiente para Cloud TPU en GKE.

Prepare el entorno

En esta sección, aprovisionarás los recursos que necesitas para implementar el vLLM y el modelo.

Obtén acceso al modelo

Debes firmar el acuerdo de consentimiento para usar Llama 3.1 70b en el repositorio de Hugging Face.

Genera un token de acceso

Si aún no tienes uno, genera un nuevo token de Hugging Face:

Haz clic en Tu perfil > Configuración > Tokens de acceso.
Selecciona Token nuevo.
Especifica el nombre que desees y un rol de al menos Read.
Selecciona Generate un token.

Inicia Cloud Shell

En este instructivo, usarás Cloud Shell para administrar recursos alojados en Google Cloud. Cloud Shell tiene preinstalado el software que necesitas para este instructivo, incluidos kubectl y la CLI de gcloud.

Para configurar tu entorno con Cloud Shell, sigue estos pasos:

En la consola de Google Cloud , haz clic en Activar Cloud Shell en la consola de Google Cloud para iniciar una sesión de Cloud Shell. Esto inicia una sesión en el panel inferior de la consola de Google Cloud .
Configura las variables de entorno predeterminadas:
```
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
```
Reemplaza los siguientes valores:
- PROJECT_ID: El ID del proyecto de Google Cloud .
- CLUSTER_NAME: Es el nombre del clúster de GKE.
- ZONE: Una zona que admite TPU Trillium (v6e).
- CLUSTER_VERSION: la versión de GKE, que debe ser compatible con el tipo de máquina que deseas usar. Ten en cuenta que es posible que la versión predeterminada de GKE no tenga disponibilidad para la TPU de destino. TPU Trillium es compatible con las versiones 1.31.2-gke.1115000 de GKE y versiones posteriores.
- GSBUCKET: Es el nombre del bucket de Cloud Storage que se usará para Cloud Storage FUSE.
- KSA_NAME: El nombre de la cuenta de servicio de Kubernetes que se usa para acceder a los buckets de Cloud Storage. Se necesita acceso al bucket para que Cloud Storage FUSE funcione.
- NAMESPACE: Es el espacio de nombres de Kubernetes en el que deseas implementar los recursos de vLLM.
- IMAGE_NAME: La imagen de TPU de vLLM. Puedes usar la imagen pública docker.io/vllm/vllm-tpu:2e33fe419186c65a18da6668972d61d7bbc31564 o crear tu propia imagen.

Cree un clúster de GKE

Puedes entregar LLM en TPU en un clúster de GKE Autopilot o Standard. Te recomendamos que uses un clúster de Autopilot para una experiencia de Kubernetes completamente administrada. Para elegir el modo de operación de GKE que se adapte mejor a tus cargas de trabajo, consulta Elige un modo de operación de GKE.

Autopilot

Crea un clúster de GKE Autopilot:
```
gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --release-channel=rapid
```
Reemplaza PROJECT_ID por el ID del proyecto de Google Cloud.

Nota: Si tu instancia de Cloud Shell se desconecta durante toda la ejecución del instructivo, repite el paso anterior.

Estándar

Crea un clúster de GKE Standard:

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

Crea un grupo de nodos de porción de 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 crea los siguientes recursos para el LLM:
- Un clúster de GKE estándar que use la federación de identidades para cargas de trabajo para GKE y tenga habilitado el controlador de CSI de Cloud Storage FUSE
- Un grupo de nodos TPU Trillium con un tipo de máquina ct6e-standard-8t Este grupo de nodos tiene un nodo, ocho chips TPU y el ajuste de escala automático habilitado.

Configura kubectl para que se comunique con tu clúster

Para configurar kubectl para que se comunique con tu clúster, ejecuta el siguiente comando:

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

Crea un secreto de Kubernetes para las credenciales de Hugging Face

Crea un espacio de nombres. Puedes omitir este paso si usas el espacio de nombres default:
```
kubectl create namespace NAMESPACE
```

Crea un Secret de Kubernetes que contenga el token de Hugging Face y ejecuta el siguiente comando:

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

Cree un bucket de Cloud Storage

En Cloud Shell, ejecute el siguiente comando:

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

Esto crea un bucket de Cloud Storage para almacenar los archivos del modelo que descargas de Hugging Face.

Configura una cuenta de servicio de Kubernetes para acceder al bucket

Crea la ServiceAccount de Kubernetes:

kubectl create serviceaccount KSA_NAME --namespace NAMESPACE

Otorga acceso de lectura y escritura a la ServiceAccount de Kubernetes para acceder al bucket de 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"

Como alternativa, puedes otorgar acceso de lectura y escritura a todos los buckets de Cloud Storage del proyecto:
```
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 los siguientes recursos para el LLM:
1. Un bucket de Cloud Storage para almacenar el modelo descargado y la caché de compilación Un controlador CSI de Cloud Storage FUSE lee el contenido del bucket.
2. Volumes con el almacenamiento en caché de archivos habilitado y la función de descarga en paralelo de Cloud Storage FUSE
Práctica recomendada:
Usa una caché de archivos respaldada por tmpfs o Hyperdisk / Persistent Disk según el tamaño esperado del contenido del modelo, por ejemplo, los archivos de pesos. En este instructivo, usarás el almacenamiento en caché de archivos de Cloud Storage FUSE respaldado por la RAM.

Compila y, luego, implementa la imagen de TPU (opcional)

Si necesitas un control más detallado sobre el contenido de tu imagen de Docker, elige esta opción.

Aloja tu servidor de vLLM en contenedores:

Clona el repositorio de vLLM y compila la imagen:

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

Envía la imagen a 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

Implementa el servidor de modelos de vLLM

Para implementar el servidor de modelos de vLLM, sigue estos pasos:

Inspecciona el manifiesto de Deployment guardado como vllm-llama3-70b.yaml. Un Deployment es un objeto de la API de Kubernetes que te permite ejecutar varias réplicas de Pods que se distribuyen entre los nodos de un clúster:


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

Ejecuta el siguiente comando para aplicar el manifiesto:

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

Observa los registros del servidor de modelos en ejecución:

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

El resultado debería ser similar al siguiente:

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)

Entrega el modelo

Ejecuta el siguiente comando para obtener la dirección IP externa del servicio:

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

En una terminal nueva, interactúa con el modelo con 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
}'

El resultado debería ser similar al siguiente ejemplo:

{"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}}

Configura el escalador automático personalizado

En esta sección, configurarás el ajuste de escala automático horizontal de Pods con métricas personalizadas de Prometheus. Usas las métricas de Google Cloud Managed Service para Prometheus desde el servidor vLLM.

Para obtener más información, consulta Google Cloud Managed Service para Prometheus. Esta opción debería estar habilitada de forma predeterminada en el clúster de GKE.

Configura el adaptador de métricas personalizadas de Stackdriver en tu clúster:

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

Agrega el rol de visor de supervisión a la cuenta de servicio que usa el adaptador de Stackdriver de métricas personalizadas:
```
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: Asegúrate de que la cuenta de servicio que usa tu clúster de GKE tenga el rol de Escritor de métricas de supervisión. En este instructivo, se usa la cuenta de servicio predeterminada de Compute Engine.

Guarda el siguiente manifiesto como 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

Aplícalo al clúster:
```
kubectl apply -f vllm_pod_monitor.yaml
```

Crea carga en el extremo vLLM

Crea una carga en el servidor de vLLM para probar cómo GKE se ajusta automáticamente con una métrica de vLLM personalizada.

Ejecuta una secuencia de comandos de Bash (load.sh) para enviar N solicitudes simultáneas al extremo de 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

Reemplaza PARALLEL_PROCESSES por la cantidad de procesos paralelos que deseas ejecutar.

Ejecuta la secuencia de comandos de Bash:
```
nohup ./load.sh &
```

Verifica que Google Cloud Managed Service para Prometheus transfiera las métricas

Después de que Google Cloud Managed Service para Prometheus extraiga las métricas y agregues carga al extremo de vLLM, podrás ver las métricas en Cloud Monitoring.

En la consola de Google Cloud , ve a la página Explorador de métricas.

Ir al Explorador de métricas
Haz clic en < > PromQL.

Ingresa la siguiente consulta para observar las métricas de tráfico:

vllm:avg_generation_throughput_toks_per_s{cluster='CLUSTER_NAME_HERE'}

En el gráfico de líneas, la métrica vLLM aumenta de 0 (carga previa) a un valor (carga posterior). Este gráfico confirma que tus métricas de vLLM se transfieren a Google Cloud Managed Service para Prometheus.

La siguiente imagen es un ejemplo de un gráfico después de la ejecución de la secuencia de comandos de carga. En este caso, el servidor de modelos entrega alrededor de 2,000 tokens de generación por segundo.

prueba

Implementa la configuración del Horizontal Pod Autoscaler

Cuando decidas en qué métrica realizar el ajuste de escala automático, te recomendamos las siguientes métricas para la TPU de vLLM:

num_requests_waiting: Esta métrica se relaciona con la cantidad de solicitudes que esperan en la cola del servidor de modelos. Esta cantidad comienza a crecer de forma notable cuando la caché de kv está llena.
gpu_cache_usage_perc: Esta métrica se relaciona con el uso de la caché de kv, que se correlaciona directamente con la cantidad de solicitudes que se procesan para un ciclo de inferencia determinado en el servidor de modelos. Ten en cuenta que esta métrica funciona de la misma manera en las GPUs y las TPU, aunque está vinculada al esquema de nombres de las GPUs.

Te recomendamos que uses num_requests_waiting cuando optimices la capacidad de procesamiento y el costo, y cuando tus objetivos de latencia se puedan alcanzar con la capacidad de procesamiento máxima del servidor de modelos.

Te recomendamos que uses gpu_cache_usage_perc cuando tengas cargas de trabajo sensibles a la latencia en las que el escalamiento basado en colas no sea lo suficientemente rápido para cumplir con tus requisitos.

Para obtener más información, consulta Prácticas recomendadas para el ajuste de escala automático de cargas de trabajo de inferencia de modelos de lenguaje grandes (LLM) con TPU.

Cuando selecciones un objetivo averageValue para tu configuración de HPA, deberás determinarlo de forma experimental. Consulta la entrada de blog Ahorrar en GPUs: Ajuste de escala automático más inteligente para tus cargas de trabajo de inferencia de GKE para obtener más ideas sobre cómo optimizar esta parte. El profile-generator que se usa en esta entrada de blog también funciona para la TPU de vLLM.

Para implementar la configuración del Horizontal Pod Autoscaler con num_requests_waiting, sigue estos pasos:

Guarda el siguiente manifiesto como 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

Las métricas de vLLM en Google Cloud Managed Service para Prometheus siguen el formato vllm:metric_name.

Práctica recomendada:

Usa num_requests_waiting para escalar la capacidad de procesamiento. Usa gpu_cache_usage_perc para casos de uso de TPU sensibles a la latencia.

Implementa la configuración del Horizontal Pod Autoscaler:
```
kubectl apply -f vllm-hpa.yaml
```
GKE programa otro Pod para que se implemente, lo que activa el escalador automático del grupo de nodos para que agregue un segundo nodo antes de implementar la segunda réplica de vLLM.

Observa el progreso del ajuste de escala automático de Pods:

kubectl get hpa --watch

El resultado es similar a este:

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

Espera 10 minutos y repite los pasos de la sección Verifica que Google Cloud Managed Service para Prometheus transfiera las métricas. Google Cloud Managed Service para Prometheus transfiere las métricas de ambos extremos de vLLM.

prueba2

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Borra los recursos implementados

Para evitar que se generen cargos en tu cuenta de Google Cloud por los recursos que creaste en esta guía, ejecuta los siguientes comandos:

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

gcloud container clusters delete CLUSTER_NAME \
  --location=ZONE

¿Qué sigue?

Obtén más información sobre las TPU en GKE.
Obtén más información sobre las métricas disponibles para configurar el Horizontal Pod Autoscaler.
Explora el repositorio de GitHub y la documentación de vLLM.

Entrega un LLM con TPU Trillium en GKE con vLLM

Contexto

TPU Trillium

vLLM

Cloud Storage FUSE

Objetivos

Antes de comenzar

Check for the roles

Grant the roles

Prepare el entorno

Obtén acceso al modelo

Genera un token de acceso

Inicia Cloud Shell

Cree un clúster de GKE

Autopilot

Estándar

Configura kubectl para que se comunique con tu clúster

Crea un secreto de Kubernetes para las credenciales de Hugging Face

Cree un bucket de Cloud Storage

Configura una cuenta de servicio de Kubernetes para acceder al bucket

Compila y, luego, implementa la imagen de TPU (opcional)

Implementa el servidor de modelos de vLLM

Entrega el modelo

Configura el escalador automático personalizado

Crea carga en el extremo vLLM

Verifica que Google Cloud Managed Service para Prometheus transfiera las métricas

Implementa la configuración del Horizontal Pod Autoscaler

Limpia

Borra los recursos implementados

¿Qué sigue?