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

Publica LLM como DeepSeek-R1 671B o Llama 3.1 405B en GKE

Autopilot Estándar

Descripción general

En esta guía, se muestra cómo entregar modelos de lenguaje grande (LLM) de vanguardia, como DeepSeek-R1 671B o Llama 3.1 405B en Google Kubernetes Engine (GKE) con unidades de procesamiento gráfico (GPU) en varios nodos.

En esta guía, se muestra cómo usar tecnologías de código abierto portátiles, como Kubernetes, vLLM y la API de LeaderWorkerSet (LWS), para implementar y entregar cargas de trabajo de IA/AA en GKE, aprovechando su control detallado, escalabilidad, resiliencia, portabilidad y rentabilidad.

Antes de leer esta página, asegúrate de estar familiarizado con lo siguiente:

Fondo

En esta sección, se describen las tecnologías clave que se usan en esta guía, incluidos los dos LLM que se usan como ejemplos en esta guía: DeepSeek-R1 y Llama 3.1 405B.

DeepSeek-R1

DeepSeek-R1, un modelo grande de lenguaje de 671, 000 millones de parámetros de DeepSeek, está diseñado para la inferencia lógica, el razonamiento matemático y la resolución de problemas en tiempo real en varias tareas basadas en texto. GKE controla las demandas computacionales de DeepSeek-R1 y admite sus capacidades con recursos escalables, computación distribuida y redes eficientes.

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

Llama 3.1 405b

Llama 3.1 405B es un modelo de lenguaje extenso de Meta diseñado para una amplia variedad de tareas de procesamiento de lenguaje natural, incluida la generación de texto, la traducción y la respuesta de preguntas. GKE ofrece la infraestructura sólida necesaria para admitir las necesidades de entrenamiento y entrega distribuidos de modelos de esta escala.

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

Servicio de Kubernetes administrado de GKE

Google Cloud ofrece una amplia variedad de servicios, incluido GKE, que es adecuado para implementar y administrar cargas de trabajo de IA/AA. GKE es un servicio administrado de Kubernetes que simplifica la implementación, el escalamiento y la administración de aplicaciones alojadas en contenedores. GKE proporciona la infraestructura necesaria, incluidos recursos escalables, procesamiento distribuido y redes eficientes, para controlar las demandas computacionales de los LLM.

Para obtener más información sobre los conceptos clave de Kubernetes, consulta Comienza a aprender sobre Kubernetes. Para obtener más información sobre GKE y cómo te ayuda a escalar, automatizar y administrar Kubernetes, consulta Descripción general de GKE.

GPU

Las unidades de procesamiento gráfico (GPU) te permiten acelerar cargas de trabajo específicas, como el aprendizaje automático y el procesamiento de datos. GKE ofrece nodos equipados con estas potentes GPUs, lo que te permite configurar tu clúster para obtener un rendimiento óptimo en las tareas de aprendizaje automático y procesamiento de datos. GKE proporciona una variedad de opciones de tipos de máquinas para la configuración de nodos, incluidos los tipos de máquinas con GPUs NVIDIA H100, L4 y A100.

Para obtener más información, consulta Acerca de las GPUs en GKE.

LeaderWorkerSet (LWS)

LeaderWorkerSet (LWS) es una API de implementación de Kubernetes que aborda patrones de implementación comunes de cargas de trabajo de inferencia de varios nodos de IA/AA. La entrega de varios nodos aprovecha varios Pods, cada uno de los cuales puede ejecutarse en un nodo diferente, para controlar la carga de trabajo de inferencia distribuida. LWS permite tratar varios Pods como un grupo, lo que simplifica la administración de la entrega de modelos distribuidos.

vLLM y entrega de varios hosts

Cuando se entregan LLM de procesamiento intensivo, te recomendamos que uses vLLM y ejecutes las cargas de trabajo en GPUs.

vLLM es un framework de entrega de LLM de código abierto altamente optimizado que 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
Publicación distribuida en varias GPUs

