Topologia de rede para um laboratório de robótica + computação de IA

Um laboratório de robótica não é um escritório, não é um centro de dados e não é um laboratório caseiro. É uma rede pequena, mas invulgarmente exigente: um punhado de dispositivos com perfis de tráfego muito diferentes a partilhar o mesmo cabo. Um humanoide transmite vídeo estéreo para um servidor de inferência. Uma estação de trabalho de desenvolvimento descarrega um checkpoint de modelo de 70 GB. Um quadrúpede anda às voltas à procura da sua doca. Uma porta IPMI comunica discretamente a rotação de uma ventoinha.

Erre na topologia e os sintomas são horríveis e indiretos: um robô começa a engasgar-se quando um colega envia uma imagem Docker; a latência de cauda do servidor de inferência duplica quando alguém entra no Wi-Fi; a sincronização de gradientes com a máquina de fine-tuning passa misteriosamente a ter picos de 200 ms à hora de almoço. Acerte nela e a rede torna-se invisível, que é a única coisa que se pretende dela.

Este artigo é sobre a forma correta dessa rede em 2026. Público-alvo: integradores e construtores de laboratórios que montam o "laboratório numa caixa" — um a quatro robôs, um ou dois servidores de inferência Kentino AI, algumas estações de trabalho de desenvolvimento e as peças de armazenamento e gestão que ligam tudo. Não é uma arquitetura de referência para hiperescaladores. Não é uma montagem caseira de baixo orçamento. É mesmo o meio-termo.

O alvo: "laboratório numa caixa"

A implementação de referência deste artigo:

• 1–4 robôs — humanoides, quadrúpedes ou uma mistura. Wi-Fi 6E como ligação principal, cabo opcional durante o desenvolvimento.
• 1–2 servidores de inferência Kentino AI — 4× ou 8× GPU (5090 / RTX Pro 6000 Blackwell), a correr vLLM / SGLang para VLM e LLM.
• 1–2 unidades de armazenamento / NAS — conjuntos de dados, checkpoints, registos de sensores gravados. Normalmente uma máquina ZFS com cache NVMe.
• 2–6 estações de trabalho de desenvolvimento — engenheiros a correr ROS 2 e Isaac Sim, a treinar fine-tunes, a copiar dados de um lado para o outro.
• Plano de gestão — IPMI/BMC em todos os servidores, switches, APs e um host DNS/DHCP local.

Total: 15–40 dispositivos de rede ativos. Um único switch aguentaria tudo do ponto de vista elétrico. A razão para haver dois switches no desenho abaixo não é a capacidade — é o domínio de falha, o orçamento PoE e a vontade de manter o tráfego dos robôs e o tráfego das GPU em cabos físicos distintos, para que um não possa esfomear o outro.

Topologia física

Dois switches físicos, uma firewall, um ou dois APs. Os servidores Kentino AI ligam ao core a 25 GbE; o switch de acesso agrega estações de trabalho e APs; os robôs ligam-se através de um SSID dedicado a 6 GHz.

Dois switches físicos, uma firewall, um ou dois APs. Os servidores Kentino AI e a máquina de armazenamento ligam ao switch de core a 25 GbE. O switch de acesso recolhe os dispositivos com fio mais lentos — estações de trabalho, APs, IPMI, câmaras — e faz uplink para o core a 10 GbE. Os robôs entram por Wi-Fi 6E num SSID dedicado.

Porquê 25 GbE entre o core e o Kentino AI? Porque a placa de rede ConnectX-6 Lx SFP28 de duas portas é a opção credível mais barata em 2026 (€700–€900 de rua, por vezes menos em segunda mão) e 25 GbE chega e sobra para a convergência de inferência num único servidor. Um modelo 70B em Q4 a transmitir tokens para quatro robôs em simultâneo situa-se na ordem das dezenas de Mbit/s. A transferência de um checkpoint de modelo é o grande acontecimento de largura de banda do dia e 25 GbE despacham 100 GB em cerca de 35 segundos. Os clientes que fazem treino em múltiplos nós precisam de 100 GbE — abordado em N01 e N08 — mas essa é uma rede diferente da deste artigo.

Dimensionamento dos escalões de velocidade

Duas ideias a interiorizar:

• Não precisa de 100 GbE num laboratório de servidor único. Especifica-se porque a ficha técnica impressiona. O débito de rede realmente sustentado pelo servidor Kentino AI são os "tokens à saída" (Mbit/s) mais as transferências ocasionais de checkpoints (poucos Gb/s). O cabo nunca é o estrangulamento num laboratório só de inferência.
• O Wi-Fi é sempre o troço mais lento. Planeie em função disso. Uma boa ligação a 6 GHz para um cliente Wi-Fi 6E alcança 1.2–1.8 Gb/s de débito real a 10 m em linha de vista, com 3–8 ms de latência e um jitter de ±2 ms em condições razoáveis. Os fluxos de sensores de um robô (uma ou duas câmaras RGB-D a 1080p30 cada) precisam de ~150–300 Mb/s sustentados; a margem é confortável — até que mais alguém entre no SSID.

Segmentação em VLAN

A razão para esta rede ter seis VLAN não é higiene corporativa. É para que o mau comportamento de um dispositivo não possa estragar o dia de outro.

A separação que apanha as pessoas desprevenidas: os robôs e o Kentino AI ficam em VLAN diferentes, apesar de comunicarem entre si constantemente. O encaminhamento entre VLAN é tarefa da firewall/router e é aí que se impõe quem pode falar com quem. Se os robôs e o Kentino AI partilhassem uma VLAN, um robô comprometido (e os humanoides de consumo vêm com superfície de ataque) teria acesso L2 direto ao servidor de GPU. Isso é um "não" categórico em qualquer implementação minimamente séria.

A outra separação que vale a pena defender: o plano de gestão tem VLAN própria, ponto final. As interfaces IPMI/BMC têm sido fornecidas com backdoors do fabricante há duas décadas e deve partir-se do princípio de que continuará assim. Têm a sua própria sub-rede, as suas próprias regras de acesso e ninguém lhes chega, exceto um portátil de administração na VLAN de gestão.

Regras de firewall

Negação por omissão entre VLAN. Depois, as exceções:

Duas regras assumidamente opinativas que vale a pena destacar:

• Os robôs não têm saída para a Internet. Há resistência a isto porque quebra o fluxo de telemetria / atualização de firmware do fabricante. Ainda bem. Autorize o servidor de atualizações do fabricante numa janela de manutenção e volte a fechá-lo. O estado por omissão é "este robô não telefona para casa".
• A saída WAN do Kentino AI é a pedido. Durante uma descarga de modelo ou um pull de contentor, abra a porta 443. Caso contrário, mantenha-a fechada. O servidor de inferência não tem nada que andar a navegar na Web e ninguém quer que o script curl de um programador curioso seja o caminho por onde um worm exfiltra o seu conjunto de dados.

Configuração do Wi-Fi

O erro mais comum na construção do Wi-Fi de um laboratório de robótica é "vamos pôr os robôs no SSID do escritório". Esse SSID é partilhado com telemóveis, portáteis, impressoras, um frigorífico inteligente e três pessoas em chamadas do Teams. A variação da latência é brutal e o comportamento reativo do robô desmorona-se.

A resposta certa:

• Um SSID por VLAN. "lab-robots" na VLAN 10, "lab-dev" na VLAN 30, "lab-guest" na VLAN 99. A VLAN de gestão não tem presença sem fios.
• O SSID de robótica é exclusivamente a 6 GHz. Sem 2.4 GHz, sem alternativa a 5 GHz. Sim, isto significa que os dispositivos mais antigos não conseguem ligar-se — é precisamente esse o objetivo. A banda de 6 GHz tem muitíssimo menos contenção porque a população de equipamentos antigos nela é praticamente nula em 2026.
• Largura de canal de 80 MHz, não de 160. 160 MHz fica melhor na ficha técnica, mas dois APs de 160 MHz no mesmo edifício pisam-se um ao outro. 80 MHz a 6 GHz dão quatro a seis canais limpos e uma latência previsível.
• Um AP por cada ~60–80 m² de área de trabalho do robô, em linha de vista sempre que possível. Se o laboratório tiver paredes, acrescente um AP. O roaming funciona bem em Wi-Fi 6E com o 802.11r/k/v ativado, mas um robô a meio de uma tarefa não aprecia um evento de roaming.
• Desative a equidade de tempo de antena no SSID dos robôs. A predefinição favorece os clientes mais lentos; o que se pretende é que o robô, único consumidor desse SSID, fique com todos os intervalos de antena.

