Proč roboti potřebují specializované edge computingové systémy

Humanoid, který chodí, je vyřešený problém. Humanoid, který chápe, na co se dívá, plánuje vícestupňový úkol a pamatuje si, co se stalo před pěti minutami, problémem vyřešeným není. Výpočetní prostředky, které tuto mezeru překlenou, se na robota nevejdou a cloud není pro ně tím správným místem. Tento článek je technickým argumentem, proč je specializovaný lokální inferenční server v roce 2026 nejmodernějším řešením pro jakékoli nasazení robotiky dostatečně seriózní, aby odvádělo užitečnou práci.

I01 se zabývá propojením robota a serveru. Tento článek je důvodem, proč byste si server vůbec měli koupit. Pokud si stále kladete otázku, zda má on-premise smysl, přečtěte si nejprve toto.

Rozpočet latence rozhodnutí

Každá akce, kterou robot provede, se nachází v jedné ze čtyř úrovní latence. Každá úroveň má limit daný fyzikou úkolu – pokud ji neprovedete, chování se specifickým a rozpoznatelným způsobem poruší.

Tyto nejsou libovolné. Vycházejí z šířky pásma uzavřené smyčky, uvnitř které se nacházejí.

Reaktivní řízení probíhá na úrovni kloubů na frekvenci 500 Hz až 1 kHz, protože to vyžaduje dynamika 30 kg o hmotnosti humanoidní nohy – při 100 Hz končetina rezonuje a chůze se rozbíhá. Reflexní vnímání dědí snímkovou frekvenci kamery (30–60 FPS = 16–33 ms na snímek) a časový harmonogram fyzického kontaktu (stisk prstu na objekt ukončí kontaktní událost za 20–40 ms). Deliberativní plánování je omezeno lidskými konverzačními očekáváními (jedna sekunda se jeví jako responzivní, dvě jako pomalé) a latencí modelu užitečného VLM. Strategické uvažování je jedinou úrovní se skutečným volným prostorem, a proto se do něj každý snaží vložit plánování a je kousen, když jeho VLM nestačí.

Tohle není názor Kentina. Čtyřúrovňový rozpočet je dělící systém, který zahrnuje každý důvěryhodný stack pro řízení robotů – ROS 2, Isaac, Drake, OCS2. Rozdíl je v tom, jaký hardware se za každou vrstvou umístí.

Co palubní počítač umí a co neumí

Humanoid z roku 2026 nese na vrcholu specifikací procesor NVIDIA Jetson AGX Orin – 64 GB unifikované paměti, až 275 řídkých INT8 TOPS (138 hustých), konfigurovatelný výkon 15–60 W. To je na vestavěný modul skutečně působivé. Zároveň se to ale ani zdaleka neblíží tomu, co by moderní robot poháněný VLM chtěl.

Proveďte výpočty na třech modelových třídách, které by humanoid mohl skutečně chtít použít:

Orin AGX 64 GB bude hostovat VLM třídy 32B na INT4, pokud akceptujete pomalou inferenci, žádné skutečné dávkování a žádné souběžné úlohy. Nebude hostovat VLM třídy 70B, které jsou v roce 2026 nejmodernější pro porozumění scénám – Qwen2.5-VL 72B, větší varianty Cosmos, proprietární modely, pro které dodavatelé nezveřejňují váhy. Kombinované váhy, KV cache pro dlouhý vizuální kontext a jakýkoli prostor pro druhý model se nehodí.

Druhé číslo se zamlčuje: výkon. Údaj 275 TOPS u Orinu předpokládá režim MAX_N (60 W). To je platforma napájená z baterie, která spotřebovává 60 W výpočetního výkonu a zároveň zatěžuje aktuátory o výkonu 200–800 W. Trvalý režim MAX_N zkracuje dobu běhu robota na polovinu. V praxi Orin tráví většinu času v režimu 30 W, což snižuje výkon TOPS zhruba na polovinu a posouvá již tak marginální inferenci do „nepoužitelné“ oblasti.

Překlad: palubní Jetson je dimenzován pro reaktivní a reflexivní úrovně. Není dimenzován pro VLM hostitele. Každý, kdo vám říká, že jeho humanoid „používá palubní Qwen2.5-VL“, používá buď model 3B nebo 7B a označuje ho za dobrý, nebo používá větší model s 0.5 FPS a označuje ho za demo. Oba jsou platné pro specifické případy použití. Ani univerzální vnímání robota neplatí.

Proč je cloud špatným řešením pro robotiku s uzavřenou smyčkou

Cloudová inference je levná, snadno škálovatelná a nevyžaduje žádné kapitálové náklady. Pro robota má čtyři problémy, zhruba seřazené podle závažnosti.

1. Minimální latence WAN. Dobře vyladěný cloudový hovor v rámci EU dosahuje doby zpáteční cesty v samotné WAN 15–40 ms plus 5–15 ms režijních nákladů na TLS / HTTP / vyrovnávač zátěže, plus inferenční čas modelu a cesta zpět. Transatlantic přidává 80–120 ms zpáteční cesty. U reflexivního dotazu – „je přede mnou překážka?“ – je přidání 30–50 ms ještě před spuštěním modelu porušením rozpočtu. Pro deliberativní plánování s dobou 200–500 ms to možná tolerujete, ale každý zahozený paket, každý opakovaný přenos, každé failover mobilní věže vás přesune na další úroveň.

2. Jitter. WAN RTT není konstanta. Je to distribuce. Medián 25 ms, P99 250 ms, P99.9 několik sekund. Robot jednající v reálném světě nemůže akceptovat několikasekundovou pauzu, protože trasa BGP selhala. On-premise LAN P99.9 je 1–2 ms.

3. Náklady při trvalém zatížení. Jediná inference VLM o kapacitě 70 bitů nestojí poskytovatele cloudu téměř nic – účtují si pár centů. Robot, který „neustále vnímá“, provede jedno volání VLM každých 100–500 ms, když je aktivní. To je 7 000–36 000 volání za hodinu na robota. Flotila tří robotů běžících osm hodin denně ve vysokém segmentu představuje 850 000 volání. Při pouhých 0.005 dolaru za volání na hostovaném endpointu o kapacitě 72 bitů to je 4 250 dolarů za den, tedy 125 000 dolarů za měsíc. On-premise server s 8× GPU se při tomto zatížení zaplatí za méně než tři měsíce.

4. Datová suverenita. Robot vidí tovární halu, pokoj pro pacienty, výzkumnou laboratoř, sklad s proprietárním uspořádáním zásob, vojenské cvičiště. Toto video je privilegované nebo regulované podle GDPR, HIPAA, ITAR nebo jednoduše kvůli citlivosti konkurence. Jeho odeslání do cloudu třetí strany – i takové, která podepisuje DPA – je buď zakázáno, nebo představuje netriviální zátěž z hlediska dodržování předpisů. Inference na místní úrovni eliminuje otázku datové suverenity: bajty nikdy neopouštějí budovu.

Existuje pátý, měkčí problém: závislost na dodavateli . Cloudová API slouží modelům, které chce poskytovatel zobrazovat, s kvantizacemi a kontextovými okny, které si poskytovatel vybral. Na koncovém bodě OpenAI nelze spustit vyladěný VLM. Nelze připnout konkrétní commit modelu s otevřenou váhou. Nelze kombinovat modely od konkurenčních dodavatelů v jednom pipeline. Pro prototypování jsou tato omezení v pořádku. Pro nasazení produkční robotiky, které musí být předvídatelné po celá léta, nikoli.

Případ dedikovaného edge serveru

Vyhrazený lokální inferenční server se nachází v místní síti LAN, jeden nebo dva skoky od robota. V případě řady Kentino s umělou inteligencí se jedná o 4U rackový server, hostitel EPYC nebo Xeon, 4× nebo 8× GPU, na 10GbE přepínači. Čísla, která přináší:

Dva sloupce, kterým dominuje lokální varianta, jsou trvalá propustnost a volba modelu . To jsou také dva sloupce, které jsou nejdůležitější pro úlohy, které se chystáme vyjmenovat.

Reprezentativní grafická karta Kentino AI 256 Turin Dual s 8× RTX 5090 má celkem 256 GB VRAM a výkon grafického procesoru 1.0–1.5 kW v zátěži. To stačí k současnému provozování:

• Qwen2.5-VL 72B na INT4 (~45–50 GB váhy + 10–20 GB KV na pár GPU, tenzorově paralelní napříč 4 GPU)
• Qwen2.5 32B pouze textový (plánování, dialog) na 2 GPU
• Malý VLA (OpenVLA 7B nebo Cosmos-Reason 7B) na 1 GPU pro motion intent
• Paměť scén / RAG úložiště (pgvector nebo ChromaDB) na hostitelském CPU
• Doladění kapacity online zásad na zbývajícím GPU, když je robot v doku

VLM TTFT pro Qwen2.5-VL 72B na tomto hardwaru dosahuje v rozsahu 200–400 ms při zátěži s jedním požadavkem a při velké souběžné zátěži se zvyšuje na 1–4 sekundy. Streamování tokenů je 25–50 tokenů/s. To stačí k tomu, aby se 72B VLM dostal do úrovně deliberativního plánování (100 ms – 1 s) při zátěži s jedním robotem a do úrovně strategického uvažování (1 s – více s) pro malou flotilu. Ani jedna z úrovní není problém; reaktivní a reflexivní úrovně zůstávají na palubě tam, kam patří.

