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

Entrega un LLM con la puerta de enlace de inferencia de GKE

Autopilot estándar

En este instructivo, se describe cómo implementar un modelo de lenguaje grande (LLM) en Google Kubernetes Engine (GKE) con la puerta de enlace de inferencia de GKE. El instructivo incluye pasos para configurar el clúster, implementar el modelo, configurar la puerta de enlace de GKE Inference y controlar las solicitudes del LLM.

Este instructivo está dirigido a ingenieros de aprendizaje automático (AA), administradores y operadores de plataformas, y especialistas en IA y datos que deseen implementar y administrar aplicaciones de LLM con LLM en GKE con la puerta de enlace de inferencia de GKE.

Antes de leer esta página, familiarízate con lo siguiente:

Fondo

En esta sección, se describen las tecnologías clave que se usan en este instructivo. Para obtener más información sobre los conceptos y la terminología de la entrega de modelos, y cómo las capacidades de IA generativa de GKE pueden mejorar y respaldar el rendimiento de la entrega de modelos, consulta Acerca de la inferencia de modelos en GKE.

vLLM

vLLM es un framework de entrega de LLM de código abierto altamente optimizado que aumenta 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 que mejora la capacidad de procesamiento general de la entrega
Paralelismo de tensor y entrega distribuida en varias GPUs

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

Puerta de enlace de inferencia de GKE

La puerta de enlace de inferencia de GKE mejora las capacidades de GKE para entregar LLMs. Optimiza las cargas de trabajo de inferencia con funciones como las siguientes:

Balanceo de cargas optimizado para la inferencia basado en métricas de carga.
Se agregó compatibilidad con la entrega densa de múltiples cargas de trabajo de adaptadores de LoRA.
Enrutamiento que tiene en cuenta el modelo para simplificar las operaciones.

Para obtener más información, consulta Acerca de GKE Inference Gateway.

Objetivos

Obtén acceso al modelo.
Prepara el entorno.
Crea y configura Google Cloud recursos.
Instala las CRD de InferenceModel y InferencePool.
Implementa el servidor de modelos.
Configura la observabilidad para tu puerta de enlace de inferencia.

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

Verify 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

Verify 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

Check for the roles

In the Google Cloud console, go to the IAM page.
Go to IAM
Select the project.
In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.
For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.

Grant the roles

In the Google Cloud console, go to the IAM page.
Ir a IAM
Selecciona el proyecto.
Haz clic en Otorgar acceso.
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.
En la lista Seleccionar un rol, elige uno.
Para otorgar roles adicionales, haz clic en Agregar otro rol y agrega uno más.
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 GPU H100. Para obtener más información, consulta Planifica la cuota de GPU y Cuotas de asignación.

Obtén acceso al modelo

Para implementar el modelo Llama3.1 en GKE, firma el acuerdo de consentimiento de licencia y genera un token de acceso de Hugging Face.

Debes firmar el acuerdo de consentimiento para usar el modelo Llama3.1. Sigue estas instrucciones:

Accede a la página de consentimiento y verifica el consentimiento para usar tu cuenta de Hugging Face.
Acepta los términos del modelo.

Genera un token de acceso

Para acceder al modelo a través de Hugging Face, necesitas un token de Hugging Face.

Sigue estos pasos para generar un token nuevo si aún no tienes uno:

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.
Copia el token generado al portapapeles.

Prepara el entorno

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

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

