Qué modelos de IA puede alojar según su RAM

Qué determina los modelos de IA que puede alojar por su cuenta

Los modelos de IA que puede alojar por su cuenta dependen de una cifra: la RAM del equipo. La familia del modelo y el framework importan mucho menos que saber si los pesos caben en la memoria y queda margen disponible. Este artículo explica las operaciones necesarias para calcularlo. Instalar un runtime es una tarea independiente, que se explica en la guía para ejecutar Ollama en un VPS.

La respuesta depende de dos costes. Los pesos son el coste fijo, determinado por el número de parámetros y la cuantización. La ventana de contexto es el coste variable, y es el que muchas personas olvidan hasta que un modelo que se cargó ayer deja de cargarse hoy.

La aritmética del dimensionamiento: bits por parámetro

Un archivo de modelo contiene casi exclusivamente pesos. Cada peso se almacena con un número determinado de bits. La cuantización consiste en almacenarlos con menos bits que la precisión con la que se entrenaron. Esto reduce ligeramente la precisión y ahorra mucha memoria. El tamaño se obtiene directamente de esa relación:

weights in GB = (parameters in billions x bits per weight) / 8

Los modelos se publican con 16 bits, lo que equivale a 2 GB por cada mil millones de parámetros. Por eso casi nadie ejecuta la precisión de publicación en un VPS. Estas son las cuantizaciones que encontrará habitualmente, con su promedio real de bits por peso:

• Q8_0 almacena aproximadamente 8.5 bits por peso, es decir, unos 1.1 GB por cada mil millones de parámetros.
• Q6_K almacena aproximadamente 6.6 bits, es decir, unos 0.83 GB por cada mil millones.
• Q5_K_M almacena aproximadamente 5.7 bits, es decir, unos 0.71 GB por cada mil millones.
• Q4_K_M almacena aproximadamente 4.8 bits, es decir, unos 0.6 GB por cada mil millones.

Use 0.6 GB por cada mil millones de parámetros como valor de referencia. Q4_K_M es la opción predeterminada adecuada en un equipo limitado por memoria: la pérdida de calidad frente a 8 bits es pequeña en la mayoría de las tareas y el archivo ocupa casi la mitad. Por debajo de 4 bits, la pérdida aumenta rápidamente. Por eso, un modelo 70B reducido a 2 bits normalmente responde peor que un modelo 32B a 4 bits de la misma generación. Cuando la memoria sea limitada, reduzca una categoría de tamaño antes de bajar de 4 bits.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

La columna de pesos anterior aplica la regla de 0.6 GB por cada mil millones de parámetros. Los archivos GGUF reales quedan a pocos puntos porcentuales de ese valor, porque las capas de embeddings y de salida se mantienen con una precisión superior a la del resto. Un modelo 3B a 4 bits ocupa aproximadamente 1.8 GB. Uno 8B ocupa 4.8 GB. Uno 32B ocupa 19.2 GB, y uno 70B ocupa 42 GB.

Por qué la longitud del contexto consume más RAM que los pesos

La caché KV (caché de claves y valores, el estado de atención que el modelo mantiene para cada token de la conversación actual) es el segundo coste. Se asigna cuando se carga el modelo, se dimensiona según la longitud de contexto solicitada y crece de forma lineal con esa longitud.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Con el contexto predeterminado de Ollama, ese modelo 8B usa medio gigabyte para la caché. Con 8192 tokens usa 1 GB. Con el contexto de 128k que anuncia su ficha, usa 16 GB, más de tres veces el tamaño de los pesos. El modelo 70B presenta el caso contrario: su caché con 128k ocupa 40 GB, menos que sus propios pesos, porque la atención de consultas agrupadas evita que el coste por token crezca ni de lejos al mismo ritmo que el número de parámetros.

La longitud de contexto predeterminada de Ollama es de 4096 tokens en un servidor que sólo usa CPU. Cuando hay una GPU, selecciona el valor predeterminado según la VRAM: 32k entre 24 y 48 GiB, y 256k a partir de 48 GiB. Auméntala con la variable OLLAMA_CONTEXT_LENGTH en el servidor y compruebe después qué valor recibió realmente un modelo en ejecución en la columna CONTEXT de ollama ps. El cálculo de memoria que sustenta ese ajuste se explica paso a paso en la publicación sobre num_ctx y la longitud del contexto.

Hay dos formas de reducir de nuevo el tamaño de la caché. Solicite el contexto que necesita en lugar del contexto que anuncia la ficha del modelo, ya que la mayoría de las tareas de chat y programación caben en 8k a 32k. También puede cuantizar la propia caché a 8 bits, lo que reduce su tamaño a la mitad, aunque con cierto coste en la recuperación de información en contextos largos.

Un modelo residente mantiene esa memoria RAM hasta que algo lo descarga

