Cómo mantener un modelo de Ollama cargado en memoria

¿Por qué Ollama descarga el modelo después de unos minutos?

Ollama mantiene un modelo cargado en memoria durante cinco minutos después de la última solicitud y, después, lo libera. La siguiente solicitud debe volver a leer los pesos del disco y asignarlos en la RAM o la VRAM, por lo que se detiene antes de mostrar el primer token. Por eso una interfaz de chat o un agente de programación parece rápido, permanece inactivo durante un tiempo y vuelve a parecer lento con el siguiente mensaje. No hay ningún problema. El temporizador de inactividad ha expirado.

El temporizador se denomina keep_alive. Se aplica a cada modelo y se reinicia cada vez que termina una solicitud. Un modelo que está respondiendo a una solicitud nunca se descarga, porque el servidor sólo expira un modelo que no tiene solicitudes activas. En agosto de 2026, el valor predeterminado es de cinco minutos y se aplica a todos los modelos que carga este servidor.

Hay dos lugares donde se puede configurar keep_alive: en la solicitud individual o como valor predeterminado del servidor. Un drop-in de systemd hace que el valor predeterminado del servidor se conserve después de un reinicio. Esta guía supone que Ollama ya se está ejecutando como servicio. Si no es así, empiece por instalar Ollama en un VPS y vuelva aquí.

¿Qué modelos están cargados ahora y cuándo caducan?

ollama ps

NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

Una salida vacía significa que no hay ningún modelo cargado, por lo que la siguiente solicitud debe cargarlo por completo. PROCESSOR indica dónde se cargaron los pesos. 100% GPU y 100% CPU son los casos claros. Un valor dividido como 25%/75% CPU/GPU significa que el modelo no cabía en la VRAM, por lo que una parte se ejecuta en el procesador y la generación es más lenta.

UNTIL es la cuenta atrás y muestra un tiempo relativo como 4 minutes from now. Muestra Forever cuando el modelo se cargó con un valor negativo en keep_alive. Muestra Stopping... durante el breve intervalo en el que el servidor está descargando el modelo.

El conjunto de columnas ha cambiado entre versiones, así que lea la cabecera en lugar de contar los campos en un script. Para cualquier automatización, consulte la API:

curl -s http://localhost:11434/api/ps

Cada entrada contiene expires_at, una marca de tiempo absoluta como 2026-08-09T14:38:31.83753Z, y size_vram, la parte de ese modelo que está en la memoria de la GPU. Un valor size_vram de 0 significa que el modelo se ejecuta en la CPU.

El coste real de la recarga

No lo suponga. Ollama informa del tiempo de carga en cada respuesta mediante load_duration, expresado en nanosegundos.

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

La primera llamada carga el modelo, por lo que su valor de load_duration es alto. Divídalo entre 1000000000 para leerlo en segundos. La segunda llamada se ejecuta mientras el modelo permanece residente e informa de un valor mucho menor. La diferencia entre esas dos cifras es lo que cada usuario espera una vez que el temporizador ha expirado, y es el motivo para cambiar keep_alive. Para consultar la velocidad de generación antes y después de esa pausa, vea cómo medir los tokens por segundo en su propio equipo.

Mantener un modelo de Ollama cargado en memoria durante una solicitud

Envíe keep_alive con la solicitud. Se aplica a ese modelo desde el momento en que finaliza la solicitud.

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

Se aceptan cuatro formas de valor:

• una cadena de duración: "30m", "24h", "90s"
• un número sin formato, interpretado como segundos: 3600
• un valor negativo, -1 o "-1m", que significa que no hay tiempo de espera por inactividad
• 0, que significa descargar el modelo en cuanto finalice esta solicitud

Un valor incluido en la solicitud sustituye al valor predeterminado del servidor en ambos sentidos. Esto es más importante de lo que parece: un cliente que envía su propio keep_alive tiene prioridad sobre cualquier valor configurado en el servidor.

También puede cargar un modelo sin generar nada. Envíe sólo el nombre del modelo. El servidor lo carga y devuelve una respuesta vacía con "done": true.

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

Este es el comando que debe ejecutar después de reiniciar o de descargar un modelo nuevo, para que la primera solicitud real de un usuario no tenga que esperar a la carga. La CLI hace lo mismo con una opción:

ollama run --keepalive 30m qwen3:8b "hello"

