Cuánta RAM necesita un VPS para un agente de código

¿Cuánta RAM necesita un VPS para un agente de programación?

Empiece con 4 GB de RAM y 2 vCPU para un agente de programación que trabaja de forma permanente en un repositorio. Pase a 8 GB y 4 vCPU en cuanto se incorpore un servidor de lenguaje o una compilación de Docker a la sesión. En la mayoría de los repositorios esto ocurre desde el primer día. El proceso del agente consume pocos recursos. Lo que ocupa el servidor es la cadena de herramientas que el agente ejecuta en su nombre.

[
  {
    "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
  }
]

Todas las filas anteriores presuponen que el modelo se ejecuta en otro lugar, detrás de una API a la que se accede por la red. Esta premisa determina toda la cuestión del dimensionamiento, así que debe resolverla primero.

¿Está ejecutando el agente o el modelo?

Un agente de programación que llama a un modelo en la nube es un cliente de red con un shell conectado. Envía archivos y un plan a una API, espera la respuesta, después modifica archivos y ejecuta comandos localmente. Mientras espera, usa muy poca CPU. Su propia memoria se mide en cientos de megabytes, por lo que una máquina con una CPU modesta es la opción adecuada.

Ejecutar el modelo por su cuenta es otro producto que requiere otro hardware. Los pesos permanecen en memoria mientras el servidor está activo. Un modelo de 7 billion parameters cuantizado a 4 bits ocupa aproximadamente 4 GB de pesos (Llama 2 7B se distribuye con 3.83 GB en Q4_0 y 4.08 GB en Q4_K_M), y su editor indica que necesita entre 6.3 y 6.6 GB de RAM para ejecutarse sin GPU, una vez incluido el overhead del runtime. Los contextos más largos necesitan más memoria porque la caché key/value crece con la longitud del contexto. Sólo con CPU, una vCPU compartida produce unos pocos tokens por segundo, y una tarea de agente puede generar miles de tokens, por lo que un trabajo que tarda menos de un minuto mediante una API tarda casi una hora localmente. Si eso es lo que quiere, dimensione el sistema según la VRAM (memoria de vídeo de la GPU) y lea qué ofrece realmente una VPS con GPU en lugar de esta página.

Todo lo que sigue supone el caso de un modelo en la nube.

Qué utiliza realmente la memoria

[
  {
    "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
  }
]

Estas son cifras publicadas habituales para proyectos medianos. Tómalas como una referencia de proporciones, no como una garantía para tu código.

La tabla contiene 6 filas y el agente es el componente más económico. En reposo consume cerca de 250 MB, porque mantiene una conversación y una pequeña caché de archivos, y nada más. Un servidor de lenguaje de TypeScript alcanza aproximadamente 2000 MB mientras indexa, porque construye un grafo de tipos para cada archivo accesible desde tu tsconfig.json y después mantiene ese grafo en memoria para responder más rápido a la siguiente solicitud. rust-analyzer suele superar 4000 MB en un workspace grande por la misma razón, teniendo en cuenta todos los crates del workspace.

Headless Chrome consume unos 350 MB para el navegador y una pestaña, y cada pestaña adicional es otro proceso del sistema operativo. Una ejecución de pruebas de Node con cuatro workers utiliza cuatro procesos de Node, por lo que alcanza un máximo cercano a 3000 MB. La compilación de una imagen de Docker alcanza un máximo cercano a 2500 MB, porque la compilación ejecuta el propio compilador del proyecto dentro del contenedor mientras el daemon escribe las capas.

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

Lee la columna available de free -h, no la columna free. Linux utiliza cada página libre para la caché de disco, por lo que free es pequeño en un servidor completamente sano y no proporciona ninguna información útil. available indica cuánta memoria puede obtener realmente un proceso nuevo.

Tres configuraciones que funcionan

Mínima viable: 4 GB de RAM, 2 vCPU y 50 GB de disco. Una sesión del agente, un repositorio, un servidor de lenguaje y compilaciones que está dispuesto a esperar. Este nivel funciona, pero el OOM killer actuará la primera vez que una ejecución de pruebas grande coincida con un servidor de lenguaje que esté indexando. Añada swap y limite los workers de compilación.

Cómoda: 8 GB de RAM, 4 vCPU y 100 GB de disco. Un agente, Docker y un navegador sin interfaz gráfica para las pruebas, con margen para un pico de una compilación. Este es el nivel que debería contratar la mayoría de los desarrolladores individuales. Duplicar el número de vCPU también reduce aproximadamente a la mitad la espera de las compilaciones, y esa mejora se nota mucho más a menudo que la memoria adicional.

Equipo: 16 GB de RAM, 8 vCPU y 200 GB de disco. Cuatro sesiones simultáneas, cada una con su propio checkout y su propia toolchain. Dimensione el servidor para el pico, porque cuatro agentes inactivos cuestan casi nada, mientras que cuatro ejecuciones de pruebas al mismo tiempo cuestan cuatro veces el valor máximo de la columna anterior.

