¿Cuánta RAM se necesita realmente para servidores y VPS en 2025?

El dimensionamiento de la RAM es una cuestión de cálculo de la carga de trabajo, no una prueba de rendimiento. Si te pasas, pagarás por capacidad ociosa. Si te quedas corto, tus procesos se interrumpirán, tu base de datos funcionará desde el disco en lugar de desde la memoria, o tus contenedores se verán limitados. Esta guía ofrece rangos concretos de RAM para las cargas de trabajo más habituales (alojamiento web, bases de datos, virtualización, contenedores, inferencia de IA y servidores de juegos), además de las reglas que hay que seguir a la hora de dimensionar algo que no figure en la lista.

Qué hace la RAM en un servidor

La RAM almacena todo aquello en lo que el servidor está trabajando activamente. Memoria de procesos para servidores web, motores de bases de datos y daemons en segundo plano. Caché de páginas a nivel del sistema operativo y búferes de E/S de disco. Memoria de ejecución para aplicaciones y contenedores. Y los bloques de memoria asignados a máquinas virtuales o cargas de trabajo de contenedores.

Lo que diferencia el dimensionamiento de la RAM del de la CPU es el modo de fallo. Si se agota la CPU, los procesos se ralentizan. Si se agota la RAM, el kernel o bien recurre al swap (lo que ralentiza el sistema) o bien el «OOM killer» elige una víctima y la cierra. Lo primero es molesto. La segunda provoca la pérdida de datos. Proporcionar RAM con margen no es un lujo, es lo que evita que el sistema se colapse bajo carga.

RAM según la carga de trabajo

Servidores web y de aplicaciones

• Pila LAMP o LEMP ligera: de 1 a 2 GB
• WordPress o CMS con almacenamiento en caché (p. ej., Redis): de 2 a 4 GB
• Comercio electrónico (Magento, WooCommerce): de 4 a 8 GB
• Aplicaciones Node.js, Django o Rails: de 2 a 6 GB

Las capas de almacenamiento en caché, como Redis o Varnish, requieren memoria RAM propia además de la necesaria para la aplicación. Los trabajadores de PHP-FPM, las conexiones a bases de datos y los proxies inversos consumen memoria de forma simultánea, por lo que la cifra que importa es el paralelismo máximo, no el consumo en reposo.

Servidores de bases de datos (SQL y NoSQL)

• MySQL o PostgreSQL (pequeños): de 4 a 8 GB
• MySQL o PostgreSQL (grandes o de alto tráfico): de 16 a 64 GB
• MongoDB o Redis (orientados a la memoria): de 32 a 128 GB o más
• Nodos de Elasticsearch u OpenSearch: de 32 a 128 GB por nodo

El objetivo es mantener en la RAM el conjunto de trabajo, los índices y las filas a las que se accede con frecuencia. En cuanto alguno de estos elementos se traslada al disco, la latencia se multiplica por órdenes de magnitud, por muy rápido que sea el SSD.

Hosts de virtualización (Proxmox, VMware, Hyper-V)

• Máquinas virtuales ligeras de Linux: de 2 a 4 GB por máquina virtual
• Máquinas virtuales Windows: de 8 a 12 GB por máquina virtual
• Paneles de alojamiento (cPanel, Plesk, DirectAdmin): de 4 a 8 GB por instancia
• Hosts de contenedores KVM o LXC: de 32 a 128 GB o más

Reserva siempre entre 4 y 8 GB para el propio sistema operativo del host, además de las asignaciones para los invitados. Los contenedores utilizan menos RAM por carga de trabajo que las máquinas virtuales completas, pero se escalan de forma diferente, por lo que debes planificar en función de la densidad y el margen de picos de uso, en lugar del tamaño por contenedor. Si el host utiliza ZFS, tenga en cuenta también el ARC, que, de forma predeterminada, ocupará silenciosamente hasta la mitad de la RAM del sistema y competirá con las asignaciones de los sistemas invitados (nuestra guía de ajuste de ZFS ARC describe los límites adecuados para las cargas de trabajo del hipervisor).

Contenedores y microservicios (Docker, Kubernetes)

