NVIDIA a livré Dynamo Snapshot v1.1.1 aujourd'hui, un système de checkpoint/restore Kubernetes pour les charges d'inférence AI, disponible à github.com/ai-dynamo/dynamo avec le container snapshot-agent sur NGC. L'architecture pair deux outils : CRIU (Checkpoint/Restore in Userspace), le mécanisme de freeze/thaw de process Linux de longue date, avec cuda-checkpoint, une capability plus récente du driver CUDA qui dump l'état device GPU (contexts, streams, device memory, virtual mappings) en CPU memory. L'ordre matter : cuda-checkpoint déplace l'état GPU vers CPU memory d'abord, puis CRIU sérialise CPU memory, threads, file descriptors et namespaces vers le storage. Restore renverse la chaîne. La latence de cold start pour les charges d'inférence sur Kubernetes a historiquement été des minutes, et Dynamo Snapshot rapporte l'initialisation gpt-oss-120b qui tombe de plusieurs minutes à sous cinq secondes (speedup 21x), avec le restore Qwen3-8B passant de 24 secondes (CRIU upstream) à 4,7 secondes (5,1x) après optimisation.
Le mécanisme qui vaut la pause c'est l'optimisation de taille du KV cache. Les charges d'inférence portent de larges KV caches qui autrement domineraient l'artifact du snapshot. Dynamo Snapshot préserve les virtual addresses mais release la mémoire physique via cuMemUnmap et cuMemRelease avant la capture, droppant la taille d'artifact de 190 GiB à 6 GiB pour Qwen3-0.6B sur B200. Sur restore, les addresses sont reconstituées et le cache est re-warmed. L'intégration K8s utilise trois custom resources : un snapshot-agent DaemonSet privilégié, un DynamoCheckpoint CR qui définit le model config à snapshoter, et un DynamoGraphDeployment CR qui référence le checkpoint pour le restore. Les hooks quiesce et resume fire entre l'initialisation du engine et le startup du runtime distribué via signal files. Les requirements hardware sont des nodes GPU x86_64 avec NVIDIA driver 580.xx ou plus récent (590.xx ou plus récent pour multi-GPU) et storage ReadWriteMany pour le restore cross-node. Les limitations matter et NVIDIA les disclose : backend vLLM seulement dans cette limited preview, checkpoints single-GPU seulement avec multi-GPU planifié, GMS (GPU Memory Service pour weight restoration concurrent) est PoC-only, les optimisations CRIU utilisant AIO et parallel memfd sont pending upstream merge plutôt que déjà shippées, le restore est sensible au live TCP socket state, et le requirement de DaemonSet privilégié est non-trivial pour certaines postures de sécurité cluster.
Deux fils d'écosystème à tracker. Premièrement, le cold start a été l'argument structurel contre l'autoscaling d'inférence AI sur Kubernetes depuis que les gens le font. Spinner un nouveau pod prend des minutes ; les spikes de demande n'attendent pas des minutes ; les violations de SLA suivent. Les mitigations standard ont été l'over-provisioning (payer pour GPU idle), les warm pools (encore payer pour GPU idle), et le model streaming (plus rapide mais encore 30 à 90 secondes). Le restore sub-5-second change cette math matériellement. Si reproductible sur ta charge, c'est la première solution crédible au problème de l'inférence AI élastique sur Kubernetes plutôt qu'un workaround. Deuxièmement, les limitations sont la lecture substantielle sur le timing d'adoption. vLLM-only et single-GPU-only veulent dire que Dynamo Snapshot fit présentement une shape de deployment spécifique (single-GPU vLLM serving) plutôt qu'une capability K8s générale. L'intégration TensorRT-LLM, les workers multimodaux, embedding et diffusion, multi-node, multi-GPU sont tous sur la roadmap mais pas shippés. Les merges CRIU upstream (AIO et parallel memfd) sont le path pour élargir l'adoption au-delà du fork NVIDIA. Pour les builders qui évaluent ça pour production, la question c'est si ton stack match les limitations courantes ou tu attends le prochain quarter.
Lundi matin, si tu roules vLLM sur Kubernetes avec inférence single-GPU et a payé pour du warm-pool GPU idle pour absorber les spikes de demande : essaie Dynamo Snapshot sur un cluster non-production contre ta charge réelle. Le 21x pour gpt-oss-120b est l'upper bound ; ton chiffre réel dépend de l'IO storage (ReadWriteMany matter), de la taille du modèle, et de combien agressivement tu exercises le path d'unmap du KV cache. Si t'es sur TensorRT-LLM ou multi-GPU aujourd'hui, monitor la roadmap et les merges CRIU upstream plutôt que de parier sur Dynamo Snapshot comme option courante. Si tu construis des plateformes d'inférence plus largement, l'architecture two-tool (cuda-checkpoint pour l'état GPU, CRIU pour CPU et state du process, avec préservation de virtual address du KV cache) est le pattern engineering qui vaut l'étude indépendamment de si tu adoptes Dynamo Snapshot lui-même. Et si t'opères des clusters où les DaemonSets privilégiés sont un non-starter pour raisons de sécurité, ce n'est pas la solution pour toi encore ; l'architecture requiert présentement le container privilégié pour driver cuda-checkpoint et CRIU au niveau host.