Que VPS escolher para correr uma IA: API ou modelo no servidor

Duas necessidades, dois tamanhos de servidor

A maior parte das aplicações que «usam IA» (assistentes, agentes, resumos, extração de dados, pesquisa em documentos) chama um modelo alojado pelo seu fornecedor, através de uma API. O cálculo é feito do lado dele; o seu servidor prepara o pedido, espera pela resposta e trata-a. Dimensiona-se então como qualquer aplicação web: pela sua linguagem, pela sua base de dados e pelo número de utilizadores simultâneos.

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

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

Um pedido a um modelo por API dura de um a várias dezenas de segundos, sobretudo quando a resposta é transmitida à medida que é gerada (streaming). Durante esse tempo, o seu servidor quase não calcula nada: espera. O que conta é a sua capacidade de manter muitos pedidos em espera sem bloquear os outros:

• Um servidor assíncrono: Node.js, FastAPI com Uvicorn, ou workers Gunicorn assíncronos. Um worker síncrono que espera por 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): o pedido do visitante recebe resposta de imediato, e um worker trata do resto em segundo plano.
• Tempos limite ajustados no proxy: por predefinição, o Nginx corta uma resposta que fica em silêncio mais de 60 segundos (proxy_read_timeout).

A memória a prever é a da aplicação e da sua base de dados: 4 GB cobrem uma aplicação Python ou Node.js com PostgreSQL no lançamento. Uma configuração corrente, uma interface Next.js, uma API FastAPI e uma base PostgreSQL que chamam um modelo por API, cabe em 6 a 8 GB, incluindo a compilação da interface.

Embeddings e pesquisa vetorial: a memória dos vetores

Uma aplicação que pesquisa nos seus documentos (RAG, retrieval-augmented generation) transforma cada excerto num vetor, e depois encontra os mais próximos de uma pergunta. Dois elementos a dimensionar:

• O modelo de embeddings, se correr do seu lado: os modelos mais comuns pesam de 100 MB a 1,5 GB e calculam em processador 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 excertos em 1 536 dimensões representam cerca de 6 GB de dados, a que se soma o índice HNSW que acelera a pesquisa. Para pesquisas rápidas, o índice e os vetores consultados têm de caber em memória.

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

Um modelo no servidor: primeiro a memória

Um modelo de linguagem é um ficheiro de pesos, carregado inteiro em memória para responder. O seu tamanho depende do número de parâmetros e da quantização, a precisão com que cada peso é guardado. O formato GGUF, o do llama.cpp e do Ollama, propõe quantizações de 2 a 16 bits; a variante Q4_K_M, perto dos 4 bits, é o compromisso habitual entre tamanho e qualidade.

A este peso somam-se dois elementos:

• O contexto (a cache KV): cada token da conversa em curso ocupa memória. Para o Llama 3.1 8B, conte com 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 por cada conversa tratada em paralelo.
• O resto do servidor: sistema, aplicação, base 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 processador: o que define a velocidade

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

Distinguem-se duas fases:

• A leitura da pergunta (prompt processing) é um cálculo intensivo: mais vCPU tornam-na mais rápida, o que conta para os 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 mais pequeno responde cerca de duas vezes mais depressa.

Na prática, com alguns vCPU, um modelo de 7 a 8 mil milhõ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. As utilizações interativas em grande escala, e os modelos de várias dezenas de milhares de milhões de parâmetros, executam-se em placa gráfica (GPU).

A medição decide: o llama-bench, incluído no llama.cpp, dá a velocidade das duas fases no seu servidor, para o seu modelo.

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

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

Um modelo ocupa em disco mais ou menos o que ocupa em memória: 5 GB para um modelo de 8 mil milhões de parâmetros em 4 bits. Conte com espaço para dois ou três modelos ou versões, os índices vetoriais, os documentos de origem e a base de dados. Um SSD NVMe carrega um modelo em poucos segundos no arranque do serviço, o que conta a cada reinício.

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

A instalação, em 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

Por predefinição, o Ollama escuta em 127.0.0.1:11434, ou seja, a partir do próprio servidor. Mantenha esta definição: a sua API não pede qualquer autenticação, e uma instância aberta à Internet serve qualquer pessoa, com os seus recursos. A sua aplicação, no mesmo servidor, fala com ele localmente; se outro servidor precisar de o consultar, passe por um proxy que autentica os pedidos ou por uma rede privada.

Ajuste depois o tamanho do contexto (num_ctx) ao que os seus pedidos precisam: é ele que faz crescer a memória ocupada, conversa a conversa.