En la Google Cloud consola, haz clic en Activar Cloud Shell en la Google Cloud consola 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
gcloud config set billing/quota_project PROJECT_ID
export PROJECT_ID=$(gcloud config get project)
export REGION=REGION
export CLUSTER_NAME=CLUSTER_NAME
export HF_TOKEN=HF_TOKEN
```
Reemplaza los siguientes valores:
- PROJECT_ID: Tu Google Cloud ID del proyecto.
- REGION: Una región que admita el tipo de acelerador que deseas usar, por ejemplo, us-central1 para la GPU H100.
- CLUSTER_NAME: El nombre de tu clúster.
- HF_TOKEN: El token de Hugging Face que generaste antes.

Crea y configura recursos de Google Cloud

Para crear los recursos necesarios, sigue estas instrucciones.

Crea un clúster de GKE y un grupo de nodos

Entrega LLMs en GPUs 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, ejecute el siguiente comando:

gcloud container clusters create-auto CLUSTER_NAME \
    --project=PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --release-channel=rapid

Reemplaza los siguientes valores:

PROJECT_ID: Tu Google Cloud ID del proyecto.
CONTROL_PLANE_LOCATION: La región de Compute Engine del plano de control de tu clúster. Proporciona una región que admita el tipo de acelerador que deseas usar, por ejemplo, us-central1 para la GPU H100.
CLUSTER_NAME: El nombre de tu clúster.

GKE crea un clúster de Autopilot con nodos de CPU y GPU según lo solicitan las cargas de trabajo implementadas.

Estándar

En Cloud Shell, ejecuta el siguiente comando para crear un clúster estándar:
```
gcloud container clusters create CLUSTER_NAME \
    --project=PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --release-channel=rapid \
    --num-nodes=1 \
    --enable-managed-prometheus \
    --monitoring=SYSTEM,DCGM \
    --gateway-api=standard
```
Reemplaza los siguientes valores:
- PROJECT_ID: Tu Google Cloud ID del proyecto.
- CONTROL_PLANE_LOCATION: La región de Compute Engine del plano de control de tu clúster. Proporciona una región que admita el tipo de acelerador que deseas usar, por ejemplo, us-central1 para la GPU H100.
- CLUSTER_NAME: El nombre de tu clúster.
La creación del clúster puede tomar varios minutos.

Para crear un grupo de nodos con el tamaño de disco adecuado para ejecutar el modelo Llama-3.1-8B-Instruct, ejecuta el siguiente comando:

gcloud container node-pools create gpupool \
    --accelerator type=nvidia-h100-80gb,count=2,gpu-driver-version=latest \
    --project=PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --node-locations=CONTROL_PLANE_LOCATION-a \
    --cluster=CLUSTER_NAME \
    --machine-type=a3-highgpu-2g \
    --num-nodes=1 \
    --disk-type="pd-standard"

GKE crea un grupo de nodos único que contiene una GPU H100.

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 secreto de Kubernetes para las credenciales de Hugging Face

En Cloud Shell, haz lo siguiente:

Para comunicarte con tu clúster, configura kubectl:
```
  gcloud container clusters get-credentials CLUSTER_NAME \
      --location=CONTROL_PLANE_LOCATION
```
Reemplaza los siguientes valores:
- CONTROL_PLANE_LOCATION: La región de Compute Engine del plano de control de tu clúster.
- CLUSTER_NAME: El nombre de tu clúster.
Crea un Secret de Kubernetes que contenga el token de Hugging Face:
```
  kubectl create secret generic HF_SECRET \
      --from-literal=token=HF_TOKEN \
      --dry-run=client -o yaml | kubectl apply -f -
