Netværkstopologi til et robot- + AI-beregningslaboratorium

Et robotlaboratorium er ikke et kontor, ikke et datacenter og ikke et hjemmelaboratorium. Det er et lille, men usædvanligt krævende netværk: en håndfuld enheder med meget forskellige trafikprofiler, der alle deler den samme ledning. En humanoid streamer stereovideo til en inferensserver. En udviklingsarbejdsstation trækker et 70 GB modelcheckpoint. En firbenet går rundt og leder efter sin dock. En IPMI-port rapporterer stille og roligt en blæserhastighed.

Hvis du får forkert topologi, er symptomerne forfærdelige og indirekte: en robot hakker, når en kollega sender et Docker-billede; inferensserverens haleforsinkelse fordobles, når nogen opretter forbindelse til Wi-Fi'et; gradientsynkronisering til din finjusteringsboks ser på mystisk vis 200 ms spikes i frokostpausen. Hvis du får det rigtigt, forbliver netværket usynligt, hvilket er det eneste, du ønsker fra det.

Denne artikel handler om den rette form for det netværk i 2026. Målgruppe: integratorer og laboratoriebyggere, der præsenterer "laboratoriet i en kasse" - en til fire robotter, en eller to Kentino AI-inferensservere, et par udviklingsarbejdsstationer og de lager- og administrationselementer, der binder dem sammen. Ikke en hyperscaler-referencearkitektur. Ikke et budgetvenligt hjemmelaboratorium. Den faktiske midte.

Målet "laboratorium i en kasse"

Referenceimplementeringen for denne artikel:

• 1–4 robotter — humanoider, firbenede dyr eller en blanding. Wi-Fi 6E primær, valgfri kabelbaseret tether under udvikling.
• 1–2 Kentino AI-inferensservere — 4× eller 8× GPU (5090 / RTX Pro 6000 Blackwell), der kører vLLM / SGLang til VLM'er og LLM'er.
• 1–2 lager-/NAS-bokse — datasæt, checkpoints, registrerede sensorlogfiler. Normalt én ZFS-boks med NVMe-cache.
• 2–6 udvikler-arbejdsstationer — ingeniører, der kører ROS 2, Isaac Sim, træner finjusteringer, kopierer data rundt.
• Ledelsesplan — IPMI/BMC på alle servere, switche, AP'er og en lokal DNS/DHCP-vært.

I alt: 15-40 aktive netværksenheder. En enkelt switch kunne bære den elektriske forsyning. Grunden til, at der er to switche i designet nedenfor, er ikke kapacitet – det er fejldomænet, PoE-budgettet og ønsket om at holde robottrafik og GPU-trafik på forskellige fysiske ledninger, så den ene ikke kan sulte den anden.

Fysisk topologi

To fysiske switche, en firewall, en eller to AP'er. Kentino AI-servere lander på kernen ved 25 GbE; adgangsswitchen samler arbejdsstationer og AP'er; robotter forbinder via dedikeret 6 GHz SSID.

To fysiske switche, en firewall, et eller to AP'er. Kentino AI-serverne og storageboksen lander på core-switchen ved 25 GbE. Access-switchen opfanger de kablede, men langsommere enheder - arbejdsstationer, AP'er, IPMI, kameraer - og uplinker til kernen ved 10 GbE. Robotter kommer ind via Wi-Fi 6E på et dedikeret SSID.

Hvorfor 25 GbE mellem core og Kentino AI? Fordi ConnectX-6 Lx dual-port SFP28 NIC er det billigste og mest pålidelige kort i 2026 (€700-€900 på gaden, nogle gange mindre brugt), og 25 GbE er mere end nok til single-server inference fan-in. En 70B Q4-model streaming tokens til fire robotter på én gang ligger i området tiere af Mbit/s. En model checkpoint shuffle er dagens båndbreddebegivenhed, og 25 GbE rydder 100 GB på ~35 sekunder. Kunder, der kører multi-node træning, har brug for 100 GbE - dækket i N01 og N08 - men det er et andet netværk end det i denne artikel.

Hastighedsniveaustørrelse

To ting at internalisere:

• Du behøver ikke 100 GbE i et laboratorium med én server. Folk specificerer det, fordi databladet ser imponerende ud. Kentino AI-serverens faktiske vedvarende netværkshastighed er "tokens out" (Mbit/s) plus lejlighedsvise checkpoint shuffles (enkeltcifrede Gb/s). Ledningen er aldrig flaskehalsen i et inferensbaseret laboratorium.
• Wi-Fi er altid det langsomste hop. Planlæg omkring det. En god 6 GHz-forbindelse til en Wi-Fi 6E-klient får 1.2-1.8 Gb/s reel gennemstrømning ved 10 m synslinje, med 3-8 ms latenstid, jitter ±2 ms under rimelige forhold. Robotsensorstrømme (et eller to RGB-D-kameraer på 1080p30 hver) har brug for ~150-300 Mb/s vedvarende; du har masser af headroom - indtil en anden tilslutter sig SSID'et.

VLAN-segmentering

Grunden til, at dette netværk har seks VLAN'er, er ikke virksomhedshygiejne. Det er for at én enheds dårlige opførsel ikke skal ødelægge en andens dag.

Den opdeling, der rammer folk: robotter og Kentino AI er på forskellige VLAN'er, selvom de konstant kommunikerer med hinanden. Inter-VLAN-routing er firewallens/routerens opgave, og det er stedet, hvor man håndhæver, hvem-kan-tale-med-hvem. Hvis robotter og Kentino AI delte et VLAN, ville en kompromitteret robot (og forbruger-humanoider leveres med angrebsflade) have flad L2-adgang til GPU-serveren. Det er et hårdt "nej" i enhver halvseriøs implementering.

Den anden opdeling, der er værd at forsvare: administrationsplanet har sit eget VLAN, punktum. IPMI/BMC-grænseflader er blevet leveret med bagdøre fra leverandører i to årtier, og man bør antage, at de altid vil. De har deres eget subnet, deres egne adgangsregler, og ingen router til dem undtagen en administratorlaptop på administrations-VLAN'et.

Firewall regler

Standardafvisning mellem VLAN'er. Derefter undtagelser:

To opfattelsesværdige regler, der er værd at bemærke:

• Robotter får ingen adgang til internettet. Folk modsætter sig dette, fordi det forstyrrer producentens telemetri-/firmwareopdateringsflow. Godt. Hvidliste den specifikke producentopdateringsserver i et vedligeholdelsesvindue, og luk det derefter igen. Standardtilstanden er "denne robot kan ikke ringe hjem".
• Kentino AI WAN-udgang er on-demand. Åbn 443 under en modeldownload eller container pull. Ellers skal du holde den lukket. Inferensserveren har ikke noget at gøre med at surfe på nettet, og du ønsker ikke en nysgerrig udviklers curl scriptet er den sti, en orm bruger til at eksfiltrere dit datasæt.

Wi-Fi-opsætning

Den mest almindelige fejl i et robotlaboratoriums Wi-Fi-opbygning er "lad os bare sætte robotterne på kontorets SSID." Dette SSID deles med telefoner, bærbare computere, printere, et smart køleskab og tre personer på Teams-opkald. Variansen i latenstid er brutal, og robottens reaktive adfærd falder fra hinanden.

Det rigtige svar:

• Ét SSID pr. VLAN. "lab-robots" på VLAN 10, "lab-dev" på VLAN 30, "lab-guest" på VLAN 99. Administrations-VLAN'et har ingen trådløs tilstedeværelse.
• Robottens SSID er kun 6 GHz. Ingen 2.4 GHz, ingen 5 GHz-fallback. Ja, det betyder, at ældre enheder ikke kan tilsluttes – det er pointen. 6 GHz har dramatisk mindre konkurrence, fordi antallet af ældre enheder på den stort set er nul i 2026.
• Kanalbredde 80 MHz, ikke 160. 160 MHz ser bedre ud på databladet, men to 160 MHz AP'er i samme bygning kæmper mod hinanden. 80 MHz ved 6 GHz giver dig fire til seks rene kanaler og forudsigelig latenstid.
• Et AP pr. ~60-80 m² robottens arbejdsområde, hvis muligt i synslinje. Hvis laboratoriet har vægge, skal du tilføje et adgangspunkt. Roaming er fint på Wi-Fi 6E med 802.11r/k/v slået til, men en robot midt i en opgave sætter ikke pris på en roaminghændelse.
• Deaktiver fairness af airtime for robottens SSID. Standardindstillingen favoriserer langsommere klienter; du ønsker, at robotten, som er den eneste forbruger af det pågældende SSID, skal få alle airtime-slots.

