Nasazení flotily: více robotů, sdílený výpočetní výkon

Jeden robot je projekt. Pět robotů je systém. Dvacet robotů je provoz. Každý tým, který se dostane za první kus, zjistí, že inženýrský problém cestou nahoru dvakrát změní tvar — poprvé kolem tří robotů, podruhé kolem deseti. Tento článek je o tom, co se mění, proč AI servery Kentino škálují lépe, než lidé čekají, a jakou provozní disciplínu skutečně potřebujete v den 1 flotily 2 u robota 3.

I01 se věnoval problému dvou krabic pro jednoho robota a jeden server. K03 popsal, jak vLLM dělí model mezi GPU. R08 vysvětlil, proč vůbec řešit on-prem. Tento díl staví na všech třech a odpovídá na další otázku: teď to chcete udělat N×, co se rozbije?

Tři režimy

Existují tři smysluplné režimy velikosti flotily. Přechody mezi nimi jsou provozní, ne technické — hardware vypadá podobně, způsob provozu nikoli.

Natvrdo: počítejte s vyhrazeným člověkem pro robotický provoz zhruba u robota 3. Zdí není síť ani GPU server, zdí je lidská pozornost. Jeden operátor zvládne dva roboty ad hoc. U pěti je kadence „tomuhle došla baterie, tamtomu ujel lidar, třetímu vypadla síť“ prací na plný úvazek a předstírat opak znamená jen spálit prvního člověka na půl úvazku a špatně.

Ekonomika výpočtů — kolik 8GPU Kentino AI skutečně obslouží

Číslo, podle kterého byste měli dimenzovat, je počet souběžných VLM požadavků za sekundu na robota, nikoli roboti na server. Robot není pevná zátěž, je to třída workloadu. Úloha pickování při 2 Hz není totéž co navigační úloha při 0.5 Hz a ta není totéž co dialogový agent při 0.2 Hz.

Hrubé obálky pro 8GPU Kentino AI 256 s 8× RTX 5090 (FP8 / INT4 vLLM, jeden model, zapnuté continuous batching, zapnutá prefix cache; viz I02 a K03):

Jsou to obálky, ne sliby. Čísla se mění s délkou promptu, rozlišením obrázku, úspěšností prefix cache (ve flotilách výrazně vyšší, protože roboti ve stejné budově sdílejí kontext prostředí) a přesným poměrem prefill vs. decode. Podstatný je tvar: workloady jen s malým VLM obslouží na jeden server mnoho robotů, workloady s velkým VLM ve smyčce jen několik.

Reálná instalace málokdy běží na jediném modelu. Flotila, která dělá užitečnou práci, obvykle chce 72B VLM pro uvažování nad scénou, 32B LLM pro plánování a malý VLA pro jemný pohybový záměr. Osminásobné Kentino AI zvládne všechny tři současně. S touto kombinací je reálný strop jednoho serveru 4–6 humanoidů dělajících VLM práci v uzavřené smyčce. S tímhle číslem počítejte — ne s optimistickým „naměřili jsme 24 souběžných 7B požadavků“.

Páka batchingu (a proč jsou flotily levné)

Důvod, proč jeden velký server poráží mnoho malých, je continuous batching. vLLM drží průběžnou dávku rozpracovaných požadavků; při každém průchodu dokončené požadavky vypadnou a nové se přidají. Veřejné benchmarky ukazují, že vLLM dosahuje 2.3× propustnosti Text Generation Inference a 14–24× naivního PyTorch na stejném hardwaru právě díky této páce.

U flotily se efekt násobí. Pět robotů mířících na stejný VLM endpoint s podobnými prompty vytváří téměř ideální vzorec pro batching: většina požadavků sdílí dlouhý systémový prompt (úspěšnost prefix cache 80–95 %), časy příchodů jsou dostatečně nekorelované, aby dávka zůstala plná, a náklady na požadavek se amortizují proti sdílené prefill práci.

1 robot   = 1.00× základ výpočtu
2 roboti  = ~1.6× výpočtu (batching pomáhá)
4 roboti  = ~2.5× výpočtu
8 robotů  = ~4.0× výpočtu