Con LLM que requieren un procesamiento intensivo que no se puede ajustar a un solo nodo de GPU, puedes usar varios nodos de GPU para entregar el modelo. vLLM admite la ejecución de cargas de trabajo en GPUs con dos estrategias:

El paralelismo de tensor divide las multiplicaciones de matrices en la capa de transformador en varias GPUs. Sin embargo, esta estrategia requiere una red rápida debido a la comunicación necesaria entre las GPUs, lo que la hace menos adecuada para ejecutar cargas de trabajo en varios nodos.
El paralelismo de canalización divide el modelo por capa o verticalmente. Esta estrategia no requiere una comunicación constante entre las GPUs, lo que la convierte en una mejor opción cuando se ejecutan modelos en varios nodos.

Puedes usar ambas estrategias en la publicación de varios nodos. Por ejemplo, cuando usas dos nodos con ocho GPUs H100 cada uno, puedes usar ambas estrategias:

Paralelismo de canalización de dos vías para dividir el modelo en los dos nodos
Paralelismo de tensor de ocho vías para dividir el modelo entre las ocho GPUs en cada nodo

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

Objetivos

Prepara tu entorno con un clúster de GKE en modo Autopilot o Standard.
Implementa vLLM en varios nodos de tu clúster.
Usa vLLM para entregar el modelo a través de curl.

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
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.
  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 las GPUs H100. Para obtener más información, consulta Acerca de las GPU y Cuotas de asignación.

Obtén acceso al modelo

Puedes usar los modelos Llama 3.1 405B o DeepSeek-R1.

DeepSeek-R1

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.

Llama 3.1 405b

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.

Prepare el entorno

