El tiempo de inicio en nodos GPU para inferencias de modelos de inteligencia artificial es una barrera significativa que afecta la eficiencia operativa y el coste en el despliegue de aplicaciones. Un equipo de investigación ha analizado en detalle el proceso completo que va desde la creación de un pod hasta la primera respuesta de inferencia en nodos GPU ejecutando modelos de gran tamaño, alcanzando una notable reducción en el tiempo de arranque.
El análisis se centró en modelos de clase 70B, encontrando que originalmente el arranque tomaba aproximadamente ocho minutos, divididos en seis fases sucesivas. Contrario a lo esperado, en lugar de un único cuello de botella, identificaron seis, cada uno con un impacto diferente según el tamaño del modelo.
En concreto, para un modelo de 64 GB, el 65 % del tiempo se invertía en recompilar kernels CUDA que generaban resultados idénticos en cada ejecución. Por su parte, en un modelo de 203 GB, el 92 % del tiempo se destinaba a la descarga de pesos desde el almacenamiento S3, mediante un patrón de llamada que dejaba el 98 % del ancho de banda disponible sin usar. Ambos problemas son corregibles mediante cambios en la configuración, pero ninguno se soluciona con las configuraciones predeterminadas. 
¿Qué es el tiempo hasta el primer token servido?
El equipo definió el tiempo hasta el primer token servido (TTFTS) como la duración desde la creación de un pod hasta que la GPU entrega la primera respuesta de inferencia. Este concepto se diferencia del tiempo de latencia por solicitud una vez el modelo está caliente (TTFT). TTFTS representa un coste inicial que se paga solo una vez con cada arranque o escalado.
Resultados alcanzados
| Escenario | Descripción | Antes | Después | Reducción |
|---|---|---|---|---|
| Reinicio de pod en nodo caliente | Carga de pesos y compilación en nodo ya existente | 1,5-8 minutos | menos de 30 segundos | 80-93 % |
| Nuevo nodo desde cero | Nodo provisionado sin cachés previos | 8-15 minutos | unos 5 minutos | 40-65 % |
La mejoría en nodos calientes se refleja en cualquier reinicio de pod, ya sea por escalado, actualizaciones o recuperación tras falta de memoria, y solo requiere ajustes de configuración que funcionan en cualquier clúster Kubernetes. El caso de nodo frío incluye además un coste fijo de dos minutos por el aprovisionamiento y arranque del nodo que no puede eliminarse con cambios en el nivel de la aplicación.
Las mejoras en nodos fríos se deben en parte a la utilización del modo automático de EKS, que cuenta con controladores NVIDIA precompilados, extracción paralela de imágenes con tecnología SOCI y montaje automático de almacenamiento NVMe de la instancia.
Las seis fases del arranque en frío
- Aprovisionamiento del nodo: lanzamiento y registro del nodo EC2 en Kubernetes (60-90 s).
- Inicialización del controlador GPU: carga de módulos kernel y habilitación del hardware.
- Descarga de la imagen de contenedor: la imagen del motor de inferencia (8-12 GB comprimida) se transfiere y descomprime en el nodo.
- Descarga de pesos del modelo: transmisión de los archivos del modelo desde almacenamiento a la memoria GPU.
- Compilación de kernels GPU: PyTorch compila gráficamente los kernels CUDA optimizados para el modelo.
- Inicialización del motor: captura de gráficos CUDA, perfilado de caché y puesta en marcha del servidor HTTP.
Cada etapa tiene su propio cuello de botella y necesidad de solución, dependientes del tamaño del modelo.
Dominancia según tamaño del modelo
El estudio midió las fases cuatro y cinco para dos configuraciones:
- Modelo de 64 GB: la compilación toma el 65 % del tiempo total (~53 s), y la carga de pesos el 35 % (~29 s).
- Modelo de 203 GB: la descarga de pesos es predominante con el 92 % (~423 s), mientras que la compilación solo absorbe el 8 % (~34 s).
Esto indica que la optimización debe enfocarse en la compilación para modelos pequeños y en la transferencia de datos para los grandes, pues la compilación permanece constante y la descarga escala linealmente con el tamaño.
Detalle de mejoras clave por fase
Inicialización y aprovisionamiento (fases 1 y 2): precompilar los controladores GPU durante la creación de la imagen evita retrasos de 2 a 3 minutos causados por compilaciones en tiempo real, bajando el tiempo de inicio a segundos en EKS Auto Mode.
Descarga de la imagen de contenedor (fase 3): el uso del sistema SOCI para descargas paralelas aprovecha múltiples núcleos CPU, reduciendo el tiempo de transferencia de la imagen de 2-4 minutos a 30-60 segundos en nodos con alta potencia de cómputo.
Carga de pesos (fase 4): ajustando el tamaño de fragmentos a 4 GB —coincidiendo con el tamaño típico de archivos SafeTensors— y empleando un sistema que cancela conexiones lentas y relanza la descarga, se lograron mejoras espectaculares sin modificar código: en el modelo de 203 GB, la descarga pasó de 423 a 25 segundos.
Compilación de kernels (fase 5): la caché de compilación se almacena en discos NVMe locales, accesible por pods posteriores sin recompilar, permitiendo que el tiempo se reduzca de cerca de un minuto a apenas 4-6 segundos en reinicios.
Inicialización del motor (fase 6): con kernels ya compilados, la captura de gráficos y perfilado se reduce a menos de un minuto, contribuyendo a un arranque más ágil.
Impacto económico y operativo
Los nodos GPU, especialmente modelos avanzados como p5.48xlarge que cuesta 55 dólares por hora, suponen un elevado coste asociado al tiempo ocioso. Cada minuto adicional en el arranque significa pago por recursos sin entregar valor. Con unos arranques más rápidos, es posible escalar de forma más agresiva, reducir capacidad sobrante e incluso afrontar picos de tráfico con menor latencia.
Lecciones aprendidas
- Descomponer el proceso para identificar correctamente el cuello de botella según el tamaño del modelo.
- La naturaleza cambiante del obstáculo requiere distintas estrategias para distintos tamaños de modelos.
- El aumento de paralelismo debe entender la estructura de ejecución: demasiadas conexiones concurrentes pueden no acelerar si no aprovechan la verdadera concurrencia.
- Pequeños caches de compilación pueden ahorrar decenas de segundos, siendo una optimización de alto impacto con poco coste.
- Las decisiones a nivel plataforma son clave para lograr mejoras que la simple configuración no puede alcanzar.
- El ecosistema Kubernetes avanza en funcionalidades para inferencia, pero el arranque en frío implica capas que requieren soluciones específicas y colaborativas.
El estudio está basado en mediciones realizadas en instancias p5.48xlarge con Amazon EKS Auto Mode, almacenamiento S3 optimizado y configuraciones estándar de Kubernetes para despliegues de inteligencia artificial.
