Implementa la puerta de enlace de inferencia de GKE

En esta página, se describe cómo implementar GKE Inference Gateway.

Esta página está dirigida a los especialistas en redes responsables de administrar la infraestructura de GKE y a los administradores de plataformas que administran cargas de trabajo de IA.

Antes de leer esta página, asegúrate de estar familiarizado con los siguientes temas:

GKE Inference Gateway mejora la puerta de enlace de Google Kubernetes Engine (GKE) para optimizar la entrega de aplicaciones y cargas de trabajo de IA generativa en GKE. Proporciona una administración y un escalamiento eficientes de las cargas de trabajo de IA, permite establecer objetivos de rendimiento específicos para cada carga de trabajo, como la latencia, y mejora la utilización de recursos, la observabilidad y la seguridad de la IA.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si quieres usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.

  • Habilita la API de Compute Engine, la API de Network Services y la API de Model Armor si es necesario.

    Ve a Habilita el acceso a las APIs y sigue las instrucciones.

  • Asegúrate de tener los siguientes roles en el proyecto: roles/container.admin, roles/iam.serviceAccountAdmin.

  • Asegúrate de que tu proyecto tenga la cuota suficiente para las GPU H100. Para obtener más información, consulta Planifica la cuota de GPU y Cuotas de asignación.

  • Crea una cuenta de Hugging Face si aún no tienes una. Lo necesitarás para acceder a los recursos del modelo de este instructivo.

  • Solicita acceso al modelo Llama 3.1 y genera un token de acceso. El acceso a este modelo requiere una solicitud aprobada en Hugging Face, y la implementación fallará si no se otorgó el acceso.

    • Firma el acuerdo de consentimiento de licencia: Debes firmar el acuerdo de consentimiento para usar el modelo de Llama 3.1. Ve a la página del modelo en Hugging Face, verifica tu cuenta y acepta las condiciones.
    • Genera un token de acceso: Para acceder al modelo, necesitas un token de Hugging Face. En tu cuenta de Hugging Face, ve a Tu perfil > Configuración > Tokens de acceso, crea un token nuevo con al menos permisos de lectura y cópialo en el portapapeles.

Requisitos del controlador de la puerta de enlace de GKE

  • GKE versión 1.32.3 o posterior.
  • Versión 407.0.0 o posterior de Google Cloud CLI.
  • La API de Gateway solo es compatible con los clústeres nativos de la VPC.
  • Debes habilitar una subred exclusiva de proxy.
  • El clúster debe tener el complemento HttpLoadBalancing habilitado.
  • Si usas Istio, debes actualizarlo a una de las siguientes versiones:
    • 1.15.2 o una versión posterior
    • 1.14.5 o una versión posterior
    • 1.13.9 o una versión posterior
  • Si usas una VPC compartida, en el proyecto host, debes asignar el rol Compute Network User a la cuenta de servicio de GKE para el proyecto de servicio.

Restricciones y limitaciones

Se aplican las siguientes restricciones y limitaciones:

  • No se admiten las puertas de enlace de varios clústeres.
  • La puerta de enlace de inferencia de GKE solo es compatible con los recursos de GatewayClass gke-l7-regional-external-managed y gke-l7-rilb.
  • No se admiten los balanceadores de cargas de aplicaciones internos entre regiones.

Matriz de compatibilidad

En la siguiente tabla, se describe la matriz de compatibilidad y asistencia para las definiciones de recursos personalizados (CRD) de la extensión de inferencia de la API de Gateway. Detalla qué versiones de CRD son compatibles con GKE en comparación con el proyecto de extensión de inferencia de la API de Gateway de código abierto (OSS), incluidos los requisitos de versión específicos y las notas de instalación.

