De la orquestación de contenedores al servicio de modelos: cargas de IA con GPU en Amazon EKS

Las preguntas de plataforma son familiares; la carga es diferente

Mi experiencia con Amazon EKS se ha centrado en operar plataformas cloud-native: aprovisionar clústeres, programar cargas, administrar acceso y construir la red y la observabilidad que las rodean. Llevé esa perspectiva al workshop Generative AI on EKS using NVIDIA GPU para ver qué cambia cuando la aplicación es un modelo de lenguaje que necesita capacidad de aceleradores.

La respuesta breve es que la base de Kubernetes resulta reconocible, pero la carga hace mucho más visibles algunos detalles operativos. La capacidad GPU debe estar disponible en el lugar adecuado. Los archivos del modelo deben llegar al servidor de inferencia. El motor de serving debe exponer un endpoint que puedan usar las aplicaciones. Y la salud del clúster por sí sola no basta para explicar si la inferencia está funcionando bien.

Empezar por la plataforma

La configuración de Terraform construye la base: una VPC con subredes públicas y privadas, un clúster de Amazon EKS Auto Mode, NodePools de sistema y de propósito general, y un NodePool y NodeClass dedicados a GPU. También prepara las integraciones que usa el workshop, incluidas EKS Pod Identity, almacenamiento del modelo en S3, un driver CSI para S3 y el stack de monitorización Prometheus y Grafana. Los recursos de soporte preparan ejercicios posteriores, como el repositorio de imágenes del agente Strands, almacenamiento RAG y una caché Valkey.

La captura de arquitectura en mis notas me ayudó a orientarme antes de desplegar cargas. Muestra el plano de control de EKS y sus capacidades administradas junto con los pools de sistema y de propósito general; los componentes de monitorización envían métricas a Amazon Managed Prometheus.

1. Arquitectura inicial de EKS Auto Mode.

La otra captura del clúster registra los NodePools y los Pods de monitorización, y muestra que durante la configuración restringí el CIDR de entrada del balanceador a mi propia IP pública.

2. Configuración del clúster: NodePools, Pods de monitorización y tráfico de entrada restringido.

La capacidad GPU es un requisito previo de infraestructura

Mi primera lección práctica llegó antes del serving del modelo. Al principio, crear una On-Demand Capacity Reservation para una g6e.xlarge en us-east-1 falló con InstanceLimitExceeded, porque la cuota de vCPU aplicable de la cuenta era cero. Una vez que la reserva está disponible, todavía hay que conectarla al GPU NodeClass: recuperé su ID, lo añadí al selector del NodeClass y revisé la configuración resultante.

La distinción importa. Crear una reserva no le indica por sí solo a EKS Auto Mode que la use. Después de habilitar el GPU NodePool con la ODCR activa, capturé la arquitectura actualizada.

3. GPU NodePool después de asociar la ODCR.

El pool GPU proporciona un destino de scheduling dedicado a las cargas aceleradas. Un Pod pequeño con nvidia-smi puede solicitar una GPU y servir como primera comprobación de que se aprovisiona un nodo adecuado y el contenedor puede ver el dispositivo. Es una comprobación útil de infraestructura antes de cargar un modelo; no es un benchmark de inferencia.

Mantener los artefactos del modelo en S3 y servirlos con vLLM

El modelo del workshop es Ministral-3-8B-Instruct-2512. Sus pesos y los archivos de configuración y tokenizer que los acompañan se almacenan en S3. En mi configuración, un Job de Kubernetes prepara los archivos del modelo en el bucket.

4. Job usado para preparar el modelo en S3.

Para el despliegue de serving con vLLM, Run:ai Model Streamer lee los pesos directamente desde S3, por lo que ese Pod de serving en particular no necesita un PersistentVolume ni un PersistentVolumeClaim. El entorno de Terraform también prepara el driver CSI para S3 y un PV/PVC respaldado por S3 para otros usos del workshop.

La carga de serving del modelo se ejecuta como un Deployment y Service de Kubernetes que usan un AWS Deep Learning Container con vLLM. El Pod solicita recursos GPU; si el pool GPU no tiene listo un nodo adecuado, EKS Auto Mode puede aprovisionarlo. EKS Pod Identity proporciona al workload acceso de AWS a S3 a través de su service account.

vLLM encaja bien en este ejercicio porque está diseñado para inferencia generativa. Continuous batching ayuda a atender solicitudes concurrentes, mientras que PagedAttention administra la memoria utilizada por la caché KV del modelo. Su API compatible con OpenAI también ofrece a las aplicaciones una forma conocida de llamar al modelo. Estas son capacidades del motor de serving, no resultados de rendimiento medidos en mi entorno.

Probar el endpoint y luego añadir una interfaz de usuario

El workshop primero prueba el Service de vLLM con un port-forward local y una solicitud de completion. La respuesta de la API incluye texto generado y uso de tokens, lo que ofrece una comprobación funcional básica antes de añadir una interfaz.

También desplegué Open WebUI y accedí a través de un Application Load Balancer aprovisionado desde un Ingress de Kubernetes. Esto hace concreta la diferencia entre el endpoint del modelo y una aplicación orientada a usuarios: vLLM sirve la inferencia; Open WebUI proporciona una interfaz web que llama al modelo.

5. Open WebUI expuesto a través del balanceador de carga.

Observar por separado la plataforma, la GPU y la inferencia

El stack de monitorización base incluye kube-prometheus-stack, Node Exporter, kube-state-metrics, Amazon Managed Prometheus, Grafana y Grafana Operator. Prometheus recopila métricas del clúster y de la aplicación y las envía a AMP; Grafana consulta esas métricas. EKS Pod Identity proporciona permisos de AWS a los workloads de monitorización.

El workshop añade NVIDIA DCGM Exporter para telemetría de GPU, como utilización, memoria, temperatura y consumo de energía. Después introduce métricas y dashboards de vLLM para señales como generación de tokens, latencia y procesamiento de solicitudes. Estas capas responden preguntas distintas: si el clúster está saludable, si se está usando la GPU y cómo el servicio de inferencia está gestionando las solicitudes. Mis capturas muestran los Pods de monitorización en el clúster; todavía falta registrar valores detallados de métricas desde los dashboards durante una ejecución.

6. Estado de los workloads después del despliegue, capturado en k9s.

Conectar un agente al modelo

El módulo Strands añade una aplicación que usa el endpoint de vLLM. El agente de ejemplo se empaqueta como contenedor Python, se publica en el repositorio ECR creado previamente y se despliega en EKS. Expone un endpoint HTTP y registra herramientas de hora y clima que el modelo puede invocar cuando una pregunta necesita información externa. En este ejemplo, cada solicitud crea una instancia nueva del agente, por lo que no conserva el historial de conversación entre solicitudes.

Probé el agente desplegado a través de su Service. Ante “¿Qué hora es en Dallas?”, respondió 3:00 PM CDT. Ante “¿Qué clima hace en Denver?”, devolvió cielo despejado y 25.9°C. Son comprobaciones funcionales de un momento concreto, no benchmarks; la hora local y el clima pueden cambiar. La captura de mis notas muestra ambas respuestas.

Cuando hace falta una herramienta, primero el modelo selecciona la llamada apropiada; después de que la herramienta devuelve datos, el modelo usa ese resultado para redactar la respuesta. Esto muestra cómo un endpoint de modelo autohospedado puede formar parte de un flujo de aplicación más amplio, con el agente y sus herramientas ejecutándose como workloads de Kubernetes.

Lo que me llevo

El workshop conectó varias preocupaciones conocidas de EKS —planificación de capacidad, scheduling, identidad, red, almacenamiento y observabilidad— con las necesidades particulares de la inferencia. La lección más útil hasta ahora es tratar el serving del modelo como un sistema con capas distintas: infraestructura aceleradora, entrega del modelo, API de inferencia, integración con la aplicación y telemetría.

Mi experiencia con EKS me ayudó a razonar sobre cómo encajan esas capas. El workshop me dio una manera concreta de inspeccionarlas, desde el aprovisionamiento GPU y el acceso a S3 hasta un endpoint de modelo funcional y un agente que usa herramientas externas. Como siguiente paso, capturaría métricas de inferencia repetibles y las compararía solo bajo una configuración de modelo, instancia y solicitud documentada con claridad.