```
Reemplaza lo siguiente:
- HF_TOKEN: El token de Hugging Face que generaste antes.
- HF_SECRET: Es el nombre de tu Secret de Kubernetes. Por ejemplo, hf-secret

Instala las CRD de `InferenceModel` y `InferencePool`

En esta sección, instalarás las definiciones de recursos personalizados (CRD) necesarias para la puerta de enlace de inferencia de GKE.

Los CRD extienden la API de Kubernetes. Esto te permite definir nuevos tipos de recursos. Para usar la puerta de enlace de inferencia de GKE, instala los CRD InferencePool y InferenceModel en tu clúster de GKE ejecutando el siguiente comando:

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

Implementa el servidor de modelos

En este ejemplo, se implementa un modelo Llama3.1 con un servidor de modelos vLLM. 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 actualizar esta implementación con tu propio servidor de modelos y contenedor de modelos, puerto de entrega y nombre de implementación. De manera opcional, puedes configurar adaptadores LoRA en la implementación o implementar el modelo base.

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: VLLM_USE_V1
              value: "1"
            - 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 the 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

Aplica el manifiesto al clúster:

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

Crea un recurso `InferencePool`

El recurso personalizado de Kubernetes InferencePool define un grupo de Pods con un LLM base y una configuración de procesamiento comunes.

El recurso personalizado InferencePool incluye los siguientes campos clave:

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.
targetPort: Define los puertos que usa el servidor de modelos dentro de los Pods.

El recurso InferencePool permite que GKE Inference Gateway enrute el tráfico a los Pods del servidor de modelos.

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 \
  --set healthCheckPolicy.create=false \
  --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.

Este comando crea un objeto InferencePool que representa de forma lógica la implementación del servidor de modelos y hace referencia a los servicios de extremos del modelo dentro de los Pods que selecciona Selector.

Crea un recurso `InferenceModel` con una criticidad de entrega

El recurso personalizado de Kubernetes InferenceModel define un modelo específico, incluidos los modelos ajustados con LoRA, y su criticidad de servicio.

El recurso personalizado InferenceModel incluye los siguientes campos clave:

modelName: Especifica el nombre del modelo base o del adaptador de LoRA.
Criticality: Especifica la criticidad de la publicación del modelo.
poolRef: Hace referencia al InferencePool en el que se publica el modelo.

InferenceModel permite que la puerta de enlace de GKE Inference enrute el tráfico a los Pods del servidor del modelo según el nombre y la criticidad del modelo.

Para crear un InferenceModel, sigue estos pasos:

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: CRITICALITY
  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
- CRITICALITY: Es la criticidad de 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.
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 Gateway actúa como punto de entrada para el tráfico externo en tu clúster de Kubernetes. Define los objetos de escucha que aceptan conexiones entrantes.

GKE Inference Gateway admite las clases de Gateway gke-l7-rilb y gke-l7-regional-external-managed. Para obtener más información, consulta la documentación de GKE sobre las clases de Gateway.

Para crear una puerta de enlace, sigue estos pasos:

Guarda el siguiente manifiesto de muestra como gateway.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: GATEWAY_NAME
spec:
  gatewayClassName: gke-l7-regional-external-managed
  listeners:
    - protocol: HTTP # Or HTTPS for production
      port: 80 # Or 443 for HTTPS
      name: http

Reemplaza GATEWAY_NAME por un nombre único para tu recurso de Gateway. Por ejemplo, inference-gateway

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

Crea el recurso `HTTPRoute`

En esta sección, crearás un recurso HTTPRoute para definir cómo la puerta de enlace enruta las solicitudes HTTP entrantes a tu InferencePool.

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

Para crear una HTTPRoute, sigue estos pasos:

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.
Aplica el manifiesto al clúster:
```
kubectl apply -f httproute.yaml
```

Envía una solicitud de inferencia

Después de configurar la puerta de enlace de inferencia de GKE, puedes enviar solicitudes de inferencia a tu modelo implementado.

Para enviar solicitudes de inferencia, sigue estos pasos:

Recupera el extremo de la puerta de enlace.
Construye una solicitud JSON con el formato adecuado.
Usa curl para enviar la solicitud al extremo /v1/completions.

Esto te permite generar texto según la instrucción de entrada y los parámetros especificados.

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 443 for HTTPS, or 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.
Para enviar una solicitud al extremo /v1/completions con curl, ejecuta el siguiente comando:
```
curl -i -X POST https://${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.

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.

Configura la observabilidad para tu puerta de enlace de inferencia

La puerta de enlace de inferencia de GKE proporciona observabilidad del estado, el rendimiento y el comportamiento de tus cargas de trabajo de inferencia. Esto te ayuda a identificar y resolver problemas, optimizar el uso de recursos y garantizar la confiabilidad de tus aplicaciones. Puedes ver estas métricas de observabilidad en Cloud Monitoring a través del Explorador de métricas.

Para configurar la observabilidad de GKE Inference Gateway, consulta Configura la observabilidad.

Borra los recursos implementados

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos que creaste a partir de esta guía, ejecuta el siguiente comando:

gcloud container clusters delete CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION