Prečo roboty potrebujú špecializované Edge Compute

Humanoid, ktorý chodí, je vyriešený problém. Humanoid, ktorý rozumie, na čo sa pozerá, plánuje viacstupňovú úlohu a pamätá si, čo sa stalo pred piatimi minútami, nie je. Výpočtové prostriedky, ktoré túto medzeru vyriešia, sa nezmestia do robota a cloud nie je na ich umiestnenie to pravé miesto. Tento článok je technickým argumentom, prečo je vyhradený lokálny inferenčný server v roku 2026 najmodernejším riešením pre akékoľvek nasadenie robotiky dostatočne seriózne na to, aby vykonávalo užitočnú prácu.

I01 kryty ako Robot a server sú prepojené káblom. Tento článok je prečo Vôbec by ste si kúpili server. Ak sa stále pýtate, či má on-premise zmysel, prečítajte si najprv toto.

Rozpočet latencie rozhodovania

Každá akcia, ktorú robot vykoná, sa nachádza v jednej zo štyroch úrovní latencie. Každá úroveň má limit stanovený fyzikou úlohy – ak ho vynecháte, správanie sa naruší špecifickým a rozpoznateľným spôsobom.

Tieto nie sú ľubovoľné. Pochádzajú zo šírky pásma uzavretej slučky, v ktorej sa nachádzajú.

Reaktívne riadenie prebieha na úrovni kĺbov pri frekvencii 500 Hz až 1 kHz, pretože si to vyžaduje dynamika 30 kg humanoidnej nohy – pri 100 Hz končatina rezonuje a chôdza sa rozbieha. Reflexné vnímanie dedí snímkové frekvencie kamery (30 – 60 FPS = 16 – 33 ms na snímku) a časový harmonogram fyzického kontaktu (stlačenie prsta na objekt ukončí kontaktnú udalosť za 20 – 40 ms). Zámerné plánovanie je ohraničené ľudskými konverzačnými očakávaniami (jedna sekunda sa zdá byť responzívna, dve pomalé) a latenciou modelu užitočného VLM. Strategické uvažovanie je jedinou úrovňou so skutočným voľnom priestorom, a preto chce každý doňho vložiť plánovanie a dostane sa do problémov, keď jeho VLM nedokáže držať krok.

Toto nie je názor Kentina. Štvorúrovňový rozpočet je rozdelenie, ktoré obsahuje každý dôveryhodný balík riadenia robotov – ROS 2, Isaac, Drake, OCS2. Rozdiel je v tom, aký hardvér umiestnite za každú vrstvu.

Čo dokáže a čo nemôže urobiť palubný počítač

Humanoid z roku 2026 nesie na vrchole špecifikácií procesor NVIDIA Jetson AGX Orin – 64 GB unifikovanej pamäte, až 275 riedkych INT8 TOPS (138 hustých), konfigurovateľný výkon 15 – 60 W. To je na vstavaný modul skutočne pôsobivé. Zároveň sa to však ani zďaleka nepribližuje tomu, čo by moderný robot poháňaný VLM chcel.

Vypočítajte si tri modelové triedy, ktoré by humanoid mohol skutočne chcieť použiť:

Orin AGX 64 GB bude hostiť VLM triedy 32B na INT4, ak akceptujete pomalú inferenciu, žiadne skutočné dávkovanie a žiadne súbežné pracovné zaťaženia. Nebude hostiť VLM triedy 70B, ktoré sú v roku 2026 najmodernejšie pre pochopenie scén – Qwen2.5-VL 72B, väčšie varianty Cosmos, proprietárne modely, pre ktoré dodávatelia nezverejňujú váhy. Kombinované váhy, KV vyrovnávacia pamäť pre dlhý vizuálny kontext a akýkoľvek priestor pre druhý model sa nezmestia.

Druhé číslo sa prehliada: výkon. Údaj 275 TOPS robota Orin predpokladá režim MAX_N (60 W). Ide o platformu napájanú z batérie, ktorá spotrebuje 60 W výpočtového výkonu a navyše zaťažuje aktuátor 200 – 800 W. Trvalý režim MAX_N skracuje prevádzkový čas robota na polovicu. V praxi Orin trávi väčšinu času v režime 30 W, čo znižuje výkon TOPS zhruba na polovicu a posúva už aj tak marginálnu inferenciu do „nepoužiteľnej“ zóny.

Preklad: Integrovaný Jetson je dimenzovaný pre reaktívne a reflexívne úrovne. Nie je dimenzovaný ako hostiteľ VLM. Každý, kto vám povie, že jeho humanoid „používa integrovaný Qwen2.5-VL“, používa buď model 3B alebo 7B a nazýva ho dobrým, alebo používa väčší model s 0.5 FPS a nazýva ho demo. Oba sú platné pre špecifické prípady použitia. Ani všeobecné vnímanie robota nie je platné.

Prečo je cloud nesprávnym riešením pre robotiku s uzavretou slučkou

Cloudová inferencia je lacná, bez námahy škálovateľná a nevyžaduje žiadne kapitálové výdavky. Pre robota predstavuje štyri problémy, zhruba zoradené podľa závažnosti.

1. Minimálna latencia WAN. Dobre vyladený cloudový hovor v rámci EÚ dosahuje 15 – 40 ms spiatočnej cesty na samotnej WAN, plus 5 – 15 ms réžie TLS / HTTP / vyrovnávača záťaže, plus čas inferencie modelu a spätnú cestu. Transatlantic pridáva 80 – 120 ms spiatočnej cesty. Pre reflexívny otázka vnímania – „je predo mnou prekážka?“ – pridanie 30 – 50 ms pred samotným spustením modelu predstavuje porušenie rozpočtu. Pre deliberatívny Pri plánovaní na úrovni 200–500 ms to možno tolerujete, ale každý stratený paket, každý opakovaný prenos, každé prepnutie na záložnú vežu mobilnej siete vás presunie na ďalšiu úroveň.

2. Chvenie. WAN RTT nie je konštanta. Je to rozdelenie. Medián 25 ms, P99 250 ms, P99.9 niekoľko sekúnd. Robot konajúci v reálnom svete nemôže akceptovať niekoľkosekundovú pauzu, pretože trasa BGP sa prerušila. On-premise LAN P99.9 je 1–2 ms.

3. Náklady pri trvalom zaťažení. Jedna 70B VLM inferencia nestojí poskytovateľa cloudu takmer nič – účtuje si pár centov. Robot, ktorý „neustále vníma“, vykoná jedno VLM volanie každých 100 – 500 ms, keď je aktívny. To je 7 000 – 36 000 volaní za hodinu na robota. Flotila troch robotov bežiacich osem hodín denne vo vyššej kategórii predstavuje 850 000 volaní. Pri cene dokonca 0.005 USD za volanie na hostovanom 72B endpointe je to 4 250 USD za deň, teda 125 000 USD za mesiac. Lokálny 8× GPU server sa pri tomto zaťažení zaplatí za menej ako tri mesiace.

4. Zvrchovanosť údajov. Robot vidí výrobnú halu, izbu pacienta, výskumné laboratórium, sklad s proprietárnym usporiadaním zásob, vojenské cvičisko. Toto video je privilegované alebo regulované podľa GDPR, HIPAA, ITAR alebo jednoducho z dôvodu citlivosti konkurencie. Jeho odoslanie do cloudu tretej strany – aj takého, ktorý podpisuje dohodu o spracovaní údajov – je buď zakázané, alebo predstavuje netriviálnu záťaž v oblasti dodržiavania predpisov. Inferencia na lokálnej úrovni eliminuje otázku suverenity údajov: bajty nikdy neopúšťajú budovu.

Existuje piaty, mäkší problém: uzamknutie predajcuCloudové API slúžia modelom, ktoré chce poskytovateľ poskytovať, s kvantizáciami a kontextovými oknami, ktoré si poskytovateľ vybral. Na koncovom bode OpenAI nemôžete spustiť doladený VLM. Nemôžete pripnúť konkrétny commit modelu s otvorenou váhou. Nemôžete kombinovať modely od konkurenčných dodávateľov v jednom kanáli. Pre prototypovanie sú tieto obmedzenia v poriadku. Pre nasadenie produkčnej robotiky, ktoré musí byť predvídateľné roky, nie sú.

Prípad dedikovaného edge servera

Vyhradený lokálny inferenčný server sa nachádza v lokálnej sieti LAN, jeden alebo dva skoky od robota. V prípade radu Kentino K-AI ide o 4U rackový server, hostiteľ EPYC alebo Xeon, 4× alebo 8× GPU, na 10 GbE prepínači. Čísla, ktoré prináša:

Dva stĺpce, v ktorých dominuje lokálna možnosť, sú trvalá priepustnosť a výber modeluTo sú tiež dva stĺpce, ktoré sú najdôležitejšie pre pracovné zaťaženia, ktoré sa chystáme vymenovať.

Reprezentatívna grafická karta K-AI 256 Turin Dual s 8× RTX 5090 má celkovo 256 GB VRAM a výkon grafického procesora 1.0–1.5 kW pri zaťažení. To stačí na súčasné spustenie:

• Qwen2.5-VL 72B na INT4 (~45–50 GB váhy + 10–20 GB KV na pár GPU, tenzorovo paralelne medzi 4 GPU)
• Qwen2.5 32B iba textový (plánovanie, dialógy) na 2 GPU
• Malá VLA (OpenVLA 7B alebo Cosmos-Reason 7B) na 1 GPU pre motion intent
• Pamäť scén / RAG úložisko (pgvector alebo ChromaDB) na hostiteľskom CPU
• Doladenie kapacity online pravidiel na zostávajúcej grafickej karte, keď je robot pripojený k doku

VLM TTFT pre Qwen2.5-VL 72B na tomto hardvéri sa pri zaťažení jednou požiadavkou pohybuje v rozsahu 200 – 400 ms, pričom pri veľkom súbežnom zaťažení sa zvyšuje na 1 – 4 sekundy. Streamovanie tokenov je 25 – 50 token/s. To stačí na to, aby sa 72B VLM dostal do úrovne deliberatívneho plánovania (100 ms – 1 s) pri zaťažení jedným robotom a do úrovne strategického uvažovania (1 s – viacero s) pre malú flotilu. Ani jedna z úrovní nie je problémom; reaktívna a reflexívna úroveň zostávajú na palube tam, kam patria.

Rozdiel v schopnostiach: čomu slúži iba vyhradená okrajová vrstva

Lokálny server nie je len „ten istý robot, ale rýchlejší“. Umožňuje triedu pracovných záťaží, ktoré ostatné dve úrovne štrukturálne nemôžu hostiť. Úprimný zoznam:

1. Spätná väzba o pochopení scény v reálnom čase. 72B VLM sa pozerá na kameru robota každých 200 – 500 ms a vracia štruktúrovaný popis scény, ktorú plánovač využíva. Cloud to nemôže urobiť vo veľkom meradle kvôli chveniu a nákladom siete WAN. Integrovaný systém to nemôže urobiť, pretože model nesedí. Lokálny systém uzatvára slučku celkovo za 250 – 500 ms.

2. Fúzia VLM z viacerých kamier. Humanoid má 3–5 kamier (hlava, dve zápästia, dve na tele/hrudník). Súčasné spustenie VLM cez všetky z nich – pre priestorové uzemnenie, manipuláciu s oklúziou alebo koordináciu ruka-oko – predstavuje 5-násobok inferenčnej záťaže. Limity rýchlosti cloudu alebo poplatky za stream. Na doske sa zmestí jeden stream v malom meradle. Na mieste sa všetkých päť dávkovo sníma cez rovnaký koncový bod VLM.

3. Plánovanie úloh s dlhodobým horizontom a perzistentnou pamäťou scény. „Včera som nechal kľúč na druhej poličke. Nájdi ho.“ To si vyžaduje VLM + LLM + vektorové úložisko bežiace spoločne s perzistentným stavom naprieč reláciami robota. Stav musí byť umiestnený niekde stabilne, dotazovateľne a rýchlo. To je databáza na serveri, nie kontextové okno cloudu pre každé volanie a nie 4 GB RAM na Jetsone.

4. Doladenie online politík. Robot počas dňa zhromažďuje ukážky úloh. Cez noc, keď je v doku, spustíte LoRA, ktorá doladí denné dáta oproti základnej VLA, nainštalujete aktualizovaný adaptér a robot je zajtra lepší. To predstavuje 2× až 5× väčšiu pamäťovú náročnosť oproti inferencii. Cloud účtuje školenie a úložisko samostatne. On-premise všetko absorbuje do jednej platformy.

5. Koordinácia flotily viacerých robotov. Dva alebo tri roboty zdieľajúce pamäť scény, koordinujúce úlohy a sledujúce stav ostatných. Vrstva koordinácie medzi robotmi vyžaduje latenciu medzi robotmi pod 10 ms. On-premise so zdieľaným serverom v lokálnej sieti LAN to zabezpečí. Cloud to nedokáže – aktualizácia každého robota sa odošle do regiónu, vráti sa a dostane sa k ďalšiemu robotovi.

6. Iterácia zo simulácie do reality. Isaac Sim beží na rovnakých grafických procesoroch, ktoré slúžia na inferenciu, generuje syntetické trénovacie dáta a overuje aktualizácie politík predtým, ako sa dostanú k skutočnému robotovi. V cloude ide o pol dňa na iteráciu (iba presun dát), čo je 30-minútová slučka v lokálnej sieti.

Žiadna z nich nie je sci-fi. Všetky sú to pracovné zaťaženia, ktoré dnes používajú integrátori robotiky z roku 2026. Žiadna z nich nefunguje čisto na žiadnej z ostatných dvoch úrovní.

Prečo je toto v roku 2026 najmodernejšie riešenie

Najmodernejší stav v oblasti vnímania robotov v roku 2026 je VLM v slučkeModel sa pozerá na svet, vyjadruje o ňom argumenty v jazyku, vytvára štruktúrované plány a politika ich vykonáva. Toto bol výskumný nápad v roku 2023, produktová ukážka v roku 2024 a produkčný vzorec v rokoch 2025 – 2026.

Trend vynucujúci si lokálnu vrstvu je priamočiary: fungujúce VLM sa zväčšujú, nie zmenšujú. Qwen2.5-VL 7B je dobrý. Qwen2.5-VL 72B je výrazne lepší. Proprietárne modely, ktoré Frontier Labs nepublikujú, sú ešte väčšie. Cesta „malého VLM, ktorý beží na zariadení“ existuje a bude existovať aj naďalej, ale zaostáva za Frontierom o 12 – 18 mesiacov a predstavuje významnú medzeru vo funkciách. Ak chcete hraničné správanie, hostujete Frontier model. Frontier model sa nehodí na Jetson.

Cloud by teoreticky mohol držať krok. V praxi to tak nie je zo štyroch vyššie uvedených dôvodov (latencia, jitter, náklady, suverenita) a preto, že hraničné laboratóriá skrývajú najväčšie modely za partnerskými úrovňami, ku ktorým robotický startup nemá prístup. VLM s otvorenou hmotnosťou triedy 70B. do existovať, môcť byť hostované a dobre fungovať na komerčných serveroch s 8 GPU. Táto súhra – otvorené modely hraničnej triedy a komerčný hardvér s viacerými GPU – je dôvodom, prečo je on-premise práve teraz tou správnou odpoveďou a v roku 2023 nebola.

Toto tiež nie je názor spoločnosti Kentino. Inferenčná vrstva pre lokálne riešenia je to, na čom je postavený stack Isaac od spoločnosti NVIDIA, na čo hlavné robotické platformy dodávajú referenčné architektúry a čo zabezpečuje každý seriózny integrátor, s ktorým sme sa za posledných šesť mesiacov rozprávali. Trh dobehol hardvér, dobehol modely a rok 2026 je rokom, kedy sa to vyčistilo.

Keď je lokálna cesta nesprávnou odpoveďou

Úprimne povedané: špeciálna okrajová vrstva je v niekoľkých reálnych prípadoch prehnaná.

• Teleoperované roboty. Operátor je plánovač. Robot je bábka s riadiacim prepojením. V slučke nie je žiadny VLM; tá malá inferencia, ktorá sa deje (odhad polohy, kódovanie videa s nízkou latenciou), môže bežať na Jetsone. V prípade potreby pridajte cloud pre akúkoľvek ťažkú ​​prácu. Nie je potrebný žiadny GPU server.
• Jednoduchá kontrola štvornožcov. Robot triedy Spot alebo Go2, ktorý kráča po pevnej hliadkovej trase s detekciou na úrovni YOLO a termokamerou, nepotrebuje 72B VLM. Túto úlohu vykonáva palubný Jetson. Dáta sa odosielajú do cloudu na analýzu po hliadke, nie počas nej.
• Ukážky a jednorazové pilotné projekty. Potrebujete systém bežať na veľtrhu, prezentácii zákazníkom, trojtýždňovom overovaní konceptu. Cloud vás tam dostane za popoludnie. Kapitálové náklady na lokálne riešenia nie sú vhodné pre pracovnú záťaž, ktorá bude zrušená o mesiac.
• Využitie na hobby a vzdelávanie. Univerzitné laboratórium s jednou G1 EDU, obmedzeným rozpočtom a zameraním na tréning RL pred inferenciou. Jetson a jedna pracovná stanica 4090 dokážu hostiť dostatok kapacity na vykonávanie zmysluplného výskumu. Celá úroveň K-AI 8× nemá žiadny zmysel.
• Čisto jazykové pracovné zaťaženie. Robot, ktorý rozpráva, ale nevidí – hlasový asistent na nohách. Cloudové LLM API je v poriadku. Latenčný rozpočet je konverzačný, nie uzavretý.

Vzor: ak váš robot nebeží skutočný VLM v uzavretej slučke vnímania, nepotrebujete vyhradenú okrajovú vrstvu. Ak ju používa, potrebujete ju.

Keď je lokálna cesta opodstatnená

Vyhradená okrajová vrstva sa stáva správnou odpoveďou, keď je pravdivé aspoň jedno z nasledujúcich a ideálne dve alebo viac:

1. Skutočný VLM je v uzavretej slučke. Nie „na občasné otázky“ – in slučka od vnímania k akcii, ktorá prebieha každých 100 – 500 ms. Toto je štrukturálny dôvod existencie lokálneho prostredia.
2. Trvalé zaťaženie. Osem hodín denne, päť dní v týždni, na neurčito. Kapitálové náklady sa amortizujú. Cena za hovor v cloude sa hromadí na neurčito.
3. Dáta nemôžu opustiť budovu. GDPR, HIPAA, ITAR, súťaživosť alebo jednoduchá paranoja. Bajty zostávajú v lokálnej sieti. Neobchodovateľné.
4. Viacero robotov. Dve alebo viac jednotiek zdieľajúcich pamäť scény alebo koordinujúcich úlohy. Amortizácia zdieľaného servera je na robota a rozpočet na latenciu medzi robotmi sa zrúti.
5. Prispôsobenie je dôležité. Jemne doladené VLM, pripnuté verzie modelov, proprietárne hlavy na otvorených chrbticových sieťach, špecializované kvantizácie. Sloboda je produkt.
6. Rýchlosť iterácie je dôležitá. Tím vydáva aktualizácie politík týždenne alebo rýchlejšie. Simulácia a školenie na rovnakom hardvéri ako inferencia uzatvára slučku z dní na hodiny.

Ak zaškrtnete tri alebo viac z nich, otázka už neznie if lokálne, ale ktorá veľkosťŠtvor-GPU K-AI 96 (RTX 4090 alebo 5090) úroveň postačuje pre jedného robota vykonávajúceho skutočnú prácu. Osem-GPU K-AI 256 (5090 alebo Pro 6000 Blackwell) je ten správny tvar pre malú flotilu robotov, najväčšie VLM alebo akékoľvek nasadenie s požiadavkou na školenie nad rámec inferencie.

---

Toto je súčasť Kentino Wiki, referenčnej série o umelej inteligencii, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy sú vítané na adrese info@kentino.com.