Phase 17 - Lesson 10

Mitigação de Cold Start para LLMs Serverless

Uma imagem de modelo de 20 GB leva de 5 a 10 minutos (7B) a mais de 20 minutos (70B) para passar do estado cold (inativo) para serving (pronto para serviço). Em um cenário serverless autêntico, isso não é um aquecimento — é uma indisponibilidade. As mitigações atuam em cinco camadas: imagens de nós pré-carregadas (Bottlerocket na AWS, arquitetura de volume duplo), model streaming (NVIDIA Run:ai Model Streamer, nativo no vLLM), snapshots de memória de GPU (checkpoints da Modal, reinicialização até 10x mais rápida), warm pools (min_workers=1), carregamento em camadas (pipeline NVMe→DRAM→HBM do ServerlessLLM, redução de 10-200x na latência) e migração em tempo real (live migration) que transfere tokens de entrada (KB) em vez do KV cache (GB). A Modal publica cold starts de 2-4s como piso; o padrão da Baseten é de 5-10s, sendo inferior a um segundo com pre-warming. Esta lição ensina a medir, planejar o orçamento e empilhar essas cinco camadas.

Tipo: Learn Idiomas: Python (stdlib, simulador simples de fluxo de cold-start) Pré-requisitos: Phase 17 · 02 (Inference Platform Economics), Phase 17 · 03 (GPU Autoscaling) Tempo: ~60 minutos

Objetivos de Aprendizado

Enumerar as cinco camadas de mitigação de cold start e nomear uma ferramenta ou padrão associado a cada uma delas.
Calcular o tempo total de cold-start como a soma de (provisionamento do nó) + (download dos pesos) + (carregamento dos pesos em HBM) + (inicialização da engine) para um modelo de 70B.
Explicar por que a migração em tempo real transfere tokens de entrada (KB) e não o KV cache (GB), além de identificar a penalidade desse processo (recomputação).
Descrever a compensação envolvida nos warm pools (pagar por uma GPU ociosa ou aceitar a cauda de latência do cold start) e o limite de SLA a partir do qual min_workers > 0 torna-se obrigatório.

O Problema

Seu endpoint de LLM serverless reduz a escala para zero durante a noite. Às 8:00, o tráfego atinge um pico repentino. A primeira requisição aguarda enquanto:

O Karpenter provisiona um nó de GPU: 45-60s.
O contêiner faz o download de uma imagem de 30 GB com os pesos: 120-300s.
A engine carrega os pesos para a HBM: 45-120s, dependendo do tamanho do modelo e da velocidade de leitura do armazenamento.
O vLLM ou o TRT-LLM inicializa os grafos CUDA, o pool de KV cache e o tokenizador: 10-30s.

Total: 220-510s (aproximadamente de 3 a 8 minutos) antes que o primeiro token retorne. Seu SLA é de 2s. Ao implantar um warm-pool (min_workers=1), o problema parece desaparecer — no entanto, você passa a pagar por uma GPU ociosa 24 horas por dia, 7 dias por semana. Se seu serviço possuir 5 produtos, cada um com uma réplica warm, a conta chega a 5 × 24 × 30 = 3.600 GPU-horas/mês, independente de algum usuário ter feito chamadas.

A mitigação de cold start é a técnica para manter a viabilidade econômica do modelo serverless enquanto se aproxima da latência de sistemas sempre ativos (always-on).

O Conceito

Camada 1 — imagens de nós pré-carregadas (Bottlerocket)

Na AWS, a arquitetura de volume duplo do Bottlerocket separa o sistema operacional (OS) dos dados. Tire um snapshot do volume de dados contendo a imagem do seu contêiner pré-baixada; referencie o ID do snapshot no seu EC2NodeClass. Os novos nós inicializarão com os pesos do modelo já armazenados no NVMe local — eliminando as etapas 2 e parte da 3. Esse método funciona de maneira nativa com o Karpenter. A economia típica de tempo varia entre 2 e 4 minutos por cold start em modelos grandes.

Equivalente no GCP: imagens de VM customizadas com camadas de contêiner pré-carregadas. No Azure: snapshots de discos gerenciados utilizando o mesmo padrão.

Camada 2 — model streaming (Run:ai Model Streamer)

