NVIDIA Dynamo Snapshot Acelera el Inicio de Inferencia de IA en Kubernetes de Minutos a Segundos

El Problema del Cold Start en Producción

¡Hola Devs! Si alguna vez has intentado escalar inferencia de IA en Kubernetes, sabes de lo que hablo: cuando la demanda sube, las GPUs tardan minutos en estar listas. Mientras tanto, están asignadas pero ociosas — quemando dinero sin servir ni una petición. Eso es el cold start, y puede arruinar tus SLAs.

Para una workload single-GPU con vLLM, el tiempo de arranque se desglosa así:

• Carga de pesos: 60-80%
• Compilación de grafos CUDA: 10-15%
• Calentamiento de kernels: 5-10%
• Registro en runtime distribuido: 5-10%

NVIDIA acaba de presentar Dynamo Snapshot, un enfoque de checkpoint/restore que reduce ese tiempo hasta acercarse al límite teórico de la memoria (speed of light). Vamos a ver los detalles técnicos, basados en el artículo original del blog de NVIDIA.

¿Cómo Funciona? CRIU + CUDA Checkpoint en Equipo

La idea es simple: en lugar de inicializar todo desde cero, toma un snapshot del worker ya caliente y restáuralo en segundos.

El Checkpoint en Dos Capas

Se complementan perfectamente: cuda-checkpoint vuelca el estado de la GPU a la RAM, y CRIU serializa el árbol de procesos al disco. Al restaurar (incluso en otro nodo), CRIU rehidrata el estado del host, y cuda-checkpoint reconecta la memoria de la GPU.

Integración con Kubernetes vía DaemonSet

NVIDIA creó un DaemonSet privilegiado llamado snapshot-agent, instalable con Helm. Este:

• Corre en todos los nodos
• Hace checkpoint/restore de contenedores runc sin modificar runc
• Guarda los artefactos en almacenamiento compartido (NFS/SMB)
• Se paraleliza automáticamente por el clúster

# Ejemplo: despliegue del snapshot-agent con Helm
helm repo add nvidia-dynamo https://nvidia.github.io/dynamo
helm install snapshot-agent nvidia-dynamo/snapshot-agent \
  --set storage.backend=nfs \
  --set storage.nfs.server=10.0.0.1 \
  --set storage.nfs.path=/exports/checkpoints

El Patrón Quiesce/Resume

El mayor reto: después de restaurar, el worker necesita reconectarse al plano de control. La solución usa archivos de señalización:

1. Worker inicializa el motor → escribe ready_for_checkpoint.signal
2. Worker entra en un loop de polling esperando restore_complete.signal
3. snapshot-agent hace el checkpoint dentro de ese loop
4. Al restaurar, CRIU retoma exactamente en la misma instrucción → el worker ve la nueva señal → continúa la inicialización

# Pseudocódigo del hook quiesce/resume
import os
import time

SIGNAL_DIR = "/tmp/dynamo"
READY_FILE = os.path.join(SIGNAL_DIR, "ready_for_checkpoint.signal")
RESTORE_FILE = os.path.join(SIGNAL_DIR, "restore_complete.signal")

def initialize_engine():
    # Carga pesos, compila grafos, calienta kernels
    print("[Engine] Inicialización completa")
    # Señaliza que está listo para checkpoint
    with open(READY_FILE, "w") as f:
        f.write("ready")

def wait_for_restore():
    # Espera hasta detectar restauración
    while not os.path.exists(RESTORE_FILE):
        time.sleep(0.1)
    print("[Worker] Restauración detectada, reanudando runtime")
    # Ahora conecta al plano de control
    register_with_dynamo_control_plane()

if __name__ == "__main__":
    initialize_engine()
    wait_for_restore()

Cuatro Optimizaciones que lo Cambian Todo

1. Desasignar el KV Cache Antes del Checkpoint

Antes de tomar el snapshot, el worker libera el caché KV (como no ha atendido ninguna petición). Usando la API de Gestión de Memoria Virtual de CUDA (cuMemUnmap / cuMemRelease), la dirección virtual se mantiene estable para los grafos CUDA, pero la memoria física se libera. Esto reduce el tamaño del checkpoint de ~190 GiB a ~6 GiB en modelos pequeños.

2. Restauración Paralela de memfd

Los pesos de los modelos viven en memfd (memoria anónima compartida). El CRIU original restaura esos buffers uno por uno. NVIDIA modificó CRIU para usar un pool de hilos, restaurando todos los buffers en paralelo. Ganancia de 5-8x en modelos grandes.

3. AIO Nativo de Linux para Memoria Anónima

En lugar del loop síncrono preadv (una lectura a la vez), Dynamo Snapshot usa AIO nativo de Linux con io_submit e io_getevents. Hasta 128 lecturas simultáneas, saturando NVMe o almacenamiento en red. Combinado con O_DIRECT para no contaminar la caché de página, los tiempos de restauración se acercan al SOL.

4. GPU Memory Service (GMS) — El Remate Final

Incluso con CRIU optimizado, mover los pesos del almacenamiento a la CPU y luego a la GPU es un cuello de botella serial. GMS desacopla la restauración de los pesos de la restauración del proceso usando CUDA VMM:

• Checkpoint CRIU se reduce a ~5-7 GiB (solo estado del proceso)
• Artefacto de pesos (~74 GiB para gpt-oss-120b) se restaura concurrentemente vía GPUDirect Storage (GDS) o stripes de NVMe
• Tiempo total de arranque baja de 5+ minutos a menos de 5 segundos — 21x de mejora

# Flujo conceptual: GMS restaura pesos en paralelo con CRIU
# Proceso 1: Restauración CRIU (5-7 GiB)
criu restore -d --images-dir /checkpoints/criu/ &

# Proceso 2: Restauración de pesos vía GDS
gms_restore --backend gds --source /checkpoints/weights/ --gpu-id 0 &

wait  # Ambos completan concurrentemente

Limitaciones y Precauciones

• Solo single-GPU por ahora: El soporte multi-GPU y multi-nodo está en el roadmap, pero requiere manejar conexiones NCCL, estado RDMA y cambios de IP de los pods.
• Optimizaciones CRIU aún no upstream: Las modificaciones (memfd paralelo, AIO) se enviarán al CRIU oficial, pero por ahora vienen solo con Dynamo Snapshot.
• Dependencia de almacenamiento rápido: En NFS lento sin O_DIRECT, las ganancias se reducen.
• Requiere integración con el framework: Los hooks quiesce/resume necesitan soporte en vLLM o SGLang. No todos los frameworks implementan sleep()/wake_up() nativamente.

¿Qué Sigue?

• GMS con backends enchufables: GDS, UCX, RDMA/NVLink entre GPUs (esperando parche del driver CUDA)
• Soporte para TensorRT-LLM
• Multi-GPU y multi-nodo con hooks para PyTorch, NCCL, NIXL

Si ejecutas inferencia en producción sobre Kubernetes, este es el enfoque más prometedor para acabar con el cold start desde que las GPUs se popularizaron. La versión experimental ya soporta vLLM y SGLang single-GPU — vale la pena probarlo en tu entorno de staging.

Junto con: Microsoft Sovereign Cloud: Ejecutando Grandes Modelos de IA Totalmente Desconectados — explora cómo la gobernanza de IA desconectada complementa el arranque rápido para industrias reguladas.

También mira: Visión 2026 de Microsoft para Bases de Datos: Datos Unificados, Agentes de IA y el Nuevo Fabric Hub — la infraestructura de datos que alimentará estas workloads de inferencia de escalado rápido.