Zdvojnásobení počtu robotů není zdvojnásobením nákladů na výpočet, pokud sdílejí backend. To je argument na straně zátěže pro jeden velký server místo mnoha malých. Přidejte k tomu argument capexu (jedna skříň 8× 5090 je v BOM o ~15–25 % levnější než dvě skříně 4× 5090) a provozní argument (monitorujete jeden server, ne dva) a pro flotily do zhruba osmi robotů je výsledek jednoznačný.

Nad osm robotů stejně potřebujete druhý server a otázkou se stává, jak rozdělit provoz — o tom níže.

Architektura pro flotilu 3–8 robotů

Tři roviny na jednom fyzickém hostu (do ~8 robotů): správa flotily, koordinace a inference. Každá je logicky oddělená, nad tuto velikost je rozdělte na samostatné hosty.

Tři roviny, ne jedna krabice. Rovina správy flotily je vrstva pro operátora — inventář robotů, telemetrie, OTA aktualizace, výstrahy. Koordinační rovina je vrstva mezi roboty — sdílené mapy, alokace úloh, paměť scény. Inferenční rovina je vrstva obsluhy modelů — vLLM za routerem. Pro flotily do ~8 robotů běží na stejném fyzickém hostu Kentino AI, nad tuto velikost na samostatných hostech.

Routování požadavků: co stojí před vLLM

Naivní řešení s jedním vLLM endpointem, čtyřmi roboty a TCP round-robinem funguje týden a pak spadne, jakmile jeden požadavek trvá 8 sekund a další čtyři se za ním zařadí do fronty. Právě tomu router zabraňuje.

Tři možnosti, seřazené podle složitosti:

Obyčejný nginx s least_conn. Round-robin je špatně; chcete nejmenší počet aktivních spojení, aby pomalý požadavek nestáhl celou flotilu. Pět řádků konfigurace. Správná odpověď pro jeden model, jeden endpoint a dvě repliky. Pro KV cache ani prefix lokalitu neudělá nic.

vLLM Router (Rust, vydaný koncem roku 2025). Konzistentní hashování podle prefixu promptu, takže stejná konverzace dopadne na stejnou repliku a prefix cache zůstane teplá. Pro flotilu, kde má každý robot vlastní konverzaci, ale všichni sdílejí dlouhý systémový prompt, je to správná volba. Politiky jsou cache_aware, power_of_two a round_robin; pro produkční flotily je výchozí cache-aware.

llm-d na Kubernetes. Oddělení prefillu a decodu, plánování napříč replikami, gateway inference extensions. Správná odpověď, když máte ≥4 repliky, smíšené typy modelů a ops tým zvyklý na Kubernetes. Pro všechny ostatní zbytečné.

Jemnou otázkou je afinita session. Robot, který konverzuje s plánovacím agentem, těží ze sticky routování na stejnou repliku (prefix cache). Robot, který posílá jednorázové VLM tagy scény, nikoli — ty jsou bezstavové, routujte je round-robinem. Správná odpověď zní routujte podle typu požadavku, ne podle klienta: plánování na cache-aware, tagování scény na round-robin. vLLM Router podporuje obojí politikou pro jednotlivé endpointy.

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

Robot není bezstavový klient. Pamatuje si, kde včera nechal klíč, kdo před hodinou prošel dveřmi, že kartonová krabice v uličce 7 tam leží tři dny. Tahle paměť musí někde žít a volba, kde, je jedním z nosných rozhodnutí v návrhu flotily.

Tři vzory:

Varianta A — pgvector na serveru, pro každého robota zvlášť. Každý robot má vlastní kolekci ve sdílené instanci Postgres+pgvector. Paměť je trvalá, dotazovatelná ze strany serveru a dostupná správě flotily. Jednoduché, škáluje na desítky robotů v jednom Postgresu. Slabinou je soukromí: každý bajt paměti každého robota je centralizovaný.

