Architektura EDGE AI: Jak robot komunikuje s lokálním inferenčním serverem

Pokud si v roce 2026 koupíte humanoidního nebo čtyřnohého robota, jednotka, kterou obdržíte, je pouze polovina systému. Druhá polovina je výpočetní zařízení, které běží na velkých modelech, které samotný robot nemůže hostovat. Tento článek vysvětluje, co se kde vlastně nachází, proč vůbec existuje on-premise cesta, když jsou cloudová API levná, a jak jsou obě poloviny fyzicky a logicky propojeny.

Publikem jsou kupující a integrátoři, kteří chtějí mít jasnou představu před podpisem objednávky – ne ještě inženýři píšící spojovací kód.

Problém dvou krabic

Moderní humanoidní tvor, jako je Unitree G1 nebo Booster T1, nese na palubě vestavěný výpočetní modul: obvykle Jetson Orin (třída NX nebo AGX) nebo SoC třídy Snapdragon, často spárovaný s malým specializovaným MCU pro řídicí smyčku motoru. Čtvernožci, jako je Unitree Go2, používají podobné uspořádání v menším měřítku.

Palubní výpočetní výkon stačí na:

• Řízení motoru v reálném čase — krouticí moment v kloubu, rovnováha, chůze. Toto běží na frekvenci 500 Hz až 1 kHz a netoleruje žádné síťové skoky. Zůstává lokální, tečka.
• Okamžité bezpečnostní reflexy — ochrana proti pádu, nouzové zastavení, reakce na kontakt. Stejné omezení, stejná odpověď.
• Vnímání s nízkou latencí — hloubka ze sterea nebo RGB-D, fúze IMU, základní detekce objektů (obvykle malá varianta YOLO nebo MobileNet).
• Hlasové probuzení a základní směrování příkazů.

Co palubní počítač nedokáže rozumně spustit:

• Velké modely vizuální řeči (VLM) jako Qwen2.5-VL 72B, NVIDIA Cosmos, OpenVLA. Ty potřebují desítky GB VRAM a jsou příliš energeticky náročné na platformu napájenou z baterie.
• Modely velkých jazyků (LLM) pro dialog nebo plánování nad třídou 7B–8B kvantovanou.
• Plánovače pohybu založené na difuzi nebo autoregresi které fungují na základě stovek milisekund kontextu.
• Paměť scény a grafy úloh s dlouhým horizontem.

Toto rozdělení není názorem Kentina. Je to skutečný oddíl, se kterým se dnes dodává každá důvěryhodná humanoidní platforma. Integrovaný modul je dimenzován s ohledem na bezpečnost a latenci; těžké myšlení se přesouvá mimo palubu.

„Mimo palubní“ cíl může být cloud (hostovaný na OpenAI, Anthropic, NVIDIA Cosmos) nebo on-premise inferenční server. Zbytek tohoto článku se věnuje tomu, kdy a proč chcete on-premise.

Co kde žije – praktické rozdělení

Rozdělení na dvě oblasti: lokální řízení zůstává na robotovi; těžká inference a trénování jdou na místní server přes LAN.

Tři věci, kterých je třeba si všimnout:

1. Robot k chůzi nepotřebuje GPU server. Pokud dojde k výpadku lokální sítě (LAN), jednotka stále stojí, drží rovnováhu a vyhýbá se nárazu do zdi. Externí informační kanál přidává funkce – jazyk, plánování, úkoly s dlouhým horizontem – nenahrazuje však lokální ovládání.
2. Některé pracovní zátěže jsou dohodou. Malý VLM (např. kvantizovaný Qwen2.5-VL 7B) může běžet na Jetson Orin AGX. To, zda jej nainstalujete na desku nebo mimo ni, je otázkou výkonu, teploty a latence. Neexistuje jedna správná odpověď.
3. Server dělá víc než jen obsluhuje inferenci. Vážné nasazení také spouští trénování (pro doladění specifického prostředí), simulaci (Isaac Sim pro iteraci politik) a paměť/načítání scén. „Inferenční server“ je zkratka pro „GPU compute backend“.

