Muchos han intentado integrar modelos en la nube para analizar y reportar los datos, pero los costos, las preocupaciones por la privacidad y la dependencia externa suelen chocar con la filosofía de autoalojamiento. Así, la mayoría regresa a los paneles básicos: Uptime Kuma para el estado de los servicios, Portainer para el estado de los contenedores y Beszel para el monitoreo de recursos.

El problema real nunca ha sido la visibilidad. Estas herramientas son excelentes en sus categorías y proporcionan una cantidad abrumadora de datos. Lo que suele faltar es la interpretación. No es difícil recolectar datos, pero el desafío está en entenderlos. Los paneles muestran todo; no obstante, ninguno explica qué significa.

¿Por qué un modelo de lenguaje local es la solución?

Gemma 4 es un modelo de lenguaje abierto desarrollado por Google, optimizado para ejecutarse localmente en hardware de consumo. Cuando se decide probar un modelo como este, ejecutándolo en una PC con una tarjeta gráfica como la RTX 4070 Ti, se descubre que es posible redirigir los datos del homelab hacia él. En lugar de crear otro script de monitorización, se pueden formular preguntas directas. Y, en muchos casos, los scripts previos dejan de ser necesarios.

Las herramientas como Uptime Kuma, Beszel y Portainer ofrecen información valiosa: Uptime Kuma indica si los servicios públicos están caídos, Beszel monitorea la salud del servidor y Portainer muestra el estado de los contenedores. Sin embargo, ninguna de estas herramientas explica si los contenedores detenidos son críticos, si el uso elevado de memoria RAM está relacionado con algún problema o qué acciones se deben tomar.

Previamente, se experimentó con modelos de lenguaje en la nube, accediendo al servidor mediante interfaces de programación. No obstante, esta dependencia externa no alineaba con la filosofía de autoalojamiento, donde el control y la privacidad son prioritarios. Al ejecutar un modelo local como Gemma 4 en una PC con una tarjeta gráfica potente, se puede exponer los datos del servidor al modelo sin depender de la nube. Esto permite obtener respuestas a preguntas como: ¿el uso elevado de memoria RAM está conectado con algún contenedor detenido? ¿Cuáles contenedores detenidos son críticos y cuáles se pueden ignorar? ¿Hay algo en el servidor que requiera atención inmediata?

Por primera vez, revisar la salud del homelab se siente como obtener una respuesta en lugar de buscarla. Lo más sorprendente no fue que el modelo pudiera leer los registros, sino que, por primera vez, estos dejaron de ser un dolor de cabeza.

¿Cómo encaja un modelo de lenguaje de gran tamaño en un homelab?

Una pregunta común es cómo un modelo de lenguaje de gran tamaño, como uno de 12 mil millones de parámetros (Gemma 4 12B), puede integrarse en un homelab con hardware limitado. Un modelo de este tamaño requiere una cantidad significativa de memoria de video —aproximadamente 16 GB de VRAM o memoria unificada según Google—, más de la que un servidor reutilizado podría ofrecer. Incluso si el servidor tuviera esa capacidad, alojar un modelo de este tamaño no sería práctico, ya que saturaría el servidor que ya ejecuta múltiples contenedores.

La solución es no tocar el homelab en absoluto. Todo el procesamiento se realiza en una PC con una tarjeta gráfica potente, como una RTX 4070 Ti (12 GB VRAM). Para modelos más grandes, se puede usar una RTX 4080/4090 o el modelo Gemma 4 E4B (4B parámetros), que es más ligero pero aún capaz. Si esta PC está encendida la mayor parte del tiempo, alojar el modelo local en ella es una opción viable.

El proceso es sencillo: Gemma 4 se ejecuta localmente a través de Ollama en la PC. Un pequeño script de proxy conecta el navegador con la interfaz de Portainer y los puntos de acceso de Beszel. Este script de proxy es necesario porque la API de Portainer requiere autenticación y no expone datos directamente al navegador por razones de seguridad. Luego, una simple página HTML permite visualizar todo. Portainer proporciona el estado y los registros de los contenedores, mientras que Beszel ofrece las estadísticas del host. Todo se mantiene en la red local, sin depender de la nube ni de claves de interfaz externas.

Los registros se vuelven útiles