• Pilas sencillas de Docker (web, aplicación, base de datos): de 8 a 16 GB
• Nodos periféricos de Docker Swarm o K3s: de 16 a 32 GB
• Nodos de trabajo de Kubernetes: de 32 a 128 GB
• Ejecutores de CI/CD y agentes de compilación (GitLab, Jenkins): de 8 a 32 GB por ejecutor

Presta atención a las fugas de memoria en contenedores de ejecución prolongada. Las cargas de trabajo basadas en JVM, como Kafka y Elasticsearch, necesitan valores de referencia más altos porque el montón de memoria se expandirá hasta donde se le permita, lo que a menudo es más de lo esperado.

Inferencia de IA y ML

• Modelos pequeños (BERT cuantificado, Llama 7B): de 16 a 32 GB
• Modelos medianos (de 13B a 30B, cuantificados): de 64 a 128 GB
• Modelos grandes (más de 40B o de gama media no cuantificados): de 128 a 512 GB o más
• Inferencia respaldada por GPU (Stable Diffusion, Whisper): de 32 a 128 GB, dependiendo de la descarga

La cuantificación traslada la carga de la memoria de la GPU a la RAM de la CPU, por lo que las especificaciones del sistema varían significativamente dependiendo de si se procesa fp16 en la GPU o 4 bits en la CPU. El tamaño del lote y la longitud de la consulta también influyen en estas cifras. Nuestra guía sobre el alojamiento de inferencia de IA profundiza en cómo adaptar el hardware al tamaño del modelo.

Servidores de juegos

• Minecraft (vanilla): de 2 a 4 GB
• Minecraft (modificado): de 6 a 16 GB
• Rust, ARK o 7 Days to Die: de 8 a 16 GB
• Nodos de alojamiento multiinstancia: de 32 a 64 GB

Cargas de trabajo especializadas

• Transcodificación de vídeo (FFmpeg, Plex): de 16 a 64 GB
• Servidores de copias de seguridad o instantáneas: de 8 a 16 GB, más si se ejecutan motores de deduplicación
• Cortafuegos o IDS (pfSense, Suricata): de 2 a 8 GB, más si se utiliza NetFlow o registro completo de paquetes

No confíes en la memoria de intercambio

La memoria de intercambio es entre 10 y 100 veces más lenta que la RAM. Su función es servir de red de seguridad para que el núcleo tenga un lugar al que recurrir cuando se producen picos de presión en la memoria, no como una forma de ampliar la memoria utilizable. Si un servidor recurre a la memoria de intercambio bajo una carga normal, significa que no cuenta con los recursos suficientes, y punto. El artículo «Cómo interactúan el swap de Linux, el OOM killer y los cgroups» aborda en detalle los modos de fallo.

Cómo calcular con precisión la cantidad de RAM

1. Mide los picos, no la media. Utiliza htop, free -m, vmstat 1o tus métricas de Kubernetes para determinar el uso máximo a lo largo de un ciclo completo de tráfico. Los picos diarios, los lotes semanales y los ciclos de facturación mensuales son factores importantes.
2. Añade margen para el crecimiento: entre un 20 % y un 50 % para el escalado de aplicaciones. En el caso de las bases de datos, escala la memoria en función del tamaño del conjunto de datos, no de la tasa de solicitudes. Para plataformas multitenant, calcula el consumo por cliente y multiplícalo.
3. Planifica en función del modo de fallo que puedas tolerar. Una réplica de lectura que se queda sin RAM se degrada. Una base de datos primaria que se queda sin RAM corrompe las consultas y puede provocar la caída de las aplicaciones. Dedica la RAM donde el radio de impacto sea mayor.

La RAM es la especificación en la que quedarse corto duele más que excederse. Añadir memoria no acelerará una aplicación limitada por la CPU, pero funcionar con recursos insuficientes destruye la estabilidad. Determina el tamaño basándote en la monitorización real y en los picos probados, y luego deja margen.

FDC ofrece servidores dedicados y VPS con configuraciones de gran capacidad de RAM y ancho de banda ilimitado en múltiples regiones.