Elige una estrategia de balanceo de cargas para la inferencia de modelos de IA/AA en GKE

En esta página, se te ayuda a elegir la estrategia de balanceo de cargas adecuada para las cargas de trabajo de inferencia de modelos de IA/AA en Google Kubernetes Engine (GKE).

Esta página está destinada a los siguientes arquetipos de usuarios:

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

Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido deGoogle Cloud , consulta Roles y tareas comunes de los usuarios de GKE.

Antes de leer esta página, asegúrate de estar familiarizado con lo siguiente:

Cuando implementes cargas de trabajo de inferencia de modelos de IA/AA en GKE, elige la estrategia de balanceo de cargas adecuada para optimizar el rendimiento, la escalabilidad y la rentabilidad:

  • Elige la puerta de enlace de inferencia de GKE para un enrutamiento y un balanceo de cargas optimizados para la entrega de cargas de trabajo de IA/AA.
  • Elige la puerta de enlace de GKE con métricas personalizadas, que usa balanceadores de cargas de aplicaciones. Esta opción proporciona un control de uso general y te permite configurar la distribución del tráfico según las métricas específicas de los requisitos de tu aplicación o infraestructura.

Descripción general de la puerta de enlace de inferencia de GKE

GKE Inference Gateway optimiza y administra las exigentes cargas de trabajo de inferencia de IA generativa (IA generativa) y de modelos de lenguaje grandes (LLM) complejos. Extiende la API de GKE Gateway y ofrece varias ventajas clave:

  • Enrutamiento inteligente con reconocimiento de IA: GKE Inference Gateway supervisa las métricas críticas específicas de la IA, incluidas las siguientes:

    • Uso de la caché de KV del servidor del modelo
    • Longitud de la cola de solicitudes pendientes
    • Uso general de GPU/TPU
    • Disponibilidad del adaptador de LoRA
    • El costo de procesamiento de las solicitudes individuales: Según estas métricas, la puerta de enlace distribuye de forma inteligente el tráfico a la réplica del servidor del modelo más adecuada y menos cargada.

  • Priorización de solicitudes: La puerta de enlace proporciona mecanismos para priorizar solicitudes.

  • Ajuste de escala automático optimizado: La puerta de enlace ofrece mecanismos de ajuste de escala automático optimizados para los servidores de modelos.

Descripción general de la puerta de enlace de GKE con métricas personalizadas

Google Cloud ofrece recursos del balanceador de cargas de aplicaciones que admiten alcances como externo global y externo regional. Estos balanceadores de cargas de uso general distribuyen el tráfico según las métricas personalizadas que informan tus servicios de backend. Este enfoque proporciona un control detallado sobre la distribución de la carga, lo que te permite basarla en indicadores de rendimiento específicos de la aplicación.

Compara GKE Inference Gateway y GKE Gateway con métricas personalizadas

Usa la siguiente tabla para comparar las funciones de la puerta de enlace de inferencia de GKE y la puerta de enlace de GKE con métricas personalizadas, y elige la solución de balanceo de cargas adecuada para tus cargas de trabajo de inferencia de IA/ML en GKE.