Cada contenedor genera registros, pero la mayoría de estos suelen quedarse sin leer, ya que solo se revisan después de que algo ha fallado. Es un flujo de trabajo humano normal. Cuando se trata de contenedores detenidos, a menudo se revisan cientos de líneas en busca de una pista útil. Por ejemplo, todos los servicios públicos, como Jellyfin, Immich y Vaultwarden, pueden estar funcionando bien. Sin embargo, al pedirle al modelo que revise los registros de Uptime Kuma, podría descubrir que Vaultwarden ocasionalmente falla externamente y que Nextcloud tiene errores intermitentes 503. Ninguno de estos problemas es lo suficientemente crítico como para activar una alerta, lo que explica por qué nunca se habían notado antes.

Lo sorprendente no es que el modelo pueda leer los registros, sino que ahora los registros se vuelven útiles. Dejan de ser algo que se evita hasta que ocurre un desastre.

La automatización como toque final

Todo funciona bien: hay datos, inteligencia y una interfaz de chat. Obtener respuestas es más rápido que abrir múltiples paneles. Sin embargo, aún es necesario recordar abrir el panel, lo que sigue siendo un paso manual. Aunque sea más inteligente, sigue siendo una tarea adicional en el flujo de trabajo diario.

Aquí es donde entra en juego un script sin interfaz gráfica, el programador de tareas de Windows y la herramienta ntfy. ntfy es un servicio de notificaciones open-source que permite enviar alertas a dispositivos móviles o de escritorio mediante una API simple. Para usarlo, es necesario instalar la aplicación en el teléfono (disponible en Android e iOS) y configurar un tema en el servidor.

El script sin interfaz gráfica elimina la necesidad de abrir el panel cada vez. Este script maneja todo en cada ejecución: consulta Portainer, extrae las estadísticas de Beszel, obtiene los registros de los contenedores detenidos, envía la solicitud a Gemma 4 y envía el resultado a través de ntfy. El programador de tareas de Windows ayuda a automatizar todo este proceso sin esfuerzo. Se puede configurar para que se ejecute al iniciar sesión y luego cada dos horas mientras el usuario esté conectado.

Los resúmenes llegan al teléfono automáticamente. Cuando algo requiere atención, se resalta. Ya no es necesario abrir cada panel para ver si algo está mal o necesita atención: el resumen ahora llega directamente. Con el tiempo, se nota que ya no se abre Portainer con tanta frecuencia, y herramientas como Beszel y Uptime Kuma pasan a un segundo plano. Las tres herramientas siguen haciendo su trabajo, pero el modelo de lenguaje local se convierte en el primer lugar al que se recurre.

Los scripts de monitorización que se seguían escribiendo estaban resolviendo un problema de interpretación. Una vez que el modelo de lenguaje puede entender los datos, la mayoría de esos scripts dejan de ser necesarios. Al principio, parecía magia: el modelo no solo entendía los datos, sino que los interpretaba mejor que cualquier script que se hubiera escrito.

Los datos siempre estuvieron ahí. Ahora hablan

Aún se ejecutan Uptime Kuma, Beszel y Portainer. Eso no cambia. Nunca fue el objetivo. Los datos de monitorización nunca fueron el problema. El problema era la cantidad de datos, que superaba la capacidad de procesamiento manual. El modelo de lenguaje local reemplaza el esfuerzo entre ver los datos y entenderlos. Se convierte en una capa de interpretación sobre herramientas que ya hacen bien su trabajo.

Los scripts que se escribían intentaban traducir datos crudos en respuestas, pero el modelo de lenguaje local simplemente hace ese trabajo mejor. Hoy en día, en lugar de escribir otro script, solo se formula la pregunta. Y lo mejor es que ni siquiera es necesario preguntar: la respuesta llega al teléfono.

Guía detallada para implementar un modelo de lenguaje local en un homelab

Contexto inicial

Un homelab es un entorno ideal para experimentar con tecnologías de servidores, redes y contenedores sin el riesgo de afectar sistemas de producción. La monitorización es una parte esencial de cualquier homelab, ya que permite mantener un seguimiento del estado de los servicios, los recursos del servidor y los contenedores en ejecución.

Los modelos de lenguaje locales, como Gemma 4, ofrecen una forma de analizar y entender los datos generados por estas herramientas de monitorización. A diferencia de los modelos en la nube, los modelos locales permiten mantener el control total sobre los datos y la privacidad, alineándose con la filosofía de autoalojamiento.

Requisitos previos

