Proč roboti potřebují vyhrazený edge výkon

Humanoid, který chodí, je vyřešený problém. Humanoid, který rozumí tomu, na co se dívá, naplánuje vícekrokovou úlohu a pamatuje si, co se stalo před pěti minutami, vyřešený není. Výpočetní výkon, který tuto mezeru zaplní, se do robota nevejde — a cloud je pro něj špatné místo. Tento článek je technickou argumentací, proč je vyhrazený on-prem inferenční server v roce 2026 tou nejpokročilejší odpovědí pro každé nasazení robotiky, které má odvádět skutečnou práci.

I01 popisuje, jak jsou robot a server propojeny. Tento článek vysvětluje, proč byste server vůbec měli pořizovat. Pokud se stále ptáte, zda má on-prem řešení smysl, začněte tímto textem.

Rozpočet rozhodovací latence

Každá akce robota spadá do jedné ze čtyř latenčních úrovní. Každá úroveň má rozpočet, který jí vnucuje fyzika dané úlohy — pokud jej překročíte, chování se rozpadne specifickým a dobře rozpoznatelným způsobem.

Tyto hodnoty nejsou libovolné. Vycházejí z šířky pásma uzavřené smyčky, ve které daná vrstva pracuje.

Reaktivní řízení běží na úrovni kloubu na 500 Hz až 1 kHz, protože to vyžaduje dynamika nohy 30kg humanoida — při 100 Hz končetina rezonuje a chůze se rozpadá. Reflexivní vnímání přebírá snímkovou frekvenci kamer (30–60 FPS = 16–33 ms na snímek) a časové měřítko fyzického kontaktu (prst tlačící na předmět uzavře kontaktní událost za 20–40 ms). Deliberativní plánování je omezeno lidskými očekáváními od konverzace (jedna sekunda působí svižně, dvě už pomalu) a latencí použitelného VLM modelu. Strategické uvažování je jediná úroveň se skutečnou rezervou — proto do ní chce každý přesunout plánování a pak narazí, když jeho VLM nestíhá.

Tohle není názor Kentina. Čtyřúrovňový rozpočet je rozdělení, které má zabudované každý věrohodný řídicí stack robotů — ROS 2, Isaac, Drake i OCS2. Liší se jen to, jaký hardware za jednotlivé úrovně postavíte.

Co palubní výpočetní výkon zvládne a co už ne

Humanoid roku 2026 veze na špičce specifikace NVIDIA Jetson AGX Orin — 64 GB sjednocené paměti, až 275 sparse INT8 TOPS (138 dense), konfigurovatelný příkon 15–60 W. Na vestavěný modul je to skutečně působivé. A zároveň je to zdaleka ne to, co moderní robot řízený VLM potřebuje.

Spočítejte si to na třech třídách modelů, které byste v humanoidovi reálně chtěli používat:

Orin AGX 64 GB utáhne VLM třídy 32B v INT4, pokud se smíříte s pomalou inferencí, žádným reálným dávkováním a žádnými souběžnými workloady. Neutáhne ale VLM třídy 70B, které jsou v roce 2026 špičkou pro porozumění scéně — Qwen2.5-VL 72B, větší varianty Cosmos nebo proprietární modely, jejichž váhy dodavatelé nezveřejňují. Váhy dohromady s KV cache pro dlouhý vizuální kontext a jakýmkoli prostorem pro druhý model se prostě nevejdou.

Je tu ještě druhé číslo, které se běžně přechází: příkon. Údaj 275 TOPS u Orinu předpokládá režim MAX_N (60 W). To je bateriově napájená platforma, která na výpočty spálí 60 W nad rámec 200–800 W zátěže aktuátorů. Trvalý MAX_N zkracuje výdrž robota na polovinu. V praxi tráví Orin většinu času v režimu 30 W, což zhruba půlí TOPS a posouvá už tak hraniční inferenci do území „nepoužitelné“.

Překlad do praxe: palubní Jetson je dimenzovaný na reaktivní a reflexivní úroveň. Není dimenzovaný na to, aby hostoval VLM. Kdokoli Vám tvrdí, že jeho humanoid „běží s Qwen2.5-VL přímo na palubě“, buď provozuje model 3B či 7B a vydává to za dostatečné, nebo pouští větší model na 0.5 FPS a říká tomu demo. Obojí má v konkrétních případech smysl. Ani jedno není univerzální robotické vnímání.

Proč je cloud pro robotiku v uzavřené smyčce špatná odpověď

