¿Por qué tengo un homelab en 2026?
Durante la mayor parte de la última década, la industria movió todo a la nube. La infraestructura se volvió APIs. Los servidores pasaron a ser problema de otro. La mayoría dejamos de pensar en hardware. Y con razón. Los servicios gestionados son genuinamente buenos para la mayor parte de las cargas.
Entonces llegó la IA. De repente volvimos a necesitar GPUs. A entender la latencia de inferencia, el footprint de memoria de los modelos y lo que realmente cuesta correr un modelo de 7B parámetros a escala. Las instancias GPU en cloud funcionan, pero a 200€+ al mes por tarjeta la economía de la experimentación cambia rápido. Para muchos ingenieros, eso disparó un regreso silencioso al pensamiento on-premise, no por nostalgia, sino por necesidad.
Así es como mi homelab pasó de ser un hobby a algo de lo que realmente dependo.
El setup
Nada exótico. Un host Proxmox sobre una ASUS PRIME X570-PRO con dos RTX 3060 (12GB cada una), un NVMe de 500GB que siempre se queda corto y un Mac Mini M1 corriendo servicios más ligeros. Todo cuelga de una conexión de fibra residencial en Málaga.
Sobre Proxmox tengo un puñado de VMs:
- Un clúster K3s donde despliego side projects con CI/CD real, cert-manager y secretos gestionados con Vault. Los mismos patrones que uso en producción en el trabajo.
- Una instancia de HashiCorp Vault para automatización de PKI y gestión de secretos. Quería entender Vault a fondo antes de recomendarlo a clientes, así que corro el mío.
- Un bastion host para control de acceso SSH.
- Un runner self-hosted de GitHub para pipelines de CI que necesitan acceso a GPU o a la red privada.
El Mac Mini lleva Jellyfin para streaming de medios y dobla como una workstation sorprendentemente capaz para LLMs. LM Studio corre modelos pequeños sobre la unified memory del M1 sin despeinarse. Lo mantengo como máquina separada del host de Proxmox.
También corro una VPN WireGuard para acceso remoto seguro a todo el lab cuando estoy fuera, y uso Cloudflare Tunnels para exponer servicios concretos cuando port forwarding me da mala espina o no es opción. El router en sí ha pasado por varias rondas de hardening: deshabilitar UPnP, cerrar el DNS, apretar reglas de firewall. Es el tipo de trabajo que no da capturas de pantalla emocionantes pero importa más que la mayor parte de lo que corre detrás.
Self-hosting de LLMs: lo que he aprendido de verdad
Aquí es donde las GPUs se ganan la factura de la luz. He corrido varios modelos en local: Qwen2.5-7B-Instruct para comprensión de lenguaje natural, GLM para tareas generales, bge-m3 para embeddings multilingües y varios modelos más pequeños para experimentación.
Del lado de Proxmox, el stack de serving es vLLM, que maneja bien paged attention e inferencia batched sobre GPUs de consumo. Un setup típico:
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-7B-Instruct \
--tensor-parallel-size 1 \
--gpu-memory-utilization 0.85 \
--max-model-len 4096
Una RTX 3060 de 12GB puede servir un modelo de 7B con latencia razonable para cargas single-user. Para experimentación más ligera, el Mac Mini con LM Studio es sorprendentemente efectivo. La unified memory de Apple Silicon maneja bien modelos cuantizados, y el setup es trivial comparado con configurar drivers CUDA y vLLM en Linux.
No es production-grade, pero suficiente para prototipar una API de recomendaciones completa con routing por complejidad: las consultas simples van a un modelo ligero, las complejas se escalan. Esa arquitectura salió directamente de experimentos en el homelab antes de aterrizar en un proyecto real.
La conclusión honesta: hacer self-hosting de LLMs es viable para desarrollo y prototipado. Para producción con concurrencia real necesitas hardware más serio o un enfoque híbrido con fallback a cloud. Saberlo de primera mano vale más que leerlo en un artículo.
Las partes nada glamorosas
La mayor parte del contenido sobre homelabs en internet enseña los momentos emocionantes. El hardware nuevo, las capturas del dashboard, los diagramas de arquitectura. Nadie habla del martes por la noche en el que tu nodo K3s no quiere reincorporarse al clúster después de restaurar un snapshot de Proxmox, o de la tarde que pierdes debugueando problemas de red entre VMs que ayer iban bien.
Algunos problemas reales con los que he lidiado:
La presión de almacenamiento es constante. Un NVMe de 500GB se llena rápido cuando corres VMs con thick provisioning. Llegué al 96% de uso del disco y tuve que diseñar una estrategia de almacenamiento multi-tier sobre la marcha: NVMe para cargas calientes, SSD SATA para backups, HDD para almacenamiento frío. El ejercicio me enseñó más sobre tiering de storage que cualquier calculadora de precios cloud.
# El momento en el que te das cuenta de que te quedan 16GB
pvdisplay | grep "Free"
# PV Free 16.00 GiB
Reconfigurar la red es humillante. Cuando cambié de ISP, todas las VMs y contenedores con IP estática se quedaron a oscuras. La nueva subnet implicó tocar todos los /etc/netplan/*.yaml, actualizar la dirección del listener de Vault, reconfigurar el endpoint del API server de K3s y reconstruir la confianza SSH. Llevó unas horas y me forzó a documentar todo mi esquema de asignación de IPs, algo que debería haber hecho desde el primer día.
# /etc/netplan/50-cloud-init.yaml en cada VM
network:
ethernets:
enp6s18:
addresses:
- 192.168.1.25/24
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses: [192.168.1.1, 8.8.8.8]
version: 2
El GPU passthrough tiene aristas afiladas. Pasar las RTX 3060 a las VMs en Proxmox implica configurar VFIO, blacklistear el driver nouveau y aceptar que tu host no va a tener salida de vídeo a menos que le añadas una GPU barata para la consola. Cuando funciona, es transparente. Cuando no, estás leyendo tablas de IOMMU groups a medianoche.
La gestión térmica no es broma. Esto es algo que la mayoría de las guías de homelab se saltan por completo. En Málaga, el verano son 35°C+ a la sombra. Cuando las dos GPUs están al máximo, la oficina se convierte en un horno en cuestión de minutos. Dos RTX 3060 bajo cargas de inferencia sostenidas generan suficiente calor para subir la temperatura ambiente de forma notable. He tenido que pensar en serio sobre flujo de aire, curvas de ventiladores y programar trabajos pesados de GPU fuera de las horas pico de calor. Si tienes hardware serio en un clima cálido, el enfriamiento no es algo accesorio. Es infraestructura.
Por qué importa profesionalmente
No tengo el homelab para ponerlo en el currículum. Lo tengo porque me mantiene honesto.
Cuando diseño una plataforma Kubernetes en el trabajo, ya he roto un clúster K3s en casa de maneras que me enseñaron cómo son realmente los modos de fallo. Cuando recomiendo Vault para gestión de secretos, ya he lidiado con su ceremonia de seal/unseal, las rarezas de su backend de almacenamiento y los casos límite de la renovación de certificados. Cuando digo que la infraestructura GPU es difícil, no estoy repitiendo una charla de conferencia. He configurado los bindings de VFIO yo mismo.
Hay una brecha entre los ingenieros que saben usar servicios gestionados y los ingenieros que entienden qué están gestionando esos servicios. Un homelab te mantiene en el lado correcto de esa brecha.
También construye un hábito que creo que importa más que cualquier tecnología concreta: la disciplina de mantener algo a lo largo del tiempo. No solo montarlo una vez para un post de blog, sino mantenerlo actualizado, parcheado, con backups y corriendo. Lidiar con la realidad nada glamorosa de que la infraestructura es una relación a largo plazo, no un despliegue puntual.
El coste real
Seamos transparentes. Tener un homelab no es gratis:
- Electricidad: unos 15-20€ al mes para el servidor Proxmox corriendo 24/7.
- Hardware: unos 1.500€ totales en dos años. GPUs, discos y un SAI (unos 100€) para respaldo de energía, que ya me ha salvado de al menos dos cortes.
- Tiempo: unas horas al mes en mantenimiento, más cuando estoy experimentando activamente.
Comparado con equivalentes en cloud (dos instancias GPU en cualquier proveedor grande costarían más de 200€/mes), se paga solo bastante rápido si lo usas de verdad. La palabra clave es “de verdad”. Un homelab parado es solo un calefactor caro.
Empezar el tuyo
Si te lo estás planteando, empieza más pequeño de lo que crees que necesitas. Un solo mini PC con Proxmox y una VM corriendo K3s te va a enseñar más en un mes que la mayoría de cursos. Añade complejidad cuando tengas una razón, no porque un vídeo de YouTube lo hiciera parecer guay.
El mejor homelab es el que de verdad mantienes.