Ollama pull vs run: diferencias y ubicación de modelos

ollama pull frente a ollama run

ollama pull descarga un modelo y termina. ollama run descarga el modelo sólo si falta, después lo carga en memoria y abre un chat interactivo. La descarga es idéntica y los archivos se guardan en el mismo lugar. Sólo run continúa después.

Esa única diferencia determina qué comando debe usarse en un script y cuál debe ejecutarse en un terminal.

ollama pull gemma4
ollama run gemma4
ollama run gemma4 "Reply with one word: ready"

La primera línea obtiene el modelo y termina, por lo que es segura en el aprovisionamiento y en una unidad de systemd. La segunda abre una sesión de chat; escriba /bye o pulse Ctrl+D para salir. La tercera envía un prompt único, muestra la respuesta y termina. Este es el formato que necesita un script cuando requiere una respuesta en lugar de una sesión. Los nombres de los modelos cambian con rapidez, así que considere gemma4 un marcador de posición: es el ejemplo que usa la documentación oficial de Ollama en agosto de 2026, y cualquier tag de la biblioteca funciona del mismo modo.

Por qué la primera ejecución de ollama parece bloqueada

Una primera run en un VPS nuevo puede permanecer varios minutos sin mostrar salida. No hay ningún problema. El indicador de chat no puede aparecer hasta que el modelo esté guardado en disco y cargado en memoria. Por eso, run está descargando varios gigabytes antes de mostrar cualquier información.

Hay dos factores que ocultan esa actividad. Ollama muestra la barra de progreso sólo cuando su salida está conectada a una terminal. Por tanto, un run dentro de un script de shell, un trabajo de cron, un paso de CI o un ssh host ollama run ... simple no muestra nada mientras realiza la descarga. Después de escribir los datos en disco, el archivo todavía debe leerse desde el disco y cargarse en la RAM antes de generar el primer token. En un VPS pequeño, esta lectura puede ser lenta. Si el servidor no tiene memoria suficiente para el modelo, el kernel empieza a usar swap y la espera se prolonga mucho más.

Supervíselo desde una segunda sesión en lugar de hacer suposiciones:

df -h /
watch -n5 df -h /

Si el espacio libre disminuye por etapas, la descarga sigue en curso. Si el espacio libre deja de disminuir mientras el comando continúa ocupado, la descarga ha terminado y ha comenzado la carga en memoria.

Por eso conviene descargar el modelo con antelación. La persona que escribe ollama run no debería ser quien espere la descarga.

Descargue el modelo antes de que alguien lo solicite

En un servidor nuevo, incluya la descarga en el mismo script que instala el servidor:

curl -fsSL https://ollama.com/install.sh | sh
ollama pull gemma4

Si es la primera vez que pone en marcha el servidor, la instalación completa de Ollama en un VPS explica el servicio y quién puede acceder a él. Después, conviene configurar una descarga que continúe aunque cierre el terminal, porque una descarga interrumpida a mitad es la causa habitual de que el almacén de modelos quede incompleto.

Ejecútela dentro de tmux o entréguela a systemd como una unidad one-shot que se ejecute durante el arranque. Escriba /etc/systemd/system/ollama-pull.service:

[Unit]
Description=Pre-pull Ollama models
Wants=ollama.service network-online.target
After=ollama.service network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'until ollama list >/dev/null 2>&1; do sleep 2; done'
ExecStart=/bin/sh -c 'ollama pull gemma4'

[Install]
WantedBy=multi-user.target

Ambos comandos pasan deliberadamente por /bin/sh -c. Un ExecStart= sin más necesita una ruta absoluta, y el instalador no siempre coloca el binario en el mismo directorio. Por eso, command -v ollama en su propio servidor es la única respuesta fiable. El uso del shell emplea el PATH del servicio en lugar de una ruta copiada de una guía. El primer ExecStart también es importante: After=ollama.service indica que se inició la unidad del servidor, pero no que ya esté lista. Por eso, el bucle espera hasta que ollama list responda antes de iniciar la descarga.

sudo systemctl daemon-reload
sudo systemctl enable --now ollama-pull.service
journalctl -u ollama-pull.service

El journal debe mostrar que la descarga terminó sin errores, y ollama list debe mostrar entonces el modelo. Para mantener actualizado un tag que cambia, añada un temporizador de systemd o una entrada semanal de cron que ejecute la misma descarga. Volver a descargar un tag que ha cambiado descarga las capas nuevas y deja las antiguas sin ninguna referencia. Esas capas se limpian la próxima vez que se inicia el servidor.

Qué ocurre cuando se interrumpe un pull

Cada capa de un modelo se almacena bajo un hash de su propio contenido. Por tanto, un pull interrumpido no supone trabajo perdido: vuelva a ejecutar el mismo ollama pull y las capas que ya se completaron se reconocerán y se omitirán. La descarga continuará con la capa que quedó interrumpida.

Una acción destruye ese progreso. Cuando se inicia el servidor de Ollama, elimina las capas almacenadas a las que ningún manifiesto de modelo hace referencia. La capa parcial que deja un pull finalizado de forma inesperada es exactamente eso. Por tanto, reiniciar el servicio antes de volver a intentarlo elimina la parte que ya se había descargado. Vuelva a intentar el pull primero y reinicie después. Si una descarga parcial debe conservarse realmente durante un reinicio, establezca OLLAMA_NOPRUNE=1 en el entorno del servicio y elimínelo después. Esa limpieza durante el arranque evita que las capas huérfanas se acumulen en el disco.

Si el pull terminó con no space left on device, libere espacio antes de volver a intentarlo. Si df indica que el disco está lleno y du en el directorio del modelo no explica ese uso, el espacio se está utilizando en otra ubicación. Antes de eliminar nada, conviene leer los motivos por los que df y du no coinciden.

¿Dónde almacena Ollama los modelos en un VPS?

Consulte su propio servidor en lugar de confiar en una ruta de cualquier guía, incluida esta. La ubicación cambia entre una instalación mediante paquete y un contenedor. También cambia si alguien ha definido OLLAMA_MODELS.

systemctl cat ollama.service
getent passwd ollama
sudo find / -xdev -type d -name blobs 2>/dev/null

systemctl cat muestra el archivo de unidad junto con todos los archivos drop-in. Por tanto, allí aparece cualquier línea OLLAMA_MODELS que haya definido usted o que esté incluida en su imagen. Si no existe esa línea, el almacén se encuentra bajo el directorio personal de la cuenta con la que se ejecuta el servicio. getent passwd muestra ese directorio personal en el sexto campo separado por dos puntos. find busca en un sistema de archivos el directorio blobs, que es donde se escriben realmente las capas. Omita -xdev si los modelos pueden estar ya en un punto de montaje independiente.

Ahora mida y revise sus propios valores:

ollama list
df -h /
sudo du -sh /the/directory/you/found
sudo du -h -d1 /the/directory/you/found

El almacén tiene dos partes. manifests contiene un archivo pequeño por cada etiqueta de modelo. Ese archivo enumera las capas a partir de las que se construye la etiqueta. blobs contiene las propias capas. Cada una recibe como nombre el hash de su contenido y casi todo el tamaño se encuentra allí. Como las capas se comparten entre las etiquetas, dos modelos creados con los mismos pesos muestran su propio tamaño en ollama list, aunque ocupan ese espacio una sola vez en el disco. Por eso, los tamaños mostrados pueden sumar más de lo que du indica para el directorio.

Los archivos de modelos llenan el sistema de archivos raíz de un VPS pequeño más rápido que cualquier otro componente que probablemente instale. El factor que más influye en su tamaño es el formato de los pesos. Elegir entre q4, q8 y fp16 puede ahorrar varios gigabytes por modelo.

Mover los modelos a un volumen de datos con OLLAMA_MODELS

Si el plan incluye un segundo disco o un volumen de datos más grande, mueva el almacén antes de que se llene el sistema de archivos raíz. Detenga primero el servidor para no copiar un archivo que todavía se está escribiendo.

