AWS apunta a los retrasos de inferencia en SageMaker con el almacenamiento en caché de modelos de HyperPod y el enrutamiento por prefijo

AWS está incorporando dos funciones de infraestructura dirigidas a cuellos de botella distintos, pero relacionados, en la prestación de modelos de lenguaje grandes: almacenamiento en caché de modelos para Amazon SageMaker HyperPod y enrutamiento con conocimiento de prefijo para SageMaker Inference. La primera está diseñada para acortar el tiempo necesario para poner en línea nuevos pods de inferencia; la segunda pretende reducir la latencia de respuesta manteniendo el cálculo de prompts reutilizado con frecuencia en la misma instancia.

Los cambios importan sobre todo para equipos que operan modelos grandes con tráfico variable. Sin almacenamiento en caché, un evento de escalado horizontal puede obligar a nuevos nodos a descargar imágenes de contenedores y pesos de modelo de varios gigabytes antes de poder atender solicitudes. Sin un enrutamiento que tenga en cuenta el contenido del prompt, la caché de prefijo de un framework de serving puede infrautilizarse porque se distribuyen secciones idénticas del prompt por toda una flota.

Ambos anuncios proceden del AWS Machine Learning Blog, por lo que las cifras de rendimiento y las afirmaciones operativas son reportadas por AWS y no verificadas de forma independiente. En conjunto, describen un enfoque más coordinado para reducir tanto los arranques en frío de inferencia como el tiempo hasta el primer token en estado estable.

El almacenamiento en caché de HyperPod aborda la brecha del escalado horizontal

AWS afirma que el despliegue de modelos en SageMaker HyperPod puede retrasarse por dos descargas secuenciales. Kubernetes primero extrae una imagen del servidor de inferencia desde Amazon Elastic Container Registry, tras lo cual el servidor descarga los pesos del modelo desde una fuente como Amazon S3, Amazon FSx for Lustre, Hugging Face Hub o JumpStart.

Para modelos más pequeños, este proceso puede tardar minutos. AWS pone como ejemplo un modelo de 145 GB cuya descarga de pesos puede tardar más de 20 minutos desde Amazon S3, según las condiciones de red. Para un modelo como DeepSeek-R1, que AWS describe como de más de 600 GB en el escenario citado, el proceso puede tardar 30 minutos o más. Solo la extracción de la imagen del contenedor se estima por AWS en cinco a siete minutos para imágenes de inferencia multigigabyte típicas.

Ese retraso crea una desalineación entre el autoscaling y la capacidad real. Un HorizontalPodAutoscaler puede solicitar rápidamente pods adicionales, pero esos pods no pueden aceptar tráfico hasta que sus imágenes y pesos estén disponibles. Un pico repentino de solicitudes puede, por tanto, desencadenar una respuesta operativa que llega decenas de minutos tarde.

La nueva capacidad de almacenamiento en caché de modelos precarga los pesos en almacenamiento NVMe local en los nodos de destino. AWS dice que el HyperPod Inference Operator descarga los pesos por adelantado, marca los nodos como listos para caché y espera a que los nodos de destino completen el proceso antes de crear el despliegue de inferencia. Una vez que un pod arranca en un nodo preparado, puede leer localmente a aproximadamente 7 GB por segundo en lugar de descargar el modelo por la red.

AWS también ofrece una caché de imágenes independiente. Un DaemonSet precarga la imagen del contenedor de inferencia en los nodos, permitiendo que los pods posteriores se salten la descarga desde Amazon Elastic Container Registry. Varios despliegues que usen la misma imagen pueden compartir esa caché, mientras el operador gestiona referencias y limpieza.

Cómo se comportan los dos sistemas de caché en producción

El almacenamiento en caché de pesos y de imágenes no tiene la misma semántica de despliegue. AWS dice que la caché de pesos puede retrasar la creación del despliegue de inferencia hasta que todos los nodos de destino estén listos, mientras que la caché de imágenes no bloquea la creación del despliegue. Un pod puede, por tanto, arrancar antes de que una caché de imágenes haya terminado en un nodo concreto y recurrir a una extracción normal de la imagen.

Ambos mecanismos utilizan programación preferente en lugar de obligatoria. Los pods se dirigen hacia nodos con datos calientes cuando es posible, pero no se les impide ejecutarse en otros lugares. Si un escalado horizontal rápido supera el número de nodos preparados, un pod puede usar la fuente original del modelo y descargar su imagen con normalidad. La contrapartida es un arranque más lento, no un despliegue fallido.

