Topología de red para un laboratorio de robótica y cómputo de IA

Un laboratorio de robótica no es una oficina, ni un centro de datos, ni un laboratorio doméstico. Es una red pequeña pero excepcionalmente exigente: un puñado de dispositivos con perfiles de tráfico muy distintos compartiendo el mismo cable. Un humanoide transmite vídeo estéreo a un servidor de inferencia. Una estación de trabajo de desarrollo descarga un checkpoint de modelo de 70 GB. Un cuadrúpedo deambula buscando su base. Un puerto IPMI informa discretamente del tacómetro de un ventilador.

Si se equivoca con la topología, los síntomas son horribles e indirectos: un robot se entrecorta cuando un compañero sube una imagen de Docker; la latencia de cola del servidor de inferencia se duplica cuando alguien se conecta al Wi-Fi; la sincronización de gradientes con su equipo de ajuste fino sufre misteriosos picos de 200 ms a la hora de comer. Si acierta, la red se vuelve invisible, que es lo único que usted quiere de ella.

Este artículo trata de la forma correcta de esa red en 2026. Público: integradores y montadores de laboratorios que levantan el «laboratorio en una caja»: de uno a cuatro robots, uno o dos servidores de inferencia Kentino AI, unas cuantas estaciones de trabajo de desarrollo y las piezas de almacenamiento y gestión que lo unen todo. No es una arquitectura de referencia de hiperescalador. Tampoco un montaje doméstico de bajo presupuesto. El término medio real.

El objetivo: el «laboratorio en una caja»

El despliegue de referencia de este artículo:

• 1–4 robots — humanoides, cuadrúpedos o una mezcla. Wi-Fi 6E como enlace principal y cable opcional durante el desarrollo.
• 1–2 servidores de inferencia Kentino AI — 4× u 8× GPU (5090 / RTX Pro 6000 Blackwell), con vLLM / SGLang para VLM y LLM.
• 1–2 equipos de almacenamiento / NAS — conjuntos de datos, checkpoints y registros de sensores grabados. Normalmente un equipo ZFS con caché NVMe.
• 2–6 estaciones de trabajo de desarrollo — ingenieros que ejecutan ROS 2, Isaac Sim, entrenan ajustes finos y copian datos de un lado a otro.
• Plano de gestión — IPMI/BMC en cada servidor, switches, puntos de acceso y un host local de DNS/DHCP.

Total: 15–40 dispositivos de red activos. Un solo switch podría soportarlo eléctricamente. Si el diseño de abajo lleva dos switches no es por capacidad, sino por dominio de fallo, presupuesto PoE y el deseo de mantener el tráfico de los robots y el de las GPU en cables físicos distintos, para que ninguno pueda asfixiar al otro.

Topología física

Dos switches físicos, un firewall, uno o dos puntos de acceso. Los servidores Kentino AI llegan al núcleo a 25 GbE; el switch de acceso agrega estaciones de trabajo y puntos de acceso; los robots se conectan por un SSID dedicado de 6 GHz.

Dos switches físicos, un firewall, uno o dos puntos de acceso. Los servidores Kentino AI y el equipo de almacenamiento llegan al switch de núcleo a 25 GbE. El switch de acceso recoge los dispositivos cableados pero más lentos (estaciones de trabajo, puntos de acceso, IPMI, cámaras) y sube al núcleo a 10 GbE. Los robots entran por Wi-Fi 6E en un SSID dedicado.

¿Por qué 25 GbE entre el núcleo y Kentino AI? Porque la NIC ConnectX-6 Lx SFP28 de doble puerto es la tarjeta solvente más barata de 2026 (€700–€900 en el mercado, a veces menos de segunda mano) y 25 GbE sobra para la convergencia de inferencia de un solo servidor. Un modelo 70B en Q4 que envía tokens a cuatro robots a la vez se mueve en decenas de Mbit/s. El trasiego de un checkpoint de modelo es el gran evento de ancho de banda del día, y 25 GbE despacha 100 GB en unos 35 segundos. Los clientes que entrenan en varios nodos necesitan 100 GbE, algo que se trata en N01 y N08 — pero esa es una red distinta de la de este artículo.

Dimensionado de las velocidades de enlace

Dos ideas que conviene interiorizar:

• No necesita 100 GbE en un laboratorio de un solo servidor. Se especifica porque la ficha técnica impresiona. El caudal de red realmente sostenido del servidor Kentino AI son «tokens de salida» (Mbit/s) más algún trasiego ocasional de checkpoints (Gb/s de un solo dígito). El cable nunca es el cuello de botella en un laboratorio dedicado solo a inferencia.
• El Wi-Fi es siempre el salto más lento. Planifique contando con ello. Un buen enlace de 6 GHz con un cliente Wi-Fi 6E ofrece 1.2–1.8 Gb/s reales a 10 m con línea de visión directa, con 3–8 ms de latencia y un jitter de ±2 ms en condiciones aceptables. Los flujos de sensores de un robot (una o dos cámaras RGB-D a 1080p30 cada una) necesitan ~150–300 Mb/s sostenidos; margen le sobra, hasta que alguien más se conecta a ese SSID.

Segmentación en VLAN

Esta red tiene seis VLAN no por higiene corporativa, sino para que el mal comportamiento de un dispositivo no pueda arruinarle el día a otro.

La separación que pilla a todo el mundo: los robots y Kentino AI están en VLAN distintas aunque hablen entre sí constantemente. El enrutamiento entre VLAN es tarea del firewall/router, y ahí es donde se impone quién puede hablar con quién. Si los robots y Kentino AI compartieran VLAN, un robot comprometido (y los humanoides de consumo llegan con superficie de ataque) tendría acceso plano de nivel 2 al servidor de GPU. Eso es un «no» rotundo en cualquier despliegue medianamente serio.

La otra separación que merece la pena defender: el plano de gestión tiene su propia VLAN, y punto. Las interfaces IPMI/BMC llevan dos décadas saliendo de fábrica con puertas traseras del fabricante y conviene dar por hecho que siempre será así. Tienen su propia subred, sus propias reglas de acceso y nadie enruta hacia ellas salvo un portátil de administración en la VLAN de gestión.

Reglas del firewall

Denegación por defecto entre VLAN. Y luego, las excepciones:

Dos reglas con criterio propio que conviene destacar:

• Los robots no tienen salida a internet. Hay resistencia a esto porque rompe el flujo de telemetría y actualización de firmware del fabricante. Mejor. Autorice el servidor de actualizaciones concreto del fabricante durante una ventana de mantenimiento y vuelva a cerrarlo después. El estado por defecto es «este robot no puede llamar a casa».
• La salida WAN de Kentino AI es bajo demanda. Durante la descarga de un modelo o de un contenedor, abra el 443. El resto del tiempo, manténgalo cerrado. El servidor de inferencia no tiene nada que hacer navegando por la web, y usted no quiere que el script curl de un desarrollador curioso sea la vía por la que un gusano exfiltre su dataset.

Configuración del Wi-Fi

El error más común al montar el Wi-Fi de un laboratorio de robótica es «ya ponemos los robots en el SSID de la oficina». Ese SSID lo comparten teléfonos, portátiles, impresoras, un frigorífico inteligente y tres personas en llamadas de Teams. La variación de latencia es brutal y el comportamiento reactivo del robot se desmorona.

La respuesta correcta:

• Un SSID por VLAN. «lab-robots» en la VLAN 10, «lab-dev» en la 30 y «lab-guest» en la 99. La VLAN de gestión no tiene presencia inalámbrica.
• El SSID de robótica es solo de 6 GHz. Sin 2.4 GHz ni reserva en 5 GHz. Sí, eso significa que los dispositivos antiguos no pueden conectarse: de eso se trata. En 6 GHz hay muchísima menos contienda porque en 2026 la población de dispositivos heredados allí es prácticamente nula.
• Ancho de canal de 80 MHz, no de 160. 160 MHz queda mejor en la ficha técnica, pero dos puntos de acceso a 160 MHz en el mismo edificio se pisan el uno al otro. 80 MHz en 6 GHz le dan de cuatro a seis canales limpios y una latencia predecible.
• Un punto de acceso por cada ~60–80 m² de área de trabajo de los robots, con línea de visión directa si es posible. Si el laboratorio tiene tabiques, añada un punto de acceso. El roaming funciona bien en Wi-Fi 6E con 802.11r/k/v activados, pero a un robot en mitad de una tarea no le hace ninguna gracia un cambio de punto de acceso.
• Desactive el reparto equitativo de tiempo de aire en el SSID de los robots. El ajuste por defecto favorece a los clientes más lentos; usted quiere que el robot, único consumidor de ese SSID, se quede con todas las ranuras de tiempo de aire.