Para hardware de 2026: o UniFi U6 Enterprise (Wi-Fi 6E, ~€450) ou os mais recentes U7 Pro / E7 (Wi-Fi 7, €189 / €499+) são as escolhas com melhor relação custo-benefício. As séries Aruba 650 e Cisco Meraki MR são as alternativas de classe empresarial a 2–3× o preço; o plano de gestão é mais agradável e os rádios aguentam melhor uma densidade elevada de clientes, duas coisas de que um laboratório único com dois robôs não precisa de facto.

Sincronização de tempo — PTP e NTP

O desvio de relógio entre o robô e o servidor estraga a fusão de sensores de formas subtis e embaraçosas. Um desvio de 20 ms faz um pipeline de profundidade estéreo produzir objetos fantasma. Um desvio de 100 ms faz o planeador de manipulação julgar que a garra está onde não está.

Dois níveis de solução:

• NTP com chronyd contra um servidor local de estrato 1 (um Raspberry Pi com um chapéu GPS, ~€80 tudo incluído, ou a firewall a funcionar como estrato 2). Atinge uma exatidão de ~1 ms numa LAN com fios e de ~5–20 ms por Wi-Fi. Suficiente para a maioria do trabalho de robótica.
• PTP (IEEE 1588v2) com marcação temporal por hardware em switches que o suportem. As séries MikroTik CRS3xx/CRS5xx suportam relógio de fronteira PTP com sincronização na ordem dos nanossegundos; o Aruba CX 6300 e o Cisco Catalyst também o fazem. Atinge o submicrossegundo em percursos com fios e o submilissegundo por Wi-Fi.

Para 1–2 robôs, o NTP chega. Corra o chronyd em todos os nós, aponte-o ao mestre local, monitorize o desvio e defina um alarme para derivas >5 ms. Para quatro ou mais robôs, ou para qualquer implementação com fusão multissensor entre máquinas, use PTP do lado com fios e o NTP como alternativa. Em qualquer dos casos, monitorize a deriva. O número de laboratórios que "têm sincronização de tempo" porque correram apt install ntp uma vez há dois anos é grande.

DNS, DHCP e IPAM

Resolvedor local no plano de gestão, ponto final. Pi-hole ou Unbound numa pequena VM resolvem o assunto. As razões:

1. Os robôs e os servidores de inferência precisam de resolver vllm.lab.local, nas.lab.local, etc. sem ida e volta à WAN.
2. Convém ter um único sítio onde acrescentar uma entrada de host quando se põe de pé um novo endpoint Kentino AI.
3. O Pi-hole oferece gratuitamente um bloqueio de publicidade/telemetria para toda a rede, o que mantém o tráfego avulso de "telefonar para casa" dos fabricantes fora dos seus cabos.

DHCP por VLAN, configurado na firewall/router (UDM Pro Max, OPNsense e pfSense fazem-no todos com competência). Reservas para tudo o que interessa — robôs, servidores, APs, IPMI, switches, NAS. As pools dinâmicas são só para visitantes e estações de trabalho efémeras. Um robô que recebe um IP diferente a cada arranque é um robô cujos ficheiros de arranque do ROS 2 deixam de funcionar todas as terças-feiras.

Monitorização

Um laboratório sem monitorização é um laboratório onde os problemas são diagnosticados pelas suas consequências. Corra a pilha habitual no plano de gestão:

• Prometheus a recolher SNMPv3 dos switches, contadores das NIC (node_exporter), métricas de GPU (dcgm_exporter) e métricas do servidor de inferência (o vLLM expõe Prometheus nativamente).
• Grafana painéis: utilização por porta, débito por VLAN, temperatura e utilização das GPU, deriva PTP/NTP, disponibilidade da ligação dos robôs.
• Alertas que disparem mesmo: contador de pausas PFC > 0 em qualquer porta (significa que alguém está a congestionar RDMA, que não devia sequer existir nesta rede, mas verifique na mesma), temperatura de GPU > 80 °C, deriva temporal > 5 ms, anomalia na contagem de clientes de um AP.

SNMPv3, não v2c. O laboratório é suficientemente pequeno para que o trabalho adicional de configuração sejam quinze minutos e o ganho de segurança seja real.

