AWS lanza SageMaker HyperPod Inference Gateway para enrutamiento con conciencia de GPU

Amazon Web Services anunció Amazon SageMaker HyperPod Inference Gateway el 18 de septiembre de 2026, un sistema de enrutamiento nativo de Kubernetes y con conciencia de GPU para inferencia de modelos de lenguaje grande que se implementa como un único complemento gestionado para Amazon EKS sobre la infraestructura HyperPod existente. AWS dijo que la puerta de enlace puede reducir la latencia del primer token hasta un 82%.

El problema de enrutamiento detrás de la puerta de enlace

Según AWS, los algoritmos predeterminados de balanceo de carga de Kubernetes, como round-robin y least-connections, no tienen visibilidad del estado de la GPU: qué pods tienen cachés KV saturadas, cuáles están a mitad de generaciones de contexto largo y cuáles ya tienen cargado en memoria el adaptador LoRA que una solicitud necesita. La compañía dijo que las solicitudes se acumulan detrás de los pods ocupados mientras la capacidad inactiva queda sin usar, la latencia del primer token se dispara por encima de los cuatro segundos durante picos de tráfico, la utilización se vuelve desigual e impredecible, y los operadores sobredimensionan para compensar. AWS describió un escenario en el que un usuario de chatbot que espera 4,4 segundos por el primer token, en su lugar lo recibe en menos de 800 milisegundos.

Arquitectura de dos niveles

La puerta de enlace utiliza un diseño de dos niveles basado en primitivas nativas de Kubernetes. AWS dijo que usa señales de GPU en tiempo real para colocar cada solicitud de inferencia en el pod más adecuado. El Nivel 1 se instala directamente en cada HyperPod o clúster EKS como el complemento amazon-sagemaker-hyperpod-inference y consta de tres componentes, todos construidos sobre la extensión de código abierto Gateway API Inference Extension. Envoy Gateway, un proxy de capa 7, termina el tráfico HTTPS entrante y expone un único punto de enlace privado por clúster. El enrutador basado en el cuerpo inspecciona cada cuerpo de solicitud compatible con OpenAI, extrae el campo modelo y dirige la solicitud al grupo de modelos correcto, de modo que una puerta de enlace pueda servir varios modelos.

El Selector de Punto Final consume métricas de Prometheus en tiempo real de cada pod que sirve modelos y aplica un algoritmo de puntuación ponderada entre los evaluadores que cubren la utilización de la caché KV, la profundidad de la cola, la residencia del adaptador LoRA, la tasa de aciertos de la caché de prefijos y las solicitudes en ejecución. Cada evaluador lleva un peso configurable, lo que permite ajustar el comportamiento de enrutamiento para una carga de trabajo específica, como chat sensible a la latencia frente a lotes optimizados para rendimiento.

El Nivel 2, el Global Inference Router, está anunciado como próximamente. AWS dijo que añadirá coordinación a nivel de flota entre múltiples clústeres y regiones, con conmutación por error entre clústeres, limitación global de velocidad y modelado de tráfico con conciencia de costos. El Nivel 2 se construye sobre el Nivel 1, mientras que la puerta de enlace por clúster de cada clúster sigue manejando el enrutamiento local.

Despliegue, manejo de fallos y observabilidad

El despliegue consiste en un único comando aws eks create-addon y un recurso personalizado declarativo InferenceGatewayConfig que define los modelos y el comportamiento de enrutamiento, con implementaciones de servidores de modelos existentes descubiertas a través de etiquetas de pods. AWS dijo que la instalación no requiere sidecars, malla de servicios ni cambios en el código de la aplicación. La puerta de enlace expone un punto de enlace estándar compatible con OpenAI sobre HTTP; según AWS, el código cliente existente funciona sin cambios, sin modificaciones del SDK y sin firma SigV4 para el tráfico de inferencia.

Para cargas de trabajo que sirven adaptadores LoRA afinados en un modelo base compartido, el LoRA Affinity Scorer del Selector de Punto Final dirige las solicitudes de adaptador a los pods que ya tienen el adaptador solicitado residente en memoria GPU; si ningún pod lo tiene cargado, la solicitud se envía al pod con mayor capacidad disponible. AWS dijo que esto elimina la latencia de intercambio de adaptadores.

