Architektura edge AI: jak robot mluví s on-prem inferenčním serverem

Pokud v roce 2026 kupujete humanoidního nebo čtyřnohého robota, dostanete jen polovinu systému. Druhou polovinou je výpočetní výkon, na kterém běží velké modely, jež robot sám hostovat nedokáže. Tento článek vysvětluje, co se ve skutečnosti odehrává kde, proč má on-prem cesta smysl i v době levných cloudových API a jak jsou obě poloviny fyzicky i logicky propojené.

Text je určený kupujícím a integrátorům, kteří chtějí mít jasno dřív, než podepíšou objednávku — zatím ne inženýrům, kteří budou psát propojovací kód.

Problém dvou krabic

Moderní humanoid jako Unitree G1 nebo Booster T1 nese na palubě vestavěný výpočetní modul: typicky Jetson Orin (třídy NX nebo AGX) nebo SoC třídy Snapdragon, často doplněný malým vyhrazeným MCU pro smyčku řízení motorů. Čtyřnozí roboti jako Unitree Go2 používají podobné uspořádání v menším měřítku.

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

• Řízení motorů v reálném čase — moment v kloubech, rovnováha, chůze. Běží na 500 Hz až 1 kHz a nesnese žádný síťový skok. 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 stereo nebo RGB-D kamery, fúze dat z IMU, základní detekce objektů (typicky malá varianta YOLO nebo MobileNet).
• Hlasové aktivační slovo a základní směrování příkazů.

Co palubní výpočet rozumně utáhnout nedokáže:

• Velké vision-language modely (VLM) jako Qwen2.5-VL 72B, NVIDIA Cosmos nebo OpenVLA. Potřebují desítky GB VRAM a na platformu napájenou z baterie jsou příliš žravé.
• Velké jazykové modely (LLM) pro dialog nebo plánování nad kvantizovanou třídou 7B–8B.
• Difuzní nebo autoregresivní plánovače pohybu, které pracují se stovkami milisekund kontextu.
• Paměť scény a úlohové grafy s dlouhým horizontem.

Tohle rozdělení není názor Kentina. Je to reálné rozvrstvení, se kterým dnes přichází každá seriózní humanoidní platforma. Palubní modul je dimenzovaný na bezpečnost a latenci; těžké přemýšlení jde mimo robota.

Cílem „mimo robota“ může být cloud (OpenAI, Anthropic, hostovaná NVIDIA Cosmos) nebo on-prem inferenční server. Zbytek článku je o tom, kdy a proč chcete právě on-prem variantu.

Co kde běží — praktické rozdělení

Rozdělení na dvě krabice: lokální řízení zůstává v robotu, náročná inference a trénink jdou přes LAN na on-prem server.

Všimněte si tří věcí:

1. Robot nepotřebuje GPU server k tomu, aby chodil. Když vypadne LAN, jednotka se pořád postaví, udrží rovnováhu a nenarazí do zdi. Pipeline mimo robota přidává schopnosti — jazyk, plánování, úlohy s dlouhým horizontem — ale lokální řízení nenahrazuje.
2. O některých workloadech se dá vyjednávat. Malý VLM (např. kvantizovaný Qwen2.5-VL 7B) zvládne běžet na Jetsonu Orin AGX. Jestli ho dáte na palubu, nebo mimo ni, je kompromis mezi spotřebou, teplotou a latencí. Jedna správná odpověď neexistuje.
3. Server dělá víc než jen obsluhu inference. Seriózní nasazení na něm provozuje i trénink (doladění na konkrétní prostředí), simulaci (Isaac Sim pro iteraci policy) a paměť scény s vyhledáváním. „Inferenční server“ je zkratka pro „GPU výpočetní backend“.

Rozpočet latence

Jediné číslo, které rozhodne, jestli Vaše architektura bude fungovat, je doba odezvy z robota na server a zpátky.

Rozpočtu dominuje latence modelu na straně serveru a — pokud jedete bezdrátově — kolísání Wi-Fi. Samotný přenos je na drátové LAN jen zřídka úzkým hrdlem. Proto většina seriózních robotických instalací používá drátové připojení nebo vyhrazený AP Wi-Fi 6/6E v přímé viditelnosti pracovní plochy.

