NVIDIA Dynamo Snapshot: startup rapido per carichi di lavoro AI inference su Kubernetes

In produzione, i carichi di inferenza AI devono scalare rapidamente per rispondere ai picchi di domanda. Su Kubernetes, però, l’avvio a freddo di una replica può richiedere diversi minuti: il tempo necessario per scaricare l’immagine del container, caricare i pesi del modello in GPU, riscaldare i kernel CUDA, compilare i CUDA graph e registrarsi nel service discovery. Durante questi minuti, le GPU sono allocate ma non producono token.

Per risolvere il problema, il team di ricerca AI di NVIDIA ha introdotto Dynamo Snapshot, un sistema di checkpoint/restore pensato per carichi di inferenza su Kubernetes.

Come funziona CRIU e cuda-checkpoint

Dynamo Snapshot si basa su due strumenti: CRIU (Checkpoint/Restore in Userspace) per lo stato CPU (memoria, thread, file descriptor, namespace) e cuda-checkpoint per lo stato GPU (contesti CUDA, stream, memoria, mapping di indirizzi virtuali). Il checkpointing avviene in due fasi ordinate: prima cuda-checkpoint salva lo stato GPU nella memoria CPU del processo, poi CRIU serializza l’intero albero dei processi su disco. Al ripristino, CRIU ricostruisce il processo, poi cuda-checkpoint ripristina lo stato GPU sulla nuova scheda.

«CRIU è un meccanismo di freeze-and-thaw. Quando un processo viene ripristinato, riprende l’esecuzione dall’istruzione esatta in cui è stato checkpointato, completamente inconsapevole che sia avvenuto un checkpoint o un ripristino.»

Dynamo Snapshot su Kubernetes

NVIDIA fornisce un DaemonSet privilegiato chiamato snapshot-agent, installabile tramite Helm chart. Ogni agente su ciascun nodo gestisce checkpoint e restore per container runc, senza modificare runc stesso. Durante il checkpoint, l’agente attende il probe di readiness del carico, invoca cuda-checkpoint e CRIU, e salva l’artefatto in uno storage condiviso (NFS, SMB, ecc.). Al restore, lancia un pod placeholder leggero, ripristina il filesystem overlay e il checkpoint CRIU/CUDA nei suoi namespace.

L’approccio DaemonSet è stato scelto perché portabile (non dipende da feature gate del cloud provider), permette un controllo più stretto su CRIU per il tuning delle prestazioni e consente di archiviare gli artefatti in backend di storage flessibili.

Hooks di quiesce/resume

Un worker di inferenza Dynamo si inizializza in due fasi ordinate: prima l’inizializzazione del motore (pesi, kernel, CUDA graph), poi l’avvio del runtime distribuito (connessione al control plane Dynamo). Se il checkpoint venisse preso dopo la seconda fase, le connessioni TCP aperte non potrebbero essere catturate da CRIU. La soluzione è un meccanismo di quiesce/resume: il worker scrive un file segnale “pronto per checkpoint” dopo l’inizializzazione del motore, ma prima del runtime distribuito. Entra quindi in un loop di polling in attesa del file “ripristino completato”, mentre l’agente esegue il checkpoint. Al restore, il worker riprende dal loop, rileva il file e prosegue con l’inizializzazione del runtime.

Ottimizzazione 1: KV cache unmap e release

Dopo aver allocato pesi e buffer, il motore di inferenza alloca la memoria GPU rimanente come buffer KV cache. Poiché il checkpoint viene preso prima che la replica serva richieste, questo buffer non va checkpointato. La soluzione è allocare la KV cache tramite l’API CUDA Virtual Memory Management, quindi liberare l’allocazione fisica con cuMemUnmap e cuMemRelease, ma non l’indirizzo virtuale. Per Qwen3-0.6B su una B200, questo riduce la dimensione totale dell’artefatto da ~190 GiB a ~6 GiB.

Ottimizzazione 2: parallelizzare il restore di CRIU

Anche con artefatti più piccoli, il tempo di restore di CRIU rimane un collo di bottiglia per modelli grandi. NVIDIA ha sviluppato due ottimizzazioni (non ancora integrate in Dynamo Snapshot, in attesa di merge in upstream CRIU):

• Parallel memfd restore: i buffer delle weight spostati in memoria pinned CPU appaiono nel kernel Linux come memfd, file anonimi mappati con MAP_SHARED. La modifica a CRIU usa un thread pool per ripristinarli in parallelo, sfruttando la larghezza di banda dello storage e il parallelismo della CPU.
• Linux native AIO per memoria anonima: per migliorare ulteriormente il throughput di restore.

NVIDIA ha pubblicato il codice e i dettagli tecnici completi sul suo blog.