Edge AI-arkitektur: Hvordan en robot kommunikerer med en lokal inferensserver

Hvis du køber en humanoid eller firbenet robot i 2026, er den enhed, du modtager, kun halvdelen af ​​systemet. Den anden halvdel er den computer, der kører de store modeller, som robotten selv ikke kan hoste. Denne artikel forklarer, hvad der rent faktisk bor hvor, hvorfor on-prem-stien overhovedet eksisterer, når cloud-API'er er billige, og hvordan de to halvdele er fysisk og logisk forbundet sammen.

Målgruppen er købere og integratorer, der ønsker et klart billede, før de underskriver en købsordre – ikke endnu ingeniører, der skriver limkoden.

Problemet med de to bokse

En moderne humanoid som Unitree G1 eller Booster T1 har et indlejret computermodul ombord: typisk en Jetson Orin (NX- eller AGX-klasse) eller en Snapdragon-klasse SoC, ofte parret med en lille dedikeret MCU til motorstyringssløjfen. Firbenede dyr som Unitree Go2 bruger et lignende layout i mindre skala.

Den indbyggede computer er nok til:

• Motorstyring i realtid — ledmoment, balance, gang. Dette kører ved 500 Hz til 1 kHz og kan ikke tolerere nogen netværkshopp. Det forbliver lokalt, punktum.
• Øjeblikkelige sikkerhedsreflekser — faldsikring, nødstop, kontaktrespons. Samme begrænsning, samme svar.
• Opfattelse med lav latenstid — dybde fra stereo eller RGB-D, IMU-fusion, grundlæggende objektdetektion (typisk en lille YOLO- eller MobileNet-variant).
• Stemmeaktivering og grundlæggende kommandorouting.

Hvad den indbyggede computer ikke med rimelighed kan køre:

• Store visionssprogsmodeller (VLM'er) som Qwen2.5-VL 72B, NVIDIA Cosmos, OpenVLA. Disse kræver snesevis af GB VRAM og er for strømkrævende til en batteridrevet platform.
• Store sprogmodeller (LLM'er) til dialog eller planlægning over den kvantiserede 7B-8B-klasse.
• Diffusionsbaserede eller autoregressive bevægelsesplanlæggere der opererer på hundredvis af millisekunders kontekst.
• Scenehukommelse og langhorisontopgavegrafer.

Denne opdeling er ikke Kentinos mening. Det er den faktiske opdeling, som alle troværdige humanoide platforme leveres med i dag. Det indbyggede modul er dimensioneret til sikkerhed og latenstid; den tunge tankegang går uden for kortet.

Det "off-board" mål kan være skyen (OpenAI, Anthropic, NVIDIA Cosmos hostet) eller en on-prem inferensserver. Resten af ​​denne artikel handler om, hvornår og hvorfor du ønsker on-prem-muligheden.

Hvad bor hvor — den praktiske opdeling

To-boks-opdelingen: lokal kontrol forbliver på robotten; tung inferens og træning går til den lokale server via LAN.

Tre ting at bemærke:

1. Robotten behøver ikke en GPU-server for at kunne gå. Hvis LAN-forbindelsen går ned, står enheden stadig oprejst, holder balancen og undgår at ramme væggen. Den eksterne pipeline tilføjer funktioner – sprog, planlægning, opgaver med lang horisont – den erstatter ikke lokal kontrol.
2. Nogle arbejdsbyrder kan forhandles. En lille VLM (f.eks. Qwen2.5-VL 7B kvantiseret) kan køre på en Jetson Orin AGX. Om du installerer den på kortet eller ej, er en handel med hensyn til effekt, termisk spænding og latenstid. Der er ikke ét rigtigt svar.
3. Serveren gør mere end at levere inferens. En seriøs implementering kører også træning (til finjustering til et specifikt miljø), simulering (Isaac Sim til policy-iteration) og scenehukommelse/hentning. "Inferensserver" er en forkortelse for "GPU-beregningsbackend".

Latensbudgettet

Det eneste tal, der afgør, om din arkitektur vil fungere, er tur-retur-tiden fra robotten til serveren og tilbage.

De tal, der dominerer budgettet, er serversidemodellens latenstid og (hvis du er trådløs) Wi-Fi-jitter. Selve transporten er sjældent flaskehalsen på et kablet LAN. Derfor bruger de fleste seriøse robotinstallationer en kablet tether eller et dedikeret Wi-Fi 6/6E AP inden for synsvidde af arbejdsområdet.

Hvis din robot skal besvare en verbal kommando på under et sekund, er regnestykket omtrent:

audio capture          ~ 50 ms
wake-word + STT        100–250 ms  (on-board or off-board, your choice)
LLM TTFT (planning)    200–500 ms  (server-side)
LLM stream 20 tokens   600–1200 ms
TTS                    100–300 ms
audio playout          ~ 50 ms
                       --------------
                       ~ 1.1 – 2.3 s

Der er ingen måde at nå "under et sekund end-to-end" med en 70B LLM i loopet i dag. Du accepterer enten latensen, bruger en mindre model on-prem (8B-13B klasse), eller deler responsen (bekræft med det samme, planlæg i baggrunden).

Det er den slags kompromis, der intet har at gøre med netværket, men alt at gøre med modelvalg. Det er også den slags kompromis, hvor det at have sin egen server er vigtigt: man kan bytte modeller, køre flere på én gang og lave forskellige batcher. Med en cloud-API tager man det, som udbyderen leverer.

Hvorfor overhovedet on-prem

Cloud-inferens er billig, skalerbar uden besvær og kræver nul kapitaludgifter. Så hvorfor skulle nogen købe en server med fire eller otte GPU'er, når en OpenAI API-nøgle koster halvtreds dollars?

Der er fire reelle grunde, i nogenlunde rækkefølge efter hvor ofte de rent faktisk driver beslutningen:

1. Data forlader ikke bygningen. Implementeringer inden for industri, forsvar, sundhedsvæsen og EU/GDPR-følsomme områder kan ofte ikke sende rå sensordata til en tredjeparts-cloud. Robotten ser en fabriksgulv, et patientværelse, en laboratoriebænk. Den video er enten privilegeret, reguleret eller konkurrencepræget. On-prem inferens løser dette problemfrit. Det gør skyen ikke.

2. Latensbund. Hvert cloud-opkald har en WAN RTT på 15-40 ms oven i modellatens. For de fleste robotopgaver er dette fint. For reaktiv kontrol i lukket kredsløb – pick-and-place med hastighed, balancegendannelse efter et push, finmanipulation – er WAN-gulvet for meget. On-prem bringer det under 1 ms.

3. Omkostninger ved vedvarende belastning. Et enkelt 70B VLM-opkald koster cloududbyderen næsten ingenting; de opkræver et par cent. Men en robot, der "altid tænker", foretager tusindvis af opkald i timen. Et forskningslaboratorium, der kører træning, og en flåde af robotter, der begge konkluderer mod de samme modeller, kan mætte $5,000-$15,000/måned i cloud-udgifter. En on-prem 4× eller 8× GPU-server tjener sig hjem på under tolv måneder med den belastning.

4. Modelvalg og tilpasning. Du vil finjustere en VLM til dit specifikke miljø. Du vil køre en model, som cloud-udbyderne ikke hoster. Du vil blande open-weight-modeller fra forskellige leverandører i en brugerdefineret pipeline. On-prem giver dig det. Cloud API'er gør det ikke.

Hvis ingen af ​​disse fire er vigtige for din implementering, bør du bruge skyen. Det ærlige svar er, at måske 30-40 % af robotkøbere faktisk har brug for on-prem; resten vælger det af prestige eller fordi deres indkøbsafdeling ikke er tryg ved skyen. Begge dele er også gyldige grunde, men vi vil ikke påstå andet.

Netværkstopologi

Netværkstopologi: robot på Wi-Fi 6E → dedikeret AP → 10 GbE switch → inferensserver. Udgang og WAN er valgfrie.

Et par praktiske noter, der overrasker folk:

• Wi-Fi 6E er gulvet, ikke loftet. 6 GHz-båndet er det eneste med ensartet lav latenstid i miljøer med andre enheder. Planlæg ét AP pr. ~50 m² robottens arbejdsområde, helst i synslinjen.
• Kablet er stadig bedre. Hvis robotten har en tether-mulighed (nogle humanoider på forskningsniveau har det, firbenede dyr har det normalt ikke), så brug den under udvikling. Udviklingsoplevelsen med LAN på under et millisekund er betydeligt bedre end at kæmpe mod Wi-Fi.
• Udgang er valgfri, men nyttig. Selv ved en fuldt on-prem implementering ønsker du normalt WAN-udgang til: opdatering af modeller, hentning af kortdata, trækning af NVIDIA NGC-containere, telemetri til din egen overvågning. Beskyt den tæt med en firewall; udsæt ikke robotten eller serveren for internettet.
• Tidssynkronisering er vigtig. Kør en lokal NTP-server. Sensorfusion og bevægelsesplanlægning afbrydes på diskrete måder, når urene bevæger sig hen over robotten, serveren og eventuelle hjælpeenheder i kanten.

Strøm og køling

En 4-GPU K-AI-server (4× RTX 5090 eller 4× RTX Pro 6000 Blackwell) bruger 1.8-2.4 kW vedvarende under belastning. En 8-GPU-server bruger 3.5-4.5 kW. Disse tal er ikke stationære computere; de ​​kræver 16 A kredsløb og korrekt rack-luftgennemstrømning.

For et robotlaboratorium er det omtrentlige budget:

Planlæg rummet før installationen, ikke efter. De fleste laboratorier, der "tilføjer GPU-beregning senere", ender med at udløse afbrydere i den første måned.

Luftgennemstrømningen er lige så vigtig som effekten. K-AI-serverne bruger industriel front-to-back rack-luftgennemstrømning med 120 mm blæsere og er eksplicit designet til vedvarende belastning døgnet rundt. De er ikke desktop tower-modeller, og de vil mætte et lille rums HVAC. Enten rack dem i et skab med dedikeret køling, eller placer dem i et separat rum og kør et 10 GbE-link.

Softwarestak — hvad der rent faktisk kører

Det er her implementeringen finder sted. Det overordnede billede:

Softwareopdeling: ROS 2 på robotten kommunikerer via gRPC til inferensserveren, der kører vLLM / SGLang.

Et par meningsfulde opfordringer:

• vLLM er standard serveringstakken til transformerbaserede VLM'er og LLM'er. Det er hurtigere end naiv HuggingFace-inferens og understøtter kontinuerlig batching og præfiks-caching. SGLang er et stærkt alternativ, hvis du bruger struktureret output eller agentlignende arbejdsgange.
• call.cpp er det rigtige svar, når du kører en lille model (7B-13B-klassen) på en GPU, som vLLM ikke elsker (f.eks. RTX 4090 med finurlig tensorparallelisme), eller på selve robotten.
• NVIDIA Triton er tungere at sætte op, men det er det rigtige valg, hvis du blander modeltyper (LLM + syn + tale) og ønsker ét serveringslag over dem alle.
• ROS 2 Ydmyg er lingua franca. Producentens SDK'er (Unitree, Booster, EngineAI) leverer ROS 2-wrappers. Byg din integration på ROS 2-siden, ikke producentens proprietære protokol, medmindre du har en specifik grund.

Et konkret eksempel

Forestil dig den enkleste og mest brugbare produktionsopsætning: én humanoid (Unitree G1), én inferensserver (K-AI 256 Turin Dual med 8× RTX 5090), én switch, ét AP, i et 30 m² laboratorium.

Hardware:
- Unitree G1 (one unit, ~1 kW charging draw)
- K-AI 256 Turin Dual / 8× RTX 5090 (sustained ~4 kW)
- 10 GbE switch (5 ports, ~30 W)
- Wi-Fi 6E AP (~15 W)
- 32 A three-phase or 2× 16 A single-phase circuit
- ~6 kW dedicated cooling (split AC)

Software on server:
- Ubuntu 22.04, CUDA 13, Docker
- vLLM serving Qwen2.5-VL 72B at INT4
- vLLM serving Qwen2.5 32B (text-only, for planning)
- pgvector for scene memory
- Isaac Sim for policy work
- Prometheus + Grafana

Software on robot:
- Unitree's ROS 2 driver
- Custom command-router ROS 2 node
- gRPC client to vLLM endpoints
- Local YOLO for fast obstacle detection

Dette er en reel, levedygtig arkitektur, som du kan købe og klare på to til tre uger. Det samlede budget for computersiden (server, netværk, el, køledelta) ligger i intervallet €60-€90 afhængigt af konfigurationen. Robotten er sin egen post.

For et forskningslaboratorium med 2-4 robotter skalerer den samme server – vLLM håndterer samtidige anmodninger fint, og flaskehalsen bliver enten GPU-hukommelse (hvis du vil hoste flere modeller samtidigt) eller strøm fra væggen.

Hvad går i stykker

Ærlig liste over fejltilstande, vi har set, i grov rækkefølge efter hvor ofte de bider:

• Wi-Fi-jitter under belastning. Et tidligere fint netværk bliver overbelastet, når en ny enhed tilsluttes, latenstiden stiger fra 5 ms til 80 ms, og robottens reaktive adfærd forringes. Rettelse: dedikeret SSID til robotteknologi, kun 6 GHz, AP med frit synsfelt.
• Modelbytte ødelægger systemet. Du opdaterer VLM'en, vLLM skal genindlæses, og robottens kommandopipeline får timeout. Rettelse: blå/grøn visning, to slutpunkter, skift et ad gangen.
• Serverens termiske drossel. Under vedvarende træning + inferens kan rummets klimaanlæg ikke følge med, og GPU'erne reduceres. Inferensforsinkelsen fordobles lydløst. Rettelse: størrelseskøling til 1.3× vedvarende, overvåg GPU-temperaturer, alarm ved 80 °C.
• Kabel-/stikfejl på robotsiden. Robotter vibrerer. Ledningstræthed. Planlæg for ét netværks- eller sensorkabelfejl pr. robot pr. kvartal på enheder med høj belastning. Gem reservedele.
• NVIDIA-driver/CUDA-versionsoverensstemmelse efter en apt-get-opgradering. Dette rammer alle præcis én gang. Fastgør din driverversion, brug containere, lad være apt-get dist-upgrade på en fungerende server.
• Urdrift mellem robot og server. Sensorens tidsstempler afviger med snesevis af millisekunder, sensorfusion producerer affald, ingen forstår hvorfor. Rettelse: lokal NTP, overvåg den, alarm ved afvigelse > 5 ms.

Ingen af ​​disse er katastrofale. Alle er forudsigelige, når man først har set dem én gang.

Når den lokale løsning er det forkerte svar

For at være ærlig: den lokale inferensserver er det forkerte svar, når —

• Din robot er udelukkende en fjernbetjent enhed, og din operatør sidder alligevel ved en cloud-arbejdsstation. Brug bare skyen.
• Du anvender en firbenet model til en udendørs inspektionsopgave, og der er ikke behov for store modelinferenser; den indbyggede beregning klarer jobbet.
• Dit modelfodaftryk passer faktisk til Jetson Orin AGX (50-70 W TDP), og dit latenstidsbudget tillader det ombord. Orin kan køre en 7B INT4 LLM med brugbar hastighed.
• Du kører en engangsdemo. Cloud-opsætning er hurtigere, billigere ved nul belastning, og du kan tage det ned på en eftermiddag.

On-prem-strategien er den rigtige, når implementeringen opretholdes, dataene er følsomme, latensbudgettet er stramt, eller behovet for tilpasning er reelt. Det meste seriøse robotarbejde i 2026 rammer mindst én af disse.

---

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.