sudo systemctl stop ollama
sudo mkdir -p /mnt/data/ollama-models
sudo rsync -a /the/directory/you/found/ /mnt/data/ollama-models/
sudo chown -R ollama:ollama /mnt/data/ollama-models
sudo systemctl edit ollama.service

systemctl edit abre un editor sobre un archivo drop-in, por lo que la unidad proporcionada por el paquete permanece intacta y una actualización del paquete no puede sobrescribir el cambio. Añada estas dos líneas:

[Service]
Environment="OLLAMA_MODELS=/mnt/data/ollama-models"

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

systemctl show debe mostrar la nueva ruta y ollama list debe mostrar los mismos modelos que mostraba antes del traslado. Una lista vacía significa que el servidor no puede leer el directorio nuevo. El servicio se ejecuta con el usuario ollama, por lo que ese usuario necesita permisos de lectura y escritura en el destino. La línea chown anterior se encarga de ello. Compruebe journalctl -e -u ollama para buscar errores de permisos relacionados con la nueva ruta. Elimine la copia anterior sólo después de confirmar que la lista es correcta, porque un traslado fallido seguido de la eliminación del origen obliga a descargarlo todo de nuevo.

La otra opción conserva la ruta original y monta el volumen de datos sobre ella:

echo '/mnt/data/ollama-models /the/directory/you/found none bind 0 0' | sudo tee -a /etc/fstab
sudo mount -a
findmnt /the/directory/you/found
df -h /

Si findmnt muestra el montaje, el bind mount está activo. Un bind mount resulta útil cuando otro componente del servidor ya espera la ubicación predeterminada. Tiene una particularidad: los archivos que copió siguen bajo el punto de montaje en el disco raíz, ocultos por el montaje, por lo que el espacio no se libera hasta desmontarlos y eliminarlos. La variable de entorno es la opción más sencilla de explicar a la siguiente persona que inicie sesión.

Dónde los guarda realmente el contenedor

La imagen oficial almacena los modelos en la ubicación que monte, no en ningún directorio del host perteneciente a un usuario ollama. El comando documentado para ejecutarla es:

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

ollama antes de los dos puntos es un volumen con nombre de Docker, y /root/.ollama es la ubicación donde escribe el servidor dentro del contenedor. Por eso du no encuentra nada en las rutas de la sección anterior: allí no hay ningún archivo. Muestre la ubicación y el tamaño reales:

docker volume inspect ollama
docker system df -v
docker exec -it ollama ollama list

Lea el campo Mountpoint de docker volume inspect y ejecute después sudo du -sh sobre esa ubicación. Para almacenar los modelos en un volumen de datos, sustituya el volumen con nombre por un directorio del host (-v /mnt/data/ollama:/root/.ollama) y vuelva a crear el contenedor. El contenedor escribe como root, por lo que ese directorio del host queda propiedad de root. En Podman sin root, los identificadores se asignan al rango de subuid de su usuario, por lo que la propiedad en el host vuelve a ser diferente: ejecutar Ollama con Podman sin root explica esa asignación.

Hay una advertencia sobre la limpieza. docker volume prune elimina todos los volúmenes a los que ningún contenedor hace referencia. Si elimina o vuelve a crear el contenedor ollama sin su volumen, una ejecución posterior de prune elimina todos los modelos descargados y no podrá recuperarlos salvo descargándolos de nuevo. Lea cómo limpiar el uso de disco de Docker en un VPS antes de ejecutar prune en un servidor que aloje modelos.

Eliminar un modelo con ollama rm, no con rm

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm elimina el manifiesto de esa etiqueta y, después, las capas a las que ya no hace referencia ningún manifiesto. El espacio se recupera en cuanto se desvinculan esos archivos, por lo que df se actualiza de inmediato. Como las capas se comparten, eliminar una de dos etiquetas estrechamente relacionadas puede liberar mucho menos espacio que el tamaño que ollama list muestra junto a ella. Es el comportamiento esperado, no un fallo de eliminación.

