Homelab de IA con Proxmox, Kubernetes, red de 200Gb y Ceph

Un homelab compartido en Reddit este agosto combina tres hosts Proxmox, 36 núcleos físicos de CPU, 192 GB de memoria DDR5, cuatro equipos ASUS GX10 que hacen de nodos Kubernetes, 512 GB de VRAM en total y una red de alta velocidad de 200Gb. El entorno sirve modelos de lenguaje grandes en local, generación de imágenes, servicios de identidad, cargas de trabajo GitOps y otros proyectos. El dueño también piensa añadir tarjetas de red de alta velocidad a los nodos Proxmox y montar un almacenamiento Ceph más rápido.

Esto va mucho más allá del típico homelab de un solo mini PC, pero resulta útil porque plantea las mismas preguntas de arquitectura que surgen en la infraestructura de IA en producción. El cómputo es solo una parte del sistema, y el uso de las GPU, el rendimiento del almacenamiento, el tráfico este-oeste, los dominios de fallo, la sobrecarga de la virtualización, la orquestación, el backup y la complejidad operativa empiezan a influirse entre sí.

El centro de Proxmox de Mr.PlanB es un buen punto de partida para la capa de virtualización. Lo más interesante es cómo debería conectarse esa capa con Kubernetes y con el hardware específico de IA sin que el laboratorio se convierta en una enorme cadena de dependencias.

Proxmox es la capa de control y puede que no sea la capa de GPU

Proxmox funciona bien como base de virtualización general para servicios de gestión, VMs de utilidades, sistemas de prueba, servicios de almacenamiento, firewalls y cargas de trabajo de aplicaciones convencionales. Da al dueño del laboratorio un sitio coherente donde crear VMs y contenedores, gestionar redes y almacenamiento y experimentar con clústeres y automatización.

Las cargas de IA que tiran mucho de GPU traen otras prioridades. El acceso directo al hardware, la compatibilidad de los drivers, la capacidad de memoria, la topología PCIe y el ancho de banda de la red pueden importar más que la densidad de VMs. En este montaje, los nodos dedicados a IA forman parte de Kubernetes mientras Proxmox sigue siendo un clúster aparte. Esa división puede ser sensata, porque deja que cada capa haga lo que mejor sabe hacer.

Un laboratorio no necesita virtualizar todos los aceleradores solo porque haya un hipervisor disponible. A veces la arquitectura más limpia es usar Proxmox para la infraestructura compartida y las cargas de gestión de Kubernetes y mantener los nodos con GPU más cerca del bare metal. La elección depende de si el objetivo es el aislamiento, la portabilidad, el aprovechamiento del hardware o aprender un patrón concreto de producción.

Kubernetes convierte las máquinas con GPU en un pool de cómputo compartido

Cuando hay varios nodos con aceleradores, Kubernetes resulta atractivo porque puede repartir cargas de trabajo entre ellos, exponer servicios de forma coherente y ofrecer un modelo de despliegue común para inferencia, servicio de modelos, APIs y aplicaciones de apoyo.

Lo difícil es mantener productivas unas GPU caras. La guía de cargas de IA y GPU en Kubernetes cubre la detección de aceleradores, la planificación, los pools de nodos, los drivers, el rendimiento del almacenamiento, la red, el autoescalado, la resiliencia, la observabilidad y el coste. Esas cuestiones se hacen visibles enseguida en un homelab con varios modelos y servicios compitiendo por la memoria de las GPU y por las rutas de datos.

Un modelo local puede parecer rápido cuando se prueba solo y luego ralentizarse cuando la generación de imágenes, los embeddings, el tráfico de almacenamiento y las tareas en segundo plano comparten la misma red. Kubernetes puede planificar cargas de trabajo, pero no puede crear ancho de banda ni VRAM que no existen. Un buen diseño del clúster sigue exigiendo saber dónde está de verdad el cuello de botella.

Una red de 200Gb cambia lo que puede llegar a ser el almacenamiento

La red de alta velocidad es especialmente interesante porque el almacenamiento distribuido a menudo no cumple las expectativas cuando la red se trata como algo secundario. Ceph replica los datos entre nodos y depende mucho del comportamiento de la red durante las escrituras normales, la recuperación, el reequilibrado y los escenarios de fallo.

Con enlaces lo bastante rápidos, Ceph puede resultar mucho más atractivo para un clúster Proxmox, pero la velocidad de línea por sí sola no garantiza un buen almacenamiento. El rendimiento de los discos, la capacidad de la CPU, la latencia de la red, la configuración de los switches, la coherencia del MTU, los drivers de las tarjetas de red, los ajustes de replicación y el diseño de los dominios de fallo siguen decidiendo el resultado.