Nombre del CRD Versión de la API de CRD Asistencia administrada de GKE Compatibilidad con OSS (extensión de inferencia de la API de Gateway)
InferencePool de la versión 1 inference.networking.k8s.io/v1 Es compatible con GKE 1.32.3 o versiones posteriores, y la CRD se instala de forma predeterminada en GKE 1.34.0-gke.1626000 o versiones posteriores. Compatible a partir de la versión 1.0.0 de la extensión de inferencia de la API de Gateway
InferencePool alfa (se recomienda que los usuarios comiencen con InferencePool v1, ya que la versión alfa de InferencePool dejó de estar disponible) inference.networking.x-k8s.io/v1alpha2 Es compatible con GKE 1.32.3 o versiones posteriores. Sin embargo, la CRD no se instala de forma predeterminada en GKE. Los usuarios deben instalar manualmente la CRD desde la extensión de inferencia de la API de Gateway. Compatible a partir de la extensión de inferencia de la API de Gateway v0.2.0
Alpha InferenceObjective inference.networking.x-k8s.io/v1alpha2 GKE no administra InferenceObjective Compatible a partir de la versión 1.0.0 de la extensión de inferencia de la API de Gateway
Modelo InferenceModel alfa (se recomienda usar usuarios que comiencen con InferenceObjective, ya que InferenceModel dejó de estar disponible) inference.networking.x-k8s.io/v1alpha2 GKE no administra InferenceModel Se admite a partir de la versión 0.2.0 de la extensión de inferencia de la API de Gateway.

Configura la puerta de enlace de GKE Inference

Para configurar la puerta de enlace de inferencia de GKE, considera este ejemplo. Un equipo ejecuta modelos de vLLM y Llama3, y experimenta de forma activa con dos adaptadores distintos ajustados con LoRA: "food-review" y "cad-fabricator".

El flujo de trabajo de alto nivel para configurar GKE Inference Gateway es el siguiente:

  1. Prepara tu entorno: Configura la infraestructura y los componentes necesarios.
  2. Crea un grupo de inferencia: Define un grupo de servidores de modelos con el recurso personalizado InferencePool.
  3. Especifica objetivos de inferencia: Especifica objetivos de inferencia con el recurso personalizado InferenceObjective
  4. Crea la puerta de enlace: Expón el servicio de inferencia con la API de Gateway.
  5. Crea el HTTPRoute: Define cómo se enruta el tráfico HTTP al servicio de inferencia.
  6. Envía solicitudes de inferencia: Realiza solicitudes al modelo implementado.

Prepara el entorno

  1. Instala Helm.

  2. Crea un clúster de GKE:

    • Crea un clúster de GKE Autopilot o Standard con la versión 1.32.3 o posterior. Para obtener instrucciones, consulta Crea un clúster de GKE.
    • Configura los nodos con la familia de procesamiento y el acelerador que prefieras.
    • Usa la Guía de inicio rápido de GKE Inference para obtener manifiestos de implementación preconfigurados y probados, según el acelerador, el modelo y las necesidades de rendimiento que selecciones.

  3. Instala las definiciones de recursos personalizados (CRD) necesarias en tu clúster de GKE:

    • Para las versiones de GKE anteriores a 1.34.0-gke.1626000, ejecuta el siguiente comando para instalar los CRD de v1 InferencePool y alfa InferenceObjective:
    kubectl apply -f  https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.0/experimental-manifests.yaml
    • Para las versiones de GKE 1.34.0-gke.1626000 o posteriores, instala solo la CRD InferenceObjective alfa ejecutando el siguiente comando:
    kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/raw/v1.0.0/config/crd/bases/inference.networking.x-k8s.io_inferenceobjectives.yaml

  4. Si usas una versión de GKE anterior a v1.32.2-gke.1182001 y deseas usar Model Armor con GKE Inference Gateway, debes instalar las CRD de extensión de tráfico y enrutamiento:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcptrafficextensions.yaml
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcproutingextensions.yaml

  5. Para configurar la autorización para extraer métricas, crea el secreto inference-gateway-sa-metrics-reader-secret:

    kubectl apply -f - <<EOF
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: inference-gateway-metrics-reader
rules:
- nonResourceURLs:
  - /metrics
  verbs:
  - get
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: inference-gateway-sa-metrics-reader
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: inference-gateway-sa-metrics-reader-role-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: inference-gateway-sa-metrics-reader
  namespace: default
