원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
En entornos empresariales, cuando varios equipos llaman simultáneamente a modelos de IA generativa, una estructura de proxy centralizada provoca fácilmente el agotamiento de los hilos debido a los miles de E/S de tokens y sesiones largas. Para eliminar la latencia de red cruzada entre VPC (que oscila entre 15 y 40 milisegundos) y el problema de vecinos ruidosos entre inquilinos, es necesario aislar físicamente la ruta de tráfico en tiempo de ejecución y el plano de control de políticas central.
Una pasarela central única se convierte en el epicentro de los cuellos de botella en entornos de tráfico a gran escala. Al adoptar una topología de dos niveles, el envío de tráfico se aísla en planos de datos específicos de cada dominio, mientras que el plano de control se mantiene centralizado.
En un entorno de Kubernetes, se aplica de forma declarativa la especificación Envoy AI Gateway 1.0. Se crea un recurso Gateway en el espacio de nombres de cada dominio de negocio para terminar el tráfico HTTPS y se vincula BackendSecurityPolicy para sincronizar las claves de autenticación de API desde el almacén de seguridad central. Se definen los recursos AIServiceBackend y AIGatewayRoute para leer los parámetros del modelo en el cuerpo de la solicitud y ramificar el enrutamiento.
Incluso si se produce un fallo en el servidor de políticas central o en el troncal de red corporativa, cada dominio procesa el tráfico de inferencia sin interrupciones utilizando la política de caché sincronizada justo antes. Se amplía la configuración del tamaño de mensaje del controlador a más de 25 megabytes y se estabiliza el intervalo de sondeo para suprimir los picos de CPU causados por recargas frecuentes.
Si el tiempo de respuesta general se recopila como una métrica única, los tiempos de inferencia de los modelos grandes y pequeños se mezclan, lo que enmascara la degradación del rendimiento. Para distinguir si un pico en el indicador P99 se debe a la sobrecarga de la cola de prellenado de GPU de un proveedor externo o al tiempo de espera de bloqueo dentro de la pasarela, es necesario medir y separar el ciclo de vida en la capa de middleware.
Se escribe directamente un middleware para recopilar métricas de histograma de Prometheus en la tubería de la pasarela. Se captura la hora de entrada del cliente mediante un middleware ASGI y se almacenan el ID del inquilino y la cabecera del dominio de ruta en los valores de estado. El tiempo de latencia de encolamiento del middleware interno se registra en un objeto Histogram para recopilarlo en cubos (buckets) que van de 0.001 segundos a 2.5 segundos. Al canalizar el flujo del cliente ascendente, se detecta el momento en que se recibe el primer byte de token para observar la latencia TTFT pura del proveedor como un histograma independiente.
Según los casos de gobernanza de infraestructura de Uber, al colocar de esta manera la latencia P99 de encolamiento del middleware interno y la latencia TTFT pura por proveedor de backend una al lado de la otra en el panel de Grafana, se redujo en 6 segundos el tiempo de procesamiento de respuesta de la tubería de generación de resúmenes de atención al cliente.
La mayoría de los servidores de inferencia LLM vacían instantáneamente el código de estado 200 OK y luego detienen la transmisión de carga útil durante unos segundos hasta que se carga el caché KV. Para evitar que los usuarios vean una pantalla congelada, es necesario operar un motor en tiempo de ejecución que detecte en tiempo real el retraso en la recepción del primer byte del token y realice una conmutación por error (failover) a un modelo alternativo.
Se implementa el enrutamiento de reserva (fallback) en tiempo de ejecución combinando un bucle de eventos asíncrono y la lógica de control de transmisiones. Se define un diccionario de configuración que incluye los puntos finales y las cabeceras de autenticación del primer y segundo proveedor, estableciendo el umbral de tiempo de espera en 2.0 segundos. Se llama al flujo del primer proveedor mediante un iterador asíncrono y se utiliza la función asyncio.wait_for para verificar si el primer token llega dentro del umbral especificado. Si se produce un tiempo de espera (timeout), el primer flujo se cancela inmediatamente para recuperar el socket y los recursos, y el tráfico se transfiere de inmediato al flujo del segundo proveedor en un estado sin pérdidas donde ni un solo byte de token ha sido entregado al cliente descendiente.
Según los datos de referencia de cobertura adaptativa (adaptive hedging), al operar una capa de transporte que genera solicitudes de respaldo cuando se producen retrasos, la latencia de cola P99 disminuyó de 64.3 milisegundos a 17.0 milisegundos, lo que representa un efecto de reducción de la latencia del 73.6 por ciento. Incluso en situaciones de fallo parcial del primer proveedor, se defiende a la perfección el tiempo de inactividad percibido por el usuario.
