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:

• Acerca de GKE Inference Gateway
• Organización de IA/AA en GKE.
• Glosario de IA generativa
• Balanceo de cargas enGoogle Cloud, en especial cómo interactúan los balanceadores de cargas con GKE
• Extensiones de Service de GKE Para obtener más información, consulta la documentación del controlador de GKE Gateway.
• Personaliza el tráfico de GKE Gateway con extensiones de servicio.

La puerta de enlace de inferencia de GKE mejora la puerta de enlace de Google Kubernetes Engine (GKE) para optimizar la entrega de aplicaciones de IA generativa. La puerta de enlace de inferencia de GKE te permite optimizar la entrega de cargas de trabajo de IA generativa en GKE. Proporciona una administración y un escalamiento eficientes de las cargas de trabajo de IA, permite objetivos de rendimiento específicos de la 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 deseas 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.

Requisitos del controlador de la puerta de enlace de GKE

• Versión 1.32.3 de GKE
• 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 de solo 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.

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 los objetivos de la entrega del modelo: Especifica los objetivos del modelo con el recurso personalizado InferenceModel.
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.31 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 las recetas de la guía de inicio rápido de GKE Inference para ejecutar la inferencia según las prácticas recomendadas para obtener manifiestos de implementación preconfigurados y probados, según el acelerador, el modelo y las necesidades de rendimiento que selecciones.

3. Para instalar las definiciones de recursos personalizados (CRD) InferencePool y InferenceModel en tu clúster de GKE, ejecuta el siguiente comando:

   kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v0.3.0/manifests.yaml
   

   Reemplaza VERSION por la versión de las CRD que deseas instalar (por ejemplo, v0.3.0).

