Qué modelos de IA puede alojar en su propio servidor

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 servidor. La familia del modelo y el framework importan mucho menos que comprobar si los pesos caben en la memoria y dejan 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.

Dos costes determinan el resultado. Los pesos son el coste fijo, establecido por el número de parámetros y la cuantización. La ventana de contexto es el coste variable, y es el que se suele olvidar hasta que un modelo que se cargó ayer deja de cargarse hoy.

El cálculo de 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, cerca de 1.1 GB por cada mil millones de parámetros.
• Q6_K almacena aproximadamente 6.6 bits, es decir, cerca de 0.83 GB por cada mil millones.
• Q5_K_M almacena aproximadamente 5.7 bits, es decir, cerca de 0.71 GB por cada mil millones.
• Q4_K_M almacena aproximadamente 4.8 bits, es decir, cerca de 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 razonable en un equipo limitado por la 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 suele responder peor que un modelo 32B con 4 bits de la misma generación. Cuando la memoria es 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 mayor que el resto. Un modelo 3B con 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 de contexto consume más RAM que los pesos

La caché KV (caché de claves y valores, el estado de atención que el modelo conserva 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 utiliza medio gigabyte para la caché. Con 8192 tokens utiliza 1 GB. Con el contexto de 128k que anuncia su tarjeta del modelo, utiliza 16 GB, más de tres veces sus pesos. El modelo 70B presenta el caso contrario: su caché con 128k es de 40 GB, menos que sus propios pesos, porque la atención de consultas agrupadas evita que el coste por token crezca casi 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 con 48 GiB o más. Auméntela mediante la variable OLLAMA_CONTEXT_LENGTH en el servidor y compruebe qué valor recibió realmente un modelo en ejecución en la columna CONTEXT de ollama ps. La aritmética de memoria que explica ese ajuste se desarrolla en el artículo sobre num_ctx y la longitud de 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 tarjeta del modelo, ya que la mayoría de las tareas de chat y programación caben en 8k a 32k. Otra opción es cuantizar la propia caché a 8 bits, lo que reduce su tamaño a la mitad, a cambio de cierta pérdida de recuperación en contextos largos.

Un modelo residente mantiene esa cantidad de RAM hasta que algo lo descarga

Ollama mantiene un modelo en memoria durante 5 minutos después de la última solicitud y luego lo descarga. Ese valor predeterminado es adecuado para un portátil, pero no para un servidor, donde la primera solicitud 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. La columna SIZE indica cuánta memoria ocupa cada uno y la columna UNTIL indica cuándo caduca. Para mantener un modelo cargado permanentemente, configure OLLAMA_KEEP_ALIVE=-1 en el servicio. Un valor de 0 lo descarga 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 solicitud y vuelva a ejecutar ollama ps diez minutos después. El modelo seguirá apareciendo en la lista. Ese es precisamente el objetivo: mantiene esa RAM ocupada tanto si alguien lo usa como si 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. Mantener un modelo en memoria explica la relación entre este consumo 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. Quedarán unos 3 GB. Eso permite usar un modelo de 1B a 4B con 4 bits y el contexto predeterminado de 4096 tokens. En agosto de 2026, esa 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 las cuentas no.

Espere aproximadamente entre 6 y 14 tokens por segundo. Los modelos de este tamaño funcionan bien para tareas específicas: clasificación, extracción de etiquetas, resúmenes breves y reescritura de un párrafo según el estilo de la organización. Son débiles para el razonamiento en varios pasos y para el código que abarca varios archivos. Ninguna instrucción adicional corrige esas limitaciones.

El problema habitual en este nivel es la swap. Si el modelo no cabe en la memoria, Linux no se niega a cargarlo. En su lugar, mueve páginas de memoria al disco. Como generar un solo token requiere leer todos los pesos una vez, la generación se degrada hasta tardar varios segundos por token. Supervise free -h y las columnas si y so de vmstat 1 mientras el modelo responde. Un valor distinto de cero en swap in y swap out durante la generación significa que el modelo es demasiado grande para el plan.

Qué se puede ejecutar en un VPS de 8 a 16 GB

Aquí es donde un modelo autoalojado empieza a resultar generalmente útil. En 8 GB puede ejecutar un modelo de 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 de 13B o 14B a 4 bits, con aproximadamente 8.4 GB, o mantener un modelo de 8B a 8 bits si prefiere dedicar la memoria a la precisión en lugar de al número de parámetros.

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

Qué se ejecuta en una VPS de 32 a 64 GB

Un modelo de 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 de 70B a 4 bits ocupa aproximadamente 42 GB, por lo que necesita 64 GB antes de añadir cualquier caché.

Después, evalúe el rendimiento de forma realista. Un modelo 32B en CPU procesa aproximadamente entre 0.6 y 1.5 tokens por segundo, y uno 70B entre 0.2 y 0.5. Una respuesta de 500 tokens de ese modelo 70B tarda unos veinte minutos. A ese ritmo, la solicitud suele terminar antes de que el modelo finalice, porque algún tiempo de espera del cliente o del proxy situado delante de Ollama se agota primero. De ahí procede el error de que se superó el plazo de contexto. Estas herramientas están pensadas para procesamiento por lotes. Puede alimentarlas durante la noche con una cola de documentos y la velocidad deja de ser importante. Si las coloca detrás de una ventana de chat, la velocidad importa mucho.

El enrutamiento 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 de parámetros activos por token necesita la memoria de un modelo de 30B y genera a una velocidad cercana a la de un modelo denso de 3B, porque cada token sólo lee los expertos activos. En un equipo de 32 GB, un MoE con esa configuración es mucho más utilizable que un modelo denso de 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 de 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 y no del número de núcleos. El límite superior se obtiene dividiendo el ancho de banda de memoria utilizable entre el tamaño de los pesos en bytes. Un VPS compartido pequeño suele ofrecer de forma realista 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 VPS normal, 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 compiten por ella. Mida el rendimiento de su propio sistema 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 con el texto 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 también 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 a partir de unos 8 núcleos los núcleos adicionales esperan a la memoria en lugar de realizar operaciones aritméticas. Además, en un plan compartido el mismo comando devuelve valores distintos según la hora. Eso es tiempo de steal de CPU causado por un vecino ruidoso, no un problema de configuración.

Leer el prompt es una tarea distinta de generar la respuesta. El procesamiento del prompt está limitado por la capacidad de cálculo, por lo que escala con el número de núcleos. También es el aspecto en el que una GPU obtiene la mayor ventaja. Una CPU tarda minutos en leer un documento largo, mientras que una GPU tarda segundos. Ese es el primer límite que se alcanza al conectar un agente de programación a un modelo alojado por usted, porque en cada turno se vuelven a enviar el contexto del archivo y las definiciones de las herramientas antes de recibir un solo token de la respuesta.

Qué cambia al añadir una GPU

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

• 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. Considérelo una advertencia, no una característica. La parte que se ejecuta en la CPU marca el ritmo, porque cada token tiene que esperar a esas capas. Por tanto, 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 aparece una división que no esperaba, reduzca primero la longitud del contexto. Normalmente, la caché es lo que hace que se supere el límite.

La concurrencia es otro motivo para aumentar los recursos. Los pesos se comparten entre las solicitudes simultáneas, pero cada solicitud 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. Servir usuarios simultáneos desde un único modelo autoalojado muestra dónde se sitúa ese límite.

Determinar si merece la pena contratar una 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 GPU VPS y los tokens de una API contiene esas cifras.

Lo que no puede alojar por sí mismo

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

El primero son los pesos cerrados. Los modelos comerciales de vanguardia no se distribuyen. Por tanto, no hay ningún archivo que descargar y ninguna cantidad de RAM cambia esa situación. Puede alojar por sí mismo todo lo que los rodea: la interfaz, la capa de recuperación, el bucle del agente y los registros. El modelo sigue siendo una API remota. Si puede alojar Claude por sí mismo 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 aproximadamente 240 GB sólo para los pesos, antes de añadir cualquier caché. Eso requiere hardware especializado, y alquilarlo durante un mes cuesta mucho más de lo que la mayoría de las personas gasta en tokens de API durante un año. Qué se necesita para alojar por sí mismo un modelo de clase Kimi explica los requisitos reales. La misma diferencia aparece en la propia biblioteca de Ollama, donde GLM 5.2 sólo figura como modelo en la nube y el modelo hermano, mucho más pequeño, es el que realmente se descarga en un VPS.

La distinción práctica es clara: aloje por sí mismo cuando la carga sea constante 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 los modelos de vanguardia.

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 la memoria que el sistema ya está utilizando. Reste aproximadamente 1 GB para el sistema operativo y el servidor del modelo. Divida el resultado entre 0.6 para obtener el número máximo de parámetros, en miles de millones, que puede admitir con 4 bits. Después, reste la caché KV correspondiente al contexto que realmente quiere utilizar. El resultado es la respuesta y, a diferencia de una lista de nombres de modelos, no queda obsoleto.

FAQ

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

Aproximadamente 4.8 GB para los pesos con cuantización de 4 bits, más 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 necesita 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 extraer de la RAM todo el conjunto activo de pesos. Cuando unos pocos núcleos saturan los canales de memoria, los demás tienen que esperar. Otra causa habitual es el uso de 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 sirve desde el disco. Esto tiene un coste mucho mayor del esperado.

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

Sí. El crecimiento es lineal respecto al número de tokens. Un modelo 8B típico utiliza aproximadamente 128 KiB de caché KV por token. Por tanto, 8192 tokens requieren 1 GB y 131072 tokens requieren 16 GB. La caché se asigna cuando se carga el modelo, no cuando crece la conversación. Por eso, solicitar un contexto de 128k reserva esa memoria de inmediato, 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 entre 8 y 4 bits, pero cae rápidamente por debajo de 4 bits. Por eso, un modelo 70B comprimido a 2 bits suele dar peores respuestas que un modelo 32B a 4 bits de la misma generación. La cuantización excesiva 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 en su lugar.

¿Puedo alojar yo mismo un modelo tan capaz como los grandes modelos comerciales?

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