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 asociado. Envía archivos y un plan a una API, espera la respuesta, edita archivos y ejecuta comandos localmente. Mientras espera, utiliza muy poca CPU. Su consumo de memoria se mide en cientos de megabytes. Por eso, un servidor con una CPU modesta es la máquina adecuada.

Ejecutar el modelo por su cuenta es un producto diferente que requiere otro hardware. Los pesos permanecen en la memoria mientras el servidor está activo. Un modelo de 7 billion parameters cuantizado a 4 bits necesita aproximadamente 5 GB sólo para los pesos, antes de contar la caché key/value, que crece con la longitud del contexto. Si usa únicamente la CPU, una vCPU compartida produce unos pocos tokens por segundo. Una tarea del agente puede generar miles de tokens. Por tanto, un trabajo que tarda menos de un minuto mediante una API puede tardar casi una hora de forma local. Si eso es lo que necesita, dimensione el sistema según la VRAM (memoria de vídeo de la GPU) y consulte qué ofrece realmente una VPS con GPU en lugar de esta página.

Todo lo que sigue presupone el uso 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 agota el disco antes que la 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 todas las capas intermedias de cada compilación hasta que se le indica que las elimine.

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 elimina la caché de compilación con más de una semana y conserva la de esta semana, que es la que todavía le ahorra tiempo. docker image prune -a va más lejos y elimina todas las imágenes que no utiliza ningún contenedor, así que la siguiente compilación tendrá que descargarlas de nuevo.

Los proyectos de Node fallan de una forma más extraña. 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 muestra varios gigabytes libres. La escritura falla entonces con No space left on device en un disco que parece estar medio vacío.

df -h /
df -i /

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

Los registros son el problema menos visible. Un agente siempre activo escribe transcripciones de las sesiones y el journal de systemd crece de forma predeterminada hasta ocupar una parte importante del disco.

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

Configure 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 hoy.

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é parece que su agente de programación se bloquea

Este es el fallo que más se diagnostica mal en un equipo pequeño que ejecuta un agente. Un comando no devuelve nada, el agente espera y la sesión parece bloqueada. El proceso fue terminado por el asesino OOM (out-of-memory) del kernel. Recibió SIGKILL, por lo que no pudo mostrar un error, vaciar un registro ni informar al agente de lo ocurrido. El agente recibe 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 tenía ese proceso cuando terminó. Observe qué proceso se seleccionó: el kernel calcula la puntuación principalmente según la memoria utilizada, por lo que suele terminar el servidor de lenguaje o el agente, en lugar de la compilación que llevó al equipo al límite. Por eso el síntoma parece indicar que «el agente falló».

En Docker, el mismo evento deja una evidencia 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 y no que se cerró por un fallo propio.

La solución es asignar un límite independiente al comando que consume más recursos, para que termine la compilación en lugar del agente:

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

La compilación ahora se termina al alcanzar 4 GB y el agente sigue funcionando. Así, una espera inexplicable se convierte en un comando fallido normal con un código de salida legible. Esto requiere una sesión de usuario de systemd, por lo que debe ejecutar loginctl enable-linger $USER en un equipo al que sólo acceda mediante SSH. MemoryHigh= limita el proceso al alcanzar el umbral en lugar de terminarlo. A menudo es una configuración más adecuada para una compilación que prefiere que finalice 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.