13 min de lectura 22 de agosto de 2026

Instalar Ollama en Docker: CPU, GPU, volúmenes y comprobaciones de API

Un recorrido práctico para ejecutar Ollama en Docker sin perder los modelos ni confundir la red del host con la red del contenedor.

Equipo editorial de Odysseus AI Wiki
Equipo editorial de Odysseus AI Wiki
Documentación técnica y verificación independiente
Ilustración conceptual de un modelo de Ollama dentro de un contenedor Docker con CPU, GPU, almacenamiento y un host local
Docker añade una frontera alrededor de Ollama; el almacenamiento, el procesamiento y la red deben seguir siendo decisiones visibles.

Respuesta breve: Sí, Ollama puede ejecutarse en Docker. La configuración más estable usa un volumen con nombre para /root/.ollama, publica el puerto solo cuando hace falta y elige una ruta de CPU o GPU compatible con el host. Comprueba el contenedor, /api/tags y una petición pequeña antes de conectar otra aplicación.

En esta guía

La búsqueda instalar Ollama en Docker suele esconder tres decisiones: dónde se guardan los modelos, cómo llega el contenedor al host o a otro servicio y si se usará CPU o una GPU disponible. Empieza por el camino mínimo. Ejecuta la imagen oficial con un volumen con nombre, verifica la API local y añade opciones de GPU o una segunda aplicación solo cuando el contenedor base esté sano.

Qué cambia al ejecutar Ollama en Docker

Ollama como servicio nativo parece sencillo: un comando inicia el runtime, los modelos viven en el equipo y los clientes usan el puerto 11434. Docker envuelve ese servicio en un contenedor con su propio sistema de archivos, procesos, red y ciclo de vida. Esto facilita repetir el despliegue, pero un modelo guardado solo en la capa escribible del contenedor puede desaparecer cuando se elimina el contenedor.

Por eso un comando docker run que funciona no es toda la configuración. Decide si Docker será el único runtime de Ollama, si accederá una aplicación del host u otro contenedor y si las descargas deben sobrevivir a una actualización. Mantén esos límites claros antes de añadir OpenCode, un host MCP, una interfaz web o un cliente remoto.

El ciclo del contenedor no es el almacenamiento de modelos

Puedes reemplazar el contenedor con seguridad cuando /root/.ollama está fuera de la capa escribible. Para ello necesitas un volumen con nombre o un bind mount elegido de forma consciente.

Elegir CPU, NVIDIA GPU o AMD GPU

Usa CPU primero cuando estés comprobando la red, los volúmenes o un host nuevo. Tiene menos piezas y ofrece una línea base limpia para comparar el tiempo de carga y la velocidad de respuesta. Cuando la API funcione, cambia al comando del acelerador documentado para tu host en lugar de copiar flags de Docker de otra combinación.

Los contenedores NVIDIA suelen depender de un controlador funcional y de NVIDIA Container Toolkit. En AMD pueden cambiar la etiqueta de la imagen y el mapeo de dispositivos; la compatibilidad depende del sistema operativo, el runtime y la documentación actual de Ollama. Trata la GPU como una capa de optimización: el endpoint, el volumen y las comprobaciones básicas deben seguir iguales.

Comprobar Docker
docker version
Comprobar una GPU NVIDIA del host
docker run --rm --gpus=all nvidia/cuda:12.0.0-base-ubuntu22.04 nvidia-smi
Ruta Cuándo usarla Comprobación clave
CPU Quieres la base más simple o no tienes un acelerador compatible Comprobar la API y una respuesta pequeña antes de ajustar rendimiento
NVIDIA GPU El controlador del host y NVIDIA Container Toolkit ya funcionan Verificar que Docker ve la GPU antes de descargar un modelo grande
AMD GPU El host y la imagen de Ollama soportan la ruta ROCm necesaria Seguir los requisitos actuales de imagen y dispositivos
Host y contenedor Otro servicio necesita llamar a Ollama por una red Docker Usar el nombre del servicio dentro de la red, no localhost del host

Crear almacenamiento persistente para modelos

Un volumen con nombre es el valor por defecto más fácil para Ollama en Docker: Docker administra el lugar y el contenedor puede reemplazarse sin copiar los modelos a mano. La imagen oficial guarda los datos de Ollama en /root/.ollama, así que monta siempre el volumen allí. No crees otro volumen durante una actualización si quieres conservar la misma biblioteca.