En agosto de 2026, pasar de la primera fila a la última supone aproximadamente cuadruplicar el precio mensual en la facturación anual de VPS: unos pocos dólares al mes en el nivel inferior y decenas de dólares en el superior. Consulte la oferta actual antes de planificar, porque esas cifras cambian. El servidor rara vez es la parte más cara. Para quien usa un agente a diario, el coste de la API del modelo supera rápidamente el coste del servidor, así que limite lo que el agente puede gastar antes de reducir el tamaño del servidor. Para la compilación en sí, la guía para ejecutar un agente de programación en un VPS explica la configuración de la cuenta y cómo mantener activa la sesión después de desconectarse.

Por qué se queda sin disco antes que sin 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
  }
]

Sume esas filas y un disco de 50 GB estará casi lleno antes de que haya escrito una línea de código. El elemento individual más grande es Docker, con unos 20 GB, porque BuildKit conserva cada capa intermedia de cada compilación hasta que se le indica que deje de hacerlo.

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

docker system df muestra el espacio recuperable por categoría, así que ejecútelo antes y después. El filtro until=168h conserva los registros de caché que una compilación haya usado durante la última semana y elimina el resto. Se basa en el último uso, no en la antigüedad, por lo que una capa creada hace un mes pero reutilizada ayer se conserva. Esa es la caché que todavía le ahorra tiempo. docker image prune -a va más allá y elimina todas las imágenes que ningún contenedor esté usando, así que la siguiente compilación tendrá que descargarlas de nuevo.

Los proyectos de Node fallan de una forma más difícil de diagnosticar. npm install escribe cientos de miles de archivos pequeños, por lo que el sistema de archivos puede quedarse sin inodos mientras df -h todavía indica que quedan gigabytes libres. Entonces la escritura falla con No space left on device en un disco que parece estar medio vacío.

df -h /
df -i /

Si IUse% muestra 100, elimine los directorios node_modules de las ramas que ya no usa o cambie a pnpm, que almacena cada versión de paquete una sola vez y crea enlaces duros hacia ella desde cada proyecto.

Los registros son el problema menos visible. Un agente que permanece siempre activo escribe transcripciones de las sesiones, y el journal de systemd crece hasta ocupar por defecto una parte del disco.

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

Establezca SystemMaxUse=200M en /etc/systemd/journald.conf y ejecute sudo systemctl restart systemd-journald para que ese límite sea permanente, porque una limpieza puntual sólo recupera el espacio disponible ese día.

Swap: qué aporta y qué oculta

Conviene añadir swap porque convierte un exceso puntual de memoria en trabajo lento en lugar de terminar el proceso. Asígnale la mitad de la RAM, hasta unos 4 GB. En un servidor de compilación, normalmente no hay motivo para superar esa cantidad.

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 debería mostrar ahora /swapfile con el tamaño solicitado. Sin la línea /etc/fstab, la swap desaparece después del siguiente reinicio y el servidor vuelve silenciosamente a su comportamiento anterior. Si fallocate responde Operation not supported, cree el archivo con sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 y continúe desde chmod.

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

Un valor bajo de swappiness indica al kernel que recupere primero la caché de disco antes de mover la memoria de los programas al disco. Esto mantiene la capacidad de respuesta del servidor de lenguaje.

Ahora, la parte que oculta la swap. Cuando un trabajo necesita realmente más memoria de la disponible en el servidor, el kernel dedica su tiempo a mover páginas entre la RAM y el disco en lugar de ejecutar la compilación. No se produce ningún error. Todo funciona muy lentamente y el load average aumenta mientras la CPU permanece inactiva.

vmstat 1 10

Los valores distintos de cero y estables en las columnas si y so indican swapping continuo. La solución es reducir la concurrencia o aumentar la RAM, nunca añadir más swap. En un servidor pequeño, sudo apt install -y zram-tools proporciona swap comprimida mantenida en la RAM y configurada en /etc/default/zramswap. Es mucho más rápida que un archivo de swap y utiliza RAM para ahorrar RAM. Por eso ayuda con las páginas inactivas, pero no con una compilación que necesita memoria de trabajo real.

Por qué su agente de programación parece quedarse bloqueado

Este es el fallo que más se diagnostica erróneamente en una máquina pequeña para agentes. Un comando no devuelve nada, el agente espera y la sesión parece bloqueada. El kernel mató el proceso mediante el terminador de falta de memoria (OOM). El proceso recibió SIGKILL, por lo que no pudo mostrar un error, vaciar un registro ni informar al agente de lo ocurrido. El agente ve un resultado vacío y ningún mensaje de salida.

El kernel sí lo registra:

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

Una línea real tiene este aspecto:

[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 cuánta memoria ocupaba ese proceso cuando murió. Observe qué proceso se eligió: el kernel calcula la puntuación principalmente según la memoria en uso, por lo que suele matar el servidor de lenguaje o el agente en lugar de la compilación que llevó la máquina al límite. Por eso el síntoma parece indicar que «el agente se rompió».

Dentro de Docker, el mismo evento deja una señal más clara. El contenedor termina con el código 137, que es 128 más la señal 9.

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

"OOMKilled": true confirma que el contenedor alcanzó su límite de memoria en lugar de bloquearse por su cuenta.

La solución es asignar su propio límite al comando costoso, para que muera la compilación en lugar del agente:

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

La compilación ahora termina al alcanzar 4 GB y el agente sobrevive. Así, un bloqueo inexplicable se convierte en un comando fallido normal con un código de salida legible. Esto requiere un gestor de usuario de systemd, y un inicio de sesión SSH normal inicia uno automáticamente, por lo que el comando funciona por SSH tal como está. loginctl enable-linger $USER sólo sirve para mantener en ejecución las unidades de usuario después de cerrar la sesión. MemoryHigh= limita el proceso al alcanzar el umbral en lugar de matarlo, lo que suele ser una configuración más adecuada para una compilación que prefiere terminar lentamente.

Limítelo una vez con los límites de memoria de Compose

Si las herramientas del agente se ejecutan en contenedores, establezca el límite en el archivo de Compose para aplicarlo en cada ejecución.

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

Docker Compose v2 aplica deploy.resources.limits en un docker compose up normal, por lo que no interviene el modo swarm. La clave antigua mem_limit: 2g sigue funcionando. La guía completa sobre los límites de memoria de Compose explica las reservas y qué ocurre cuando un contenedor alcanza su límite. Si Docker todavía no está instalado en el servidor, instale Docker en un VPS primero.

Hay un error que puede costar una tarde de trabajo. Un contenedor limitado a 2 GB sigue leyendo el /proc/meminfo del host y el número de CPU del host, porque ninguno de los dos recursos está aislado mediante espacios de nombres. Un ejecutor de pruebas que determine el número de workers a partir del número de CPU iniciará ocho workers dentro de un contenedor de 2 GB en un host con ocho vCPU y después terminará con el código 137. Establezca los valores manualmente:

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

--max-old-space-size se expresa en MB y limita el heap de V8. Establézcalo por debajo del límite del contenedor para que Node genere un error que pueda leer en lugar de desaparecer:

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

Ese mensaje resulta útil porque indica el límite alcanzado y el proceso que lo alcanzó. El OOM killer nunca lo hace.

Ejecutar varias sesiones de agentes en un mismo equipo

Planifique por sesión, no por persona. Dos sesiones en el mismo repositorio implican dos servidores de lenguaje, dos conjuntos de cachés de compilación en memoria y dos ejecuciones de pruebas si ambos agentes se activan al mismo tiempo. Por eso la fila del equipo aumenta hasta 16 GB.

Asigne a cada usuario un límite estricto para que una sesión descontrolada no bloquee todo el equipo:

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

Sustituya 1001 por el UID que mostró id -u. systemctl show debe mostrar MemoryMax=6442450944 una vez que el usuario haya iniciado sesión. Cuando todo lo que se ejecuta en la sesión de ese usuario supera 6 GB, el kernel termina un proceso dentro de su slice y las demás sesiones siguen funcionando. Para un agente que se ejecuta como servicio en lugar de hacerlo en una terminal, incluya MemoryMax= en el archivo de unidad correspondiente. Este es el patrón que debe seguir cuando aloja un agente como servicio permanente.

FAQ

¿Son suficientes 2 GB de RAM para un agente de programación?

Para el proceso del agente, sí. Para el trabajo que realiza, rara vez. El agente consume cerca de 250 MB, pero un solo servidor de lenguaje de TypeScript puede alcanzar 2000 MB en un repositorio de tamaño medio, y eso por sí solo hace que un sistema con 2 GB empiece a usar swap. 2 GB son suficientes para editar archivos de configuración y scripts pequeños. Use 4 GB como mínimo para cualquier tarea que compile o ejecute una suite de pruebas.

¿Necesito una GPU para ejecutar un agente de programación en un VPS?

No, si el agente llama a un modelo en la nube mediante una API. Esa carga depende de la red, por lo que un VPS con una CPU normal es la opción adecuada y una GPU permanece inactiva con un coste mucho mayor. Sólo necesita una GPU cuando el propio modelo se ejecuta en el mismo sistema. En ese caso, la cuestión cambia de la RAM a la VRAM y al tamaño del modelo.

¿Cuánto swap debo añadir a un VPS con un agente?

La mitad de la RAM, hasta unos 4 GB. El swap protege frente a un exceso puntual, porque el kernel puede mover a disco las páginas inactivas en lugar de terminar un proceso. No añade memoria utilizable. Si vmstat 1 muestra actividad constante en las columnas si y so, el sistema está en thrashing. La solución es reducir el número de workers en paralelo o contratar un plan mayor.

¿Por qué mi agente de programación se bloquea durante una compilación?

Casi con toda seguridad, el kernel OOM killer terminó la compilación. Envía SIGKILL, por lo que no se muestra ningún mensaje y el agente queda esperando en una pipe que nunca recibe datos. Ejecute sudo dmesg -T | grep -i "killed process" y revise el nombre del proceso y su valor de anon-rss. Para corregirlo, limite la compilación con systemd-run --user --scope -p MemoryMax=4G y reduzca el número de workers, o pase al siguiente nivel de RAM.