Em vez de carregar o arquivo completo antes de responder à primeira chamada, transmita os pesos do modelo para a memória da GPU camada por camada, iniciando o processamento assim que o primeiro bloco de transformer estiver posicionado. O NVIDIA Run:ai Model Streamer é entregue nativamente no vLLM a partir de 2026. Ele funciona com S3, GCS e NVMe local. Essa abordagem reduz o tempo de carregamento de pesos aproximadamente pela metade em modelos grandes ao sobrepor a operação de I/O com a configuração de computação.

Camada 3 — snapshots de memória de GPU (Modal)

A Modal gera um checkpoint do estado da GPU (pesos, grafos CUDA, região de KV cache) logo após a primeira inicialização. Inicializações subsequentes desserializam esses dados diretamente para a HBM — um processo até 10x mais rápido do que a reinicialização padrão. Esse é o recurso mais próximo de "inicializar uma GPU aquecida em 2 segundos". O trade-off: os snapshots são vinculados à topologia específica da GPU; portanto, se o Karpenter migrar a carga de trabalho para outro SKU, será necessário redefinir o checkpoint.

Camada 4 — warm pools (min_workers=1)

A mitigação mais direta: manter uma réplica sempre pronta para atendimento. O custo equivale à tarifa horária da GPU contratada 24 horas por dia, 7 dias por semana. A lógica aritmética é severa em modelos pequenos (onde se paga de $0.85 a

.50/hora para evitar um cold start de 30s) e razoável em modelos grandes (onde se paga $4/hora para evitar um cold start de 5 minutos). O limite de SLA no qual a manutenção de warm pools torna-se mandatória costuma ser de TTFT P99 < 60s em modelos acima de 70B.

Camada 5 — carregamento em camadas (ServerlessLLM)

O ServerlessLLM gerencia o armazenamento como uma hierarquia de memória: NVMe (rápido, mas volumoso), DRAM (intermediário, mas escalonado em camadas) e HBM (reduzido, mas instantâneo). Os pesos do modelo são pré-carregados na DRAM e carregados sob demanda na HBM. O artigo original aponta uma redução de 10 a 200x na latência de carregamentos a frio comparado com a rota direta disco-para-HBM. A adoção comercial ainda é inicial, mas já existem integrações estruturadas com vLLM.

Camada 6 — migração em tempo real (padrão bônus)

Quando um nó fica indisponível (como em despejos spot ou drenagem de nós), o padrão tradicional é inicializar a frio outra réplica e esvaziar a fila de requisições. A migração em tempo real (live migration) move apenas os tokens de entrada (kilobytes) para um destino que já contenha o modelo carregado e recomputa o KV cache nessa nova localidade. A recomputação é mais barata do que realizar a transferência de gigabytes de KV cache pela rede física. Esse processo se aplica a arquiteturas de implantações desmembradas.

O cálculo do warm-pool

Para um serviço que opera sob um SLA de TTFT P99 de 2s, a questão central não reside em decidir entre usar ou não warm pools, mas sim em "quantas réplicas manter ativas e quais fluxos de tráfego devem utilizá-las".

Caminhos interativos de alto valor (chat em tempo real, assistente de voz): min_workers=1-2.
Caminhos em lote em segundo plano (classificações noturnas): redução de escala para zero é aceita, com cold starts toleráveis de 5 a 10 minutos.
Camadas Premium: min_workers dedicados por inquilino (tenant) com capacidade garantida.

Meça antes de otimizar

Detalhamento ilustrativo de um processo de cold-start para um modelo 70B em um nó recém-provisionado:

Fase	Tempo	Mitigação
Provisionamento do nó	50s	Bottlerocket + imagem pré-carregada, warm pool
Download da imagem	180s	Volume de dados pré-carregado (elimina a fase)
Pesos para HBM	75s	Model streamer (corta pela metade); snapshot de GPU (elimina a fase)
Inicialização da engine	20s	Cache persistente de grafos CUDA
Primeiro forward	3s	Latência mínima intrínseca
Total a frio (cold)	328s
Total com mitigações	~15s	Redução de 22x

Números que você deve memorizar