Mezera ve schopnostech: k čemu slouží pouze vyhrazená okrajová vrstva

On-premise server není jen „stejný robot, ale rychlejší“. Umožňuje třídu úloh, které ostatní dvě úrovně strukturálně nemohou hostovat. Upřímný seznam:

1. Zpětná vazba o porozumění scéně v reálném čase. 72B VLM se dívá na kameru robota každých 200–500 ms a vrací strukturovaný popis scény, který plánovač spotřebuje. Cloud to nemůže provést ve velkém měřítku kvůli chvění WAN a nákladům. Integrovaný systém to nemůže provést, protože model nesedí. On-premise uzavírá smyčku celkem za 250–500 ms.

2. Fúze VLM z více kamer. Humanoid má 3–5 kamer (hlava, dvě zápěstí, dvě na těle / hrudník). Spuštění VLM přes všechny z nich současně – pro prostorové uzemnění, manipulaci s okluzí nebo koordinaci ruka-oko – představuje 5× větší inferenční zátěž. Limity rychlosti cloudu nebo poplatky za stream. Na desce se vejde jeden stream v malém měřítku. On-premise dávkově odesílá všech pět přes stejný koncový bod VLM.

3. Dlouhodobé plánování úloh s perzistentní pamětí scény. „Včera jsem nechal klíč na druhé polici. Najdi ho.“ To vyžaduje VLM + LLM + vektorové úložiště běžící společně s perzistentním stavem napříč relacemi robota. Stav musí být uložen někde stabilně, dotazovatelně a rychle. To je databáze na serveru, nikoli kontextové okno cloudu pro každé volání, a ne 4 GB RAM na Jetsonu.

4. Online doladění zásad. Robot během dne shromažďuje ukázky úloh. Přes noc, když je v doku, spustíte doladění LoRA na základě denních dat oproti základnímu VLA, nainstalujete aktualizovaný adaptér a robot je zítra v lepším stavu. Jedná se o 2× až 5× větší paměťovou náročnost oproti inferenci. Cloud účtuje školení a úložiště odděleně. On-premise je absorbuje do stejného zařízení.

5. Koordinace více robotů. Dva nebo tři roboti sdílející paměť scény, koordinující úkoly a sledující vzájemný stav. Vrstva koordinace mezi roboty vyžaduje latenci mezi roboty pod 10 ms. On-premise se sdíleným serverem v místní síti to umožňuje. Cloud to nedokáže – aktualizace každého robota se odešle do určité oblasti, vrátí se a dotkne se dalšího robota.

6. Iterace simulace do reálného prostředí. Isaac Sim běží na stejných GPU, které slouží k inferenci, generuje syntetická trénovací data a ověřuje aktualizace politik předtím, než se dostanou ke skutečnému robotovi. Jedna iterace v cloudu trvá půl dne (pouze přesun dat), což je 30minutová smyčka v on-premise.

Žádná z nich není sci-fi. Všechny tyto úlohy jsou úlohy, které dnes používají integrátoři robotů z roku 2026. Žádná z nich nefunguje čistě na žádné ze zbývajících dvou úrovní.

Proč je tohle v roce 2026 to nejmodernější řešení

Nejmodernějším modelem vnímání robotů v roce 2026 je VLM-in-the-loop . Model se dívá na svět, argumentuje o něm v jazyce, generuje strukturované plány a politika je realizuje. V roce 2023 se jednalo o výzkumný nápad, v roce 2024 o produktovou demonstraci a v letech 2025–2026 o produkční model.

Trend vynucující přechod na on-premise vrstvu je přímočarý: fungující VLM se zvětšují, ne zmenšují. Qwen2.5-VL 7B je dobrý. Qwen2.5-VL 72B je výrazně lepší. Proprietární modely, které Frontier Labs nepublikují, jsou ještě větší. Cesta s „malým VLM, který běží na zařízení“, existuje a bude existovat i nadále, ale za Frontier zaostává o 12–18 měsíců a představuje významnou mezeru ve funkcích. Pokud chcete chování Frontier, hostujete Frontier model. Frontier model se nevejde na Jetson.

Cloud by teoreticky mohl držet krok. V praxi to tak není, a to ze čtyř výše uvedených důvodů (latence, jitter, náklady, suverenita) a také proto, že laboratoře Frontier Labs sdílejí největší modely za partnerskými úrovněmi, ke kterým robotický startup nemá přístup. VLM třídy 70B s otevřenou váhou existují , lze je hostovat a dobře běží na komoditních serverech s 8 GPU. Tato souhra – modely Frontier třídy s otevřenou váhou a komoditní hardware s více GPU – je důvodem, proč je on-premise řešení právě teď tou správnou odpovědí, a v roce 2023 jí nebyla.

Ani tohle není názor Kentina. Inferenční úroveň pro on-premise je to, na čem je postaven stack Isaac od NVIDIA, pro co hlavní robotické platformy dodávají referenční architektury a co zajišťuje každý seriózní integrátor, se kterým jsme v posledních šesti měsících hovořili. Trh dohnal hardware, který dohnal modely, a rok 2026 je rokem, kdy se to vyčistilo.

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

Abych byl upřímný: vyhrazená okrajová úroveň je v několika reálných případech zbytečná.

• Teleoperovaní roboti. Operátor je plánovač. Robot je loutka s řídicím článkem. Ve smyčce není žádný VLM; i to málo, co se děje (odhad pozice, kódování videa s nízkou latencí), může běžet na Jetsonu. V případě potřeby přidejte cloud pro jakoukoli těžkou práci. Není potřeba žádný GPU server.
• Jednoduchá inspekce čtyřnožců. Robot třídy Spot nebo Go2, který kráčí po pevné trase hlídky s detekcí na úrovni YOLO a termokamerou, nepotřebuje 72B VLM. Tuto práci vykoná palubní Jetson. Data se ukládají do cloudu k analýze po hlídce, nikoli během ní.
• Dema a jednorázové pilotní projekty. Potřebujete systém běžet na veletrhu, prezentaci zákazníkům nebo třítýdenní ověření konceptu. Cloud vás tam dostane za odpoledne. Kapitálové náklady na lokální prostředí jsou pro zátěž, která bude zrušena za měsíc, nevhodné.
• Využití pro koníčky a vzdělávání. Univerzitní laboratoř s jednou G1 EDU, omezeným rozpočtem a zaměřením na trénování RL spíše než na inferenci. Jetson a jedna pracovní stanice 4090 mohou hostit dostatek kapacity pro smysluplný výzkum. Plná úroveň Kentino AI 8× je špatný tvar účtu.
• Čistě jazykové úlohy. Robot, který mluví, ale nevidí – hlasový asistent na nohou. Cloudové LLM API je v pořádku. Latenční rozpočet je konverzační, ne uzavřená smyčka.

Vzor: pokud váš robot neběží skutečný VLM v uzavřené smyčce vnímání, nepotřebujete vyhrazenou okrajovou vrstvu. Pokud ano, pak ji potřebujete.

Když cesta k lokálnímu serveru prokáže důvod

Vyhrazená okrajová vrstva se stává správnou odpovědí, pokud je splněna alespoň jedna z následujících podmínek a ideálně dvě nebo více:

1. Skutečný VLM je v uzavřené smyčce. Ne „na občasné otázky“ – in smyčka od vnímání k akci, která probíhá každých 100–500 ms. To je strukturální důvod existence lokálního prostředí.
2. Trvalé zatížení. Osm hodin denně, pět dní v týdnu, na dobu neurčitou. Kapitálové náklady se amortizují. Cena za hovor v cloudu se hromadí na dobu neurčitou.
3. Data nemohou opustit budovu. GDPR, HIPAA, ITAR, konkurenční prostředí nebo prostá paranoia. Bajty zůstávají v místní síti. Neobchodovatelné.
4. Více robotů. Dvě nebo více jednotek sdílejících paměť scény nebo koordinujících úkoly. Amortizace sdíleného serveru je na robota a rozpočet na latenci mezi roboty se hroutí.
5. Na přizpůsobení záleží. Jemně vyladěné VLM, připnuté verze modelů, proprietární hlavice na otevřených páteřních sítích, kvantizace pro specifické oblasti. Svoboda je produkt.
6. Rychlost iterace je důležitá. Tým vydává aktualizace zásad jednou týdně nebo i rychleji. Simulace a školení na stejném hardwaru jako inference uzavírají cyklus z dnů na hodiny.

Pokud zaškrtnete tři nebo více z nich, otázkou už není, zda se jedná o on-premise systém, ale o jakou velikost . Čtyřnásobná úroveň Kentino AI 96 (RTX 4090 nebo 5090) je dostatečná pro jednoho robota vykonávajícího skutečnou práci. Osminásobná verze Kentino AI 256 (5090 nebo Pro 6000 Blackwell) je správná pro malou flotilu robotů, největší VLM nebo jakékoli nasazení s požadavkem na školení nad rámec inference.

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 vítány na adrese info@kentino.com.