Architektúra Edge AI: Ako robot komunikuje s lokálnym inferenčným serverom
Ak si v roku 2026 kupujete humanoidného alebo štvornohého robota, jednotka, ktorú dostanete, je len polovica systému. Druhá polovica je výpočtový systém, ktorý spúšťa veľké modely, ktoré samotný robot nemôže hostiť. Tento článok vysvetľuje, čo sa kde vlastne nachádza, prečo vôbec existuje lokálna cesta, keď sú cloudové API lacné, a ako sú tieto dve polovice fyzicky a logicky prepojené.
Publikum tvoria kupujúci a integrátori, ktorí chcú mať jasný obraz pred podpísaním objednávky – ešte nie inžinieri píšuci základný kód.
Problém dvoch boxov
Moderný humanoid ako Unitree G1 alebo Booster T1 nesie na palube zabudovaný výpočtový modul: zvyčajne Jetson Orin (trieda NX alebo AGX) alebo SoC triedy Snapdragon, často spárovaný s malým vyhradeným MCU pre riadiacu slučku motora. Štvornožce ako Unitree Go2 používajú podobné rozloženie v menšom meradle.
Tento integrovaný výpočtový výkon stačí na:
- Riadenie motora v reálnom čase — krútiaci moment kĺbov, rovnováha, chôdza. Toto funguje na frekvencii 500 Hz až 1 kHz a netoleruje žiadne sieťové skoky. Zostáva lokálne a bodka.
- Okamžité bezpečnostné reflexy — ochrana proti pádu, núdzové zastavenie, reakcia na kontakt. Rovnaké obmedzenie, rovnaká odpoveď.
- Vnímanie s nízkou latenciou — hĺbka zo sterea alebo RGB-D, fúzia IMU, základná detekcia objektov (zvyčajne malý variant YOLO alebo MobileNet).
- Hlasové budenie a základné smerovanie príkazov.
Čo palubný počítač nedokáže rozumne spustiť:
- Veľké modely vizuálneho jazyka (VLM) ako Qwen2.5-VL 72B, NVIDIA Cosmos, OpenVLA. Tieto potrebujú desiatky GB VRAM a sú príliš náročné na energiu pre platformu napájanú z batérie.
- Veľké jazykové modely (LLM) pre dialóg alebo plánovanie nad triedou 7B–8B kvantovanou.
- Plánovače pohybu založené na difúzii alebo autoregresívne plánovače pohybu ktoré fungujú na základe stoviek milisekúnd kontextu.
- Pamäť scény a grafy úloh s dlhým horizontom.
Toto rozdelenie nie je názorom spoločnosti Kentino. Je to skutočný rozdelenie, s ktorým sa dnes dodáva každá dôveryhodná humanoidná platforma. Integrovaný modul je dimenzovaný pre bezpečnosť a latenciu; ťažké myslenie sa deje mimo paluby.
Cieľom „mimo paluby“ môže byť cloud (hostovaný na OpenAI, Anthropic, NVIDIA Cosmos) alebo lokálny inferenčný server. Zvyšok tohto článku sa venuje tomu, kedy a prečo chcete lokálnu možnosť.
Čo kde žije – praktické rozdelenie
- Riadiaca slučka 500 Hz – 1 kHz
- Lokálne bezpečnostné reflexy
- Hĺbka stereo / RGB-D
- Ľahký YOLO / MobileNet
- Fúzia IMU + senzorov
- Budiace slovo, smerovanie príkazov
- Lokálny mikrofón, reproduktor
- Správa batérie
- VLM — Qwen2.5-VL, Cosmos, OpenVLA
- Dialóg a plánovanie v LLM (70B+)
- Plánovač pohybu / trajektórie
- Pamäť scény / RAG
- Školenie — LoRA, RLHF
- Simulácia — Isaac Sim
Rozdelenie na dve oblasti: lokálne riadenie zostáva na robotovi; ťažká inferencia a trénovanie idú na lokálny server cez LAN.
Tri veci, ktoré si treba všimnúť:
- Robot na chôdzu nepotrebuje GPU server. Ak dôjde k výpadku siete LAN, jednotka stále stojí, drží rovnováhu a vyhýba sa nárazu do steny. Externý kanál pridáva možnosti – jazyk, plánovanie, úlohy s dlhým horizontom – nenahrádza lokálne riadenie.
- Niektoré pracovné zaťaženia sú dohodou. Malý VLM (napr. kvantizovaný Qwen2.5-VL 7B) môže bežať na Jetson Orin AGX. Či ho zapojíte do integrovaného obvodu alebo mimo neho, je vecou z hľadiska výkonu, teploty a latencie. Neexistuje jedna správna odpoveď.
- Server robí viac než len obsluhuje inferenciu. Vážne nasadenie spúšťa aj tréning (pre doladenie špecifického prostredia), simuláciu (Isaac Sim pre iteráciu politík) a pamäť/načítanie scén. „Inferenčný server“ je skratka pre „GPU compute backend“.
Rozpočet latencie
Jediné číslo, ktoré určuje, či vaša architektúra bude fungovať, je čas prenosu z robota na server a späť.
| hop | Typická latencia |
|---|---|
| Integrovaná inferencia YOLO (Jetson Orin AGX) | 8 - 15 ms |
| LAN (káblové pripojenie 2.5/10 GbE) obojsmerne | 0.2 - 0.5 ms |
| Wi-Fi 6 tam a späť (v dobrom stave) | 3–10 ms (chvenie) |
| Inferencia VLM na strane servera (Qwen2.5-VL 72B) | 200–800 ms TTFT |
| Generovanie tokenov LLM na strane servera (70B Q4) | 30–80 ms/token |
| WAN do cloudu (v rámci EÚ) | 15–40 ms RTT |
| WAN do cloudu (transatlantický) | 80–120 ms RTT |
Čísla, ktoré dominujú rozpočtu, sú latencia modelu na strane servera a (ak používate bezdrôtové pripojenie) chvenie Wi-Fi. Samotný prenos je v káblovej lokálnej sieti LAN zriedkavo úzkym hrdlom. Preto väčšina serióznych inštalácií robotov používa káblové pripojenie alebo vyhradený prístupový bod Wi-Fi 6/6E v priamej viditeľnosti pracovnej oblasti.
Ak váš robot musí odpovedať na slovný príkaz za menej ako jednu sekundu, matematika vyzerá zhruba takto:
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
V súčasnosti neexistuje spôsob, ako dosiahnuť „kratšiu dobu prenosu ako jedna sekunda“ s 70B LLM v slučke. Buď akceptujete latenciu, použijete menší model lokálne (trieda 8B–13B), alebo rozdelíte odozvu (okamžité potvrdenie, plánovanie na pozadí).
Toto je druh kompromisu, ktorý nemá nič spoločné so sieťou, ale súvisí s výberom modelu. Je to tiež druh kompromisu, pri ktorom je dôležité mať vlastný server: môžete si vymieňať modely, spúšťať viacero naraz, dávkovať rôzne. S cloudovým API si beriete to, čo poskytuje poskytovateľ.
Prečo vôbec lokálne
Cloudová inferencia je lacná, bez námahy sa škáluje a nevyžaduje žiadne kapitálové výdavky. Prečo by si teda niekto kupoval server so štyrmi alebo ôsmimi grafickými procesormi, keď kľúč OpenAI API stojí päťdesiat dolárov?
Existujú štyri skutočné dôvody, zhruba v poradí, ako často v skutočnosti ovplyvňujú rozhodnutie:
1. Dáta neopúšťajú budovu. Priemyselné, obranné, zdravotnícke a nasadenia citlivé na EÚ/GDPR často nedokážu posielať surové dáta zo senzorov do cloudu tretej strany. Robot vidí výrobnú halu, izbu pacienta, laboratórny stôl. Toto video je buď privilegované, regulované alebo konkurenčné. Lokálna inferencia to rieši jasne. Cloud to nerobí.
2. Latenčná spodná hranica. Každé cloudové volanie má okrem latencie modelu aj WAN RTT 15 – 40 ms. Pre väčšinu robotických úloh je to v poriadku. Pre reaktívne riadenie v uzavretej slučke – rýchle umiestnenie, obnovenie rovnováhy po zatlačení, jemná manipulácia – je WAN podlaha príliš vysoká. On-premise systém ju znižuje pod 1 ms.
3. Náklady pri trvalom zaťažení. Jediný 70B VLM hovor nestojí poskytovateľa cloudu takmer nič; účtuje si od vás pár centov. Ale robot, ktorý „stále premýšľa“, vykoná tisíce hovorov za hodinu. Výskumné laboratórium, ktoré vykonáva školenia, a flotila robotov, ktoré obaja vyvodzujú výsledky z rovnakých modelov, môžu mesačne vynaložiť 5 000 až 15 000 dolárov na cloud. Lokálny server so 4× alebo 8× GPU sa pri tomto zaťažení vráti za menej ako dvanásť mesiacov.
4. Výber a prispôsobenie modelu. Chcete doladiť VLM vo vašom konkrétnom prostredí. Chcete spustiť model, ktorý poskytovatelia cloudu nehosťujú. Chcete kombinovať modely s otvorenou váhou od rôznych dodávateľov vo vlastnom kanáli. On-premise vám to poskytuje. Cloudové API nie.
Ak žiadna z týchto štyroch možností nie je pre vaše nasadenie dôležitá, mali by ste použiť cloud. Úprimná odpoveď je, že asi 30 – 40 % kupujúcich robotiky skutočne potrebuje lokálne riešenia; zvyšok si ich vyberá kvôli prestíži alebo preto, že ich obstarávacia kancelária nemá s cloudom problém. Oba sú tiež platné dôvody, ale nebudeme predstierať opak.
Topológia siete
1 AP / ~50 m²
káblové 10 GbE
Topológia siete: robot na Wi-Fi 6E → vyhradený prístupový bod → 10 GbE prepínač → inferenčný server. Výstup a WAN sú voliteľné.
Niekoľko praktických poznámok, ktoré ľudí prekvapia:
- Wi-Fi 6E je podlaha, nie strop. Pásmo 6 GHz je jediné s konzistentne nízkou latenciou v prostrediach s inými zariadeniami. Naplánujte jeden prístupový bod na približne 50 m² pracovnej plochy robota, pokiaľ je to možné v priamej viditeľnosti.
- Káblové je stále lepšie. Ak má robot možnosť pripojenia (niektorí humanoidi na výskumnej úrovni ju majú, štvornožci zvyčajne nie), použite ju počas vývoja. Vývojový zážitok s lokálnou sieťou LAN s frekvenciou menšou ako milisekundovou frekvenciou je výrazne príjemnejší ako boj s Wi-Fi.
- Výstup je voliteľný, ale užitočný. Aj pri plne lokálnom nasadení zvyčajne potrebujete WAN výstup na: aktualizáciu modelov, načítanie mapových údajov, sťahovanie kontajnerov NVIDIA NGC, telemetriu do vášho vlastného monitorovania. Nainštalujte prísny firewall; nevystavujte robota ani server internetu.
- Synchronizácia času je dôležitá. Spustite lokálny NTP server. Fúzia senzorov a plánovanie pohybu sa nenápadne prerušia, keď sa hodiny v robote, serveri a akýchkoľvek pomocných zariadeniach na okraji siete menia.
Napájanie a chladenie
Server K-AI so 4 grafickými kartami (4× RTX 5090 alebo 4× RTX Pro 6000 Blackwell) odoberá pri zaťažení trvalo 1.8 – 2.4 kW. Server s 8 grafickými kartami odoberá 3.5 – 4.5 kW. Toto nie sú čísla pre stolné počítače; potrebujú obvody s prúdom 16 A a správne prúdenie vzduchu v racku.
Približný rozpočet robotického laboratória je:
| Položka | Trvalý výkon |
|---|---|
| Humanoidný robot (nabíjacia stanica) | 0.5–1.5 kW |
| Štvornohý robot (nabíjacia stanica) | 0.2–0.5 kW |
| 4-GPU K-AI server | 1.8–2.4 kW |
| 8-GPU K-AI server | 3.5–4.5 kW |
| Sieťové zariadenia (prepínače, prístupové body) | 50 – 150 W |
| Chladenie (klimatizácia v miestnosti nad hlavou pre vyššie uvedené) | ~30 % z celkovej sumy |
Naplánujte si miestnosť pred inštaláciou, nie po nej. Väčšina laboratórií, ktoré „pridali výpočty na GPU neskôr“, nakoniec vypne ističe už v prvom mesiaci.
Prúdenie vzduchu je rovnako dôležité ako výkon. Servery K-AI využívajú priemyselné prúdenie vzduchu do racku spredu dozadu so 120 mm ventilátormi a sú výslovne navrhnuté pre nepretržitú záťaž 24 hodín denne, 7 dní v týždni. Nie sú to stolové vežové konštrukcie a preťažia vykurovanie, vetranie a klimatizáciu malej miestnosti. Buď ich umiestnite do skrine so samostatným chladením, alebo ich umiestnite do samostatnej miestnosti a spustite 10 GbE pripojenie.
Softvérový stack – čo vlastne beží
Tu sa nachádza implementácia. Obrázok na vysokej úrovni:
Ubuntu 22.04 + ROS 2 Humble
- Uzly ROS 2: vnímanie, riadenie, smerovač príkazov
- Lokálne odľahčené modely (YOLO, MobileNet, wake-word)
- gRPC klient k inferenčnému serveru
- SDK výrobcu (Unitree, Booster, EngineAI)
Ubuntu 22.04 + CUDA 12.x / 13.x
- Inferencia: vLLM, SGLang, llama.cpp alebo NVIDIA Triton
- Váhy modelov VLM / LLM (HuggingFace, NGC, interné)
- Úložisko pamäte scén: ChromaDB alebo pgvector
- Voliteľné školenia: PyTorch, accelerator, peft, Isaac Sim
- Monitorovanie: Prometheus, Grafana (latencia, využitie GPU, hĺbka frontu)
Rozdelenie softvéru: ROS 2 na robotovi komunikuje cez gRPC s inferenčným serverom, na ktorom beží vLLM / SGLang.
Pár názorových výziev:
- vLLM je predvolený obslužný zásobník pre VLM a LLM založené na transformátoroch. Je rýchlejší ako naivná inferencia HuggingFace a podporuje kontinuálne dávkovanie a ukladanie prefixov do vyrovnávacej pamäte. SGLang je silnou alternatívou, ak vytvárate štruktúrovaný výstup alebo pracovné postupy v štýle agentov.
- call.cpp je správna odpoveď, keď spúšťate malý model (trieda 7B–13B) na GPU, ktorú vLLM nemá rád (napr. RTX 4090 s nepredvídateľným tenzorovým paralelizmom), alebo na samotnom robotovi.
- NVIDIA Triton Je náročnejšie na nastavenie, ale je to správne rozhodnutie, ak kombinujete typy modelov (LLM + vízia + reč) a chcete nad nimi všetkými jednu obslužnú vrstvu.
- ROS 2 Humble je lingua franca. Výrobcovské SDK (Unitree, Booster, EngineAI) dodávajú obalovacie súbory ROS 2. Pokiaľ na to nemáte konkrétny dôvod, vytvorte si integráciu na strane ROS 2, nie na proprietárnom protokole výrobcu.
Konkrétny príklad
Predstavte si najjednoduchšie realizovateľné nastavenie produkcie: jeden humanoid (Unitree G1), jeden inferenčný server (K-AI 256 Turin Dual s 8× RTX 5090), jeden switch, jeden AP, v laboratóriu s rozlohou 30 m².
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
Ide o skutočnú a životaschopnú architektúru, ktorú si môžete kúpiť a uviesť do prevádzky za dva až tri týždne. Celkový rozpočet na výpočtovú časť (server, sieť, elektrika, chladenie) sa pohybuje v rozmedzí 60 000 až 90 000 eur v závislosti od konfigurácie. Robot je samostatnou položkou.
Pre výskumné laboratórium s 2–4 robotmi sa ten istý server škáluje – vLLM bez problémov zvláda súbežné požiadavky a úzkym hrdlom sa stáva buď pamäť GPU (ak chcete hostiť viac modelov súčasne), alebo napájanie zo siete.
Čo sa zlomí
Úprimný zoznam spôsobov zlyhania, ktoré sme videli, v zhrubam poradí, ako často sa prejavujú:
- Chvenie Wi-Fi pri zaťažení. Predtým bezproblémová sieť sa preťaží, keď sa pripojí nové zariadenie, latencia sa zvýši z 5 ms na 80 ms a reaktívne správanie robota sa zhorší. Oprava: vyhradené SSID pre robotiku, iba 6 GHz, prístupový bod v priamom dosahu.
- Výmena modelu vyradí systém z prevádzky. Aktualizujete VLM, vLLM sa musí znova načítať, časový limit príkazového kanála robota vyprší. Oprava: obsluha modrej/zelenej, dva koncové body, striedanie po jednom.
- Tepelná škrtiaca klapka servera. Pri trvalom tréningu + inferencii klimatizácia v miestnosti nedokáže držať krok a GPU sa spomaľujú. Latencia inferencie sa potichu zdvojnásobí. Oprava: zníženie chladenia na 1.3× trvalo, monitorovanie teplôt GPU, alarm pri 80 °C.
- Poruchy káblov/konektorov na strane robota. Roboty vibrujú. Únava káblov. V intenzívne používaných jednotkách počítajte s jedným zlyhaním sieťového alebo senzorového kábla na robota za štvrťrok. Uschovajte si náhradné diely.
-
Nezhoda medzi ovládačom NVIDIA a verziou CUDA po aktualizácii pomocou apt-get. Toto každého udrie presne raz. Pripnite si verziu ovládača, používajte kontajnery, nie
apt-get dist-upgradena funkčnom serveri. - Posun hodín medzi robotom a serverom. Časové pečiatky senzorov sa posunujú o desiatky milisekúnd, fúzia senzorov produkuje odpad, nikto nechápe prečo. Oprava: lokálny NTP, monitorovať ho, alarm pri posune > 5 ms.
Žiadna z nich nie je katastrofálna. Všetky sú predvídateľné, keď ich raz uvidíte.
Keď je lokálna cesta nesprávnou odpoveďou
Aby som bol úprimný: lokálny inferenčný server je nesprávnou odpoveďou, keď —
- Váš robot je čisto teleoperovaná jednotka a váš operátor aj tak sedí na cloudovej pracovnej stanici. Stačí použiť cloud.
- Nasadzujete jedno štvornohé zviera na úlohu vonkajšej inšpekcie a nie je potrebné rozsiahle modelovanie; prácu vykoná palubný počítač.
- Váš model sa v skutočnosti zmestí na Jetson Orin AGX (50–70 W TDP) a váš rozpočet na latenciu to umožňuje. Orin dokáže prevádzkovať 7B INT4 LLM s použiteľnou rýchlosťou.
- Spúšťate jednorazovú demoverziu. Cloud sa nastavuje rýchlejšie, je lacnejší pri nulovom zaťažení a môžete ho rozobrať za popoludnie.
Cesta k lokálnej prevádzke je správna, keď je nasadenie udržateľné, dáta sú citlivé, rozpočet na latenciu je obmedzený alebo sú potreby prispôsobenia skutočné. Väčšina serióznych robotických projektov v roku 2026 sa dotýka aspoň jedného z týchto aspektov.
Čo urobiť ďalej
Ak hodnotíte on-premise zostavenie, otázky, na ktoré sa oplatí odpovedať predtým, ako investujete peniaze, sú:
- Aké modely potrebujete hostiť? Zapíšte si názvy a počty parametrov. Týmto sa zmení veľkosť pamäte GPU.
- Koľko súbežných inferenčných požiadaviek, špičkových a trvalých? Toto upravuje počet grafických procesorov.
- Potrebujete tréningovú kapacitu alebo iba inferenciu? Tréning zhruba strojnásobí rozpočet na grafickú kartu a úložisko.
- Aký je váš výkonový a chladiaci limit? Buďte úprimní. Väčšina laboratórií tvrdo zisťuje, že nedokážu dodať nepretržitý výkon 5 kW.
- Máte integrátora? SDK od výrobcu sú dobré, ale spojivom medzi robotom, inferenčným serverom a vašou aplikáciou je skutočná práca. Buď si ho najmite, alebo si ho najmite.
Následné články v tejto sérii sa hlbšie venujú konkrétnym častiam: poskytovanie modelov (I02), topológia siete (I03), samotná referenčná zostava so zoznamom dielov a benchmarkmi (I05) a nasadenie flotily (I06).
Toto je súčasť Kentino Wiki, referenčnej série o umelej inteligencii, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy sú vítané na info@kentino.com.