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 petición y, a continuación, libera esa memoria. La siguiente petición tiene que volver a leer los pesos del disco y asignarlos en la RAM o la VRAM, por lo que se detiene antes de que llegue 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 mensaje siguiente. 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 finaliza una petición. Un modelo que está respondiendo a una petición nunca se descarga, porque el servidor sólo expira un modelo que no tiene ninguna petición activa. En agosto de 2026, el valor predeterminado es de cinco minutos y se aplica a todos los modelos que carga este servidor.

keep_alive se puede configurar en dos lugares: en la petición individual o como valor predeterminado del servidor. Un drop-in de systemd hace que el valor predeterminado del servidor se mantenga 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 tendrá que 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 de keep_alive. Muestra Stopping... durante el breve intervalo en el que el servidor está descargando el modelo.

Las columnas han cambiado entre versiones, así que lea la cabecera en lugar de contar los campos en un script. Para cualquier proceso automatizado, 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 de ese modelo que se encuentra en la memoria de la GPU. Un valor size_vram de 0 significa que el modelo se está ejecutando en la CPU.

Lo que cuesta realmente la recarga

No lo suponga. Ollama informa del tiempo de carga en cada respuesta, como load_duration, 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 load_duration es alto. Divídalo entre 1000000000 para leerlo en segundos. La segunda llamada se ejecuta mientras el modelo permanece en memoria y muestra un valor mucho menor. La diferencia entre esas dos cifras es lo que cada usuario paga una vez que el temporizador ha expirado, y es la razón principal para cambiar keep_alive. La mayor parte de esa diferencia corresponde a la lectura del disco. Por tanto, 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 consultar la velocidad de generación a ambos lados 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 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 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 con el paquete. Por tanto, una actualización del paquete Ollama que sustituya ollama.service no modifica su configuración. 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 con el que se ejecutará realmente 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 requiere una carga en frío. Precargue el modelo 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 8B con cuantización de 4 bits ocupa aproximadamente entre 5 y 6 GB. Un modelo 27B plantea una situación distinta, y conviene revisar el cálculo de memoria para ejecutar uno en una VPS que sólo usa CPU antes de decidir mantenerlo residente. Si establece keep_alive en -1, decide que el modelo tiene prioridad permanente sobre todo lo demás en el servidor. En una VPS pequeña, esto compite directamente con la base de datos, la aplicación web y los trabajos de compilación.

Compruebe los valores reales en lugar de confiar en una estimación. Ejecute esto mientras haya un modelo cargado y vuelva a ejecutarlo después de ollama stop:

free -h

La columna available indica la memoria que el kernel todavía podría asignar a un proceso nuevo. En un servidor con GPU NVIDIA, nvidia-smi muestra la misma situación en la VRAM. Si el servidor 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 de mantenimiento activa prolongada en un servidor 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 mantiene mientras genera), y esa caché forma parte del tamaño residente. Su tamaño depende de num_ctx. Por tanto, aumentar la ventana de contexto incrementa la memoria que el modelo residente mantiene 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 atender a varias personas con 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 servidor con suficiente margen use -1. Un servidor 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. Si el nombre no está cargado, devuelve couldn't find model "qwen3:8b" to stop. La forma de la API es una petición 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 elimina todos los demás modelos cargados y termina cualquier petición que estuviera ejecutándose.

Ejecutar más de un modelo en un 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, el segundo modelo grande puede no tener espacio mucho antes de llegar a tres.

Cuando se solicita un modelo nuevo y no hay memoria suficiente, el planificador descarga uno de los modelos residentes para liberar espacio. Da preferencia a un modelo sin solicitudes activas y puede expulsar un modelo cuyo temporizador aún no ha expirado, incluido uno cargado con -1. Por tanto, un valor negativo de keep_alive significa que no hay tiempo de espera por inactividad. Esto no fija los pesos para impedir que otra solicitud de modelo los desaloje.

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

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 rápidamente y 0 para el que se utiliza 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 solicitud. Cuando vence, el servidor libera los pesos. La siguiente solicitud los carga de nuevo desde el disco y esa carga 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 permanentemente en la memoria?

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 descarga este modelo para liberar espacio.

¿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. Configúrela con sudo systemctl edit ollama.service y después ejecute sudo systemctl daemon-reload y sudo systemctl restart ollama. La otra causa es que un cliente envíe su propio keep_alive en la solicitud, lo que anula el valor predeterminado del servidor.

¿Cómo libero la memoria sin reiniciar Ollama?

ollama stop qwen3:8b descarga ese modelo inmediatamente 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 devuelve "done_reason": "unload". Confírmelo con ollama ps, que ya no debería mostrar el modelo.