Nasadenie flotily: Viacero robotov, zdieľané výpočty

Jeden robot je projekt. Päť robotov je systém. Dvadsať robotov je operácia. Každý tím, ktorý prešiel prvú jednotku, zistí, že technický problém sa na ceste nahor dvakrát zmení – raz okolo troch robotov, znova okolo desiatich. Tento článok pojednáva o tom, čo sa mení, prečo sa servery Kentino s umelou inteligenciou, ktoré Kentino dodáva, škálujú lepšie, ako ľudia očakávajú, a o operačnej disciplíne, ktorú skutočne potrebujete v 1. deň flotily 2 robota 3.

I01 sa venoval problému dvoch boxov pre jedného robota a jeden server. K03 sa venoval tomu, ako vLLM rozdeľuje model na rôzne GPU. R08 argumentoval, prečo vôbec lokálne riešenie. Tento článok nadväzuje na všetky tri a odpovedá na nasledujúcu otázku: ak 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, akým ho ovládate, nie.

Jednoduchá verzia: naplánujte si špecializovaného operátora robotiky okolo robota číslo 3. Stenou nie je sieť ani GPU server; stenou je ľudská pozornosť. Jeden operátor dokáže ad hoc spravovať dvoch robotov. Pri piatich je rytmus „tomuto sa vybila batéria, tamtomu sa lidar pohol, tretiemu sa sieť rozpadla“ prácou na plný úväzok a predstieranie opaku len spáli prvého zamestnanca na čiastočný úväzok a zle.

Výpočtová ekonomika – čomu vlastne slúži 8-GPU Kentino AI

Číslo, ktoré by malo riadiť vašu veľkosť, je počet súbežných požiadaviek VLM za sekundu na robota , nie počet robotov na server. Robot nie je fixná záťaž; je to trieda pracovnej záťaže. Úloha vychystávania pri 2 Hz nie je to isté ako navigačná úloha pri 0.5 Hz nie je to isté ako dialógový agent pri 0.2 Hz.

Hrubé hodnoty pre 8-GPU Kentino AI 256 s 8× RTX 5090 (FP8 / INT4 vLLM, jeden model, zapnuté kontinuálne dávkovanie, zapnutá prefix cache; pozri I02 a K03 ):

Toto sú obálky, nie sľuby. Čísla sa menia s dĺžkou výzvy, rozlíšením obrazu, mierou zásahov do vyrovnávacej pamäte prefixu (oveľa vyššia v kontextoch vozového parku, pretože roboty v tej istej budove zdieľajú kontext prostredia) a presnou kombináciou predbežného dopĺňania a dekódovania. Dôležitý je tvar: malé úlohy iba s VLM obsluhujú veľa robotov na server; veľké úlohy s VLM v slučke obsluhujú málo robotov.

Skutočná inštalácia zriedkakedy prevádzkuje jeden model. Flotila vykonávajúca užitočnú prácu zvyčajne potrebuje 72B VLM na uvažovanie o scéne, 32B LLM na plánovanie a malú VLA na detailné rozpracovanie pohybu. 8× Kentino AI prevádzkuje všetky tri súbežne. S touto kombináciou je realistický strop na jednom serveri 4 – 6 humanoidov vykonávajúcich prácu VLM v uzavretej slučke . Toto je číslo, s ktorým sa má plánovať – nie optimistické „namerali sme 24 súbežných 7B požiadaviek“.

Dávkovacia páka (a prečo sú flotily lacné)

Dôvod, prečo jeden veľký server prekonáva mnoho malých serverov, je neustále dávkovanie . vLLM uchováva priebežnú dávku prebiehajúcich požiadaviek; pri každom prechode dopredu sa dokončené požiadavky vyradia a pridajú sa nové. Verejné benchmarky ukazujú, že vLLM dosahuje 2.3-násobok priepustnosti inferencie generovania textu a 14–24-násobok naivného PyTorch na rovnakom hardvéri práve vďaka tejto páke.

Pre flotilu sa efekt znásobuje. Päť robotov, ktoré zasiahnu ten istý koncový bod VLM s podobnými výzvami, vytvorí takmer ideálny vzorec dávkovania: väčšina požiadaviek zdieľa dlhú systémovú výzvu (vyrovnávacia pamäť prefixov je zasiahnutá na 80 – 95 %), časy príchodu sú dostatočne dekorelované, aby dávka zostala plná, a náklady na požiadavku sa amortizujú oproti zdieľanej práci predbežného dopĺňania.

1 robot   = 1.00× compute baseline
2 robots  = ~1.6× compute (batching helps)
4 robots  = ~2.5× compute
8 robots  = ~4.0× compute

Zdvojnásobenie robotov neznamená zdvojnásobenie výpočtových nákladov, keď zdieľajú jeden backend. Toto je argument na strane záťaže pre jeden veľký server namiesto mnohých malých. Pripočítajte to k argumentu kapitálových nákladov (jeden 8× 5090 box je lacnejší ako dva 4× 5090 boxy o ~15–25 % v kusovníku) a argumentu prevádzkových nákladov (jeden server na monitorovanie, nie dva) a matematika je jednostranná pre flotily do približne ôsmich robotov.

Po ôsmej už aj tak potrebujete druhý server a otázkou je, ako rozdeliť prevádzku – o tom viac informácií nájdete nižšie.

Architektúra pre flotilu 3–8 robotov

Tri roviny na jednom fyzickom hostiteľovi (menej ako 8 robotov): správa flotily, koordinácia a inferencia. Každá z nich je logicky odlišná; rozdelená medzi hostiteľské systémy nad túto veľkosť.

Tri roviny, nie jedna krabica. Rovina riadenia vozového parku je vrstva orientovaná na operátora – inventár robotov, telemetria, aktualizácie OTA, upozornenia. Koordinačná rovina je vrstva medzi robotmi – zdieľané mapy, alokácia úloh, pamäť scén. Inferenčná rovina je vrstva slúžiaca modelu – vLLM za routerom. Pre flotily do ~8 robotov bežia na rovnakom fyzickom hostiteľovi Kentino AI, za týmto počtom sú na samostatných hostiteľoch.

Smerovanie požiadaviek: čo sa nachádza pred vLLM

Naivné nastavenie s jedným koncovým bodom vLLM, štyrmi robotmi a TCP round-robin funguje týždeň a potom sa preruší, keď prvá požiadavka trvá 8 sekúnd a ďalšie štyri čakajú v rade za ňou. Router je ten, kto tomu bráni.

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

Obyčajný nginx s least_conn. Round-robin je nesprávny; chcete najmenej aktívne pripojenia, aby pomalá požiadavka nestiahla za sebou celú flotilu. Päť riadkov konfigurácie. Správna odpoveď pre jeden model, jeden koncový bod, dve repliky. Nerobí nič pre KV vyrovnávaciu pamäť ani lokalitu prefixu.

vLLM Router (Rust, vydaný koncom roka 2025). Konzistentné hašovanie prefixu výzvy, takže tá istá konverzácia pristane na tej istej replike a vyrovnávacia pamäť prefixov zostane aktívna. Pre flotilu, kde každý robot má vlastnú konverzáciu, ale všetci zdieľajú dlhý systémový výzvu, je to správne rozhodnutie. Zásady sú cache_aware, power_of_twoa round_robin; pre produkčné flotily je predvolená hodnota s ohľadom na vyrovnávaciu pamäť.

llm-d o Kubernetes. Preddopĺňanie/dekódovanie disagregácie, plánovanie viacerých replík, rozšírenia inferencie brány. Správna odpoveď, keď máte ≥4 repliky, zmiešané typy modelov a natívny operačný tím Kubernetes. Pre všetkých ostatných je to príliš veľa.

Afinita relácie je jemná otázka. Robot komunikujúci s plánovacím agentom profituje z lepkavého smerovania do tej istej repliky (prefix cache). Robot spúšťajúci jednorazové značky scén VLM to nezíska – tie sú bezstavové, smerujte ich round-robin. Správna odpoveď je smerovanie podľa typu požiadavky, nie podľa klienta : plánovanie s pamätou cache, označovanie scén round-robin. Router vLLM podporuje oboje prostredníctvom politiky pre každý koncový bod.

Pamäť scény: kde sa nachádza kontext každého robota

Robot nie je klient bez štátnej príslušnosti. Pamätá si, kde včera nechal kľúč, kto prešiel dverami pred hodinou a že kartónová krabica v uličke 7 tam leží už tri dni. Táto spomienka musí niekde bývať a výber miesta je jedným z kľúčových rozhodnutí pri návrhu vozového parku.

Tri vzory:

Možnosť A – pgvector pre každého robota na serveri. Každý robot má svoju vlastnú kolekciu v zdieľanej inštancii Postgres+pgvector. Pamäť je odolná, dotazovateľná zo strany servera, prístupná pre správu vozového parku. Jednoduchá, škálovateľná na desiatky robotov na jednom Postgrese. Súkromie je slabým miestom: každý bajt pamäte každého robota je centralizovaný.

