Acerca de GKE Inference Gateway con tecnología de llm-d

En esta página, se explican los conceptos y las funciones clave de GKE Inference Gateway, una extensión de GKE Gateway para la entrega optimizada de aplicaciones de IA generativa.

En esta página, se supone que conoces lo siguiente:

• Organización de IA y AA en GKE
• Terminología de IA generativa
• Conceptos de redes de GKE, incluidos los servicios, y la API de GKE Gateway
• Balanceo de cargas en Google Cloud, en especial, cómo interactúan los balanceadores de cargas con GKE

Esta página está destinada a los siguientes perfiles:

• Ingenieros de aprendizaje automático (AA), administradores y operadores de plataformas, y especialistas en datos y en IA que estén interesados en usar las capacidades de organización de contenedores de Kubernetes para entregar cargas de trabajo de IA y AA
• Arquitectos de la nube y especialistas en redes que interactúan con las redes de Kubernetes

Descripción general

GKE Inference Gateway es una extensión de GKE Gateway que proporciona enrutamiento y balanceo de cargas optimizados para entregar cargas de trabajo de Inteligencia Artificial (IA) generativa. Simplifica la implementación, la administración y la observabilidad de las cargas de trabajo de inferencia de IA.

Para elegir la estrategia de balanceo de cargas óptima para tus cargas de trabajo de IA y AA, consulta Elige una estrategia de balanceo de cargas para la inferencia de IA en GKE.

Características y beneficios

GKE Inference Gateway proporciona las siguientes capacidades clave para entregar de manera eficiente modelos de IA generativa para aplicaciones de IA generativa en GKE:

• Métricas admitidas:
  • KV cache hits: Es la cantidad de búsquedas exitosas en la caché de pares clave-valor (KV).
  • Utilización de GPU o TPU: Es el porcentaje de tiempo que la GPU o la TPU procesan de forma activa.
  • Longitud de la cola de solicitudes: Es la cantidad de solicitudes que esperan ser procesadas.