Ollama mantiene un modelo en memoria durante 5 minutos después de la última petición y luego lo descarga. Ese valor predeterminado es adecuado para un portátil, pero no para un servidor, donde la primera petición después de cada periodo de inactividad vuelve a pagar el tiempo de carga.

ollama ps
ollama stop qwen3:4b

ollama ps muestra los modelos residentes, con una columna SIZE que indica cuánta memoria ocupa cada uno y una columna UNTIL que indica cuándo caduca. Para fijar un modelo de forma permanente, configure OLLAMA_KEEP_ALIVE=-1 en el servicio. Un valor de 0 hace que se descargue en cuanto termina cada respuesta.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Envíe una petición y vuelva a ejecutar ollama ps diez minutos después. El modelo seguirá apareciendo en la lista. Ese es precisamente el objetivo: mantiene esa memoria RAM ocupada, se esté usando o no. Un modelo fijado no es capacidad disponible. En un VPS de 16 GB, un modelo 8B con un contexto de 8k mantiene aproximadamente 6 GB ocupados mientras el servicio esté activo. Por tanto, dimensione el servidor para el modelo y la aplicación, no sólo para el modelo. Fijar un modelo en memoria explica la relación entre esta opción y la latencia de arranque en frío.

Qué se puede ejecutar en un VPS de 4 GB

Reserve aproximadamente 1 GB para el sistema operativo y el servidor del modelo. Quedan unos 3 GB. Eso permite ejecutar un modelo de 1B a 4B con 4 bits y un contexto predeterminado de 4096 tokens. En agosto de 2026, esta categoría incluye Llama 3.2 de 3B, Qwen 3 de 1.7B y 4B, y las versiones pequeñas de Gemma y Phi. Tómelos como ejemplos de tamaño, no como recomendaciones. Los nombres cambian cada pocos meses, pero el cálculo no.

Espere aproximadamente 6 a 14 tokens por segundo. Estos modelos pequeños funcionan bien para tareas específicas: clasificación, extracción de etiquetas, resúmenes breves y reescritura de un párrafo con el estilo establecido. Son débiles para el razonamiento en varios pasos y para código que abarca varios archivos. Ninguna cantidad de instrucciones bien formuladas corrige esa limitación.

El problema habitual en este nivel es la memoria swap. Si el modelo no cabe, Linux no se niega a cargarlo. En su lugar, pagina la memoria al disco. Como la generación de cada token lee todos los pesos una vez, el rendimiento cae hasta varios segundos por token. Supervise free -h y las columnas si y so de vmstat 1 mientras el modelo responde. Una actividad distinta de cero en la entrada y salida de swap durante la generación significa que el modelo es demasiado grande para ese plan.

Qué se ejecuta en un VPS de 8 a 16 GB

Aquí es donde un modelo autoalojado empieza a ser generalmente útil. En 8 GB puede ejecutar un modelo 7B u 8B a 4 bits, con aproximadamente 4.8 GB de pesos y un contexto de 8k. En 16 GB puede ejecutar un modelo 13B o 14B a 4 bits, con aproximadamente 8.4 GB, o mantener un modelo 8B a 8 bits si prefiere dedicar la memoria a la precisión en lugar de al número de parámetros.

La limitación es la velocidad. Un modelo 8B en CPU genera aproximadamente entre 3 y 7 tokens por segundo, y un modelo 14B entre 1.5 y 3.5. Una persona lee aproximadamente entre 5 y 10 tokens por segundo, por lo que un modelo 8B en un VPS con CPU se percibe como un mecanógrafo lento. Esto es adecuado para una tarea en segundo plano, pero resulta incómodo para un chat interactivo. Ejecuciones medidas de Qwen 3 a 8B y tamaños superiores en un VPS muestran cómo funciona en la práctica.

Qué puede ejecutarse en una VPS de 32 a 64 GB

Un modelo 32B a 4 bits ocupa aproximadamente 19.2 GB, por lo que cabe en un plan de 32 GB con un contexto corto y funciona con margen en 48 GB o 64 GB. Un modelo 70B a 4 bits ocupa aproximadamente 42 GB, por lo que necesita 64 GB antes de añadir cualquier caché.

Después, evalúe la velocidad de forma realista. Un modelo 32B en CPU funciona a aproximadamente 0.6 a 1.5 tokens por segundo, y un modelo 70B a 0.2 a 0.5. Una respuesta de 500 tokens de ese modelo 70B tarda aproximadamente veinte minutos. Estas herramientas están pensadas para procesar lotes. Si les entrega una cola de documentos durante la noche, la velocidad no importa. Si las conecta a una interfaz de chat, importa mucho.

