Ollama IA local en Docker: modelos privados en tu homelab

¿Por qué ejecutar IA en local?

No es para todo el mundo. Si solo usas ChatGPT de vez en cuando para una consulta rápida, probablemente no necesitas montar nada de esto.

Pero si eres desarrollador, trabajas en tecnología, tienes un homelab, eres CIO o simplemente te importa la privacidad, ejecutar modelos de IA en local empieza a tener mucho sentido.

La idea es sencilla: en lugar de enviar cada prompt a un proveedor externo, ejecutas el modelo en tu propio hardware. En tu red. Con tus datos. Bajo tu control.

Privacidad: tus prompts, logs, documentos y pruebas no salen de tu máquina o de tu red local.
Control: eliges qué modelo usar, cuándo actualizarlo, qué datos cargar y qué integraciones permitir.
Sin coste por uso: no pagas por token ni por llamada. Pagas hardware, electricidad y mantenimiento.
Sin depender siempre de Internet: si el modelo está descargado y tu equipo está encendido, puedes usarlo aunque no tengas conexión externa.
Integración con tu homelab: puedes conectarlo con Open WebUI, agentes, scripts, n8n, alertas, logs, Home Assistant o herramientas internas.
Aprendizaje real: entiendes de verdad qué implica ejecutar IA: VRAM, cuantización, contexto, latencia, consumo, RAG y límites reales.

Ahora bien, tampoco quiero vender humo. La IA local tiene límites.

No vas a montar en casa algo equivalente a los modelos frontera de OpenAI, Anthropic o Google. No vas a tener la misma calidad general, ni la misma velocidad, ni la misma capacidad multimodal avanzada, salvo en casos muy concretos. Pero para muchísimos usos técnicos, personales y de homelab, un buen modelo local es más que suficiente.

Y sobre todo: te da una independencia que no tienes cuando todo pasa por una API externa.

Qué puedes esperar de la IA local

La IA local brilla especialmente en tareas donde la privacidad, la integración y el control importan más que tener “el modelo más inteligente del mundo”.

Ejemplos donde tiene mucho sentido:

Analizar logs de tu homelab sin subirlos a terceros.
Resumir alertas de Uptime Kuma, Pi-hole, AdGuard Home o firewall.
Ayudarte con scripts, Docker Compose, YAML, Bash o Python.
Revisar configuraciones de servidores antes de aplicarlas.
Hacer borradores de artículos técnicos.
Clasificar correos, notas o textos internos.
Montar asistentes conectados a documentación propia.
Probar modelos nuevos sin depender de cuotas ni suscripciones.

Donde hay que ser más prudente:

Análisis críticos de seguridad sin revisión humana.
Decisiones legales, médicas o financieras.
Razonamiento complejo con modelos pequeños.
Documentos enormes sin un buen sistema RAG.
Prometer que un modelo local “sabe más” que uno cloud de última generación.

Mi forma de verlo es esta: la IA local no sustituye siempre a ChatGPT, pero sí te da una herramienta privada, flexible y tremendamente útil para tu propio entorno.

Qué necesitas

Hardware mínimo: CPU only

Para probar, no necesitas una bestia. Puedes empezar con CPU:

CPU moderna de 4 núcleos o más.
8 GB de RAM como mínimo.
10-20 GB de disco libre para modelos pequeños.
Linux, Windows o macOS.

Con esto puedes ejecutar modelos pequeños de 1B, 3B o incluso 7B/8B cuantizados. Funcionarán, pero no esperes milagros. En CPU, un modelo puede ser útil para pruebas, pero la velocidad dependerá muchísimo del procesador, la RAM, el tamaño de contexto y la cuantización.

Para empezar, modelos como llama3.2:3b, qwen2.5:3b o variantes pequeñas de Phi o Gemma son razonables.

Hardware recomendado: con GPU

Si quieres que la experiencia sea cómoda, una GPU dedicada marca la diferencia.

NVIDIA RTX 3060 de 12 GB como punto de entrada muy interesante.
RTX 4070/4070 Ti/4080 si buscas más velocidad y eficiencia.
RTX 3090/3090 Ti/4090 con 24 GB de VRAM si quieres jugar en serio con modelos grandes.
32 GB de RAM como mínimo razonable para un homelab de IA.
64 GB de RAM si vas a probar modelos grandes, RAG o varios servicios a la vez.
SSD con espacio: los modelos ocupan bastante más de lo que parece cuando empiezas a probar varios.

En Docker con NVIDIA necesitas tener correctamente instalado y configurado nvidia-container-toolkit. No basta con tener drivers en el host: Docker tiene que poder ver la GPU.