• Balanceo de cargas optimizado para la inferencia: distribuye las solicitudes para optimizar el rendimiento de la entrega de modelos de IA. Usa métricas de servidores de modelos, como KV cache hits y la queue length of pending requests para consumir aceleradores (como GPUs y TPUs) de manera más eficiente para las cargas de trabajo de IA generativa. Esto habilita el enrutamiento con reconocimiento de caché de prefijo, una función clave que envía solicitudes con contexto compartido, identificadas mediante el análisis del cuerpo de la solicitud, a la misma réplica del modelo maximizando los aciertos de caché. Este enfoque reduce de manera drástica los cálculos redundantes y mejora el tiempo hasta el primer token, lo que lo hace muy eficaz para la IA conversacional, la generación mejorada por recuperación (RAG) y otras cargas de trabajo de IA generativa basadas en plantillas.
• Entrega de modelos ajustados de LoRA dinámicos: Admite la entrega de modelos ajustados de LoRA dinámicos en un acelerador común. Esto reduce la cantidad de GPUs y TPUs necesarias para entregar modelos mediante la multiplexación de varios modelos ajustados de LoRA en un modelo base y un acelerador comunes.
• Ajuste de escala automático optimizado para la inferencia: El escalador automático de pods horizontal (HPA) de GKE usa métricas del servidor de modelos para el ajuste de escala automático, lo que ayuda a garantizar el uso eficiente de los recursos de procesamiento y el rendimiento optimizado de la inferencia.
• Enrutamiento con reconocimiento de modelos: Enruta las solicitudes de inferencia según los nombres de los modelos definidos en las OpenAI API especificaciones dentro de tu clúster de GKE. Puedes definir políticas de enrutamiento de Gateway, como la división de tráfico y la duplicación de solicitudes, para administrar diferentes versiones de modelos y simplificar los lanzamientos de modelos. Por ejemplo, puedes enrutar solicitudes para un nombre de modelo específico a diferentes objetos InferencePool, cada uno de los cuales entrega una versión diferente del modelo. Para obtener más información sobre cómo configurar esto, consulta Configura el enrutamiento basado en el cuerpo Routing.
• Seguridad de IA y filtrado de contenido integrados: GKE Inference Gateway se integra con Google Cloud Model Armor para aplicar verificaciones de seguridad de IA y filtrado de contenido a las instrucciones y respuestas en la puerta de enlace. También puedes usar NVIDIA NeMo Guardrails. Model Armor proporciona registros de solicitudes, respuestas y procesamiento para el análisis y la optimización retrospectivos. Las interfaces abiertas de GKE Inference Gateway permiten que los proveedores y desarrolladores externos integren servicios personalizados en el proceso de solicitud de inferencia.
• Entrega específica del modelo Priority: Te permite especificar la entrega Priority de los modelos de IA. Prioriza las solicitudes sensibles a la latencia por sobre los trabajos de inferencia por lotes tolerantes a la latencia. Por ejemplo, puedes priorizar las solicitudes de aplicaciones sensibles a la latencia y descartar tareas menos sensibles al tiempo cuando los recursos son limitados.
• Enrutamiento basado en la latencia prevista: Enruta las solicitudes de inferencia con un modelo XGBoost entrenado de forma continua en el tráfico en vivo, optimizando los objetivos de tiempo hasta el primer token (TTFT) y tiempo por token de salida (TPOT) por solicitud. Es más preciso que la heurística estática en cargas de trabajo de alta varianza. Consulta Usa el enrutamiento basado en la latencia prevista con GKE Inference Gateway.
• Observabilidad de la inferencia: Proporciona métricas de observabilidad para las solicitudes de inferencia , como la tasa de solicitudes, la latencia, los errores y la saturación. Supervisa el rendimiento y el comportamiento de tus servicios de inferencia a través de Cloud Monitoring y Cloud Logging, aprovechando los paneles precompilados especializados para obtener estadísticas detalladas. Para obtener más información, consulta Visualiza el panel de GKE Inference Gateway.
• Administración avanzada de APIs con Apigee: Se integra con Apigee para mejorar tu puerta de enlace de inferencia con funciones como seguridad de la API, límite de frecuencia y cuotas. Para obtener instrucciones detalladas, consulta Configura Apigee para la autenticación y la administración de APIs.
• Extensibilidad: Se basa en una extensión de inferencia de la API de Gateway de Kubernetes de código abierto y extensible que admite un algoritmo de selector de extremos (EPP) llm-d administrado por el usuario, con tecnología de llm-d. El algoritmo de selector de extremos (EPP) llm-d, con tecnología de llm-d, proporciona la inteligencia de enrutamiento principal para esta extensión.
• Compatibilidad con varios puertos: Admite servidores de modelos que exponen varios puertos, lo que es esencial para situaciones de entrega avanzadas, como la atención paralela de datos.
• Límites del grupo de extremos de red (NEG): Tiene un límite de 50 NEGs por Google Cloud servicio de backend. Cuando se usa un InferencePool de varios puertos, cada puerto de cada zona crea un NEG dedicado. Por ejemplo, un InferencePool con ocho puertos en un clúster regional típico (tres zonas) genera 24 NEGs. Por lo tanto, una puerta de enlace de varios clústeres solo puede agregar un InferencePool de un máximo de dos clústeres (dos clústeres × 24 NEGs = 48 NEGs) antes de alcanzar el límite de 50 NEGs.

Comprende los conceptos clave

GKE Inference Gateway mejora el GKE Gateway existente que usa GatewayClass objetos. GKE Inference Gateway presenta las siguientes definiciones de recursos personalizados (CRDs) de la API de Gateway nuevas , alineadas con la extensión de la API de Gateway de Kubernetes de OSS para la inferencia:

• Objeto InferencePool: Representa un grupo de pods (contenedores) que comparten la misma configuración de procesamiento, el tipo de acelerador, el modelo de lenguaje base y el servidor de modelos. Esto agrupa y administra de forma lógica los recursos de entrega de modelos de IA. Un solo objeto InferencePool puede abarcar varios Pods en diferentes nodos de GKE y proporciona escalabilidad y alta disponibilidad. Puedes especificar hasta ocho targetPorts en un recurso InferencePool para admitir servidores de modelos que requieren varios puertos.
• Objeto InferenceObjective: Especifica el nombre del modelo de entrega de InferencePool según la especificación OpenAI API. El objeto InferenceObjective también especifica las propiedades de entrega del modelo, como la Priority del modelo de IA. GKE Inference Gateway da preferencia a las cargas de trabajo con un valor de prioridad más alto. Esto te permite multiplexar cargas de trabajo de IA críticas para la latencia y tolerantes a la latencia en un clúster de GKE. También puedes configurar el objeto InferenceObjective para entregar modelos ajustados de LoRA.

En el siguiente diagrama, se ilustra GKE Inference Gateway y su integración con la seguridad de la IA, la observabilidad y la entrega de modelos dentro de un clúster de GKE.

En el siguiente diagrama, se ilustra el modelo de recursos que se enfoca en dos nuevos perfiles centrados en la inferencia y los recursos que administran.

Router llm-d

El router llm-d es el componente inteligente de enrutamiento de solicitudes que usa Inference Gateway para tomar decisiones de extremos por solicitud. Está compuesto por dos subcomponentes:

Modo de puerta de enlace