Un bind mount puede ser útil para controlar el uso de disco, guardar los datos en una unidad concreta o hacer copias de seguridad de una carpeta conocida. También añade decisiones de permisos y rutas. Para el primer despliegue, un volumen con nombre suele ser más fácil de explicar y más difícil de romper.

Un volumen no es una copia de seguridad

Un volumen protege los modelos frente al reemplazo del contenedor, pero no crea automáticamente una segunda copia. Haz una copia o define una reconstrucción de forma deliberada si la biblioteca es importante.

Diagrama conceptual de red con clientes del host, un contenedor Docker de Ollama, un volumen persistente y una red externa separada
La aplicación, el límite del contenedor, el volumen persistente y la red de salida son decisiones independientes.
Crear un volumen con nombre
docker volume create ollama-data
Iniciar el contenedor CPU con almacenamiento persistente
docker run -d --name ollama -p 11434:11434 -v ollama-data:/root/.ollama ollama/ollama
Descargar un modelo dentro del contenedor
docker exec -it ollama ollama pull <model-name>

Iniciar el contenedor y verificar la API

Cuando docker run devuelva el ID del contenedor, comprueba el estado antes de descargar un modelo grande. docker ps indica si el proceso sigue activo y docker logs puede mostrar errores de puerto, permisos o runtime. Después consulta /api/tags desde el host. Una respuesta correcta demuestra que el endpoint HTTP es accesible, no que todos los modelos estén cargados ni que cualquier cliente tenga permiso.

Haz una petición con un modelo pequeño como segunda prueba. Así separas un listener HTTP sano de una ruta de modelo funcional. Si la API responde pero la petición del modelo falla, revisa el nombre del modelo, el espacio libre, la memoria y los logs antes de cambiar la red.

  1. Comprobar el proceso

    Confirma que el contenedor está Up y que el puerto publicado es el que querías exponer.

  2. Comprobar el endpoint

    Solicita /api/tags desde la máquina que publica el puerto 11434 y registra el código de estado.

  3. Comprobar un modelo

    Descarga un modelo pequeño y ejecuta una petición inocua antes de conectar un editor o agente.

Comprobar el contenedor
docker ps --filter name=ollama
Leer los logs recientes
docker logs ollama --tail 100
Comprobar la API local
curl http://127.0.0.1:11434/api/tags
Listar modelos dentro del contenedor
docker exec -it ollama ollama list

Conectar aplicaciones sin confundir localhost

La URL correcta depende del lugar donde se ejecuta el cliente. Una aplicación de escritorio en el mismo host puede llamar normalmente a http://127.0.0.1:11434 si Docker publica el puerto. Otro contenedor de la misma red Docker debe usar el nombre del servicio y el puerto, por ejemplo http://ollama:11434. Dentro de un contenedor, 127.0.0.1 apunta a ese contenedor; no significa automáticamente el host Windows, macOS o Linux.

Para un cliente remoto necesitas una dirección protegida y una regla de firewall explícita. No publiques el puerto 11434 en Internet solo para que una aplicación de prueba conecte. Documenta la ruta, la autenticación o red privada y el servicio de modelos exacto que el cliente puede alcanzar.

Lugar del cliente Endpoint habitual Problema frecuente
Escritorio del host http://127.0.0.1:11434 Usar un nombre de servicio Docker desde una aplicación del host
Otro servicio Compose http://ollama:11434 Usar localhost, que apunta al contenedor que llama
Otra máquina Dirección privada y filtrada del host Publicar una API sin autenticación en una interfaz pública
Odysseus o un editor El endpoint de los ajustes del proveedor de esa aplicación Cambiar el endpoint antes de superar la prueba de API

Proteger modelos, contexto y exposición

Docker no hace privado un servicio de Ollama por sí solo. Un puerto publicado puede enlazarse a todas las interfaces según el comando y los valores del host. Para una prueba solo local, prefiere una asociación de loopback como -p 127.0.0.1:11434:11434. Si un servicio Compose necesita la API internamente, usa una red privada y no publiques un puerto del host sin motivo.

La longitud de contexto, la concurrencia y la memoria de GPU cambian el uso de RAM o VRAM. Aumenta una variable cada vez y observa docker stats, la memoria del host y el comportamiento de las respuestas. No guardes secretos en imágenes, historial de comandos, capturas ni archivos Compose versionados; un endpoint local y una herramienta de búsqueda externa tienen límites de privacidad diferentes.