Los comportamientos de falla documentados cubren fallas de pod, agotamiento de pool, fallas de clúster y fallas regionales. Ante una falla de pod, el Selector de Punto Final excluye los pods con métricas obsoletas y dirige el tráfico a pods saludables, recuperándose automáticamente cuando las métricas se reanudan. Ante el agotamiento de pool, la puerta de enlace devuelve HTTP 429 con un encabezado Retry-After mientras el escalado automático añade capacidad. Ante una falla de clúster, el Global Inference Router detecta un latido del corazón obsoleto y redirige el tráfico en un plazo de 35 segundos, con un aumento gradual cuando el clúster se vuelve a introducir. Ante una falla regional, el enrutamiento entre regiones se activa automáticamente, lo que AWS dijo que conlleva mayor latencia pero sin impacto en la disponibilidad.

La puerta de enlace emite métricas a nivel de pod, pool, clúster y flota: utilización de la caché KV, profundidad de la cola, solicitudes en ejecución y residencia del adaptador a través de Prometheus a nivel de pod; totales de solicitudes, histogramas de duración y recuentos de tokens a través de Prometheus y Grafana a nivel de pool; promedio de caché KV, tasa de error y latencia P99 a través de Amazon CloudWatch a nivel de clúster; y decisiones de enrutamiento, eventos de conmutación por error y golpes de límite de velocidad a través de CloudWatch a nivel de flota.

Resultados de referencia reportados por AWS

AWS dijo que realizó pruebas de referencia a cuatro modelos que van desde 8 B hasta 235 B de parámetros en instancias p5.48xlarge con GPUs H100 e instancias g5 con GPUs A10G. Todo el tráfico se enrutó a través de equilibradores de carga de aplicación internos, coincidiendo con la ruta que sigue una solicitud de producción, con un grupo de nodos cliente dedicado que genera carga controlada y servidores de modelo aislados en un grupo de nodos de servidor separado. Cada resultado utiliza la configuración de enrutamiento predeterminada de la puerta de enlace sin ajustes y se mide frente a una línea base de round-robin de Kubernetes en las mismas réplicas de modelo, según AWS.

En los resultados reportados, una flota de GPU de generación mixta redujo la latencia P95 y P99 de tiempo hasta el primer token en un 97 % cada una para Llama-3.1-8B, con un aumento del 8 % en el rendimiento, y en un 98 % y 97 % para Qwen3-32B, con un aumento del 50 % en el rendimiento. Con tráfico intermitente, Llama-3.1-70B mostró reducciones P95 y P99 del 94 % y 98 % con un 12 % más de rendimiento, mientras que Qwen3-235B presentó una latencia P95 comparable y una P99 un 89 % menor. Con prefijos de solicitud compartidos, la latencia P95 y P99 de Llama-3.1-8B disminuyó un 26 % y un 43 %.

AWS afirmó que, con una flota totalmente uniforme bajo tráfico constante, la puerta de enlace funciona al mismo nivel que el round-robin, y definió resultados comparables como diferencias dentro de la variabilidad entre ejecuciones. La compañía señaló que las mejoras son mayores donde el round-robin tiene más dificultades: hardware mixto, demanda intermitente y prefijos de solicitud compartidos.

Disponibilidad y hoja de ruta

AWS describe la puerta de enlace como conforme a la Kubernetes Gateway API y su Extensión de Inferencia, configurada mediante una única definición de recurso personalizado, y compatible con cualquier servidor de modelos compatible con OpenAI, incluidos vLLM, SGLang y TGI. La gestión se realiza a través de kubectl, GitOps, Helm y ArgoCD, y la instalación, actualizaciones y reversión se manejan mediante el ciclo de vida del complemento de EKS.

El enrutamiento de nivel 1 por clúster está disponible a partir del 18 de septiembre de 2026 en las regiones donde el complemento de inferencia está disponible. Más allá del Global Inference Router, los elementos de la hoja de ruta de AWS incluyen la división de tráfico canario, que dirigirá un porcentaje del tráfico a nuevas versiones de modelo mediante recursos personalizados InferenceModelRewrite, y el control de flujo que clasifica las solicitudes como Crítica, Estándar o Descartable con control de admisión por banda.