Mi caso concreto es un equipo con un mini pc y una NVIDIA por eGPU. Con 24 GB de VRAM puedes ejecutar modelos muy serios, pero hay que ser honesto: 70B es posible en determinados escenarios y cuantizaciones, pero no siempre es cómodo ni rápido. Para uso fluido, los modelos de 7B, 8B, 14B y 30B/32B suelen ser mucho más razonables.

Paso 1: Instala Ollama en Docker

Ollama se puede instalar nativo en Windows, macOS o Linux. De hecho, si usas Windows como equipo principal, instalarlo con el .exe oficial es muy cómodo.

Pero para un homelab, Docker tiene mucho sentido: volumen persistente, despliegue reproducible, fácil actualización y mejor integración con otros servicios como Open WebUI.

Crea la carpeta:

mkdir -p ~/docker/ollama
cd ~/docker/ollama

Ese valor no debe quedarse así. Usa una clave larga y única, y no la pegues en capturas, repositorios ni documentación pública.

Crea el archivo:

nano docker-compose.yml

Y pega este contenido:

services:
  ollama:
    container_name: ollama
    image: ollama/ollama:latest
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    environment:
      # Mantiene los modelos cargados un tiempo después de usarlos.
      # Ajusta según tu RAM/VRAM.
      - OLLAMA_KEEP_ALIVE=10m

      # Número máximo de modelos cargados simultáneamente,
      # siempre que quepan en memoria.
      - OLLAMA_MAX_LOADED_MODELS=1

      # Peticiones paralelas por modelo.
      # Más paralelo = más memoria necesaria.
      - OLLAMA_NUM_PARALLEL=1
    restart: unless-stopped

  open-webui:
    container_name: open-webui
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "3000:8080"
    volumes:
      - openwebui_data:/app/backend/data
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_SECRET_KEY=cambia-esto-por-una-clave-larga
    depends_on:
      - ollama
    restart: unless-stopped

volumes:
  ollama_data:
  openwebui_data:

Este Compose levanta dos servicios:

Ollama: el servidor que ejecuta los modelos.
Open WebUI: una interfaz web tipo ChatGPT para usar esos modelos desde el navegador.

El puerto 11434 es la API de Ollama. El puerto 3000 será la interfaz de Open WebUI.

Importante: la imagen Docker correcta de Open WebUI es:

ghcr.io/open-webui/open-webui:main

No mezcles ahí URLs, capturas ni rutas de WordPress. Docker necesita el nombre de la imagen del contenedor, no una URL de una página web.

Paso 1B: activar GPU NVIDIA en Docker

Si tienes NVIDIA y quieres que Ollama use la GPU dentro de Docker, necesitas tener instalado y configurado nvidia-container-toolkit.

Instalación típica en Ubuntu/Debian:

sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Después puedes añadir soporte GPU en el servicio de Ollama.

Opción sencilla con Compose moderno:

services:
  ollama:
    container_name: ollama
    image: ollama/ollama:latest
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    gpus: all
    restart: unless-stopped

Si tu versión de Docker Compose no soporta gpus: all, puedes usar la forma con reserva de dispositivos:

services:
  ollama:
    container_name: ollama
    image: ollama/ollama:latest
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities:
                - gpu
    restart: unless-stopped

En algunas versiones de Docker Compose también verás ejemplos con gpus: all. En otras, se usa la reserva de dispositivos con deploy.resources.reservations.devices. Lo importante es no mezclar configuraciones sin saber qué soporta tu versión de Docker Compose.

Mi consejo: no empieces complicándote. Primero levanta Ollama en CPU y comprueba que funciona. Luego activa GPU y valida que realmente la está usando.

Para comprobarlo:

docker exec -it ollama ollama ps
nvidia-smi

En ollama ps podrás ver si el modelo está cargado en CPU, GPU o repartido entre CPU/GPU. En nvidia-smi deberías ver consumo de VRAM cuando el modelo esté cargado.

¿Y si uso Windows o WSL2?

Si usas Windows 11, tienes dos caminos:

Ollama nativo en Windows: lo instalas con el .exe y te olvidas de Docker para Ollama.
Ollama en Docker dentro de WSL2: necesitas Docker Desktop/WSL2 correctamente configurado y soporte NVIDIA funcionando en WSL2.

Para un artículo de homelab con Docker, esta guía usa Linux/Docker como base. Pero si tu equipo principal es Windows, no pasa nada: Ollama nativo en Windows funciona muy bien y Open WebUI puede conectarse a http://host.docker.internal:11434 si corre en Docker.

Paso 2: Arranca el stack

Levanta los contenedores:

