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 agent ou o model?

Um coding agent que chama um cloud model é um network client com um shell associado. Envia ficheiros e um plano para uma API, aguarda a resposta, edita os ficheiros e executa comandos localmente. Enquanto aguarda, usa quase nenhum CPU. A memória própria é medida em centenas de megabytes. Por isso, uma máquina com CPU modesta é a escolha correta.

Executar o model localmente é um produto diferente, em hardware diferente. Os weights permanecem na memória enquanto o servidor estiver ativo. Um model com 7 billion parameters quantizado para 4 bits ocupa cerca de 4 GB de weights (Llama 2 7B é disponibilizado com 3.83 GB em Q4_0 e 4.08 GB em Q4_K_M), e o publisher indica 6.3 a 6.6 GB de RAM para o executar sem GPU, depois de contabilizar o overhead do runtime. Contextos mais longos precisam de mais memória, porque a key/value cache cresce com o tamanho do contexto. Apenas com CPU, uma vCPU partilhada produz alguns tokens por segundo, e uma tarefa do agent 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 para VRAM (memória de vídeo da GPU) e leia o que um VPS com GPU oferece na prática em vez desta página.

Tudo o que se segue assume o caso de utilização de um cloud model.

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.

Porque fica sem espaço em disco antes de ficar sem 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
  }
]

Some esses valores. 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 cada camada intermédia de cada build até lhe indicar que as deve remover.

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

docker system df mostra o espaço recuperável por categoria. Execute-o antes e depois da limpeza. O filtro until=168h mantém os registos de cache usados por um build na última semana e elimina os restantes. A decisão baseia-se na última utilização, não na idade. Assim, uma camada criada há um mês mas reutilizada ontem permanece, e essa é precisamente a cache que continua a poupar tempo. docker image prune -a vai mais longe e remove todas as imagens que nenhum container utiliza. Espere que o próximo build volte a fazer o pull.

Os projetos Node falham de uma forma menos evidente. npm install cria centenas de milhares de ficheiros pequenos. Por isso, o filesystem pode ficar sem inodes enquanto df -h continua a indicar que há 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. Esta opção guarda cada versão de cada package uma única vez e cria hard links para a disponibilizar em cada projeto.

Os logs são o problema silencioso. Um agent sempre ativo escreve transcrições das 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. Um vacuum executado uma única vez 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.

Porque o seu coding agent parece ficar bloqueado

Esta é a falha mais frequentemente diagnosticada de forma errada numa máquina pequena para agents. Um comando não devolve resultados, o agent fica à espera e a sessão parece bloqueada. O processo foi terminado pelo OOM killer do kernel. Recebeu SIGKILL, pelo que não conseguiu apresentar um erro, descarregar um log ou informar o agent sobre o que aconteceu. O agent 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 a quantidade de memória que esse processo tinha quando terminou. Observe qual foi o processo escolhido. O kernel baseia a pontuação sobretudo na memória em utilização. Por isso, termina frequentemente o language server ou o agent em vez do build que levou a máquina ao limite. É exatamente por isso que o sintoma parece indicar que "o agent falhou".

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

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

"OOMKilled": true confirma que o container atingiu o seu limite de memória, em vez de ter terminado por uma falha própria.

A solução é atribuir ao comando pesado o seu próprio limite, para que o build termine e não o agent:

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

O build é agora terminado ao atingir 4 GB e o agent continua ativo. Um bloqueio inexplicável passa a ser um comando que falhou normalmente, com um exit code legível. Isto requer um systemd user manager. Um login SSH normal inicia um para si, pelo que o comando funciona através de SSH sem alterações. loginctl enable-linger $USER serve apenas para manter os user units ativos depois de terminar a sessão. MemoryHigh= limita o processo ao atingir o valor definido, em vez de o terminar. Muitas vezes, esta é a opçã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.