Corre modelos de IA locales en tu homelab con Ollama

¿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.

Esta guía utiliza Linux y Docker como arquitectura didáctica para un homelab. En mi equipo principal ejecuto actualmente Ollama de forma nativa en Windows 11; son dos escenarios distintos.

Puedes ver la comparativa y el contexto de mi instalación actual en Ollama vs LM Studio: diferencias y cuándo usar cada uno.

Crea la carpeta:

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

Crea el archivo:

nano docker-compose.yml

Y pega este contenido:

services:
  ollama:
    container_name: ollama
    image: ollama/ollama:latest
    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.

Open WebUI puede conservar una clave generada automáticamente en su directorio de datos persistente, pero este Compose define WEBUI_SECRET_KEY de forma explícita. Sustituye el valor de ejemplo antes del primer arranque por una clave larga, estable y exclusiva para esta instalación. La clave se utiliza para firmar sesiones y proteger información asociada; si la cambias posteriormente, las sesiones existentes dejarán de ser válidas. Puedes generar una con:

openssl rand -hex 32

Copia el resultado en WEBUI_SECRET_KEY, conserva el mismo valor cuando recrees el contenedor y no lo publiques en capturas, repositorios ni documentación.

En esta arquitectura Open WebUI accede a Ollama mediante la red interna de Docker, por lo que no es necesario publicar la API 11434 en el host.

Acceso opcional a la API desde el host o la LAN. Para usarla únicamente desde el propio servidor:

ports:
  - "127.0.0.1:11434:11434"

Para permitir acceso desde una red local concreta:

ports:
  - "IP_LAN_DEL_HOST:11434:11434"

La API local de Ollama no incorpora autenticación. Publica este puerto solo cuando sea necesario, limita las redes que pueden alcanzarlo y no lo redirijas directamente desde el router hacia Internet. Para acceso remoto, utiliza una VPN o un proxy con controles de acceso.

"3000:8080" publica Open WebUI en todas las interfaces del host. Para limitarlo a una dirección LAN concreta, sustituye el mapeo por el bloque siguiente:

ports:
  - "IP_LAN_DEL_HOST:3000:8080"

No redirijas directamente este puerto desde el router. Para acceso remoto, prioriza una VPN o un proxy con HTTPS y autenticación.

Las imágenes ollama/ollama:latest y ghcr.io/open-webui/open-webui:main utilizan tags móviles. Resultan cómodas para un homelab personal con actualizaciones manuales, pero no permiten reproducir una versión exacta. En un entorno crítico convendría fijar una versión o digest y revisar los cambios antes de actualizar.

Open WebUI documenta actualmente :main como su imagen estándar, pero también aclara que es un tag móvil; las versiones numeradas son las apropiadas cuando se necesita reproducibilidad.

Importante: la imagen Docker correcta de Open WebUI es:

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

---

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.

Estos pasos asumen que el driver NVIDIA ya funciona en el host y que nvidia-smi devuelve correctamente la GPU.

Instalación típica en Ubuntu/Debian:

sudo apt-get update
sudo apt-get install -y --no-install-recommends \
ca-certificates \
curl \
gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \
| sudo gpg --dearmor \
-o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -fsSL https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \
| sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \
| sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Comprueba la integración dentro de Docker:

sudo docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi

Esta segunda comprobación es importante: nvidia-smi en el host confirma el driver, mientras que el comando anterior confirma que la GPU también es visible desde un contenedor. Continúa únicamente si ambos funcionan.

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

Comprueba la versión de Docker Compose:

docker compose version

La sintaxis gpus: all requiere Docker Compose 2.30.0 o posterior. Si tu versión no reconoce esta propiedad, utiliza la alternativa con deploy.resources.reservations.devices. Son dos formas alternativas: no las combines.

Dentro del Compose principal, modifica únicamente el servicio ollama utilizando una de las dos alternativas siguientes. Mantén sin cambios el servicio open-webui y las declaraciones de volúmenes situadas al final del archivo.

  ollama:
    container_name: ollama
    image: ollama/ollama:latest
    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
    gpus: all
    restart: unless-stopped

O bien, la alternativa:

  ollama:
    container_name: ollama
    image: ollama/ollama:latest
    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
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities:
                - gpu
    restart: unless-stopped

Estos bloques son fragmentos alternativos del servicio ollama, no archivos Compose independientes. No pegues ambos. Después de aplicar uno de ellos al Compose principal, valida el archivo completo con:

docker compose config

Continúa únicamente si la validación termina sin errores.

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.

En una instalación nativa, Ollama escucha por defecto en 127.0.0.1:11434. Si necesitas que otra máquina acceda a la API, OLLAMA_HOST permite cambiar la dirección de escucha. Hazlo solo cuando sea necesario, limita las redes que pueden alcanzarla y no expongas directamente el puerto 11434 a Internet.

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:

1. Registra el primer usuario, que será administrador.
2. Comprueba que Open WebUI detecta Ollama.
3. Selecciona un modelo en el desplegable.
4. 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:

Servicios externos o cloud	Ejecución de IA local
Dependencia de una API externa	Modelos ejecutándose en tu propio hardware
Envío de logs o documentos a terceros	Análisis local de los datos
Interfaces exclusivamente cloud	Interfaz tipo ChatGPT dentro de tu red
Modelos y actualizaciones decididos por terceros	Elección del modelo y del momento de actualización
Pago por suscripción o consumo	Coste de 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.

---

¿Ya has probado Ollama en tu homelab? ¿Qué modelo usas? Cuéntalo en los comentarios — las configuraciones reales ayudan más que cualquier benchmark.

---

Fuentes de referencia

• Ollama — Docker
• Open WebUI — Conectar con Ollama
• NVIDIA — Installing the NVIDIA Container Toolkit
• Docker Docs — Run Docker Compose services with GPU access
• Ollama — Biblioteca de modelos
• Comisión Europea — General-purpose AI obligations under the AI Act