El operador gestiona dos recursos personalizados subyacentes: ModelDataCacheConfig para los pesos del modelo y ModelImageCache para las imágenes de contenedor. Los usuarios habilitan el almacenamiento en caché mediante modelCacheConfig en un recurso InferenceEndpointConfig o JumpStartModel, en lugar de gestionar directamente esos objetos de ciclo de vida.

AWS también afirma que las actualizaciones de caché se gestionan cuando cambia una fuente de modelo o una imagen. El operador crea una nueva caché, despliega la actualización y luego elimina la caché antigua. Eso pretende evitar pesos obsoletos y, al mismo tiempo, soportar transiciones sin tiempo de inactividad, aunque el resultado práctico seguirá dependiendo del almacenamiento disponible en los nodos y del tiempo necesario para poblar la caché de reemplazo.

El enrutamiento con conocimiento de prefijo mantiene útiles las cachés de prompts de LLM

El segundo cambio de SageMaker apunta a otra capa del stack de serving. Muchas solicitudes de LLM contienen un prefijo largo y repetido —como instrucciones del sistema, documentos recuperados, historial de conversación o código fuente— seguido de un sufijo breve específico del usuario. Frameworks como vLLM y TensorRT-LLM pueden reutilizar la caché de key-value, o KV, calculada para ese prefijo repetido.

La distribución aleatoria de solicitudes debilita ese beneficio en un endpoint con varias instancias. Si solicitudes sucesivas con el mismo prefijo llegan a máquinas distintas, cada instancia puede tener que recalcular el contexto compartido. La nueva estrategia de enrutamiento con conocimiento de prefijo de SageMaker Inference examina el comienzo de una solicitud y envía de forma consistente los prefijos coincidentes a la misma instancia.

AWS dice que la función también puede proteger a la flota de un prefijo excesivamente popular. Si la instancia preferida alcanza su límite de concurrencia configurado, la solicitud puede redirigirse a una instancia menos ocupada. Eso puede sacrificar un acierto de caché para una solicitud, pero evita concentrar el tráfico en una sola máquina. AWS añade además que incorporar o eliminar instancias debería desplazar solo una porción limitada del tráfico, ayudando a preservar la localidad de la caché durante el escalado.

La estrategia se configura por variante de producción y puede modificarse mediante la configuración del endpoint sin volver a desplegar el modelo. AWS sigue ofreciendo enrutamiento aleatorio como opción predeterminada, junto con enrutamiento de menos solicitudes pendientes para cargas de trabajo en las que la duración de las solicitudes varía. El enrutamiento con conocimiento de prefijo está orientado específicamente a cargas de trabajo de LLM con contexto inicial compartido y caché de prefijo habilitada.

Evidencia, benchmarks y límites

AWS comparó el enrutamiento con conocimiento de prefijo con el enrutamiento aleatorio usando Llama 3.1 70B Instruct en siete instancias ml.p5.48xlarge con vLLM y caché de prefijo habilitados. En 16 configuraciones de prueba que cubrían distintos arreglos de endpoint y API, AWS informa de una reducción de hasta el 77% en el tiempo mediano hasta el primer token, mejoras de rendimiento de hasta el 16% y un aumento en la tasa de aciertos de la caché KV de aproximadamente el 25% a más del 80%.

Se trata de resultados de benchmark reportados por el proveedor, no de una evaluación independiente. AWS dice que el tráfico se mantuvo equilibrado en las pruebas, con cada instancia recibiendo entre el 13,3% y el 15,4% de las solicitudes. También informa de un coste adicional de enrutamiento de 1,3 a 1,9 milisegundos por solicitud, en comparación con resultados de tiempo hasta el primer token del modelo que oscilan entre 63 y 280 milisegundos en las configuraciones probadas.

La magnitud del beneficio depende mucho de la forma de la carga de trabajo. AWS dice que los prefijos compartidos más largos generan mayores ganancias porque se puede omitir más cómputo. Entre los casos de uso que AWS identifica están los sistemas RAG que consultan repetidamente el mismo documento, las conversaciones multi-turno, los asistentes basados en plantillas y la completación de código. Las cargas de trabajo con prompts cortos o mayoritariamente únicos deberían ver menos valor.

