Qual VPS para rodar uma IA: API ou modelo no servidor

Duas necessidades, dois tamanhos de servidor

A maioria das aplicações que “usam IA” (assistentes, agentes, resumos, extração de dados, busca em documentos) chama um modelo hospedado pelo fornecedor, por meio de uma API. O cálculo acontece do lado dele; seu servidor prepara a requisição, aguarda a resposta e a processa. Ele se dimensiona então como qualquer aplicação web: pela linguagem, pelo banco de dados e pelo número de usuários simultâneos.

O outro caso é o modelo executado no próprio servidor, com Ollama, llama.cpp ou uma biblioteca Python. Os motivos são conhecidos: dados que ficam em sua infraestrutura, um custo fixo seja qual for o número de requisições, um processamento em segundo plano sobre grandes volumes, um modelo especializado. Aqui, o modelo inteiro precisa caber na memória, e é ele que define o tamanho.

Por API: dimensionar a aplicação, não o modelo

Uma requisição a um modelo por API dura de um a várias dezenas de segundos, sobretudo quando a resposta é transmitida aos poucos (streaming). Durante esse tempo, seu servidor quase não calcula nada: ele espera. O que conta é a capacidade de manter muitas requisições em espera sem bloquear as outras:

• Um servidor assíncrono: Node.js, FastAPI com Uvicorn, ou workers assíncronos do Gunicorn. Um worker síncrono que espera uma resposta de 20 segundos é um worker bloqueado para todos os outros visitantes.
• Uma fila de tarefas para os processamentos longos (resumo de um documento, análise de um lote): a requisição do visitante retorna na hora, e um worker processa em segundo plano.
• Timeouts ajustados no proxy: por padrão, o Nginx corta uma resposta que fica mais de 60 segundos em silêncio (proxy_read_timeout).

A memória a prever é a da aplicação e do banco dela: 4 GB cobrem uma aplicação Python ou Node.js com PostgreSQL no lançamento. Uma configuração comum, com interface Next.js, API FastAPI e banco PostgreSQL chamando um modelo por API, cabe em 6 a 8 GB, build da interface incluído.

Embeddings e busca vetorial: a memória dos vetores

Uma aplicação que faz buscas em seus documentos (RAG, retrieval-augmented generation) transforma cada trecho em vetor e depois encontra os mais próximos de uma pergunta. Dois itens a dimensionar:

• O modelo de embeddings, se ele roda em seu servidor: os modelos mais usados pesam de 100 MB a 1,5 GB e calculam em CPU sem dificuldade. O all-MiniLM-L6-v2, por exemplo, ocupa menos de 100 MB.
• Os vetores: com o pgvector, um vetor ocupa 4 bytes por dimensão, mais 8. Um milhão de trechos em 1.536 dimensões representam cerca de 6 GB de dados, aos quais se soma o índice HNSW que acelera a busca. Para buscas rápidas, o índice e os vetores consultados precisam caber na memória.

O tipo halfvec do pgvector armazena cada dimensão em 2 bytes em vez de 4: metade da memória, com uma qualidade de busca que continua muito próxima.

Um modelo no servidor: a memória primeiro

Um modelo de linguagem é um arquivo de pesos, carregado inteiro na memória para responder. O tamanho dele depende do número de parâmetros e da quantização, a precisão com que cada peso é armazenado. O formato GGUF, usado pelo llama.cpp e pelo Ollama, oferece quantizações de 2 a 16 bits; a variante Q4_K_M, em torno de 4 bits, é o meio-termo mais comum entre tamanho e qualidade.

A esse peso somam-se dois itens:

• O contexto (o cache KV): cada token da conversa em andamento ocupa memória. Para o Llama 3.1 8B, conte cerca de 128 KB por token em precisão de 16 bits, ou seja, 1 GB para um contexto de 8.000 tokens, e o mesmo tanto para cada conversa processada em paralelo.
• O resto do servidor: sistema, aplicação, banco de dados, como em qualquer aplicação web.

Exemplo. Llama 3.1 8B em 4 bits, duas conversas simultâneas de 8.000 tokens e uma pequena aplicação: 5 GB de modelo, 2 GB de contexto, 2 GB para a aplicação e o sistema, ou seja, 9 GB, e cerca de 12 GB com 25% de margem.

Em CPU: o que define a velocidade

Para produzir cada token, o modelo relê todos os pesos na memória. Em CPU, a velocidade de geração é limitada, portanto, pela largura de banda da memória mais do que pelo número de núcleos: um modelo de 5 GB, em uma máquina que lê 25 GB por segundo, fica em torno de 5 tokens por segundo, antes mesmo de contar o cálculo.

Duas fases se distinguem:

• A leitura da pergunta (prompt processing) é um cálculo intensivo: mais vCPU a tornam mais rápida, o que conta para documentos longos.
• A geração da resposta depende sobretudo da largura de banda da memória e do tamanho do modelo: um modelo duas vezes menor responde cerca de duas vezes mais rápido.

Na prática, com alguns vCPU, um modelo de 7 a 8 bilhões de parâmetros quantizado em 4 bits produz alguns tokens por segundo. É confortável para um processamento em segundo plano (classificar mensagens, extrair campos de um documento, resumir durante a noite o que chegou durante o dia) e para um assistente interno. Os usos interativos em grande escala, e os modelos de várias dezenas de bilhões de parâmetros, rodam em placa de vídeo (GPU).

A medição decide: o llama-bench, que acompanha o llama.cpp, mostra a velocidade das duas fases em seu servidor, para seu modelo.

llama-bench -m modelo-Q4_K_M.gguf -p 512 -n 128

O disco: os modelos, as versões, os vetores

Um modelo ocupa em disco mais ou menos o que ocupa na memória: 5 GB para um modelo de 8 bilhões de parâmetros em 4 bits. Reserve espaço para dois ou três modelos ou versões, os índices vetoriais, os documentos de origem e o banco de dados. Um SSD NVMe carrega um modelo em poucos segundos quando o serviço inicia, o que conta a cada reinicialização.

Ordem de grandeza: 50 GB para uma aplicação que chama um modelo por API, 80 a 120 GB quando um modelo e os documentos dele ficam no servidor.

A instalação, com segurança

Com o Ollama, a instalação cabe em dois comandos:

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b

O Ollama escuta por padrão em 127.0.0.1:11434, ou seja, apenas a partir do próprio servidor. Mantenha essa configuração: a API do Ollama não exige nenhuma autenticação, e uma instância aberta na internet atende qualquer pessoa, com seus recursos. Sua aplicação, no mesmo servidor, conversa com ele localmente; se outro servidor precisar consultá-lo, passe por um proxy que autentique as requisições ou por uma rede privada.

Depois, ajuste o tamanho do contexto (num_ctx) ao que suas requisições realmente precisam: é ele que faz crescer a memória ocupada, conversa por conversa.