En este instructivo, usarás Cloud Shell para administrar recursos alojados en Google Cloud. Cloud Shell tiene preinstalado el software que necesitarás 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 CLUSTER_NAME=CLUSTER_NAME
export ZONE=ZONE
export HF_TOKEN=HUGGING_FACE_TOKEN
export IMAGE_NAME=REGION_NAME-docker.pkg.dev/PROJECT_ID/vllm-multihost/vllm-multihost:latest
```
Reemplaza los siguientes valores:
- PROJECT_ID: Es el Google Cloud ID de tu proyecto.
- CLUSTER_NAME: Es el nombre del clúster de GKE.
- ZONE: Es una zona que admite GPUs NVIDIA H100 Tensor Core.
- IMAGE_NAME: La imagen de vLLM que incluye la secuencia de comandos de Ray.

Crea un clúster de GKE

Puedes entregar modelos con vLLM en varios nodos de GPU 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

En Cloud Shell, ejecuta el siguiente comando:

  gcloud container clusters create-auto ${CLUSTER_NAME} \
    --project=${PROJECT_ID} \
    --region=${REGION} \
    --cluster-version=${CLUSTER_VERSION}

Estándar

Crea un clúster de GKE Standard con dos nodos de CPU:

gcloud container clusters create CLUSTER_NAME \
    --project=PROJECT_ID \
    --num-nodes=2 \
    --location=ZONE \
    --machine-type=e2-standard-16

Crea un grupo de nodos A3 con dos nodos, cada uno con ocho H100:

gcloud container node-pools create gpu-nodepool \
    --location=ZONE \
    --num-nodes=2 \
    --machine-type=a3-highgpu-8g \
    --accelerator=type=nvidia-h100-80gb,count=8,gpu-driver-version=LATEST \
    --placement-type=COMPACT \
    --cluster=CLUSTER_NAME

Configura `kubectl` para que se comunique con tu clúster

Configura kubectl para que se comunique con tu clúster con 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 Secret de Kubernetes que contenga el token de Hugging Face con el siguiente comando:

kubectl create secret generic hf-secret \
  --from-literal=hf_api_token=${HF_TOKEN} \
  --dry-run=client -o yaml | kubectl apply -f -

Crea tu propia imagen de vLLM de varios nodos

Para facilitar la comunicación entre nodos de vLLM, puedes usar Ray. El repositorio de LeaderWorkerSet proporciona un Dockerfile, que incluye una secuencia de comandos de Bash para configurar Ray con vLLM.

Para crear tu propia imagen de varios nodos de vLLM, debes clonar el repositorio de LeaderWorkerSet, compilar una imagen de Docker con el Dockerfile proporcionado (que configura Ray para la comunicación entre nodos) y, luego, enviar esa imagen a Artifact Registry para la implementación en GKE.

Compile el contenedor

Para compilar el contenedor, sigue estos pasos:

Clona el repositorio LeaderWorkerSet:

git clone https://github.com/kubernetes-sigs/lws.git

Compila la imagen.

cd lws/docs/examples/vllm/build/ && docker build -f Dockerfile.GPU . -t vllm-multihost

Envía la imagen al registro de Artifact Registry.

Para asegurarte de que tu implementación de Kubernetes pueda acceder a la imagen, almacénala en Artifact Registry dentro de tu Google Cloud proyecto.

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

Instala LeaderWorkerSet

Para instalar LWS, ejecuta el siguiente comando:

kubectl apply --server-side -f https://github.com/kubernetes-sigs/lws/releases/latest/download/manifests.yaml

Valida que el controlador LeaderWorkerSet se ejecute en el espacio de nombres lws-system con el siguiente comando:

kubectl get pod -n lws-system

El resultado es similar a este:

NAME                                      READY   STATUS    RESTARTS   AGE
lws-controller-manager-5c4ff67cbd-9jsfc   2/2     Running   0          6d23h

Implementa el servidor de modelos de vLLM

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

Aplica el manifiesto, según el LLM que quieras implementar.

DeepSeek-R1

Inspecciona el manifiesto vllm-deepseek-r1-A3.yaml.


apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
  name: vllm
spec:
  replicas: 1
  leaderWorkerTemplate:
    size: 2
    restartPolicy: RecreateGroupOnPodRestart
    leaderTemplate:
      metadata:
        labels:
          role: leader
      spec:
        nodeSelector:
          cloud.google.com/gke-accelerator: nvidia-h100-80gb
        containers:
          - name: vllm-leader
            image: IMAGE_NAME
            env:
              - name: HUGGING_FACE_HUB_TOKEN
                valueFrom:
                  secretKeyRef:
                    name: hf-secret
                    key: hf_api_token
            command:
              - sh
              - -c
              - "/vllm-workspace/ray_init.sh leader --ray_cluster_size=$(LWS_GROUP_SIZE); 
                python3 -m vllm.entrypoints.openai.api_server --port 8080 --model deepseek-ai/DeepSeek-R1 --tensor-parallel-size 8 --pipeline-parallel-size 2 --trust-remote-code --max-model-len 4096"
            resources:
              limits:
                nvidia.com/gpu: "8"
            ports:
              - containerPort: 8080
            readinessProbe:
              tcpSocket:
                port: 8080
              initialDelaySeconds: 15
              periodSeconds: 10
            volumeMounts:
              - mountPath: /dev/shm
                name: dshm
        volumes:
        - name: dshm
          emptyDir:
            medium: Memory
            sizeLimit: 15Gi
    workerTemplate:
      spec:
        nodeSelector:
          cloud.google.com/gke-accelerator: nvidia-h100-80gb
        containers:
          - name: vllm-worker
            image: IMAGE_NAME
            command:
              - sh
              - -c
              - "/vllm-workspace/ray_init.sh worker --ray_address=$(LWS_LEADER_ADDRESS)"
            resources:
              limits:
                nvidia.com/gpu: "8"
            env:
              - name: HUGGING_FACE_HUB_TOKEN
                valueFrom:
                  secretKeyRef:
                    name: hf-secret
                    key: hf_api_token
            volumeMounts:
              - mountPath: /dev/shm
                name: dshm   
        volumes:
        - name: dshm
          emptyDir:
            medium: Memory
            sizeLimit: 15Gi
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-leader
spec:
  ports:
    - name: http
      port: 8080
      protocol: TCP
      targetPort: 8080
  selector:
    leaderworkerset.sigs.k8s.io/name: vllm
    role: leader
  type: ClusterIP

Ejecuta el siguiente comando para aplicar el manifiesto:
```
kubectl apply -f vllm-deepseek-r1-A3.yaml
```

Llama 3.1 405b

Inspecciona el manifiesto vllm-llama3-405b-A3.yaml.


apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
  name: vllm
spec:
  replicas: 1
  leaderWorkerTemplate:
    size: 2
    restartPolicy: RecreateGroupOnPodRestart
    leaderTemplate:
      metadata:
        labels:
          role: leader
      spec:
        nodeSelector:
          cloud.google.com/gke-accelerator: nvidia-h100-80gb
        containers:
          - name: vllm-leader
            image: IMAGE_NAME
            env:
              - name: HUGGING_FACE_HUB_TOKEN
                valueFrom:
                  secretKeyRef:
                    name: hf-secret
                    key: hf_api_token
            command:
              - sh
              - -c
              - "/vllm-workspace/ray_init.sh leader --ray_cluster_size=$(LWS_GROUP_SIZE); 
                python3 -m vllm.entrypoints.openai.api_server --port 8080 --model meta-llama/Meta-Llama-3.1-405B-Instruct --tensor-parallel-size 8 --pipeline-parallel-size 2"
            resources:
              limits:
                nvidia.com/gpu: "8"
            ports:
              - containerPort: 8080
            readinessProbe:
              tcpSocket:
                port: 8080
              initialDelaySeconds: 15
              periodSeconds: 10
            volumeMounts:
              - mountPath: /dev/shm
                name: dshm
        volumes:
        - name: dshm
          emptyDir:
            medium: Memory
            sizeLimit: 15Gi
    workerTemplate:
      spec:
        nodeSelector:
          cloud.google.com/gke-accelerator: nvidia-h100-80gb
        containers:
          - name: vllm-worker
            image: IMAGE_NAME
            command:
              - sh
              - -c
              - "/vllm-workspace/ray_init.sh worker --ray_address=$(LWS_LEADER_ADDRESS)"
            resources:
              limits:
                nvidia.com/gpu: "8"
            env:
              - name: HUGGING_FACE_HUB_TOKEN
                valueFrom:
                  secretKeyRef:
                    name: hf-secret
                    key: hf_api_token
            volumeMounts:
              - mountPath: /dev/shm
                name: dshm   
        volumes:
        - name: dshm
          emptyDir:
            medium: Memory
            sizeLimit: 15Gi
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-leader
spec:
  ports:
    - name: http
      port: 8080
      protocol: TCP
      targetPort: 8080
  selector:
    leaderworkerset.sigs.k8s.io/name: vllm
    role: leader
  type: ClusterIP

Ejecuta el siguiente comando para aplicar el manifiesto:
```
kubectl apply -f vllm-llama3-405b-A3.yaml
```

Ejecuta el siguiente comando para ver los registros del servidor de modelos en ejecución:

kubectl logs vllm-0 -c vllm-leader

El resultado debería ser similar al siguiente:

INFO 08-09 21:01:34 api_server.py:297] Route: /detokenize, Methods: POST
INFO 08-09 21:01:34 api_server.py:297] Route: /v1/models, Methods: GET
INFO 08-09 21:01:34 api_server.py:297] Route: /version, Methods: GET
INFO 08-09 21:01:34 api_server.py:297] Route: /v1/chat/completions, Methods: POST
INFO 08-09 21:01:34 api_server.py:297] Route: /v1/completions, Methods: POST
INFO 08-09 21:01:34 api_server.py:297] Route: /v1/embeddings, Methods: POST
INFO:     Started server process [7428]
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 configurar la redirección de puertos al modelo:

kubectl port-forward svc/vllm-leader 8080:8080

Interactúa con el modelo con curl

Para interactuar con el modelo con curl, sigue estas instrucciones:

DeepSeek-R1

En una terminal nueva, envía una solicitud al servidor:

curl http://localhost:8080/v1/completions \
-H "Content-Type: application/json" \
-d '{
    "model": "deepseek-ai/DeepSeek-R1",
    "prompt": "I have four boxes. I put the red box on the bottom and put the blue box on top. Then I put the yellow box on top the blue. Then I take the blue box out and put it on top. And finally I put the green box on the top. Give me the final order of the boxes from bottom to top. Show your reasoning but be brief",
    "max_tokens": 1024,
    "temperature": 0
}'

El resultado debería ser similar al siguiente ejemplo:

{
"id": "cmpl-f2222b5589d947419f59f6e9fe24c5bd",
"object": "text_completion",
"created": 1738269669,
"model": "deepseek-ai/DeepSeek-R1",
"choices": [
  {
    "index": 0,
    "text": ".\n\nOkay, let's see. The user has four boxes and is moving them around. Let me try to visualize each step. \n\nFirst, the red box is placed on the bottom. So the stack starts with red. Then the blue box is put on top of red. Now the order is red (bottom), blue. Next, the yellow box is added on top of blue. So now it's red, blue, yellow. \n\nThen the user takes the blue box out. Wait, blue is in the middle. If they remove blue, the stack would be red and yellow. But where do they put the blue box? The instruction says to put it on top. So after removing blue, the stack is red, yellow. Then blue is placed on top, making it red, yellow, blue. \n\nFinally, the green box is added on the top. So the final order should be red (bottom), yellow, blue, green. Let me double-check each step to make sure I didn't mix up any steps. Starting with red, then blue, then yellow. Remove blue from the middle, so yellow is now on top of red. Then place blue on top of that, so red, yellow, blue. Then green on top. Yes, that seems right. The key step is removing the blue box from the middle, which leaves yellow on red, then blue goes back on top, followed by green. So the final order from bottom to top is red, yellow, blue, green.\n\n**Final Answer**\nThe final order from bottom to top is \\boxed{red}, \\boxed{yellow}, \\boxed{blue}, \\boxed{green}.\n</think>\n\n1. Start with the red box at the bottom.\n2. Place the blue box on top of the red box. Order: red (bottom), blue.\n3. Place the yellow box on top of the blue box. Order: red, blue, yellow.\n4. Remove the blue box (from the middle) and place it on top. Order: red, yellow, blue.\n5. Place the green box on top. Final order: red, yellow, blue, green.\n\n\\boxed{red}, \\boxed{yellow}, \\boxed{blue}, \\boxed{green}",
    "logprobs": null,
    "finish_reason": "stop",
    "stop_reason": null,
    "prompt_logprobs": null
  }
],
"usage": {
  "prompt_tokens": 76,
  "total_tokens": 544,
  "completion_tokens": 468,
  "prompt_tokens_details": null
}
}

Llama 3.1 405b

En una terminal nueva, envía una solicitud al servidor:

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

El resultado debería ser similar al siguiente ejemplo:

{"id":"cmpl-0a2310f30ac3454aa7f2c5bb6a292e6c",
"object":"text_completion","created":1723238375,"model":"meta-llama/Meta-Llama-3.1-405B-Instruct","choices":[{"index":0,"text":" top destination for foodies, with","logprobs":null,"finish_reason":"length","stop_reason":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 para usar 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:
    leaderworkerset.sigs.k8s.io/name: vllm
    role: leader
 endpoints:
 - path: /metrics
   port: 8080
   interval: 15s

Aplica el manifiesto al clúster:
```
kubectl apply -f vllm_pod_monitor.yaml
```

Crea carga en el extremo vLLM

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

Configura la redirección de puertos al modelo:

kubectl port-forward svc/vllm-leader 8080:8080

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:gpu_cache_usage_perc{cluster='CLUSTER_NAME'}
```