Varianta B — paměť scény v robotovi s RAG na server. Robot si drží vlastní embeddingy v lokálním úložišti sqlite-vss nebo DuckDB. Při dotazu na serverový VLM pošle jako součást promptu jen relevantní nalezené úryvky. Paměť je lokální a soukromá, síť vidí jen to, co se robot rozhodl odeslat. Lepší pro citlivá nasazení (zdravotnictví, obrana, kdekoli operátor nechce, aby syrová paměť opouštěla robota). Stojí to víc síťové kapacity na jedno volání.

Varianta C — sdílené úložiště scény se jmennými prostory. Všichni roboti zapisují do jednoho pgvector úložiště a čtou z něj, rozděleného jmennými prostory podle lokality nebo úlohy. Robot 2 se může zeptat „co viděl robot 1 dnes ráno v nakládací rampě?“ a dostat užitečnou odpověď. Je to jediná varianta, která umožňuje skutečně kolaborativní úlohy. Je to také varianta, kde otrávený zápis od jednoho robota znečistí obraz světa ostatních.

Poctivá výchozí volba pro flotilu 3–8 robotů je varianta C s přísným řízením přístupu — roboti zapisují do vlastního jmenného prostoru a čtou ze sdíleného prostoru „svět“, který je kurátorovaný (správce flotily do něj povyšuje pozorování až po ověření). Pro nasazení citlivá na soukromí varianta B. Varianta A je cestou nejmenšího odporu a je v pořádku, pokud spolupráce není požadavkem.

Strategie sdílení modelů

Výchozí přístup — jeden model obsluhující N robotů — je správný pro většinu flotil. Roboti dělají podobné úlohy, základní model je stejný, rozdíly leží v promptech a načteném kontextu, ne ve vahách. Je to nejlevnější cesta a dává nejvyšší efektivitu batchingu.

Dva případy, kdy to přestává platit:

Doladěné hlavy pro jednotlivé roboty. Robot 1 žije ve skladu a je doladěný na manipulaci s paletami. Robot 2 žije v laboratoři a je doladěný na manipulaci s přístroji. Obsluhujete stejný základní VLM s různými LoRA adaptéry načítanými podle požadavku. vLLM podporuje multi-LoRA obsluhu (--enable-lora --max-loras N) s malou režií na požadavek a sdíleným batchingem základního modelu. Užitečné, když doladění tvoří 0.1–1 % základních vah (typické pro LoRA) a máte 2–10 různých adaptérů.

Specializované modely podle třídy úloh. Jiný model na každou úlohu — Qwen2.5-VL pro obecné uvažování nad scénou, OpenVLA pro úchop, doladěný 7B pro dialog. Každý model dostane vlastní vLLM endpoint na vlastním výseku GPU. Routuje se podle typu požadavku. Víc VRAM, méně batchingu na model, větší provozní plocha. Správná odpověď až ve chvíli, kdy jste ověřili, že jeden model na to nestačí — ne dřív.

Začněte jedním modelem. LoRA adaptéry přidejte, až naměříte rozdíl v kvalitě mezi roboty. Specializované modely přidejte, až naměříte rozdíl mezi úlohami, který LoRA nedorovná.

Správa robotické flotily (RFM) — vyberte si produkt

Stavět si vlastní RFM je past, do které většina týmů jednou spadne. Funkce vypadají rozsahem samozřejmě, ale ve skutečnosti jsou drahé: inventář, příjem telemetrie, ukládání časových řad, OTA pipeline, routování výstrah, přístup podle rolí, auditní logy a multitenance, pokud máte zákazníky. Malý tým postaví verzi, která funguje pro jednu flotilu a u druhé se zlomí. Kupte raději jeden z těchto a přizpůsobte si okolí.

Open-RMF spravuje od roku 2024 Open Source Robotics Alliance a řeší alokaci úloh, řešení konfliktů a arbitráž sdílené infrastruktury (výtahy, dveře, chodby). Pro on-prem nasazení ve stylu Kentino s roboty od různých výrobců — řekněme jeden Unitree G1, jeden Booster T1 a jeden čtyřnohý Go2 na stejné lokalitě — je Open-RMF jedinou důvěryhodnou otevřenou cestou. Formant a Orbit jsou výborné, ale jde o SaaS a preferují vlastní ekosystém.

