AWS lança cache de modelos no HyperPod e reduz cold start de minutos para segundos

Quem opera inferência de LLMs em escala conhece bem o drama: entre o pedido de um novo pod e o momento em que ele serve tráfego, há uma lacuna dominada por dois downloads sequenciais — a imagem do servidor de inferência (do Amazon ECR) e os pesos do modelo (do S3, FSx for Lustre ou HuggingFace Hub). Para modelos pequenos, minutos. Para um DeepSeek-R1 de 600+ GB, são 30 minutos ou mais antes de uma única requisição ser atendida. E cada evento de scale-out repete o ciclo inteiro.

O model caching que o Amazon SageMaker Inference acaba de lançar para o HyperPod ataca esse gargalo, pré-carregando pesos e imagens nos nós antes de os pods precisarem deles.

Dois caches independentes

O weights cache baixa os pesos do modelo para o armazenamento NVMe local de cada nó com antecedência. Quando o pod sobe, ele lê do NVMe a ~7 GB/s em vez de baixar pela rede — tipicamente passando a servir em segundos, não dezenas de minutos. O operador só cria o deployment depois que todos os nós-alvo ficam “cache-ready”.

O image cache faz o pré-pull da imagem do container de inferência, eliminando os 5 a 7 minutos de download do ECR (redução de até 97% nesse tempo, segundo a AWS). Vários deployments que usam a mesma imagem compartilham um único cache.

Ambos usam agendamento preferencial, não obrigatório: se um pod cair num nó sem cache (num scale-out rápido que exceda os nós em cache), ele simplesmente baixa da fonte original, sem falha nem intervenção.

Como habilitar

Basta adicionar a seção modelCacheConfig ao recurso InferenceEndpointConfig ou JumpStartModel existente:

modelCacheConfig:
  weightsCache:
    enabled: true
  imageCache:
    enabled: true

O operador cria e gerencia automaticamente duas Custom Resource Definitions: ModelDataCacheConfig (ciclo de vida do cache de pesos) e ModelImageCache (cache de imagem). Nenhuma infraestrutura adicional é necessária, e ao excluir o recurso pai, o operador limpa tudo sozinho.

Os resultados

Nos benchmarks da AWS com modelos de 57 a 145 GB, o weights cache trouxe ~60% mais rápido no scale-out, e o image cache eliminou mais de dois minutos de pull. O benefício cresce com o tamanho do modelo — para modelos acima de 600 GB, você remove o que seria um download de mais de 30 minutos.

Há limitações a ter em mente. O weights cache é por nó (cada nó mantém sua cópia, então o consumo de NVMe escala com o número de nós), o cache inicial ainda exige um download da fonte, e atualizações no S3 não são detectadas automaticamente — para pegar pesos novos, é preciso atualizar a spec (por exemplo, mudar o caminho ou adicionar um sufixo de versão). Também é preciso escolher o tipo de instância com NVMe suficiente para o modelo.

O recurso está disponível de forma geral em todas as regiões onde o SageMaker HyperPod opera.