Función Puerta de enlace de inferencia de GKE Puerta de enlace de GKE con métricas personalizadas (a través de balanceadores de cargas de aplicaciones)
Caso de uso principal Optimiza las cargas de trabajo de inferencia de IA generativa y aprendizaje automático en Kubernetes, incluida la entrega de modelos de lenguaje grandes (LLM). Garantiza un acceso justo a los recursos del modelo y optimiza las cargas de trabajo de LLM basadas en GPU o TPU que son sensibles a la latencia. Proporciona balanceo de cargas HTTP(S) de uso general, que distribuye el tráfico según métricas personalizadas informadas por la aplicación. Este tipo de balanceo de cargas es ideal para servicios sensibles a la latencia, como servidores de juegos en tiempo real o plataformas de comercio de alta frecuencia, que informan datos de utilización personalizados.
Enrutamiento básico Admite el enrutamiento HTTP(S) estándar basado en el host y la ruta de acceso, lo que extiende la API de GKE Gateway. Admite el enrutamiento HTTP(S) estándar basado en el host y la ruta de acceso. Puedes configurar esto con los recursos estándar de la API de GKE Gateway.
Lógica de enrutamiento avanzada Proporciona capacidades avanzadas, como el enrutamiento que tiene en cuenta el modelo, la división y la duplicación del tráfico, y la aplicación de niveles de prioridad y criticidad a las solicitudes. Balancea el tráfico según las métricas personalizadas que informa la aplicación a través del estándar de Open Request Cost Aggregation (ORCA). Esto habilita políticas como WEIGHTED_ROUND_ROBIN para la ponderación de extremos dentro de una localidad.
Métricas admitidas Utiliza un conjunto de métricas nativas específicas de la IA, como el uso de GPU o TPU, los aciertos de la caché de KV y la longitud de la cola de solicitudes. También se puede configurar para usar métricas informadas por la aplicación a través de un mecanismo de encabezado HTTP estandarizado. Se basa en las métricas que informa la aplicación a través de un mecanismo de encabezado HTTP estandarizado, específicamente el informe de carga de Open Request Cost Aggregation (ORCA). Este mecanismo admite métricas estándar, como la CPU y la memoria, así como métricas con nombres personalizados para recursos restringidos específicos de la aplicación.
Cómo administrar solicitudes Diseñado para controlar cargas de trabajo con costos de solicitudes no uniformes, que son comunes en los LLM debido a las diferentes complejidades de las instrucciones. Admite niveles de criticidad de solicitudes, lo que permite priorizar diferentes tipos de solicitudes de inferencia. Es más adecuado para cargas de trabajo en las que las solicitudes individuales tienen costos de procesamiento relativamente uniformes. Esta solución no incluye capacidades nativas de priorización de solicitudes.
Compatibilidad con adaptadores LoRA Ofrece enrutamiento nativo basado en la afinidad a backends equipados con adaptadores LoRa específicos, lo que garantiza que las solicitudes se dirijan a los recursos adecuados. No proporciona compatibilidad nativa con adaptadores LoRa ni con el enrutamiento basado en la afinidad según las configuraciones de LoRa.
Integración de ajuste de escala automático Optimiza el ajuste de escala automático para los servidores de modelos aprovechando las métricas específicas de la IA, como el uso de la caché de KV, para tomar decisiones de escalamiento más fundamentadas. Se integra con el Horizontal Pod Autoscaler (HPA) a través de métricas personalizadas. Estas métricas se informan al balanceador de cargas de aplicaciones y se utilizan de manera genérica para el ajuste de escala, según los indicadores de carga informados.
Instalación y configuración Configúralo con la API de GKE Gateway. Extiende la API estándar con definiciones de recursos personalizados (CRD) InferencePool y InferenceModel especializadas para habilitar sus funciones compatibles con la IA. Configurarás esta solución con los recursos estándar de la API de GKE Gateway. La aplicación debe implementar un mecanismo basado en encabezados HTTP, como la Agregación de costos de solicitudes abiertas (ORCA), para registrar métricas personalizadas para el balanceo de cargas.
Seguridad Esta solución incluye el filtrado de contenido generado por IA con Model Armor a nivel de la puerta de enlace. También aprovecha las funciones de seguridad fundamentales de GKE, como TLS, Identity and Access Management (IAM), control de acceso basado en roles (RBAC) y espacios de nombres. Esta solución usa la pila de seguridad estándar del balanceador de cargas de aplicaciones, que incluye Google Cloud Armor, finalización de TLS y IAM. Para habilitar el filtrado de contenido generado por IA, puedes integrar Google Cloud Armor como una extensión de servicio.
Observabilidad Ofrece observabilidad integrada en métricas específicas de la IA, como el uso de GPU o TPU, los aciertos de la caché de KV, la longitud de la cola de solicitudes y la latencia del modelo. La observabilidad depende de las métricas personalizadas que la aplicación esté configurada para informar. Puedes verlas en Cloud Monitoring. Pueden incluir métricas estándar o con nombres personalizados.
Extensibilidad Se basa en una base de código abierto extensible, lo que permite un algoritmo de Endpoint Picker administrado por el usuario. Extiende la API de GKE Gateway con [definiciones de recursos personalizados (CRD)](/kubernetes-engine/docs/how-to/deploy-gke-inference-gateway) especializadas, como InferencePool y InferenceModel, para simplificar los casos de uso comunes de la IA. Diseñado para brindar flexibilidad, lo que te permite extender el balanceo de cargas con cualquier [métrica personalizada (indicador de carga)](/load-balancing/docs/https/applb-custom-metrics) que la aplicación informe con el estándar de ORCA.
Etapa de lanzamiento DG DG

