¿Cuánta RAM necesita un VPS? Cifras reales por tarea

La mayoría elige su RAM a ojo. O compra muchísimo más de la cuenta «por si acaso», o conoce al OOM killer a las 3 de la madrugada. Y sin embargo la memoria es de lo más fácil de dimensionar, porque las cargas son predecibles en cuanto conoces las cifras aproximadas. Aquí las tienes: desde un servidor de 1 GB para un bot hasta los de 64 GB que busca la gente cuando quiere ejecutar un modelo grande en local.

Cifras aproximadas por tarea

Son valores reales en régimen estable para una instalación típica, no mínimos de documentación.

Hay dos cosas que llaman la atención. Primero, el salto entre las tareas «normales» y los LLM es enorme: un bot y un modelo de 70B se diferencian en un factor de doscientos. Segundo, la mayoría de servicios se apañan con 1–4 GB; se compra de más porque se dimensiona para un futuro que rara vez llega.

La fórmula de los LLM

Para modelos de lenguaje hay una estimación sencilla: parámetros × bits por peso ÷ 8, más la sobrecarga. Un modelo de 8B a unos 4,5 bits (una cuantización Q4 típica) son 8 × 4,5 ÷ 8 ≈ 4,5 GB de pesos. Suma 1–2 GB para la ventana de contexto (la caché KV crece con la longitud del contexto) y el runtime, y llegas a 5–6 GB.

La parte honesta: en servidores solo con CPU, la memoria es solo la mitad de la historia. Espera una cifra de tokens por segundo de un solo dígito para modelos de 7–8B en unos pocos vCPU y alrededor de un token por segundo para 70B. Está bien para trabajos por lotes, agentes en segundo plano y experimentos privados; no es un chat para muchos usuarios a la vez. Si sobre todo llamas a APIs de modelos alojados, tu agente necesita mucho menos: consulta cómo dimensionar un VPS para agentes de IA.

Mide en lugar de adivinar

Si ya tienes un servidor, las cifras están ahí mismo:

free -h                              # look at "available", not "free"
ps aux --sort=-rss | head -n 8       # the biggest processes, by resident memory
docker stats --no-stream             # per-container usage

Linux usa la RAM ociosa como caché de disco, así que «free» siempre es pequeño y eso es sano. Available es la cifra que importa: la memoria que el kernel puede dar a los programas ahora mismo. Si available se mantiene por encima del ~25 % en tu hora de más carga, vas bien. Si llega a cero con frecuencia y el swap crece, sube un escalón.

Comprueba también los OOM pasados:

journalctl -k | grep -i "out of memory"

El swap: cinturón de seguridad, no motor

Un archivo swap de 1–2 GB en un servidor pequeño es un seguro barato: una actualización de paquetes o una compilación de Docker que necesita más memoria un momento sobrevive en lugar de morir. Pero si un servicio vive en el swap, cada petición espera al disco. El swap es para picos. Un swap constante significa que necesitas el siguiente plan.

Entonces, ¿cuánta comprar?

• 1 GB: un bot, una API pequeña, un sitio estático.
• 2 GB: el estándar razonable para todo lo que tenga base de datos o Docker.
• 4–6 GB: varios servicios en una máquina, compilaciones en el servidor, un modelo local pequeño.
• 32–64 GB: solo cuando una cosa grande tiene que vivir en memoria: un modelo local de más de 14B, un índice RAG grande, una flota de agentes. Para eso están los planes con mucha memoria.

Empieza una talla por debajo de lo que te dice el instinto, vigila free -h durante una semana y amplía si las cifras lo piden. En EQVPS, cambiar de plan conserva tus datos y solo cobra la diferencia proporcional (cómo funciona el cambio de plan).