Las afirmaciones sobre HyperPod dependen de condiciones que tampoco están totalmente especificadas en la fuente, incluyendo disponibilidad de nodos, tiempo de población de la caché, capacidad de almacenamiento, formato del modelo y rendimiento de red durante la precarga inicial. La transición declarada de decenas de minutos a segundos se aplica cuando un pod aterriza en un nodo que ya tiene almacenados los datos relevantes; un nodo sin preparar sigue la ruta normal de descarga.

Qué significan los cambios para los equipos de infraestructura de IA

Para los desarrolladores y los equipos de plataforma empresarial, los anuncios separan dos decisiones que a menudo se tratan como un solo problema de latencia. El almacenamiento en caché de modelos mejora la elasticidad: puede hacer que la nueva capacidad sea útil antes cuando aumenta el tráfico. El enrutamiento con conocimiento de prefijo mejora la eficiencia de las solicitudes: puede reducir el trabajo repetido de prefill una vez que la capacidad ya está en línea.

La combinación podría ser útil para aplicaciones RAG y asistentes que tienen tanto tráfico en ráfagas como grandes contextos repetidos. Un equipo podría usar el almacenamiento en caché de HyperPod para preparar nodos para el escalado horizontal mientras usa el enrutamiento con conocimiento de prefijo para mantener calientes los prefijos de documentos o conversaciones en la flota activa. Eso no elimina la necesidad de dimensionar la capacidad local NVMe, configurar límites de concurrencia o medir las tasas de acierto de caché con tráfico real.

También hay cuestiones de coste y fiabilidad que los compradores deben probar. Mantener los pesos en cada nodo de destino consume almacenamiento local y puede aumentar el tiempo de preparación antes de que un despliegue esté listo. La afinidad por prefijo puede mejorar la latencia, pero introduce un comportamiento de enrutamiento dependiente del contenido que los equipos deberían observar junto con la profundidad de cola, la utilización de instancias, la ocupación de la caché y la latencia de cola larga. Las revisiones de privacidad y gobernanza de datos también pueden ser relevantes porque las decisiones de enrutamiento inspeccionan el comienzo de los payloads de las solicitudes, aunque AWS gestione el enrutamiento automáticamente.

Qué vigilar a continuación

Los equipos que evalúen estas funciones deberían buscar resultados reproducidos de forma independiente en modelos, hardware y distribuciones de prompts más allá de la prueba de AWS con Llama 3.1 70B. Las métricas más útiles incluirán p95 y p99 del tiempo hasta el primer token, tasas de acierto de caché durante el escalado horizontal y el porcentaje de solicitudes que llegan a nodos no preparados.

También serán importantes las orientaciones operativas sobre dimensionamiento de NVMe local, orquestación de calentamiento de caché y clústeres multi-modelo. Los compradores deberían verificar cómo afecta la preparación de la caché a los despliegues, al reemplazo de nodos, a escenarios spot o de interrupción y al escalado rápido más allá de la flota precargada.

Por último, los controles de enrutamiento a nivel de endpoint de AWS pueden ganar importancia a medida que las plataformas de serving alojadas compiten más por la latencia predecible que por el mero acceso al modelo. La señal a seguir será si los clientes pueden usar estos controles sin añadir una complejidad de programación sustancial ni sacrificar una utilización equilibrada de GPU.

Perspectiva de Creati.ai

AWS está abordando dos debilidades prácticas en las operaciones de LLM en lugar de introducir una nueva capacidad del modelo. El almacenamiento en caché de modelos de HyperPod reduce la penalización por añadir capacidad, mientras que el enrutamiento con conocimiento de prefijo hace más fiable a través de varias instancias una optimización de serving ya existente: la reutilización de la caché KV.

El caso más sólido es para cargas de trabajo predecibles y de contexto repetido con suficiente tráfico como para justificar la precarga de modelos grandes. Para equipos con prompts mayoritariamente únicos o despliegues poco frecuentes, la sobrecarga de almacenamiento y preparación puede superar las ganancias. Las cifras de benchmark de AWS son alentadoras, pero los compradores de infraestructura deberían validarlas frente a su propio solapamiento de prompts, patrones de escalado y objetivos de latencia antes de considerar el almacenamiento en caché como una mejora garantizada.