Výpočty v robotu vs. mimo robota

Každý workload na robotu běží na jednom ze dvou míst: na palubě, kde čerpá z baterie a spoléhá na ventilátory v hrudi, nebo mimo palubu, na serveru napájeném ze sítě vzdáleném jeden skok po LAN. Těžká otázka nezní, zda potřebujete obojí — téměř vždy ano — ale který workload patří kam a proč. R08 vysvětluje, proč vůbec dává smysl samostatná edge vrstva. Tento článek řeší rozhodnutí workload po workloadu: řízení motorů sem, VLM tam, STT podle situace a tak dále.

Tento pohled je vyhraněný. Pro každý workload existuje správná odpověď a ta se mění, jak palubní čipy dohánějí náskok. U každé položky uvedeme, kterým směrem se v letech 2026–2027 posouvá.

Dva rozpočty, které rozhodují o všem

Workload může běžet na palubě právě tehdy, když se současně vejde do dvou rozpočtů: napájení a paměť. Latence je třetí omezení, ale obvykle napoví spíš to, kterým směrem posunout workload, který se vejde — ne to, zda se vejde vůbec.

Energetický rozpočet humanoida. Humanoid o hmotnosti 30–50 kg nese baterii 700–900 Wh. Trvalá chůze odebírá z aktuátorů 200–500 W, špičky při dynamickém pohybu přesahují 800 W. Stání na místě s „přemýšlením“ stojí 80–150 W (držet moment je levné, držet postoj už ne). Zbývá tedy zhruba 60–120 W na všechno ostatní — výpočetní výkon, senzory, ventilátory, rádio — pokud chcete použitelnou dvouhodinovou výdrž. Rozpočet na výpočty je v rámci této obálky 30–80 W trvale. Držet Jetson natrvalo v režimu MAX_N (60 W) zkrátí výdrž robota na polovinu. To je fyzika, o které se nevyjednává, ne otázka návrhu.

Paměťový rozpočet. Jetson AGX Orin 64 GB znamená 64 GB LPDDR5 sdílených mezi CPU a GPU. Odečtěte operační systém (4–6 GB), ROS 2 a SDK výrobce (2–4 GB), buffery pro vnímání (2–4 GB na stereo hloubku a mračna bodů) a vlastní aplikační kód. Reálně použitelný rozpočet pro LLM/VLM je 40–48 GB. U modulu Jetson Thor 128 GB strop stoupá na zhruba 96 GB využitelných. U Orin NX 16 GB klesá na ~8–10 GB — tedy na jeden malý model.

Mimo palubu jsou oba rozpočty zcela jiným problémem. Kentino AI 96 (4× RTX 5090) má 128 GB vyhrazené VRAM a 1.0–1.5 kW příkonu GPU ze sítě. Kentino AI 256 (8× RTX 5090) obojí zdvojnásobuje. Napájení a paměť prostě přestanou být limitem — výměnou za to řešíte investiční náklady, chlazení místnosti a drátovou síť.

Palubní křemík — realita roku 2026

Palubní platformy, které se dnes reálně dodávají v seriózních humanoidech a čtyřnohých robotech:

Thor není iterace, ale skok. Paměťový strop 128 GB a nativně FP4 tenzorová jádra Blackwell posouvají palubní hranici z „VLM 7B, a bolestivě“ na „VLM 32B, a užitečně“ během jediné generace. Workloady, které byly v roce 2025 strukturálně mimo palubu — středně velké VLM, průběžné popisování scény, LLM plánovače střední velikosti — se stávají kandidáty na palubu už v roce 2026, pokud tepelné řešení robota uchladí trvalých 100–130 W.

Hailo a podobné specializované NPU nejsou akcelerátory pro LLM. Slouží k odlehčení vision pipeline: hlavní Jetson zůstává volný pro větší model a trvale běžící kamerové CV (detekce objektů, sledování, základní VLM-lite) jede na čipu se 3 W.

Snapdragon třídy QRB je odpovědí pro roboty orientované na hlas — wake-word, beamforming, STT — kde je Jetson zbytečný a Cortex-M nedostačuje. Užitečné, úzce zaměřené a čím dál běžnější.

Mimo palubu: řada Kentino AI jako referenční vrstva

Cílovou platformou mimo palubu je v celé této sérii řada Kentino AI — napájená ze sítě, v racku 4U nebo 5U, se 4 nebo 8 GPU na platformě EPYC či Xeon, připojená k 10GbE switchi jeden skok od robota. Tři vrstvy, které jsou pro robotiku podstatné:

Rozhodovací matice

Každý robotický workload spadá přesně do jedné z pěti kategorií: vždy na palubě, spíše na palubě, obojí, spíše mimo palubu, pouze mimo palubu. Důvodem každého zařazení je limitující rozpočet — napájení, paměť, nebo latence.

Z této tabulky stojí za to vytáhnout tři závěry.

Řádky „vždy na palubě“ jsou fyzika. Žádné množství propustnosti nevyřeší řídicí smyčku, která potřebuje odezvu 1 kHz. Tyto položky se nepřesunou nikdy, ať už bude síť nebo externí výkon jakkoli dobrý.

Řádky „obojí“ jsou místem, kde se odehrává skutečné inženýrské rozhodování. Právě tady leží většina zajímavých kompromisů. To, zda VLM 7B běží na palubě nebo mimo ni, určuje podstatnou část chování celého systému. Univerzálně správná odpověď neexistuje.

Řádky „pouze mimo palubu“ se posouvají pomalu. Model 72B bude pravděpodobně i v roce 2027 pouze mimo palubu. Model 32B se na palubu přesune, jakmile se Thor začne dodávat ve velkém. Hranice toho, „co se vejde do zařízení“, se posouvá zhruba o jednu velikostní třídu modelu každých 18–24 měsíců.

Mapování latenčních vrstev

Čtyřúrovňový latenční rozpočet z článku I01 se na umístění mapuje přímo:

Právě ve dvou prostředních vrstvách leží skutečná architektonická rozhodnutí. Reflexní workload, který se těsně vejde do 50 ms, se může vejít mimo palubu po drátové LAN (0.5 ms cesta tam + 40 ms inference + 0.5 ms zpět = 41 ms), ale rozpočet přestřelí po zatíženém Wi-Fi 6E (8 ms × 2 + 40 ms = 56 ms, plus jitter). Proto jsou při vývoji drátové propojky důležité: ukážou vám, zda se workload principiálně vejde mimo palubu, ještě než začnete bojovat s bezdrátovou sítí.

Realita sítě

Mimo palubu to funguje jen tehdy, když funguje síť. Skutečná čísla:

Pro deliberativní workloady (rozpočet 100 ms – 1 s) stačí Wi-Fi 6E na vyhrazeném SSID s přístupovým bodem v přímé viditelnosti. Pro reflexní workloady (10–50 ms) je drát bezpečná odpověď a Wi-Fi 6E odpověď se štěstím. Plánujte podle toho: má-li úloha robota jakoukoli reflexní část mimo palubu, navrhněte drátovou variantu pro vývoj a záložní režim pro chvíle, kdy se Wi-Fi zhorší.

Hybridní vzor — rozdělení rychlý/pomalý

Vzor, ke kterému v roce 2026 konverguje většina seriózních nasazení, je rozdělení VLM na rychlý a pomalý: malý VLM na palubě pro okamžitou zpětnou vazbu, velký VLM mimo palubu pro uvážená rozhodnutí, oba vstupují do téhož plánovače.

Konkrétní podoba:

Rozdělení rychlý/pomalý: palubní 7B řeší okamžitou reakci, mimopalubní 72B uvážené uvažování a aktualizace plánu.

Rychlý model řeší „jde proti mně člověk, zpomal“. Pomalý model řeší „člověk, který jde proti mně, je operátor, a ten mě požádal, abych se zastavil, pokud přijde s červenou deskou — a tohle je červená deska, takže zastav“. Rychlý model se nejprve zaváže k bezpečnému chování, pomalý model ho pak vylepší.

Příběh migrace — co se v letech 2026–2027 přesune na palubu

Stranu mimo palubu stlačují tři síly: Thor přichází ve velkých objemech (2070 FP4 TFLOPS, 128 GB sdílené paměti, obálka 130 W — strukturální skok oproti Orinu); efektivita VLM se stále zlepšuje („dostatečně dobrý“ vnímací VLM měl v roce 2024 přes 70B, v roce 2026 má 32B a v roce 2027 to bude pravděpodobně 13B–20B); a spekulativní dekódování s malými návrhovými modely umožňuje dodávat kvalitu velkého modelu při latenci malého.

Workloady, které se během příštích 18 měsíců přesunou na palubu nejspíš jako první: scénický VLM třídy 7B (už se přesouvá), LLM plánovač 13B (na Thoru pohodlně), řetězec STT-LLM-TTS s krátkým kontextem pro hlas a doménově doladěné VLM 7B.

Workloady, které se nepřesunou nikam: cokoli nad 70B, paměť scény v měřítku celé flotily, trénink a simulace, fúze VLM z více streamů. Ty zůstanou mimo palubu minimálně do roku 2027. Paměťová propustnost a kapacita baterií se tak rychle neohýbají.

Dvě konkrétní konfigurace

Jeden G1 EDU ve výzkumné laboratoři. Palubní AGX Orin provozuje ROS 2, YOLOv11-s při 30 FPS, STT Whisper-distil a Qwen2.5-VL 7B INT4 při 5–8 FPS (deliberativně). Mimo palubu běží Kentino AI 96 (4× RTX 5090, 128 GB VRAM) s vLLM, modely Qwen2.5-VL 72B a Qwen2.5 32B pouze textově, pamětí scény nad pgvector a Isaac Sim na nevytížených GPU.

Malá flotila, 3 humanoidi, palubní platforma třídy Thor. Každá jednotka má vision SoC Hailo-15 pro trvalou detekci z více kamer, Whisper-small přímo v zařízení a Qwen2.5-VL 32B INT4 při 10–15 FPS — nativně a už bez kompromisů. Mimo palubu hostuje Kentino AI 256 (8× RTX 5090, 256 GB VRAM) sdílený Qwen2.5-VL 72B a Llama-3.1 70B pro plánování, sdílené úložiště pgvector pro všechny tři roboty a dvě GPU vyhrazená na noční doladění LoRA.

Kde čistě jednovrstvé nasazení opravdu funguje

Čistě palubní řešení funguje pro úzce zaměřené čtyřnohé roboty (obchůzka perimetru s YOLO a termokamerou), teleoperované roboty (plánovačem je operátor, ve smyčce není žádný VLM), předváděcí a výukové roboty s nejmenšími modely a jakékoli nasazení zcela bez sítě (venkovní inspekce, odlehlé lokality).

Čistě cloudové řešení funguje pro hlasové robotické asistenty bez uzavřené vnímací smyčky, prototypy, kde rychlost zprovoznění přebíjí vše ostatní, a nasazení, kde data stejně záměrně putují do cloudového workloadu.

Hybridní řešení je odpovědí pro všechno mezi tím — tedy zhruba pro 90 % seriózní robotiky roku 2026. Pokud stavíte cokoli s vnímáním, kde je VLM ve smyčce, skončíte u obou vrstev. Počítejte s tím od prvního dne.

---

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