Možnosť B – pamäť scény v robote s RAG na server. Robot si uchováva svoje vlastné vnorenia v lokálnom úložisku sqlite-vss alebo DuckDB. Keď sa dopytuje na VLM servera, odošle relevantné načítané časti ako súčasť výzvy. Pamäť je lokálna a súkromná; sieť vidí iba to, čo sa robot rozhodol odoslať. Lepšie pre citlivé nasadenia (medicína, obrana, kdekoľvek, kde operátor nechce, aby surová pamäť opúšťala robota). Náklady na vyššiu šírku pásma siete na hovor.

Možnosť C – zdieľaný úložisko scén s menným priestorom. Všetky roboty zapisujú a čítajú z jedného úložiska pgvector, menného priestoru podľa lokality alebo úlohy. Robot 2 môže položiť otázku „čo videl robot 1 dnes ráno v nakladacej rampe?“ a získať užitočnú odpoveď. Toto je jediná možnosť, ktorá podporuje skutočné kolaboratívne úlohy. Je to tiež možnosť, kde nesprávny zápis od jedného robota znečisťuje pohľad ostatných na svet.

Predvolenou možnosťou pre flotilu 3–8 robotov je možnosť C s prísnou kontrolou prístupu – roboty zapisujú do vlastného menného priestoru, čítajú zo zdieľaného menného priestoru „sveta“, ktorý je spravovaný (správca flotily doň po overení prenáša pozorovania). Pre nasadenia citlivé na súkromie je to možnosť B. Možnosť A je cestou najmenšieho odporu a je vhodná, ak nie je potrebná spolupráca.

Stratégie zdieľania modelov

Predvolená hodnota – jeden model obsluhujúci N robotov – je vhodná pre väčšinu flotíl. Roboty vykonávajú podobné úlohy; základný model je rovnaký; rozdiely spočívajú v pokynoch a načítanom kontexte, nie vo váhach. Toto je najlacnejšia cesta a poskytuje najvyššiu efektivitu dávkového spracovania.

Dva prípady, kedy sa pokazí:

Jemne doladené hlavy pre každý robot. Robot 1 sa nachádza v sklade a je vyladený na manipuláciu s paletami. Robot 2 sa nachádza v laboratóriu a je vyladený na manipuláciu s prístrojmi. Obsluhujete rovnaký základný VLM s rôznymi LoRA adaptérmi nahranými na požiadanie. vLLM podporuje obsluhu viacerých LoRA (--enable-lora --max-loras N) s malou réžiou na požiadavku a zdieľaným dávkovým spracovaním základného modelu. Užitočné, keď sú jemné doladenia 0.1 – 1 % základných váh (typické pre LoRA) a máte 2 – 10 rôznych adaptérov.

Špecializované modely pre každú triedu úloh. Iný model pre každú úlohu – Qwen2.5-VL pre všeobecné uvažovanie o scéne, OpenVLA pre uchopenie, jemne vyladený 7B pre dialóg. Každý model má svoj vlastný koncový bod vLLM na vlastnom segmente GPU. Trasy podľa typu požiadavky. Viac VRAM, menej dávkovania na model, viac operačnej plochy. Správna odpoveď až po overení, že jeden model nedokáže danú úlohu vykonať, nie skôr.

Začnite s jedným modelom. Pridajte adaptéry LoRA, keď máte nameraný rozdiel v kvalite na robota. Pridajte špeciálne modely, keď máte nameraný rozdiel na úlohu, ktorý LoRA nedokáže odstrániť.

Riadenie robotického parku (RFM) – vyberte si produkt

Vytvorenie vlastného RFM je pasca, do ktorej väčšina tímov padne raz. Funkcie sú zrejmé z hľadiska rozsahu, ale v skutočnosti drahé: inventár, príjem telemetrie, ukladanie časových radov, OTA kanál, smerovanie upozornení, prístup založený na rolách, audítorské protokoly, multi-tenancy, ak máte zákazníkov. Malý tím vytvorí verziu, ktorá funguje pre jednu flotilu a prestane fungovať pod druhou. Kúpte si radšej jednu z nich a prispôsobte si ju podľa nej.

Open-RMF spravuje od roku 2024 organizácia Open Source Robotics Alliance a zaoberá sa prideľovaním úloh, riešením konfliktov a arbitrážou zdieľanej infraštruktúry (výťahy, dvere, chodby). Pre lokálne nasadenie v štýle Kentino so zmiešanými robotmi – povedzme jeden Unitree G1, jeden Booster T1, jeden štvornohý Go2, všetci na tom istom mieste – je Open-RMF jedinou dôveryhodnou otvorenou cestou. Formant a Orbit sú vynikajúce, ale sú SaaS a uprednostňujú vlastný ekosystém.