Rozpočet latence

Jediné číslo, které určuje, zda bude vaše architektura fungovat, je doba cesty od robota k serveru a zpět.

Čísla, která dominují rozpočtu, jsou latence modelu na straně serveru a (pokud používáte bezdrátovou síť) chvění Wi-Fi. Samotný přenos je v kabelové síti LAN jen zřídka úzkým hrdlem. Proto většina seriózních instalací robotů používá kabelové připojení nebo vyhrazený přístupový bod Wi-Fi 6/6E v přímé viditelnosti pracovní oblasti.

Pokud váš robot musí odpovědět na slovní příkaz za méně než jednu sekundu, matematika je zhruba následující:

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 dnešní době neexistuje způsob, jak dosáhnout „kratší doby než jedna sekunda mezi konci“ s 70B LLM ve smyčce. Buď akceptujete latenci, použijete menší model lokálně (třída 8B–13B), nebo rozdělíte odpověď (okamžité potvrzení, plánování na pozadí).

To je druh kompromisu, který nemá nic společného se sítí, ale souvisí s výběrem modelu. Je to také druh kompromisu, kde záleží na vlastním serveru: můžete si modely vyměňovat, spouštět více najednou, dávkovat je různě. S cloudovým API berete to, co nabízí poskytovatel.

Proč vůbec on-premise

Cloudová inference je levná, snadno se škáluje a nevyžaduje žádné kapitálové náklady. Proč by si tedy někdo kupoval server se čtyřmi nebo osmi grafickými procesory, když klíč OpenAI API stojí padesát dolarů?

Existují čtyři skutečné důvody, zhruba v pořadí, jak často ve skutečnosti ovlivňují rozhodnutí:

1. Data neopouštějí budovu. Průmyslová, obranná, zdravotnická a nasazení citlivá na EU/GDPR často nemohou odesílat nezpracovaná data ze senzorů do cloudu třetí strany. Robot vidí tovární halu, pokoj pacienta nebo laboratorní stůl. Toto video je buď privilegované, regulované nebo konkurenční. On-premise inference to řeší čistě. Cloud ne.

2. Latenční spodní hranice. Každé cloudové volání má navíc latenci modelu WAN RTT 15–40 ms. Pro většinu robotických úloh je to v pořádku. Pro reaktivní řízení v uzavřené smyčce – rychlé umisťování, obnovení rovnováhy po stisknutí tlačítka, jemná manipulace – je WAN spodní hranice příliš vysoká. On-premise systém ji snižuje pod 1 ms.

3. Náklady při trvalém zatížení. Jediný hovor VLM o objemu 70 bitů nestojí poskytovatele cloudu téměř nic; účtují si od vás pár centů. Robot, který „neustále přemýšlí“, ale provede tisíce hovorů za hodinu. Výzkumná laboratoř provádějící školení a flotila robotů, kteří oba vyhodnocují výsledky na základě stejných modelů, mohou v cloudu utratit 5 000–15 000 dolarů měsíčně. On-premise server se 4× nebo 8× GPU se při tomto zatížení zaplatí za méně než dvanáct měsíců.

4. Výběr a přizpůsobení modelu. Chcete doladit VLM ve vašem specifickém prostředí. Chcete spustit model, který poskytovatelé cloudu nehostují. Chcete kombinovat modely s otevřenou váhou od různých dodavatelů ve vlastním kanálu. On-premise vám to umožňuje. Cloudová API ne.

Pokud pro vaše nasazení nezáleží na žádném z těchto čtyř, měli byste použít cloud. Upřímná odpověď zní, že asi 30–40 % kupujících robotů skutečně potřebuje on-premise řešení; zbytek si ho vybírá kvůli prestiži nebo proto, že jejich nákupní kancelář nemá s cloudem nic společného. Oba důvody jsou také platné, ale nebudeme předstírat opak.

Topologie sítě

