Cómo mantener un modelo de Ollama 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 luego libera esa memoria. La siguiente solicitud tiene que volver a cargar los pesos en RAM o VRAM, por lo que se retrasa antes de que llegue el primer token. Por eso una interfaz de chat o un agente de programación parece rápido, queda 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 llama 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 sin solicitudes activas. En octubre 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 presupone que Ollama ya se está ejecutando como servicio. Si no es así, empiece por instalar Ollama en un VPS y vuelva después.

¿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 primero. PROCESSOR indica dónde se cargaron los pesos. 100% GPU y 100% CPU son los casos claros. Una división como 25%/75% CPU/GPU significa que sólo parte del modelo está en la VRAM, por lo que el resto se ejecuta en el procesador y la generación es más lenta. Normalmente se debe a que el modelo no cabe, pero una configuración num_gpu que limita cuántas capas se envían a la GPU produce el mismo tipo de división.

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 de 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. Ollama v0.40.2, la versión actual cuando se comprobó esto el 2026-10-10, también muestra una columna RUNNER entre CONTEXT y UNTIL. Esta columna indica el runner que sirve el modelo, por lo que la cabecera puede tener una columna más que el ejemplo anterior. Para cualquier automatización, consulte la API:

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

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

Qué coste tiene realmente la recarga

No lo suponga. Ollama informa del tiempo de carga en cada respuesta, en 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 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 el coste que asume cada usuario una vez que expira el temporizador, y es la razón principal para cambiar keep_alive. Después de descargar el modelo, la caché de páginas del kernel suele seguir conservando el archivo del modelo. Por eso, en un equipo con RAM disponible, una recarga puede ser más rápida que la primera carga después de iniciar el sistema. Cuando esa caché se recupera, los pesos se leen del disco. Si ha movido el directorio del modelo a un segundo volumen, la velocidad de ese volumen determina el tiempo mínimo de cada carga en frío. Para conocer la velocidad de generación antes y después de esa pausa, consulte 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 termina 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 simple, 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 termine esta solicitud

Un valor incluido en la solicitud reemplaza el 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"}'

Ese 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 que se cargue. La CLI hace lo mismo con una opción:

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

Manténgalo 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 definirse. 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 causa más habitual de que el ajuste parezca ignorarse.

Haz que persista tras 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 con el paquete, por lo que una actualización del paquete de Ollama que sustituya ollama.service no modificará este ajuste. Si los drop-ins y los archivos de unidad son conceptos 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 real con el que se ejecutará el servicio. Si OLLAMA_KEEP_ALIVE=30m no aparece 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 petición tendrá que cargarlos en frío. Precargue el modelo con la llamada de precarga anterior. El drop-in conserva el ajuste después de un reinicio del sistema, pero no el modelo: el servicio se inicia ollama serve sin ningún modelo cargado, por lo que debe ejecutar la misma llamada de precarga después de cada arranque.

Lo que cuesta mantener un modelo residente

La columna SIZE de ollama ps representa la memoria retenida durante todo el periodo de inactividad, no sólo durante una petición. Un modelo 8B con cuantización de 4 bits ocupa aproximadamente entre 5 y 6 GB. Un modelo 27B requiere otro planteamiento, y conviene revisar el cálculo de memoria para ejecutar uno en un VPS que sólo usa CPU antes de decidir mantenerlo residente. Si establece keep_alive en -1, decide que el modelo conservará esa memoria mientras el servidor esté en ejecución, salvo que una petición de otro modelo lo expulse. En un VPS pequeño, esto compite directamente con la base de datos, la aplicación web y los trabajos de compilación.

Observe 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 muestra la memoria que el kernel todavía podría asignar a un proceso nuevo. En un equipo con GPU NVIDIA, nvidia-smi muestra la misma situación en la VRAM. Si el equipo 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 un periodo de mantenimiento activo largo en un equipo sin margen de memoria.