roleRef:
  kind: ClusterRole
  name: inference-gateway-metrics-reader
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: Secret
metadata:
  name: inference-gateway-sa-metrics-reader-secret
  namespace: default
  annotations:
    kubernetes.io/service-account.name: inference-gateway-sa-metrics-reader
type: kubernetes.io/service-account-token
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: inference-gateway-sa-metrics-reader-secret-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["inference-gateway-sa-metrics-reader-secret"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gmp-system:collector:inference-gateway-sa-metrics-reader-secret-read
  namespace: default
roleRef:
  name: inference-gateway-sa-metrics-reader-secret-read
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gmp-system
  kind: ServiceAccount
EOF

Crea un servidor de modelos y una implementación de modelos

En esta sección, se muestra cómo implementar un servidor y un modelo. En el ejemplo, se usa un servidor de modelos vLLM con un modelo Llama3. La implementación se etiqueta como app:vllm-llama3-8b-instruct. Esta implementación también usa dos adaptadores de LoRA llamados food-review y cad-fabricator de Hugging Face.

Puedes adaptar este ejemplo con tu propio contenedor y modelo del servidor de modelos, puerto de entrega y nombre de implementación. También puedes configurar adaptadores de LoRA en la implementación o implementar el modelo base. En los siguientes pasos, se describe cómo crear los recursos de Kubernetes necesarios.

  1. Crea un Secret de Kubernetes para almacenar tu token de Hugging Face. Este token se usa para acceder al modelo base y a los adaptadores de LoRA:

    kubectl create secret generic hf-token --from-literal=token=HF_TOKEN

    Reemplaza HF_TOKEN por tu token de Hugging Face.

  2. Implementa el servidor y el modelo. El siguiente comando aplica un manifiesto que define una implementación de Kubernetes para un servidor de modelos vLLM con un modelo Llama3:

    kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/release-1.0/config/manifests/vllm/gpu-deployment.yaml

Crea un grupo de inferencia

El recurso personalizado de Kubernetes InferencePool define un grupo de Pods con un modelo de lenguaje grande (LLM) y una configuración de procesamiento base comunes. El campo selector especifica qué Pods pertenecen a este grupo. Las etiquetas de este selector deben coincidir exactamente con las etiquetas aplicadas a los Pods del servidor del modelo. El campo targetPort define los puertos que usa el servidor del modelo dentro de los Pods. El campo extensionRef hace referencia a un servicio de extensión que proporciona capacidad adicional para el grupo de inferencia. El InferencePool permite que la puerta de enlace de inferencia de GKE enrute el tráfico a los Pods de tu servidor de modelos.

Antes de crear el InferencePool, asegúrate de que los Pods que selecciona el InferencePool ya estén en ejecución.

Para crear un InferencePool con Helm, sigue estos pasos:

helm install vllm-llama3-8b-instruct \
  --set inferencePool.modelServers.matchLabels.app=vllm-llama3-8b-instruct \
  --set provider.name=gke \
  --version v1.0.0 \
  oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool

Cambia el siguiente campo para que coincida con tu Deployment:

  • inferencePool.modelServers.matchLabels.app: Es la clave de la etiqueta que se usa para seleccionar los Pods del servidor del modelo.

La instalación de Helm instala automáticamente la política de tiempo de espera, el selector de extremos y los Pods necesarios para la observabilidad.

Esto crea un objeto InferencePool: vllm-llama3-8b-instruct que hace referencia a los servicios de extremos del modelo dentro de los Pods. También crea una implementación del selector de extremos llamado app:vllm-llama3-8b-instruct-epp para este InferencePool creado.

Especifica los objetivos de la inferencia

El recurso personalizado InferenceObjective te permite especificar la prioridad de las solicitudes.

El campo metadata.name del recurso InferenceObjective especifica el nombre del objetivo de inferencia, el campo Priority especifica su criticidad de servicio y el campo poolRef especifica el InferencePool en el que se publica el modelo.

```yaml
apiVersion: inference.networking.k8s.io/v1alpha2
kind: InferenceObjective
metadata:
  name: NAME
spec:
  priority: VALUE
  poolRef:
    name: INFERENCE_POOL_NAME
    group: "inference.networking.k8s.io"
```

Reemplaza lo siguiente:

  • NAME: Es el nombre de tu objetivo de inferencia. Por ejemplo, food-review
  • VALUE: Es la prioridad del objetivo de inferencia. Es un número entero en el que un valor más alto indica una solicitud más crítica. Por ejemplo, 10.
  • INFERENCE_POOL_NAME: Es el nombre del InferencePool que creaste en el paso anterior. Por ejemplo, vllm-llama3-8b-instruct.

Para crear un InferenceObjective, sigue estos pasos:

  1. Guarda el siguiente manifiesto como inference-objectives.yaml. En este manifiesto, se crean dos recursos InferenceObjective. El primero configura el objetivo de inferencia food-review en el InferencePool vllm-llama3-8b-instruct con una prioridad de 10. La segunda configura el objetivo de inferencia llama3-base-model para que se publique con una prioridad más alta de 20.

    apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceObjective
metadata:
  name: food-review
spec:
  priority: 10
  poolRef:
    name: vllm-llama3-8b-instruct
    group: "inference.networking.k8s.io"
---
apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceObjective
metadata:
  name: llama3-base-model
spec:
  priority: 20 # Higher priority
  poolRef:
    name: vllm-llama3-8b-instruct

  2. Aplica el manifiesto de muestra a tu clúster:

    kubectl apply -f inferenceobjective.yaml

Crea la puerta de enlace

El recurso de Gateway es el punto de entrada para el tráfico externo en tu clúster de Kubernetes. Define los objetos de escucha que aceptan conexiones entrantes.

La puerta de enlace de inferencia de GKE funciona con las siguientes clases de puerta de enlace:

  • gke-l7-rilb: Para balanceadores de cargas de aplicaciones internos regionales.
  • gke-l7-regional-external-managed: Para balanceadores de cargas de aplicaciones externos regionales.

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

Para crear una puerta de enlace, sigue estos pasos:

  1. Guarda el siguiente manifiesto de muestra como gateway.yaml:

    apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: GATEWAY_NAME
spec:
  gatewayClassName: GATEWAY_CLASS
  listeners:
    - protocol: HTTP
      port: 80
      name: http

    Reemplaza lo siguiente:

    • GATEWAY_NAME: Es un nombre único para tu recurso de Gateway. Por ejemplo, inference-gateway
    • GATEWAY_CLASS: Es la clase de puerta de enlace que deseas usar. Por ejemplo, gke-l7-regional-external-managed

  2. Aplica el manifiesto al clúster:

    kubectl apply -f gateway.yaml

Nota: Para obtener más información sobre cómo configurar TLS para proteger tu puerta de enlace con HTTPS, consulta la documentación de GKE sobre la configuración de TLS.

Crea el HTTPRoute

El recurso HTTPRoute define cómo GKE Gateway enruta las solicitudes HTTP entrantes a los servicios de backend, como tu InferencePool. El recurso HTTPRoute especifica reglas de coincidencia (por ejemplo, encabezados o rutas de acceso) y el backend al que se debe reenviar el tráfico.

  1. Para crear un HTTPRoute, guarda el siguiente manifiesto de muestra como httproute.yaml:

    apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: HTTPROUTE_NAME
spec:
  parentRefs:
  - name: GATEWAY_NAME
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: PATH_PREFIX
    backendRefs:
    - name: INFERENCE_POOL_NAME
      group: "inference.networking.k8s.io"
      kind: InferencePool

    Reemplaza lo siguiente:

    • HTTPROUTE_NAME: Es un nombre único para tu recurso HTTPRoute. Por ejemplo, my-route.
    • GATEWAY_NAME: Es el nombre del recurso Gateway que creaste. Por ejemplo, inference-gateway.
    • PATH_PREFIX: Es el prefijo de ruta de acceso que usas para hacer coincidir las solicitudes entrantes. Por ejemplo, / para que coincida con todo.
    • INFERENCE_POOL_NAME: Es el nombre del recurso InferencePool al que deseas enrutar el tráfico. Por ejemplo, vllm-llama3-8b-instruct.

  2. Aplica el manifiesto al clúster:

    kubectl apply -f httproute.yaml

Envía la solicitud de inferencia

Después de configurar GKE Inference Gateway, puedes enviar solicitudes de inferencia a tu modelo implementado. Esto te permite generar texto en función de la instrucción de entrada y los parámetros especificados.

Para enviar solicitudes de inferencia, sigue estos pasos:

  1. Configura las siguientes variables de entorno:

    export GATEWAY_NAME=GATEWAY_NAME
export PORT_NUMBER=PORT_NUMBER # Use 80 for HTTP

    Reemplaza lo siguiente:

    • GATEWAY_NAME: Es el nombre de tu recurso de Gateway.
    • PORT_NUMBER: Es el número de puerto que configuraste en la puerta de enlace.

  2. Para obtener el extremo de la puerta de enlace, ejecuta el siguiente comando:

    echo "Waiting for the Gateway IP address..."
IP=""
while [ -z "$IP" ]; do
  IP=$(kubectl get gateway/${GATEWAY_NAME} -o jsonpath='{.status.addresses[0].value}' 2>/dev/null)
  if [ -z "$IP" ]; then
    echo "Gateway IP not found, waiting 5 seconds..."
    sleep 5
  fi
done

echo "Gateway IP address is: $IP"
PORT=${PORT_NUMBER}

  3. Para enviar una solicitud al extremo /v1/completions con curl, ejecuta el siguiente comando:

    curl -i -X POST ${IP}:${PORT}/v1/completions \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer $(gcloud auth application-default print-access-token)' \
-d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "TEMPERATURE"
}'

    Reemplaza lo siguiente:

    • MODEL_NAME: Es el nombre del modelo o del adaptador de LoRA que se usará.
    • PROMPT_TEXT: Es la instrucción de entrada para el modelo.
    • MAX_TOKENS: Es la cantidad máxima de tokens que se pueden generar en la respuesta.
    • TEMPERATURE: Controla la aleatoriedad del resultado. Usa el valor 0 para obtener un resultado determinístico o un número más alto para obtener un resultado más creativo.

En el siguiente ejemplo, se muestra cómo enviar una solicitud de muestra a la puerta de enlace de GKE Inference:

curl -i -X POST ${IP}:${PORT}/v1/completions -H 'Content-Type: application/json' -H 'Authorization: Bearer $(gcloud auth print-access-token)' -d '{
    "model": "food-review-1",
    "prompt": "What is the best pizza in the world?",
    "max_tokens": 2048,
    "temperature": "0"
}'

Ten en cuenta los siguientes comportamientos:

  • Cuerpo de la solicitud: El cuerpo de la solicitud puede incluir parámetros adicionales, como stop y top_p. Consulta la especificación de la API de OpenAI para obtener una lista completa de opciones.
  • Control de errores: Implementa manejo de errores adecuado en el código del cliente para controlar los posibles errores en la respuesta. Por ejemplo, verifica el código de estado HTTP en la respuesta curl. Por lo general, un código de estado que no es 200 indica un error.
  • Autenticación y autorización: Para las implementaciones de producción, protege tu extremo de API con mecanismos de autenticación y autorización. Incluye los encabezados adecuados (por ejemplo, Authorization) en tus solicitudes.

¿Qué sigue?