La puerta de enlace de inferencia de Google Kubernetes Engine (GKE) de varios clústeres balancea las cargas de trabajo de inferencia de IA/AA en varios clústeres de GKE. Integra puertas de enlace de varios clústeres de GKE para el enrutamiento de tráfico entre clústeres con la puerta de enlace de inferencia para la entrega de modelos de IA/AA. Esta integración mejora la escalabilidad y la alta disponibilidad de tus implementaciones. En este documento, se explican los conceptos y beneficios principales de la puerta de enlace.
Para obtener más información sobre cómo implementar la puerta de enlace de inferencia de GKE de varios clústeres, consulta Configura la puerta de enlace de inferencia de GKE de varios clústeres.
Para comprender este documento, debes estar familiarizado con lo siguiente:
- Organización de IA y AA en GKE.
- Terminología de IA generativa.
- Conceptos de redes de GKE, incluidos los servicios, la puerta de enlace de varios clústeres de GKE y la API de puerta de enlace.
- Balanceo de cargas en Google Cloud, en especial, cómo interactúan los balanceadores de cargas con GKE.
Este documento está dirigido a los siguientes perfiles:
- Ingenieros de aprendizaje automático (AA), administradores y operadores de plataformas, y especialistas en datos y en IA interesados en usar las funciones de organización de contenedores de Kubernetes para entregar cargas de trabajo de IA/AA
- Arquitectos de nube o 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 Google Cloud el contenido, consulta Roles de usuario y tareas comunes de GKE Enterprise y tareas.
Beneficios de la puerta de enlace de inferencia de GKE de varios clústeres
La GKE Inference Gateway de varios clústeres proporciona varios beneficios para administrar tus cargas de trabajo de inferencia de IA/AA, incluidos los siguientes:
- Mejora la alta disponibilidad y la tolerancia a fallas a través del balanceo de cargas inteligente en varios clústeres de GKE, incluso en diferentes regiones geográficas. Tus cargas de trabajo de inferencia permanecen disponibles, y el sistema redirecciona automáticamente las solicitudes si un clúster o una región experimentan problemas, lo que minimiza el tiempo de inactividad.
- Mejora la escalabilidad y optimiza el uso de recursos mediante la agrupación de recursos de GPU y TPU de varios clústeres para controlar el aumento de la demanda. Esta agrupación permite que tus cargas de trabajo superen la capacidad de un solo clúster y usen de manera eficiente los recursos disponibles en toda tu flota.
- Maximiza el rendimiento con el enrutamiento optimizado a nivel global. La puerta de enlace usa métricas avanzadas, como el uso de la caché de clave-valor (KV) de todos los clústeres, para tomar decisiones de enrutamiento eficientes. Este enfoque ayuda a garantizar que las solicitudes se dirijan al clúster mejor equipado para controlarlas, lo que maximiza el rendimiento general de tu flota de inferencia de IA/AA.
Limitaciones
La puerta de enlace de inferencia de GKE de varios clústeres tiene las siguientes limitaciones:
Integración de Model Armor: La puerta de enlace de inferencia de GKE de varios clústeres no admite la integración de Model Armor.
Informes de latencia de Envoy Proxy: Envoy Proxy solo informa la latencia de las consultas para las solicitudes exitosas (
2xx). Ignora los errores y los tiempos de espera. Este comportamiento puede hacer que el balanceador de cargas del servidor global (GSLB) subestime la carga real en los backends con errores, lo que podría dirigir más tráfico a los servicios ya sobrecargados. Para mitigar este problema, configura un tiempo de espera de solicitud más largo. Por ejemplo, se recomienda un valor de600s.Límites del grupo de extremos de red (NEG): tiene un límite de 50 NEG 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 NEG. 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 NEG = 48 NEG) antes de alcanzar el límite de 50 NEG.
Componentes clave
La puerta de enlace de inferencia de GKE de varios clústeres usa varios recursos personalizados de Kubernetes para administrar las cargas de trabajo de inferencia y el enrutamiento de tráfico:
- InferencePool: Agrupa backends idénticos del servidor de modelos en tu clúster de destino. Este recurso simplifica la administración y el escalamiento de tus instancias de entrega de modelos. Los objetos InferencePool de varios puertos son compatibles con implementaciones de un solo clúster y de varios clústeres.
InferenceObjective: Define las prioridades de enrutamiento para modelos específicos dentro de un InferencePool. Este enrutamiento ayuda a garantizar que ciertos modelos reciban preferencia de tráfico según tus requisitos.GCPInferencePoolImport: Hace que tus backends de modelos estén disponibles para la configuración de enrutamiento medianteHTTPRouteen el clúster de configuración. Este recurso se crea automáticamente en tu clúster de configuración cuando exportas un InferencePool desde un clúster de destino. El clúster de configuración actúa como el punto de control central de tu entorno de varios clústeres.GCPBackendPolicy: Personaliza la forma en que se balancean las cargas del tráfico a tus backends. Por ejemplo, puedes habilitar el balanceo de cargas en función de métricas personalizadas o establecer límites en las solicitudes en tránsito por extremo para proteger tus servidores de modelos.AutoscalingMetric: Define métricas personalizadas, comovllm:kv_cache_usage_perc, para exportar desde tus servidores de modelos. Luego, puedes usar estas métricas dentro deGCPBackendPolicypara tomar decisiones de balanceo de cargas más inteligentes y optimizar el rendimiento y el uso de recursos.
Cómo funciona GKE Inference Gateway de varios clústeres
La GKE Inference Gateway de varios clústeres administra y enruta el tráfico a tus modelos de IA/AA implementados en varios clústeres de GKE. Esto funciona de la siguiente manera:
- Administración de tráfico centralizada: Un clúster de configuración dedicado define tus reglas de enrutamiento de tráfico. El clúster de configuración actúa como el punto de control central de tu entorno de varios clústeres. Designas un clúster de GKE como el clúster de configuración cuando habilitas Ingress de varios clústeres para tu flota. Este enfoque centralizado te permite administrar cómo se dirigen las solicitudes a tus modelos en toda tu flota de clústeres de GKE desde un solo lugar.
- Implementación de modelos flexible: Tus modelos de IA/AA reales se ejecutan en clústeres de destino separados. Esta separación te permite implementar modelos donde tenga más sentido (por ejemplo, más cerca de los datos o de los clústeres con hardware específico).
- Integración sencilla de modelos: Cuando implementas un modelo en un clúster de destino, agrupas sus instancias de entrega con un InferencePool. La exportación de este InferencePool lo pone a disposición automáticamente para el enrutamiento en tu clúster de configuración.
- Balanceo de cargas inteligente: La puerta de enlace no solo distribuye el tráfico, sino que también toma decisiones de enrutamiento inteligentes. Si la configuras para que use varios indicadores, incluidas las métricas personalizadas de tus servidores de modelos, la puerta de enlace ayuda a garantizar que las solicitudes entrantes se envíen al clúster o a la instancia de modelo mejor equipados, lo que puede maximizar el rendimiento y el uso de recursos. Por ejemplo, puedes enrutar las solicitudes al clúster con la mayor capacidad de inferencia disponible en función de métricas como el uso de la caché de clave-valor (KV).
¿Qué sigue?
- Para implementar la puerta de enlace, consulta Configura la puerta de enlace de inferencia de GKE de varios clústeres.
- Para obtener información sobre cómo usar el campo
scopesen el recursoGCPBackendPolicy, consulta Personaliza las configuraciones de backend con los alcances deGCPBackendPolicy.