Application Gateway para contenedores: puerta de enlace de inferencia

Las cargas de trabajo de inferencia de IA no se comportan como las aplicaciones HTTP sin estado tradicionales. Las solicitudes suelen ser específicas del modelo, de larga duración, costosas de atender y sensibles a las señales en tiempo de ejecución, como la disponibilidad del acelerador, la profundidad de la cola, la prioridad de la solicitud, el presupuesto del token y la capacidad del servidor del modelo.

La puerta de enlace de inferencia de Application Gateway for Containers admite estas cargas de trabajo mediante la integración con la extensión de Kubernetes Gateway API Inference Extension, que añade recursos con reconocimiento de inferencia al modelo de Gateway API. Al usar la puerta de enlace de inferencia, puede exponer servidores de modelos autohospedados a través de Application Gateway for Containers con comportamiento de enrutamiento en función del modelo y de la carga.

La puerta de enlace de inferencia está diseñada específicamente para servir modelos de lenguaje grandes (LLM) y otras cargas de trabajo de inferencia. Dirige las solicitudes en función de las señales del servidor de modelos, en lugar de usar un balanceo de carga genérico, lo que reduce el tiempo hasta el primer token (TTFT), disminuye los tiempos de espera en situaciones de alta carga y mejora la eficiencia de la GPU. Basado en las capacidades de entrada de Application Gateway para contenedores, la puerta de enlace de inferencia también le permite combinar cargas de trabajo de IA con funcionalidades como el firewall de aplicaciones web (WAF) para proteger el tráfico antes de que llegue a los servidores que alojan los modelos.

Muchos entornos de ejecución de inferencia autohospedados, incluidos vLLM, exponen API HTTP compatibles con OpenAI , como /v1/chat/completions, /v1/completionsy /v1/models. La compatibilidad con OpenAI hace referencia al formato de API, no a una restricción a los modelos hospedados en OpenAI. Si se proporciona otra familia de modelos a través de un entorno de ejecución o proxy que usa este formato, Application Gateway for Containers puede usar el model campo en el cuerpo de la solicitud JSON para el enrutamiento basado en el cuerpo.

Qué proporciona la extensión de inferencia de la API Gateway

La extensión de inferencia de Gateway API convierte una implementación de Gateway API en una pasarela de inferencia mediante la incorporación de conceptos de backend y planificación específicos de la inferencia.

La extensión presenta estos recursos y componentes principales:

• InferencePool: un recurso de backend que representa un grupo de pods de servidores de modelos y el selector de endpoints que se usa para seleccionar un pod para cada solicitud de inferencia.
• InferenceObjective: un recurso que representa los objetivos de servicio de solicitudes, como la prioridad, para las solicitudes que comparten un objeto InferencePool.
• Selector de puntos de conexión (EPP): una extensión proporcionada por el cliente que se ejecuta en el clúster e implementa la programación de inferencia. El EPP recibe metadatos de la solicitud, evalúa los pods candidatos del servidor de modelos mediante plugins configurables (por ejemplo, profundidad de cola, uso de la caché KV y afinidad de la caché de prefijos) y devuelve el extremo seleccionado. Dado que la selección de puntos de conexión se ejecuta en el EPP, los comportamientos de enrutamiento disponibles dependen de los complementos de puntuación que habilita el EPP.
• Enrutamiento basado en el cuerpo de la solicitud (BBR): un procesador de solicitudes que puede inspeccionar un cuerpo de solicitud compatible con OpenAI, extraer el nombre del modelo y ponerlo a disposición de la puerta de enlace como el encabezado X-Gateway-Model-Name para el enrutamiento en función del modelo.

Application Gateway for Containers ejecuta el procesador BBR como parte administrada de la puerta de enlace, por lo que no hay ningún nivel de enrutamiento basado en el cuerpo independiente para implementar, escalar o aplicar revisiones. Se integra con un EPP proporcionado por el cliente para permitir decisiones de enrutamiento en el momento de la solicitud. La puerta de enlace de inferencia admite la API de extensión de inferencia de Gateway API, por lo que estas capacidades se configuran mediante los recursos estándar de Gateway API, y los equipos de plataforma pueden usar un modelo de API nativo de Kubernetes para el tráfico de inferencia en lugar de introducir un modelo de configuración de Ingress independiente.

Cómo Application Gateway for Containers usa recursos de inferencia

Application Gateway for Containers sigue usando recursos de API de puerta de enlace estándar para la configuración de entrada. El comportamiento de inferencia se activa cuando una referencia de backend HTTPRoute apunta a un InferencePool en lugar de a un Service de Kubernetes.