Úprimná predvolená hodnota: Open-RMF pre lokálne riešenia od zmiešaných dodávateľov, Formant pre hostované riešenia zamerané na pozorovateľnosť, Orbit iba pre Boston Dynamics. Vytváranie vlastného RFM je nesprávne, pokiaľ ho explicitne nepredávate ako produkt.

Koordinácia viacerých robotov na drôte

Priestor názvov ROS 2. Každý robot spúšťa svoj ROS 2 stack pod jedinečným menným priestorom (/r01/, /r02/, …). Témy, služby a parametre DDS sú tiež menné priestory. Roboty sa prihlasujú na odber tém o stave rovesníkov (/r02/pose, /r03/pose) priamo cez DDS, bez sprostredkovateľa. DDS v ROS 2 je peer-to-peer a je škálovateľný na desiatky robotov v jednej lokálnej sieti LAN; nad ~50 sa prevádzka objavovania stáva hlučnou a je potrebné buď rozdeliť podľa ID domény DDS, alebo prejsť do režimu objavovacieho servera v ROS 2.

MQTT pre telemetriu hore, príkazy dole. ROS 2 / DDS je skvelý pre stav peer-u s nízkou latenciou v sieti LAN. Nie je skvelý pre „odosielanie 0.5 Hz telemetrie stavu do cloudu pre správu vozového parku cez nestabilné LTE backhaul“. MQTT je na to ten správny nástroj – ľahké, brokerom sprostredkované úrovne QoS pre garantované doručenie, natívna podpora v každej platforme vozového parku. Typické rozdelenie: DDS v sieti LAN, MQTT (alebo HTTPS) cez WAN.

Prideľovanie úloh. Dva prístupy skutočne používané vo flotilách v roku 2026:

1. Centrálny plánovač. Manažér vozového parku priraďuje úlohy na základe dostupnosti robota, batérie, polohy a kapacity. Jednoduché, predvídateľné, vhodné pre 90 % prípadov. Open-RMF to robí ihneď po vybalení z krabice.
2. Na základe aukcie. Roboty prihadzujú ceny na úlohy na základe nákladovej funkcie (vzdialenosť, batéria, aktuálne zaťaženie). Najnižšia ponuka vyhráva. Lepšie pre heterogénne flotily alebo dynamické prostredia. Nedávna práca ukazuje, že aukčné metódy dosahujú ~12 % úsporu energie v porovnaní s alokáciou najbližšej úlohy pri flotilách 2 – 20 robotov. Pri flotilách 10 a viac robotov sa to oplatí; nižšie uvedené je prehnané.

Predchádzanie kolíziám. Každý robot publikuje svoju polohu s frekvenciou 10 Hz; každý robot sa prihlasuje k polohám ostatných robotov. Lokálni plánovači zohľadňujú trajektórie ostatných robotov. Pre flotily, kde dva roboty bežne zdieľajú pracovný priestor s rozlohou 1 m², potrebujete aj koordinačnú vrstvu (kanonickým riešením je riadenie premávky v Open-RMF).

Riešenie porúch v rozsahu flotily

Princíp je jednoduchý: poruchy by mali byť izolované, degradované režimy by mali byť plynulé a obnova by mala byť automatická. Praktické postupy:

Jeden robot zomrie, ostatní pokračujú. Každý robot je autonómny vo svojom palubnom počítači kvôli bezpečnosti a reaktívnemu vnímaniu. Strata jedného robota je stratou jedného robota – kolegovia naňho neblokujú čakanie. Manažér vozového parku ho označí, prerozdelí jeho úlohy a upozorní človeka.

Inferenčný server zlyhá. Každý robot by mal byť schopný prejsť do režimu iba na palube, keď je server nedostupný: žiadny veľký VLM, žiadne dlhodobé plánovanie, ale lokálne ovládanie, vyhýbanie sa prekážkam a predinštalované kroky misie stále fungujú. Robot sa v podstate stáva „slepým voči jazyku“, ale nepadá. Naplánujte si to; testujte ho mesačne so zámerným blokovaním firewallu na strane servera.

Aktualizácia inferenčného servera. Dve repliky za vLLM routerom; vyprázdniť jednu, znova nasadiť, overiť, vyprázdniť druhú, znova nasadiť. Roboty nevidia žiadne viditeľné prerušenie, pretože router vyprázdni iba repliky bez požiadaviek počas prevádzky. Modrá/zelená je tiež správna voľba pre výmenu modelov – načítať nový model na repliku B, prepnúť ukazovateľ routera, overiť niekoľko dotazov, vyradiť repliku A. Preskočenie kroku zahrievania uhryzne všetkých presne raz (pozri I02 o chybe pri zahrievaní).

Pravidlo 1 z N. V ktoromkoľvek okamihu vo flotile N robotov predpokladajme, že jeden je v degradovanom stave, jeden je offline a jeden robí niečo neočakávané. Naplánujte kapacitu pre N-2 efektívne roboty. Ak N-2 nestačí na danú pracovnú záťaž, flotila je nesprávne dimenzovaná.

Pozorovateľnosť na úrovni flotily

Ovládací panel, ktorý skutočne chcete, zoradený podľa priority:

1. Zdravie každého robota. Batéria, teplota integrovanej grafickej karty, časová pečiatka posledného zobrazenia, aktuálna úloha, posledná chyba. Jeden riadok na robota, obnovenie každých 5 sekúnd, stav červená/žltá/zelená. Toto je prvá vec, na ktorú sa operátor každé ráno pozrie.
2. Latencia na robota k inferenčnému serveru. Čas prenosu P50, P95, P99 pre volania VLM každého robota. Skoky v P99 sú hlavným indikátorom degradácie Wi-Fi, preťaženia servera alebo výmeny modelu, ktorá sa nezahriala.
3. Hĺbka frontu obsluhy modelu. vllm_num_requests_waiting na koncový bod. Trvalá nenulová hodnota je signálom, že flotila predbieha server. Upozornenie pri 10+ po dobu viac ako minúty.
4. Teplotná mapa využitia vozového parku. Ktoré roboty sú zaneprázdnené, kde v budove a čo robia. Prevádzkový pohľad; informuje manažéra, či je flotila vyvážená.
5. Vzorkovanie výstupu modelu. Malá časť (1 – 5 %) odpovedí modelu zostala v rade na kontrolu. Manuálna náhodná kontrola každý týždeň. Jediný spôsob, ako zachytiť tiché regresie kvality.

Prometheus + Grafana pre metriky; zobrazenie stavu robota je zvyčajne také, aké dodáva RFM (Formant, Orbit alebo vaša vlastná Grafana). Relevantné série vLLM 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 — toto sú informácie o stave na strane inferencie; exportér DCGM pokrýva stranu GPU.

Realita škálovania nákladov

Dve postrehy:

• Kapitálové náklady na robota sú od 4 robotov nahor zhruba nemenné. Pod hodnotou 4 dominujú fixné náklady na server. Nad hodnotou 4 platíte lineárne za výpočtové náklady úmerne záťaži. Ideálna hodnota pre... prvý Server je 4–6 robotov.
• Kapitálové náklady na robota (ktoré sú samostatné a dominantné) sa lineárne škálujú. Výpočty sú malou položkou, keď flotila presiahne približne 3 roboty. Jediným veľkým nákladovým faktorom je „potrebujete vôbec lokálne riešenia“ (pozri R08), nie „aká veľkosť servera“.

Výpočtová ekonomika silne argumentuje v prospech jedného veľkého servera Kentino AI obsluhujúceho 4–8 robotov namiesto viacerých menších serverov. Dva servery Kentino AI 256 sú horšie ako jeden Kentino AI 256 s 8× Pro 6000 pre rovnakú flotilu, až kým nedosiahnete strop kapacity servera, ktorý spustí DP=2. Prechod je špecifický pre pracovné zaťaženie, ale pri intenzívnej práci s VLM-in-the-loop sa dosahuje približne 7–9 robotov.

Úprimný pohľad

Flotily s viac ako piatimi robotmi predstavujú inú operačnú disciplínu ako jednotlivé jednotky. Nie sú to „päťkrát jeden robotický projekt“. Ide o iný typ projektu, kde:

• Výpočet je malá riadková položka; operácie sú najdôležitejšie
• Úzkym hrdlom je zvyčajne ľudský problém (pozornosť manažéra) a skôr technický problém.
• Wi-Fi a plánovanie napájania sú trikrát tvrdšie ako pri flotile veľkosti 1
• Náklady na doladenie každého robota sú reálne; náklady na degradáciu modelu v celej flotile sú reálnejšie.
• Vytvorenie vlastného RFM je takmer vždy chyba; vyberte si jeden a prispôsobte si ho

Výpočtová stránka problému bude skutočne vyriešená do roku 2026. vLLM + router + dostatočne veľký server Kentino s umelou inteligenciou zvládne flotily až do veľkosti približne 8 humanoidov na jednom zariadení. Okrem toho je možné škálovať pomocou paralelizmu dát (viac serverov za routerom) – o tom sa píše v K03 . Závažné problémy nad veľkosťou flotily 5 sú prevádzkové, nie architektonické.

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