Antes de comenzar, es importante asegurarse de que se cumplen los siguientes requisitos:

• Una PC con una tarjeta gráfica potente, como una RTX 4070 Ti (12 GB VRAM) o superior, para ejecutar el modelo de lenguaje.
• Ollama instalado en la PC para gestionar los modelos de lenguaje.
• Acceso a las interfaces de programación de Portainer y Beszel para obtener los datos de monitorización.
• Conocimientos básicos de línea de comandos y scripting en Python o Node.js.

Preparación del entorno

1. Instalación de Ollama

Ollama es una herramienta que facilita la ejecución de modelos de lenguaje local.

• Linux/macOS: Abre una terminal y ejecuta:

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

• Windows: Descarga el instalador desde ollama.com y sigue el asistente de instalación.

2. Descarga del modelo Gemma 4

Una vez instalado Ollama, descarga el modelo Gemma 4 según el tamaño que tu hardware permita:

# Modelo ligero (4B parámetros) - recomendado para RTX 4070 Ti
ollama pull gemma4:4b

# Modelo mediano (12B parámetros) - requiere ~16 GB VRAM
ollama pull gemma4:12b

# Modelo grande (27B parámetros MoE) - requiere GPU de alta gama
ollama pull gemma4:27b

3. Prueba del modelo

Para probar el modelo, ejecuta:

ollama run gemma4:4b

Escribe una pregunta simple, como: “Explica qué es un contenedor en términos simples”.

Configuración del proxy

1. Creación de un script de proxy para Portainer

Para acceder de forma segura a la API de Portainer, se puede crear un script de proxy en Node.js. Este script actuará como intermediario entre el navegador y la interfaz de Portainer.

Primero, obtén tu Endpoint ID desde Portainer (Settings > Endpoints, usualmente 1 para el local) y genera un Access Token en tu perfil de usuario.

Ejemplo de script en Node.js (proxy.js):

const express = require('express');
const axios = require('axios');
const app = express();

const PORTAINER_URL = 'http://TU_SERVIDOR_PORTAINER:9000';
const PORTAINER_TOKEN = 'TU_ACCESS_TOKEN';
const ENDPOINT_ID = 1; // Ajusta según tu configuración

// Middleware de seguridad básico
app.use((req, res, next) => {
    const clientIp = req.ip || req.connection.remoteAddress;
    // Restringir a red local (ajusta según tu red)
    if (!clientIp.startsWith('192.168.') && !clientIp.startsWith('127.')) {
        return res.status(403).json({ error: "Acceso denegado" });
    }
    next();
});

app.get('/portainer/containers', async (req, res) => {
    try {
        const response = await axios.get(
            `${PORTAINER_URL}/api/endpoints/${ENDPOINT_ID}/docker/containers/json`,
            {
                headers: { 'X-Api-Key': PORTAINER_TOKEN }
            }
        );
        res.json(response.data);
    } catch (error) {
        res.status(500).json({ error: "No se pudo obtener la lista de contenedores" });
    }
});

// Endpoint para logs de un contenedor específico
app.get('/portainer/containers/:id/logs', async (req, res) => {
    try {
        const response = await axios.get(
            `${PORTAINER_URL}/api/endpoints/${ENDPOINT_ID}/docker/containers/${req.params.id}/logs?stdout=true&stderr=true&tail=100`,
            {
                headers: { 'X-Api-Key': PORTAINER_TOKEN }
            }
        );
        res.json(response.data);
    } catch (error) {
        res.status(500).json({ error: "No se pudieron obtener los logs" });
    }
});

app.listen(3000, () => console.log('Proxy seguro en ejecución en el puerto 3000'));

2. Ejecución del script de proxy

Para mantener el script de proxy en ejecución de manera continua, se puede usar pm2:

npm install pm2 -g
pm2 start proxy.js
pm2 save
pm2 startup

Integración con Portainer y Beszel

1. Conexión del modelo de lenguaje a los datos

Una vez que el script de proxy está en ejecución, usa el endpoint de Ollama para enviar los datos de Portainer al modelo de lenguaje. Aquí hay un ejemplo:

curl -X POST http://localhost:11434/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4:4b",
    "prompt": "Analiza estos contenedores Docker y di si hay problemas críticos. Responde en español y sé conciso: [DATOS_DE_PORTAINER]",
    "stream": false
  }'