docker compose up -d

Comprueba que están corriendo:

docker ps

Descarga y prueba un modelo pequeño:

docker exec -it ollama ollama pull llama3.2:3b
docker exec -it ollama ollama run llama3.2:3b "Explica qué es Docker en una frase"

Si responde, Ollama ya está funcionando.

Ahora abre Open WebUI:

http://IP-DE-TU-SERVIDOR:3000

La primera cuenta que registres será la cuenta administradora. Guárdala bien.

Desde Open WebUI puedes seleccionar modelos, chatear, gestionar usuarios, subir documentos, configurar conexiones y trabajar con una experiencia bastante parecida a ChatGPT, pero usando tus modelos locales.

Paso 3: Elige tus modelos

Elegir modelo es donde todos nos emocionamos demasiado al principio.

Ves modelos de 70B, 120B o incluso más, y piensas: “lo quiero”. Luego llega la realidad: VRAM, RAM, cuantización, contexto y tokens por segundo.

Mi consejo: empieza pequeño, entiende cómo responde cada modelo y sube poco a poco.

Modelos rápidos para empezar

llama3.2:3b: 3B
qwen2.5:7b: 7B
gemma3:4b: 4B
deepseek-r1:8b: 8B

Modelos para trabajo serio

phi4:14b: análisis técnico, código y razonamiento general. Uno de mis puntos dulces para uso local.
qwen2.5:14b: texto, código y tareas generales. Muy equilibrado si tienes GPU suficiente.
deepseek-r1:14b: razonamiento y análisis paso a paso. Más lento, pero útil cuando quieres que piense más.
deepseek-r1:32b: razonamiento más avanzado. Buen candidato si tienes 24 GB de VRAM y aceptas más latencia.

Modelos grandes

llama3.1:70b: análisis complejo, redacción y razonamiento. Necesita mucha memoria. Con 24 GB de VRAM puede requerir cuantización agresiva y/o offload a RAM.
deepseek-r1:70b: razonamiento complejo. Potente, pero no lo vendería como “cómodo” en cualquier 3090/4090.
mixtral:8x7b: texto y razonamiento general. Interesante, pero no siempre es la mejor opción frente a modelos más recientes de 14B/32B.

Los nombres y etiquetas de modelos cambian con el tiempo. Antes de descargar uno, revisa la biblioteca de Ollama y confirma que el tag sigue existiendo.

Mi recomendación práctica:

Para probar: llama3.2:3b.
Para uso diario técnico: phi4:14b o qwen2.5:14b.
Para razonamiento local: deepseek-r1:14b o deepseek-r1:32b.
Para experimentar con modelos grandes: deepseek-r1:70b o llama3.1:70b, pero sabiendo que no siempre será rápido.

Comandos básicos:

docker exec -it ollama ollama pull llama3.2:3b
docker exec -it ollama ollama pull phi4:14b
docker exec -it ollama ollama pull deepseek-r1:14b
docker exec -it ollama ollama pull deepseek-r1:32b

Y para listar modelos descargados:

docker exec -it ollama ollama list

Paso 4: Usa los modelos desde Open WebUI

Cuando abras:

http://IP-DE-TU-SERVIDOR:3000

por primera vez:

Registra el primer usuario, que será administrador.
Comprueba que Open WebUI detecta Ollama.
Selecciona un modelo en el desplegable.
Empieza a probar.

Open WebUI añade una capa muy cómoda encima de Ollama:

Historial de conversaciones: mucho más cómodo que usar solo terminal.
Multiusuario: cada usuario puede tener su propio historial.
Gestión de modelos: puedes descargar modelos desde la interfaz si la conexión con Ollama está bien configurada.
Subida de documentos: útil para trabajar con PDFs, notas o documentación.
RAG: permite buscar en documentos antes de responder, aunque necesita ajuste para funcionar bien.
Conexiones múltiples: puedes conectar varios backends si tienes más de una instancia.
Interfaz cómoda: temas, chats, ajustes, usuarios y una experiencia mucho más cercana a ChatGPT.

Para mí, Ollama sin Open WebUI es muy útil como backend. Pero Ollama con Open WebUI se convierte en algo que realmente puedes usar a diario.

¿Qué modelo uso yo según el día?

En mi homelab, con un equipo potente y una RTX 3090 Ti por eGPU, no uso siempre el modelo más grande. De hecho, casi nunca tiene sentido hacerlo.

Uso el modelo según la tarea:

Consultas rápidas y dudas técnicas: usaría phi4:14b o qwen2.5:14b, porque dan buen equilibrio entre velocidad y calidad.
Clasificación de texto corto: usaría llama3.2:3b o un modelo 7B. No necesitas un 70B para clasificar correos o resumir alertas simples.
Análisis de logs: probaría phi4:14b, qwen2.5:14b o deepseek-r1:14b. Son suficientemente buenos para detectar patrones si el prompt está bien planteado.
Razonamiento más complejo: usaría deepseek-r1:32b. Más lento, pero más interesante cuando quiero análisis más profundo.
Pruebas con modelos grandes: probaría deepseek-r1:70b como experimento o para tareas puntuales, no como modelo diario.
Escritura de artículos: usaría phi4:14b, qwen2.5:14b o un modelo grande si compensa. Para escribir, muchas veces importa más el prompt y el contexto que el tamaño bruto.

Con una RTX 3090 Ti de 24 GB puedes hacer cosas muy serias en IA local. Pero no diría alegremente que “mueve 70B cómodamente” en todos los casos. Un 70B cuantizado puede cargar y responder, sí, pero la experiencia depende de la cuantización, del contexto, del offload a CPU/RAM, del ancho de banda de la eGPU y de lo que entiendas por cómodo.

Mi punto dulce real para uso diario está más en 14B y 32B que en 70B.

Casos de uso reales en mi homelab

1. Análisis de logs de seguridad

Cuando veo algo raro en Pi-hole, AdGuard Home, firewall o servicios internos, puedo pasar fragmentos de logs al modelo local y pedirle que me ayude a identificar patrones.

No lo uso como veredicto final. Lo uso como segunda opinión.

La ventaja es clara: no tengo que subir logs internos a un servicio externo. Para un homelab puede parecer exagerado, pero si trabajas en TI sabes que los logs cuentan demasiadas cosas: IPs, nombres de host, rutas, dominios, errores, tokens mal gestionados y patrones de uso.

2. Resumen de alertas

Uptime Kuma, Home Assistant, Pi-hole, AdGuard Home o cualquier sistema de monitorización puede generar mucho ruido.

Un modelo local puede ayudar a resumir alertas, agrupar eventos repetidos y separar lo urgente de lo informativo. Esto no sustituye una buena monitorización, pero ayuda a reducir fatiga.

3. Helper de hardening

Cuando configuro un servidor nuevo, puedo pasarle al modelo partes de la configuración y pedirle que revise errores evidentes: puertos expuestos, permisos demasiado abiertos, cabeceras, configuración de Docker, variables sensibles o servicios innecesarios.

De nuevo: no lo aplico a ciegas. Lo uso como copiloto técnico.

4. Escritura asistida de artículos

También uso modelos locales para revisar borradores, mejorar estructura, detectar repeticiones y mantener el tono.

Para escribir artículos técnicos, la IA local va muy bien si ya sabes de lo que hablas. Si no sabes, puede sonar convincente y equivocarse igual. Por eso siempre contrasto lo técnico con documentación oficial antes de publicar.

5. Asistente para documentación interna

Con Open WebUI y RAG puedes cargar documentación propia y hacer preguntas sobre ella. Esto es muy interesante para:

Notas de configuración.
Procedimientos de backup.
Inventario de servicios.
Documentación de Home Assistant.
Runbooks del homelab.
Artículos propios.

Pero hay que entender una cosa: RAG no es magia. Si los documentos están mal troceados, si los metadatos son pobres o si preguntas de forma ambigua, la respuesta puede ser mala.

Limitaciones reales

Para ser honesto, la IA local no es perfecta.

Los modelos pequeños se equivocan: un 3B o 7B puede ser rápido, pero no le pediría análisis crítico sin revisión.
Los modelos grandes consumen mucho: VRAM, RAM, disco y electricidad. No todo merece levantar un 70B.
La latencia no es cero: es local y puede ser baja, pero depende del modelo, hardware, contexto y si está cargado o no.
El contexto cuesta memoria: subir de 4K a 32K o 128K no sale gratis.
La concurrencia aumenta consumo: variables como OLLAMA_NUM_PARALLEL pueden multiplicar memoria necesaria.
RAG requiere ajuste: chunking, embeddings, fuentes, limpieza de documentos y buenos prompts.
No todo modelo “open” es igual: revisa licencias. Muchos son open-weight, no necesariamente open source en sentido estricto.
La electricidad importa: una GPU potente cargando modelos todo el día no es gratis.

Sobre consumo, no daría una cifra fija tipo “200-400 W siempre”. Una RTX 3090 Ti puede consumir mucho bajo carga, pero en reposo no es lo mismo que generando tokens con un modelo grande. Lo correcto es medir tu caso con un enchufe inteligente o monitor energético.

