Usa el enrutamiento basado en la latencia prevista con GKE Inference Gateway

En este documento, se describe cómo habilitar y usar el enrutamiento basado en la latencia prevista que proporciona llm-d dentro de GKE Inference Gateway. De forma predeterminada, GKE Inference Gateway enruta las solicitudes con una combinación de indicadores de carga y heurísticas de afinidad de caché de prefijo. El enrutamiento basado en la latencia prevista reemplaza los pesos heurísticos estáticos con un modelo XGBoost entrenado de forma continua en el tráfico en vivo, lo que permite tomar decisiones de enrutamiento más precisas a medida que cambian los patrones de carga de trabajo.

Cuándo usar el enrutamiento basado en la latencia prevista

Esta función es más eficaz cuando se cumplen las siguientes condiciones para tu carga de trabajo:

• Alta varianza en la longitud de la instrucción y la finalización: La profundidad de la cola por sí sola es un proxy deficiente para la carga del servidor cuando los tamaños de las solicitudes varían de manera significativa. El predictor de latencia tiene en cuenta el costo real de relleno previo y decodificación por solicitud.
• SLO de latencia por solicitud: Cuando tus aplicaciones especifican objetivos de tiempo hasta el primer token (TTFT) o tiempo por token de salida (TPOT) en solicitudes individuales, el programador aplica estos objetivos durante el enrutamiento. Para ello, calcula el margen (latencia prevista menos el objetivo de SLO) para cada Pod candidato.
• Ajuste de peso estático frágil: Si vuelves a ajustar con frecuencia el equilibrio entre la afinidad de caché y los indicadores de carga a medida que cambian los patrones de tráfico, el modelo entrenado en línea se adapta automáticamente.

Cómo funciona el enrutamiento basado en la latencia prevista

En esta sección, se detallan la arquitectura y la canalización de programación que usa el enrutamiento basado en la latencia prevista.

Arquitectura

La programación basada en la latencia prevista implementa dos contenedores de sidecar adicionales dentro del Pod de EPP, junto con el propio EPP:

Canalización de programación de EPP de llm-d

Cuando se habilita la programación basada en la latencia prevista, el EPP procesa cada solicitud a través de la siguiente secuencia de complementos componibles:

1. predicted-latency-producer: Llama al servidor de predicción para obtener estimaciones de TTFT y TPOT para cada Pod candidato en el InferencePool, según el uso actual de la caché de KV, la profundidad de la cola, la puntuación de coincidencia de la caché de prefijo y las funciones de solicitud entrantes de cada Pod. Después de que se devuelve la respuesta al cliente, el productor envía el TTFT observado y la latencia entre tokens de vuelta al servidor de entrenamiento como una nueva muestra de entrenamiento.

   • Comportamiento de resguardo: Si no se puede acceder al servidor de predicción o devuelve un error, el EPP recurre automáticamente a una puntuación compuesta basada en el uso de la caché de KV, la profundidad de la cola y la coincidencia de la caché de prefijo.

2. prefix-cache-affinity-filter: Este filtro reduce el conjunto de candidatos a los Pods con caché activa cuando la puntuación de coincidencia de la caché de prefijo de cualquier Pod supera el umbral de afinidad (el valor predeterminado es 0.80). Este umbral separa dos poblaciones observadas en la producción: los Pods que ya tienen un historial de conversaciones almacenado en caché de turnos anteriores y los Pods que no lo tienen. Este filtro implementa una estrategia de exploración y explotación codiciosa de epsilon:

   • Explotación (ruta de acceso predeterminada): Esta ruta de acceso se enruta a los Pods con caché activa para que la puntuación concentre la reutilización de la caché en ellos.

   • Exploración (probabilidad pequeña): Esta ruta de acceso omite el filtro por completo en una fracción configurable de solicitudes para propagar entradas de caché en Pods inactivos para evitar la fragmentación de la caché.

   • Puerta de carga de TTFT: Incluso en la ruta de acceso de explotación, si el TTFT previsto del mejor Pod con caché activa supera el TTFT del mejor Pod general en más de un umbral configurable (el valor predeterminado es de 5,000 ms), se interrumpe la afinidad y se usa el conjunto completo de candidatos.