La siguiente imagen es un ejemplo de un gráfico después de la ejecución de la secuencia de comandos de carga. Este gráfico muestra que Google Cloud Managed Service para Prometheus transfiere las métricas de tráfico en respuesta a la carga que se agregó al extremo de vLLM:

Métricas de tráfico capturadas para el servidor vLLM

Implementa la configuración del escalador automático horizontal de Pods

Cuando decidas en qué métrica realizar el ajuste de escala automático, te recomendamos las siguientes métricas para 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 manera 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.

Te recomendamos que uses num_requests_waiting cuando realices optimizaciones para 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 GPUs.

Cuando seleccionas un objetivo averageValue para tu configuración de HPA, debes determinar experimentalmente en qué métrica realizar el ajuste de escala automático. Para obtener más ideas sobre cómo optimizar tus experimentos, 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. El comando profile-generator que se usa en esta entrada de blog también funciona para vLLM.

Para implementar la configuración del escalador automático horizontal de Pods con num_requests_waiting, sigue estos pasos:

Guarda el siguiente manifiesto como vllm-hpa.yaml:


apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: lws-hpa
spec:
  minReplicas: 1
  maxReplicas: 2
  metrics:
  - type: Pods
    pods:
      metric:
        name: prometheus.googleapis.com|vllm:num_requests_waiting|gauge
      target:
        type: AverageValue
        averageValue: 5
  scaleTargetRef:
    apiVersion: leaderworkerset.x-k8s.io/v1
    kind: LeaderWorkerSet
    name: vllm

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 GPU sensibles a la latencia.

