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 pokrývá jak Robot a server jsou propojeny kabelem. Tento článek je proč Vůbec byste si ten server koupili. Pokud se stále ptáte, zda má on-premise smysl, přečtěte si nejdříve 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: Integrovaný Jetson je dimenzován pro reaktivní a reflexivní úrovně. Není dimenzován pro VLM hostitele. Každý, kdo vám řekne, že jeho humanoid „běží na integrovaném Qwen2.5-VL“, buď používá 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é volání v rámci EU dosahuje doby přenosu dat v síti WAN 15–40 ms, plus 5–15 ms režijních nákladů na TLS / HTTP / vyrovnávač zátěže, plus dobu inference modelu a cestu zpět. Transatlantic přidává 80–120 ms přenosu dat. Pro... reflexní dotaz na vnímání – „je přede mnou překážka?“ – přidání 30–50 ms před samotným spuštěním modelu představuje porušení rozpočtu. Pro poradní Při plánování na 200–500 ms to možná tolerujete, ale každý zahozený paket, každý opakovaný přenos, každé přepnutí vysílače při selhání vás přesune na další úroveň.

2. Chvění. WAN RTT není konstanta. Je to rozdělení. 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 objemu 70 bitů nestojí poskytovatele cloudu téměř nic – účtuje 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é třídě představuje 850 000 volání. Při pouhých 0.005 dolaru za volání na hostovaném 72B endpointu to je 4 250 dolarů za den, 125 tisíc 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 pacienta, 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 podle citlivosti konkurence. Jeho odeslání do cloudu třetí strany – i takové, která podepisuje dohodu o zpracování dat – je buď zakázáno, nebo představuje netriviální zátěž z hlediska dodržování předpisů. Inference v místních podmínkách eliminuje otázku datové suverenity: bajty nikdy neopouštějí budovu.

Existuje pátý, méně závažný problém: uzamčení dodavateleCloudová API slouží modelům, které chce poskytovatel zobrazovat, s kvantizacemi a kontextovými okny, které poskytovatel zvolil. 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 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 K-AI 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 výběr modeluTo jsou také dva sloupce, které jsou nejdůležitější pro úlohy, které se chystáme vyjmenovat.

Reprezentativní grafická karta K-AI 256 Turin Dual s 8× RTX 5090 má celkem 256 GB VRAM a výkon grafického procesoru 1.0–1.5 kW při 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, kterou plánovač zpracovává. Cloud to nemůže provést ve velkém měřítku kvůli chvění a nákladům WAN. Integrovaný systém to nemůže provést, protože model neodpovídá. 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 5násobek inferenční zátěže. Limity rychlosti cloudu nebo poplatky za stream. Na desce se vejde jeden stream v malém měřítku. On-premise dávkově nasměruje 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. Doladění online politik. Robot během dne shromažďuje ukázky úloh. Přes noc, když je v doku, spustíte LoRA, která doladí denní data oproti základnímu VLA, nainstalujete aktualizovaný adaptér a robot je zítra v lepším stavu. To představuje 2× až 5× větší paměťovou náročnost než inference. Cloud účtuje školení a úložiště odděleně. On-premise je absorbuje do stejného zařízení.

5. Koordinace flotily více robotů. Dva nebo tři roboti sdílející paměť scény, koordinující úkoly a sledující navzájem 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 osloví dalšího robota.

6. Iterace simulace/reálu. Isaac Sim běží na stejných GPU, které slouží pro inferenci, generuje syntetická trénovací data a ověřuje aktualizace politik předtím, než se dostanou ke skutečnému robotovi. V cloudu se jedná o půl dne na iteraci (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ší vnímání robotů v roce 2026 je VLM ve smyčceModel se dívá na svět, argumentuje o něm v jazyce, generuje strukturované plány a politika je realizuje. Toto byl výzkumný nápad v roce 2023, produktová demonstrace v roce 2024 a produkční vzorec v letech 2025–2026.

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 hraniční laboratoře shromažďují největší modely za partnerskými úrovněmi, ke kterým robotický startup nemá přístup. VLM s otevřenou hmotností třídy 70B. do existovat, umět být hostovány a dobře fungovat na komoditních serverech s 8 GPU. Tato souhra – otevřené modely Frontier třídy a komoditní hardware s více GPU – je důvodem, proč je on-premise právě teď tou správnou odpovědí, a v roce 2023 nebyla.

Ani toto není názor Kentina. Inferenční vrstva pro lokální prostředí 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, dohnal modely a rok 2026 je rokem, kdy se situace vyčistila.

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 školení RL spíše než na inferenci. Jetson a jedna pracovní stanice 4090 mohou hostit dostatek kapacity pro smysluplný výzkum. Plná úroveň K-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ázka již nezní if lokálně, ale která velikostČtyřnásobná grafická karta K-AI 96 (RTX 4090 nebo 5090) postačuje pro jednoho robota vykonávajícího skutečnou práci. Osminásobná karta K-AI 256 (5090 nebo Pro 6000 Blackwell) je ideální 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.