3. slo-headroom-tier-filter (solo solicitudes de SLO): Cuando la solicitud incluye encabezados de SLO, divide los Pods candidatos en un nivel positivo (se prevé que cumplan con el SLO) y un nivel negativo (se prevé que lo infrinjan).

4. latency-scorer: Puntúa los Pods candidatos. Sin encabezados de SLO, se selecciona el Pod con la latencia prevista más baja. Con encabezados de SLO, la puntuación se basa en el margen (SLO menos la latencia prevista) con headroomSelectionStrategy:

   • least (predeterminado): Agrupación. Se enruta al Pod con el margen positivo más pequeño, lo que maximiza el uso y mantiene los Pods menos cargados libres para futuras ráfagas de tráfico.
   • most: Distribución. Se enruta al Pod con el margen positivo más grande, lo que deja más margen para los picos de carga inesperados.

5. latency-slo-admitter (solo solicitudes de SLO): Rechaza las solicitudes descartables (la prioridad es inferior a 0) cuando no se prevé que ningún Pod candidato cumpla con el SLO, en lugar de consumir capacidad en una solicitud que se prevé que no alcance su objetivo. Este filtro no tiene efecto cuando faltan encabezados de SLO o cuando existe un Pod que cumple con el SLO.

6. weighted-random-picker: Selecciona el Pod final con una selección aleatoria ponderada sobre las puntuaciones. Esto distribuye la carga y, al mismo tiempo, favorece los Pods con mejor puntuación.

Modo de transmisión

El complemento predicted-latency-producer admite dos modos de entrenamiento, que se configuran con el parámetro streamingMode:

• streamingMode: false (predeterminado): Entrena en la latencia de solicitud de extremo a extremo (E2E). Usa este modo si tu carga de trabajo combina respuestas de transmisión y no transmisión, o si solo necesitas un enrutamiento con reconocimiento de latencia sin aplicación forzosa de SLO por solicitud.
• streamingMode: true: Entrena modelos TTFT y TPOT separados. El TTFT se registra en el primer fragmento transmitido; el TPOT se muestrea en los tokens posteriores. Usa este modo si tu carga de trabajo es de transmisión completa y necesitas una aplicación forzosa significativa de x-slo-ttft-ms / x-slo-tpot-ms.

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 the gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos de este documento.

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

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

• Asegúrate de tener una implementación de GKE Inference Gateway en funcionamiento. Consulta Implementa GKE Inference Gateway.

• Asegúrate de que tu InferencePool use un conjunto homogéneo de Pods: tipo de GPU, pesos del modelo y configuración de entrega idénticos.

• Asegúrate de que tu clúster de GKE sea la versión 1.32.3 o posterior.

• Instala Helm. Consulta la guía de instalación de Helm.

Habilita la programación basada en la latencia prevista

En los siguientes pasos, se explica cómo habilitar la programación basada en la latencia prevista para tu implementación de GKE Inference Gateway.

Paso 1: Instala o actualiza InferencePool con la latencia prevista habilitada

La marca latencyPredictor.enabled=true implementa los sidecars del servidor de entrenamiento y del servidor de predicción dentro del Pod de EPP y conecta la canalización completa del complemento de programación:

helm upgrade --install INFERENCE_POOL_NAME \
  --set inferencePool.modelServers.matchLabels.app=MODEL_SERVER_LABEL \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  --set inferenceExtension.latencyPredictor.enabled=true \
  --version LLM_D_VERSION \
  oci://LLM_D_REGISTRY_PATH

Reemplaza lo siguiente:

• INFERENCE_POOL_NAME: Es el nombre de tu InferencePool, por ejemplo, vllm-llama3-8b-instruct.
• MODEL_SERVER_LABEL: Es la clave de etiqueta que se usa para seleccionar los Pods del servidor de modelos.
• LLM_D_VERSION: Es la versión del gráfico de Helm de llm-d que se usará.
• LLM_D_REGISTRY_PATH: Es la ruta de acceso al registro de OCI de llm-d.