Cold start na Modal: 2-4s (utilizando snapshots de GPU).
Cold start padrão na Baseten: 5-10s; inferior a um segundo com pre-warming.
Cold start bruto em modelos 70B: de 3 a 8 minutos.
Run:ai Model Streamer: ~2x de aceleração no carregamento de pesos.
Carregamento em camadas do ServerlessLLM: redução de 10 a 200x na latência (números do artigo técnico).

Use-o

O code/main.py simula um fluxo de inicialização a frio (cold-start) com e sem cada uma das mitigações. Ele exibe o tempo total de cold-start, o custo de manutenção do warm-pool e o limite mínimo de taxa de requisições a partir do qual a presença do warm-pool torna-se economicamente favorável em comparação à penalidade financeira por requisições descartadas no SLA.

Entregue-o

Esta lição gera o documento outputs/skill-cold-start-planner.md. Com base nos parâmetros informados de SLA, tamanho do modelo e perfil de tráfego, o planejador seleciona e propõe a melhor estratégia de empilhamento de mitigações.

Exercícios

Execute code/main.py. Determine a taxa mínima de requisições acima da qual manter uma réplica warm se torna mais vantajoso financeiramente do que arcar com a taxa de cold-start devido ao descarte de requisições fora do limite do SLO.
Você precisa implantar um modelo de 13B sob um SLA de TTFT P99 de 3s. Proponha a stack mínima de mitigações (menor número de camadas) que atenda a essa restrição.
A pré-carga com Bottlerocket elimina o download da imagem, mas os pesos do modelo ainda precisam ser transferidos do snapshot para a HBM. Calcule o tempo real (wall-clock) dessa cópia para um modelo de 70B considerando que o NVMe lê a 7 GB/s.
Sua equipe recusa utilizar snapshots de GPU em ambiente serverless sob o argumento de que "snapshots expõem PII (dados pessoais identificáveis)". Defenda ambos os lados da questão: mapeie o risco real envolvido e as contramedidas possíveis (como snapshots efêmeros, criptografia forte e isolamento de namespaces).
Projete uma política estruturada de warm-pool baseada em camadas: quantas réplicas warm manter ativas para usuários pagantes, usuários em teste gratuito e cargas de trabalho em lote? Apresente as fórmulas e contas que justificam as escolhas.

Termos-Chave

Termo	O que as pessoas dizem	O que realmente significa
Cold start	"a grande pausa"	Tempo decorrido do recebimento da requisição até a emissão do primeiro token em uma nova réplica
Warm pool	"mínimo sempre ativo"	Configuração de `min_workers >= 1` para garantir que haja sempre ao menos uma réplica ativa
Imagem pré-carregada	"AMI pronta"	Imagem de nó de computação que já traz os pesos do modelo gravados localmente
Bottlerocket	"OS de nós da AWS"	Sistema operacional otimizado para contêineres na AWS que permite snapshots de volumes de dados
Model streamer	"carregamento em fluxo"	Técnica para sobrepor o fluxo de leitura de pesos com a preparação do ambiente computacional
Snapshot de GPU	"checkpoint para HBM"	Processo de serializar o estado da GPU carregada e desserializá-lo para aceleração no boot
Carregamento em camadas	"NVMe + DRAM + HBM"	Estrutura de armazenamento hierárquico usada para buscar e disponibilizar pesos sob demanda
Migração em tempo real	"mover tokens"	Redirecionamento que envia o prompt (KB) e recomputa o KV cache no nó de destino
`min_workers`	"réplicas warm"	Número mínimo de instâncias ativas mantidas pelo orquestrador serverless
Redução a zero (scale-to-zero)	"serverless puro"	Prática de desativar todos os nós ociosos para zerar custos, assumindo a penalidade de cold start

Leituras Adicionais

Modal — Cold start performance — Benchmarks oficiais e arquitetura de checkpoints da Modal.
AWS Bottlerocket — Documentação sobre o padrão de snapshots de volumes de dados pré-carregados.
NVIDIA Run:ai Model Streamer — Detalhes sobre a sobreposição do carregamento de pesos com a inicialização computacional.
Baseten — Cold-start mitigation — Guias e práticas recomendadas sobre pre-warming.
Artigo do ServerlessLLM (USENIX OSDI'24) — Arquitetura de carregamento em camadas.
NVIDIA — Disaggregated LLM Inference on Kubernetes — Aplicação de live migration para implantações desmembradas.