Comprobación Por qué importa Valor más seguro
Asociación del puerto Controla qué interfaces pueden llegar a la API Usar loopback para pruebas del host
Ruta del volumen Determina si los modelos sobreviven al reemplazo Usar un volumen con nombre documentado
Contexto y concurrencia Pueden multiplicar el uso de memoria por petición Empezar bajo y medir antes de aumentar
Herramientas externas Pueden enviar prompts o contenido fuera del host Revisar el proveedor y limitar permisos

Resolver fallos de salud, GPU, volumen y API

Cuando falla un despliegue de Ollama en Docker, cambia una capa cada vez. Comprueba primero Docker, después que el contenedor de Ollama siga activo, luego el volumen, la API, el modelo y por último la aplicación cliente. Sustituir todo el comando después de cada error oculta el límite que realmente falló.

Los fallos de GPU suelen estar en el runtime del host y no en la API de Ollama. Un contenedor puede responder a /api/tags y seguir usando CPU porque no se pasó la GPU, el controlador no es compatible o la imagen no corresponde al host. Si falta un modelo después de recrear el contenedor, compara docker inspect y el destino /root/.ollama antes de volver a descargarlo.

Eliminar el contenedor no elimina el volumen

El último comando solo quita el contenedor. No ejecutes docker volume rm ollama-data hasta confirmar que los modelos ya no son necesarios o que tienen una copia.

Ilustración conceptual de diagnóstico para Ollama Docker con rutas CPU y GPU, volumen persistente, señal de salud y protección de red
Diagnostica en este orden: runtime, procesamiento, almacenamiento, endpoint y exposición.
Inspeccionar mounts y puertos
docker inspect ollama
Observar recursos del contenedor
docker stats ollama
Detener y eliminar solo el contenedor
docker stop ollama && docker rm ollama
Síntoma Límite probable Siguiente comprobación
El contenedor termina al instante Imagen, comando, permisos o runtime Leer docker logs ollama y el código de salida
Conexión a la API rechazada Asociación del puerto o salud del proceso Comprobar docker ps, puertos y /api/tags
Desapareció el modelo Volumen incorrecto o ausente Comparar los mounts de docker inspect y /root/.ollama
Falla el flag de GPU Controlador del host o runtime del contenedor Ejecutar la prueba GPU más pequeña del proveedor
Funciona desde el host pero no desde el contenedor Namespace de red Cambiar localhost por el nombre del servicio Compose
Las peticiones usan demasiada memoria Contexto, concurrencia o tamaño del modelo Bajar una opción y observar las métricas

Preguntas frecuentes sobre Ollama en Docker

Sí. La ruta oficial inicia el servicio en un contenedor. Los puntos prácticos son la imagen, el volumen /root/.ollama, el runtime de CPU o acelerador y el endpoint del cliente.

Crea un volumen con nombre, inicia la imagen oficial con el puerto 11434 y monta el volumen en /root/.ollama. Verifica docker ps y /api/tags antes de descargar un modelo. Para GPU, usa la documentación oficial actual.

Puedes diseñar un almacenamiento compartido, pero no conviene que dos runtimes escriban sin coordinación en el mismo directorio. Un único propietario, una copia de seguridad y una migración documentada reducen problemas de bloqueo y permisos.

Usa CPU como base para probar la instalación. NVIDIA o AMD tienen sentido cuando controlador, runtime, imagen y dispositivos son compatibles juntos. La ruta de GPU debería conservar el mismo volumen y las mismas comprobaciones de API.

Los clientes están en namespaces de red distintos. El host puede usar 127.0.0.1:11434 si el puerto está publicado; otro servicio Compose normalmente debe usar http://ollama:11434.

Usa la variable de entorno y la configuración documentadas para la versión de Ollama que ejecutas y recrea el contenedor con el mismo volumen. Aumenta poco a poco y vigila la memoria.

No lo des por hecho. Comprueba la dirección de escucha y el firewall. Para uso solo en el host, enlaza el puerto a loopback; para servicios internos, usa una red Docker privada y evita un puerto público innecesario.

Referencias oficiales

  1. Documentación de Ollama Docker - Imágenes de contenedor y guía oficial de Docker
  2. Documentación de la API de Ollama - Referencia oficial de endpoints y peticiones
  3. GPU con Docker Compose - Reserva de GPU y configuración oficial de Compose

Guías relacionadas de IA local

Última actualización: 22 de agosto de 2026

Volver a la página de inicio