Como reduzir o tempo de startup de servidores de inferência de LLM

A matéria parte de uma ideia simples: réplica nova só vira capacidade quando consegue atender requisição. Até lá, o servidor carrega pesos, inicializa recursos de GPU, compila kernels, captura execution graphs e faz warm up. Parte disso paga a performance depois (compilação, autotuning, captura de CUDA Graph, que reduz o overhead de lançamento na GPU). O equilíbrio muda conforme modelo, software, hardware e armazenamento. Com os arquivos em cache local, a inicialização do engine passa a pesar mais. Com os pesos reaproveitados na memória da GPU, sobram imports, tuning e graph capture.

No vLLM, o Fast Start gira em torno de um weight daemon que mantém os tensores na GPU e os expõe a engines compatíveis via CUDA IPC. O daemon e o comando vllm preload já foram incorporados. No modo zero-copy, o daemon precisa continuar ativo enquanto houver engine usando a memória, e os handles de CUDA IPC são locais ao nó. O SGLang tem um daemon de cache de pesos equivalente já incorporado e um roadmap de recuperação rápida. Nos dois projetos, snapshots de engine inicializado seguem experimentais, com escopo de uma GPU NVIDIA, tensor parallelism de 1 e mesma máquina. No nível Kubernetes, o CRI ganhou CheckpointPod e RestorePod em 22 de julho de 2026, mas as implementações no containerd e no CRI-O ainda não fecharam. O KEP-5823, de checkpoint em nível de Pod, tem alpha previsto como meta para a v1.38 e exclui estado de dispositivo e restore entre nós.

Em 11 de maio de 2026, o CEVIU noticiou "Como a NetEase Games reduziu o cold start de LLMs de 42 minutos para 30 segundos", sobre pré-aquecer e compartilhar o acesso aos dados do modelo. Em 13 de maio de 2026, em "Como alcançar GPUs verdadeiramente serverless", o ponto era que serverless só funciona se novas réplicas subirem rápido. A matéria de agora mostra o que a comunidade constrói por baixo disso: daemons de pesos, snapshots e interfaces de checkpoint no Kubernetes. O foco saiu do acesso aos dados e foi para o estado do engine, com a ressalva de que boa parte ainda é experimental ou está em proposta.

Para quem opera inferência em Kubernetes, isso sugere separar o tempo de startup em etapas antes de escolher a solução. Se o gargalo é leitura de arquivos, cache de modelo resolve. Se são kernels e graphs, vale olhar preload e snapshot. Como as restrições de versão, GPU e nó são rígidas (o guia do vLLM, por exemplo, não funciona na v0.28), tratar esses recursos como produção exige teste por versão.