Quanta RAM um VPS precisa para um agente de código?

De quanta RAM precisa um VPS para um agente de programação?

Comece com 4 GB de RAM e 2 vCPU para um agente de programação sempre ativo a trabalhar num repositório. Passe para 8 GB e 4 vCPU assim que um servidor de linguagem ou uma compilação Docker fizer parte da sessão. Na maioria dos repositórios, isso acontece logo no primeiro dia. O processo do agente ocupa poucos recursos. O que consome a capacidade do servidor é a cadeia de ferramentas que o agente executa em seu nome.

[
  {
    "plan": "Minimum viable",
    "ram_gb": 4,
    "vcpu": 2,
    "disk_gb": 50
  },
  {
    "plan": "Comfortable",
    "ram_gb": 8,
    "vcpu": 4,
    "disk_gb": 100
  },
  {
    "plan": "Team, 4 sessions",
    "ram_gb": 16,
    "vcpu": 8,
    "disk_gb": 200
  }
]

Cada linha acima pressupõe que o modelo é executado noutro local, através de uma API que consulta pela rede. Essa premissa determina toda a questão do dimensionamento. Confirme-a primeiro.

Você está a executar o agente ou o modelo?

Um agente de programação que chama um modelo na nuvem é um cliente de rede com um shell associado. Envia ficheiros e um plano para uma API, aguarda a resposta, depois edita ficheiros e executa comandos localmente. Enquanto aguarda, utiliza quase nenhum CPU. A memória utilizada pelo próprio agente é medida em centenas de megabytes. Por isso, uma máquina com CPU modesto é a escolha correta.

Executar o modelo localmente é um produto diferente, em hardware diferente. Os pesos permanecem na memória enquanto o servidor estiver em execução. Um modelo com 7 mil milhões de parâmetros, quantizado para 4 bits, precisa de aproximadamente 5 GB apenas para os pesos. Isto acontece antes de considerar a cache de chave/valor, que cresce com o comprimento do contexto. Usando apenas CPU, uma vCPU partilhada produz alguns tokens por segundo. Uma tarefa de agente pode gerar milhares de tokens. Por isso, um trabalho que demora menos de um minuto através de uma API pode demorar quase uma hora localmente. Se é isso que pretende, dimensione o sistema em função da VRAM (memória de vídeo da GPU) e leia o que uma VPS com GPU oferece realmente em vez desta página.

Tudo o que se segue pressupõe o caso de utilização de um modelo na nuvem.

O que realmente usa a memória

[
  {
    "label": "Agent CLI process, idle",
    "typical_mb": 250,
    "peak_mb": 600
  },
  {
    "label": "TypeScript language server",
    "typical_mb": 700,
    "peak_mb": 2000
  },
  {
    "label": "rust-analyzer, large workspace",
    "typical_mb": 1200,
    "peak_mb": 4000
  },
  {
    "label": "Headless Chrome, one tab",
    "typical_mb": 350,
    "peak_mb": 900
  },
  {
    "label": "Node test run, 4 workers",
    "typical_mb": 1600,
    "peak_mb": 3000
  },
  {
    "label": "Docker image build",
    "typical_mb": 800,
    "peak_mb": 2500
  }
]

Estes são valores publicados típicos para projetos de tamanho médio. Considere-os como uma referência de proporções, não como uma garantia para o seu código.

A tabela contém 6 linhas, e o agent é o componente que menos memória usa. Em estado inativo, fica perto de 250 MB, porque mantém uma conversa e uma pequena cache de ficheiros, sem mais nada. Um servidor de linguagem TypeScript chega a cerca de 2000 MB durante a indexação, porque cria um grafo de tipos para todos os ficheiros acessíveis a partir do seu tsconfig.json e mantém esse grafo na memória para responder rapidamente ao pedido seguinte. O rust-analyzer num workspace grande ultrapassa normalmente 4000 MB pelo mesmo motivo, considerando todos os crates do workspace.

O Chrome sem interface gráfica usa cerca de 350 MB para o browser e um separador, e cada separador adicional corresponde a outro processo do sistema operativo. Uma execução de testes Node com quatro workers corresponde a quatro processos Node, por isso atinge um pico próximo de 3000 MB. Uma compilação de uma imagem Docker atinge um pico próximo de 2500 MB, porque a compilação executa o compilador do próprio projeto dentro do contentor enquanto o daemon grava as camadas.

