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 una cantidad determinada 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 esta relación:

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

La mayoría de los modelos se publican a 16 bits, lo que equivale a 2 GB por cada mil millones de parámetros. Algunos ya se distribuyen parcialmente cuantizados. Por ejemplo, OpenAI's gpt-oss se sometió a un entrenamiento posterior con los pesos de su mezcla de expertos en MXFP4 de 4 bits. En cualquier caso, casi nadie ejecuta pesos de 16 bits en un VPS. Estas son las cuantizaciones que encontrará en la práctica, 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 referencia de trabajo. Q4_K_M es la opción predeterminada razonable 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 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. Los archivos GGUF reales quedan a pocos puntos porcentuales de esa cifra porque las capas de embedding y de salida se mantienen con una precisión mayor que el 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 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. Quedan unos 3 GB. Esto permite ejecutar un modelo de 1B a 4B con 4 bits y el 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 las cuentas no.

Espere aproximadamente entre 6 y 14 tokens por segundo. Los modelos de este tamaño funcionan bien para tareas acotadas: 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 trabajar con código que abarca varios archivos. Ninguna instrucción adicional corrige esas limitaciones.

El problema habitual en este nivel es el swap. Si el modelo no cabe en la memoria, 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. Ignore la primera línea de la salida de vmstat, que calcula el promedio desde el arranque, y recuerde que los contadores abarcan todo el sistema, no sólo el modelo. Si el uso de swap y el swap liberado permanecen en cero cuando el equipo está inactivo y aumentan en cuanto empieza la generación, el modelo es demasiado grande para el plan contratado.

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é modelos funcionan 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, una cifra coherente con los 43 GB que Ollama indica para Llama 3.3 70B en Q4_K_M. Por tanto, cabe con dificultad en un plan de 48 GB con un contexto corto y necesita 64 GB para cualquier contexto más largo.

Después, interprete 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. A esa velocidad, la solicitud suele fallar antes de que el modelo termine porque algún tiempo de espera del cliente o del proxy situado delante de Ollama se agota primero. De ahí procede el error de límite de tiempo del contexto superado. Estas herramientas están diseñadas para procesamiento por lotes. Puede proporcionarles una cola de documentos durante la noche y la velocidad no será importante. Si las coloca detrás de una ventana de chat, la velocidad será un factor crítico.

El enrutamiento de expertos múltiples cambia estos cálculos. Es el único detalle de arquitectura que merece la pena conocer. Un modelo MoE procesa cada token sólo con una pequeña parte de sus pesos. Un modelo con 30B 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 consulta los expertos activos. En un equipo de 32 GB, un modelo 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 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 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 si el contexto se mantiene corto.
• 48 GB permiten ejecutar un modelo 70B a 4 bits con un contexto moderado. Para contextos largos y más concurrencia, el punto de partida sube a unos 80 GB.

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 parecido a 78%/22% CPU/GPU. Interprételo como una advertencia, no como una característica. La parte 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, la caché es lo que provoca que se supere el límite.

La concurrencia es otra razón para aumentar la capacidad. 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 a usuarios simultáneos desde un único modelo autohospedado muestra hasta dónde llega ese límite.

Determinar si merece la pena alquilar la GPU también es una cuestión 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 esos cálculos.

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 de 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 alrededor de 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 usar 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 leer de la RAM todo el conjunto activo de pesos. Cuando unos pocos núcleos saturan los canales de memoria, los demás simplemente esperan. Otra causa habitual es el uso de swap. Si vmstat 1 muestra si y so en cero antes de enviar el prompt y sus valores aumentan mientras el modelo responde, lo más probable es que los pesos no quepan en la RAM. En ese caso, parte de cada token se obtiene del disco, lo que tiene un coste mucho mayor de lo que parece.

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

Sí. El consumo aumenta de forma lineal con el número de tokens. Un modelo típico de 8B usa unos 128 KiB de caché KV por token. Por tanto, 8192 tokens consumen 1 GB y 131072 tokens consumen 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 sólo 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 comprimido a 2 bits suele dar peores respuestas 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 tienen 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 directamente. El hardware convencional funciona bien para ejecutar un modelo de 8B a 32B destinado a una tarea concreta. En ese contexto, 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 coste del hardware antes de comprar cualquiera de las dos opciones.