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 K-AI, 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 pokrýval problém dvoch boxov pre jedného robota a jeden server. K03 popísal, ako vLLM rozdeľuje model naprieč grafickými procesormi. R08 zdôvodnil, 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 K-AI

Číslo, ktoré by malo určovať vašu veľkosť, je súbežné požiadavky VLM za sekundu na robota, nie roboty 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é obálky pre 8-GPU K-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 obrázka, mierou zásahov do vyrovnávacej pamäte prefixu (oveľa vyššou v kontexte flotily, 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 vzor, ​​ktorý je tvar: Malé úlohy s využitím iba VLM obsluhujú veľa robotov na server; veľké úlohy s využitím VLM v slučke obsluhujú len málo robotov.

Skutočná inštalácia zriedkakedy prevádzkuje jeden model. Vozový park vykonávajúci 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× K-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čkeTo je číslo, s ktorým treba počítať – nie optimistické „namerali sme 24 súbežných 7 miliárd žiadostí“.

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 kontinuálne dávkovanievLLM uchováva priebežnú dávku požiadaviek, ktoré sa práve spracovávajú; 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 priepustnosti naivného PyTorch na rovnakom hardvéri, a to 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 je nie 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 oproti mnohým malým. 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 lietadlá, 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, prideľovanie ú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 K-AI a za týmto časom 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 na 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 operačný tím natívny na Kubernetes. Pre všetkých ostatných je to príliš veľa.

Afinita relácie je rafinovaná otázka. Robot, ktorý komunikuje s plánovacím agentom, profituje z pevného smerovania do tej istej repliky (prefix cache). Robot, ktorý spúšťa jednorazové tagy scény VLM, to z toho nemá – tie sú bezstavové, smerujte ich round-robin. Správna odpoveď je smerovanie podľa typu požiadavky, nie podľa klienta: plánovanie s ohľadom na vyrovnávaciu pamäť, označovanie scén s využitím kruhového spracovania. Smerovač 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 žiť a voľba... kde je jedným z rozhodnutí o nosnosti 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 na robote s RAG na server. Robot si uchováva vlastné vnorenia v lokálnom úložisku sqlite-vss alebo DuckDB. Keď sa dopytuje na serverový VLM, odošle relevantné načítané časti ako súčasť výzvy. Pamäť je lokálna a súkromná; sieť vidí iba to, čo robot odoslal. 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ými priestormi. 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.

Predvolená hodnota pre flotilu 3–8 robotov je Možnosť C s prísnou kontrolou prístupu — roboty zapisujú do svojho vlastného menného priestoru, čítajú zo zdieľaného menného priestoru „sveta“, ktorý je spravovaný (správca vozového parku 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 na triedu úloh. Iný model na úlohu — Qwen2.5-VL pre všeobecné uvažovanie o scéne, OpenVLA pre uchopenie, 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.

Čestné zlyhanie: 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ľ RFM 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-ov s nízkou latenciou v lokálnej 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 lokálnej 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é.

Zabránenie zrážkam. Každý robot publikuje svoju pózu s frekvenciou 10 Hz; každý robot sa prihlasuje k pózam 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é vzory:

Jeden robot zomrie, ostatní pokračujú. Každý robot je autonómny vo svojom palubnom počítači, čo zabezpečuje bezpečnosť a reaktívne vnímanie. Strata jedného robota je stratou jedného robota – kolegovia naňho neblokujú čakanie. Manažér vozového parku ho označí, prerozdelí mu úlohy a upozorní človeka.

Inferenčný server zlyhá. Každý robot by mal byť schopný vrátiť sa k režim 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.

Priebežná aktualizácia inferenčného servera. Dve repliky za smerovačom vLLM; vyprázdniť jednu, znova nasadiť, overiť, vyprázdniť druhú, znova nasadiť. Roboty nevidia žiadne viditeľné prerušenie, pretože smerovač 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ľ smerovača, overiť niekoľko dotazov, vyradiť repliku A. Preskočenie kroku zahrievania zasiahne každého presne raz (pozri I02 na rozcvičke (chytil som).

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á ekonómia silne argumentuje za jeden veľký K-AI server obsluhujúci 4–8 robotov na viacerých menších serveroch. Dva servery K-AI 256 sú horšie ako jeden K-AI 256 s 8× Pro 6000 pre rovnakú flotilu, až kým nedosiahnete strop kapacity serverov, ktorý spustí DP=2. Prechod je špecifický pre pracovnú záťaž, ale pri intenzívnej práci s VLM-in-the-loop sa pohybuje okolo 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 K-AI 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) – popísané v... K03Zložité 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ú. Komentáre a opravy sú vítané na info@kentino.com.