sudo apt update && sudo apt install -y time
/usr/bin/time -v -o /tmp/build.rusage npm run build
grep "Maximum resident set size" /tmp/build.rusage

Leia a coluna available de free -h, não a coluna free. O Linux usa todas as páginas livres para a cache de disco, por isso free é baixo numa máquina perfeitamente saudável e não fornece informação útil. available indica o que um processo novo pode realmente obter.

Três configurações que funcionam

Mínimo viável: 4 GB de RAM, 2 vCPU, 50 GB de disco. Uma sessão do agente, um repositório, um servidor de linguagem e compilações pelas quais está disposto a esperar. Este nível funciona, mas encontrará o out-of-memory killer quando uma execução de testes grande coincidir pela primeira vez com um servidor de linguagem a indexar. Adicione swap e limite os workers de compilação.

Confortável: 8 GB de RAM, 4 vCPU, 100 GB de disco. Um agente, mais Docker, mais um browser headless para os testes, com margem para um pico de compilação. Este é o nível que a maioria dos programadores a trabalhar individualmente deve escolher. Duplicar o número de vCPUs também reduz aproximadamente para metade o tempo de espera da compilação, e essa diferença é sentida com muito mais frequência do que a memória.

Equipa: 16 GB de RAM, 8 vCPU, 200 GB de disco. Quatro sessões concorrentes, cada uma com o seu próprio checkout e a sua própria toolchain. Dimensione para o pico, porque quatro agentes inativos quase não custam nada, enquanto quatro execuções de testes ao mesmo tempo custam quatro vezes o valor máximo da coluna acima.

Em agosto de 2026, a passagem da primeira linha para a última representa aproximadamente quatro vezes o preço mensal num VPS faturado anualmente: alguns dólares por mês no nível inferior e dezenas de dólares no nível superior. Consulte a oferta atual antes de fazer o planeamento, porque estes valores mudam. O servidor raramente é a parte mais cara. Para quem utiliza um agente diariamente, o custo da API do modelo ultrapassa rapidamente o custo do servidor. Por isso, limite o valor que o agente pode gastar antes de reduzir os recursos da máquina. Para a compilação propriamente dita, o guia para executar um agente de programação num VPS explica a configuração da conta e como manter a sessão ativa depois de se desligar.

Por que o disco fica cheio antes da RAM

[
  {
    "label": "Ubuntu 24.04 base and toolchain",
    "typical_gb": 6
  },
  {
    "label": "One JS monorepo checkout",
    "typical_gb": 3
  },
  {
    "label": "node_modules across 3 branches",
    "typical_gb": 4
  },
  {
    "label": "Docker images and build cache",
    "typical_gb": 20
  },
  {
    "label": "Agent logs and journal, 90 days",
    "typical_gb": 2
  }
]

Somando essas linhas, um disco de 50 GB fica quase cheio antes de escrever uma linha de código. O maior item individual é o Docker, com cerca de 20 GB, porque o BuildKit mantém todas as camadas intermédias de todas as compilações até receber instruções para as remover.

docker system df
docker builder prune --filter until=168h

docker system df mostra o espaço recuperável por categoria, portanto execute-o antes e depois. O filtro until=168h remove a cache de compilação com mais de uma semana e mantém a desta semana, que ainda poupa tempo. docker image prune -a vai mais longe e remove todas as imagens que nenhum contentor utiliza, portanto a compilação seguinte terá de as transferir novamente.

Os projetos Node falham de uma forma mais difícil de diagnosticar. npm install cria centenas de milhares de ficheiros pequenos, por isso o sistema de ficheiros pode ficar sem inodes enquanto df -h continua a indicar gigabytes livres. A escrita falha então com No space left on device num disco que parece estar meio vazio.

df -h /
df -i /

Se IUse% indicar 100, elimine os diretórios node_modules das branches que já não utiliza ou mude para pnpm, que armazena cada versão do pacote uma única vez e cria hard links para ela em cada projeto.

Os logs são o problema silencioso. Um agente sempre ativo escreve transcrições de sessões, e o journal do systemd cresce, por predefinição, até ocupar uma parte significativa do disco.

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=200M
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail

Defina SystemMaxUse=200M em /etc/systemd/journald.conf e execute sudo systemctl restart systemd-journald para tornar esse limite permanente, porque uma limpeza única apenas recupera o espaço disponível hoje.