4. Si usas una versión de GKE anterior a la v1.32.2-gke.1182001 y deseas usar Model Armor con GKE Inference Gateway, debes instalar los CRD de la 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 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. Para realizar la implementación en un tipo de acelerador nvidia-h100-80gb, guarda el siguiente manifiesto como vllm-llama3-8b-instruct.yaml. En este manifiesto, se define una implementación de Kubernetes con tu modelo y servidor del modelo:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: vllm-llama3-8b-instruct
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: vllm-llama3-8b-instruct
     template:
       metadata:
         labels:
           app: vllm-llama3-8b-instruct
       spec:
         containers:
           - name: vllm
             image: "vllm/vllm-openai:latest"
             imagePullPolicy: Always
             command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]
             args:
             - "--model"
             - "meta-llama/Llama-3.1-8B-Instruct"
             - "--tensor-parallel-size"
             - "1"
             - "--port"
             - "8000"
             - "--enable-lora"
             - "--max-loras"
             - "2"
             - "--max-cpu-loras"
             - "12"
             env:
               # Enabling LoRA support temporarily disables automatic v1, we want to force it on
               # until 0.8.3 vLLM is released.
               - name: PORT
                 value: "8000"
               - name: HUGGING_FACE_HUB_TOKEN
                 valueFrom:
                   secretKeyRef:
                     name: hf-token
                     key: token
               - name: VLLM_ALLOW_RUNTIME_LORA_UPDATING
                 value: "true"
             ports:
               - containerPort: 8000
                 name: http
                 protocol: TCP
             lifecycle:
               preStop:
                 # vLLM stops accepting connections when it receives SIGTERM, so we need to sleep
                 # to give upstream gateways a chance to take us out of rotation. The time we wait
                 # is dependent on the time it takes for all upstreams to completely remove us from
                 # rotation. Older or simpler load balancers might take upwards of 30s, but we expect
                 # our deployment to run behind a modern gateway like Envoy which is designed to
                 # probe for readiness aggressively.
                 sleep:
                   # Upstream gateway probers for health should be set on a low period, such as 5s,
                   # and the shorter we can tighten that bound the faster that we release
                   # accelerators during controlled shutdowns. However, we should expect variance,
                   # as load balancers may have internal delays, and we don't want to drop requests
                   # normally, so we're often aiming to set this value to a p99 propagation latency
                   # of readiness -> load balancer taking backend out of rotation, not the average.
                   #
                   # This value is generally stable and must often be experimentally determined on
                   # for a given load balancer and health check period. We set the value here to
                   # the highest value we observe on a supported load balancer, and we recommend
                   # tuning this value down and verifying no requests are dropped.
                   #
                   # If this value is updated, be sure to update terminationGracePeriodSeconds.
                   #
                   seconds: 30
                 #
                 # IMPORTANT: preStop.sleep is beta as of Kubernetes 1.30 - for older versions
                 # replace with this exec action.
                 #exec:
                 #  command:
                 #  - /usr/bin/sleep
                 #  - 30
             livenessProbe:
               httpGet:
                 path: /health
                 port: http
                 scheme: HTTP
               # vLLM's health check is simple, so we can more aggressively probe it.  Liveness
               # check endpoints should always be suitable for aggressive probing.
               periodSeconds: 1
               successThreshold: 1
               # vLLM has a very simple health implementation, which means that any failure is
               # likely significant. However, any liveness triggered restart requires the very
               # large core model to be reloaded, and so we should bias towards ensuring the
               # server is definitely unhealthy vs immediately restarting. Use 5 attempts as
               # evidence of a serious problem.
               failureThreshold: 5
               timeoutSeconds: 1
             readinessProbe:
               httpGet:
                 path: /health
                 port: http
                 scheme: HTTP
               # vLLM's health check is simple, so we can more aggressively probe it.  Readiness
               # check endpoints should always be suitable for aggressive probing, but may be
               # slightly more expensive than readiness probes.
               periodSeconds: 1
               successThreshold: 1
               # vLLM has a very simple health implementation, which means that any failure is
               # likely significant,
               failureThreshold: 1
               timeoutSeconds: 1
             # We set a startup probe so that we don't begin directing traffic or checking
             # liveness to this instance until the model is loaded.
             startupProbe:
               # Failure threshold is when we believe startup will not happen at all, and is set
               # to the maximum possible time we believe loading a model will take. In our
               # default configuration we are downloading a model from HuggingFace, which may
               # take a long time, then the model must load into the accelerator. We choose
               # 10 minutes as a reasonable maximum startup time before giving up and attempting
               # to restart the pod.
               #
               # IMPORTANT: If the core model takes more than 10 minutes to load, pods will crash
               # loop forever. Be sure to set this appropriately.
               failureThreshold: 3600
               # Set delay to start low so that if the base model changes to something smaller
               # or an optimization is deployed, we don't wait unnecessarily.
               initialDelaySeconds: 2
               # As a startup probe, this stops running and so we can more aggressively probe
               # even a moderately complex startup - this is a very important workload.
               periodSeconds: 1
               httpGet:
                 # vLLM does not start the OpenAI server (and hence make /health available)
                 # until models are loaded. This may not be true for all model servers.
                 path: /health
                 port: http
                 scheme: HTTP
   
             resources:
               limits:
                 nvidia.com/gpu: 1
               requests:
                 nvidia.com/gpu: 1
             volumeMounts:
               - mountPath: /data
                 name: data
               - mountPath: /dev/shm
                 name: shm
               - name: adapters
                 mountPath: "/adapters"
         initContainers:
           - name: lora-adapter-syncer
             tty: true
             stdin: true
             image: us-central1-docker.pkg.dev/k8s-staging-images/gateway-api-inference-extension/lora-syncer:main
             restartPolicy: Always
             imagePullPolicy: Always
             env:
               - name: DYNAMIC_LORA_ROLLOUT_CONFIG
                 value: "/config/configmap.yaml"
             volumeMounts: # DO NOT USE subPath, dynamic configmap updates don't work on subPaths
             - name: config-volume
               mountPath:  /config
         restartPolicy: Always
   
         # vLLM allows VLLM_PORT to be specified as an environment variable, but a user might
         # create a 'vllm' service in their namespace. That auto-injects VLLM_PORT in docker
         # compatible form as `tcp://<IP>:<PORT>` instead of the numeric value vLLM accepts
         # causing CrashLoopBackoff. Set service environment injection off by default.
         enableServiceLinks: false
   
         # Generally, the termination grace period needs to last longer than the slowest request
         # we expect to serve plus any extra time spent waiting for load balancers to take the
         # model server out of rotation.
         #
         # An easy starting point is the p99 or max request latency measured for your workload,
         # although LLM request latencies vary significantly if clients send longer inputs or
         # trigger longer outputs. Since steady state p99 will be higher than the latency
         # to drain a server, you may wish to slightly this value either experimentally or
         # via the calculation below.
         #
         # For most models you can derive an upper bound for the maximum drain latency as
         # follows:
         #
         #   1. Identify the maximum context length the model was trained on, or the maximum
         #      allowed length of output tokens configured on vLLM (llama2-7b was trained to
         #      4k context length, while llama3-8b was trained to 128k).
         #   2. Output tokens are the more compute intensive to calculate and the accelerator
         #      will have a maximum concurrency (batch size) - the time per output token at
         #      maximum batch with no prompt tokens being processed is the slowest an output
         #      token can be generated (for this model it would be about 100ms TPOT at a max
         #      batch size around 50)
         #   3. Calculate the worst case request duration if a request starts immediately
         #      before the server stops accepting new connections - generally when it receives
         #      SIGTERM (for this model that is about 4096 / 10 ~ 40s)
         #   4. If there are any requests generating prompt tokens that will delay when those
         #      output tokens start, and prompt token generation is roughly 6x faster than
         #      compute-bound output token generation, so add 20% to the time from above (40s +
         #      16s ~ 55s)
         #
         # Thus we think it will take us at worst about 55s to complete the longest possible
         # request the model is likely to receive at maximum concurrency (highest latency)
         # once requests stop being sent.
         #
         # NOTE: This number will be lower than steady state p99 latency since we stop receiving
         #       new requests which require continuous prompt token computation.
         # NOTE: The max timeout for backend connections from gateway to model servers should
         #       be configured based on steady state p99 latency, not drain p99 latency
         #
         #   5. Add the time the pod takes in its preStop hook to allow the load balancers have
         #      stopped sending us new requests (55s + 30s ~ 85s)
         #
         # Because termination grace period controls when the Kubelet forcibly terminates a
         # stuck or hung process (a possibility due to a GPU crash), there is operational safety
         # in keeping the value roughly proportional to the time to finish serving. There is also
         # value in adding a bit of extra time to deal with unexpectedly long workloads.
         #
         #   6. Add a 50% safety buffer to this time since the operational impact should be low
         #      (85s * 1.5 ~ 130s)
         #
         # One additional source of drain latency is that some workloads may run close to
         # saturation and have queued requests on each server. Since traffic in excess of the
         # max sustainable QPS will result in timeouts as the queues grow, we assume that failure
         # to drain in time due to excess queues at the time of shutdown is an expected failure
         # mode of server overload. If your workload occasionally experiences high queue depths
         # due to periodic traffic, consider increasing the safety margin above to account for
         # time to drain queued requests.
         terminationGracePeriodSeconds: 130
         nodeSelector:
           cloud.google.com/gke-accelerator: "nvidia-h100-80gb"
         volumes:
           - name: data
             emptyDir: {}
           - name: shm
             emptyDir:
               medium: Memory
           - name: adapters
             emptyDir: {}
           - name: config-volume
             configMap:
               name: vllm-llama3-8b-adapters
   ---
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: vllm-llama3-8b-adapters
   data:
     configmap.yaml: |
         vLLMLoRAConfig:
           name: vllm-llama3.1-8b-instruct
           port: 8000
           defaultBaseModel: meta-llama/Llama-3.1-8B-Instruct
           ensureExist:
             models:
             - id: food-review
               source: Kawon/llama3.1-food-finetune_v14_r8
             - id: cad-fabricator
               source: redcathode/fabricator
   ---
   kind: HealthCheckPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: health-check-policy
     namespace: default
   spec:
     targetRef:
       group: "inference.networking.x-k8s.io"
       kind: InferencePool
       name: vllm-llama3-8b-instruct
     default:
       config:
         type: HTTP
         httpHealthCheck:
             requestPath: /health
             port: 8000
   

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

   kubectl apply -f vllm-llama3-8b-instruct.yaml
   