Cloudová inference je levná, škáluje bez námahy a nevyžaduje žádné investiční výdaje. Pro robota má ale čtyři problémy, zhruba v pořadí podle závažnosti.

1. Spodní hranice latence WAN. Dobře vyladěné cloudové volání v rámci EU se na samotné WAN vejde do 15–40 ms obousměrně, k tomu 5–15 ms režie TLS / HTTP / load balanceru, k tomu doba inference modelu a cesta zpět. Transatlantické spojení přidá dalších 80–120 ms obousměrně. U reflexivního dotazu vnímání — „je přede mnou překážka?“ — je přidání 30–50 ms ještě předtím, než se model vůbec rozběhne, překročením rozpočtu. U deliberativního plánování na 200–500 ms to snad tolerovat lze, jenže každý zahozený paket, každé opakované odeslání a každý výpadek mobilní buňky Vás vystřelí o úroveň výš.

2. Jitter. RTT na WAN 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ě si nemůže dovolit několikasekundovou pauzu jen proto, že se přepnula BGP trasa. On-prem LAN má P99.9 na úrovni 1–2 ms.

3. Náklady při trvalé zátěži. Jediná inference VLM třídy 70B stojí poskytovatele cloudu takřka nic — účtuje si pár centů. Robot, který „neustále vnímá“, provede jedno volání VLM každých 100–500 ms, dokud je aktivní. To je 7,000–36,000 volání za hodinu na jednoho robota. Flotila tří robotů pracujících osm hodin denně je v horní hranici 850,000 volání. I při 0.005 $ za volání na hostovaném endpointu 72B to dělá 4,250 $ denně a 125k $ měsíčně. On-prem server s 8× GPU se při takové zátěži vrátí do tří měsíců.

4. Datová suverenita. Robot vidí výrobní halu, nemocniční pokoj, výzkumnou laboratoř, sklad s důvěrným rozložením zásob nebo vojenské cvičiště. Takové video je chráněné nebo regulované podle GDPR, HIPAA, ITAR — anebo prostě konkurenčně citlivé. Odesílat je do cloudu třetí strany, byť s podepsanou smlouvou o zpracování osobních údajů, je buď zakázané, nebo znamená netriviální compliance zátěž. On-prem inference otázku datové suverenity ruší: bajty nikdy neopustí budovu.

Je tu i pátý, měkčí problém: vendor lock-in. Cloudová API nabízejí modely, které chce nabízet poskytovatel, v kvantizacích a s kontextovými okny, jež zvolil on. Doladěný VLM model na endpointu OpenAI nespustíte. Konkrétní commit modelu s otevřenými vahami si nezafixujete. Modely konkurenčních dodavatelů v jedné pipeline nezkombinujete. Pro prototypování jsou tato omezení v pořádku. Pro produkční nasazení robotiky, které musí být roky předvídatelné, nikoli.

Argumenty pro vyhrazený edge server

Vyhrazený on-prem inferenční server je umístěn v LAN, jeden až dva skoky od robota. U řady Kentino Kentino AI jde o 4U rackový server, hostitelský EPYC nebo Xeon, 4× nebo 8× GPU, na 10GbE switchi. Čísla, která přináší:

Dva sloupce, v nichž on-prem varianta dominuje, jsou trvalá propustnost a volba modelu. A právě tyto dva sloupce jsou pro workloady, které si za chvíli vyjmenujeme, nejdůležitější.

Reprezentativní Kentino AI 256 Turin Dual s 8× RTX 5090 nabízí 256 GB agregované VRAM a 1.0–1.5 kW příkonu GPU pod zátěží. To stačí na současné hostování:

• Qwen2.5-VL 72B v INT4 (~45–50 GB váhy + 10–20 GB KV na dvojici GPU, tensor-paralelně přes 4 GPU)
• Qwen2.5 32B pouze textový (plánování, dialog) na 2 GPU
• Malý VLA model (OpenVLA 7B nebo Cosmos-Reason 7B) na 1 GPU pro záměr pohybu
• Paměť scény / úložiště RAG (pgvector nebo ChromaDB) na hostitelském CPU
• Kapacitu pro online doladění policy na zbývajícím GPU, zatímco je robot v dokovací stanici

