Reduza cold starts de inferência no Amazon SageMaker HyperPod com cache de modelos

O problema do cold start em inferência de LLMs

Quem trabalha com implantação de Modelos de Linguagem de Grande Escala (LLMs) no Amazon SageMaker HyperPod conhece bem a frustração do cold start: você solicita um pod, mas ele só começa a responder requisições depois de um longo tempo de espera. Esse atraso é dominado por duas etapas sequenciais de download que acontecem toda vez que um pod sobe.

A primeira etapa é o download da imagem de contêiner do servidor de inferência a partir do Registro de Contêineres Elástico da Amazon (Amazon ECR). Imagens de servidores como vLLM ou LMI são volumosas — múltiplos gigabytes — porque empacotam drivers de GPU, bibliotecas CUDA e o próprio framework de serving. Esse processo costuma levar de 5 a 7 minutos.

A segunda etapa, e geralmente a mais demorada, é o download dos pesos do modelo a partir da fonte de armazenamento configurada, que pode ser o Serviço de Armazenamento Simples da Amazon (Amazon S3), o Amazon FSx for Lustre ou o HuggingFace Hub. Para um modelo de 145 GB hospedado no S3, essa etapa pode consumir mais de 20 minutos. Para modelos ainda maiores, como o DeepSeek-R1 com mais de 600 GB, o tempo ultrapassa os 30 minutos.

O cenário piora durante eventos de escalonamento horizontal. Se um pico de tráfego acionar o Autoescalador Horizontal de Pods (HorizontalPodAutoscaler) para criar cinco novos pods simultaneamente, cada um deles passa pelo mesmo ciclo de download de forma independente. A política de autoscaling reage em segundos, mas o tráfego adicional só começa a ser atendido 25 a 30 minutos depois — porque cada pod fica bloqueado aguardando os downloads.

Cache de modelos: como a AWS resolve o problema

A AWS anunciou o lançamento do cache de modelos para inferência no SageMaker HyperPod. A ideia central é simples: pré-carregar os pesos do modelo e a imagem de contêiner nos nós do cluster antes que os pods precisem deles. Quando o pod sobe, ele lê os dados do armazenamento NVMe local — a velocidades de aproximadamente 7 GB/s — em vez de baixar tudo pela rede. O resultado prático é que pods que antes levavam dezenas de minutos para iniciar passam a estar prontos em segundos.

O recurso introduz duas capacidades independentes que podem ser habilitadas juntas ou separadamente.

Cache de pesos (Weights Cache)

O cache de pesos baixa os pesos do modelo para o armazenamento NVMe local de cada nó com antecedência. O fluxo funciona assim:

• Você adiciona a seção modelCacheConfig com weightsCache habilitado ao seu recurso InferenceEndpointConfig ou JumpStartModel e aplica a configuração.
• O Operador de Inferência do HyperPod cria automaticamente um recurso ModelDataCacheConfig e inicia o download dos pesos a partir da fonte configurada (S3, FSx for Lustre, HuggingFace Hub ou JumpStart) para o NVMe local de todos os nós alvo.
• Após o download ser concluído em um nó, o operador marca esse nó como cache-ready (cache pronto).
• O operador aguarda que todos os nós alvo estejam marcados como prontos antes de criar o deployment de inferência, garantindo que os pods sempre encontrem os dados localmente disponíveis.
• O cache persiste entre reinicializações de pods no mesmo nó. Durante eventos de escalonamento, novos pods que forem alocados em nós com o cache já populado iniciam imediatamente.

Cache de imagem (Image Cache)

O cache de imagem realiza o pré-download da imagem de contêiner do servidor de inferência nos nós, eliminando a espera pelo pull do ECR. O comportamento é ligeiramente diferente do cache de pesos:

• O operador cria um DaemonSet que baixa a imagem de contêiner em todos os nós alvo.
• Ao contrário do cache de pesos, o cache de imagem não bloqueia a criação do deployment — ele é criado imediatamente.
• Se um pod iniciar antes que o cache de imagem esteja completo naquele nó, o pull acontece normalmente pelo ECR, sem falhas.
• Múltiplos deployments que usam a mesma imagem de contêiner compartilham um único recurso de cache de imagem. O operador rastreia as referências e só remove o cache quando nenhum deployment o referencia mais.

Comportamento de fallback

Ambas as capacidades utilizam agendamento preferencial, não obrigatório. Os pods preferem nós com cache disponível, mas nunca ficam bloqueados por isso. Se um pod for alocado em um nó sem cache — por exemplo, durante um escalonamento rápido que supera o número de nós com cache populado — ele baixa os pesos normalmente do S3 ou FSx e puxa a imagem do ECR. Não há falha, não há intervenção manual necessária e o comportamento é idêntico ao de um pod rodando sem cache habilitado.

Arquitetura e recursos customizados (CRDs)

O operador introduz dois Recursos de Definição Customizada (CRDs) para gerenciar o ciclo de vida do cache. Eles são criados e gerenciados automaticamente — você não precisa criá-los diretamente.

O ModelDataCacheConfig gerencia o ciclo de vida completo do cache de pesos: controla o download para o NVMe local, marca os nós como prontos, monitora a saúde do cache e realiza a limpeza quando o recurso pai é deletado. Você pode inspecionar o estado do cache a qualquer momento:

kubectl get modeldatacacheconfig -n <namespace>
NAME                  STATE   TARGET   READY   AGE
example-model-cache   Ready   10       10      5m

O ModelImageCache gerencia o ciclo de vida do cache de imagens: controla o pré-download da imagem nos nós, relata o status por nó e realiza a limpeza quando nenhum deployment referencia mais o cache.