For hardware i 2026: UniFi U6 Enterprise (Wi-Fi 6E, ~€450) eller den nyere U7 Pro / E7 (Wi-Fi 7, €189 / €499+) er de omkostningseffektive valg. Aruba 650-serien og Cisco Meraki MR-serien er alternativer i virksomhedsklassen til 2-3 gange prisen; administrationssystemet er bedre, og radioerne er bedre til høj klienttæthed, hvilket en implementering i et enkelt laboratorium med to robotter faktisk ikke har brug for.

Tidssynkronisering — PTP og NTP

Urdrift mellem robot og server afbryder sensorfusionen på subtile og pinlige måder. En 20 ms skævhed får en stereodybdepipeline til at producere spøgelsesobjekter. En 100 ms skævhed får manipulationsplanlæggeren til at tro, at griberen er et sted, hvor den ikke er.

To niveauer af løsning:

• NTP med chronyd mod en lokal stratum-1-server (en Raspberry Pi med en GPS-hat, ~€80 alt-i-et, eller firewallen, der fungerer som stratum-2). Opnår en nøjagtighed på ~1 ms på et kablet LAN, ~5-20 ms over Wi-Fi. Tilstrækkelig til det meste robotarbejde.
• PTP (IEEE 1588v2) med hardware-tidsstempling på switche, der understøtter det. MikroTik CRS3xx/CRS5xx-serien understøtter PTP-grænseur med synkronisering i nanosekundsområdet; Aruba CX 6300 og Cisco Catalyst håndterer det også. Når sub-mikrosekund på kabelbaserede stier, sub-millisekunder over Wi-Fi.

For 1-2 robotter er NTP fint. Kør chronyd På hver node, peg den mod den lokale master, overvåg offset, alarm ved >5 ms drift. For robotter på fire plus eller enhver implementering, der udfører multisensorfusion på tværs af maskiner, kør PTP på den kabelforbundne side og brug NTP som et reservepunkt. Uanset hvad, overvåg driftenAntallet af laboratorier, der "har tidssynkronisering", fordi de kørte apt install ntp en gang for to år siden er stort.

DNS, DHCP og IPAM

Lokal resolver på administrationsplanet, punktum. Pi-hole eller Unbound på en lille VM klarer jobbet. Årsagerne:

1. Robotter og inferensservere skal løse vllm.lab.local, nas.lab.localosv. uden en tur/retur til WAN'et.
2. Du ønsker ét sted at tilføje en værtspost, når du starter et nyt Kentino AI-slutpunkt.
3. Pi-hole giver dig en gratis netværksomfattende annonce-/telemetriblokering, som holder vildfaren producenttelefon-hjem-trafik væk fra dine ledninger.

DHCP pr. VLAN, konfigureret på firewall/router (UDM Pro Max, OPNsense, pfSense gør alle dette kompetent). Reservationer for alt, hvad der betyder noget - robotter, servere, AP'er, IPMI, switche, NAS. Dynamiske pools er kun for besøgende og kortvarige arbejdsstationer. En robot, der får en forskellig IP-adresse ved hver genstart, er en robot, hvis ROS 2-startfiler går i stykker hver tirsdag.

Overvågning

Et laboratorium uden overvågning er et laboratorium, hvor problemer diagnosticeres ud fra deres konsekvenser. Kør standardstakken på administrationsplanet:

• Prometheus scraping switch SNMPv3, NIC-tællere (node_exporter), GPU-målinger (dcgm_exporter), og inferensservermetrikker (vLLM eksponerer Prometheus nativt).
• grafana Dashboards: udnyttelse pr. port, gennemløb pr. VLAN, GPU-temperatur og -udnyttelse, PTP/NTP-drift, oppetid for robotforbindelse.
• Advarsler der rent faktisk aktiveres: PFC-pausetæller > 0 på en vilkårlig port (betyder, at nogen overbelaster RDMA, hvilket du ikke burde have på dette netværk, men tjek alligevel), GPU-temperatur > 80 °C, tidsdrift > 5 ms, AP-klientanomali.