En mi experiencia, la clave es no dejar modelos enormes cargados por postureo. Carga lo que necesitas, mide consumo y ajusta.

Seguridad y privacidad: cuidado con la falsa sensación de control

Ejecutar IA en local mejora mucho la privacidad, pero no significa que todo esté automáticamente seguro.

Recomendaciones básicas:

No expongas Open WebUI directamente a Internet sin autenticación fuerte, HTTPS y protección adicional. Para acceso remoto, mejor usar WireGuard, Tailscale o un proxy inverso bien protegido.
No subas documentos sensibles a una instancia multiusuario sin entender permisos.
Haz backup del volumen de Open WebUI si guardas conversaciones o bases de conocimiento.
Actualiza contenedores con cierta regularidad.
Revisa quién tiene cuenta en Open WebUI.
No pegues secretos, tokens o claves privadas en chats si no tienes claro dónde se almacenan.
No conectes agentes con permisos de escritura sobre tu infraestructura sin controles.

Que algo sea local no lo convierte en seguro por arte de magia. Lo local reduce exposición a terceros, pero sigues teniendo que operar bien.

¿Hace falta meter normativa aquí?

Para un homelab personal, no convertiría este tema en normativa.

No hace falta meter DORA para explicar Ollama, ni convertir una prueba local en un proyecto de cumplimiento. Aquí estamos hablando de aprendizaje, privacidad, control y pruebas dentro de tu propio entorno.

Ahora bien, si esto se lleva a una empresa, cambia la conversación. Ahí ya hay que pensar en qué datos se procesan, quién puede usar la herramienta, qué modelos están permitidos, qué licencias aplican, si se guardan conversaciones, si hay revisión humana y si el sistema solo recomienda o también ejecuta acciones.

El AI Act también conviene tenerlo en el radar si hablamos de usos profesionales de IA, pero sin sobreactuar: no es lo mismo probar Ollama en un homelab que desplegar un sistema de IA para usuarios, clientes o procesos críticos.

En resumen: en casa, sentido común. En empresa, gobierno, seguridad, privacidad, licencias y trazabilidad.

Mantenimiento básico

Actualizar el stack es sencillo:

cd ~/docker/ollama
docker compose pull
docker compose up -d

Ver logs:

docker logs ollama
docker logs open-webui

Ver modelos descargados:

docker exec -it ollama ollama list

Ver modelos cargados en memoria:

docker exec -it ollama ollama ps

Borrar un modelo que ya no usas:

docker exec -it ollama ollama rm nombre-del-modelo

Y un consejo práctico: los modelos ocupan mucho. Lo normal es empezar probando “solo dos o tres” y acabar con decenas de gigas ocupados. Revisa de vez en cuando.

Lo siguiente: automatizar con agentes

Una vez que tienes Ollama funcionando, el siguiente paso natural es conectarlo con agentes o automatizaciones.

Ahí entran herramientas como OpenClaw, n8n, scripts propios, integraciones con Telegram, análisis de logs, respuestas automatizadas o flujos que reaccionan a eventos de tu homelab.

Pero aquí hay que ir con cabeza.

Una cosa es usar un modelo local para resumir una alerta. Otra muy distinta es darle permiso para actuar automáticamente sobre tu infraestructura.

Mi regla sería:

Primero que observe.
Luego que recomiende.
Después que proponga acciones.
Y solo al final, si tienes mucha confianza, que ejecute acciones de bajo riesgo.

La IA local conectada al homelab es potentísima. Pero precisamente por eso conviene no darle las llaves de casa el primer día.

Resumen

Montar Ollama con Open WebUI en tu homelab es una de las formas más prácticas de empezar con IA local.

Lo que consigues:

Dependes siempre de una API externa: Tienes modelos ejecutándose en tu propio hardware
Subes logs o documentos a terceros: Puedes analizarlos en local
Usas solo interfaces cloud: Tienes una interfaz tipo ChatGPT en tu red
No controlas modelos ni actualizaciones: Eliges qué modelo usar y cuándo cambiarlo
Pagas por suscripción o uso: Pagas hardware, electricidad y mantenimiento

Mi recomendación es empezar simple:

Levanta Ollama.
Añade Open WebUI.
Prueba un modelo pequeño.
Sube a 14B cuando todo funcione.
Experimenta con 32B si tienes VRAM.
Deja 70B para pruebas concretas, no como punto de partida.

Para mí, la IA local no va de sustituirlo todo. Va de tener una herramienta propia, privada y conectada a tu entorno. Y eso, en un homelab, encaja como un guante.

Corre modelos de IA locales en tu homelab con Ollama