No es un equipo pensado para "IA generativa", pero si fue una maquina con la que aprendí algo importante: cuando tenes curiosidad técnica, muchas veces el limite no es el hardware perfecto sino empezar con lo que ya tenes.

Con esa base fui probando entornos, virtualizacion, servicios locales y varias ideas que en su momento no tenían nombre de moda, pero que en esencia ya apuntaban a lo mismo: montar laboratorio propio, controlar el entorno y aprender haciendo.

Cuando el upgrade no llega por compra, sino por oportunidad

En un momento apareció una oportunidad inesperada: me regalaron una H310M H 2.0.

No era el tipico upgrade que uno planifica durante meses comparando benchmarks, VRM, lanes PCIe o capacidad de expansión. De hecho, desde afuera podría parecer un movimiento raro: pasar de una placa que en su momento estaba bastante bien posicionada a otra mucho mas simple.

Pero en laboratorios personales no siempre gana "la mejor placa". Muchas veces gana la que te permite seguir construyendo.

Y eso fue exactamente lo que paso.

La H310M H 2.0 junto con un i7 8700 y 32 gb de ram ddr4 me dieron una excusa perfecta para reorganizar lo que tenia, rearmar el stack, separar mejor usos y convertir ese cambio en algo mas interesante que un simple recambio de motherboard: termino siendo la base de mi home lab para Gen AI.

Con el tiempo, esa base también se fue fortaleciendo del lado que mas impacto tenia para este tipo de laboratorio: la GPU. En un momento pude comprar una NVIDIA A2000 de 12 GB, y mas adelante sume una NVIDIA A5000 de 24 GB.

Ese salto fue clave.

Porque una cosa es tener ganas de experimentar con Gen AI en local, y otra muy distinta es empezar a contar con hardware que realmente te deja probar modelos, probar inferencia con mas margen y construir flujos mas ambiciosos sin quedar tan limitado desde el arranque.

Del PC de uso general al home lab

Ese cambio me ayudo a pensar el equipo de otra manera.

Ya no como un simple servidor "para todo", sino como un entorno donde podía levantar herramientas, romper cosas, reconstruir servicios y probar flujos sin depender de cloud desde el minuto cero.

Cuando armas un home lab, incluso con hardware modesto, empezás a mirar distinto:

• que servicios querés dejar persistentes

• que cosas pueden correr en contenedores

• que procesos querés automatizar

• que parte del lab sirve para aprender y que parte sirve para producir valor real

En mi caso, el foco se fue yendo cada vez mas hacia Gen AI en local.

No necesariamente para competir con infra grande, sino para entender mejor el ecosistema, iterar rápido y tener control real sobre el entorno donde corro modelos, herramientas y experimentos.

Jugar con Gen AI en casa, pero con intención

Una de las cosas que mas me interesaba era evitar el típico laboratorio caótico donde todo vive suelto, sin orden y sin una forma clara de conectar piezas.

Por eso empece a jugar con tres componentes que, juntos, me resultaron especialmente interesantes:

• Backstage

• Ollama

• MCPs

• N8N

Cada uno me resolvía una parte distinta del problema.

Backstage como capa de orden

Backstage me resulto útil porque aporta algo que muchos laboratorios caseros no tienen al principio: estructura.

Cuando empezás a sumar servicios, scripts, APIs locales, repositorios, pipelines y experimentos de IA, todo se puede volver desprolijo muy rápido. Backstage ayuda a poner catalogo, documentación, relaciones entre componentes y una vista mas ordenada del ecosistema.

En otras palabras: deja de ser "tengo varias cosas corriendo" para convertirse en "tengo una plataforma personal que entiendo y puedo evolucionar".

Y eso, incluso en un home lab chico, vale mucho.

Ollama para correr modelos en local

Ollama fue otra pieza clave porque me permitió hacer algo muy concreto: correr modelos localmente de forma simple.

Esa parte me interesaba especialmente por varios motivos:

• reducir dependencia de servicios externos para pruebas

• entender mejor limites reales del hardware

• experimentar con prompts, herramientas y automatizaciones de forma mas privada

• tener un entorno repetible para hacer pruebas técnicas

