En despliegues de inferencia productivos, la demanda fluctua a lo largo del dia y las replicas tienen que escalar de forma elastica. El problema es que arrancar en frio un worker de inferencia sobre Kubernetes puede tomar varios minutos. Durante esa ventana, las GPUs estan asignadas pero ociosas: no generan tokens, no atienden requests y la cuenta sigue corriendo. El riesgo de incumplir el SLA crece en cada pico, porque el sistema no alcanza a absorber la demanda a tiempo.
Para un workload single-GPU con vLLM v0.20.0, el cold-start se descompone en varias etapas (carga de pesos, inicializacion del engine, warmup de kernels, captura de grafos CUDA, registro en el control plane). NVIDIA propone Dynamo Snapshot, su enfoque de checkpoint y restore para Kubernetes, que en su prototipo inicial logra tiempos de restore cercanos al limite fisico de la memoria.
¿Que hace exactamente Dynamo Snapshot?
El estado de un worker de inferencia tiene dos componentes: estado del dispositivo (contextos CUDA, streams, memoria de GPU, mapeos virtuales) y estado del host (memoria CPU, threads, file descriptors, namespaces). Para serializar lo primero, NVIDIA usa la capacidad de checkpoint del driver CUDA, expuesta como la herramienta cuda-checkpoint. Para lo segundo, recurre a CRIU, un proyecto open source que recorre el bookkeeping del kernel Linux y vuelca el arbol de procesos a disco.
Las dos piezas se componen limpiamente: en el checkpoint, cuda-checkpoint baja el estado de la GPU a memoria CPU y CRIU serializa toda la jerarquia de procesos a una carpeta en almacenamiento distribuido. En el restore (mismo o distinto nodo), CRIU reconstruye el arbol de procesos desde NFS o SMB y cuda-checkpoint recarga el estado de la GPU. La ejecucion retoma exactamente en la instruccion donde fue capturada, sin que el proceso se entere de nada.
La arquitectura en Kubernetes
En clusters reales los workloads viven dentro de contenedores y pods. Como los checkpoints de CRIU contienen referencias al filesystem writable del contenedor, NVIDIA hace el checkpoint a nivel de contenedor, manteniendo el filesystem y el arbol de procesos juntos. Provee un DaemonSet privilegiado llamado snapshot-agent, instalable via Helm chart, que corre en cada nodo y maneja checkpoint y restore para contenedores administrados por runc, sin parchearlo.
En el checkpoint, el agente espera la senial de readiness del workload, invoca cuda-checkpoint y CRIU desde el host, y escribe el artefacto a almacenamiento compartido. En el restore lanza un pod placeholder liviano, restaura el overlay filesystem y reinyecta el checkpoint en los namespaces.
Que cada agente opere de forma independiente permite paralelizar los checkpoints y restores en todo el cluster. NVIDIA descarta la alternativa nativa de Kubernetes (checkpoint feature gate via runc, que tambien delega en CRIU) por dos razones: el DaemonSet es portable a cualquier proveedor cloud y da control mas fino sobre CRIU para tunear performance, ademas de permitir que los checkpoints vivan en backends de storage flexibles en vez de quedar embebidos en imagenes OCI.
Hooks de quiesce y resume: la pieza clave
Un worker de Dynamo arranca en dos fases. Primero la inicializacion del engine: se levantan los comunicadores, se cargan los pesos, se calientan los kernels y se capturan los grafos. Despues el arranque del runtime distribuido, donde el worker se conecta al control plane de Dynamo y se registra en el discovery backend.
Si CRIU capturase el snapshot despues del registro, habria conexiones TCP abiertas que CRIU no puede serializar. La solucion es un patron de quiesce/resume: el worker entra en estado quiescente y bloquea esperando una senial externa que dispara cuando el restore termino. En la practica, Dynamo Snapshot define la readiness probe como la presencia de un archivo "ready for checkpoint" que el worker escribe entre la inicializacion del engine y el arranque del runtime distribuido. Inmediatamente despues entra en un loop polling esperando un archivo "restore complete". El snapshot agent puede congelar el proceso en cualquier instruccion de ese loop.
Optimizacion 1: liberar el KV cache
La primera ganancia de tamaño viene de desalojar el KV cache antes del checkpoint. Los engines de inferencia asignan toda la memoria de GPU sobrante como buffer de KV cache. Como el checkpoint se toma en estado quiescente, antes de servir requests, ese buffer no necesita persistirse en absoluto.
Eso si, hay que mantener la direccion virtual del KV cache estable porque queda incorporada en el grafo CUDA. La solucion es asignar el buffer via la CUDA Virtual Memory Management API (cuMemCreate y cuMemMap) y liberar solo la asignacion fisica con cuMemUnmap y cuMemRelease, sin tocar cuMemAddressFree. Esta capacidad ya esta nativa en vLLM (via sleep() y wake_up()) y en SGLang (via torch_memory_saver).
El resultado es contundente: el artefacto total de Qwen3-0.6B sobre un B200 baja de 190 GiB a 6 GiB. La ganancia se nota mas cuanto mayor sea el KV cache respecto al peso del modelo.
Optimizacion 2: acelerar CRIU
Reducir tamaño no basta. CRIU y cuda-checkpoint no copian memoria a la velocidad limite del hardware, y en modelos grandes el tiempo de restore con upstream CRIU incluso supera al cold start, anulando el sentido del sistema.
NVIDIA aclara que las optimizaciones a CRIU todavia no estan empaquetadas con Dynamo Snapshot y se liberaran cuando se mergeen upstream. Entre las mejoras hay restore paralelo de memfd, uso de AIO nativa de Linux para acelerar la restauracion de memoria anonima, y un GPU Memory Service (GMS) que desacopla los pesos grandes del estado del proceso para restaurarlos en paralelo por canales de alto ancho de banda como GPUDirect Storage.
Tabla comparativa: cold start vs Dynamo Snapshot
| Escenario | Tiempo aprox. | Tamaño del artefacto |
|---|---|---|
| Cold start gpt-oss-120b | varios minutos | n/a (carga desde pesos) |
| Snapshot naive Qwen3-0.6B | similar a cold start | ~190 GiB |
| Snapshot + KV unmap | reducido | ~6 GiB |
| Snapshot + KV unmap + CRIU paralelo | hasta 21x mas rapido | ~6 GiB |
¿Como impacta esto a los integradores LatAm?
Para equipos en Chile o Brasil que arman pipelines de IA sobre H100 o B200 alquilados a proveedores cloud, cada minuto de GPU ociosa durante el scale-up cuesta entre USD 2 y USD 5 dependiendo de la region. Un cluster que escala 30 veces al dia para absorber picos puede estar pagando 90 minutos diarios de GPUs sin trabajo. Dynamo Snapshot apunta directo a ese gasto, aunque por ahora solo cubre workloads single-GPU; el soporte multi-GPU y multi-nodo, junto con la integracion a TensorRT-LLM, esta planificado para releases futuros.
El proyecto se distribuye bajo la licencia abierta de Dynamo y la pieza CRIU optimizada llegara como upstream del proyecto open source. Para quienes prefieran no esperar al merge, NVIDIA promete que las modificaciones estaran disponibles como patches separados.