En hardware de 2026: el UniFi U6 Enterprise (Wi-Fi 6E, ~€450) o los más recientes U7 Pro / E7 (Wi-Fi 7, €189 / €499+) son las opciones con mejor relación calidad-precio. La serie Aruba 650 y la Cisco Meraki MR son las alternativas de clase empresarial a 2–3× el precio; el plano de gestión es más agradable y las radios se comportan mejor con alta densidad de clientes, y un despliegue de un solo laboratorio con dos robots no necesita ninguna de las dos cosas.

Sincronización horaria: PTP y NTP

La deriva de reloj entre robot y servidor rompe la fusión de sensores de maneras sutiles y bochornosas. Un desfase de 20 ms hace que una cadena de profundidad estéreo genere objetos fantasma. Uno de 100 ms hace que el planificador de manipulación crea que la pinza está donde no está.

Dos niveles de solución:

• NTP con chronyd contra un servidor local de estrato 1 (una Raspberry Pi con un HAT de GPS, ~€80 todo incluido, o el propio firewall haciendo de estrato 2). Alcanza una precisión de ~1 ms en LAN cableada y de ~5–20 ms por Wi-Fi. Suficiente para la mayoría del trabajo de robótica.
• PTP (IEEE 1588v2) con marcas de tiempo por hardware en switches que lo admitan. Las series MikroTik CRS3xx/CRS5xx admiten reloj de frontera PTP con sincronización del orden del nanosegundo; el Aruba CX 6300 y los Cisco Catalyst también. Alcanza menos de un microsegundo en rutas cableadas y menos de un milisegundo por Wi-Fi.

Con 1–2 robots, NTP basta. Ejecute chronyd en cada nodo, apúntelo al maestro local, vigile el desfase y configure una alarma a partir de >5 ms de deriva. Con cuatro o más robots, o en cualquier despliegue que haga fusión multisensor entre máquinas, use PTP en la parte cableada y NTP como reserva. En cualquier caso, vigile la deriva. Hay muchísimos laboratorios que «tienen sincronización horaria» porque ejecutaron apt install ntp una vez hace dos años.

DNS, DHCP e IPAM

Un resolutor local en el plano de gestión, sin discusión. Pi-hole o Unbound en una pequeña máquina virtual hacen el trabajo. Los motivos:

1. Los robots y los servidores de inferencia necesitan resolver vllm.lab.local, nas.lab.local, etc., sin un viaje de ida y vuelta a la WAN.
2. Usted quiere un único sitio donde añadir una entrada de hosts cuando levante un nuevo endpoint Kentino AI.
3. Pi-hole le regala un bloqueo de anuncios y telemetría para toda la red, que mantiene fuera de sus cables el tráfico perdido de los fabricantes llamando a casa.

DHCP por VLAN, configurado en el firewall/router (UDM Pro Max, OPNsense y pfSense lo hacen todos con solvencia). Reservas para todo lo que importa — robots, servidores, puntos de acceso, IPMI, switches y NAS. Los rangos dinámicos son solo para visitantes y estaciones de trabajo efímeras. Un robot que recibe una IP distinta en cada reinicio es un robot cuyos archivos de arranque de ROS 2 se rompen todos los martes.

Monitorización

Un laboratorio sin monitorización es un laboratorio donde los problemas se diagnostican por sus consecuencias. Despliegue la pila habitual en el plano de gestión:

• Prometheus recogiendo SNMPv3 de los switches, contadores de NIC (node_exporter), métricas de GPU (dcgm_exporter) y métricas del servidor de inferencia (vLLM expone Prometheus de forma nativa).
• Grafana con paneles de uso por puerto, caudal por VLAN, temperatura y uso de GPU, deriva PTP/NTP y disponibilidad de conectividad de los robots.
• Alertas que salten de verdad: contador de pausas PFC > 0 en cualquier puerto (significa que alguien está congestionando RDMA, que no debería existir en esta red, pero compruébelo igualmente), temperatura de GPU > 80 °C, deriva horaria > 5 ms y anomalías en el número de clientes de un punto de acceso.

SNMPv3, no v2c. El laboratorio es lo bastante pequeño como para que el trabajo extra de configuración sean quince minutos y la seguridad adicional sea real.

