Rodar um modelo de IA na sua própria VPS: o que é realista sem GPU

A pergunta chega quase sempre no mesmo formato: "dá para rodar um modelo de IA na minha VPS?". Dá. A resposta útil, porém, é outra: o que exatamente você quer que ele faça — porque a diferença entre "classificar 200 tickets por hora" e "atender um chat ao vivo" muda tudo no dimensionamento.

Este artigo é o que muda na prática quando a inferência acontece em CPU, sem placa de vídeo.

O que decide se cabe: RAM, não CPU

O primeiro limite não é velocidade, é memória. Um modelo precisa estar carregado inteiro para gerar o primeiro token, e o tamanho depende de quantos parâmetros ele tem e de quantos bits cada parâmetro ocupa.

Sem quantização, cada parâmetro ocupa 2 bytes (16 bits). Quantizar reduz para 8, 5 ou 4 bits, com perda de qualidade que vai de imperceptível a relevante conforme você desce.

A conta aproximada de um modelo em 4 bits é parâmetros ÷ 2 = gigabytes:

A coluna da direita não é o tamanho do modelo: é o tamanho do modelo mais o contexto, mais o sistema operacional, mais a sua aplicação. O contexto consome memória proporcional ao tamanho da janela, e é ele que costuma estourar o cálculo de quem dimensionou pelo arquivo do modelo.

Não conte com swap. Se o modelo não couber na RAM, o sistema começa a paginar e a geração passa de lenta para inutilizável — é o cenário de si/so ativos descrito em VPS lenta: como diagnosticar. Em inferência, faltar 1 GB não degrada 10%: degrada uma ordem de grandeza.

O que decide se serve: velocidade

Em CPU, a geração é limitada pela banda de memória — o processador precisa percorrer os pesos do modelo a cada token gerado. É por isso que mais vCPU ajuda bem menos do que a intuição sugere, e por isso que um modelo menor é desproporcionalmente mais rápido.

A ordem de grandeza que se observa em VPS comum, com modelo quantizado em 4 bits:

• 1B a 3B: dezenas de tokens por segundo. Confortável para uso interativo.
• 7B a 8B: poucos tokens por segundo. Uma resposta de parágrafo leva de dezenas de segundos a alguns minutos.
• 13B ou mais: lento o suficiente para só fazer sentido em processamento assíncrono.

Há ainda um detalhe que confunde na primeira medição: o tempo até o primeiro token cresce com o tamanho do prompt, porque o modelo precisa processar tudo que você mandou antes de começar a responder. Um prompt de 4.000 tokens em um modelo 7B pode passar bem de um minuto em CPU só na fase de leitura, antes de escrever a primeira palavra.

Meça no seu caso antes de decidir a arquitetura, não depois.

Para que isso realmente serve

Com esses números na mesa, o corte fica claro. Em CPU, prefira tarefas assíncronas e de saída curta:

• Classificar e rotear tickets, e-mails ou mensagens.
• Extrair campos estruturados de texto livre (nota fiscal, currículo, contrato).
• Analisar sentimento de avaliações em lote.
• Gerar resumo de documento em fila, com o resultado entregue depois.
• Normalizar e enriquecer dados durante um ETL noturno.
• Gerar embeddings — que são muito mais baratos que geração de texto e rodam bem em CPU.

Em CPU, evite: chat ao vivo com usuário final, assistente de código, geração de textos longos e qualquer coisa em que a pessoa fica olhando para o cursor piscando.

Boa parte do valor prático de LLM em produto está justamente na primeira lista. Ela é menos vistosa e frequentemente a que paga a conta.

Subindo na prática

O caminho mais curto é o ollama, que embala o llama.cpp com gerenciamento de modelos e uma API HTTP:

curl -fsSL https://ollama.com/install.sh | sh
systemctl status ollama --no-pager
ollama pull llama3.2:3b
ollama run llama3.2:3b "Resuma em uma frase: ..."