Topologie sítě: robot na Wi-Fi 6E → dedikovaný přístupový bod → 10GbE switch → inferenční server. Výstupní síť a WAN jsou volitelné.

Několik praktických poznámek, které lidi překvapí:

• Wi-Fi 6E je podlaha, ne strop. Pásmo 6 GHz je jediné s konzistentně nízkou latencí v prostředích s jinými zařízeními. Naplánujte jeden přístupový bod na přibližně 50 m² pracovní plochy robota, pokud možno v přímé viditelnosti.
• Drátové je pořád lepší. Pokud má robot možnost připojení k internetu (někteří humanoidi na výzkumné úrovni ji mají, čtyřnožci obvykle ne), použijte ji během vývoje. Vývojový zážitek s lokální sítí LAN v submilisekundové frekvenci je dramaticky příjemnější než boj s Wi-Fi.
• Výstup je volitelný, ale užitečný. I při plně on-premise nasazení obvykle potřebujete WAN egress pro: aktualizaci modelů, načítání mapových dat, stahování kontejnerů NVIDIA NGC a telemetrii pro váš vlastní monitoring. Pevně ​​jej chraňte firewallem; nevystavujte robota ani server internetu.
• Synchronizace času je důležitá. Spusťte lokální NTP server. Fúze senzorů a plánování pohybu se nenápadně přerušují, když se hodiny v robotu, serveru a jakýchkoli pomocných zařízeních na okraji sítě posunou.

Napájení a chlazení

Server s 4 grafickými kartami K-AI (4× RTX 5090 nebo 4× RTX Pro 6000 Blackwell) odebírá trvale 1.8–2.4 kW při zátěži. Server s 8 grafickými kartami odebírá 3.5–4.5 kW. Nejedná se o čísla pro stolní počítače; potřebují obvody s proudem 16 A a správné proudění vzduchu v racku.

Pro robotickou laboratoř je hrubý rozpočet:

Naplánujte si místnost před instalací, ne po ní. Většina laboratoří, které „přidaly výpočty na GPU později“, nakonec vypne jističe hned v prvním měsíci.

Proudění vzduchu je stejně důležité jako příkon. Servery K-AI využívají průmyslové proudění vzduchu do racku s předním a zadním vedením se 120mm ventilátory a jsou speciálně navrženy pro nepřetržité zatížení 24 hodin denně, 7 dní v týdnu. Nejsou to stolní počítače typu tower a zahltí systém vytápění, větrání a klimatizace v malé místnosti. Buď je umístěte do skříně se samostatným chlazením, nebo je umístěte do samostatné místnosti a použijte 10GbE připojení.

Softwarový stack – co vlastně běží

Zde se nachází implementace. Obrázek na vysoké úrovni:

Rozdělení softwaru: ROS 2 na robotu komunikuje přes gRPC s inferenčním serverem, na kterém běží vLLM / SGLang.

Pár názorových výroků:

• vLLM je výchozí obslužný zásobník pro VLM a LLM založené na transformátorech. Je rychlejší než naivní inference HuggingFace a podporuje kontinuální dávkování a ukládání prefixů do mezipaměti. SGLang je silnou alternativou, pokud vytváříte strukturovaný výstup nebo pracovní postupy ve stylu agentů.
• lama.cpp je správná odpověď, když provozujete malý model (třída 7B–13B) na GPU, kterou vLLM nemá rád (např. RTX 4090 s netradičním tenzorovým paralelismem), nebo na samotném robotu.
• NVIDIA Triton Je náročnější na nastavení, ale je to správné rozhodnutí, pokud kombinujete typy modelů (LLM + vize + řeč) a chcete nad nimi všechny jednu obslužnou vrstvu.
• ROS 2 Humble je lingua franca. Výrobní SDK (Unitree, Booster, EngineAI) dodávají obalovací protokoly ROS 2. Pokud k tomu nemáte konkrétní důvod, vytvářejte svou integraci na straně ROS 2, nikoli na proprietárním protokolu výrobce.