Swap: o que oferece e o que oculta

Vale a pena adicionar swap, porque transforma um pequeno excesso de consumo num trabalho lento, em vez de terminar o processo. Defina o tamanho como metade da RAM, até cerca de 4 GB. Num servidor de build, há pouca razão para ir além disso.

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
swapon --show

swapon --show deve agora listar /swapfile com o tamanho solicitado. Sem a linha /etc/fstab, a swap desaparece depois do próximo reboot e o servidor regressa silenciosamente ao comportamento anterior. Se fallocate responder Operation not supported, crie o ficheiro com sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 e continue a partir de chmod.

echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

Um valor baixo de swappiness indica ao kernel que deve recuperar primeiro a cache de disco, antes de transferir a memória dos programas para o disco. Isto mantém um language server responsivo.

Agora, a parte que a swap oculta. Quando um job precisa realmente de mais memória do que a disponível no servidor, o kernel passa o tempo a mover páginas entre a RAM e o disco, em vez de executar o build. Nada falha. Tudo fica lento, e a média de carga aumenta enquanto a CPU permanece inativa.

vmstat 1 10

Valores não nulos constantes nas colunas si e so indicam swapping contínuo. A correção é reduzir a concorrência ou aumentar a RAM, nunca aumentar a swap. Num servidor pequeno, sudo apt install -y zram-tools fornece swap comprimida mantida na RAM, configurada em /etc/default/zramswap. É muito mais rápida do que um ficheiro de swap e usa RAM para poupar RAM. Por isso, ajuda com páginas inativas, mas não com um build que precise de memória de trabalho real.

Por que o seu agente de programação parece ficar bloqueado

Esta é a falha mais diagnosticada de forma incorreta num servidor pequeno que executa um agente. Um comando não devolve nada, o agente fica à espera e a sessão parece bloqueada. O processo foi terminado pelo OOM killer do kernel por falta de memória. Recebeu SIGKILL, por isso não conseguiu imprimir um erro, descarregar um log nem informar o agente do que aconteceu. O agente vê um resultado vazio e nenhuma mensagem de saída.

O kernel regista o evento:

sudo dmesg -T | grep -iE "out of memory|killed process"
sudo journalctl -k -b | grep -i oom

Uma linha real tem este aspeto:

[Thu Aug  6 11:02:14 2026] Out of memory: Killed process 4711 (node) total-vm:4210880kB, anon-rss:3820104kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:8236kB oom_score_adj:0

anon-rss indica quanta memória esse processo tinha quando terminou. Observe qual foi o processo escolhido: o kernel atribui a pontuação principalmente com base na memória em uso, por isso muitas vezes termina o language server ou o agente, e não o build que levou o servidor acima do limite. É exatamente por isso que o sintoma parece indicar que "o agente falhou".

Dentro do Docker, o mesmo evento deixa uma indicação mais clara. O contentor termina com o código 137, que corresponde a 128 mais o sinal 9.

docker ps -a
docker inspect "$(docker ps -lq)" | grep -i oomkilled

"OOMKilled": true confirma que o contentor atingiu o limite de memória, em vez de terminar devido a uma falha própria.

A solução é atribuir ao comando dispendioso o seu próprio limite, para que o build termine e o agente continue em execução:

systemd-run --user --scope -p MemoryMax=4G -- npm run build

O build é agora terminado aos 4 GB e o agente continua em execução. Assim, um bloqueio difícil de diagnosticar transforma-se num comando normalmente concluído com falha e um código de saída legível. Isto requer uma sessão de utilizador do systemd, por isso execute loginctl enable-linger $USER num servidor ao qual só acede por SSH. MemoryHigh= limita o processo quando este atinge o limiar, em vez de o terminar. Esta é muitas vezes a configuração mais adequada para um build que prefere deixar concluir lentamente.

Defina o limite uma vez no Compose

Se as ferramentas do agente forem executadas em containers, defina o limite no ficheiro Compose para que seja aplicado em todas as execuções.

services:
  agent:
    image: node:22-bookworm
    deploy:
      resources:
        limits:
          memory: 2g
          cpus: "1.5"

