Phase 17 - Lesson 10

Mitigación de Cold Start para LLMs Serverless

Una imagen de modelo de 20 GB tarda de 5 a 10 minutos (7B) a más de 20 minutos (70B) en pasar de cold a serving. En un entorno serverless real, esto no es un precalentamiento: es una caída del servicio. Las mitigaciones operan en cinco niveles: imágenes de nodos presembradas (Bottlerocket en AWS, arquitectura de doble volumen), model streaming (NVIDIA Run:ai Model Streamer, nativo en vLLM), snapshots de memoria de GPU (checkpoints de Modal, reinicio hasta 10x más rápido), warm pools (min_workers=1), carga escalonada (el flujo NVMe→DRAM→HBM de ServerlessLLM, reducción de latencia de 10-200x) y migración en vivo que mueve tokens de entrada (KB) en lugar de la caché KV (GB). Modal publica cold starts de 2-4s como mínimo; el valor predeterminado de Baseten es de 5-10s, y de menos de un segundo con precalentamiento. Esta lección le enseña a medir, presupuestar y apilar estos cinco niveles.

Tipo: Learn Idiomas: Python (stdlib, simulador básico de flujo de cold-start) Prerrequisitos: Phase 17 · 02 (Inference Platform Economics), Phase 17 · 03 (GPU Autoscaling) Tiempo: ~60 minutos

Objetivos de Aprendizaje

Enumerar los cinco niveles de mitigación de cold-start e identificar una herramienta o patrón en cada nivel.
Calcular el tiempo total de cold-start como la suma de (provisión del nodo) + (descarga de pesos) + (carga de pesos en HBM) + (inicialización del motor) para un modelo de 70B.
Explicar por qué la migración en vivo transfiere tokens de entrada (KB) y no la caché KV (GB), y cuál es la penalización de este proceso (recomputación).
Nombrar el compromiso de warm-pool (pagar por una GPU inactiva o aceptar la cola de cold-start) y el umbral de SLA en el que min_workers > 0 se vuelve obligatorio.

El Problema

Su endpoint de LLM serverless se escala a cero durante la noche. A las 8 a.m. se produce un pico de tráfico. La primera solicitud espera mientras:

Karpenter aprovisiona un nodo GPU: 45-60s.
El contenedor descarga una imagen de 30 GB con los pesos del modelo: 120-300s.
El motor carga los pesos en la HBM: 45-120s según el tamaño del modelo y la velocidad de almacenamiento.
vLLM o TRT-LLM inicializan los gráficos de CUDA, el pool de caché KV y el tokenizador: 10-30s.

Total: 220-510s (aproximadamente entre 3 y 8 minutos) antes de recibir el primer token. Su SLA es de 2s. Si implementa una warm-pool (min_workers=1), el problema parece desaparecer, pero ahora paga por una GPU inactiva las 24 horas del día, los 7 días de la semana. Si su servicio tiene 5 productos, cada uno con una réplica warm, eso representa 5 × 24 × 30 = 3,600 horas-GPU/mes, independientemente de si algún usuario realizó una llamada.

La mitigación de cold-start es la forma de mantener las ventajas económicas de serverless mientras se aproxima a la latencia de un sistema siempre activo (always-on).

El Concepto

Nivel 1: imágenes de nodos presembradas (Bottlerocket)

En AWS, la arquitectura de doble volumen de Bottlerocket separa el sistema operativo de los datos. Realice una snapshot del volumen de datos con la imagen de su contenedor predescargada; haga referencia al ID de la snapshot en su EC2NodeClass. Los nuevos nodos se inician con los pesos ya en el NVMe local: los pasos 2 y parte del 3 desaparecen. Funciona con Karpenter de forma nativa. Ahorro típico: 2-4 minutos por cold-start para modelos grandes.

Equivalente en GCP: imágenes de VM personalizadas con capas de contenedor preintegradas. En Azure: snapshots de disco administrado con el mismo patrón.