kubectl get inferenceimagecache -n hyperpod-inference-system
NAME                                      PHASE      CACHED   TARGET   AGE
iic-vllm-openai-ml-g5-24xlarge-a1b2      Complete   10       10       3m

Quando você altera a fonte do modelo — por exemplo, apontando para um novo caminho no S3 com pesos atualizados — o operador cria um novo cache, implanta o deployment atualizado e só então remove o cache antigo. O mesmo se aplica a mudanças de imagem, garantindo transições sem downtime e sem dados desatualizados.

Como habilitar o cache de modelos

Para ativar o recurso, basta adicionar a seção modelCacheConfig ao seu recurso InferenceEndpointConfig ou JumpStartModel existente. Nenhuma infraestrutura adicional é necessária.

Exemplo com InferenceEndpointConfig:

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: example-model
  namespace: default
spec:
  modelName: example-model
  modelSourceConfig:
    modelSourceType: s3
    s3Storage:
      bucketName: example-bucket
      region: us-west-2
      modelLocation: "models/example-model"
  modelCacheConfig:
    weightsCache:
      enabled: true
    imageCache:
      enabled: true
  instanceType: ml.g5.24xlarge
  worker:
    image: vllm/vllm-openai:latest
    modelInvocationPort:
      containerPort: 8000
    modelVolumeMount:
      name: model-weights
      mountPath: /opt/ml/model
    resources:
      limits:
        nvidia.com/gpu: "4"

Exemplo com JumpStartModel:

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: JumpStartModel
metadata:
  name: example-jumpstart-model
  namespace: default
spec:
  model:
    modelId: "meta-textgeneration-llama-3-1-8b-instruct"
    acceptEula: true
  server:
    instanceType: ml.g5.24xlarge
    modelCacheConfig:
      weightsCache:
        enabled: true
      imageCache:
        enabled: true

Você pode habilitar cada capacidade de forma independente. Se quiser apenas o cache de imagem, basta omitir weightsCache ou defini-lo como false. O cache de pesos também suporta um override opcional de hostPath caso você queira usar um caminho de montagem NVMe diferente do padrão (/opt/dlami/nvme). Quando configurado via SageMaker JumpStart, a configuração é mantida em cada deployment originado dali.

Fontes de modelo suportadas

O cache de modelos funciona com todas as fontes de modelo suportadas pelo HyperPod Inference:

• Amazon S3 — cache de pesos e cache de imagem suportados
• Amazon FSx for Lustre — cache de pesos e cache de imagem suportados
• HuggingFace Hub — cache de pesos e cache de imagem suportados
• Amazon SageMaker JumpStart (não bloqueado) — cache de pesos e cache de imagem suportados
• Amazon SageMaker JumpStart (bloqueado) — cache de pesos e cache de imagem suportados

Benchmarks

Os resultados divulgados pela AWS mostram ganhos expressivos. Em modelos entre 57 e 145 GB, o cache de pesos proporcionou cerca de 60% de redução no tempo de escalonamento. O cache de imagem eliminou mais de dois minutos do tempo de pull de imagem, representando uma redução de até 97% em comparação com o pull direto do ECR a cada inicialização de pod.

O benefício cresce proporcionalmente ao tamanho do modelo, já que há mais dados que precisariam ser baixados pela rede. Para modelos acima de 600 GB, como o DeepSeek-R1, o cache elimina o que seria um download de mais de 30 minutos.

Armazenamento de instância e limitações importantes

Como o cache de modelos armazena os pesos no NVMe local, o tipo de instância precisa ter capacidade de armazenamento suficiente para o modelo. A AWS disponibiliza a seguinte referência:

• ml.g5.xlarge — 250 GB de NVMe
• ml.g5.12xlarge — 3.800 GB de NVMe
• ml.g5.48xlarge — 7.600 GB de NVMe
• ml.p4d.24xlarge — 8.000 GB de NVMe
• ml.p5.48xlarge — 30.000 GB de NVMe

Há algumas limitações que vale conhecer antes de adotar o recurso:

• Cache por nó: cada nó mantém sua própria cópia dos pesos do modelo. O consumo de NVMe escala com o número de nós.
• Download inicial obrigatório: na primeira vez que o cache é habilitado para um modelo, o download da fonte remota ainda acontece. Após isso, os pods naqueles nós partem do armazenamento local.
• Capacidade finita: se o modelo tem 300 GB e o tipo de instância oferece apenas 250 GB de NVMe, o cache não funcionará. Escolha o tipo de instância considerando o tamanho do modelo.
• Atualizações não são detectadas automaticamente: se você atualizar os arquivos do modelo no mesmo caminho do S3 sem alterar o spec do InferenceEndpointConfig, o operador continuará servindo a versão em cache. Para capturar os novos pesos, atualize o spec — por exemplo, alterando o caminho do modelo ou adicionando um sufixo de versão.

Limpeza automática

Quando você deleta o recurso InferenceEndpointConfig ou JumpStartModel, o operador remove automaticamente todos os dados em cache, DaemonSets e labels de nós do cluster. Nenhuma limpeza manual é necessária e o armazenamento NVMe fica disponível para outras cargas de trabalho.

Disponibilidade

O cache de modelos para inferência no Amazon SageMaker HyperPod está disponível de forma geral em todas as regiões onde o SageMaker HyperPod opera. Para começar a usar, basta adicionar a seção modelCacheConfig ao spec do seu deployment existente e aplicar a configuração — o operador cuida do restante. Para a documentação completa, consulte a documentação do SageMaker HyperPod Inference.

Fonte

Reduce inference cold starts on Amazon SageMaker HyperPod with model caching (https://aws.amazon.com/blogs/machine-learning/reduce-inference-cold-starts-on-amazon-sagemaker-hyperpod-with-model-caching/)