AWS muestra cómo ejecutar una sola LLM en dos nodos GPU de EKS con Ray LLM DLC

AWS ha publicado una guía paso a paso para ejecutar una gran LLM en dos nodos GPU de Amazon EKS. Un nodo realiza el prefill y el otro el decode, y desde fuera todo se ve como un único endpoint compatible con OpenAI. La base son los multi-node Ray LLM Deep Learning Containers: imágenes listas para usar que ya empaquetan todo el stack de inferencia. El equipo deja de ocuparse del ensamblaje de componentes y solo le queda la configuración del despliegue.

Qué es exactamente lo que se despliega

El esquema es sencillo. Hay una sola modelo, dos nodos GPU en un clúster de Amazon EKS y dos etapas distintas del procesamiento de la solicitud, repartidas en máquinas diferentes. La aplicación cliente no sabe nada de la topología. Se dirige a una única dirección mediante el protocolo habitual de OpenAI, y los SDK y las herramientas existentes siguen funcionando sin cambios.

Lo relevante del lanzamiento no es la idea en sí, sino el empaquetado. Hasta ahora, montar inferencia multinodo implicaba elegir uno mismo versiones compatibles del motor, el orquestador, los drivers y las librerías de red. Ahora AWS lo entrega como un contenedor preconstruido de la línea Deep Learning Containers. Que la imagen incluya soporte para Ray tiene lógica: Ray lleva tiempo siendo la capa de orquestación de cargas distribuidas, y su extensión para LLM está pensada para servir modelos a través de una API única.

Por qué separar prefill y decode

La generación de texto tiene dos fases con perfiles de carga distintos. El prefill procesa el prompt de entrada completo. Son cálculos densos y el límite lo marca el rendimiento de la GPU. El decode produce los tokens uno a uno y suele toparse con el ancho de banda de memoria y el tamaño de la KV-cache.

Si ambas fases se ejecutan en los mismos aceleradores, se estorban entre sí. El prompt largo de un usuario retrasa la entrega de tokens a los demás. Separarlas por nodos permite ajustar cada lado por separado: elegir el paralelismo, el tamaño del batch y la cantidad de memoria según su tarea. El precio de este enfoque es conocido. Hay que transferir la KV-cache entre nodos, por lo que importan la red y la configuración correcta del conector. Esa es precisamente la parte de la que se encarga el contenedor.

Parámetros clave del esquema

• Modelo: una gran LLM distribuida entre los nodos.
• Topología: dos nodos GPU, uno dedicado al prefill y otro al decode.
• Plataforma: Amazon EKS, es decir, Kubernetes estándar en versión gestionada.
• Interfaz: un único endpoint compatible con OpenAI para todos los clientes.
• Entrega: un multi-node Ray LLM Deep Learning Container preconstruido con el stack de inferencia completo.
• Enfoque de configuración: configuración del despliegue sin ensamblar los componentes a mano.

En la práctica: qué revisar antes de adoptarlo

Esta arquitectura no se justifica en todos los casos. Para una modelo pequeña que cabe en un solo nodo, la desagregación solo añadirá saltos de red y puntos de fallo. Tiene sentido cuando la modelo no cabe en la memoria de un nodo o cuando el perfil de tráfico es muy heterogéneo. Por ejemplo, contextos largos de entrada con respuestas cortas de salida, o al revés.

Antes de un piloto conviene comprobar varios puntos:

• Conectividad entre nodos. La transferencia de la KV-cache es sensible a la latencia y al ancho de banda, así que conviene colocar los nodos en la misma zona de disponibilidad y consultar la documentación de AWS sobre los tipos de instancia y los adaptadores de red compatibles.
• Métricas por fase. Hay que vigilar el tiempo hasta el primer token, que depende del prefill, y la velocidad de generación de tokens, que depende del decode. La latencia media global oculta los desequilibrios.
• Equilibrio entre nodos. Un nodo por fase es un punto de partida. Si la cola se acumula en uno de los lados, habrá que escalarlo de forma independiente.
• Compatibilidad de los clientes. Una API compatible con OpenAI simplifica la migración, pero el comportamiento de los parámetros de solicitud poco habituales es mejor verificarlo con los escenarios propios.

Para los equipos que ya trabajan sobre EKS y buscan una forma de servir modelos grandes sin una plataforma de inferencia propia, es un camino rápido hacia un prototipo funcional. El coste y el rendimiento real debe medirlos cada equipo con su propio tráfico: la guía describe el despliegue, pero no garantiza una mejora concreta.