Implementa la configuración del escalador automático horizontal de Pods:
```
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
lws-hpa   LeaderWorkerSet/vllm   0/1       1         2         1          6d1h
lws-hpa   LeaderWorkerSet/vllm   1/1       1         2         1          6d1h
lws-hpa   LeaderWorkerSet/vllm   0/1       1         2         1          6d1h
lws-hpa   LeaderWorkerSet/vllm   4/1       1         2         1          6d1h
lws-hpa   LeaderWorkerSet/vllm   0/1       1         2         2          6d1h

Acelera los tiempos de carga de modelos con Hyperdisk ML

Con estos tipos de LLM, el vLLM puede tardar una cantidad significativa de tiempo en descargarse, cargarse y prepararse en cada réplica nueva. Por ejemplo, ese proceso puede tardar alrededor de 90 minutos con Llama 3.1 405B. Puedes reducir este tiempo (a 20 minutos con Llama 3.1 405B) si descargas el modelo directamente en un volumen de Hyperdisk ML y lo activas en cada pod. Para completar esta operación, en este instructivo se usa un volumen de Hyperdisk ML y un trabajo de Kubernetes. Un controlador de trabajos en Kubernetes crea uno o más Pods y se asegura de que ejecuten correctamente una tarea específica.

Para acelerar los tiempos de carga del modelo, sigue estos pasos:

Guarda el siguiente manifiesto de ejemplo como producer-pvc.yaml:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: producer-pvc
spec:
  storageClassName: hyperdisk-ml
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 800Gi

Guarda el siguiente manifiesto de ejemplo como producer-job.yaml:

DeepSeek-R1


apiVersion: batch/v1
kind: Job
metadata:
  name: producer-job
spec:
  template:  # Template for the Pods the Job will create
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/machine-family
                operator: In
                values:
                - "c3"
            - matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values:
                - "ZONE"
      containers:
      - name: copy
        resources:
          requests:
            cpu: "32"
          limits:
            cpu: "32"
        image: python:3.11-alpine
        command:
        - sh
        - -c
        - "pip install 'huggingface_hub==0.24.6' && \
          huggingface-cli download deepseek-ai/DeepSeek-R1 --local-dir-use-symlinks=False --local-dir=/data/DeepSeek-R1 --include *.safetensors *.json *.py"
        env:
        - name: HUGGING_FACE_HUB_TOKEN
          valueFrom:
            secretKeyRef:
              name: hf-secret
              key: hf_api_token
        volumeMounts:
          - mountPath: "/data"
            name: volume
      restartPolicy: Never
      volumes:
        - name: volume
          persistentVolumeClaim:
            claimName: producer-pvc
  parallelism: 1         # Run 1 Pods concurrently
  completions: 1         # Once 1 Pods complete successfully, the Job is done
  backoffLimit: 4        # Max retries on failure

Llama 3.1 405b


apiVersion: batch/v1
kind: Job
metadata:
  name: producer-job
spec:
  template:  # Template for the Pods the Job will create
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/machine-family
                operator: In
                values:
                - "c3"
            - matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values:
                - "ZONE"
      containers:
      - name: copy
        resources:
          requests:
            cpu: "32"
          limits:
            cpu: "32"
        image: python:3.11-alpine
        command:
        - sh
        - -c
        - "pip install 'huggingface_hub==0.24.6' && \
          huggingface-cli download meta-llama/Meta-Llama-3.1-405B-Instruct --local-dir-use-symlinks=False --local-dir=/data/Meta-Llama-3.1-405B-Instruct --include *.safetensors *.json"
        env:
        - name: HUGGING_FACE_HUB_TOKEN
          valueFrom:
            secretKeyRef:
              name: hf-secret
              key: hf_api_token
        volumeMounts:
          - mountPath: "/data"
            name: volume
      restartPolicy: Never
      volumes:
        - name: volume
          persistentVolumeClaim:
            claimName: producer-pvc
  parallelism: 1         # Run 1 Pods concurrently
  completions: 1         # Once 1 Pods complete successfully, the Job is done
  backoffLimit: 4        # Max retries on failure

Sigue las instrucciones que se indican en Acelera la carga de datos de IA/AA con Hyperdisk ML y usa los dos archivos que creaste en los pasos anteriores.

Después de este paso, habrás creado y propagado el volumen de Hyperdisk de AA con los datos del modelo.

Implementa la implementación del servidor de GPU de varios nodos de vLLM, que usará el volumen de Hyperdisk de AA creado recientemente para los datos del modelo.

DeepSeek-R1



apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
  name: vllm
spec:
  replicas: 1
  leaderWorkerTemplate:
    size: 2
    restartPolicy: RecreateGroupOnPodRestart
    leaderTemplate:
      metadata:
        labels:
          role: leader
      spec:
        containers:
          - name: vllm-leader
            image: IMAGE_NAME
            env:
              - name: HUGGING_FACE_HUB_TOKEN
                valueFrom:
                  secretKeyRef:
                    name: hf-secret
                    key: hf_api_token
            command:
              - sh
              - -c
              - "/vllm-workspace/ray_init.sh leader --ray_cluster_size=$(LWS_GROUP_SIZE); 
                python3 -m vllm.entrypoints.openai.api_server --port 8080 --model /models/DeepSeek-R1 --tensor-parallel-size 8 --pipeline-parallel-size 2 --trust-remote-code --max-model-len 4096"
            resources:
              limits:
                nvidia.com/gpu: "8"
            ports:
              - containerPort: 8080
            readinessProbe:
              tcpSocket:
                port: 8080
              initialDelaySeconds: 15
              periodSeconds: 10
            volumeMounts:
              - mountPath: /dev/shm
                name: dshm
              - mountPath: /models
                name: deepseek-r1
        volumes:
        - name: dshm
          emptyDir:
            medium: Memory
        - name: deepseek-r1
          persistentVolumeClaim:
            claimName: hdml-static-pvc
    workerTemplate:
      spec:
        containers:
          - name: vllm-worker
            image: IMAGE_NAME
            command:
              - sh
              - -c
              - "/vllm-workspace/ray_init.sh worker --ray_address=$(LWS_LEADER_ADDRESS)"
            resources:
              limits:
                nvidia.com/gpu: "8"
            env:
              - name: HUGGING_FACE_HUB_TOKEN
                valueFrom:
                  secretKeyRef:
                    name: hf-secret
                    key: hf_api_token
            volumeMounts:
              - mountPath: /dev/shm
                name: dshm
              - mountPath: /models
                name: deepseek-r1
        volumes:
        - name: dshm
          emptyDir:
            medium: Memory
        - name: deepseek-r1
          persistentVolumeClaim:
            claimName: hdml-static-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-leader
spec:
  ports:
    - name: http
      port: 8080
      protocol: TCP
      targetPort: 8080
  selector:
    leaderworkerset.sigs.k8s.io/name: vllm
    role: leader
  type: ClusterIP

Llama 3.1 405b



apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
  name: vllm
spec:
  replicas: 1
  leaderWorkerTemplate:
    size: 2
    restartPolicy: RecreateGroupOnPodRestart
    leaderTemplate:
      metadata:
        labels:
          role: leader
      spec:
        containers:
          - name: vllm-leader
            image: IMAGE_NAME
            env:
              - name: HUGGING_FACE_HUB_TOKEN
                valueFrom:
                  secretKeyRef:
                    name: hf-secret
                    key: hf_api_token
            command:
              - sh
              - -c
              - "/vllm-workspace/ray_init.sh leader --ray_cluster_size=$(LWS_GROUP_SIZE); 
                python3 -m vllm.entrypoints.openai.api_server --port 8080 --model /models/Meta-Llama-3.1-405B-Instruct --tensor-parallel-size 8 --pipeline-parallel-size 2"
            resources:
              limits:
                nvidia.com/gpu: "8"
            ports:
              - containerPort: 8080
            readinessProbe:
              tcpSocket:
                port: 8080
              initialDelaySeconds: 15
              periodSeconds: 10
            volumeMounts:
              - mountPath: /dev/shm
                name: dshm
              - mountPath: /models
                name: llama3-405b
        volumes:
        - name: dshm
          emptyDir:
            medium: Memory
        - name: llama3-405b
          persistentVolumeClaim:
            claimName: hdml-static-pvc
    workerTemplate:
      spec:
        containers:
          - name: vllm-worker
            image: IMAGE_NAME
            command:
              - sh
              - -c
              - "/vllm-workspace/ray_init.sh worker --ray_address=$(LWS_LEADER_ADDRESS)"
            resources:
              limits:
                nvidia.com/gpu: "8"
            env:
              - name: HUGGING_FACE_HUB_TOKEN
                valueFrom:
                  secretKeyRef:
                    name: hf-secret
                    key: hf_api_token
            volumeMounts:
              - mountPath: /dev/shm
                name: dshm
              - mountPath: /models
                name: llama3-405b
        volumes:
        - name: dshm
          emptyDir:
            medium: Memory
        - name: llama3-405b
          persistentVolumeClaim:
            claimName: hdml-static-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-leader
spec:
  ports:
    - name: http
      port: 8080
      protocol: TCP
      targetPort: 8080
  selector:
    leaderworkerset.sigs.k8s.io/name: vllm
    role: leader
  type: ClusterIP

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 el siguiente comando:

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 GPU en GKE.
Explora el repositorio de GitHub y la documentación de vLLM.
Explora el repositorio de GitHub de LWS.

Publica LLM como DeepSeek-R1 671B o Llama 3.1 405B en GKE

Descripción general

Fondo

DeepSeek-R1

Llama 3.1 405b

Servicio de Kubernetes administrado de GKE

GPU

LeaderWorkerSet (LWS)

vLLM y entrega de varios hosts

Objetivos

Antes de comenzar

Check for the roles

Grant the roles

Obtén acceso al modelo

DeepSeek-R1

Genera un token de acceso

Llama 3.1 405b

Genera un token de acceso

Prepare el entorno

Crea 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

Crea tu propia imagen de vLLM de varios nodos

Compile el contenedor

Envía la imagen al registro de Artifact Registry.

Instala LeaderWorkerSet

Implementa el servidor de modelos de vLLM

DeepSeek-R1

Llama 3.1 405b

Entrega el modelo

Interactúa con el modelo con curl

DeepSeek-R1

Llama 3.1 405b

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 escalador automático horizontal de Pods

Acelera los tiempos de carga de modelos con Hyperdisk ML

DeepSeek-R1

Llama 3.1 405b

DeepSeek-R1

Llama 3.1 405b

Limpia

Borra los recursos implementados

¿Qué sigue?

Configura `kubectl` para que se comunique con tu clúster