Topologia sieci dla laboratorium robotyki i obliczeń AI

Laboratorium robotyki to nie biuro, nie centrum danych i nie domowy lab. To mała, ale wyjątkowo wymagająca sieć: garstka urządzeń o zupełnie różnych profilach ruchu współdzieli ten sam kabel. Humanoid strumieniuje obraz stereo do serwera inferencyjnego. Stacja robocza dewelopera pobiera 70 GB checkpointu modelu. Czworonóg krąży po sali, szukając swojej stacji dokującej. Port IPMI po cichu raportuje obroty wentylatora.

Przy źle dobranej topologii objawy są przykre i mylące: robot się zacina, gdy kolega wypycha obraz Dockera; opóźnienia ogonowe serwera inferencyjnego podwajają się, gdy ktoś podłącza się do Wi-Fi; synchronizacja gradientów z maszyną do dostrajania w porze lunchu w tajemniczy sposób notuje skoki po 200 ms. Przy dobrze dobranej topologii sieć pozostaje niewidoczna — a to jedyne, czego się od niej oczekuje.

Ten artykuł opisuje właściwy kształt takiej sieci w 2026 roku. Odbiorcy: integratorzy i budowniczowie laboratoriów stawiający „lab w pudełku” — od jednego do czterech robotów, jeden lub dwa serwery inferencyjne Kentino AI, kilka stacji roboczych oraz pamięć masowa i warstwa zarządzania, które to wszystko spinają. To nie jest architektura referencyjna hiperskalera. To nie jest budżetowy homelab. To rzeczywisty środek.

Cel: „lab w pudełku”

Wdrożenie referencyjne dla tego artykułu:

• 1–4 roboty — humanoidy, czworonogi lub ich mieszanka. Podstawowo Wi-Fi 6E, opcjonalnie przewód na czas prac deweloperskich.
• 1–2 serwery inferencyjne Kentino AI — 4× lub 8× GPU (5090 / RTX Pro 6000 Blackwell), z vLLM / SGLang dla modeli VLM i LLM.
• 1–2 maszyny storage / NAS — zbiory danych, checkpointy, nagrane logi z czujników. Zwykle jedna maszyna ZFS z pamięcią podręczną NVMe.
• 2–6 stacji roboczych — inżynierowie uruchamiają ROS 2 i Isaac Sim, trenują dostrojenia, przerzucają dane.
• Warstwa zarządzania — IPMI/BMC na każdym serwerze, przełączniki, punkty dostępowe, lokalny host DNS/DHCP.

Łącznie: 15–40 aktywnych urządzeń sieciowych. Elektrycznie uniósłby to jeden przełącznik. Dwa przełączniki w poniższym projekcie wynikają nie z przepustowości, lecz z domeny awarii, budżetu PoE i chęci rozdzielenia ruchu robotów i ruchu GPU na osobne fizyczne kable, tak aby jeden nie zagłodził drugiego.

Topologia fizyczna

Dwa przełączniki fizyczne, jeden firewall, jeden lub dwa punkty dostępowe. Serwery Kentino AI wpinają się do rdzenia na 25 GbE; przełącznik dostępowy agreguje stacje robocze i punkty dostępowe; roboty łączą się przez dedykowany SSID 6 GHz.

Dwa przełączniki fizyczne, jeden firewall, jeden lub dwa punkty dostępowe. Serwery Kentino AI i maszyna storage wpinają się do przełącznika rdzeniowego na 25 GbE. Przełącznik dostępowy zbiera urządzenia przewodowe, ale wolniejsze — stacje robocze, punkty dostępowe, IPMI, kamery — i łączy się z rdzeniem uplinkiem 10 GbE. Roboty wchodzą przez Wi-Fi 6E na dedykowanym SSID.

