Arranque en frio de un LLM en Kubernetes: 200 de 294 segundos no se dedican a cargar los pesos

La idea resulta atractiva: las solicitudes al modelo llegan varias veces al dia, pero el nodo con GPU se paga las 24 horas del dia, los 7 dias de la semana. La opcion logica es eliminar los pods entre solicitudes y levantarlos cuando aparezca carga. Esto funciona para un servicio web convencional: un retraso de un par de segundos no molestara a nadie. Con los LLM, la situacion es distinta.

Por que un LLM tarda tanto en arrancar

Despues de iniciar el pod, hay que descargar la imagen, cargar los pesos en la GPU, compilar los grafos y calentar el motor. En julio, el equipo de H Company escribio que una nueva replica de sus modelos mas grandes podia tardar hasta 27 minutos en estar lista. Utilizan vLLM en nodos de Kubernetes con GPU y agregan replicas a medida que aumenta la carga generada por los agentes. El autoescalador incrementa rapidamente el numero de pods, pero la configuracion del escalado no puede acelerar todas estas etapas de preparacion.

El autor del analisis esperaba que la carga de los pesos consumiera la mayor parte del tiempo. Las mediciones publicas mostraron lo contrario. En Tensorfuse, el arranque de Llama 3.1 8B en una L40S tardo 294 segundos. La descarga del modelo y la transferencia de los pesos a la GPU solo requirieron 94 segundos. Los 200 segundos restantes se dedicaron a la compilacion, la captura de grafos CUDA, la inicializacion del motor y las importaciones.

Que se puede almacenar en cache

Un detalle importante: una parte considerable de este trabajo se repite cada vez que arranca un pod, aunque sus resultados pueden conservarse en el nodo. Ahi se encuentra la principal oportunidad de aceleracion. Si los artefactos de compilacion se mantienen en el nodo y los pesos se descargan de antemano, el nuevo pod no tiene que empezar desde cero.

En el articulo completo, el autor promete abordar la parte practica:

• de donde obtiene KEDA la señal de carga cuando no hay ningun pod;
• que conviene almacenar en cache por adelantado;
• que tiempos de espera permiten que la primera solicitud aguarde al modelo;
• manifiestos de KEDA HTTP Add-on, un DaemonSet de precarga y la configuracion de vLLM.

La señal de carga merece una mencion aparte. Cuando no hay pods, tampoco hay metricas que obtener de ellos, por lo que se necesita un componente delante del servicio. KEDA HTTP Add-on intercepta la solicitud, levanta el pod y mantiene la conexion hasta que el modelo esta listo. Los tiempos de espera son cruciales: el cliente, la pasarela y el ingress no deben cerrar la conexion antes de que el modelo termine de calentarse.

Limitaciones y conclusion

Incluso despues de todas las optimizaciones, el arranque en frio no se reducira a unos segundos. Si se trata de un chat interactivo en el que el usuario no esta dispuesto a esperar un minuto, el escalado a cero sera una mala eleccion. Para tareas en segundo plano, herramientas internas, lotes y agentes que toleren el retraso, este esquema puede ahorrar una cantidad considerable de dinero.

La conclusion practica para los ingenieros de plataformas es que, antes de optimizar la descarga de los pesos, deben comprobar adonde se va realmente el tiempo. Segun las mediciones publicas, mas de dos tercios del arranque corresponden a la compilacion y la inicializacion, no a la red. Almacenar en cache estas etapas en el nodo aporta mas que un disco rapido.

Por ultimo, hay que evaluar con honestidad el perfil de carga. Si las solicitudes son poco frecuentes y predecibles, mantener cero replicas compensa. Si los usuarios esperan una respuesta inmediata, es mejor conservar una replica caliente y pagar por ella que pagar por los clientes perdidos.