Lista de materiales concreta: 1 servidor, 2 robots, 4 estaciones de trabajo

Una lista de la compra realista y con precios honestos para el despliegue de referencia, en EUR sin IVA a mediados de 2026:

Como comparación: solo el servidor Kentino AI de 8 GPU cuesta €40–70k, y cada uno de los dos humanoides, €30–80k. La red supone el 5–10 % del gasto total y es la parte que con más probabilidad marca la diferencia entre un laboratorio que funciona y otro que no.

Si el presupuesto aprieta, los recortes defendibles: bajar el switch de núcleo a un MikroTik CRS504-4XQ-IN (4× QSFP28, con derivaciones a 16× 25 GbE, ~€700) y aceptar menos puertos; usar un solo punto de acceso si el área de trabajo es <60 m²; prescindir de la fuente NTP por GPS y conformarse con chrony a través de la WAN.

Meteduras de pata habituales

Más o menos por orden de frecuencia con la que muerden:

• Mezclar el tráfico de robótica con el Wi-Fi general de la oficina. La variación de latencia mata el comportamiento reactivo. El primer arreglo en cada llamada del tipo «mi robot va a trompicones» es «dele su propio SSID en 6 GHz».
• Búferes insuficientes en switches baratos. Un switch de 10G y 8 puertos por €200 lleva bien dos dispositivos y se derrumba cuando cuatro nodos golpean el mismo enlace ascendente. El tráfico de IA va a ráfagas; los búferes del switch absorben la ráfaga. El switch de búfer profundo más barato y solvente de este artículo es el Aruba CX 6300 (búfer compartido de 8/16/32 MB); el MikroTik CRS5xx es más justo, pero suficiente para un laboratorio de un solo servidor.
• Ni maestro PTP ni auditoría de NTP. Las sincronizaciones horarias «funcionan» hasta que dejan de hacerlo, y entretanto la fusión de sensores falla en silencio. Vigile el desfase y ponga una alarma.
• Presupuesto PoE mal calculado. Un switch anuncia «PoE++» y usted descubre que su presupuesto total son 200 W, la mitad de los cuales se los comen las cámaras de las que nadie le habló, y el punto de acceso se queda sin tensión al arrancar. Sume los vatios y deje un 30 % de margen.
• Permitir que el robot llame a casa. Actualización de firmware del fabricante un martes por la mañana, que descarga un modelo nuevo, que cambia la latencia de inferencia a bordo, que rompe la sincronización de la pinza. Siempre. Bloquee con el firewall la salida WAN del robot y controle las actualizaciones a mano.
• Nada de monitorización hasta que algo se rompe. El laboratorio funciona bien durante seis meses. Después el punto de acceso empieza a tirar clientes dos veces al día y nadie se entera en una semana porque no hay paneles. Cuando alguien investiga, han cambiado otras cuatro cosas y nadie sabe decir qué falló primero.

Opinión sincera

La mayoría de los laboratorios de robótica sobredimensionan su red e infradimensionan las partes que importan. Se especifican troncales de 100 GbE para laboratorios de inferencia con un solo servidor y luego se pone el robot en el Wi-Fi de la oficina. Se compra un Cisco Catalyst 9300X con búferes profundos y luego se trabaja en nivel 2 plano, sin segmentación en VLAN.

El diseño 80/20 para un laboratorio de 2026 con un servidor y 1–4 robots es pequeño y poco vistoso:

• 25 GbE entre el switch de núcleo y el servidor Kentino AI. Una NIC, un DAC y listo.
• 10 GbE entre núcleo y acceso. Dos DAC.
• Un switch de núcleo, un switch de acceso, un firewall y uno o dos puntos de acceso.
• Seis VLAN, firewall con denegación por defecto y SSID separados por función.
• NTP desde una fuente local, monitorizado.
• Prometheus + Grafana en una pequeña máquina virtual.

Gasto total en red: menos de €7k. Tiempo total de puesta en marcha: alrededor de una semana si el cableado está listo. Esto sostiene un laboratorio de producción real; el siguiente escalón (troncal de 100 GbE, Clos enrutado, switches de IA con búfer profundo) es para entrenamiento multiservidor, que es el terreno de N04, N08 y K02.

Esto forma parte de la Kentino Wiki, una serie de referencia sobre computación de IA, robótica y los sistemas que los conectan. Comentarios y correcciones son bienvenidos en info@kentino.com.