Cuándo usar la puerta de enlace de inferencia de GKE

Elige la puerta de enlace de inferencia de GKE para optimizar las cargas de trabajo de inferencia sofisticadas de IA y aprendizaje automático en GKE, en especial para los modelos de lenguaje grande (LLM). Recomendamos esta solución en las siguientes situaciones:

  • Publicación de LLM: Necesitas decisiones de enrutamiento basadas en estados específicos del LLM, como la utilización de la caché de KV o la longitud de la cola de solicitudes, cuando usas servidores de modelos como vLLM.
  • Implementación de modelos con adaptadores de LoRA: Necesitas un enrutamiento inteligente basado en la afinidad a los backends equipados con los adaptadores de LoRA correctos y disponibles.
  • Cómo controlar las solicitudes de inferencia con costos de procesamiento muy variables: Por ejemplo, los tamaños o la complejidad de las instrucciones dinámicas requieren un balanceador de cargas que tenga en cuenta los costos.
  • Implementa la priorización de solicitudes: Debes priorizar diferentes clases de tráfico de inferencia, como solicitudes críticas, estándar o descartables.
  • Optimización del ajuste de escala automático: Deseas un mecanismo de ajuste de escala automático estrechamente vinculado con métricas de rendimiento específicas de los servidores de modelos de IA generativa (GenAI), como la utilización de la caché de KV, para tomar decisiones de ajuste de escala más fundamentadas.
  • Utiliza la integración de Model Armor: Debes usar Model Armor para las verificaciones de seguridad de la IA a nivel de la puerta de enlace.
  • Obtén observabilidad lista para usar: Necesitas observabilidad integrada para las métricas críticas específicas de la IA, como el uso de GPU o TPU, los aciertos de la caché de KV y la longitud de la cola de solicitudes.
  • Simplifica las implementaciones de IA generativa: Prefieres una solución creada específicamente que simplifique los patrones de implementación comunes de IA generativa en GKE, a la vez que conserva opciones para la personalización futura a través de su base extensible de la API de GKE Gateway.

Cuándo usar GKE Gateway con métricas personalizadas

Para lograr un balanceo de cargas flexible y de uso general basado en los indicadores de rendimiento únicos de tu aplicación, usa GKE Gateway con métricas personalizadas. Este enfoque permite la distribución de la carga según indicadores de rendimiento únicos definidos por la aplicación, incluidos los casos de inferencia específicos. Recomendamos esta opción en los siguientes casos:

  • Tu carga de trabajo tiene un gran volumen de tráfico con costos de procesamiento por solicitud relativamente uniformes.
  • La distribución de la carga se puede administrar de manera eficaz con una o dos métricas personalizadas específicas que informa la aplicación, por lo general, a través de encabezados de respuesta HTTP con el estándar de informes de carga de Open Request Cost Aggregation (ORCA).
  • Tus requisitos de balanceo de cargas no dependen de las funciones específicas de la IA generativa o los LLM.
  • Tu modelo operativo no requiere la inteligencia especializada específica de la IA que proporciona GKE Inference Gateway, lo que evita una complejidad arquitectónica innecesaria.
  • Mantener la coherencia con las implementaciones existentes del balanceador de cargas de aplicaciones es una prioridad, y estas implementaciones cumplen con los requisitos de balanceo de cargas del servicio de inferencia.

¿Qué sigue?