Dlaczego 25 GbE między rdzeniem a Kentino AI? Ponieważ dwuportowa karta SFP28 ConnectX-6 Lx to w 2026 roku najtańsza wiarygodna opcja (€700–€900 w detalu, czasem mniej z drugiej ręki), a 25 GbE z nadmiarem wystarcza do zbierania ruchu inferencyjnego jednego serwera. Model 70B w Q4 strumieniujący tokeny do czterech robotów naraz mieści się w dziesiątkach Mbit/s. Przerzucenie checkpointu modelu to największe zdarzenie pasmowe w ciągu dnia, a 25 GbE przenosi 100 GB w ~35 sekund. Klienci prowadzący trenowanie wielowęzłowe potrzebują 100 GbE — opisano to w N01 i N08 — ale to już inna sieć niż ta z tego artykułu.

Dobór prędkości łączy

Dwie rzeczy, które warto przyswoić:

• W laboratorium z jednym serwerem 100 GbE nie jest potrzebne. Ludzie je specyfikują, bo karta katalogowa robi wrażenie. Rzeczywiste, stałe obciążenie sieci przez serwer Kentino AI to „tokeny na wyjściu” (Mbit/s) plus okazjonalne przerzuty checkpointów (jednocyfrowe Gb/s). W laboratorium wyłącznie inferencyjnym kabel nigdy nie jest wąskim gardłem.
• Wi-Fi zawsze jest najwolniejszym odcinkiem. Trzeba to uwzględnić w projekcie. Dobre łącze 6 GHz do klienta Wi-Fi 6E daje realnie 1.2–1.8 Gb/s przy 10 m w linii wzroku, z opóźnieniem 3–8 ms i jitterem ±2 ms w przyzwoitych warunkach. Strumienie z czujników robota (jedna lub dwie kamery RGB-D po 1080p30) potrzebują stale ~150–300 Mb/s; zapasu jest sporo — dopóki do tego SSID nie podłączy się ktoś jeszcze.

Segmentacja VLAN

Sześć sieci VLAN nie wynika tu z korporacyjnej higieny. Chodzi o to, by nieprawidłowe zachowanie jednego urządzenia nie zepsuło dnia innemu.

Podział, który zaskakuje: roboty i Kentino AI są w różnych sieciach VLAN, choć nieustannie się ze sobą komunikują. Routing między VLAN-ami to zadanie firewalla/routera i właśnie tam egzekwuje się, kto z kim może rozmawiać. Gdyby roboty i Kentino AI dzieliły jedną sieć VLAN, przejęty robot (a konsumenckie humanoidy przychodzą z gotową powierzchnią ataku) miałby płaski dostęp L2 do serwera GPU. W każdym choć trochę poważnym wdrożeniu to zdecydowane „nie”.

Drugi podział wart obrony: warstwa zarządzania ma własną sieć VLAN, kropka. Interfejsy IPMI/BMC od dwóch dekad trafiają na rynek z furtkami producentów i należy zakładać, że tak już zostanie. Dostają własną podsieć, własne reguły dostępu i nikt do nich nie routuje poza laptopem administratora w sieci VLAN zarządzania.

Reguły firewalla

Domyślnie blokada ruchu między sieciami VLAN. Następnie wyjątki:

Dwie stanowcze reguły warte wyróżnienia:

• Roboty nie mają wyjścia do internetu. Ludzie się przed tym bronią, bo psuje to telemetrię producenta i aktualizacje firmware. I dobrze. Serwer aktualizacji producenta wpuszcza się na białą listę na czas okna serwisowego, a potem zamyka ponownie. Stan domyślny brzmi: „ten robot nie zadzwoni do domu”.
• Wyjście Kentino AI do WAN jest otwierane na żądanie. Na czas pobierania modelu lub obrazu kontenera otwiera się port 443. Poza tym pozostaje zamknięty. Serwer inferencyjny nie ma czego szukać w sieci, a skrypt curl ciekawskiego dewelopera nie powinien stać się drogą, którą robak wyniesie zbiór danych.

Konfiguracja Wi-Fi