La guía de Ceph explica las piezas básicas, como los monitores, los managers, los OSD, los placement groups, la replicación, el erasure coding, la autorreparación y el escalado. En un clúster Proxmox de tres nodos, la lección principal es dimensionar Ceph en torno al componente importante más lento y no en torno a la velocidad de red del titular, porque una red rápida puede eliminar una limitación y simplemente dejar al descubierto la siguiente.

Separa el tráfico de almacenamiento de todo lo demás

Un laboratorio que lleva por la misma ruta el tráfico de las VMs, el de Kubernetes, la replicación del almacenamiento, los backups, la gestión y los datos de los modelos de IA puede volverse impredecible. Aquí es donde un diseño de red con mentalidad de producción empieza a compensar.

La replicación y la recuperación de Ceph pueden generar grandes flujos este-oeste, los nodos de inferencia pueden mover pesos de modelos y conjuntos de datos, y las tareas de backup pueden crear transferencias sostenidas. Kubernetes añade encima el tráfico de servicios y de control, y el acceso de gestión debería seguir disponible incluso cuando las cargas de trabajo están ocupadas.

La separación lógica con VLANs es un punto de partida, pero los entornos de alto rendimiento también pueden necesitar separación física o interfaces planificadas con cuidado. El trabajo extra de diseño sirve para que una carga pesada no haga difícil operar el resto del laboratorio.

La misma idea se aplica a los dominios de fallo. Si el mismo switch, la misma fuente de alimentación o la misma ruta de almacenamiento sostienen todas las capas, un clúster sofisticado puede seguir teniendo un punto único de fallo muy simple.

Una infraestructura rápida necesita un backup igual de serio

Un laboratorio con cientos de gigabytes de VRAM y almacenamiento de alta velocidad puede reconstruir el cómputo rápido, pero los datos pueden ser más difíciles de recrear. Los archivos de los modelos a menudo se pueden volver a descargar, mientras que los repositorios Git, las bases de datos de las aplicaciones, la configuración de identidad, los resultados de fine tuning, los prompts, los conjuntos de datos y el estado de los servicios pueden ser únicos.

Eso hace que la arquitectura de backup importe incluso en un entorno experimental. La guía de Proxmox Backup Server cubre las copias incrementales con deduplicación, la verificación, la sincronización remota, el cifrado, la poda y el soporte de cinta. Las cargas de trabajo de Kubernetes también necesitan su propio diseño de recuperación, porque los recursos del clúster y los datos persistentes de las aplicaciones no siempre viven en el mismo sitio.

El enfoque práctico es clasificar los datos, ya que las cachés de modelos desechables no deberían recibir la misma protección que las bases de datos irremplazables. Los manifiestos de Kubernetes reproducibles pueden necesitar más el historial de Git que un backup a nivel de imagen. Los servicios con estado necesitan una protección coherente a nivel de aplicación y restauraciones probadas.

Lo que este homelab enseña sobre arquitectura

La cifra de benchmark de un homelab de IA con 200Gb impresiona menos que la oportunidad que te da de ver cómo interactúan las capas de la infraestructura.

Proxmox puede enseñar virtualización, clústeres, almacenamiento, redes, backup y automatización. Kubernetes añade planificación, redes de servicios, estado deseado, secretos, operators y GitOps. Ceph añade el comportamiento del almacenamiento distribuido y la recuperación ante fallos. Los nodos con GPU añaden un recurso de hardware escaso con sus propios drivers, límites de memoria y características de rendimiento.

Cuando estos sistemas se conectan, el laboratorio se convierte en un sitio donde probar preguntas realistas. ¿Qué pasa cuando falla un nodo de Ceph en pleno tráfico de inferencia intenso? ¿Cuánto tarda en recuperarse un servicio de modelos cuando desaparece un nodo de Kubernetes? ¿Qué tráfico domina la red durante el backup? ¿La gestión sigue respondiendo durante la recuperación del almacenamiento? ¿Qué servicios deberían virtualizarse y cuáles deberían quedarse en bare metal?

Responder a esas preguntas vale más que montar el rack más rápido posible. Un buen homelab te da fallos controlados, cuellos de botella medibles y un entorno seguro para cambiar la arquitectura una y otra vez, y por eso Proxmox, Kubernetes, Ceph y la infraestructura de IA forman una combinación tan interesante.

Publicado originalmente en el blog de Mr.PlanB.