El censo de un homelab revela la lógica de enrutamiento para agentes de IA en hardware limitado

Un desarrollador publicó el 24 de septiembre un censo exhaustivo de su infraestructura autoalojada, detallando cómo operan 41 contenedores Docker y nueve contenedores LXC a través de cuatro nodos de hardware distintos. El informe destaca las restricciones específicas impuestas por una única tarjeta gráfica de 6 GB, que finalmente determina si los agentes de inteligencia artificial se ejecutan localmente o se enrutan hacia servicios en la nube de pago.

Qué ocurrió

El autor realizó una auditoría completa de su entorno de laboratorio doméstico para entender exactamente dónde se ejecutaban las cargas de trabajo y por qué. La configuración consta de dos nodos Proxmox, un ZimaBlade y una máquina dedicada para modelos de lenguaje grandes (LLM). En conjunto, estas máquinas proporcionan 26 subprocesos de CPU y 71 GB de RAM, alojando una mezcla de servicios contenerizados y aplicaciones nativas. El censo reveló que la caja LLM, equipada con una RTX 2060, ejecuta Ollama y ComfyUI directamente sin contenedores, mientras que los otros nodos gestionan desde la automatización del hogar hasta el rastreo de agentes.

Una parte significativa del análisis se centró en las limitaciones de la inferencia de IA local. El autor descubrió que un modelo de 27 mil millones de parámetros, que supuestamente se ejecutaba en la GPU, en realidad solo colocaba 0,5 GB de su huella total de 18,3 GB en la tarjeta gráfica, dejando el resto para procesarse lentamente en la CPU. Este hallazgo motivó una investigación más profunda sobre cómo el requisito de una ventana de contexto de 64K del framework de agentes entra en conflicto con los 6 GB de memoria de video disponibles. Como resultado, la mayoría de los agentes de propósito general fueron trasladados a proveedores en la nube, mientras que tareas sensibles como las auditorías de seguridad permanecieron locales.

El informe también destapó fallos operativos causados por errores silenciosos y descuidos en la configuración. Por ejemplo, una instancia duplicada de agente con la misma identidad de red provocó días de problemas de conectividad, y una sonda de verificación de estado falló durante 17 días porque activó un filtro de privacidad en lugar de indicar una caída real del servicio. Estos incidentes subrayaron la necesidad de mejor monitoreo y una lógica de respaldo más precisa en entornos distribuidos autoalojados.

Detalles clave

• La infraestructura incluye 41 contenedores Docker y 9 contenedores LXC repartidos en cuatro cajas físicas.
• La caja LLM utiliza una RTX 2060 con 6 GB de VRAM, lo que limita la selección de modelos locales a aquellos que se ajusten a estrictas restricciones de memoria.
• Los agentes generales se enrutan hacia suscripciones de OpenRouter o OpenCode Go debido a requisitos de latencia y ventana de contexto, costando aproximadamente $11.39 al mes en total.
• Los agentes de seguridad y revisión de código se ejecutan exclusivamente en instancias locales de Ollama para evitar la fuga de datos.
• Un sistema watchdog monitorea la salud de las APIs en la nube, pero previamente falló al restaurar servicios después de un falso positivo causado por un filtro de redacción de prompts.
• Los cuelgues silenciosos en Ollama, donde los modelos permanecían fijados en memoria sin registros de error, requirieron un script personalizado para descargar procesos obsoletos cada 15 minutos.

Antecedentes

Autoalojar agentes de IA implica equilibrar los recursos computacionales frente a las necesidades de rendimiento. Las ventanas de contexto definen cuánto texto puede considerar un modelo a la vez, siendo que las ventanas más grandes requieren significativamente más memoria. Cuando un modelo supera la memoria de video disponible (VRAM), desborda hacia la RAM del sistema y utiliza la CPU para los cálculos, ralentizando drásticamente la generación de tokens. En este caso, el framework de agentes rechazaba cualquier modelo con menos de una ventana de contexto de 64K, eliminando muchos modelos más pequeños y rápidos que podrían haber cabido completamente en la GPU.

El monitoreo de sistemas distribuidos suele depender de comprobaciones de latido (heartbeat checks), donde un servicio reporta su estado a intervalos regulares. Si una comprobación falla, los sistemas automáticos suelen disparar alertas o procedimientos de conmutación por error (failover). Sin embargo, estos mecanismos pueden ser engañados por fallos no estándar, como una sonda rechazada por un filtro de contenido en lugar de un servidor caído. Entender la diferencia entre un error duro y un rechazo lógico es crítico para mantener una disponibilidad fiable en homelabs complejos.

Por qué importa

Para equipos que ejecutan su propio software, este censo ilustra la complejidad oculta de gestionar flujos de trabajo híbridos de IA. Demuestra que las especificaciones de hardware por sí solas no determinan el rendimiento; restricciones de software como los requisitos de ventana de contexto pueden forzar el uso costoso de la nube incluso cuando el hardware local parece suficiente. Los ingenieros deben medir el uso real de tokens y la latencia en lugar de confiar en las especificaciones titulares, ya que las cargas de trabajo intensivas en entrada pueden hacer que los modelos económicos en la nube sean más rentables que mantener grandes servidores locales.

El incidente con la caída de 17 días destaca la fragilidad de los sistemas de recuperación automática. Cuando la lógica de monitoreo no tiene en cuenta todos los modos de fallo, como filtros upstream bloqueando sondas, los equipos pueden permanecer ignorantes del rendimiento degradado durante períodos prolongados. Esto refuerza la necesidad de herramientas robustas de observabilidad capaces de distinguir entre indisponibilidad del servicio y errores lógicos, asegurando que los respaldos se activen correctamente y restauren las operaciones normales sin intervención manual.

Qué puedes hacer

• Audita tu inventario de contenedores y máquinas virtuales para identificar servicios duplicados o recursos no utilizados que consuman memoria.
• Mide las ratios reales de tokens de entrada versus salida para determinar si los costos de las APIs en la nube están impulsados por el volumen o por la elección del modelo.
• Implementa monitoreo de latido para todos los trabajos críticos en segundo plano y servicios de IA para detectar cuelgues silenciosos o estancamientos.
• Configura cadenas de respaldo con diversos proveedores para evitar puntos únicos de fallo cuando un proveedor experimenta problemas.
• Prueba regularmente las sondas de verificación de estado para asegurar que no estén bloqueadas por filtros de privacidad o políticas de contenido.
• Crea scripts para descargar automáticamente modelos inactivos de la memoria de la GPU si tu motor de inferencia no maneja bien la contención de recursos.