Nivel 2: model streaming (Run:ai Model Streamer)

En lugar de cargar el archivo completo antes de responder a la primera solicitud, transmita los pesos a la memoria de la GPU capa por capa y comience el procesamiento tan pronto como el primer bloque de transformer esté residente. El Run:ai Model Streamer de NVIDIA se incluye de forma nativa en vLLM en 2026. Funciona con S3, GCS y NVMe local. Reduce el tiempo de carga de pesos a la mitad aproximadamente para modelos grandes al superponer la E/S con la configuración del cómputo.

Nivel 3: snapshots de memoria de GPU (Modal)

Modal realiza un checkpoint del estado de la GPU (pesos, gráficos CUDA, región de caché KV) después de la primera carga. Los reinicios posteriores se deserializan directamente en la HBM, lo que es hasta 10 veces más rápido que volver a inicializar. Esto es lo más parecido a "iniciar una GPU caliente en 2 segundos". Compromiso: las snapshots son por topología de GPU, de modo que si Karpenter realiza una migración a un SKU diferente, se debe volver a realizar el checkpoint.

Nivel 4: warm pools (min_workers=1)

La mitigación más sencilla: mantener una réplica siempre lista. El costo es la tarifa horaria de una GPU las 24 horas del día, los 7 días de la semana. La aritmética es dura para los modelos pequeños (se paga entre $0.85 y

.50/h para evitar un cold-start de 30s) y favorable para los grandes (se paga $4/h para evitar un cold-start de 5 minutos). El umbral de SLA donde las warm pools se vuelven obligatorias: típicamente TTFT P99 < 60s en un modelo de más de 70B.

Nivel 5: carga escalonada (ServerlessLLM)

ServerlessLLM trata el almacenamiento como una jerarquía: NVMe (rápido pero grande), DRAM (mediano pero escalonado) e HBM (pequeño pero instantáneo). Los pesos se precargan en DRAM; carga bajo demanda en HBM. El artículo reporta una reducción de latencia de 10 a 200 veces en cargas frías en comparación con el proceso directo de disco a HBM. La adopción en producción es temprana, pero existen integraciones con vLLM.

Nivel 6: migración en vivo (patrón bónus)

Cuando un nodo deja de estar disponible (desalojo spot, vaciado de nodo), el patrón tradicional consiste en iniciar en frío otra réplica y vaciar la cola de solicitudes. La migración en vivo mueve los tokens de entrada (kilobytes) a un destino que tiene el modelo cargado y recalcula la caché KV en el destino. El cálculo es más económico que transferir gigabytes de caché KV a través de la red. Aplicable a implementaciones desagregadas.

La aritmética de las warm-pools

Para un servicio con un SLA de TTFT P99 de 2s, la pregunta no es "warm pool sí/no", sino "cuántas réplicas calientes y qué rutas las obtienen".

Rutas interactivas de alto valor (chat en vivo, asistente de voz): min_workers=1-2.
Rutas por lotes en segundo plano (clasificación nocturna): se acepta escala a cero, latencia de cold-start de 5 a 10 minutos tolerable.
Nivel Premium: min_workers por inquilino (tenant) con capacidad dedicada.

Medir antes de optimizar

Desglose del cold-start para un modelo de 70B en un nodo limpio (ilustrativo):

Fase	Tiempo	Mitigación
Provisión de nodo	50s	Bottlerocket + imagen presembrada, warm pool
Descarga de imagen	180s	Volumen de datos presembrado (eliminar)
Pesos a HBM	75s	Model streamer (reducir a la mitad); snapshot de GPU (eliminar)
Inicialización del motor	20s	Caché de gráfico CUDA persistente
Primer forward	3s	Latencia inherente mínima
Total en frío (cold)	328s
Total con mitigaciones	~15s	Reducción de 22x

Números que debe recordar

Cold start en Modal: 2-4s (con snapshots de GPU).
Cold start por defecto en Baseten: 5-10s; menos de un segundo con precalentamiento.
Cold start de 70B sin optimizar: 3-8 minutos.
Run:ai Model Streamer: ~2x de aceleración en la carga de pesos.
Carga escalonada de ServerlessLLM: reducción de latencia de 10 a 200 veces (cifras del artículo).

Utilízalo

code/main.py modela una ruta de cold-start con y sin cada mitigación. Reporta el tiempo total de cold-start, el costo de la warm-pool y la tasa de solicitudes de equilibrio por encima de la cual la warm-pool se paga sola en comparación con las solicitudes descartadas.

Entrégalo

Esta lección produce outputs/skill-cold-start-planner.md. Dados el SLA, el tamaño del modelo y el perfil del tráfico, selecciona qué mitigaciones apilar.

Ejercicios

Ejecute code/main.py. Calcule la tasa de solicitudes de equilibrio por encima de la cual una réplica warm es más barata que pagar la penalización de cold-start por pérdida de solicitudes en el límite del SLO.
Implementa un modelo de 13B con un SLA de TTFT P99 de 3s. Elija la pila de mitigación mínima (menor número de niveles) que lo logre.
El presembrado de Bottlerocket elimina la descarga de imagen, pero los pesos aún deben cargarse desde el snapshot a la HBM. Calcule el tiempo real (wall-clock) para un modelo de 70B si el NVMe respaldado por snapshot lee a 7 GB/s.
Su proveedor serverless ofrece snapshots de GPU (Modal) y su equipo se niega porque "las snapshots filtran PII (datos de identificación personal)". Defienda ambas posturas: cuál es el riesgo real y cuál la mitigación (snapshots efímeras, cifrado, aislamiento de namespaces).
Diseñe una política de warm-pool escalonada: ¿cuántas réplicas calientes para usuarios de pago, usuarios de prueba gratuita y cargas de trabajo por lotes? Muestre las fórmulas y cálculos que lo respaldan.

Términos Clave

Termo	O que as pessoas dizem	O que realmente significa
Cold start	"la gran pausa"	Tiempo transcurrido desde la solicitud hasta el primer token en una réplica limpia
Warm pool	"mínimo siempre activo"	Configuración de `min_workers >= 1` para mantener al menos una réplica lista
Imagen presembrada	"AMI horneada"	Imagen de nodo con los pesos del contenedor ya residentes de forma local
Bottlerocket	"OS de nodos de AWS"	OS optimizado para contenedores en AWS con soporte para snapshots de doble volumen
Model streamer	"carga por flujo"	Superponer la E/S de pesos con la configuración de cómputo
Snapshot de GPU	"checkpoint a HBM"	Serializar el estado de la GPU después de la carga; deserializar al reiniciar
Carga escalonada	"NVMe + DRAM + HBM"	Jerarquía de niveles de almacenamiento; carga bajo demanda
Migración en vivo	"mover tokens"	Transferir la entrada (KB), recalcular la caché KV en el destino
`min_workers`	"réplicas warm"	Cantidad mínima de instancias activas mantenidas por el orquestador serverless
Escala a cero	"serverless completo"	Costo cero cuando está inactivo; se acepta toda la penalidad del cold-start

Leituras Adicionais

Modal — Cold start performance — Benchmarks de rendimiento publicados por Modal y arquitectura de checkpoints.
AWS Bottlerocket — Patrón de snapshot de volumen de datos presembrado.
NVIDIA Run:ai Model Streamer — Superponer la carga de pesos con la configuración de cómputo.
Baseten — Cold-start mitigation — Guía de precalentamiento.
ServerlessLLM paper (USENIX OSDI'24) — Diseño de carga escalonada.
NVIDIA — Disaggregated LLM Inference on Kubernetes — Migración en vivo para implementaciones desagregadas.