Mantenerlo cargado de forma predeterminada con OLLAMA_KEEP_ALIVE

El servidor lee OLLAMA_KEEP_ALIVE al iniciarse y lo usa para todos los modelos que no tengan un valor propio. Admite los mismos formatos que el campo de la solicitud, por lo que funcionan 30m, 3600 y -1.

El punto importante es en qué entorno debe estar definida la variable. Ejecutar export OLLAMA_KEEP_ALIVE=30m en la sesión SSH no tiene ningún efecto, porque la instalación empaquetada ejecuta el servidor como un servicio de systemd, con su propio usuario y su propio entorno. El shell de inicio de sesión y ese servicio no comparten el entorno. Esta es la razón más habitual por la que parece que la configuración se ignora.

Haz que sobreviva a un reinicio con un drop-in de systemd

sudo systemctl edit ollama.service

El editor se abre con dos marcadores de comentario. Escriba entre ellos: systemd descarta todo lo que escriba debajo del segundo marcador.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

Al guardar se escribe /etc/systemd/system/ollama.service.d/override.conf. Es un drop-in, no una modificación de la unidad distribuida, por lo que una actualización del paquete Ollama que sustituya ollama.service no modificará este ajuste. Si los drop-ins y los archivos de unidad son nuevos para usted, la guía de servicios y temporizadores de systemd explica su funcionamiento.

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

El último comando muestra el entorno con el que se ejecutará realmente el servicio. Si falta OLLAMA_KEEP_ALIVE=30m en esa línea, el drop-in no se aplicó. La causa casi siempre es la falta de la cabecera [Service] o que se hayan escrito líneas debajo del marcador. El reinicio descarga todos los modelos cargados, por lo que la siguiente solicitud requiere una carga en frío. Caliéntelo con la llamada de precarga anterior.

El coste de mantener un modelo residente

La columna SIZE de ollama ps indica la memoria retenida durante toda la ventana de inactividad, no sólo durante una petición. Un modelo de 8B con cuantización de 4 bits ocupa alrededor de 5 a 6 GB. Un modelo de 27B requiere otro planteamiento, y conviene revisar el cálculo de memoria para ejecutar uno en una VPS sólo con CPU antes de decidir mantenerlo residente. Si establece keep_alive en -1, decide que el modelo tendrá prioridad permanente sobre todo lo demás del sistema. En una VPS pequeña, esto compite directamente con la base de datos, la aplicación web y los trabajos de compilación.

Compruebe las cifras reales en lugar de confiar en una estimación. Ejecute esto mientras haya un modelo cargado y repítalo después de ollama stop:

free -h

La columna available indica la memoria que el kernel todavía puede asignar a un proceso nuevo. En un sistema con GPU NVIDIA, nvidia-smi muestra la misma situación en la VRAM. Si el sistema se queda sin memoria, el kernel termina un proceso para recuperarla:

sudo dmesg -T | grep -i "out of memory"

Una línea que menciona ollama indica que el servidor del modelo fue la víctima. Una línea que menciona la base de datos indica que el modelo ganó y que se perdió algo importante. Ambos resultados proceden de la misma decisión: usar una ventana keep-alive larga en un sistema sin margen de memoria.

Hay dos costes fáciles de pasar por alto. Una longitud de contexto mayor reserva una caché KV más grande (caché de valores y claves, el estado de atención por token que el modelo conserva durante la generación), y esa caché forma parte del tamaño residente. Un valor de OLLAMA_NUM_PARALLEL superior a 1 reserva esa caché una vez por cada slot paralelo. Si piensa atender a varias personas con un solo modelo, dimensione la memoria para los slots, no sólo para los pesos.

Un valor predeterminado razonable es que un modelo en un sistema con margen de memoria use -1. Un sistema compartido debería usar una ventana que cubra los intervalos entre sus peticiones, como 30m, para que la memoria se libere cuando deje de trabajar.

Descargar un modelo inmediatamente

ollama stop qwen3:8b

No devuelve ninguna salida y el modelo desaparece de ollama ps. Un nombre que no está cargado devuelve couldn't find model "qwen3:8b" to stop. En la API, se envía una solicitud sin prompt y con keep_alive establecido en 0:

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

La respuesta contiene "done_reason": "unload". Use esta opción en lugar de reiniciar el servicio. systemctl restart ollama también libera la memoria, pero descarga todos los demás modelos cargados y termina cualquier solicitud que estuviera en ejecución.