Poctivá výchozí volba: Open-RMF pro on-prem s více výrobci, Formant pro hostovaná nasazení náročná na observabilitu, Orbit pro čistě Boston Dynamics. Stavět vlastní RFM je chyba, pokud RFM sami neprodáváte jako produkt.

Koordinace více robotů na síti

Jmenné prostory v ROS 2. Každý robot provozuje svůj ROS 2 stack ve vlastním jmenném prostoru (/r01/, /r02/, …). Jmenné prostory mají i DDS topiky, služby a parametry. Roboti odebírají stavové topiky protějšků (/r02/pose, /r03/pose) přímo přes DDS, bez brokeru. DDS v ROS 2 je peer-to-peer a bez problémů škáluje na desítky robotů v jedné LAN; nad ~50 začne být discovery provoz hlučný a chcete buď rozdělit sítě podle DDS domain ID, nebo přejít na režim discovery serveru v ROS 2.

MQTT pro telemetrii nahoru a příkazy dolů. ROS 2 / DDS je skvělé pro nízkolatenční stav protějšků v LAN. Není ale dobré na „posílej 0.5 Hz telemetrii o zdraví do cloudu pro správu flotily přes vrtkavý LTE backhaul“. Na to je správným nástrojem MQTT — odlehčený, zprostředkovaný brokerem, s úrovněmi QoS pro zaručené doručení a nativní podporou v každé flotilové platformě. Typické rozdělení: DDS v LAN, MQTT (nebo HTTPS) přes WAN.

Alokace úloh. Dva přístupy, které se ve flotilách roku 2026 skutečně používají:

1. Centrální plánovač. Správce flotily přiděluje úlohy podle dostupnosti robota, baterie, polohy a schopností. Jednoduché, předvídatelné, pokryje 90 % případů. Open-RMF to umí rovnou z krabice.
2. Aukční. Roboti na úlohy nabízejí podle nákladové funkce (vzdálenost, baterie, aktuální zátěž). Vyhrává nejnižší nabídka. Lepší pro heterogenní flotily nebo dynamická prostředí. Nedávné práce ukazují, že aukční metody dosahují u flotil 2–20 robotů ~12 % úspory energie oproti přidělování nejbližší úlohy. Složitost se vyplatí u flotil 10+, níže je zbytečná.

Vyhýbání se kolizím. Každý robot publikuje svou pózu při 10 Hz a odebírá pózy protějšků. Lokální plánovače počítají s trajektoriemi ostatních. U flotil, kde dva roboti běžně sdílejí pracovní prostor 1 m², potřebujete navíc koordinační vrstvu (kanonickou odpovědí je řízení provozu v Open-RMF).

Zvládání poruch v měřítku flotily

Princip je jednoduchý: poruchy mají být izolované, degradované režimy plynulé a zotavení automatické. Praktické vzory:

Jeden robot padne, ostatní pokračují. Každý robot je pro bezpečnost a reaktivní vnímání autonomní na svém palubním výpočetním výkonu. Ztráta jednoho robota je ztrátou jednoho robota — protějšky na něj nečekají. Správce flotily ho označí jako nedostupného, přerozdělí jeho úlohy a upozorní člověka.

Inferenční server selže. Každý robot musí umět přejít do režimu pouze palubního výpočtu, když je server nedostupný: žádný velký VLM, žádné plánování na dlouhý horizont, ale lokální řízení, vyhýbání se překážkám a předem nahrané kroky mise dál fungují. Robot se fakticky stane „slepým vůči jazyku“, ale nespadne. Počítejte s tím a testujte to měsíčně záměrným zablokováním na firewallu serveru.

Postupná aktualizace inferenčního serveru. Dvě repliky za vLLM Routerem; jednu vyprázdněte, nasaďte, ověřte, pak vyprázdněte druhou a nasaďte. Roboti nezaznamenají žádné viditelné přerušení, protože router vyprazdňuje jen repliky bez rozpracovaných požadavků. Blue/green je správná volba i pro výměnu modelů — načtěte nový model na repliku B, přepněte ukazatel routeru, ověřte pár dotazů a repliku A vyřaďte. Vynechání zahřívacího kroku kousne každého přesně jednou (viz I02 o nástraze se zahříváním).