En el caso de las rutas que no son de inferencia, Application Gateway for Containers mantiene el comportamiento de la API de puerta de enlace existente. Las rutas que tienen como destino los back-end de Kubernetes Service no invocan procesadores de inferencia y no reciben un comportamiento de enrutamiento específico de la inferencia.

Para las rutas de inferencia, el plano de control reconcilia la API de puerta de enlace y los recursos de inferencia y programas el plano de datos para que:

• El HTTPRoute selecciona el servidor InferencePool.
• El InferencePool selecciona los pods del servidor de modelos que pertenecen al conjunto.
• Se utiliza el EPP asociado al conjunto para seleccionar el punto de conexión.
• El punto de conexión del servidor de modelo seleccionado recibe la solicitud.
• El enrutamiento opcional compatible con modelos usa el nombre del modelo de solicitud extraído por BBR.

Flujo de solicitud

Una solicitud de inferencia típica sigue esta ruta de acceso. Los pasos numerados corresponden a las etiquetas del siguiente diagrama:

1. Solicitud del cliente: Un cliente envía una solicitud compatible con OpenAI al front-end de Application Gateway for Containers y el agente de escucha de la puerta de enlace la acepta.
2. Enrutamiento basado en el cuerpo (BBR): en el caso de las rutas compatibles con el modelo, el procesador BBR administrado inspecciona el cuerpo de la solicitud, extrae el nombre del modelo e inserta el X-Gateway-Model-Name encabezado. El HTTPRoute puede entonces basarse en ese valor para seleccionar el InferencePool adecuado.
3. Selección de extremos: cuando la ruta coincidente apunta a un InferencePool, Application Gateway for Containers invoca el EPP, que evalúa la solicitud y la telemetría del servidor de modelos, y devuelve el extremo seleccionado.
4. Enrutamiento al InferencePool: Application Gateway for Containers reenvía la solicitud al pod del servidor del modelo seleccionado, y la respuesta del servidor del modelo regresa al cliente a través de la puerta de enlace.

Capacidades de enrutamiento

La puerta de enlace de inferencia admite estos patrones de enrutamiento para cargas de trabajo de IA autohospedadas. La selección de puntos de conexión se ejecuta en el EPP, por lo que los comportamientos compatibles con la carga y el reconocimiento de caché dependen de los complementos de puntuación que habilita el EPP.

• Enrutamiento en función del modelo: enruta las solicitudes en función del nombre del modelo en los cuerpos de solicitud compatibles con OpenAI, que extrae el procesador BBR gestionado.
• División del tráfico e implementaciones: Use el enrutamiento ponderado estándar HTTPRoutebackendRefs para dividir el tráfico entre InferencePool backends para implementaciones de modelos de tipo canary o blue-green.
• Selección de endpoints en función de la carga y de la caché: EPP puntúa los endpoints utilizando la telemetría del servidor del modelo, como la profundidad de la cola y la utilización de la caché KV. Cuando el EPP habilita la asignación con reconocimiento de caché de prefijos, las solicitudes que comparten un prefijo del prompt se envían a la misma réplica para aumentar los aciertos de caché y reducir el TTFT.
• Prioridad de las solicitudes y protección contra sobrecarga: Use los recursos InferenceObjective y el encabezado de solicitud x-gateway-inference-objective para asignar la prioridad de servicio. Cuando los servidores del modelo están saturados, el EPP descarta primero las solicitudes de menor prioridad para proteger el tráfico sensible a la latencia.
• Selección de puntos de conexión resistentes: configure el comportamiento de error de EPP con FailOpen o FailClose, en función de si la selección de puntos de conexión estricta o de disponibilidad es más importante para un grupo.
• Compatibilidad con la API de Gateway: siga usando Gateway, HTTPRoute, ReferenceGrant y las condiciones de estado estándar de la Gateway API para la configuración de ingreso.

Inferencia segura

Mantenga los servidores de modelos privados detrás de la puerta de enlace administrada y aplique las funcionalidades de seguridad de la plataforma al tráfico de inferencia.

• Firewall de aplicaciones web (WAF): la puerta de enlace de inferencia se integra de forma nativa con la capacidad de WAF existente en Application Gateway for Containers, aplicando protecciones alineadas con OWASP al tráfico de IA antes de que las solicitudes lleguen a los servidores de modelos.
• Protección para backends costosos: dado que la política se aplica en el borde gestionado, las solicitudes malformadas o abusivas pueden inspeccionarse y bloquearse antes de que consuman la escasa capacidad de GPU.