Para Beszel, consulta su API REST (puerto 8090 por defecto):

curl http://localhost:8090/api/v1/system-stats

Automatización con notificaciones

1. Instalación de ntfy

Se puede ejecutar ntfy en un contenedor Docker con el siguiente comando:

docker run -d \
  --name ntfy \
  --restart unless-stopped \
  -p 8080:80 \
  -v /mnt/ntfy:/var/cache/ntfy \
  binwiederhier/ntfy serve

2. Configuración de un script en Python para enviar notificaciones

Script completo de automatización (homelab_monitor.py):

import requests
import json
import time

# Configuración
NTFY_TOPIC = "mi_homelab"
NTFY_SERVER = "http://localhost:8080"
NTFY_USER = "usuario"      # Opcional
NTFY_PASSWORD = "contraseña"  # Opcional

PROXY_URL = "http://localhost:3000"
OLLAMA_URL = "http://localhost:11434/api/generate"

def obtener_contenedores():
    try:
        response = requests.get(f"{PROXY_URL}/portainer/containers")
        return response.json()
    except Exception as e:
        return {"error": str(e)}

def obtener_stats_beszel():
    try:
        response = requests.get("http://TU_SERVIDOR_BESZEL:8090/api/v1/system-stats")
        return response.json()
    except Exception as e:
        return {"error": str(e)}

def analizar_con_llm(datos):
    prompt = f"""Eres un experto en administración de sistemas. Analiza los siguientes datos de un homelab:
    
    CONTENEDORES DOCKER: {json.dumps(datos['contenedores'], indent=2)}
    ESTADÍSTICAS DEL SISTEMA: {json.dumps(datos['stats'], indent=2)}
    
    Responde en español de forma concisa:
    1. ¿Hay contenedores detenidos que sean críticos?
    2. ¿El uso de recursos es normal?
    3. ¿Qué acciones recomiendas?
    4. ¿Hay algo que requiera atención inmediata?
    """
    
    try:
        response = requests.post(
            OLLAMA_URL,
            json={
                "model": "gemma4:4b",
                "prompt": prompt,
                "stream": False,
                "options": {"temperature": 0.3}
            },
            timeout=120
        )
        return response.json().get("response", "Sin respuesta del modelo")
    except Exception as e:
        return f"Error al consultar el modelo: {e}"

def enviar_notificacion(titulo, mensaje, prioridad="default"):
    try:
        response = requests.post(
            f"{NTFY_SERVER}/{NTFY_TOPIC}",
            data=mensaje.encode('utf-8'),
            auth=(NTFY_USER, NTFY_PASSWORD) if NTFY_USER else None,
            headers={
                "Title": titulo,
                "Priority": prioridad,
                "Tags": "computer" if prioridad == "default" else "warning"
            },
            timeout=10
        )
        print(f"Notificación enviada: {response.status_code}")
    except Exception as e:
        print(f"Error enviando notificación: {e}")

def main():
    print(f"[{time.strftime('%Y-%m-%d %H:%M:%S')}] Iniciando revisión del homelab...")
    
    # Obtener datos
    contenedores = obtener_contenedores()
    stats = obtener_stats_beszel()
    
    datos = {
        "contenedores": contenedores,
        "stats": stats
    }
    
    # Analizar con LLM
    analisis = analizar_con_llm(datos)
    print(f"Análisis: {analisis}")
    
    # Determinar prioridad
    prioridad = "high" if any(palabra in analisis.lower() for palabra in 
                              ["crítico", "inmediata", "urgente", "detenido", "falla"]) else "default"
    
    # Enviar notificación
    enviar_notificacion("📊 Resumen Homelab", analisis, prioridad)
    print("Revisión completada.")

if __name__ == "__main__":
    main()

3. Programación del script

En Windows (Programador de tareas):

1. Abre el Programador de tareas (taskschd.msc)
2. Crea una tarea básica que ejecute: python C:\ruta\homelab_monitor.py
3. Configura:
   • Al iniciar sesión (disparador)
   • Repetir cada 2 horas durante 1 día
   • Ejecutar solo si hay conexión de red

En Linux (cron):

crontab -e

Añadir:

# Ejecutar cada 2 horas
0 */2 * * * /usr/bin/python3 /ruta/al/homelab_monitor.py >> /var/log/homelab.log 2>&1

Casos de uso prácticos

Para principiantes

Monitorear un servidor de juegos