BOM concreta — 1 servidor, 2 robôs, 4 estações de trabalho

Uma lista de compras realista e honestamente orçamentada para a implementação de referência, em EUR sem IVA a meio de 2026:

Para comparação: só o servidor Kentino AI de 8 GPU custa €40–70k e cada um dos dois humanoides €30–80k. A rede representa 5–10% do investimento total e é a parte com maior probabilidade de fazer a diferença entre um laboratório que funciona e um que não funciona.

Se o orçamento for apertado, os cortes credíveis são: baixar o switch de core para um MikroTik CRS504-4XQ-IN (4× QSFP28, com breakouts para 16× 25 GbE, ~€700) e aceitar o menor número de portas; usar um único AP se a área de trabalho for <60 m²; dispensar a fonte NTP por GPS e viver com o chrony através da WAN.

Erros mais comuns

Por ordem aproximada da frequência com que mordem:

• Misturar o tráfego de robótica com o Wi-Fi geral do escritório. A variação da latência destrói o comportamento reativo. A primeira correção em todas as chamadas do tipo "o meu robô está a falhar" é "dê-lhe um SSID próprio a 6 GHz".
• Buffers subdimensionados em switches baratos. Um switch 10G de 8 portas a €200 lida bem com dois dispositivos e colapsa quando quatro nós atacam o mesmo uplink. O tráfego de IA é irregular; os buffers do switch absorvem o pico. O switch de buffer profundo mais barato e credível deste artigo é o Aruba CX 6300 (buffer partilhado de 8/16/32 MB); o MikroTik CRS5xx é mais limitado, mas chega para um laboratório de servidor único.
• Sem mestre PTP, sem auditoria de NTP. A sincronização de tempo "funciona" até deixar de funcionar e, entretanto, a fusão de sensores falha em silêncio. Monitorize o desvio e configure alarmes.
• Orçamento PoE mal calculado. Um switch anuncia "PoE++" e depois descobre-se que o orçamento total é de 200 W, metade dos quais consumidos pelas câmaras de que ninguém o avisou, e o AP vai abaixo no arranque. Some as potências e deixe 30% de margem.
• Deixar o robô telefonar para casa. Atualização de firmware do fabricante numa manhã de terça-feira, que descarrega um novo modelo, que altera a latência de inferência a bordo, que estraga a sincronização da garra. Sempre. Bloqueie na firewall a saída WAN do robô; controle as atualizações manualmente.
• Nenhuma monitorização até algo falhar. O laboratório funciona bem durante seis meses. Depois, o AP começa a largar clientes duas vezes por dia e ninguém dá por isso durante uma semana porque não há painéis. Quando alguém vai investigar, mudaram outras quatro coisas e já ninguém consegue dizer o que falhou primeiro.

Opinião sem rodeios

A maioria dos laboratórios de robótica sobredimensiona a rede e subdimensiona as partes que interessam. Especificam-se backbones de 100 GbE para laboratórios de inferência com um único servidor e depois põe-se o robô no Wi-Fi do escritório. Compra-se um Cisco Catalyst 9300X com buffers profundos e depois corre-se L2 plano, sem qualquer segmentação em VLAN.

O desenho 80/20 para um laboratório de 2026 com um servidor e 1–4 robôs é pequeno e nada vistoso:

• 25 GbE entre o switch de core e o servidor Kentino AI. Uma NIC, um DAC e está feito.
• 10 GbE entre o core e o acesso. Dois DAC.
• Um switch de core, um switch de acesso, uma firewall, um ou dois APs.
• Seis VLAN, firewall com negação por omissão, SSID separados por função.
• NTP a partir de uma fonte local, monitorizado.
• Prometheus + Grafana numa pequena VM.

Investimento total em rede: abaixo de €7k. Tempo total de comissionamento: cerca de uma semana, se a cablagem estiver pronta. Isto sustenta um laboratório de produção a sério; o passo seguinte — backbone de 100 GbE, Clos encaminhado, switches de IA com buffer profundo — destina-se a treino em múltiplos servidores, que é o território de N04, N08e K02.

Isto faz parte da Kentino Wiki, uma série de referência sobre computação de IA, robótica e os sistemas que os ligam. Comentários e correções são bem-vindos em info@kentino.com.