A API local fica em 127.0.0.1:11434:

curl http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.2:3b",
  "prompt": "Classifique o sentimento: o produto chegou quebrado",
  "stream": false
}'

Três ajustes que valem desde o primeiro dia:

# /etc/systemd/system/ollama.service.d/override.conf
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_KEEP_ALIVE=30m"
Environment="OLLAMA_MAX_LOADED_MODELS=1"

• OLLAMA_HOST em 127.0.0.1 deixa a porta acessível só de dentro da máquina. Este é o item mais importante da lista — veja a seção seguinte.
• OLLAMA_KEEP_ALIVE evita descarregar e recarregar o modelo entre chamadas. Recarregar custa segundos, às vezes dezenas.
• OLLAMA_MAX_LOADED_MODELS=1 impede que dois modelos ocupem RAM ao mesmo tempo e derrubem o serviço por falta de memória.

Depois de criar o drop-in: sudo systemctl daemon-reload && sudo systemctl restart ollama.

Não deixe a porta aberta

Um servidor de inferência exposto na internet é, na prática, uma conta aberta: quem achar a porta usa a sua CPU, o seu tráfego e — se houver contexto guardado — os seus dados. Serviços de IA autohospedados costumam subir sem autenticação por padrão, porque o pressuposto é que ficarão em localhost.

O mínimo é:

• Manter o serviço em 127.0.0.1 e acessá-lo apenas pela sua aplicação, na mesma máquina.
• Se precisar expor, colocar um proxy reverso na frente com autenticação e limite de requisição, com certificado SSL válido.
• Fechar a porta no firewall de qualquer jeito, como segunda camada: o padrão certo é negar tudo e abrir o necessário.

Vale conferir o que está escutando:

sudo ss -tlnp | grep -E '11434|8080'

Se aparecer 0.0.0.0:11434, está exposto.

Isolar da aplicação principal

Inferência consome a máquina inteira: satura CPU e ocupa a memória de forma sustentada. Rodar o modelo na mesma VPS que serve o seu site significa que uma fila de classificação vai deixar as páginas lentas.

Duas formas de conter, em ordem de preferência:

1. VPS separada para a inferência, com a aplicação chamando por rede. Simples de raciocinar, simples de redimensionar, e um pico de IA não derruba o site.
2. Limites no systemd, se tiver de conviver na mesma máquina:

[Service]
CPUQuota=200%
MemoryMax=6G

MemoryMax faz o serviço de inferência ser morto pelo kernel antes de arrastar o resto da máquina junto — que é exatamente o que você quer que aconteça.

Modelo local ou API: o critério honesto

Não é uma escolha ideológica. É uma conta.

Modelo local ganha quando: o volume é alto e previsível, a tarefa é simples o bastante para um modelo pequeno, o custo precisa ser fixo, ou o dado não pode sair da sua infraestrutura por exigência de contrato ou regulação.

API gerenciada ganha quando: a tarefa exige a qualidade dos modelos de fronteira, o volume é baixo ou irregular, a latência interativa importa, ou você ainda está descobrindo se a funcionalidade tem valor — nesse estágio, pagar por chamada é muito mais barato do que dimensionar servidor.

O padrão que funciona bem na prática é híbrido: modelo local para o volume alto e mecânico, API para os casos difíceis. E vale medir antes de migrar: a economia projetada costuma encolher quando entra na conta o tempo de quem mantém o servidor de inferência de pé.

Se a decisão for hospedar, o dimensionamento é o mesmo raciocínio de sempre, só que com a memória mandando: como escolher CPU, memória e disco tem o método, os valores estão em preços, e os modelos ocupam disco de verdade — vários gigabytes cada, o que faz valer manter os arquivos e os resultados em Object Storage em vez de crescer o disco da VPS.

Se você não tem certeza de qual tamanho serve para a sua carga, traga o modelo que pretende usar e o volume esperado ao falar com a gente — é uma conta que fica muito mais curta com os dois números na mão.