Escenarios de ejemplo

Los escenarios siguientes muestran formas comunes de usar la puerta de enlace de inferencia:

• Servir e implementar versiones de modelo: enrutar solicitudes compatibles con OpenAI a un InferencePool por nombre de modelo y, a continuación, usar backendRefs ponderados HTTPRoute para cambiar un porcentaje de tráfico a una nueva versión del modelo para las pruebas controladas antes de completar el lanzamiento.
• Priorice el tráfico sensible a la latencia: defina InferenceObjective recursos para cargas de trabajo de alta prioridad y baja prioridad en un grupo compartido. Las solicitudes de chat interactivo tienen prioridad alta, mientras que los trabajos por lotes usan una prioridad menor, que es la primera en descartarse cuando el pool se satura.

InferencePool en comparación con Service

Kubernetes Service sigue siendo la abstracción de back-end adecuada para el tráfico de aplicaciones estándar. Utilice un InferencePool cuando el backend sea un grupo de pods de servidor de modelos que requieren una selección de endpoints específica para la inferencia.

Un InferencePool incluye un selector de pods, información sobre el puerto de destino y una referencia al selector de endpoints. El EPP es responsable de seleccionar el punto de conexión para una solicitud. Un único EPP está asociado a un único grupo.

Comportamiento ante fallos

El enrutamiento de inferencia es un comportamiento que se produce en el momento de la solicitud, por lo que el modo de fallo del selector de puntos de conexión es importante.

InferencePool Las referencias del selector de puntos de conexión admiten estos modos de error:

• FailOpen: si el EPP no está disponible o no responde, la puerta de enlace puede continuar con la selección de punto de conexión estándar para el grupo. Esta opción conserva la disponibilidad, pero podría reducir la calidad del enrutamiento.
• FailClose: si el EPP no está disponible o no responde, la puerta de enlace rechaza la solicitud. Esta opción impide que el tráfico se envíe sin la decisión de selección de punto de conexión necesaria.

Para el enrutamiento basado en modelos que depende del análisis del cuerpo de la solicitud, Application Gateway for Containers prioriza la exactitud. Si el nombre del modelo no se puede extraer para una ruta que requiere BBR, la solicitud se rechaza en lugar de dirigirse silenciosamente al backend del modelo equivocado.

Consideraciones operativas

Planee las siguientes consideraciones al ejecutar cargas de trabajo de inferencia detrás de Application Gateway para contenedores:

• Capacidad del EPP: El EPP está en la ruta de solicitud de los sistemas InferencePool backend. Ajustar el tamaño y supervisarlo como un componente de aplicación crítico.
• Telemetría del servidor de modelos: el EPP necesita métricas actualizadas del servidor de modelos para tomar decisiones de enrutamiento de alta calidad. Confirme que el servidor de modelos admite las métricas esperadas por la configuración de EPP.
• Capacidad y programación de GPU: los pods de servidor de modelos suelen requerir grupos de nodos de GPU, complementos de dispositivos y credenciales de descarga de modelos.
• Escalado automático: escalar los pods del servidor de modelos en función de señales de inferencia, como la longitud de la cola y el uso de la caché KV, mediante el Horizontal Pod Autoscaler o KEDA. El escalado automático añade capacidad a medida que crece la demanda, mientras que el EPP redirige el tráfico para evitar las réplicas que ya están saturadas.
• Respuestas de streaming: muchas cargas de trabajo de finalización de chat usan eventos enviados por el servidor. Valide el comportamiento de streaming al probar la latencia de un extremo a otro y la configuración de tiempo de espera.
• Observabilidad: supervise el estado de Gateway y HTTPRoute, el estado de InferencePool, el estado de EPP, el estado de preparación del servidor de modelos y las métricas del servidor de modelos, como las solicitudes activas y la profundidad de la cola.

Limitaciones

La puerta de enlace de inferencia se centra en cargas de trabajo de inferencia autohospedada que se ejecutan en Kubernetes. El enrutamiento directo a los puntos de conexión del proveedor de modelos públicos o administrados está fuera del ámbito de esta integración.

La extensión Gateway API Inference Extension evoluciona de forma independiente de Application Gateway for Containers. Use versiones y manifiestos de API que coincidan con los CRD de extensión de inferencia instalados en el clúster.

Pasos siguientes

• Application Gateway para contenedores: configuración de la puerta de enlace de inferencia
• Componentes de Application Gateway para contenedores
• Documentación de la extensión de inferencia para Gateway API