TTFT modelu Qwen2.5-VL 72B se na tomto hardwaru pohybuje v rozmezí 200–400 ms při zátěži jediného požadavku a roste na 1–4 sekundy při vysoké souběžné zátěži. Streamování tokenů běží na 25–50 tok/s. To stačí na zařazení 72B VLM do úrovně deliberativního plánování (100 ms – 1 s) při zátěži jediného robota a do úrovně strategického uvažování (1 s – několik s) u malé flotily. Ani jedna úroveň není problém; reaktivní a reflexivní vrstva zůstávají na palubě, kam patří.

Rozdíl ve schopnostech: co obslouží jen vyhrazená edge vrstva

On-prem server není jen „tentýž robot, ale rychlejší“. Umožňuje celou třídu workloadů, které zbylé dvě úrovně strukturálně hostovat nedokážou. Poctivý seznam:

1. Zpětná vazba z porozumění scéně v reálném čase. VLM o 72B parametrech se každých 200–500 ms dívá do robotovy kamery a vrací strukturovaný popis scény, který konzumuje plánovač. Cloud to ve větším měřítku nezvládne kvůli jitteru na WAN a kvůli nákladům. Palubní výkon to nezvládne, protože se model nevejde. On-prem uzavře 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 / hrudi). Provozovat VLM nad všemi současně — kvůli prostorovému ukotvení, řešení okluzí nebo koordinaci ruka–oko — znamená pětinásobnou inferenční zátěž. Cloud buď omezí rychlost, nebo si účtuje za každý stream. Palubní výkon zvládne jeden stream v malém měřítku. On-prem všech pět dávkově protáhne stejným VLM endpointem.

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. Tento stav musí žít někde stabilně, dotazovatelně a rychle. To je databáze na serveru — ne kontextové okno cloudu pro jedno volání a ne 4 GB RAM na Jetsonu.

4. Online doladění policy. Robot během dne sbírá demonstrace úloh. V noci, zatímco je v doku, spustíte LoRA doladění na datech z daného dne proti základnímu VLA modelu, nasadíte aktualizovaný adaptér — a robot je zítra lepší. To znamená dvoj- až pětinásobnou paměťovou stopu oproti inferenci. Cloud účtuje trénink a úložiště zvlášť. On-prem to pohltí do téže skříně.

5. Koordinace flotily více robotů. Dva nebo tři roboti sdílejí paměť scény, koordinují úlohy a sledují stav jeden druhého. Vrstva koordinace mezi roboty potřebuje latenci pod 10 ms. On-prem se sdíleným serverem v LAN to dodá. Cloud ne — aktualizace každého robota putuje do regionu, zpět a teprve pak k dalšímu robotovi.

6. Iterace sim-to-real. Isaac Sim běžící na týchž GPU, která obsluhují inferenci, generuje syntetická trénovací data a ověřuje aktualizace policy dřív, než dorazí ke skutečnému robotovi. V cloudu je to půl dne na jednu iteraci (jen kvůli přesunu dat), on-prem třicetiminutová smyčka.

Nic z toho není sci-fi. Všechno jsou to workloady, které integrátoři robotiky v roce 2026 reálně provozují. A žádný z nich nefunguje čistě na zbylých dvou úrovních.

Proč je to v roce 2026 ta nejpokročilejší odpověď

Špičkou v robotickém vnímání je v roce 2026 přístup VLM v uzavřené smyčce. Model se dívá na svět, uvažuje o něm v jazyce, vydává strukturované plány a policy je vykonává. V roce 2023 to byl výzkumný nápad, v roce 2024 produktové demo a v letech 2025–2026 je to produkční vzor.

Trend, který on-prem vrstvu vynucuje, je přímočarý: VLM modely, které fungují, se zvětšují, nikoli zmenšují. Qwen2.5-VL 7B je dobrý. Qwen2.5-VL 72B je výrazně lepší. Proprietární modely, které špičkové laboratoře nezveřejňují, jsou ještě větší. Cesta „malého VLM běžícího přímo v zařízení“ existuje a existovat bude, ale za špičkou zaostává o 12–18 měsíců a o citelný rozdíl ve schopnostech. Pokud chcete chování na úrovni špičky, musíte hostovat špičkový model. A ten se do Jetsonu nevejde.

Cloud by teoreticky stačit mohl. V praxi nestačí — ze čtyř výše uvedených důvodů (latence, jitter, náklady, suverenita) a také proto, že špičkové laboratoře zpřístupňují největší modely jen partnerským úrovním, na které robotický startup nedosáhne. VLM třídy 70B s otevřenými vahami ovšem existují, lze je hostovat a na běžných serverech s 8 GPU běží dobře. Právě tento souběh — modely špičkové třídy s otevřenými vahami plus běžně dostupný multi-GPU hardware — je důvodem, proč je on-prem správnou odpovědí právě teď a proč jí v roce 2023 nebyl.