Eliminar archivos manualmente rompe la relación entre ambos elementos. Si elimina un blob con rm, el manifiesto seguirá incluyéndolo, por lo que ollama list continuará mostrando el modelo y cualquier intento de usarlo fallará al leer la capa que falta. Si elimina manualmente un manifiesto, sus capas permanecerán en el disco sin ninguna referencia, ocuparán espacio y ningún comando de Ollama se lo mostrará. Si ya lo hizo, ollama rm sobre la etiqueta elimina la entrada sobrante, y al reiniciar el servidor se eliminan las capas que ya no tienen referencias.

Hay una última diferencia, porque suelen confundirse. ollama rm se ocupa del disco. ollama stop gemma4 descarga un modelo de la memoria y no libera espacio en disco. El tiempo que un modelo permanece residente en la RAM una vez completada la descarga es una configuración independiente, que se explica en mantener un modelo cargado en lugar de volver a cargarlo en cada petición.

FAQ

¿Cuál es la diferencia entre ollama pull y ollama run?

ollama pull descarga un modelo al disco y termina. ollama run comprueba si el modelo ya está en el disco, lo descarga si no está, lo carga en la memoria y abre una sesión de chat interactiva. Ambos escriben los mismos archivos en el mismo directorio. Use pull durante el aprovisionamiento y en scripts, y use run cuando haya una persona delante del teclado. ollama run <model> "your prompt" envía un prompt y termina, por lo que es la forma programable de run.

¿Por qué mi primer ollama run parece bloquearse?

Está descargando el modelo. El prompt del chat no puede aparecer hasta que el modelo esté en el disco y se haya cargado en la memoria, y un modelo ocupa varios gigabytes. Ollama muestra la barra de progreso sólo cuando la salida es una terminal, por lo que un run dentro de un script, un trabajo de cron o un ssh host ollama run ... no muestra nada mientras trabaja. Abra una segunda sesión y ejecute watch -n5 df -h /: si el espacio libre disminuye por pasos, la descarga está en curso. Descargue el modelo por adelantado y eliminará la espera.

¿Dónde almacena Ollama sus modelos?

La ubicación depende de la instalación, por lo que debe mostrarla en lugar de asumirla. Ejecute systemctl cat ollama.service para comprobar si OLLAMA_MODELS está definido en la unidad o en un drop-in. Si no lo está, el almacén se encuentra en el directorio personal de la cuenta con la que se ejecuta el servicio; getent passwd ollama muestra cuál es. sudo find / -xdev -type d -name blobs 2>/dev/null localiza directamente el directorio de capas. En la imagen del contenedor, el almacén está dentro del volumen montado, y docker volume inspect ollama muestra su Mountpoint del host.

¿Cómo traslado los modelos de Ollama a otro disco?

Detenga el servicio, copie el almacén a la nueva ubicación con rsync -a, asigne el directorio a la cuenta del servicio con sudo chown -R ollama:ollama <directory>, ejecute sudo systemctl edit ollama.service y añada Environment="OLLAMA_MODELS=<directory>" bajo una línea [Service]. Recargue con sudo systemctl daemon-reload y reinicie. Confirme el resultado con systemctl show ollama --property=Environment y ollama list. Una lista vacía casi siempre significa que el usuario ollama no puede leer el nuevo directorio; journalctl -e -u ollama mostrará la ruta.

¿Eliminar los archivos del modelo libera espacio?

Eliminar archivos manualmente libera los bytes, pero deja el almacén en un estado incoherente. Si elimina un blob, el manifiesto sigue mostrando ese modelo, por lo que continúa apareciendo en ollama list y falla al utilizarlo. Si elimina un manifiesto, sus capas permanecen en el disco sin ninguna referencia. Use ollama rm <model>, que elimina el manifiesto y después las capas que ningún otro modelo necesita. Si ya se eliminaron archivos manualmente, ejecute ollama rm sobre la etiqueta para borrar la entrada y reinicie el servidor. El reinicio elimina las capas a las que no hace referencia ningún manifiesto.