Pokud má robot odpovědět na hlasový příkaz do jedné sekundy, počítá se to zhruba takto:

záznam zvuku           ~ 50 ms
aktivační slovo + STT  100–250 ms  (na palubě, nebo mimo ni — Vaše volba)
LLM TTFT (plánování)   200–500 ms  (na serveru)
LLM stream 20 tokenů   600–1200 ms
TTS                    100–300 ms
přehrání zvuku         ~ 50 ms
                       --------------
                       ~ 1.1 – 2.3 s

Dostat se dnes s 70B LLM ve smyčce pod jednu sekundu end-to-end prostě nejde. Buď latenci přijmete, nebo použijete menší model on-prem (třída 8B–13B), nebo odpověď rozdělíte (okamžitě potvrdíte příjem a plánujete na pozadí).

Tohle je typ kompromisu, který nemá nic společného se sítí a všechno s volbou modelu. A je to zároveň kompromis, kde se vlastní server vyplatí: můžete modely měnit, provozovat jich víc najednou, jinak dávkovat. U cloudového API berete to, co poskytovatel nabídne.

Proč vůbec on-prem

Cloudová inference je levná, škáluje bez námahy a nevyžaduje žádné investice. Proč by tedy někdo kupoval server se čtyřmi nebo osmi GPU, když API klíč od OpenAI stojí padesát dolarů?

Existují čtyři skutečné důvody, zhruba v pořadí, jak často o věci opravdu rozhodují:

1. Data neopustí budovu. Průmysl, obrana, zdravotnictví a nasazení citlivá na EU/GDPR často nemohou surová data ze senzorů posílat do cizího cloudu. Robot vidí výrobní halu, pokoj pacienta, laboratorní stůl. To video je buď chráněné, regulované, nebo konkurenčně citlivé. On-prem inference to řeší čistě. Cloud ne.

2. Spodní hranice latence. Každé volání do cloudu má nad rámec latence modelu ještě 15–40 ms WAN RTT. Pro většinu robotických úloh to stačí. Pro reaktivní řízení v uzavřené smyčce — rychlé pick-and-place, vyrovnání rovnováhy po strčení, jemnou manipulaci — je spodní hranice WAN příliš vysoká. On-prem ji srazí pod 1 ms.

3. Náklady při trvalé zátěži. Jedno volání 70B VLM stojí poskytovatele cloudu skoro nic; Vám naúčtuje pár centů. Jenže robot, který „neustále přemýšlí“, udělá tisíce volání za hodinu. Výzkumná laboratoř, kde běží trénink a zároveň flotila robotů dotazující se na stejné modely, dokáže v cloudu utratit 5 000–15 000 dolarů měsíčně. Při takové zátěži se on-prem server se 4 nebo 8 GPU zaplatí za méně než dvanáct měsíců.

4. Volba modelu a přizpůsobení. Chcete doladit VLM na své konkrétní prostředí. Chcete provozovat model, který poskytovatelé cloudu nehostují. Chcete v jedné pipeline zkombinovat modely s otevřenými vahami od různých dodavatelů. On-prem Vám to umožní. Cloudová API ne.

Pokud pro Vaše nasazení ani jeden ze čtyř bodů neplatí, používejte cloud. Upřímná odpověď je, že on-prem reálně potřebuje možná 30–40 % kupujících v robotice; zbytek po něm sahá z prestiže nebo proto, že jejich nákupní oddělení cloudu nevěří. I to jsou legitimní důvody, ale nebudeme předstírat něco jiného.

Topologie sítě

Topologie sítě: robot na Wi-Fi 6E → vyhrazený AP → přepínač 10 GbE → inferenční server. Výstup do internetu a WAN jsou volitelné.

Pár praktických poznámek, které lidi obvykle zaskočí:

• Wi-Fi 6E je minimum, ne strop. Pásmo 6 GHz je jediné, které se v prostředí s dalšími zařízeními chová konzistentně s nízkou latencí. Počítejte s jedním AP na zhruba 50 m² pracovní plochy robota, pokud možno v přímé viditelnosti.
• Drát je pořád lepší. Pokud má robot možnost připojení kabelem (někteří humanoidi pro výzkum ano, čtyřnozí roboti většinou ne), používejte ji během vývoje. Vývoj s LAN pod jednu milisekundu je dramaticky příjemnější než boj s Wi-Fi.
• Výstup do internetu je volitelný, ale užitečný. I u plně on-prem nasazení obvykle chcete výstup do WAN kvůli: aktualizaci modelů, stahování mapových dat, stahování NGC kontejnerů od NVIDIA a telemetrii do vlastního monitoringu. Zabezpečte ho přísným firewallem; robota ani server nikdy nevystavujte přímo do internetu.
• Na synchronizaci času záleží. Provozujte lokální NTP server. Fúze senzorů a plánování pohybu se rozbíjejí nenápadnými způsoby, jakmile se hodiny robota, serveru a případných pomocných edge zařízení rozejdou.

Napájení a chlazení

Server Kentino AI se 4 GPU (4× RTX 5090 nebo 4× RTX Pro 6000 Blackwell) odebírá při zátěži trvale 1.8–2.4 kW. Server s 8 GPU odebírá 3.5–4.5 kW. To nejsou desktopová čísla; potřebují jištění 16 A a pořádné proudění vzduchu v racku.

Pro robotickou laboratoř vypadá hrubý rozpočet takto:

Naplánujte místnost před instalací, ne až po ní. Většina laboratoří, které „GPU výkon dořešily později“, shazuje v prvním měsíci jističe.

Na proudění vzduchu záleží stejně jako na wattech. Servery Kentino AI používají průmyslové proudění zepředu dozadu se 120mm ventilátory a jsou výslovně navržené na trvalý provoz 24/7. Nejsou to desktopové Tower sestavy a klimatizaci malé místnosti zahltí. Buď je dejte do racku v místnosti s vlastním chlazením, nebo je umístěte do jiné místnosti a natáhněte k nim 10 GbE linku.

Softwarový stack — co na tom reálně běží

Tady se odehrává samotná implementace. Pohled shora:

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

Několik názorových doporučení:

• vLLM je výchozí stack pro obsluhu VLM a LLM postavených na transformerech. Je rychlejší než naivní inference přes HuggingFace a podporuje průběžné dávkování i cachování prefixů. SGLang je silná alternativa, pokud děláte strukturovaný výstup nebo workflow agentního typu.
• llama.cpp je správná odpověď, když provozujete malý model (třída 7B–13B) na GPU, které vLLM nemá v lásce (např. RTX 4090 s nevyzpytatelným tenzorovým paralelismem), nebo přímo v robotu.
• NVIDIA Triton se nastavuje hůř, ale je správnou volbou, pokud mícháte různé typy modelů (LLM + vidění + řeč) a chcete nad nimi mít jednu obslužnou vrstvu.
• ROS 2 Humble je společný jazyk. SDK výrobců (Unitree, Booster, EngineAI) se dodávají s obálkami pro ROS 2. Stavte integraci na straně ROS 2, ne na proprietárním protokolu výrobce, pokud nemáte konkrétní důvod.

Konkrétní příklad

Představte si nejjednodušší provozuschopnou sestavu: jeden humanoid (Unitree G1), jeden inferenční server (Kentino AI 256 Turin Dual s 8× RTX 5090), jeden přepínač, jeden AP, v laboratoři o ploše 30 m².

Hardware:
- Unitree G1 (jeden kus, ~1 kW odběr při nabíjení)
- Kentino AI 256 Turin Dual / 8× RTX 5090 (trvale ~4 kW)
- přepínač 10 GbE (5 portů, ~30 W)
- AP Wi-Fi 6E (~15 W)
- okruh 32 A třífázový nebo 2× 16 A jednofázový
- ~6 kW vyhrazeného chlazení (split klimatizace)

