Runpod mostra como rodar o Llama 3.1 8B no vLLM sem ter servidores próprios

A Runpod publicou um passo a passo para implantar o Llama 3.1 8B Instruct no engine vLLM dentro de sua plataforma Serverless. O modelo, com 8 bilhões de parâmetros e contexto de até 128 mil tokens, vira um endpoint de API que acorda sob demanda e dispensa o aluguel de uma placa de vídeo o dia inteiro. É um tutorial, não o lançamento de um novo produto. Mas o tema é prático: é assim que pequenas equipes colocam modelos abertos em produção hoje, sem montar infraestrutura própria.

O Llama 3.1 foi lançado em julho de 2024 em três tamanhos: 8B, 70B e 405B. A versão de 8 bilhões de parâmetros é a mais acessível. Em FP16, seus pesos ocupam cerca de 16 GB, então ela cabe em uma única placa com 24 GB de memória. Ainda assim, é preciso reservar à parte uma folga para o KV-cache em contextos longos.

Como funciona a solução

Hoje o vLLM é um dos engines mais usados para inferência de modelos abertos. Ele é construído sobre o PagedAttention: a memória do KV-cache é alocada em blocos, como as páginas de um sistema operacional, o que reduz a fragmentação. Combinado ao continuous batching, em que novas requisições entram em um lote que já está em execução, isso aumenta a vazão em uma única placa. Para os desenvolvedores, há um bônus: o servidor vLLM é compatível com o formato da API da OpenAI, e o código do cliente muda muito pouco.

A Runpod Serverless acrescenta uma camada de gerenciamento. O modelo é empacotado em um container worker, as requisições entram em uma fila, a plataforma sobe e desliga os workers por conta própria, e a cobrança é feita pelo tempo de execução, com precisão de segundos. Para o vLLM, a Runpod oferece um template pronto, configurado por variáveis de ambiente: nome do modelo, token do Hugging Face e comprimento máximo de contexto.

Principais parâmetros da solução:

• Modelo: Meta Llama 3.1 8B Instruct, cerca de 8 bilhões de parâmetros.
• Contexto: até 128K tokens.
• Pesos em FP16: da ordem de 16 GB.
• Engine: vLLM com PagedAttention e continuous batching.
• Interface: API compatível com a da OpenAI.
• Plataforma: Runpod Serverless, com autoescalonamento de workers, inclusive até zero.

Armadilhas

A principal é o cold start. Com o worker desligado, a primeira requisição precisa carregar cerca de 16 GB de pesos na memória da GPU, e o usuário sente a demora. Há três formas de amenizar o problema: embutir o modelo na imagem do container, usar cache do lado da plataforma ou manter ao menos um worker ativo. A última opção consome parte da economia que leva as pessoas a escolher serverless.

O segundo ponto é o acesso. O Llama 3.1 é distribuído sob a licença da Meta, e o modelo no Hugging Face é fechado: é preciso aceitar os termos e passar um token ao worker. O terceiro envolve memória. Por padrão, o vLLM pode reservar espaço para todo o contexto de 128K, por isso convém limitar o max model len às necessidades reais da aplicação. Assim sobra mais espaço para requisições paralelas.

O ganho do serverless depende do perfil de carga. O material não traz preços concretos, então o cálculo fica por conta do leitor, com base nas tarifas atuais da Runpod. A regra geral é simples: com requisições esporádicas e picos, a cobrança por segundo sai mais barata que uma placa dedicada; com carga alta e constante, o servidor dedicado costuma custar menos.

Por onde começar

Para um teste, basta uma sequência curta:

1. Aceitar a licença do Llama 3.1 no Hugging Face e criar um token de acesso. 2. Criar um endpoint Serverless com o template do vLLM, informando o modelo e o token. 3. Escolher uma GPU com folga a partir de 24 GB e limitar o comprimento máximo de contexto. 4. Definir o número mínimo e máximo de workers, além do tempo ocioso até o desligamento. 5. Apontar o cliente OpenAI existente para o novo endpoint e medir a latência do primeiro token em um worker frio e em um worker quente.

Se o cold start é crítico para o seu produto, meça-o antes da migração, não depois. Para ferramentas internas e tarefas em segundo plano, ele costuma ser tolerável. Para interfaces de chat com usuários reais, provavelmente será preciso manter um worker quente.