Konkrétní příklad

Představte si nejjednodušší schůdnou sestavu produkčního prostředí: jeden humanoid (Unitree G1), jeden inferenční server (K-AI 256 Turin Dual s 8× RTX 5090), jeden switch, jeden AP, v laboratoři o rozloze 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

Jedná se o reálnou a životaschopnou architekturu, kterou si můžete koupit a zprovoznit během dvou až tří týdnů. Celkový rozpočet na výpočetní část (server, síť, elektroinstalace, chlazení) se pohybuje v rozmezí 60 000 až 90 000 eur v závislosti na konfiguraci. Robot je samostatnou položkou.

Pro výzkumnou laboratoř s 2–4 roboty se stejný server škáluje – vLLM zvládá souběžné požadavky bez problémů a úzkým hrdlem se stává buď paměť GPU (pokud chcete hostovat více modelů současně), nebo napájení ze zásuvky.

Co se láme

Upřímný seznam poruchových režimů, které jsme viděli, zhruba v pořadí, jak často se projevují:

• Jitter Wi-Fi při zátěži. Dříve fungující síť se přetíží, když se připojí nové zařízení, latence se zvýší z 5 ms na 80 ms a reaktivní chování robota se zhorší. Oprava: vyhrazené SSID pro robotiku, pouze 6 GHz, přístupový bod v přímé viditelnosti.
• Výměna modelu systém vyřadí z provozu. Aktualizujete VLM, vLLM se musí znovu načíst, časový limit příkazového kanálu robota vyprší. Oprava: obsluha modré/zelené, dva koncové body, prohazování po jednom.
• Tepelná škrticí klapka serveru. Při trvalém tréninku + inferenci klimatizace v místnosti nestačí a GPU se zpomalují. Latence inference se tiše zdvojnásobuje. Oprava: chlazení velikosti pro 1.3× trvale vyšší rychlost, sledování teploty GPU, alarm při 80 °C.
• Poruchy kabelů/konektorů na straně robota. Roboti vibrují. Únava kabelů. U intenzivně používaných jednotek počítejte s jednou poruchou síťového nebo senzorového kabelu na robota za čtvrtletí. Uchovávejte náhradní díly.
• Neshoda mezi verzí ovladače NVIDIA a CUDA po aktualizaci pomocí apt-get. Tohle kousne každého přesně jednou. Zapněte si verzi ovladače, používejte kontejnery, ne apt-get dist-upgrade na funkčním serveru.
• Posun hodin mezi robotem a serverem. Časová razítka senzorů se posunují o desítky milisekund, fúze senzorů produkuje odpad, nikdo nechápe proč. Oprava: lokální NTP, monitorování, alarm při posunu > 5 ms.

Nic z toho není katastrofické. Všechny jsou předvídatelné, jakmile je jednou uvidíte.

Když je cesta k místní síti nesprávnou odpovědí

Abych byl upřímný: lokální inferenční server je špatnou odpovědí, když —

• Váš robot je čistě teleoperovaná jednotka a váš operátor stejně sedí na cloudové pracovní stanici. Prostě používejte cloud.
• Nasazujete jednoho čtyřnožce pro úkol venkovní inspekce a není potřeba rozsáhlá inference modelu; práci vykoná palubní počítač.
• Velikost vašeho modelu se ve skutečnosti vejde na Jetson Orin AGX (50–70 W TDP) a váš rozpočet na latenci to umožňuje. Orin zvládne 7B INT4 LLM s použitelnou rychlostí.
• Spouštíte jednorázovou demoverzi. Cloud se nastavuje rychleji, je levnější při nulové zátěži a můžete ho rozebrat během odpoledne.

Cesta k on-premise řešení je správná, když je nasazení udržitelné, data jsou citlivá, rozpočet na latenci je omezený nebo jsou potřeby přizpůsobení skutečné. Většina seriózních robotických prací v roce 2026 setkává alespoň s jednou z těchto oblastí.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.