La asignación de expertos de los modelos de mezcla de expertos cambia este cálculo. Es el único detalle de arquitectura que merece la pena aprender. Un modelo MoE procesa cada token sólo con una pequeña parte de sus pesos. Un modelo con 30B de parámetros totales y 3B activos por token necesita la memoria de un modelo 30B y genera a una velocidad cercana a la de un modelo denso 3B, porque cada token sólo lee los expertos activos. En un equipo de 32 GB, un MoE con esas características es mucho más utilizable que un modelo denso 30B. La regla que debe recordar es la siguiente: los parámetros totales determinan la memoria y los parámetros activos determinan la velocidad.

¿Qué velocidad alcanza realmente la inferencia en CPU?

Generar un token requiere leer una vez desde la memoria todos los pesos activos. No hay forma de evitarlo, por lo que la velocidad de generación en una CPU depende del ancho de banda de memoria, no del número de núcleos. El límite se obtiene dividiendo el ancho de banda de memoria utilizable entre el tamaño de los pesos en bytes. Un VPS compartido pequeño ofrece en la práctica entre 10 y 25 GB por segundo entre sus vCPU, por lo que un modelo de 4.8 GB alcanza como máximo entre 2 y 5 tokens por segundo.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

Estos son intervalos habituales en hardware de VPS ordinario, no una medición de una máquina concreta. El resultado depende de la generación de memoria, del número de canales del host y de cuántos vecinos compitan por ella. Mida el suyo con cualquier etiqueta de modelo que ya tenga:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

El resumen que se muestra después de terminar la respuesta incluye una línea que dice eval rate: ... tokens/s. Esa es la velocidad de generación. Ignore la primera ejecución de una sesión, porque load duration del mismo resumen incluye la lectura de los pesos desde el disco. Medir correctamente los tokens por segundo explica cómo obtener un valor que se pueda comparar.

Aquí hay dos resultados que suelen sorprender. Añadir vCPU deja de ayudar rápidamente, porque después de aproximadamente 8 núcleos los núcleos adicionales esperan a la memoria en lugar de realizar cálculos. Además, en un plan compartido el mismo comando devuelve valores diferentes según la hora. Esto se debe al tiempo de CPU robado por un vecino ruidoso, no a una configuración incorrecta.

Leer el prompt es una tarea distinta de generar la respuesta. El procesamiento del prompt depende de la capacidad de cálculo, por lo que escala con el número de núcleos. También es donde una GPU obtiene la mayor ventaja. Una CPU tarda minutos en leer un documento largo, mientras que una GPU tarda segundos. Este es el primer límite que encuentra al dirigir un agente de programación a un modelo que aloja, porque cada turno vuelve a enviar el contexto del archivo y las definiciones de las herramientas antes de que llegue un solo token de la respuesta.

Qué cambia al añadir una GPU

La aritmética no cambia. Sólo cambia el conjunto de recursos al que se aplica. La VRAM es un límite estricto, así que calcule qué cabe antes de alquilar:

• 8 GB de VRAM permiten ejecutar un modelo 7B u 8B a 4 bits con un contexto corto.
• 16 GB permiten ejecutar un modelo 14B a 4 bits con un contexto real, o un modelo 8B a 8 bits.
• 24 GB permiten ejecutar un modelo 32B a 4 bits con el contexto corto.
• 48 GB o más permiten ejecutar un modelo 70B a 4 bits con espacio para la caché y la concurrencia.

Cuando un modelo no cabe, Ollama lo divide: algunas capas se ejecutan en la GPU y el resto en la CPU. ollama ps muestra la división en su columna PROCESSOR, con un valor similar a 78%/22% CPU/GPU. Interprételo como una advertencia, no como una ventaja. La mitad que se ejecuta en la CPU marca el ritmo, porque cada token sigue esperando a esas capas. Por eso, un modelo con una cuarta parte de sus capas en la CPU funciona mucho más cerca de la velocidad de la CPU que de la velocidad de la GPU. Si observa una división que no pretendía, reduzca primero la longitud del contexto. Normalmente, lo que hizo que se superara el límite fue la caché.

La concurrencia es otra razón para elegir una instancia más grande. Los pesos se comparten entre las peticiones simultáneas, pero cada petición activa necesita su propia caché KV. Por tanto, diez usuarios simultáneos de un modelo 8B con un contexto de 8k necesitan diez veces 1 GB de caché, además de los pesos. Atender a usuarios simultáneos desde un solo modelo autoalojado explica dónde se sitúa ese límite.

Determinar si merece la pena alquilar la GPU también es una cuestión de aritmética. Depende de cuántos tokens genere realmente al mes. El punto de equilibrio entre una VPS con GPU y los tokens de una API contiene esas cifras.

Lo que no puede alojar por su cuenta

Aquí hay dos límites diferentes. Conviene saber cuál está encontrando.