Ani tohle není názor Kentina. On-prem inferenční vrstva je tím, kolem čeho je postavený Isaac stack od NVIDIE, pro co hlavní robotické platformy dodávají referenční architektury, a co si pořizuje každý seriózní integrátor, s nímž jsme za posledních šest měsíců mluvili. Trh dohnal hardware, hardware dohnal modely — a rok 2026 je ten, kdy se to vyčistilo.

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

Abychom byli poctiví: vyhrazená edge vrstva je v několika reálných případech zbytečný luxus.

• Teleoperovaní roboti. Plánovačem je operátor. Robot je loutka s řídicí linkou. V uzavřené smyčce není žádné VLM; to málo inference, co probíhá (odhad pózy, nízkolatenční kódování videa), zvládne Jetson. Na náročnější úlohy případně přidejte cloud. Žádný GPU server není potřeba.
• Jednoduché inspekční čtyřnožky. Robot třídy Spot nebo Go2, který obchází pevnou obchůzkovou trasu s detekcí na úrovni YOLO a termokamerou, VLM o 72B parametrech nepotřebuje. Palubní Jetson práci odvede. Data putují do cloudu k analýze až po obchůzce, ne během ní.
• Dema a jednorázové pilotní projekty. Potřebujete systém rozběhnout na veletrh, zákaznickou prezentaci nebo třítýdenní proof of concept. Cloud Vás tam dostane během odpoledne. Investice do on-prem je u workloadu, který se za měsíc zruší, špatná volba.
• Hobby a výuka. Univerzitní laboratoř s jedním G1 EDU, omezeným rozpočtem a důrazem na RL trénink spíš než na inferenci. Jetson a jediný workstation s 4090 utáhnou dost na smysluplný výzkum. Plná vrstva Kentino AI 8× je v takovém případě špatně nastavený účet.
• Čistě jazykové workloady. Robot, který mluví, ale nevidí — hlasový asistent na nohou. Cloudové LLM API bohatě stačí. Rozpočet latence je konverzační, ne v uzavřené smyčce.

Vzorec je jednoduchý: pokud Váš robot neprovozuje skutečné VLM v uzavřené percepční smyčce, vyhrazenou edge vrstvu nepotřebujete. Pokud ano, potřebujete ji.

Kdy on-prem cesta dává smysl

Vyhrazená edge vrstva se stává správnou odpovědí, jakmile platí alespoň jedno z následujícího — a ideálně dvě a více:

1. V uzavřené smyčce je skutečné VLM. Ne „na občasné dotazy“ — ale přímo uvnitř smyčky od vnímání k akci, s během každých 100–500 ms. To je strukturální důvod, proč on-prem existuje.
2. Trvalá zátěž. Osm hodin denně, pět dní v týdnu, bez konce. Investice se amortizuje. Cloudové náklady na volání se naproti tomu kumulují donekonečna.
3. Data nesmí opustit budovu. GDPR, HIPAA, ITAR, konkurenční citlivost nebo prostá opatrnost. Bajty zůstávají v LAN. Nediskutovatelné.
4. Více robotů. Dvě a více jednotek sdílí paměť scény nebo koordinuje úlohy. Amortizace sdíleného serveru se rozpočítá na robota a rozpočet latence mezi roboty se dramaticky stlačí.
5. Záleží na přizpůsobení. Doladěné VLM modely, zafixované verze modelů, proprietární hlavy na otevřených páteřních sítích, specifické kvantizace. Produktem je právě ta svoboda.
6. Záleží na rychlosti iterací. Tým nasazuje aktualizace policy každý týden nebo častěji. Simulace a trénink na stejném hardwaru jako inference zkracují smyčku ze dnů na hodiny.

Pokud si odškrtnete tři a více bodů, otázkou už není zda on-prem, ale jak velký. Vrstva Kentino AI 96 se čtyřmi GPU (RTX 4090 nebo 5090) stačí na jednoho robota odvádějícího skutečnou práci. Osm GPU v Kentino AI 256 (5090 nebo Pro 6000 Blackwell) má správné parametry pro malou flotilu, pro největší VLM modely nebo pro jakékoli nasazení, kde se k inferenci přidává i trénink.

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