Dynamo Snapshot usa CRIU + cuda-checkpoint para inicio K8s bajo 5s

NVIDIA lanzó Dynamo Snapshot v1.1.1 hoy, un sistema de checkpoint/restore de Kubernetes para cargas de inferencia AI, disponible en github.com/ai-dynamo/dynamo con el container snapshot-agent en NGC. La arquitectura empareja dos herramientas: CRIU (Checkpoint/Restore in Userspace), el mecanismo de freeze/thaw de proceso Linux de larga data, con cuda-checkpoint, una capability más reciente en el driver CUDA que vuelca el estado device GPU (contexts, streams, device memory, virtual mappings) a CPU memory. El orden importa: cuda-checkpoint mueve el estado GPU a CPU memory primero, luego CRIU serializa CPU memory, threads, file descriptors y namespaces a storage. Restore invierte la cadena. La latencia de cold start para cargas de inferencia en Kubernetes ha sido históricamente minutos, y Dynamo Snapshot reporta la inicialización de gpt-oss-120b cayendo de varios minutos a bajo cinco segundos (speedup 21x), con el restore de Qwen3-8B yendo de 24 segundos (CRIU upstream) a 4,7 segundos (5,1x) después de optimización.

El mecanismo que vale pausar es la optimización del tamaño del KV cache. Las cargas de inferencia llevan grandes KV caches que de otro modo dominarían el artifact del snapshot. Dynamo Snapshot preserva las virtual addresses pero libera la memoria física vía cuMemUnmap y cuMemRelease antes de la captura, dropeando el tamaño del artifact de 190 GiB a 6 GiB para Qwen3-0.6B en B200. En el restore, las addresses son reconstituidas y el cache es re-warmed. La integración K8s usa tres custom resources: un snapshot-agent DaemonSet privilegiado, un DynamoCheckpoint CR que define el model config a snapshotear, y un DynamoGraphDeployment CR que referencia el checkpoint para el restore. Los hooks quiesce y resume disparan entre la inicialización del engine y el startup del runtime distribuido vía signal files. Los requirements de hardware son nodos GPU x86_64 con NVIDIA driver 580.xx o más nuevo (590.xx o más nuevo para multi-GPU) y storage ReadWriteMany para el restore cross-node. Las limitaciones importan y NVIDIA las disclose: backend vLLM solamente en este limited preview, checkpoints single-GPU solamente con multi-GPU planeado, GMS (GPU Memory Service para weight restoration concurrente) es PoC-only, las optimizaciones CRIU usando AIO y parallel memfd están pending upstream merge en vez de ya shipeadas, el restore es sensible al live TCP socket state, y el requirement de DaemonSet privilegiado es non-trivial para algunas posturas de seguridad de cluster.

Dos hilos de ecosistema a trackear. Primero, el cold start ha sido el argumento estructural contra el autoscaling de inferencia AI en Kubernetes desde que la gente lo ha estado haciendo. Spinear un nuevo pod toma minutos; los spikes de demanda no esperan minutos; las violaciones de SLA siguen. Las mitigaciones estándar han sido over-provisioning (pagar por GPU idle), warm pools (todavía pagar por GPU idle), y model streaming (más rápido pero todavía 30 a 90 segundos). El restore sub-5-segundos cambia esa math materialmente. Si reproducible en tu carga, esta es la primera solución creíble al problema de inferencia AI elástica en Kubernetes en vez de un workaround. Segundo, las limitaciones son la lectura sustantiva sobre el timing de adopción. vLLM-only y single-GPU-only significan que Dynamo Snapshot actualmente cabe una shape de deployment específica (serving vLLM single-GPU) en vez de una capability K8s general. La integración TensorRT-LLM, workers multimodales, workers de embedding y diffusion, multi-node, multi-GPU están todos en la roadmap pero no shipeados. Los merges CRIU upstream (AIO y parallel memfd) son el path para ampliar la adopción más allá del fork de NVIDIA. Para builders evaluando esto para producción, la pregunta es si tu stack iguala las limitaciones actuales o esperas el próximo quarter.

Lunes por la mañana, si corres vLLM en Kubernetes con inferencia single-GPU y has estado pagando por warm-pool GPU idle para absorber spikes de demanda: prueba Dynamo Snapshot en un cluster no-producción contra tu carga real. El 21x para gpt-oss-120b es el upper bound; tu número real depende de IO de storage (ReadWriteMany importa), tamaño del modelo, y qué tan agresivamente ejercitas el path de unmap del KV cache. Si estás en TensorRT-LLM o multi-GPU hoy, monitorea la roadmap y los merges CRIU upstream en vez de apostar a Dynamo Snapshot como opción actual. Si construyes plataformas de inferencia más ampliamente, la arquitectura two-tool (cuda-checkpoint para estado GPU, CRIU para CPU y estado de proceso, con preservación de virtual address del KV cache) es el patrón de engineering que vale la pena estudiar independientemente de si adoptas Dynamo Snapshot mismo. Y si operas clusters donde DaemonSets privilegiados son un non-starter por razones de seguridad, esta no es la solución para ti todavía; la arquitectura actualmente requiere el container privilegiado para drivar cuda-checkpoint y CRIU al nivel del host.