Ejecutar varios modelos en un mismo servidor

OLLAMA_MAX_LOADED_MODELS limita cuántos modelos pueden permanecer cargados a la vez. Desde agosto de 2026, el valor predeterminado es tres por GPU, o tres en un equipo que sólo usa CPU. El límite cuenta modelos, pero la memoria es la limitación real. Por eso, un segundo modelo grande puede quedarse sin memoria mucho antes de llegar a tres.

Cuando se solicita un modelo nuevo y no hay memoria suficiente para cargarlo, el planificador descarga uno de los modelos residentes para liberar espacio. Prefiere uno que no tenga ninguna solicitud activa. También puede expulsar un modelo cuyo temporizador todavía no haya expirado, incluido un modelo cargado con -1. Por tanto, un valor negativo de keep_alive significa que no hay tiempo de espera por inactividad. No fija los pesos para impedir que se atienda la solicitud de otro modelo.

Esta decisión se registra en el nivel de depuración. Añada una segunda línea Environment="OLLAMA_DEBUG=1" al mismo drop-in, reinicie el servicio y supervise:

sudo journalctl -u ollama -f

Una línea sobre la descarga de un runner para liberar espacio, junto a la solicitud que la provocó, indica que estos dos modelos no caben juntos en este equipo. La solución es ejecutar menos modelos en este servidor, o establecer una ventana larga para el modelo que debe responder con rapidez y usar 0 para el modelo que se solicita rara vez.

Orientaciones que no dependen de la próxima versión

Ollama publica versiones con frecuencia y sus valores predeterminados cambian. Por eso, compruebe la compilación que tiene delante en lugar de memorizar números:

ollama --version
ollama serve --help

ollama serve --help muestra las variables de entorno que la compilación lee realmente, incluida OLLAMA_KEEP_ALIVE. Dos reglas se han mantenido entre versiones y permiten configurar el sistema con seguridad. Un valor incluido en la petición tiene prioridad sobre el valor predeterminado del servidor. Y ollama ps refleja lo que está cargado realmente, independientemente de lo que un archivo de configuración indique que debería estar cargado.

Si un editor o un agente controla el servidor, compruebe qué envía ese cliente antes de atribuir el problema al servidor. Configurar un agente de programación para usar su propio servidor Ollama explica dónde se encuentran esos ajustes de la petición.

FAQ

¿Por qué Ollama descarga mi modelo después de 5 minutos?

Cinco minutos es el valor predeterminado de keep_alive, el temporizador de inactividad que Ollama inicia cuando termina una solicitud. Cuando vence, el servidor libera los pesos, por lo que la siguiente solicitud los vuelve a cargar desde el disco. Esa recarga es la pausa que se percibe. Auméntelo para una solicitud enviando "keep_alive": "30m" en el cuerpo JSON, o para todo el servidor mediante la variable de entorno OLLAMA_KEEP_ALIVE.

¿Cómo mantengo un modelo de Ollama cargado en memoria permanentemente?

Use un valor negativo: "keep_alive": -1 en la solicitud o OLLAMA_KEEP_ALIVE=-1 para el servidor. ollama ps muestra entonces Forever en la columna UNTIL. Esto elimina el temporizador de inactividad y nada más. Si se solicita otro modelo y queda poca memoria, el planificador seguirá descargando este modelo para liberar espacio.

¿Por qué se ignora OLLAMA_KEEP_ALIVE?

Compruebe dónde lo configuró. Ejecute systemctl show ollama --property=Environment. Si la variable no aparece en esa salida, el servidor nunca la recibió, porque una variable exportada en su shell no llega a un servicio de systemd. Configúrela con sudo systemctl edit ollama.service y ejecute después sudo systemctl daemon-reload y sudo systemctl restart ollama. La otra causa es un cliente que envía su propio keep_alive en la solicitud, lo que sobrescribe el valor predeterminado del servidor.

¿Cómo libero la memoria sin reiniciar Ollama?

ollama stop qwen3:8b descarga ese modelo de inmediato y mantiene en ejecución el servidor y todos los demás modelos cargados. Mediante la API, envíe una solicitud sin prompt y con "keep_alive": 0. La respuesta incluirá "done_reason": "unload". Confírmelo con ollama ps, que ya no debería mostrar el modelo.