Paso 2: Verifica la implementación

Confirma que el Pod de EPP se esté ejecutando con todos los contenedores de sidecar listos:

kubectl get pods -l app=INFERENCE_POOL_NAME-epp

El Pod de EPP debe mostrar todos los contenedores en estado Running o Ready: el EPP en sí, el servidor de entrenamiento y uno o más servidores de predicción.

Paso 3: Envía una solicitud de línea de base

Envía una solicitud de inferencia estándar para confirmar que el enrutamiento funciona antes de habilitar los encabezados de SLO:

curl -i -X POST GATEWAY_IP:PORT/v1/completions \
 -H 'Content-Type: application/json' \
 -H 'Authorization: Bearer $(gcloud auth print-access-token)' \
 -H 'x-prediction-based-scheduling: true' \
 -d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "0"
 }'

Reemplaza lo siguiente:

• GATEWAY_IP: Es la dirección IP de tu servicio de puerta de enlace.
• PORT: Es el número de puerto de tu servicio de puerta de enlace.
• MODEL_NAME: Es el nombre del modelo que se usará para la inferencia.
• PROMPT_TEXT: Es la instrucción de entrada.
• MAX_TOKENS: Es la cantidad máxima de tokens que se generarán.

El encabezado x-prediction-based-scheduling: true habilita esta solicitud en la canalización de programación de latencia prevista. Durante el período de preparación del predictor, el EPP recurre al enrutamiento heurístico.

Paso 4: Envía solicitudes con reconocimiento de SLO (opcional)

Para habilitar la aplicación forzosa de SLO por solicitud, agrega encabezados de objetivo de latencia de TTFT y TPOT:

curl -i -X POST GATEWAY_IP:PORT/v1/completions \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer $(gcloud auth print-access-token)' \
  -H 'x-prediction-based-scheduling: true' \
  -H 'x-slo-ttft-ms: 500' \
  -H 'x-slo-tpot-ms: 50' \
  -d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "0",
    "stream": true
  }'

Reemplaza lo siguiente:

• GATEWAY_IP: Es la dirección IP de tu servicio de puerta de enlace.
• PORT: Es el número de puerto de tu servicio de puerta de enlace.
• MODEL_NAME: Es el nombre del modelo que se usará para la inferencia.
• PROMPT_TEXT: Es la instrucción de entrada.
• MAX_TOKENS: Es la cantidad máxima de tokens que se generarán.

Encabezados de la solicitud:

• x-prediction-based-scheduling: true: Habilita la solicitud en la canalización de programación de latencia prevista.
• x-slo-ttft-ms: Es el tiempo hasta el primer token máximo aceptable en milisegundos.
• x-slo-tpot-ms: Es el tiempo por token de salida máximo aceptable en milisegundos.

Supervisa la programación de latencia prevista

Cuando se habilita el predictor de latencia, el EPP expone métricas adicionales a través de Cloud Monitoring.

Escala el servidor de predicción

El EPP realiza una llamada de predicción por Pod candidato por solicitud entrante. Cada instancia del servidor de predicción admite aproximadamente 300 QPS de trabajo de predicción.

Orientación aproximada para el recuento de instancias del servidor de predicción:

Para agregar instancias del servidor de predicción, actualiza el valor de Helm latencyPredictor.predictionServerCount.

Limitaciones

• Se requiere InferencePool homogéneo: No se admiten tipos de GPU, variantes de modelos, ni configuraciones de entrega mixtas dentro de un solo grupo.
• Período de preparación: El modelo XGBoost requiere suficientes muestras de tráfico en vivo antes de que las predicciones se vuelvan precisas.
• Aplicación forzosa de SLO: La aplicación forzosa solo se realiza en la capa de enrutamiento. El servidor de modelos no finaliza las solicitudes que superan el objetivo de SLO después de la selección.
• Estado: Esta función está en versión preliminar. No se recomienda para cargas de trabajo de producción con requisitos estrictos de ANS sin pruebas exhaustivas.

¿Qué sigue?

• Personaliza la configuración de GKE Inference Gateway.
• Realiza operaciones de lanzamiento para GKE Inference Gateway.