Raspberry Pi 5 y openLight: por qué los agentes de IA habituales saturan el hardware pequeño

La mayoría de los agentes de IA populares se adaptan mal a la Raspberry Pi 5, y no porque el modelo sea demasiado débil, sino porque todo el stack que lo rodea se diseñó desde el principio para servidores. El autor del artículo abordó el problema en la práctica y creó su propio runtime ligero, openLight, que elimina las capas innecesarias y conserva solo lo que realmente hace falta para las tareas habituales.

Por qué todo se vuelve pesado

En un servidor normal, un framework de agentes parece un compromiso cómodo: un runtime de Python, servicios en segundo plano independientes, una capa de orquestación, a veces una base de datos vectorial y un conjunto adicional de dependencias encima. Pero en la Raspberry Pi 5 cada una de estas capas se nota casi físicamente: el sistema tarda más en arrancar, consume más memoria y una acción sencilla exige de pronto una infraestructura comparable a una pequeña plataforma.

El problema se aprecia sobre todo cuando los escenarios son, en realidad, muy simples. El autor no necesitaba un "empleado digital" universal con una larga cadena de razonamiento. Quería resolver tareas básicas de administración: consultar la carga de la CPU, comprobar el espacio libre en disco, leer logs o reiniciar un servicio. Levantar un stack de agentes pesado para eso es gastar recursos no en el resultado, sino en el mantenimiento de la propia herramienta.

Qué propone openLight

En lugar de otro framework generalista, el autor creó openLight, un runtime minimalista para infraestructura personal. La idea clave es sencilla: el agente no debe convertirse en un LLM para todo. Si un comando se puede procesar de forma determinista, debe ejecutarse así. El modelo interviene solo donde realmente resulta incómodo prescindir de él: para clasificar una solicitud, interpretar el texto del usuario o asociar un mensaje con el skill adecuado.

• Un único binario sin capas complejas
• Implementación en Go en lugar de un pesado stack de Python
• SQLite para el almacenamiento en lugar de un servicio de base de datos aparte
• Mínimo de dependencias y arranque rápido
• Validación del skill antes de ejecutar el comando

Este enfoque ahorra no solo recursos, sino también tiempo. En el ejemplo del autor, el camino a través del modelo local de Ollama con qwen2.5:0.5b tardó 42,55 segundos, mientras que el mismo escenario con OpenAI gpt-4o-mini tardó 3,28 segundos. Pero la conclusión principal no es la comparación de modelos: los comandos más frecuentes no deberían pasar cada vez por el circuito completo del LLM si el sistema puede entenderlos de antemano.

Cómo recorre una solicitud el sistema

La ruta del mensaje es lineal y transparente: la solicitud llega desde Telegram, pasa por la autorización y el guardado, y después el sistema busca primero una coincidencia directa con un skill conocido. Si la encuentra, el comando se ejecuta de inmediato. Si no, entra en juego un clasificador LLM, que decide qué hacer a continuación: seguir la conversación o elegir un skill adecuado. Antes de ejecutarse, el skill pasa una comprobación adicional para mantener el control de la ejecución.

La idea era que el agente no se convirtiera en un "LLM para todo".

Telegram se eligió aquí no como parche provisional, sino como una interfaz perfectamente válida. No hace falta un cliente web aparte, las notificaciones llegan al instante, se accede desde el móvil y la autorización ya está integrada en el canal de comunicación. El usuario puede escribir algo como "cómo va el estado del sistema" y el runtime devuelve una respuesta clara con el nombre del host, la carga de la CPU, la memoria ocupada, el espacio libre en disco, el tiempo de actividad y la temperatura. Las propias métricas se recopilan de forma determinista, sin generación innecesaria.

Qué significa

La historia de openLight muestra bien hacia dónde pueden evolucionar realmente los agentes de IA fuera de los centros de datos y las demos. En los dispositivos pequeños no gana el stack más "inteligente", sino el que sabe cuándo no llamar al modelo. Para la Raspberry Pi y la infraestructura doméstica es un cambio importante: un agente útil puede no ser una plataforma gigantesca, sino una pequeña capa ejecutable con reglas claras y un uso puntual del LLM.