Inicializacao a frio de um LLM no Kubernetes: 200 dos 294 segundos nao sao gastos carregando os pesos

A ideia parece atraente: as requisicoes ao modelo chegam algumas vezes por dia, mas e preciso pagar pelo no com GPU 24 horas por dia, 7 dias por semana. A medida logica e remover os pods entre as requisicoes e inicia-los quando surgir carga. Isso funciona para um servico web convencional: um atraso de alguns segundos nao incomodara ninguem. Com LLMs, a situacao e diferente.

Por que um LLM demora tanto para iniciar

Depois que o pod do modelo e iniciado, e necessario baixar a imagem, carregar os pesos na GPU, compilar os grafos e aquecer o motor. Em julho, a equipe da H Company escreveu que uma nova replica de seus maiores modelos podia levar ate 27 minutos para ficar pronta. A empresa usa vLLM em nos Kubernetes com GPU e adiciona replicas conforme aumenta a carga gerada pelos agentes. O autoscaler aumenta rapidamente o numero de pods, mas as configuracoes de escalabilidade nao conseguem acelerar todas essas etapas de preparacao.

O autor da analise esperava que o carregamento dos pesos consumisse a maior parte do tempo. Medicoes publicas mostraram o contrario. Na Tensorfuse, a inicializacao do Llama 3.1 8B em uma L40S levou 294 segundos. O download do modelo e a transferencia dos pesos para a GPU consumiram apenas 94 segundos. Os 200 segundos restantes foram gastos com compilacao, captura de grafos CUDA, inicializacao do motor e importacoes.

O que pode ser armazenado em cache

Um detalhe importante: uma parte significativa desse trabalho e repetida a cada inicializacao de um pod, embora seus resultados possam ser mantidos no no. Essa e a principal oportunidade de aceleracao. Se os artefatos de compilacao forem mantidos no no e os pesos forem baixados antecipadamente, o novo pod nao precisara comecar do zero.

No artigo completo, o autor promete abordar a parte pratica:

• de onde o KEDA obtem o sinal de carga quando nao ha nenhum pod;
• o que vale a pena armazenar em cache antecipadamente;
• quais timeouts permitem que a primeira requisicao espere pelo modelo;
• manifestos do KEDA HTTP Add-on, um DaemonSet de pre-carregamento e as configuracoes do vLLM.

O sinal de carga merece atencao especial. Quando nao ha pods, tambem nao existem metricas deles para coletar, por isso e necessario um componente na frente do servico. O KEDA HTTP Add-on intercepta a requisicao, inicia o pod e mantem a conexao aberta ate que o modelo esteja pronto. Os timeouts sao cruciais: o cliente, o gateway e o ingress nao podem encerrar a conexao antes que o modelo termine de aquecer.

Limitacoes e conclusao

Mesmo depois de todas as otimizacoes, a inicializacao a frio nao passara a levar apenas alguns segundos. Se voce opera um chat interativo no qual o usuario nao aceita esperar um minuto, o scale-to-zero sera uma escolha ruim. Para tarefas em segundo plano, ferramentas internas, lotes e agentes que toleram atrasos, essa abordagem pode gerar uma economia significativa.

A conclusao pratica para engenheiros de plataforma e que, antes de otimizar o download dos pesos, e preciso verificar para onde o tempo realmente vai. Segundo medicoes publicas, mais de dois tercos da inicializacao correspondem a compilacao e inicializacao, e nao a rede. Armazenar essas etapas em cache no no traz mais beneficios do que um disco rapido.

Por fim, avalie com honestidade o perfil da carga. Se as requisicoes forem raras e previsiveis, manter zero replicas compensa. Se os usuarios esperam uma resposta imediata, e melhor manter uma replica aquecida e pagar por ela do que pagar pelos clientes perdidos.