A NVIDIA lançou Dynamo Snapshot v1.1.1 hoje, um sistema de checkpoint/restore de Kubernetes para cargas de inferência AI, disponível em github.com/ai-dynamo/dynamo com o container snapshot-agent na NGC. A arquitetura emparelha duas ferramentas: CRIU (Checkpoint/Restore in Userspace), o mecanismo de freeze/thaw de processo Linux de longa data, com cuda-checkpoint, uma capability mais recente no driver CUDA que despeja o estado device GPU (contexts, streams, device memory, virtual mappings) para CPU memory. A ordem importa: cuda-checkpoint move o estado GPU para CPU memory primeiro, depois CRIU serializa CPU memory, threads, file descriptors e namespaces para storage. Restore reverte a cadeia. A latência de cold start para cargas de inferência em Kubernetes tem sido historicamente minutos, e Dynamo Snapshot reporta a inicialização do gpt-oss-120b caindo de vários minutos a sob cinco segundos (speedup 21x), com o restore do Qwen3-8B indo de 24 segundos (CRIU upstream) a 4,7 segundos (5,1x) após otimização.
O mecanismo que vale pausar é a otimização do tamanho do KV cache. As cargas de inferência carregam grandes KV caches que de outro modo dominariam o artifact do snapshot. Dynamo Snapshot preserva as virtual addresses mas libera a memória física via cuMemUnmap e cuMemRelease antes da captura, dropando o tamanho do artifact de 190 GiB a 6 GiB para Qwen3-0.6B no B200. No restore, as addresses são reconstituídas e o cache é re-warmed. A integração K8s usa três custom resources: um snapshot-agent DaemonSet privilegiado, um DynamoCheckpoint CR que define o model config a snapshotar, e um DynamoGraphDeployment CR que referencia o checkpoint para o restore. Os hooks quiesce e resume disparam entre a inicialização do engine e o startup do runtime distribuído via signal files. Os requirements de hardware são nodes GPU x86_64 com NVIDIA driver 580.xx ou mais novo (590.xx ou mais novo para multi-GPU) e storage ReadWriteMany para o restore cross-node. As limitações importam e a NVIDIA as disclose: backend vLLM somente neste limited preview, checkpoints single-GPU somente com multi-GPU planejado, GMS (GPU Memory Service para weight restoration concorrente) é PoC-only, as otimizações CRIU usando AIO e parallel memfd estão pending upstream merge em vez de já shipadas, o restore é sensível ao live TCP socket state, e o requirement de DaemonSet privilegiado é non-trivial para algumas posturas de segurança de cluster.
Dois fios de ecossistema a trackear. Primeiro, o cold start tem sido o argumento estrutural contra o autoscaling de inferência AI em Kubernetes desde que as pessoas têm feito isso. Spinar um novo pod leva minutos; os spikes de demanda não esperam minutos; as violações de SLA seguem. As mitigações padrão têm sido over-provisioning (pagar por GPU idle), warm pools (ainda pagar por GPU idle), e model streaming (mais rápido mas ainda 30 a 90 segundos). O restore sub-5-segundos muda essa math materialmente. Se reproduzível em sua carga, esta é a primeira solução credível ao problema de inferência AI elástica em Kubernetes em vez de um workaround. Segundo, as limitações são a leitura substantiva sobre o timing de adoção. vLLM-only e single-GPU-only significam que Dynamo Snapshot atualmente cabe uma shape de deployment específica (serving vLLM single-GPU) em vez de uma capability K8s geral. A integração TensorRT-LLM, workers multimodais, workers de embedding e diffusion, multi-node, multi-GPU estão todos na roadmap mas não shipados. Os merges CRIU upstream (AIO e parallel memfd) são o path para ampliar a adoção além do fork da NVIDIA. Para builders avaliando isto para produção, a pergunta é se seu stack iguala as limitações atuais ou você espera o próximo quarter.
Segunda-feira pela manhã, se você roda vLLM em Kubernetes com inferência single-GPU e tem pagado por warm-pool GPU idle para absorver spikes de demanda: tente Dynamo Snapshot em um cluster não-produção contra sua carga real. O 21x para gpt-oss-120b é o upper bound; seu número real depende de IO de storage (ReadWriteMany importa), tamanho do modelo, e quão agressivamente você exercita o path de unmap do KV cache. Se você está em TensorRT-LLM ou multi-GPU hoje, monitore a roadmap e os merges CRIU upstream em vez de apostar em Dynamo Snapshot como opção atual. Se você constrói plataformas de inferência mais amplamente, a arquitetura two-tool (cuda-checkpoint para estado GPU, CRIU para CPU e estado de processo, com preservação de virtual address do KV cache) é o padrão de engineering que vale a pena estudar independentemente de se você adota Dynamo Snapshot mesmo. E se você opera clusters onde DaemonSets privilegiados são um non-starter por razões de segurança, esta não é a solução para você ainda; a arquitetura atualmente requer o container privilegiado para drivar cuda-checkpoint e CRIU ao nível do host.