Después de aplicar el manifiesto, ten en cuenta los siguientes campos y parámetros clave:

• replicas: Especifica la cantidad de Pods para la Deployment.
• image: Especifica la imagen de Docker para el servidor del modelo.
• command: Especifica el comando que se ejecutará cuando se inicie el contenedor.
• args: Especifica los argumentos que se pasarán al comando.
• env: Especifica variables de entorno para el contenedor.
• ports: Especifica los puertos expuestos por el contenedor.
• resources: Especifica las solicitudes y los límites de recursos para el contenedor, como la GPU.
• volumeMounts: Especifica cómo se activan los volúmenes en el contenedor.
• initContainers: Especifica los contenedores que se ejecutan antes del contenedor de la aplicación.
• restartPolicy: Especifica la política de reinicio de los Pods.
• terminationGracePeriodSeconds: Especifica el período de gracia para la finalización del Pod.
• volumes: Especifica los volúmenes que usan los Pods.

Puedes modificar estos campos para que coincidan con tus requisitos específicos.

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 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 v0.3.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 publicación del modelo

El recurso personalizado InferenceModel define un modelo específico que se publicará y que incluye compatibilidad con los modelos ajustados con LoRA y su criticidad de publicación. Debes definir qué modelos se publican en un InferencePool creando recursos InferenceModel. Estos recursos InferenceModel pueden hacer referencia a modelos básicos o a adaptadores de LoRA compatibles con los servidores de modelos en InferencePool.