Pravidlo 1 z N. V kterýkoli okamžik ve flotile N robotů předpokládejte, že jeden je degradovaný, jeden offline a jeden dělá něco nečekaného. Kapacitu plánujte na N-2 efektivních robotů. Pokud N-2 na daný workload nestačí, je flotila špatně nadimenzovaná.

Observabilita v měřítku flotily

Dashboard, který skutečně chcete, seřazený podle priority:

1. Zdraví jednotlivých robotů. Baterie, teplota palubního GPU, čas posledního spojení, aktuální úloha, poslední chyba. Jeden řádek na robota, obnova každých 5 sekund, stav červená/žlutá/zelená. Na tohle se operátor dívá každé ráno jako na první věc.
2. Latence jednotlivých robotů k inferenčnímu serveru. P50, P95 a P99 doby odezvy pro VLM volání každého robota. Skoky v P99 jsou předstihovým ukazatelem zhoršení Wi-Fi, přetížení serveru nebo výměny modelu, která se nezahřála.
3. Hloubka fronty u obsluhy modelu. vllm_num_requests_waiting pro každý endpoint. Trvale nenulová hodnota je signálem, že flotila předbíhá server. Alert při 10+ po dobu delší než minuta.
4. Heatmapa využití flotily. Kteří roboti pracují, kde v budově a na čem. Provozní pohled; říká manažerovi, zda je flotila vyvážená.
5. Vzorkování výstupů modelu. Malý zlomek (1–5 %) odpovědí modelu se ukládá do revizní fronty. Týdenní ruční kontrola vzorku. Jediný způsob, jak odhalit tiché zhoršení kvality.

Na metriky Prometheus + Grafana; pohled na zdraví jednotlivých robotů obvykle přináší samotné RFM (Formant, Orbit nebo vaše vlastní Grafana). Relevantní vLLM řady jsou 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 — ty vyprávějí příběh zdraví na straně inference, stranu GPU pokrývá DCGM exporter.

Realita škálování nákladů

Dvě pozorování:

• Capex na robota je od čtyř robotů nahoru zhruba plochý. Pod čtyřmi dominuje fixní cena serveru. Nad čtyřmi platíte za výkon lineárně úměrně zátěži. Sladké místo pro první server je 4–6 robotů.
• Capex na roboty (ten je oddělený a dominuje) roste lineárně. Jakmile flotila přesáhne ~3 roboty, je výpočetní výkon malou položkou. Jedinou velkou nákladovou pákou je „potřebujete vůbec on-prem“ (viz R08), nikoli „jak velký server“.

Ekonomika výpočtů silně mluví pro jeden velký server Kentino AI obsluhující 4–8 robotů místo několika menších. Dvě skříně Kentino AI 256 jsou pro stejnou flotilu horší než jedna Kentino AI 256 s 8× Pro 6000, dokud nenarazíte na strop kapacity serveru, který vynutí DP=2. Přechod závisí na workloadu, ale u náročné práce s velkým VLM ve smyčce leží kolem 7–9 robotů.

Poctivý závěr

Flotily nad pět robotů jsou jiná provozní disciplína než jednotlivé kusy. Nejsou to „pětkrát projekt s jedním robotem“. Je to jiný tvar projektu, kde:

• výpočetní výkon je malá položka; velkou položkou je provoz
• úzké hrdlo je obvykle lidské (pozornost manažera) dřív než technické
• plánování Wi-Fi a napájení kouše třikrát víc než u flotily o velikosti 1
• náklady na doladění pro jednotlivého robota jsou reálné, náklady na zhoršení modelu napříč flotilou ještě reálnější
• stavět si vlastní RFM je téměř vždy chyba, vyberte si jedno a přizpůsobte je

Výpočetní stránka problému je v roce 2026 skutečně vyřešená. vLLM + router + dobře nadimenzovaný server Kentino AI zvládnou na jedné skříni flotily do zhruba 8 humanoidů. Nad to se škáluje datovým paralelismem (více serverů za routerem) — viz K03. Těžké problémy nad velikostí flotily 5 jsou provozní, ne architektonické.

---

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.