GKE Inference Gateway es el llm-d Router que opera en el modo de puerta de enlace. En el modo de puerta de enlace, el proxy es una puerta de enlace de Kubernetes formal aprovisionada y administrada por separado del servicio EPP. La puerta de enlace llama al EPP a través de ext-proc para tomar decisiones de enrutamiento y, luego, reenvía la solicitud directamente al pod del servidor de modelos seleccionado.

Esta separación de la puerta de enlace (plano de datos) del EPP (inteligencia de enrutamiento) permite lo siguiente:

• Infraestructura compartida: Una sola puerta de enlace de GKE entrega varios InferencePools junto con los servicios estándar de Kubernetes.
• Administración avanzada del tráfico: HTTPRoute políticas admiten la división ponderada , los lanzamientos graduales y la duplicación de solicitudes.
• Ajuste de escala independiente: El servicio EPP se ajusta de forma independiente de la puerta de enlace.
• Integración nativa de la nube: Funciona con el controlador de puerta de enlace administrado de GKE , Cloud Load Balancing y las herramientas de observabilidad existentes.

Cómo funciona GKE Inference Gateway

GKE Inference Gateway usa extensiones de la API de Gateway y lógica de enrutamiento específica del modelo para controlar las solicitudes de los clientes a un modelo de IA. En los siguientes pasos, se describe el flujo de solicitudes.

Cómo funciona el flujo de solicitudes

GKE Inference Gateway enruta las solicitudes de los clientes desde la solicitud inicial a una instancia de modelo. En esta sección, se describe cómo GKE Inference Gateway controla las solicitudes. Este flujo de solicitudes es común para todos los clientes.

1. El cliente envía una solicitud, con el formato que se describe en la OpenAI API especificación, a el modelo que se ejecuta en GKE.

2. GKE Inference Gateway procesa la solicitud con las siguientes extensiones de inferencia:

   1. Extensión de enrutamiento basado en el cuerpo: Extrae el identificador del modelo del cuerpo de la solicitud del cliente y lo envía a GKE Inference Gateway. Luego, GKE Inference Gateway usa este identificador para enrutar la solicitud según las reglas definidas en el objeto HTTPRoute de la API de Gateway. El enrutamiento del cuerpo de la solicitud es similar al enrutamiento basado en la ruta de URL. La diferencia es que el enrutamiento del cuerpo de la solicitud usa datos del cuerpo de la solicitud.
   2. Extensión de seguridad: Usa Model Armor, NVIDIA NeMo Guardrails, o soluciones de terceros compatibles para aplicar políticas de seguridad específicas del modelo, que incluyen filtrado de contenido, detección de amenazas, desinfección y registro. La extensión de seguridad aplica estas políticas a las rutas de procesamiento de solicitudes y respuestas.
   3. Selector de extremos (EPP) llm-d: Supervisa las métricas clave de los servidores de modelos dentro de InferencePool y enruta la solicitud a la réplica del modelo óptima. Para obtener más información, consulta Router llm-d.

3. GKE Inference Gateway enruta la solicitud a la réplica del modelo que muestra la extensión del selector de extremos.

En el siguiente diagrama, se ilustra el flujo de solicitudes de un cliente a una instancia de modelo a través de GKE Inference Gateway.

Cómo funciona la distribución del tráfico

GKE Inference Gateway distribuye de forma dinámica las solicitudes de inferencia a los servidores de modelos dentro del objeto InferencePool. Esto ayuda a optimizar el uso de recursos y mantiene el rendimiento en condiciones de carga variables. GKE Inference Gateway usa los siguientes dos mecanismos para administrar la distribución del tráfico:

• Selección de extremos: Selecciona de forma dinámica el servidor de modelos más adecuado para controlar una solicitud de inferencia. Supervisa la carga y la disponibilidad del servidor y, luego, toma decisiones de enrutamiento óptimas calculando una score para cada servidor que combina una serie de heurísticas de optimización:

  • Enrutamiento con reconocimiento de caché de prefijo: GKE Inference Gateway realiza un seguimiento de los índices de caché de prefijo disponibles en cada servidor de modelos y otorga una puntuación más alta a un servidor con una coincidencia de caché de prefijo más larga.
  • Enrutamiento con reconocimiento de carga: GKE Inference Gateway supervisa la carga del servidor (utilización de la caché de KV y profundidad de la cola pendiente) y otorga una puntuación más alta a un servidor con una carga más baja.
  • Enrutamiento con reconocimiento de LoRA: Cuando se habilita la entrega dinámica de LoRA, GKE Inference Gateway supervisa los adaptadores de LoRA activos por servidor y otorga una puntuación más alta a un servidor con el adaptador de LoRA solicitado activo, o espacio adicional para cargar de forma dinámica el adaptador de LoRA solicitado. Se elige un servidor con la puntuación total más alta de todos los anteriores.

