Hace unas semanas conté por qué uso la inteligencia artificial en local: sin suscripciones que se acumulan, sin datos que salen de casa. Lo que no había contado es el problema que llega justo después, cuando hay más de un modelo y más de una máquina. Este artículo es el relato de cómo lo resolví, con números medidos y los errores que cometí por el camino.
El punto de partida: dos máquinas, siete modelos
Mi infraestructura doméstica tiene dos protagonistas con caracteres muy distintos:
- Una Raspberry Pi 5 (8 GB), siempre encendida. Consume muy poco y ya ejecuta n8n, las publicaciones en redes sociales y las copias de seguridad. Sin GPU: los modelos que caben son pequeños (1-2 mil millones de parámetros) y lentos, pero siempre están ahí.
- Un PC con una RTX 4060 Ti. Aquí corren los modelos serios, hasta 27 mil millones de parámetros, a velocidad real. Pero para ahorrar energía el PC duerme de las 23 a las 8.
En ambas máquinas corre Ollama, el motor que hace funcionar los modelos de código abierto. En total: dos modelos pequeños en la Pi, cinco en el PC. Más, cuando hace falta, un servicio en la nube de pago para cuando necesito potencia y el PC no está.
El problema no era la potencia. Era el orden: cada programa tenía que saber a qué máquina dirigirse, con qué nombre de modelo, con qué clave. Cambiar un modelo significaba cambiar diez scripts. Y si el PC dormía, el script simplemente fallaba.
La idea: un único portero
La solución tiene un nombre técnico, gateway LLM, pero la idea es sencilla: una sola dirección a la que todos los programas envían sus preguntas. El gateway sabe qué modelos existen, dónde están y si son accesibles, y reparte.
Elegí LiteLLM, un proyecto de código abierto que habla el mismo "dialecto" que la API de OpenAI. La ventaja es enorme: cualquier programa o librería que sepa usar ChatGPT sabe usar también mi gateway, basta con cambiar la dirección. Corre en un contenedor Docker en la Raspberry Pi, y no es casualidad: el portero tiene que estar en la máquina que nunca duerme.
La parte más útil es que los programas ya no piden un modelo por su nombre, sino un nivel:
| Nivel | Quién responde de día | Si el PC duerme | Tiempo medido |
|---|---|---|---|
| rápido | modelo de 1B en la Pi | el mismo (está en la Pi) | 8-11 s |
| medio | modelo de 8B en el PC | modelo de 1,7B en la Pi (gratis) | 10-16 s |
| potente | modelo de 27B en el PC | nube, y la Pi como último recurso | unos 37 s |
| razona | 27B con razonamiento activo | modelo de razonamiento en la nube | minutos, para problemas difíciles |
El día que cambie el modelo "potente" por uno mejor, lo modificaré en un solo archivo de configuración. Ningún script se dará cuenta.
El plan B automático: cuando el PC duerme
Esta era la parte que más me interesaba, y la probé simulando un PC inaccesible. El comportamiento final es este:
- La primera petición prueba el PC, espera el tiempo límite (unos 25 segundos) y luego pasa al plan B.
- El gateway pone el PC "en pausa" durante un minuto: las peticiones siguientes van directamente al plan B, en 1-3 segundos.
- Pasado ese minuto, vuelve a probar el PC. Si se ha despertado, vuelve a usarlo.
Elegí conscientemente qué cuesta dinero y qué no: el nivel "medio" siempre recurre a un modelo de la Pi, así que sigue siendo gratis. Solo "potente" y "razona" recurren a la nube de pago, porque ahí el salto de calidad justifica unos céntimos.
Un chat solo mío, accesible solo para mí
Encima del gateway instalé Open WebUI: una interfaz tipo ChatGPT, desde el navegador o el móvil, con todos los niveles y modelos en el menú desplegable. También corre en la Pi.
Lo que más me importa es desde dónde se puede acceder: solo dentro de mi red privada virtual (uso Tailscale, una VPN que conecta mis dispositivos estén donde estén). No desde la red de casa, no desde internet. El propio gateway sigue cerrado: escucha solo en la máquina local y se expone a la VPN mediante un reenvío dedicado, protegido con clave. Sin la clave responde "no autorizado".
Gateway y chat juntos ocupan unos 1,2 GB de RAM en una Raspberry Pi que tiene 8. La Pi sigue haciendo todo lo demás igual que antes.
Tres trampas que ninguna guía te cuenta
1. Los modelos que "piensan" devolvían respuestas vacías. Algunos modelos recientes, antes de responder, hacen un razonamiento interno. Con un límite de longitud normal, el razonamiento se comía todo el espacio y la respuesta llegaba vacía: el nivel "potente" tardaba 78 segundos en no decir nada. Solución: razonamiento desactivado por defecto y un nivel específico, "razona", para cuando de verdad hace falta. Lo mismo, descubierto después, con el modelo en la nube. Resultado: de 78 segundos en vacío a 37 segundos con respuesta.
2. El plan B existía, pero esperaba cada vez. Con la configuración "prudente" (poner en pausa un modelo solo tras dos errores), cada petición nocturna esperaba el tiempo límite completo antes de recurrir al plan B. Leyendo el código del gateway entendí el motivo: cuando en un grupo hay un solo modelo, las protecciones estándar se desactivan para no dejarte sin nada. La solución fue bajar el umbral a cero errores tolerados: la primera petición lenta, todas las demás inmediatas.
3. Antes de migrar, cuenta. Terminado el gateway, el siguiente paso era pasar a él todos los scripts que usan IA. Antes de tocar nada hice un inventario de las tareas automáticas, tanto en la Pi como en el PC, y la sorpresa fue que ninguna de las activas usaba ya la IA. Algunas se habían apagado, otras usaban la IA solo en una fase manual. Migrar "por completar" habría significado tocar código que no se ejecuta. El gateway está listo y esperando: los próximos scripts nacerán ya conectados.
A quién le sirve de verdad una arquitectura así
No a todos. Si usas un solo modelo en un solo ordenador, Ollama por sí solo es más que suficiente. El gateway empieza a tener sentido cuando:
- tienes varias máquinas (un servidor siempre encendido y un PC potente que no lo está);
- tienes varios programas que usan IA y no quieres que cada uno gestione claves y direcciones por su cuenta;
- quieres decidir una sola vez qué se queda en casa, qué puede ir a la nube y cuánto estás dispuesto a gastar;
- manejas datos que no deben salir del despacho o de la empresa, pero quieres igualmente un plan B cuando la máquina principal está apagada.
Es exactamente el escenario de muchos despachos profesionales: un pequeño servidor siempre encendido, algunos puestos de trabajo, datos sensibles y cero ganas de suscripciones que se multiplican.
Conclusión
Con hardware que ya tenía (una Raspberry Pi y el PC de todos los días) y solo software de código abierto, convertí siete modelos dispersos en un único servicio: una dirección, cuatro niveles, plan B automático de noche y un chat privado accesible solo para mí. El coste adicional es cero, salvo los céntimos de la nube cuando yo lo pido.
La lección más útil, sin embargo, no es técnica: mide antes de construir y cuenta antes de migrar. Dos de las tres trampas las encontré solo porque probé con el cronómetro y con el PC "apagado" de mentira, en lugar de fiarme de la configuración sobre el papel.