Cold start de LLM no HyperPod: de 27 minutos a segundos com model caching

O endpoint que serve de fio condutor aqui é um pipeline de análise de documentos, contratos e extratos, tráfego em rajada na abertura do expediente e no fechamento do dia. Modelo com cerca de 145 GB de pesos no S3, vLLM num contêiner próprio de 12 GB no ECR, instâncias p5.48xlarge, InferenceEndpointConfig com autoScalingSpec disparado por invocações no CloudWatch.

Medido no kubectl describe pod, o tempo entre Scheduled e Ready se dividia em três fatias: 5 a 7 minutos puxando a imagem do ECR, mais de 20 minutos baixando os pesos do S3 para o disco do nó, e cerca de 90 segundos carregando pesos na HBM. As duas primeiras fatias são rede e não têm nada a ver com o modelo, são o mesmo download repetido em cada pod, em cada scale-out, em cada reposição de nó pelo health check do HyperPod.

A consequência operacional não era o tempo em si; era o que fizemos para conviver com ele. Mantínhamos duas réplicas de folga permanentes, scaleUpStabilizationTime em zero e targetValue baixo para o autoscaler antecipar a rajada. Duas p5.48xlarge paradas 24 horas por dia são 1.440 instance-hours por mês compradas só para esconder um download. A pergunta certa não era "como fazer o pod subir mais rápido?", era "quanto da folga existe só porque o pod demora?".

O desenho tem três peças que valem entender antes de confiar nele.

Aquecimento por nó: o operator baixa os pesos da fonte (S3, FSx for Lustre, Hugging Face Hub ou JumpStart) para um diretório isolado por deployment sob o hostPath, em cada nó que satisfaz as restrições de scheduling do deployment. Quando termina, aplica ao nó um rótulo com prefixo inference.sagemaker.aws.amazon.com/weights-cache-ready. seguido do UID da configuração; o cache de imagem faz o mesmo com image-cache-ready. via DaemonSet.

Afinidade preferida, não obrigatória: o deployment usa preferred node affinity nesses rótulos. Um pod vai para um nó quente quando existe um; se não existe, é agendado do mesmo jeito e baixa do S3 e do ECR como sempre fez. Isso é o que torna a migração reversível: o pior caso é o comportamento antigo, nunca um pod preso em Pending.

Montagem read-only: o pod monta o diretório do cache como volume hostPath somente leitura e o vLLM lê do NVMe local, a AWS cita cerca de 7 GB/s, em vez de percorrer a rede. O mesmo modelo de 145 GB que levava mais de 20 minutos para chegar ao disco agora está lá antes de o pod existir.

O que isso não faz: não replica cache entre nós, não detecta pesos novos na mesma chave e não sobrevive à troca do nó. Nó reposto pelo health check nasce frio, e o operator precisa aquecê-lo de novo enquanto os nós quentes seguem servindo.

O autoscaling no HyperPod tem duas camadas, e o cache só age numa delas.

Camada de pod (KEDA): o autoScalingSpec lê CloudWatch ou Amazon Managed Prometheus a cada pollingInterval (padrão 30 s; o HPA consulta o KEDA a cada 15 s) e decide réplicas. Com cold start de 27 minutos, uma política honesta precisa disparar cedo e manter folga; por isso tínhamos targetValue conservador e réplicas paradas. Com scale-out em segundos num nó quente, a mesma política passa a oscilar, sobe pods que ficam prontos antes de a janela padrão de 300 s de metricCollectionPeriod refletir a rajada. Reduzimos metricCollectionPeriod para 60 s, subimos targetValue e deixamos scaleDownStabilizationTime em 300 s para não devolver capacidade no primeiro vale.

Camada de nó (Karpenter): aqui o cache não ajuda. Um nó que o Karpenter acabou de provisionar não tem pesos nem imagem; o primeiro pod nele cai no fallback e paga os 27 minutos inteiros. Se o seu pico exige nós novos, o model caching encurta o segundo pod naquele nó, não o primeiro. A decisão que tomamos foi manter um piso de nós GPU quentes, o cache aquece neles fora do horário de pico, e usar o Karpenter só para o excedente raro.

Scale-to-zero no nível de nó e model caching resolvem problemas diferentes. Escolher entre eles é escolher o que você prefere pagar: instância ociosa com cache pronto, ou download completo no minuto de maior demanda.

Ligar o cache leva cinco linhas de YAML. Mantê-lo é o que custa, e três coisas viraram rotina de operação.

Capacidade de NVMe: cada deployment com cache ocupa o próprio diretório no mesmo disco local do nó. Dois modelos de 145 GB mais um de 57 GB num p5.48xlarge cabem folgados em 30 TB, mas o time que consolida seis endpoints num grupo de instâncias menor descobre a pressão de disco só quando o aquecimento para de acontecer. A documentação é explícita: separe grupos de instâncias ou reduza deployments cacheados por nó.

Invalidação por versão: como a fonte não é monitorada, a chave do S3 é a versão. Publicar pesos novos sobrescrevendo latest/ deixa o nó quente servindo o modelo antigo por tempo indefinido, sem erro algum. Um sufixo de versão no caminho e um kubectl apply novo é o único gatilho confiável; o operator limpa os arquivos antigos quando o deployment antigo é deletado.

Sinal de fallback: um pod que sobe sem o volume hostPath está no caminho lento e ninguém é avisado. Criamos um alerta simples: contagem de nós com rótulo cache-ready menor que o número de nós do grupo por mais de 10 minutos, mais o tempo Scheduled → Ready por pod exportado para o Prometheus. Sem isso, a regressão para o comportamento antigo passa despercebida até o próximo pico, e o próximo pico é exatamente quando você não quer descobrir.