Najczęstszy błąd przy budowie Wi-Fi w laboratorium robotyki brzmi: „wrzućmy roboty na biurowy SSID”. Ten SSID dzielą telefony, laptopy, drukarki, inteligentna lodówka i trzy osoby na rozmowach w Teams. Rozrzut opóźnień jest brutalny, a reaktywne zachowania robota się rozsypują.

Właściwa odpowiedź:

• Jeden SSID na sieć VLAN. „lab-robots” w VLAN 10, „lab-dev” w VLAN 30, „lab-guest” w VLAN 99. Sieć VLAN zarządzania nie ma obecności bezprzewodowej.
• SSID dla robotyki działa wyłącznie w 6 GHz. Bez 2.4 GHz, bez awaryjnego 5 GHz. Tak, starsze urządzenia się nie podłączą — o to właśnie chodzi. W paśmie 6 GHz rywalizacja o medium jest nieporównanie mniejsza, bo populacja starszych urządzeń jest w 2026 roku praktycznie zerowa.
• Szerokość kanału 80 MHz, nie 160. 160 MHz wygląda lepiej w karcie katalogowej, ale dwa punkty dostępowe po 160 MHz w jednym budynku depczą sobie po piętach. 80 MHz w paśmie 6 GHz daje od czterech do sześciu czystych kanałów i przewidywalne opóźnienia.
• Jeden punkt dostępowy na ~60–80 m² obszaru pracy robota, w miarę możliwości w linii wzroku. Jeśli laboratorium ma ściany, trzeba dołożyć punkt dostępowy. Roaming w Wi-Fi 6E z włączonym 802.11r/k/v działa dobrze, ale robot w trakcie zadania nie przepada za przełączeniem między punktami.
• Dla SSID robotów należy wyłączyć airtime fairness. Ustawienie domyślne faworyzuje wolniejszych klientów, a tu chodzi o to, by robot — jedyny użytkownik tego SSID — dostawał każdy slot czasu antenowego.

Sprzęt na 2026 rok: UniFi U6 Enterprise (Wi-Fi 6E, ~€450) albo nowsze U7 Pro / E7 (Wi-Fi 7, €189 / €499+) to rozsądne cenowo wybory. Seria Aruba 650 i Cisco Meraki MR to alternatywy klasy enterprise za 2–3× wyższą cenę; warstwa zarządzania jest przyjemniejsza, a radia lepiej znoszą duże zagęszczenie klientów — a żadna z tych rzeczy nie jest w jednym laboratorium z dwoma robotami naprawdę potrzebna.

Synchronizacja czasu — PTP i NTP

Dryf zegara między robotem a serwerem psuje fuzję danych z czujników w sposób subtelny i żenujący. Przesunięcie 20 ms sprawia, że potok głębi stereo tworzy obiekty widma. Przesunięcie 100 ms powoduje, że planer manipulacji sądzi, iż chwytak jest gdzie indziej, niż jest naprawdę.

Dwa poziomy rozwiązania:

• NTP z chronyd wobec lokalnego serwera stratum-1 (Raspberry Pi z nakładką GPS, ~€80 z wszystkim, albo firewall w roli stratum-2). Osiąga dokładność ~1 ms w przewodowej sieci LAN i ~5–20 ms przez Wi-Fi. Wystarczające do większości prac w robotyce.
• PTP (IEEE 1588v2) ze sprzętowym znakowaniem czasu na przełącznikach, które to obsługują. Serie MikroTik CRS3xx/CRS5xx wspierają PTP boundary clock z synchronizacją rzędu nanosekund; radzą sobie z tym również Aruba CX 6300 i Cisco Catalyst. Na ścieżkach przewodowych osiąga poniżej mikrosekundy, przez Wi-Fi poniżej milisekundy.