Software na serveru:
- Ubuntu 22.04, CUDA 13, Docker
- vLLM obsluhující Qwen2.5-VL 72B v INT4
- vLLM obsluhující Qwen2.5 32B (jen text, pro plánování)
- pgvector pro paměť scény
- Isaac Sim pro práci s policy
- Prometheus + Grafana

Software v robotu:
- ovladač ROS 2 od Unitree
- vlastní uzel ROS 2 pro směrování příkazů
- gRPC klient k endpointům vLLM
- lokální YOLO pro rychlou detekci překážek

Tohle je reálná, funkční architektura, kterou koupíte a zprovozníte za dva až tři týdny. Celkový rozpočet na výpočetní část (server, síť, elektroinstalace, navýšení chlazení) se podle konfigurace pohybuje v pásmu €60k–€90k. Robot je samostatná položka.

Pro výzkumnou laboratoř se 2–4 roboty stejný server postačí — vLLM si se souběžnými požadavky poradí a úzkým hrdlem se stane buď paměť GPU (pokud chcete hostovat víc modelů naráz), nebo příkon ze zásuvky.

Co se rozbíjí

Upřímný seznam poruch, které jsme viděli, zhruba v pořadí podle četnosti:

• Kolísání Wi-Fi při zátěži. Dosud bezproblémová síť se zahltí, jakmile se připojí nové zařízení, latence vyskočí z 5 ms na 80 ms a reaktivní chování robota se zhorší. Řešení: vyhrazená SSID pro robotiku, výhradně 6 GHz, AP v přímé viditelnosti.
• Výměna modelu položí systém. Aktualizujete VLM, vLLM se musí znovu načíst a příkazové pipeline robota vyprší časový limit. Řešení: blue/green nasazení, dva endpointy, výměna po jednom.
• Teplotní omezení výkonu serveru. Při trvalém tréninku a inferenci zároveň klimatizace nestíhá a GPU začnou snižovat takty. Latence inference se tiše zdvojnásobí. Řešení: dimenzujte chlazení na 1.3× trvalé zátěže, sledujte teploty GPU a nastavte alarm na 80 °C.
• Závady kabelů a konektorů na straně robota. Roboti vibrují. Vodiče se unaví. U intenzivně využívaných jednotek počítejte s jednou poruchou síťového nebo senzorového kabelu na robota za čtvrtletí. Mějte náhradní.
• Nesoulad verzí ovladače NVIDIA a CUDA po apt-get upgrade. Tohle každého chytne právě jednou. Zafixujte verzi ovladače, používejte kontejnery a na funkčním serveru nespouštějte apt-get dist-upgrade.
• Rozcházení hodin mezi robotem a serverem. Časová razítka senzorů se rozejdou o desítky milisekund, fúze senzorů začne produkovat nesmysly a nikdo nechápe proč. Řešení: lokální NTP, sledovat ho a nastavit alarm na rozdíl > 5 ms.

Nic z toho není katastrofa. Všechno je to předvídatelné, jakmile to jednou zažijete.

Kdy je on-prem cesta špatná odpověď

Abychom zůstali upřímní: on-prem inferenční server je špatná odpověď, když —

• Váš robot je čistě teleoperovaná jednotka a operátor stejně sedí u cloudové workstation. Použijte prostě cloud.
• Nasazujete jednoho čtyřnohého robota na venkovní inspekci a inferenci velkých modelů vůbec nepotřebujete; palubní výpočet práci zvládne.
• Váš model se reálně vejde na Jetson Orin AGX (TDP 50–70 W) a rozpočet latence palubní běh dovolí. Orin utáhne 7B LLM v INT4 v použitelné rychlosti.
• Děláte jednorázovou ukázku. Cloud se nastaví rychleji, při nulové zátěži je levnější a během odpoledne ho zase zrušíte.

On-prem cesta je správná, když je nasazení dlouhodobé, data jsou citlivá, rozpočet latence je napjatý, nebo jsou potřeby přizpůsobení reálné. Většina seriózní robotické práce v roce 2026 splňuje alespoň jednu z těchto podmínek.

Tento text je součástí Kentino Wiki, referenční série o AI výpočtech, robotice a systémech, které je propojují. Komentáře a opravy uvítáme na info@kentino.com.