El campo modelName especifica el nombre del modelo base o del adaptador de LoRA. El campo Criticality especifica la importancia de la publicación del modelo. El campo poolRef especifica el InferencePool en el que se publica este modelo.

Para crear un InferenceModel, sigue estos pasos:

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

   apiVersion: inference.networking.x-k8s.io/v1alpha2
   kind: InferenceModel
   metadata:
     name: inferencemodel-sample
   spec:
     modelName: MODEL_NAME
     criticality: VALUE
     poolRef:
       name: INFERENCE_POOL_NAME
   

   Reemplaza lo siguiente:

   • MODEL_NAME: Es el nombre de tu modelo base o adaptador de LoRA. Por ejemplo, food-review
   • VALUE: Es la criticidad de la publicación elegida. Elige entre Critical, Standard o Sheddable. Por ejemplo: Standard.
   • INFERENCE_POOL_NAME: Es el nombre del InferencePool que creaste en el paso anterior. Por ejemplo, vllm-llama3-8b-instruct.

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

   kubectl apply -f inferencemodel.yaml
   

En el siguiente ejemplo, se crea un objeto InferenceModel que configura el modelo LoRA food-review en el vllm-llama3-8b-instruct InferencePool con una criticidad de servicio Standard. El objeto InferenceModel también configura el modelo base para que se publique con un nivel de prioridad Critical.

apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceModel
metadata:
  name: food-review
spec:
  modelName: food-review
  criticality: Standard
  poolRef:
    name: vllm-llama3-8b-instruct
  targetModels:
  - name: food-review
    weight: 100

---
apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceModel
metadata:
  name: llama3-base-model
spec:
  modelName: meta-llama/Llama-3.1-8B-Instruct
  criticality: Critical
  poolRef:
    name: vllm-llama3-8b-instruct

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 GKE Inference funciona con las siguientes clases de Gateway:

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

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 GATEWAY_NAME por un nombre único para tu recurso de Gateway (por ejemplo, inference-gateway) y GATEWAY_CLASS por la clase de Gateway 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, que, en este contexto, serían tus 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.x-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. Para obtener el extremo de la puerta de enlace, ejecuta el siguiente comando:

   IP=$(kubectl get gateway/GATEWAY_NAME -o jsonpath='{.status.addresses[0].value}')
   PORT=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 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 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",
    "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?

• Personaliza la configuración de la puerta de enlace de inferencia de GKE
• Entrega un LLM con GKE Inference Gateway