Przy 1–2 robotach NTP w zupełności wystarczy. Na każdym węźle warto uruchomić chronyd, skierować go na lokalny serwer nadrzędny, monitorować offset i alarmować przy dryfie >5 ms. Przy czterech i więcej robotach lub przy fuzji wielu czujników między maszynami należy uruchomić PTP po stronie przewodowej, a NTP zostawić jako rozwiązanie awaryjne. Tak czy inaczej — trzeba monitorować dryf. Laboratoriów, które „mają synchronizację czasu”, bo dwa lata temu ktoś raz uruchomił apt install ntp, jest bardzo dużo.

DNS, DHCP i IPAM

Lokalny resolver w warstwie zarządzania, bez dyskusji. Pi-hole albo Unbound na małej maszynie wirtualnej w zupełności wystarczy. Powody:

1. Roboty i serwery inferencyjne muszą rozwiązywać vllm.lab.local, nas.lab.local itd. bez wycieczki do sieci WAN.
2. Przy uruchamianiu nowego punktu końcowego Kentino AI wpis w hostach powinno się dodawać w jednym miejscu.
3. Pi-hole daje za darmo blokadę reklam i telemetrii w całej sieci, co trzyma z dala od kabli błąkający się ruch producentów dzwoniących do domu.

DHCP osobno dla każdej sieci VLAN, skonfigurowany na firewallu/routerze (UDM Pro Max, OPNsense i pfSense robią to kompetentnie). Rezerwacje dla wszystkiego, co istotne — roboty, serwery, punkty dostępowe, IPMI, przełączniki, NAS. Pule dynamiczne są wyłącznie dla gości i tymczasowych stacji roboczych. Robot, który po każdym restarcie dostaje inny adres IP, to robot, którego pliki startowe ROS 2 psują się w każdy wtorek.

Monitorowanie

Laboratorium bez monitoringu to laboratorium, w którym problemy diagnozuje się po skutkach. W warstwie zarządzania warto uruchomić standardowy zestaw:

• Prometheus zbierający SNMPv3 z przełączników, liczniki kart sieciowych (node_exporter), metryki GPU (dcgm_exporter) i metryki serwera inferencyjnego (vLLM udostępnia Prometheusa natywnie).
• Grafana z pulpitami: wykorzystanie poszczególnych portów, przepustowość w podziale na sieci VLAN, temperatura i obciążenie GPU, dryf PTP/NTP, dostępność łączności robotów.
• Alerty, które naprawdę się odzywają: licznik pauz PFC > 0 na dowolnym porcie (oznacza, że ktoś zapycha RDMA, którego w tej sieci być nie powinno, ale i tak warto sprawdzić), temperatura GPU > 80 °C, dryf czasu > 5 ms, anomalia w liczbie klientów punktu dostępowego.

SNMPv3, nie v2c. Laboratorium jest na tyle małe, że dodatkowa konfiguracja zajmuje piętnaście minut, a zysk bezpieczeństwa jest realny.

Konkretny BOM — 1 serwer, 2 roboty, 4 stacje robocze

Działająca, uczciwie wyceniona lista zakupów dla wdrożenia referencyjnego, ceny w EUR bez VAT, połowa 2026 roku:

Dla porównania: sam serwer Kentino AI z 8 GPU to €40–70k, a każdy z dwóch humanoidów €30–80k. Sieć stanowi 5–10% całego wydatku i jest tym elementem, który najczęściej decyduje o tym, czy laboratorium działa, czy nie.

Przy napiętym budżecie wiarygodne cięcia wyglądają tak: zejść z przełącznikiem rdzeniowym do MikroTik CRS504-4XQ-IN (4× QSFP28, rozdzielenie do 16× 25 GbE, ~€700) i pogodzić się z mniejszą liczbą portów; przy obszarze pracy <60 m² zostawić jeden punkt dostępowy; zrezygnować ze źródła NTP z GPS i poprzestać na chrony przez WAN.

Najczęstsze wpadki

Mniej więcej w kolejności tego, jak często dają się we znaki:

• Mieszanie ruchu robotyki z ogólnym biurowym Wi-Fi. Rozrzut opóźnień zabija zachowania reaktywne. Pierwsza rada przy każdym zgłoszeniu „mój robot się zacina” brzmi: „proszę dać mu własny SSID w paśmie 6 GHz”.
• Za małe bufory na tanich przełącznikach. Ośmioportowy przełącznik 10G za €200 bez problemu obsłuży dwa urządzenia i polegnie, gdy cztery węzły uderzą w ten sam uplink. Ruch AI jest skokowy, a bufory przełącznika pochłaniają te skoki. Najtańszym wiarygodnym przełącznikiem z głębokimi buforami w tym artykule jest Aruba CX 6300 (bufor współdzielony 8/16/32 MB); MikroTik CRS5xx ma płytsze bufory, ale do laboratorium z jednym serwerem to wystarczy.
• Brak serwera nadrzędnego PTP, brak audytu NTP. Synchronizacja czasu „działa”, dopóki nie przestanie, a fuzja czujników po cichu zawodzi w międzyczasie. Trzeba monitorować offset i alarmować.
• Źle policzony budżet PoE. Przełącznik reklamuje się jako „PoE++”, a potem okazuje się, że jego łączny budżet to 200 W, z czego połowę zjadają kamery, o których nikt nie wspomniał, i punkt dostępowy przygasa przy starcie. Trzeba zsumować moce i zostawić 30% zapasu.
• Robot z prawem dzwonienia do domu. We wtorek rano aktualizacja firmware od producenta, która pobiera nowy model, który zmienia opóźnienie inferencji na pokładzie, co psuje czasy pracy chwytaka. Za każdym razem. Wyjście robota do WAN trzeba zablokować na firewallu, a aktualizacje kontrolować ręcznie.
• Brak monitoringu do czasu awarii. Laboratorium działa bez zarzutu przez pół roku. Potem punkt dostępowy zaczyna dwa razy dziennie zrywać połączenia i przez tydzień nikt tego nie zauważa, bo nie ma żadnych pulpitów. Zanim ktoś się w to wgryzie, zmieniają się cztery inne rzeczy i nie sposób ustalić, co zawiodło pierwsze.

Szczerze mówiąc

Większość laboratoriów robotyki przeinwestowuje w sieć i niedoinwestowuje to, co naprawdę się liczy. Ludzie specyfikują szkielety 100 GbE do laboratoriów inferencyjnych z jednym serwerem, a potem wrzucają robota na biurowe Wi-Fi. Kupują Cisco Catalyst 9300X z głębokimi buforami, a potem pracują na płaskiej warstwie L2 bez żadnej segmentacji VLAN.

Projekt w zasadzie 80/20 dla laboratorium z 2026 roku, jednym serwerem i 1–4 robotami, jest mały i nieefektowny:

• 25 GbE między przełącznikiem rdzeniowym a serwerem Kentino AI. Jedna karta sieciowa, jeden DAC i gotowe.
• 10 GbE między rdzeniem a warstwą dostępową. Dwa kable DAC.
• Jeden przełącznik rdzeniowy, jeden dostępowy, jeden firewall, jeden lub dwa punkty dostępowe.
• Sześć sieci VLAN, firewall z domyślną blokadą, osobne SSID dla każdej roli.
• NTP z lokalnego źródła, monitorowane.
• Prometheus i Grafana na małej maszynie wirtualnej.

Łączny wydatek na sieć: poniżej €7k. Czas uruchomienia: około tygodnia, jeśli okablowanie jest gotowe. To udźwignie prawdziwe laboratorium produkcyjne; kolejny poziom — szkielet 100 GbE, routowana topologia Clos, przełączniki AI z głębokimi buforami — dotyczy trenowania wielowęzłowego, czyli terytorium artykułów N04, N08 i K02.

To część Kentino Wiki — serii referencyjnej o infrastrukturze obliczeniowej AI, robotyce i systemach, które je łączą. Uwagi i sprostowania prosimy kierować na adres info@kentino.com.