Quanta RAM um VPS básico precisa?

Para um único bot, uma API pequena ou um site estático, 1 GB basta, muitas vezes com folga. 2 GB é o padrão confortável quando você adiciona um banco de dados ou roda coisas em Docker. Abaixo de 1 GB, os gerenciadores de pacotes e os runtimes de linguagem modernos começam a sofrer.

Quanta RAM eu preciso para rodar um LLM num VPS?

Mais ou menos o tamanho do modelo na sua quantização, mais um ou dois gigabytes para o contexto. Um modelo de 7–8B em 4 bits precisa de uns 5–6 GB, um de 14B cerca de 10 GB, um de 32B uns 20 GB e um de 70B por volta de 40–45 GB. É por isso que existem servidores de 64 GB: cabe um modelo de 70B com espaço para o resto da sua stack.

Não. Swap é uma rede de segurança para picos curtos: evita que uma build ou um backup sejam encerrados. Se uma carga vive no swap o dia inteiro, tudo fica lento; esse é o sinal para subir de plano.

Como vejo quanta RAM o meu servidor usa de verdade?

Rode 'free -h' e olhe a coluna 'available', não 'free': o Linux usa a memória sobrando como cache de disco e a devolve quando precisa. 'ps aux --sort=-rss | head' mostra os maiores processos, e 'docker stats --no-stream' mostra o uso por container.

Quando um VPS de 64 GB faz sentido?

Quando uma única coisa precisa ficar na memória: um modelo local de 32–70B, um grande índice vetorial para RAG ou uma frota de agentes com os seus próprios runtimes. Para sites, bots e a maioria das APIs, é dinheiro jogado fora.

Quanta RAM um VPS precisa? Números reais por carga

A maioria das pessoas chuta a RAM. Ou compra demais «por via das dúvidas», ou descobre o OOM killer às 3 da manhã. Memória é, na verdade, uma das coisas mais fáceis de dimensionar, porque as cargas são previsíveis quando você conhece os números aproximados. Aqui estão eles, de uma máquina de 1 GB para um bot até os servidores de 64 GB que as pessoas procuram quando querem rodar um modelo grande localmente.

Números aproximados por carga

São valores reais em regime estável para um setup típico, não os mínimos dos fabricantes.

Carga	RAM que usa de verdade	Plano adequado
Bot de Telegram/Discord (Python, Node.js)	100–300 MB	Nano 1 GB
Site estático + Caddy/Nginx	50–150 MB	Nano 1 GB
WordPress + MariaDB, tráfego normal	0,8–1,5 GB	Micro-IP 2 GB
PostgreSQL para um app pequeno	0,5–2 GB (você decide via `shared_buffers`)	Micro / Small
n8n com alguns workflows	0,5–1,5 GB	Micro 2 GB
Host Docker com 5–10 serviços pequenos	2–4 GB	Small 4 GB
Coolify + builds + um banco de dados	3–4 GB	Small-IP 4 GB
LLM de 7–8B, 4 bits, inferência em CPU	5–6 GB	Medium 6 GB
LLM de 14B, 4 bits	~10 GB	Pro-32
LLM de 32B, 4 bits	~20 GB	Pro-32
LLM de 70B, 4 bits	~40–45 GB	Pro-48 / Pro-64

Duas coisas chamam a atenção. Primeiro, o salto entre as cargas «normais» e os LLMs é enorme: um bot e um modelo de 70B diferem por um fator de duzentos. Segundo, a maioria dos serviços vai bem com 1–4 GB; as pessoas compram demais porque dimensionam para um futuro que raramente chega.

A fórmula dos LLMs

Para modelos de linguagem há uma estimativa simples: parâmetros × bits por peso ÷ 8, mais o overhead. Um modelo de 8B com cerca de 4,5 bits (uma quantização Q4 típica) dá 8 × 4,5 ÷ 8 ≈ 4,5 GB de pesos. Some 1–2 GB para a janela de contexto (o KV cache cresce com o tamanho do contexto) e para o runtime, e você chega a 5–6 GB.

A parte honesta: em servidores só com CPU, a memória é metade da história. Espere poucos tokens por segundo para modelos de 7–8B em alguns vCPUs e cerca de um token por segundo para um de 70B. Isso serve para jobs em lote, agentes em segundo plano e experimentos privados; não é uma experiência de chat para muitos usuários simultâneos. Se você chama principalmente APIs de modelos hospedados, o seu agente precisa de bem menos: veja dimensionar um VPS para agentes de IA.

Meça em vez de chutar

Se você já tem um servidor, os números estão ali:

free -h                              # look at "available", not "free"
ps aux --sort=-rss | head -n 8       # the biggest processes, by resident memory
docker stats --no-stream             # per-container usage

O Linux usa a RAM ociosa como cache de disco, então «free» é sempre pequeno, e isso é saudável. Available é o número que importa: a memória que o kernel pode entregar aos programas agora mesmo. Se o available fica acima de ~25% no seu horário de pico, o dimensionamento está certo. Se ele chega a zero com frequência e o swap cresce, suba de plano.

Verifique também se houve OOM kills no passado:

journalctl -k | grep -i "out of memory"

Swap: cinto de segurança, não motor

Um arquivo de swap de 1–2 GB num servidor pequeno é um seguro barato: uma atualização de pacotes ou uma build Docker que precisa de mais memória por um instante sobrevive em vez de ser encerrada. Mas se um serviço vive no swap, cada requisição espera pelo disco. Swap é para picos. Swapping constante significa que você precisa do próximo plano.

Então, quanto comprar?

1 GB: um bot, uma API pequena, um site estático.
2 GB: o padrão sensato para qualquer coisa com banco de dados ou Docker.
4–6 GB: vários serviços na mesma máquina, builds no servidor, um modelo local pequeno.
32–64 GB: só quando uma coisa grande precisa viver na memória: um modelo local acima de 14B, um grande índice de RAG, uma frota de agentes. É para isso que existem os planos com muita memória.

Comece um tamanho abaixo do que a sua intuição diz, acompanhe o free -h por uma semana e suba se os números mandarem. Na EQVPS, subir de plano mantém os seus dados e cobra só a diferença proporcional (como funcionam as mudanças de plano).