Aquí es fácil pasar por alto dos costes. 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 mientras genera), y esa caché forma parte del tamaño residente. Su tamaño depende de num_ctx, por lo que aumentar la ventana de contexto incrementa la memoria que un modelo residente conserva durante todo el periodo de inactividad, no sólo mientras responde. Un valor de OLLAMA_NUM_PARALLEL superior a 1 reserva esa caché una vez por cada ranura paralela. Si piensa dar servicio a varias personas desde un solo modelo, dimensione la memoria para las ranuras, no sólo para los pesos.

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

Descargar un modelo de inmediato

ollama stop qwen3:8b

No devuelve ninguna salida y el modelo desaparece de ollama ps. Tampoco devuelve ninguna salida si el modelo se ha descargado previamente, pero no está cargado en ese momento. El comando no comprueba qué modelos están en memoria: envía la solicitud de descarga y el servidor responde correctamente tanto si había algo en memoria como si no. El error couldn't find model "qwen3:8b" to stop sólo aparece cuando no hay ningún modelo con ese nombre instalado en este servidor. Normalmente, esto indica un error tipográfico en el nombre o la etiqueta. Por tanto, un ollama stop silencioso no demuestra que se haya liberado memoria. ollama ps sí lo demuestra. 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 incluye "done_reason": "unload". Use este método en lugar de reiniciar el servicio. systemctl restart ollama también libera la memoria, pero descarga todos los demás modelos cargados y cancela cualquier solicitud en curso.

Ejecutar más de un modelo en un servidor

OLLAMA_MAX_LOADED_MODELS limita cuántos modelos pueden permanecer cargados a la vez. Desde octubre 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 espacio mucho antes de llegar a tres.

Cuando se solicita un modelo nuevo y no hay memoria suficiente, o se ha alcanzado el límite, 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 no haya expirado, incluido uno cargado con -1, aunque primero intenta usar modelos con ventanas más cortas. Por tanto, un valor negativo de keep_alive significa que no hay tiempo de espera de inactividad. El modelo no queda fijado para impedir la solicitud de otro modelo.

Estas decisiones aparecen en el registro del servicio. El caso del límite sólo 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 el registro:

sudo journalctl -u ollama -f

Lea el motivo indicado junto a la solicitud que provocó la descarga. max runners achieved, unloading one to make room significa que se alcanzó el límite OLLAMA_MAX_LOADED_MODELS. Esto puede ocurrir aunque ambos modelos quepan en memoria, así que aumente el límite si free -h muestra que hay margen. Si aparece una línea que indica que se prevé que el modelo nuevo supere la memoria disponible, seguida de una expulsión, significa que estos dos modelos no caben juntos en este equipo. La solución es ejecutar menos modelos en este equipo, o usar una ventana larga para el modelo que debe responder rápido y 0 para el que se consulta con poca frecuencia.

Orientación válida más allá de la próxima versión

Ollama publica versiones con frecuencia y sus valores predeterminados cambian, así que 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 esa compilación lee realmente, incluida OLLAMA_KEEP_ALIVE. Dos reglas se han mantenido entre versiones y son una base segura. Un valor incluido en la solicitud tiene prioridad sobre el valor predeterminado del servidor. Además, ollama ps refleja qué está cargado realmente, independientemente de lo que indique un archivo de configuración.

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 valores de la solicitud.

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 petición. Cuando expira, el servidor libera los pesos, por lo que la siguiente petición debe cargarlos de nuevo. Esa recarga es la pausa que se percibe. Auméntelo para una petición enviando "keep_alive": "30m" en el cuerpo JSON, o para todo el servidor con la variable de entorno OLLAMA_KEEP_ALIVE.

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

Use un valor negativo: "keep_alive": -1 en la petición 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. Un reinicio del servicio o del sistema también lo elimina de la memoria, por lo que deberá precargarlo de nuevo después.

¿Por qué se ignora OLLAMA_KEEP_ALIVE?

Compruebe dónde la 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 el shell no llega a un servicio de systemd. Establézcala con sudo systemctl edit ollama.service y ejecute después sudo systemctl daemon-reload y sudo systemctl restart ollama. La otra causa es que un cliente envíe su propio keep_alive en la petición, 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 deja el servidor y todos los demás modelos cargados en ejecución. Mediante la API, envíe una petición 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.