NVIDIA Dynamo Snapshot Fim do Cold Start em Inferência de IA no Kubernetes

O Pesadelo do Cold Start em Produção

Se você já tentou escalar inferência de IA no Kubernetes, sabe: quando a demanda sobe, as GPUs demoram minutos para ficar prontas. Enquanto isso, elas estão alocadas, mas ociosas — gerando custo sem servir nenhuma requisição. É o famoso cold start, e ele pode quebrar seus SLAs.

Para uma workload single-GPU com vLLM, o tempo de inicialização se divide assim:

• Carregamento dos pesos: 60-80%
• Compilação de grafos CUDA: 10-15%
• Aquecimento dos kernels: 5-10%
• Registro no runtime distribuído: 5-10%

A NVIDIA lançou o Dynamo Snapshot, uma abordagem de checkpoint/restore que reduz esse tempo para próximo do limite teórico da memória (speed of light). Vamos mergulhar nos detalhes técnicos, baseados no artigo original do blog da NVIDIA.

Como Funciona: CRIU + CUDA Checkpoint em Dobradinha

A ideia é simples: em vez de inicializar tudo do zero, tire um snapshot do worker já aquecido e restaure em segundos.

O Checkpoint em Duas Camadas

Elas se compõem perfeitamente: cuda-checkpoint joga o estado da GPU na memória RAM, e o CRIU serializa a árvore de processos para o disco. Na restauração (mesmo em outro nó), o CRIU reidrata o estado do host, e o cuda-checkpoint reconecta a memória da GPU.

Integração com Kubernetes via DaemonSet

A NVIDIA criou um DaemonSet privilegiado chamado snapshot-agent, instalável via Helm. Ele:

• Roda em todos os nós
• Faz checkpoint/restore de containers runc sem modificar o runc
• Salva os artefatos em storage compartilhado (NFS/SMB)
• Paraleliza automaticamente pelo cluster

# Exemplo: deploy do snapshot-agent via 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

O Padrão Quiesce/Resume

O maior desafio: após restaurar, o worker precisa reconectar ao plano de controle. A solução usa arquivos de sinalização:

1. Worker inicializa o motor → escreve ready_for_checkpoint.signal
2. Worker entra em loop de polling esperando restore_complete.signal
3. snapshot-agent faz o checkpoint dentro desse loop
4. Na restauração, o CRIU retoma exatamente na mesma instrução → worker vê o novo sinal → continua a inicialização

# Pseudocódigo do 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():
    # Carrega pesos, compila grafos, aquece kernels
    print("[Engine] Inicialização completa")
    # Sinaliza que está pronto para checkpoint
    with open(READY_FILE, "w") as f:
        f.write("ready")

def wait_for_restore():
    # Aguarda até detectar restauração
    while not os.path.exists(RESTORE_FILE):
        time.sleep(0.1)
    print("[Worker] Restauração detectada, retomando runtime")
    # Agora conecta ao plano de controle
    register_with_dynamo_control_plane()

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

Quatro Otimizações que Mudam o Jogo

1. Desalocar o KV Cache Antes do Checkpoint

Antes de tirar o snapshot, o worker libera o cache KV (já que não atendeu nenhuma requisição ainda). Usando a API de Gerenciamento de Memória Virtual do CUDA (cuMemUnmap / cuMemRelease), o endereço virtual permanece estável para os grafos CUDA, mas a memória física é liberada. Isso reduz o tamanho do checkpoint de ~190 GiB para ~6 GiB em modelos pequenos.

2. Restauração Paralela de memfd

Os pesos dos modelos ficam em memfd (memória anônima compartilhada). O CRIU original restaura esses buffers um por um. A NVIDIA modificou o CRIU para usar um pool de threads, restaurando todos os buffers em paralelo. Ganho de 5-8x em modelos grandes.

3. AIO Nativo do Linux para Memória Anônima

Em vez do loop síncrono preadv (uma leitura por vez), o Dynamo Snapshot usa AIO nativo do Linux com io_submit e io_getevents. Até 128 leituras simultâneas, saturando NVMe ou storage em rede. Combinado com O_DIRECT para não poluir o cache de página, os tempos de restauração ficam próximos do SOL.

4. GPU Memory Service (GMS) — O Gás Final

Mesmo com CRIU otimizado, mover pesos do storage para CPU e depois para GPU é um gargalo serial. O GMS desacopla a restauração dos pesos da restauração do processo usando CUDA VMM:

• Checkpoint CRIU encolhe para ~5-7 GiB (só estado do processo)
• Artefato de pesos (~74 GiB para gpt-oss-120b) é restaurado concorrentemente via GPUDirect Storage (GDS) ou stripes de NVMe
• Tempo total de inicialização cai de 5+ minutos para menos de 5 segundos — 21x de melhoria

# Fluxo conceitual: GMS restaura pesos em paralelo com CRIU
# Processo 1: Restauração CRIU (5-7 GiB)
criu restore -d --images-dir /checkpoints/criu/ &

# Processo 2: Restauração de pesos via GDS
gms_restore --backend gds --source /checkpoints/weights/ --gpu-id 0 &

wait  # Ambos completam concorrentemente

Limitações e Cuidados

• Apenas single-GPU por enquanto: Suporte multi-GPU e multi-nó está no roadmap, mas exige lidar com conexões NCCL, estado RDMA e mudanças de IP dos pods.
• Otimizações CRIU ainda não upstream: As modificações (memfd paralelo, AIO) serão enviadas para o CRIU oficial, mas por enquanto vêm apenas com o Dynamo Snapshot.
• Dependência de storage rápido: Em NFS lento sem O_DIRECT, os ganhos são reduzidos.
• Requer integração com o framework: Os hooks quiesce/resume precisam de suporte no vLLM ou SGLang. Nem todo framework implementa sleep()/wake_up() nativamente.

Próximos Passos

• GMS com backends plugáveis: GDS, UCX, RDMA/NVLink entre GPUs (aguardando patch do driver CUDA)
• Suporte a TensorRT-LLM
• Multi-GPU e multi-nó com hooks para PyTorch, NCCL, NIXL

Se você roda inferência em produção no Kubernetes, essa é a abordagem mais promissora para acabar com o cold start desde que as GPUs se popularizaram. A versão experimental já suporta vLLM e SGLang single-GPU — vale testar no seu ambiente de staging.

Junto com: Microsoft Sovereign Cloud: Executando Grandes Modelos de IA Totalmente Desconectados — veja como a governança de IA desconectada complementa a inicialização rápida para indústrias reguladas.

Veja também: Visão 2026 da Microsoft para Banco de Dados: Dados Unificados, Agentes de IA e o Novo Fabric Hub — a infraestrutura de dados que alimentará essas workloads de inferência de escalonamento rápido.