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 basadas en LLM en GKE con GKE Inference Gateway.
Antes de leer esta página, familiarízate con lo siguiente:
- Acerca de la inferencia de modelos en GKE
- Ejecuta inferencias de prácticas recomendadas con recetas de guía de inicio rápido de GKE Inference
- Modo Autopilot y modo Standard
- GPUs en GKE
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. Las funciones clave incluyen 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.
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.
Firma el acuerdo de consentimiento de licencia
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_TOKENReemplaza 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-central1para 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
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-central1para 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=standardReemplaza 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-central1para 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 \GKE crea un grupo de nodos único que contiene una GPU H100.
Configura la autorización para recopilar métricas
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_LOCATIONReemplaza 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-token \ --from-literal=token=HF_TOKEN \ --dry-run=client -o yaml | kubectl apply -f -Reemplaza
HF_TOKENpor el token de Hugging Face que generaste antes.
Instala las CRD de InferenceObjective 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 InferenceObjective en tu clúster de GKE ejecutando el siguiente comando:
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.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.1-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 comovllm-llama3.1-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.1-8b-instruct spec: replicas: 3 selector: matchLabels: app: vllm-llama3.1-8b-instruct template: metadata: labels: app: vllm-llama3.1-8b-instruct spec: containers: - name: vllm # Versions of vllm after v0.8.5 have an issue due to an update in NVIDIA driver path. # The following workaround can be used until the fix is applied to the vllm release # BUG: https://github.com/vllm-project/vllm/issues/18859 image: "vllm/vllm-openai:latest" imagePullPolicy: Always command: ["sh", "-c"] args: - >- PATH=$PATH:/usr/local/nvidia/bin LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/nvidia/lib:/usr/local/nvidia/lib64 python3 -m vllm.entrypoints.openai.api_server --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: 600 # 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" # This is the second container in the Pod, a sidecar to the vLLM container. # It watches the ConfigMap and downloads LoRA adapters. - name: lora-adapter-syncer image: us-central1-docker.pkg.dev/k8s-staging-images/gateway-api-inference-extension/lora-syncer:main 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 10ms TPOT at a max # batch size around 50, or 100 tokens/sec) # 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 / 100 ~ 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 40% to the time from above (40s + # 16s = 56s) # # Thus we think it will take us at worst about 56s 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 to # stop sending us new requests (56s + 30s = 86s). # # 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 (86s * 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.1-8b-adapters --- apiVersion: v1 kind: ConfigMap metadata: name: vllm-llama3.1-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.k8s.io" kind: InferencePool name: vllm-llama3.1-8b-instruct default: config: type: HTTP httpHealthCheck: requestPath: /health port: 8000Aplica el manifiesto al clúster:
kubectl apply -f vllm-llama3.1-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 del modelo 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.1-8b-instruct \
--set inferencePool.modelServers.matchLabels.app=vllm-llama3.1-8b-instruct \
--set provider.name=gke \
--set healthCheckPolicy.create=false \
--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.
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 InferenceObjective con una criticidad de entrega
El recurso personalizado InferenceObjective define los parámetros de la publicación de un modelo, incluida su prioridad. Debes crear recursos InferenceObjective para definir qué modelos se publican en un InferencePool. Estos recursos pueden hacer referencia a modelos básicos o adaptadores de LoRA compatibles con los servidores de modelos en InferencePool.
El campo metadata.name especifica el nombre del modelo, el campo priority establece su criticidad de entrega y el campo poolRef vincula al InferencePool en el que se entrega el modelo.
Para crear un InferenceObjective, sigue estos pasos:
Guarda el siguiente manifiesto de muestra como
inferenceobjective.yaml:apiVersion: inference.networking.x-k8s.io/v1alpha2 kind: InferenceObjective metadata: name: MODEL_NAME spec: priority: VALUE poolRef: name: INFERENCE_POOL_NAME kind: "InferencePool"Reemplaza lo siguiente:
MODEL_NAME: Es el nombre de tu modelo base o adaptador de LoRA. Por ejemplo,food-reviewVALUE: 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,10INFERENCE_POOL_NAME: Es el nombre delInferencePoolque creaste en el paso anterior. Por ejemplo,vllm-llama3.1-8b-instruct.
Aplica el manifiesto de muestra a tu clúster:
kubectl apply -f inferenceobjective.yaml
En el siguiente ejemplo, se crean dos objetos InferenceObjective. El primero configura el modelo LoRA food-review en el InferencePool vllm-llama3.1-8b-instruct con una prioridad de 10. La segunda configura el llama3-base-model para que se publique con una prioridad más alta de 20.
apiVersion: inference.networking.k8s.io/v1alpha1
kind: InferenceObjective
metadata:
name: food-review
spec:
priority: 10
poolRef:
name: vllm-llama3.1-8b-instruct
kind: "InferencePool"
---
apiVersion: inference.networking.k8s.io/v1alpha1
kind: InferenceObjective
metadata:
name: llama3-base-model
spec:
priority: 20
poolRef:
name: vllm-llama3.1-8b-instruct
kind: "InferencePool"
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: httpReemplaza
GATEWAY_NAMEpor un nombre único para tu recurso de Gateway. Por ejemplo,inference-gatewayAplica 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.k8s.io kind: InferencePoolReemplaza lo siguiente:
HTTPROUTE_NAME: Es un nombre único para tu recursoHTTPRoute. Por ejemplo,my-route.GATEWAY_NAME: Es el nombre del recursoGatewayque 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 recursoInferencePoolal que deseas enrutar el tráfico. Por ejemplo,vllm-llama3.1-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
curlpara 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=80Reemplaza
GATEWAY_NAMEpor el nombre de tu recurso de Gateway.Para enviar una solicitud al extremo
/v1/completionsconcurl, ejecuta el siguiente comando:curl -i -X POST http://${IP}:${PORT}/v1/completions \ -H "Content-Type: application/json" \ -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 valor0para obtener un resultado determinístico o un número más alto para obtener un resultado más creativo.
Ten en cuenta lo siguiente:
- Cuerpo de la solicitud: El cuerpo de la solicitud puede incluir parámetros adicionales, como
stopytop_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
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.
¿Qué sigue?
- Obtén más información sobre GKE Inference Gateway.
- Lee sobre la implementación de la puerta de enlace de inferencia de GKE.