No hace falta tener un datacenter en casa para aprender mucho con esto. A veces alcanza con aceptar las limitaciones del equipo y usarlas a tu favor: modelos mas chicos, pruebas mas enfocadas y expectativas alineadas con el hardware que realmente tenes.

En mi caso, la llegada de la A2000 12 GB primero y de la A5000 24 GB después cambio bastante el panorama. Ya no era solo "ver si algo corría", sino empezar a evaluar que combinaciones de modelos, contexto y herramientas podían ser realmente útiles dentro del lab

n8n para automatizar y orquestar flujos

n8n apareció como una pieza muy natural dentro de ese ecosistema porque me permitió bajar muchas ideas a flujos concretos.

Cuando empezás a combinar modelos locales, APIs, scripts, bases de datos y servicios del laboratorio, enseguida aparece una necesidad bastante práctica: orquestar. No alcanza solo con tener las piezas disponibles; también hace falta conectarlas de una manera que sea mantenible, visible y fácil de iterar.

Ahí n8n me resultó especialmente útil para:

• automatizar tareas repetitivas

• conectar servicios locales con lógica de negocio simple

• probar flujos con LLMs sin tener que codear todo desde cero

• dejar procesos mas ordenados y observables.

MCPs para conectar herramientas con contexto

Otra pata importante fueron los MCPs.

Lo interesante acá no era solo "usar IA", sino empezar a conectar modelos con herramientas, contexto y acciones reales dentro del laboratorio. Esa capa abre una puerta mucho mas potente que el simple chat.

Con MCPs, la conversación deja de ser solo texto y empieza a rozar algo mas útil:

• acceso controlado a información

• integración con servicios locales

• interacción con herramientas del entorno

• flujos mas cercanos a asistentes técnicos reales

Para un home lab, esto es ideal, porque te permite experimentar con arquitectura, integración y seguridad al mismo tiempo.

Lo mas valioso no fue el hardware

Si miro el recorrido completo, la conclusión mas honesta es esta: lo mas valioso no fue pasar de una plataforma a otra, sino la forma en que ese cambio me obligo a repensar el uso del equipo.

La Maximus V Gene con 32 GB de RAM y un i7 fue una etapa importantísima. La H310M H 2.0, aun siendo una placa mas modesta, termino habilitando otra cosa: una transición mental desde "mi vieja PC" hacia "mi laboratorio".

Y a eso se sumo algo todavía mas determinante para el enfoque de IA: pasar por una NVIDIA A2000 de 12 GB y después incorporar una NVIDIA A5000 de 24 GB. Ahí el home lab dejo de ser solo una idea interesante y empezó a convertirse en una plataforma mucho mas capaz para experimentar en serio.

Y cuando esa idea se acomoda, aparecen posibilidades nuevas:

• documentar mejor

• experimentar mas rápido

• iterar arquitectura local

• probar Gen AI sin esperar una infraestructura ideal

Home lab también es criterio

Hay algo que me gusta mucho de estos recorridos técnicos: te obligan a construir criterio.

No todo pasa por comprar la ultima plataforma ni por perseguir una lista infinita de specs. A veces el avance real viene de reutilizar, adaptar, aceptar restricciones y aun así construir algo útil encima.

Eso fue, en buena parte, este proceso.

Arranqué con una Maximus V Gene como base, después apareció una H310M H 2.0 casi de casualidad, y termino en un home lab montado sobre k3s (Kubernetes ultra liviano), donde pude explorar Backstage, Ollama, n8n y MCPs.

En el medio, la incorporación de una A2000 de 12 GB y luego una A5000 de 24 GB le dio al laboratorio una dimensión mucho más concreta para trabajar con modelos locales. En Ollama, por ejemplo, pude correr modelos generales como llama3.1:8b, llama3.2:3b, qwen2.5:7b, mistral:7b-instruct y gemma2:9b; modelos orientados a código como qwen2.5-coder:7b y codellama:7b-instruct; modelos de seguridad como Foundation-Sec ( Cisco Foundation AI ) en varias especializaciones, sec-reasoning-es y DeepHat, antes conocido como WhiteRabbitNeo; y también modelos de embeddings como nomic-embed-text, mxbai-embed-large y bge-m3.