SNMPv3, ikke v2c. Laboratoriet er lille nok til, at det marginale konfigurationsarbejde er femten minutter, og den marginale sikkerhed er reel.

Beton stykliste — 1 server, 2 robotter, 4 arbejdsstationer

En fungerende, ærligt prissat indkøbsliste til referenceimplementeringen, medio 2026 EUR ekskl. moms:

Til sammenligning: Kentino AI-serveren med 8 GPU'er koster alene €40-70, de to humanoider koster €30-80 hver. Netværket tegner sig for 5-10 % af de samlede udgifter, og det er den del, der sandsynligvis er forskellen mellem et laboratorium, der fungerer, og et, der ikke gør.

Hvis budgettet er stramt, er de mest troværdige løsninger: drop core-switchen til en MikroTik CRS504-4XQ-IN (4× QSFP28, breakouts til 16× 25 GbE, ~€700) og accepter det mindre antal porte; brug et enkelt AP, hvis arbejdsområdet er <60 m²; spring GPS NTP-kilden over og lev med chrony over WAN'et.

Almindelige fejl

I nogenlunde rækkefølge efter hvor ofte hver bid:

• Blander robottrafik med generel Wi-Fi på kontoret. Latensvarians dræber reaktiv adfærd. Den første løsning på ethvert "min robot er fejlagtig"-opkald er "giv den sit eget SSID på 6 GHz".
• For små buffere på billige switche. En 8-ports 10G-switch til €200 håndterer to enheder fint og falder over, når fire noder rammer den samme uplink. AI-trafikken er bursty; switchbuffere absorberer bursten. Den billigste troværdige deep-buffer-switch i denne artikel er Aruba CX 6300 (8/16/32 MB delt buffer); MikroTik CRS5xx er mere overfladisk, men tilstrækkelig til et laboratorium med én server.
• Ingen PTP-master, ingen NTP-revision. Tid synkroniserer "arbejde", indtil de ikke længere gør det, og sensorfusionen fejler lydløst ind imellem. Overvågningsforskydning og alarm.
• PoE-budgettet blev beregnet forkert. En switch reklamerer med "PoE++", og du opdager, at dens samlede budget er 200 W, hvoraf halvdelen forbruges af kameraer, som ingen har fortalt dig om, og AP-udfald ved opstart. Læg watttallene sammen, og lad 30 % headroom være tilbage.
• Robotten får lov til at ringe hjem. Producentens firmwareopdatering tirsdag morgen, som downloader en ny model, hvilket ændrer den indbyggede inferensforsinkelse, hvilket afbryder griberens timing. Hver gang. Firewall robottens WAN-udgang; kontrol opdateres manuelt.
• Ingen overvågning, før noget går i stykker. Laboratoriet fungerer fint i seks måneder. Så begynder AP'en at droppe klienter to gange om dagen, og ingen bemærker det i en uge, fordi der ikke er nogen dashboards. Når nogen først begynder at arbejde, har fire andre ting ændret sig, og ingen kan se, hvad der fejlede først.

Ærlig vurdering

De fleste robotlaboratorier overkonstruerer deres netværk og underkonstruerer de dele, der betyder noget. Folk specificerer 100 GbE-backbones til single-server-inferenslaboratorier og sætter derefter robotten på kontorets Wi-Fi. De køber en Cisco Catalyst 9300X med dybe buffere og kører derefter fladt L2 uden VLAN-segmentering.

80/20-designet til et laboratorium med én server og 1-4 robotter i 2026 er lille og usexet:

• 25 GbE mellem core-switchen og Kentino AI-serveren. Én NIC, én DAC, færdig.
• 10 GbE mellem kerne og adgang. To DAC'er.
• Én core-switch, én adgangsswitch, én firewall, et eller to AP'er.
• Seks VLAN'er, standard-afvisende firewall, separate SSID'er pr. rolle.
• NTP fra en lokal kilde, overvåget.
• Prometheus + Grafana på en lille VM.

Samlede netværksudgifter: under €7. Samlet idriftsættelsestid: cirka en uge, hvis kablerne er klar. Dette omfatter et rigtigt produktionslaboratorium; det næste trin op — 100 GbE backbone, routede Clos, deep-buffer AI-switche — er til multiservertræning, hvilket er N04 , N08 og K02 's område.

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.