El primero son los pesos cerrados. Los modelos comerciales de frontera no se distribuyen, por lo que no hay ningún archivo que descargar y ninguna cantidad de RAM puede cambiarlo. Puede alojar por su cuenta todo lo que los rodea: la interfaz, la capa de recuperación, el ciclo del agente y los registros. El modelo sigue siendo una API remota. Si puede alojar Claude por su cuenta lo explica en detalle.

El segundo son los pesos abiertos que simplemente son demasiado grandes. Las versiones abiertas más grandes utilizan arquitecturas de mezcla de expertos con cientos de miles de millones de parámetros totales. La misma regla se aplica a estos modelos: un modelo de 400B parámetros totales a 4 bits necesita unos 240 GB sólo para los pesos, sin contar ninguna caché. Eso requiere hardware especializado, y alquilarlo por mes cuesta mucho más de lo que la mayoría de las personas gastan en tokens de API durante un año. Qué se necesita para alojar por su cuenta un modelo de la clase Kimi explica los requisitos reales.

La distinción práctica entre ambos casos es clara: aloje por su cuenta cuando la carga sea estable y los datos no deban salir de su servidor. Compre tokens cuando la carga sea variable o cuando lo que realmente necesite sea la calidad de respuesta de un modelo de frontera.

Compruebe los recursos disponibles antes de elegir

free -h
nproc
lscpu | grep 'Model name'

Planifique usando la columna available de free -h, no la columna total, porque total incluye memoria que el sistema ya está utilizando. Reste aproximadamente 1 GB para el sistema operativo y el servidor de modelos. Divida el resultado entre 0.6 para obtener el mayor número de parámetros, en miles de millones, que puede alojar con 4 bits. Después, reste la caché KV correspondiente al contexto que realmente desea. El resultado es la respuesta. A diferencia de una lista de nombres de modelos, no queda obsoleta.

FAQ

¿Cuánta RAM necesito para ejecutar un modelo de 8B?

Aproximadamente 4.8 GB para los pesos con cuantización de 4 bits, además de la caché KV correspondiente a la longitud de contexto y aproximadamente 1 GB para el sistema operativo y el servidor del modelo. Con un contexto de 8192 tokens, la caché añade unos 1 GB, por lo que un plan de 8 GB funciona y uno de 4 GB no. Si quiere utilizar el contexto completo de 128k que anuncia la ficha del modelo, la caché por sí sola ocupa 16 GB y necesitará un plan de 32 GB.

¿Por qué mi modelo es lento aunque el VPS tenga muchos vCPU?

Porque la generación está limitada por el ancho de banda de memoria, no por el número de núcleos. Para generar cada token hay que cargar todo el conjunto activo de pesos desde la RAM. Cuando unos pocos núcleos saturan los canales de memoria, los demás simplemente esperan. Otra causa habitual es la swap. Si vmstat 1 muestra un valor distinto de cero en si y so mientras el modelo responde, los pesos no caben en la RAM y parte de cada token se procesa desde el disco. Esto tiene un coste muy superior al esperado.

¿Una ventana de contexto más larga realmente necesita más memoria?

Sí. El consumo crece de forma lineal con el número de tokens. Un modelo de 8B típico utiliza unos 128 KiB de caché KV por token. Por tanto, 8192 tokens ocupan 1 GB y 131072 tokens ocupan 16 GB. La caché se reserva cuando se carga el modelo, no cuando crece la conversación. Por eso, solicitar un contexto de 128k reserva esa memoria inmediatamente, aunque cada prompt que envíe tenga 200 tokens.

¿Debo ejecutar un modelo grande a 2 bits o uno más pequeño a 4 bits?

Elija el modelo más pequeño a 4 bits. La calidad disminuye lentamente de 8 a 4 bits y rápidamente por debajo de 4 bits. Por eso, un modelo de 70B reducido a 2 bits normalmente proporciona respuestas peores que un modelo de 32B a 4 bits de la misma generación. La cuantización agresiva se manifiesta como repeticiones y omisión de instrucciones, no como un mensaje de error. Esto facilita atribuir el problema al prompt. Considere 4 bits como el límite inferior y cambie el número de parámetros.

¿Puedo alojar por mi cuenta un modelo tan capaz como los grandes modelos comerciales?

No en un VPS normal. Los modelos de pesos abiertos más potentes llegan a cientos de miles de millones de parámetros. Con 4 bits, necesitan más de 200 GB de RAM antes de añadir la caché KV. Además, los modelos comerciales más potentes no se distribuyen. El hardware convencional funciona bien para ejecutar un modelo de 8B a 32B destinado a una tarea concreta. En ese caso, un modelo pequeño, especializado y con un prompt bien diseñado suele igualar a uno generalista. Si necesita calidad de vanguardia, compare el precio de la API con el coste del hardware antes de comprar cualquiera de las dos opciones.