• Puesta en cola y descarte: Administra el flujo de solicitudes y evita la sobrecarga de tráfico. GKE Inference Gateway almacena las solicitudes entrantes en una cola y prioriza las solicitudes según la prioridad definida.

GKE Inference Gateway usa un sistema numérico Priority, también conocido como Criticality, para administrar el flujo de solicitudes y evitar la sobrecarga. Esta Priority es un campo entero opcional definido por el usuario para cada InferenceObjective. Un valor más alto significa una solicitud más importante. Cuando el sistema está bajo presión, las solicitudes con una Priority inferior a 0 se consideran de menor prioridad y se descartan primero, lo que muestra un error 429 para proteger las cargas de trabajo más críticas. De forma predeterminada, la Priority es 0. Las solicitudes solo se descartan debido a la prioridad si su Priority se establece de forma explícita en un valor inferior a 0. Este sistema te permite priorizar el tráfico de inferencia en línea sensible a la latencia por sobre los trabajos por lotes menos sensibles al tiempo.

GKE Inference Gateway admite la inferencia de transmisión para aplicaciones como chatbots y traducción en vivo, que requieren actualizaciones continuas o casi en tiempo real. La inferencia de transmisión entrega respuestas en fragmentos o segmentos incrementales, en lugar de una sola salida completa. Si se produce un error durante una respuesta de transmisión, la transmisión finaliza y el cliente recibe un mensaje de error. GKE Inference Gateway no reintenta las respuestas de transmisión.

Explora ejemplos de aplicaciones

En esta sección, se proporcionan ejemplos del uso de GKE Inference Gateway para abordar varias situaciones de aplicaciones de IA generativa.

Ejemplo 1: Entrega varios modelos de IA generativa en un clúster de GKE

Una empresa desea implementar varios modelos grandes de lenguaje (LLMs) para entregar diferentes cargas de trabajo. Por ejemplo, es posible que deseen implementar un modelo Gemma3 para una interfaz de chatbot y un modelo DeepSeek para una aplicación de recomendación. La empresa debe garantizar un rendimiento de entrega óptimo para estos LLMs.

Con GKE Inference Gateway, puedes implementar estos LLMs en tu clúster de GKE con la configuración de acelerador que elijas en un InferencePool. Luego, puedes enrutar las solicitudes según el nombre del modelo (como chatbot y recommender) y la propiedad Priority.

En el siguiente diagrama, se ilustra cómo GKE Inference Gateway enruta las solicitudes a diferentes modelos según el nombre del modelo y Priority.

En este diagrama, se ilustra cómo GKE Inference Gateway controla una solicitud a un servicio de GenAI en example.com/completions. La solicitud primero llega a una Gateway en el espacio de nombres Infra. Esta Gateway reenvía la solicitud a una HTTPRoute en el espacio de nombres GenAI Inference, que está configurado para controlar las solicitudes de modelos de chatbot y de opinión. Para el modelo de chatbot, la HTTPRoute divide el tráfico: el 90% se dirige a un InferencePool que ejecuta la versión actual del modelo (seleccionada por {pool: gemma}) y el 10% va a un grupo con una versión más reciente ({pool: gemma-new}), por lo general, para pruebas canary. Ambos grupos están vinculados a un InferenceObjective que asigna una Priority de 10 a las solicitudes del modelo de chatbot, lo que garantiza que estas solicitudes se traten como de alta prioridad.

Ejemplo 2: Entrega adaptadores de LoRA en un acelerador compartido

Una empresa desea entregar LLMs para el análisis de documentos y se enfoca en públicos en varios idiomas, como inglés y español. Tienen modelos ajustados para cada idioma, pero necesitan usar de manera eficiente su capacidad de GPU y TPU. Puedes usar GKE Inference Gateway para implementar adaptadores ajustados de LoRA dinámicos para cada idioma (por ejemplo, english-bot y spanish-bot) en un modelo base común (por ejemplo, llm-base) y un acelerador. Esto te permite reducir la cantidad de aceleradores necesarios mediante el empaquetamiento denso de varios modelos en un acelerador común.

En el siguiente diagrama, se ilustra cómo GKE Inference Gateway entrega varios adaptadores de LoRA en un acelerador compartido.

¿Qué sigue?

• Implementa GKE Inference Gateway
• Personaliza la configuración de GKE Inference Gateway
• Entrega un LLM con GKE Inference Gateway
• Usa el enrutamiento basado en la latencia prevista con GKE Inference Gateway(versión preliminar)