Un caso de uso sencillo es configurar un modelo de lenguaje local para que revise el estado de un servidor de Minecraft. El modelo puede enviar una alerta si el contenedor que ejecuta el servidor se detiene.

Pasos:

1. Configurar un contenedor Docker para el servidor de Minecraft.
2. Usar Portainer para monitorear el estado del contenedor.
3. Configurar el script para consultar el estado del contenedor y enviar una notificación si está detenido.

Para usuarios avanzados

Analizar registros de Nextcloud para detectar patrones de ataques

Utilizar un modelo de lenguaje local para analizar los registros de Nextcloud y detectar patrones sospechosos, como intentos de inicio de sesión fallidos repetidos, que podrían indicar un ataque de fuerza bruta.

Pasos:

1. Configurar Nextcloud en un contenedor Docker.
2. Usar Portainer para acceder a los registros del contenedor.
3. Enviar los registros al modelo de lenguaje local para que los analice (considera chunking para logs largos).
4. Configurar alertas automáticas si se detectan patrones sospechosos.

Problemas comunes y soluciones

Falta de memoria de video en el servidor

Problema: Un modelo de lenguaje de gran tamaño requiere una cantidad significativa de memoria de video, que puede no estar disponible en un servidor reutilizado.

Solución para principiantes: Usar una PC con una tarjeta gráfica dedicada, como una RTX 4070 Ti (12 GB VRAM), y ejecutar el modelo Gemma 4 E4B (4B parámetros).

Solución para avanzados:

• Usar el modelo Gemma 4 12B cuantizado (requiere ~16 GB VRAM/unified memory)
• Configurar la descarga de procesamiento a una GPU externa
• Usar llama.cpp con cuantización Q4_K_M para reducir uso de VRAM

Problemas de acceso con Portainer

Problema: La API de Portainer requiere autenticación y no expone datos directamente.

Solución para principiantes: Usar un script de proxy simple en Python o Node.js con autenticación por token.

Solución para avanzados: Configurar un proxy inverso con Nginx y personalizar los encabezados, o usar la API de Portainer directamente con tokens de acceso de larga duración.

Alto consumo de recursos

Problema: Ejecutar un modelo de lenguaje local puede consumir muchos recursos, especialmente si se está monitoreando un gran número de contenedores.

Solución para principiantes: Limitar el número de contenedores monitorizados y usar el modelo E4B.

Solución para avanzados:

• Implementar rate limiting en las interfaces de programación
• Usar caching de respuestas del modelo
• Optimizar las solicitudes al modelo (prompts más cortos, chunking de logs)
• Programar el análisis en horarios de baja carga

Diagrama de arquitectura

┌─────────────────────────────────────────────────────────────┐
│                      RED LOCAL (LAN)                         │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────────┐│
│  │   Homelab   │    │   Homelab   │    │   PC con GPU      ││
│  │  (Servidor) │    │  (Servidor) │    │  (RTX 4070 Ti)    ││
│  │             │    │             │    │                   ││
│  │  ┌────────┐ │    │  ┌────────┐ │    │  ┌─────────────┐ ││
│  │  │Portainer│ │    │  │ Beszel │ │    │  │   Ollama    │ ││
│  │  │ :9000   │◄┼────┼──┤ :8090  │◄┼────┼──┤ Gemma 4:4b  │ ││
│  │  └────────┘ │    │  └────────┘ │    │  └─────────────┘ ││
│  └──────┬──────┘    └──────┬──────┘    └─────────────────┘│
│         │                  │                                │
│         └──────────────────┘                                │
│                            │                                 │
│                    ┌───────▼────────┐                        │
│                    │  Script Proxy    │                        │
│                    │  (Node.js :3000)│                        │
│                    │  + Auth + HTTPS │                        │
│                    └───────┬────────┘                        │
│                            │                                 │
│                    ┌───────▼────────┐                        │
│                    │ Script Python    │                        │
│                    │ (Automatización) │                        │
│                    └───────┬────────┘                        │
│                            │                                 │
│                    ┌───────▼────────┐                        │
│                    │    ntfy        │                        │
│                    │  (:8080)         │                        │
│                    └───────┬────────┘                        │
└────────────────────────────┼────────────────────────────────┘
                             │
                    ┌────────▼────────┐
                    │   📱 Teléfono    │
                    │  (Android/iOS)   │
                    └─────────────────┘