No fue una evolución lineal ni un upgrade de catalogo. Fue algo mejor: un camino realista hacia un laboratorio personal para aprender, probar y jugar en serio con Gen AI.

El Case utilizado para mi Home Lab
https://www.printables.com/model/650130-little-boy-m-matx-pc-case

OpenWebRX es un software de recepción de señales de radio mediante dispositivos SDR que opera desde una interfaz web. Esto permite visualizar y procesar señales en tiempo real desde cualquier lugar, simplemente accediendo desde un navegador web.

Este proyecto Open Source nació en 2015 de mano de András Retzler (HA7ILM). Pero a finales de 2019, el autor abandonó el proyecto y es cuando Jakob Ketterl retomó el desarrollo del proyecto añadiendo nuevas funcionalidades y mejorando el software. El proyecto comenzó a ganar popularidad y cuenta actualmente con un gran número de colaboradores.

En este artículo veremos cómo instalar OpenWebRX en una Raspberry Pi. Existen otras opciones disponibles para instalar este software, como imágenes para tarjetas SD, imágenes para Docker, etc. Podemos consultar todas estas opciones en su página web.

Añadir repositorios de instalación

Para poder instalar OpenWebRX en nuestra Raspberry Pi necesitamos previamente añadir los repositorios para Debian. Para ello ejecutamos los siguientes comandos:

sudo bash -c 'wget -O - https://repo.openwebrx.de/debian/key.gpg.txt | apt-key add'

sudo bash -c 'echo "deb https://repo.openwebrx.de/debian/ buster main" > /etc/apt/sources.list.d/openwebrx.list'

sudo apt update

Instalar OpenWebRx

Ahora ejecutamos el siguiente comando para instalar OpenWebRX:

sudo apt install openwebrx

Durante la instalación nos pedirá una contraseña para acceder a la configuración de OpenWebRx mediante web.

Configuración

Una vez termine la instalación, accedemos desde un navegador web a la dirección IP de la Raspberry Pi y el puerto 8073.

http://[IP_RASPBERRY]:8073/

Se nos mostrará la ventana principal de OpenWebRX. Si solo tenemos un SDR conectado es posible que ya podamos comenzar a usarlo, pero si tenemos varios dispositivos conectados nos mostrará un error como el siguiente y que solventaremos en los siguientes pasos.

Ahora hacemos clic en el botón “Settings” en la esquina superior derecha para acceder a la pantalla de configuración. Nos pedirá un usuario y una contraseña para poder entrar, para los que introduciremos “admin” y la contraseña que pusimos en el paso de instalación.

Una vez accedemos, veremos un menú como el siguiente desde el que accederemos a los distintos ajustes.

El primer ajuste será introducir los datos generales desde “General settings”. Aquí podemos indicar la ubicación de nuestra estación, nuestro indicativo, etc. Una vez introducimos los ajustes, hacemos clic en “Apply and save” para guardarlos.

El siguiente paso es configurar nuestro dispositivo SDR. Para ello accedemos a los ajustes desde el menú principal en “SDR devices and profiles”. Aquí hacemos clic sobre el dispositivo que vayamos a configurar. Si el dispositivo no es ninguno de los mostrados, podemos añadirlo haciendo clic sobre “Add new device”, siempre y cuando esté soportado. Podemos ver los dispositivos soportados en este enlace.

Una vez hemos accedido a la configuración del dispositivo elegido, podemos ir añadiendo los ajustes necesarios seleccionándolos y haciendo clic sobre “Add”, y posteriormente introduciendo los valores para cada uno.

Una vez introducidos los ajustes, nos quedaría configurar las bandas. OpenWebRX no permite moverse libremente por todas las frecuencias de la misma forma que hacen otros programas como SDR#. Para poder movernos en las distintas frecuencias tenemos que crear una serie de perfiles para cada frecuencia introduciendo los datos requeridos para cada una.

Por último, para que OpenWebRW recargue todos los ajustes, reiniciamos el servicio desde la terminal con el siguiente comando: