Nasadenie flotily: viac robotov, zdieľaný výkon

Jeden robot je projekt. Päť robotov je systém. Dvadsať robotov je prevádzka. Každý tím, ktorý sa dostal za prvý kus, zistí, že inžiniersky problém cestou nahor dvakrát zmení tvar — raz okolo troch robotov, druhýkrát okolo desiatich. Tento článok je o tom, čo sa mení, prečo AI servery, ktoré Kentino dodáva, škálujú lepšie, než ľudia očakávajú, a akú prevádzkovú disciplínu naozaj potrebujete v deň 1 flotily 2 robota 3.

I01 sa venoval problému dvoch boxov pri jednom robotovi a jednom serveri. K03 vysvetlil, ako vLLM rozdeľuje model medzi GPU. R08 zdôvodnil, prečo vôbec on-prem. Tento text stojí na všetkých troch a odpovedá na ďalšiu otázku: teraz to chcete urobiť N-krát — čo sa pokazí?

Tri režimy

Existujú tri zmysluplné režimy veľkosti flotily. Prechody medzi nimi sú prevádzkové, nie technické — hardvér vyzerá podobne, spôsob prevádzky už nie.

Natvrdo: počítajte s vyhradeným človekom na robotickú prevádzku zhruba pri treťom robotovi. Stenou nie je sieť ani GPU server; stenou je ľudská pozornosť. Jeden operátor zvládne dvoch robotov ad hoc. Pri piatich je tempo „tomuto odišla batéria, tamtomu ušiel lidar, tretiemu vypadla sieť“ prácou na plný úväzok a predstierať opak znamená len zle a na polovičný úväzok spáliť prvého človeka, ktorého na to prijmete.

Ekonomika výpočtov — koľko reálne obslúži 8-GPU Kentino AI

Číslo, podľa ktorého by ste mali dimenzovať, je počet súbežných VLM požiadaviek za sekundu na robota, nie počet robotov na server. Robot nie je fixná záťaž; je to trieda workloadu. Úloha vyberania pri 2 Hz nie je to isté ako navigačná úloha pri 0.5 Hz a tá nie je to isté ako dialógový agent pri 0.2 Hz.

Hrubé rozpätia pre 8-GPU Kentino AI 256 s 8× RTX 5090 (FP8 / INT4 vLLM, jeden model, zapnuté continuous batching, zapnutá prefix cache; pozri I02 a K03):

Sú to rozpätia, nie sľuby. Čísla sa menia s dĺžkou promptu, rozlíšením obrazu, úspešnosťou prefix cache (vo flotilách je výrazne vyššia, lebo roboti v tej istej budove zdieľajú kontext prostredia) a presným pomerom prefillu a decodu. Podstatný je tvar: workloady iba s malým VLM obslúžia veľa robotov na server; workloady s veľkým VLM v slučke len málo.

Reálna inštalácia málokedy beží na jednom modeli. Flotila, ktorá robí užitočnú prácu, zvyčajne chce 72B VLM na uvažovanie o scéne, 32B LLM na plánovanie a malý VLA na jemný pohybový zámer. 8× Kentino AI zvládne všetky tri súbežne. Pri takomto mixe je reálny strop jedného servera 4–6 humanoidov v uzavretej slučke s VLM. To je číslo, s ktorým treba plánovať — nie optimistické „namerali sme 24 súbežných 7B požiadaviek“.

Páka dávkovania (a prečo sú flotily lacné)

Dôvod, prečo jeden veľký server poráža veľa malých, je continuous batching. vLLM drží plynulú dávku rozpracovaných požiadaviek; pri každom prechode dopredu dokončené požiadavky vypadnú a pridajú sa nové. Verejné benchmarky ukazujú, že vLLM dosahuje 2.3× priepustnosť Text Generation Inference a 14–24× naivného PyTorchu na rovnakom hardvéri práve vďaka tejto páke.

Vo flotile sa efekt znásobuje. Päť robotov, ktorí volajú ten istý VLM endpoint s podobnými promptmi, vytvára takmer ideálny vzor pre dávkovanie: väčšina požiadaviek zdieľa dlhý systémový prompt (prefix cache s úspešnosťou 80–95 %), časy príchodu sú dostatočne nekorelované na to, aby dávka zostala plná, a náklad na požiadavku sa amortizuje cez zdieľanú prefill prácu.

1 robot   = 1.00× základ výpočtového výkonu
2 roboty  = ~1.6× výkonu (dávkovanie pomáha)
4 roboty  = ~2.5× výkonu
8 robotov = ~4.0× výkonu

Zdvojnásobenie počtu robotov nie je zdvojnásobením nákladov na výpočty, ak zdieľajú rovnaký backend. To je argument na strane záťaže v prospech jedného veľkého servera namiesto mnohých malých. Pripočítajte argument capexu (jeden box s 8× 5090 je o ~15–25 % lacnejší na BOM než dva boxy so 4× 5090) a prevádzkový argument (jeden server na monitorovanie, nie dva) a matematika je jednoznačná pre flotily do zhruba ôsmich robotov.

Nad osem robotov tak či tak potrebujete druhý server a otázkou sa stáva, ako rozdeliť prevádzku — o tom nižšie.

Architektúra pre flotilu 3–8 robotov

Tri vrstvy na jednom fyzickom hoste (pod ~8 robotov): správa flotily, koordinácia a inferencia. Každá je logicky samostatná; nad touto veľkosťou ich rozdeľte na viacero hostov.

Tri vrstvy, nie jedna skriňa. Vrstva správy flotily je vrstva pre operátora — inventár robotov, telemetria, OTA aktualizácie, upozornenia. Koordinačná vrstva je vrstva medzi robotmi — zdieľané mapy, prideľovanie úloh, pamäť scény. Inferenčná vrstva je vrstva obsluhy modelov — vLLM za routerom. Pri flotilách pod ~8 robotov bežia na tom istom fyzickom hoste Kentino AI, nad tým na samostatných hostoch.

Smerovanie požiadaviek: čo stojí pred vLLM

Naivné nastavenie s jedným vLLM endpointom, štyrmi robotmi a TCP round-robinom funguje týždeň a potom spadne pri prvej požiadavke, ktorá trvá 8 sekúnd a za ktorou sa zaradia ďalšie štyri. Router je to, čo tomu zabráni.

Tri možnosti, zoradené podľa zložitosti:

Obyčajný nginx s least_conn. Round-robin je zlá voľba; chcete najmenej aktívnych spojení, aby pomalá požiadavka neťahala za sebou celú flotilu. Päť riadkov konfigurácie. Správna odpoveď pre jeden model, jeden endpoint, dve repliky. Pre KV cache ani prefix lokalitu nerobí nič.

vLLM Router (Rust, vydaný koncom 2025). Konzistentné hashovanie podľa prefixu promptu, takže tá istá konverzácia pristane na tej istej replike a prefix cache zostáva teplá. Pre flotilu, kde má každý robot vlastnú konverzáciu, no všetci zdieľajú dlhý systémový prompt, je to správna voľba. Politiky sú cache_aware, power_of_two, a round_robin; cache-aware je predvolená pre produkčné flotily.

llm-d na Kubernetes. Oddelenie prefillu a decodu, plánovanie naprieč replikami, gateway inference extensions. Správna odpoveď, keď máte ≥4 repliky, zmiešané typy modelov a ops tím natívne žijúci v Kubernetes. Pre všetkých ostatných je to prehnané.

Jemnou otázkou je afinita relácie. Robot, ktorý sa rozpráva s plánovacím agentom, ťaží zo sticky smerovania na tú istú repliku (prefix cache). Robot, ktorý posiela jednorazové VLM značky scény, nie — tie sú bezstavové, smerujte ich round-robinom. Správna odpoveď je smerovať podľa typu požiadavky, nie podľa klienta: plánovanie na cache-aware, značkovanie scény na round-robin. vLLM Router podporuje oboje cez politiku na úrovni endpointu.

Pamäť scény: kde žije kontext každého robota

Robot nie je bezstavový klient. Pamätá si, kde včera nechal kľúč, kto pred hodinou prešiel dverami, že kartónová krabica v uličke 7 tam leží už tri dni. Táto pamäť musí niekde bývať a voľba kde je jedným z nosných rozhodnutí v návrhu flotily.

Tri vzory:

Možnosť A — pgvector na serveri pre každého robota. Každý robot má vlastnú kolekciu v zdieľanej inštancii Postgres + pgvector. Pamäť je trvalá, dotazovateľná zo strany servera a dostupná správe flotily. Jednoduché, škáluje na desiatky robotov na jednom Postgrese. Slabinou je súkromie: každý bajt pamäte každého robota je centralizovaný.

Možnosť B — pamäť scény na robotovi s RAG na server. Robot si drží vlastné embeddingy v lokálnom úložisku sqlite-vss alebo DuckDB. Keď sa pýta serverového VLM, pošle relevantné vyhľadané úryvky ako súčasť promptu. Pamäť je lokálna a súkromná; sieť vidí len to, čo robot sám pošle. Lepšie pre citlivé nasadenia (zdravotníctvo, obrana, všade, kde prevádzkovateľ nechce, aby surová pamäť opúšťala robota). Stojí viac sieťového pásma na volanie.

Možnosť C — zdieľané úložisko scény s mennými priestormi. Všetci roboti zapisujú do jedného pgvector úložiska a čítajú z neho, s mennými priestormi podľa lokality alebo úlohy. Robot 2 sa môže opýtať „čo videl robot 1 dnes ráno v nakladacej rampe?“ a dostane užitočnú odpoveď. Je to jediná možnosť, ktorá podporuje skutočne kolaboratívne úlohy. Je to zároveň možnosť, kde otrávený zápis od jedného robota znečistí obraz sveta ostatných.

Poctivá predvoľba pre flotilu 3–8 robotov je Možnosť C s prísnym riadením prístupu — roboti zapisujú do vlastného menného priestoru a čítajú zo zdieľaného priestoru „svet“, ktorý je kurátorovaný (správca flotily do neho povyšuje pozorovania až po overení). Pre nasadenia citlivé na súkromie Možnosť B. Možnosť A je cestou najmenšieho odporu a je v poriadku, ak spolupráca nie je požiadavkou.

Stratégie zdieľania modelov

Predvoľba — jeden model obsluhujúci N robotov — je správna pre väčšinu flotíl. Roboti robia podobné úlohy; základný model je rovnaký; rozdiely žijú v promptoch a vyhľadanom kontexte, nie vo váhach. Je to najlacnejšia cesta a dáva najvyššiu efektivitu dávkovania.

Dva prípady, keď to prestane platiť:

Doladené hlavy pre jednotlivých robotov. Robot 1 žije v sklade a je doladený na manipuláciu s paletami. Robot 2 žije v laboratóriu a je doladený na prácu s prístrojmi. Obsluhujete ten istý základný VLM s rôznymi LoRA adaptérmi načítanými podľa požiadavky. vLLM podporuje multi-LoRA obsluhu (--enable-lora --max-loras N) s malou réžiou na požiadavku a zdieľaným dávkovaním základného modelu. Užitočné, keď doladenia tvoria 0.1–1 % základných váh (typické pre LoRA) a máte 2–10 rôznych adaptérov.

Špecializované modely podľa triedy úloh. Iný model na každú úlohu — Qwen2.5-VL na všeobecné uvažovanie o scéne, OpenVLA na uchopovanie, doladený 7B na dialóg. Každý model dostane vlastný vLLM endpoint na vlastnom výseku GPU. Smeruje sa podľa typu požiadavky. Viac VRAM, menej dávkovania na model, väčšia prevádzková plocha. Správna odpoveď až vtedy, keď si overíte, že jeden model na to nestačí — nie skôr.

Začnite s jedným modelom. LoRA adaptéry pridajte, keď namerate rozdiel v kvalite medzi robotmi. Špecializované modely pridajte, keď namerate rozdiel medzi úlohami, ktorý LoRA nezatvorí.

Správa robotickej flotily (RFM) — vyberte si produkt

Postaviť si vlastný RFM je pasca, do ktorej väčšina tímov raz spadne. Funkcie vyzerajú jednoducho, ale v skutočnosti sú drahé: inventár, príjem telemetrie, ukladanie časových radov, OTA pipeline, smerovanie upozornení, prístupy podľa rolí, audit logy, multi-tenancy, ak máte zákazníkov. Malý tím postaví verziu, ktorá funguje pre jednu flotilu a pri druhej sa zlomí. Radšej si kúpte niektorý z týchto a prispôsobte si ho.

Open-RMF spravuje od roku 2024 Open Source Robotics Alliance a rieši prideľovanie úloh, riešenie konfliktov a arbitráž zdieľanej infraštruktúry (výťahy, dvere, chodby). Pre on-prem nasadenie v štýle Kentino s robotmi od viacerých výrobcov — povedzme jeden Unitree G1, jeden Booster T1 a jeden štvornožec Go2 na tej istej lokalite — je Open-RMF jedinou dôveryhodnou otvorenou cestou. Formant a Orbit sú vynikajúce, ale sú to SaaS a uprednostňujú vlastný ekosystém.

Poctivá predvoľba: Open-RMF pre on-prem flotily od viacerých výrobcov, Formant pre hostované nasadenia s dôrazom na observabilitu, Orbit pre čisté Boston Dynamics. Stavať si vlastný RFM je chyba, pokiaľ RFM sami nepredávate ako produkt.

Koordinácia viacerých robotov na sieti

Menné priestory v ROS 2. Každý robot beží so svojím ROS 2 stackom pod jedinečným menným priestorom (/r01/, /r02/, …). Menné priestory majú aj DDS témy, služby a parametre. Roboti odoberajú stavové témy svojich kolegov (/r02/pose, /r03/pose) priamo cez DDS, bez brokera. DDS v ROS 2 je peer-to-peer a bez problémov škáluje na desiatky robotov v jednej LAN; nad ~50 začne byť discovery prevádzka hlučná a je vhodné buď rozdeliť siete podľa DDS domain ID, alebo prejsť na režim discovery servera v ROS 2.

MQTT pre telemetriu hore a príkazy dole. ROS 2 / DDS je skvelé pre nízku latenciu stavových dát medzi robotmi v LAN. Nie je skvelé na „posielanie 0.5 Hz telemetrie o zdraví do cloudu správy flotily cez nestabilný LTE backhaul“. Na to je správnym nástrojom MQTT — ľahký, cez brokera, s úrovňami QoS pre zaručené doručenie a natívnou podporou v každej platforme pre flotily. Typické rozdelenie: DDS v LAN, MQTT (alebo HTTPS) cez WAN.

Prideľovanie úloh. Dva prístupy, ktoré sa vo flotilách v roku 2026 reálne používajú:

1. Centrálny plánovač. Správca flotily prideľuje úlohy podľa dostupnosti robota, batérie, polohy a schopností. Jednoduché, predvídateľné, pokrýva 90 % prípadov. Open-RMF to vie hneď po inštalácii.
2. Aukčný prístup. Roboti licitujú o úlohy podľa nákladovej funkcie (vzdialenosť, batéria, aktuálna záťaž). Vyhráva najnižšia ponuka. Lepšie pre heterogénne flotily alebo dynamické prostredia. Nedávne práce ukazujú, že aukčné metódy dosahujú ~12 % úsporu energie oproti prideľovaniu najbližšej úlohy na flotilách 2–20 robotov. Pri flotilách od 10 robotov sa zložitosť oplatí, pod tým je zbytočná.

Vyhýbanie sa kolíziám. Každý robot publikuje svoju pózu pri 10 Hz a odoberá pózy ostatných. Lokálne plánovače počítajú s trajektóriami kolegov. Pri flotilách, kde dvaja roboti bežne zdieľajú pracovný priestor 1 m², potrebujete aj koordinačnú vrstvu (kanonickou odpoveďou je riadenie premávky v Open-RMF).

Zvládanie porúch v mierke flotily

Princíp je jednoduchý: poruchy majú byť izolované, degradované režimy plynulé a zotavenie automatické. Praktické vzory:

Jeden robot padne, ostatní pokračujú. Každý robot je na svojom palubnom výpočtovom výkone autonómny pre bezpečnosť a reaktívne vnímanie. Strata jedného robota je stratou jedného robota — ostatní na neho nečakajú. Správca flotily ho označí ako nedostupného, prerozdelí jeho úlohy a upozorní človeka.

Zlyhá inferenčný server. Každý robot by mal vedieť prejsť do režimu iba na palube, keď je server nedostupný: žiadny veľký VLM, žiadne plánovanie s dlhým horizontom, ale lokálne riadenie, vyhýbanie sa prekážkam a vopred nahraté kroky misie fungujú ďalej. Robot v podstate „oslepne na jazyk“, ale nespadne. Počítajte s tým a testujte to raz mesačne zámerným blokovaním na firewalle servera.

Postupná aktualizácia inferenčného servera. Dve repliky za vLLM Routerom; jednu vyprázdnite, nasaďte, overte, vyprázdnite druhú, nasaďte. Roboti nevidia žiadne prerušenie, lebo router vyprázdňuje len repliky bez rozpracovaných požiadaviek. Blue/green je správna voľba aj pri výmene modelov — načítajte nový model na repliku B, prepnite ukazovateľ routera, overte pár dotazov a repliku A vyraďte. Preskočenie zahriatia potrápi každého presne raz (pozri I02 o nástrahe zahrievania).

Pravidlo 1 z N. V ktoromkoľvek okamihu vo flotile N robotov predpokladajte, že jeden je degradovaný, jeden offline a jeden robí niečo nečakané. Plánujte kapacitu na N-2 efektívnych robotov. Ak N-2 na daný workload nestačí, flotila je zle nadimenzovaná.

Observabilita v mierke flotily

Dashboard, ktorý naozaj chcete, zoradený podľa priority:

1. Zdravie jednotlivých robotov. Batéria, teplota palubného GPU, čas posledného kontaktu, aktuálna úloha, posledná chyba. Jeden riadok na robota, obnova každých 5 sekúnd, stav červená/žltá/zelená. Toto si operátor pozrie každé ráno ako prvé.
2. Latencia jednotlivých robotov k inferenčnému serveru. P50, P95 a P99 obojsmerného času pre VLM volania každého robota. Skoky v P99 sú predstihovým ukazovateľom zhoršenia Wi-Fi, preťaženia servera alebo výmeny modelu bez zahriatia.
3. Hĺbka frontu pri obsluhe modelu. vllm_num_requests_waiting na endpoint. Trvalá nenulová hodnota je signál, že flotila predbieha server. Upozornenie pri 10+ dlhšie ako minútu.
4. Teplotná mapa vyťaženia flotily. Ktorí roboti sú zaneprázdnení, kde v budove a čím. Prevádzkový pohľad; manažérovi povie, či je flotila vyvážená.
5. Vzorkovanie výstupov modelu. Malý podiel (1–5 %) odpovedí modelu sa ukladá do kontrolného frontu. Manuálna kontrola raz týždenne. Jediný spôsob, ako odhaliť tiché zhoršenie kvality.

Na metriky Prometheus + Grafana; pohľad na zdravie robotov zvyčajne prinesie samotný RFM (Formant, Orbit alebo vaša vlastná Grafana). Relevantné vLLM série sú vllm:num_requests_running, vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_seconds, vllm:time_per_output_token_seconds — to je obraz o zdraví na strane inferencie; stranu GPU pokrýva DCGM exporter.

Realita škálovania nákladov

Dve pozorovania:

• Capex na robota je od štyroch robotov vyššie zhruba plochý. Pod štyrmi dominuje fixná cena servera. Nad štyrmi platíte za výpočtový výkon lineárne úmerne záťaži. Ideálny bod pre prvý server sú 4–6 robotov.
• Capex na robotov (ktorý je samostatný a dominuje) rastie lineárne. Výpočtový výkon je malá položka, len čo flotila prekročí ~3 roboty. Jedinou veľkou nákladovou pákou je „potrebujete vôbec on-prem?“ (pozri R08), nie „akú veľkosť servera“.

Ekonomika výpočtov silno hovorí pre jeden veľký server Kentino AI obsluhujúci 4–8 robotov namiesto viacerých menších. Dva boxy Kentino AI 256 sú pre tú istú flotilu horšie než jeden Kentino AI 256 s 8× Pro 6000, až kým nenarazíte na kapacitný strop servera, ktorý si vyžiada DP=2. Prechod závisí od workloadu, ale pri náročnej práci s veľkým VLM v slučke je okolo 7–9 robotov.

Poctivý záver

Flotily nad päť robotov sú iná prevádzková disciplína než jednotlivé kusy. Nie sú to „päťkrát projekt s jedným robotom“. Je to projekt iného tvaru, kde:

• Výpočtový výkon je malá položka; veľkou položkou je prevádzka
• Úzkym hrdlom býva človek (pozornosť manažéra) skôr než technika
• Plánovanie Wi-Fi a napájania potrápi trikrát viac než pri jednom robotovi
• Cena doladenia pre každého robota je reálna; cena degradácie modelu naprieč flotilou je ešte reálnejšia
• Stavať si vlastný RFM je takmer vždy chyba; vyberte si jeden a prispôsobte ho

Výpočtová stránka problému je v roku 2026 naozaj vyriešená. vLLM + router + správne nadimenzovaný server Kentino AI zvládnu flotilu až do zhruba 8 humanoidov na jednej skrini. Nad tým sa škáluje dátovým paralelizmom (viac serverov za routerom) — o tom v K03. Ťažké problémy nad päť robotov sú prevádzkové, nie architektonické.

---

Toto je súčasť Kentino Wiki, referenčnej série o AI výpočtoch, robotike a systémoch, ktoré ich spájajú. Pripomienky a opravy uvítame na info@kentino.com.