O Docker Compose v2 aplica deploy.resources.limits num docker compose up simples, por isso o modo swarm não está envolvido. A chave mem_limit: 2g mais antiga continua a funcionar. O guia completo sobre limites de memória do Compose aborda as reservas e o que acontece quando um container atinge o seu limite. Se o Docker ainda não estiver instalado no servidor, instale o Docker numa VPS primeiro.

Há uma armadilha que pode consumir uma tarde inteira. Um container limitado a 2 GB continua a ler o /proc/meminfo do host e o número de CPUs do host, porque nenhum dos dois é isolado por namespace. Um executor de testes que escolha o número de workers com base na contagem de CPUs inicia oito workers dentro de um container de 2 GB num host com oito vCPUs e termina com o código 137. Defina os valores manualmente:

npx jest --maxWorkers=2
export NODE_OPTIONS=--max-old-space-size=1536

--max-old-space-size é expresso em MB e limita a heap do V8. Defina-o abaixo do limite do container para que o Node apresente um erro que possa ler, em vez de desaparecer:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Essa mensagem é útil porque identifica o limite atingido e o processo que o atingiu. O OOM killer nunca faz isso.

Executar várias sessões de agentes no mesmo servidor

Planeie por sessão, não por pessoa. Duas sessões no mesmo repositório continuam a significar dois servidores de linguagem, dois conjuntos de caches de compilação em memória e duas execuções de testes se ambos os agentes ficarem ocupados ao mesmo tempo. É por isso que a linha da equipa sobe para 16 GB.

Defina um limite rígido para cada utilizador, para que uma sessão descontrolada não consiga indisponibilizar todo o servidor:

id -u alice
sudo mkdir -p /etc/systemd/system/user-1001.slice.d
printf '[Slice]\nMemoryMax=6G\n' | sudo tee /etc/systemd/system/user-1001.slice.d/limit.conf
sudo systemctl daemon-reload
systemctl show user-1001.slice -p MemoryMax

Substitua 1001 pelo UID apresentado por id -u. systemctl show deve apresentar MemoryMax=6442450944 assim que o utilizador iniciar sessão. Quando tudo o que pertence à sessão desse utilizador ultrapassar 6 GB, o kernel termina um processo dentro da slice desse utilizador e as restantes sessões continuam a funcionar. Para um agente executado como serviço, em vez de num terminal, coloque MemoryMax= no ficheiro da respetiva unit. Esse é o padrão a seguir quando aloja um agente como serviço sempre ativo.

FAQ

2 GB de RAM é suficiente para um agente de programação?

Para o processo do agente, sim. Para o trabalho que ele executa, raramente. O agente ocupa cerca de 250 MB, mas um único servidor de linguagem TypeScript pode atingir 2000 MB num repositório de tamanho médio, e isso, por si só, coloca uma máquina com 2 GB em swap. 2 GB são suficientes para editar ficheiros de configuração e scripts pequenos. Use 4 GB como o mínimo para qualquer tarefa que compile código ou execute uma suíte de testes.

Preciso de uma GPU para executar um agente de programação numa VPS?

Não, se o agente chamar um modelo na cloud através de uma API. Essa carga de trabalho depende da rede, por isso uma VPS normal com CPU é a máquina adequada, enquanto uma GPU fica inativa a um preço muito mais elevado. Só precisa de uma GPU quando o próprio modelo é executado na mesma máquina. Nesse caso, a questão passa da RAM para a VRAM e o tamanho do modelo.

Quanto swap devo adicionar a uma VPS de agente?

Metade da RAM, até cerca de 4 GB. A swap protege contra um aumento momentâneo do consumo, porque o kernel pode mover páginas pouco utilizadas para o disco em vez de terminar um processo. Ela não adiciona memória utilizável. Se vmstat 1 mostrar tráfego constante nas colunas si e so, a máquina está em thrashing, e a solução é reduzir o número de workers em paralelo ou escolher um plano maior.

Por que motivo o meu agente de programação bloqueia a meio de uma compilação?

É quase certo que a compilação foi terminada pelo OOM killer do kernel, que envia SIGKILL. Por isso, nada é apresentado e o agente fica à espera numa pipe que nunca recebe dados suficientes. Execute sudo dmesg -T | grep -i "killed process" e verifique o nome do processo e o respetivo valor de anon-rss. Resolva o problema limitando a compilação com systemd-run --user --scope -p MemoryMax=4G e reduzindo o número de workers, ou passando para o nível seguinte de RAM.