Nasazení vozového parku: Více robotů, sdílené výpočty

Jeden robot je projekt. Pět robotů je systém. Dvacet robotů je operace. Každý tým, který se posunul za první jednotku, zjistí, že technický problém se cestou nahoru dvakrát změní – jednou kolem tří robotů, znovu kolem deseti. Tento článek pojednává o tom, co se mění, proč se servery K-AI, které Kentino dodává, škálují lépe, než lidé očekávají, a o provozní disciplíně, kterou skutečně potřebujete v den 1 flotily 2 robota 3.

I01 pokryl problém dvou krabic pro jednoho robota a jeden server. K03 popsal, jak vLLM rozděluje model napříč grafickými procesory. R08 zdůvodnil, proč vůbec on-premise. Tento článek doplňuje všechny tři a odpovídá na následující otázku: teď, když to chcete udělat N-krát, co se pokazí?

Tři režimy

Existují tři smysluplné režimy velikosti vozového parku. Přechody mezi nimi jsou provozní, nikoli technické – hardware vypadá podobně; způsob, jakým jej spouštíte, nikoli.

Tupá verze: naplánujte si specializovaného operátora robotického provozu kolem robota číslo 3. Zeď není síť ani GPU server; zeď je lidská pozornost. Jeden operátor může ad hoc spravovat dva roboty. V pěti letech je rytmus „tomuto se vybila baterie, tamtomu se lidar vychýlil, třetímu se síť vymkla“ prací na plný úvazek a předstírat opak jen spálí prvního zaměstnance na částečný úvazek a špatně.

Výpočetní ekonomika – k čemu vlastně slouží 8GPU K-AI

Číslo, které by mělo ovlivnit vaši velikost, je souběžných požadavků VLM za sekundu na robota, nikoli robotů na server. Robot není fixní zátěž; je to třída pracovní zátěže. Úloha vychystávání při 2 Hz není totéž co úloha navigace při 0.5 Hz není totéž co dialogový agent při 0.2 Hz.

Hrubé obálky pro 8GPU K-AI 256 s 8× RTX 5090 (FP8 / INT4 vLLM, jeden model, zapnuté kontinuální dávkování, zapnutá prefix cache; viz I02 a K03):

Toto jsou obálky, ne sliby. Čísla se mění s délkou výzvy, rozlišením obrazu, mírou zásahů do prefix-cache (mnohem vyšší v kontextu flotily, protože roboti ve stejné budově sdílejí kontext prostředí) a přesnou kombinací předvyplnění a dekódování. Důležitý je vzorec: Malé úlohy využívající pouze VLM obsluhují mnoho robotů na server; velké úlohy využívající VLM v smyčce jich obsluhují jen málo.

Skutečná instalace zřídka provozuje jeden model. Vozový park vykonávající užitečnou práci obvykle potřebuje 72B VLM pro uvažování o scéně, 32B LLM pro plánování a malou VLA pro detailní analýzu pohybu. 8× K-AI provozuje všechny tři současně. S touto kombinací je realistický strop na jednom serveru 4–6 humanoidů provádějících práci s uzavřenou smyčkou VLMTo je číslo, se kterým je třeba počítat – ne optimistické „naměřili jsme 24 souběžných požadavků o objemu 7 miliard“.

Dávkovací páka (a proč jsou vozové parky levné)

Důvod, proč jeden velký server poráží mnoho malých serverů, je kontinuální dávkovánívLLM uchovává průběžně zpracovávané požadavky; při každém průchodu dopředu se dokončené požadavky vyřazují a přidávají se nové. Veřejné benchmarky ukazují, že vLLM dosahuje na stejném hardwaru 2.3× vyšší propustnosti než inference generování textu a 14–24× vyšší propustnosti než naivní PyTorch, a to právě díky této páce.

Pro flotilu se efekt sčítá. Pět robotů, které zasáhnou stejný koncový bod VLM s podobnými výzvami, vytváří téměř ideální vzorec dávkování: většina požadavků sdílí dlouhou systémovou výzvu (splnění prefixové mezipaměti 80–95 %), časy příchodu jsou dostatečně dekorelované, aby dávka zůstala plná, a náklady na požadavek se amortizují oproti sdílené práci s předběžným vyplňováním.

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

Zdvojnásobení robotů je ne zdvojnásobení výpočetních nákladů, když sdílejí backend. Toto je argument na straně zátěže pro jeden velký server oproti mnoha malým. Připočtěte to k argumentu kapitálových nákladů (jeden box 8× 5090 je v kusovníku levnější než dva boxy 4× 5090 o ~15–25 %) a argumentu provozních nákladů (jeden server k monitorování, ne dva) a matematika je jednostranná pro flotily až do přibližně osmi robotů.

Po osmé hodině stejně potřebujete druhý server a otázkou je, jak rozdělit provoz – jak je popsáno níže.

Architektura pro flotilu 3–8 robotů

Tři roviny na jednom fyzickém hostiteli (méně než ~8 robotů): správa flotily, koordinace a inference. Každá z nich je logicky odlišná; rozdělena mezi hostitele nad tuto velikost.

Tři letadla, ne jedna krabice. letadlo pro správu vozového parku je vrstva orientovaná na operátora – inventář robotů, telemetrie, aktualizace OTA, upozornění. koordinační rovina je vrstva mezi roboty – sdílené mapy, alokace úkolů, paměť scén. inferenční rovina je vrstva obsluhující model – vLLM za routerem. Pro flotily do ~8 robotů běží na stejném fyzickém hostiteli K-AI, za tímto limitem na samostatných hostitelích.

Směrování požadavků: co se nachází před vLLM

Naivní nastavení s jedním koncovým bodem vLLM, čtyřmi roboty a TCP round-robinem funguje týden a pak se zhroutí, když první požadavek trvá 8 sekund a další čtyři čekají ve frontě za ním. Router je ten, kdo tomu brání.

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

Obyčejný nginx s least_conn. Round-robin je špatný; chcete nejméně aktivní připojení, aby pomalý požadavek netáhl za sebou celou flotilu. Pět řádků konfigurace. Správná odpověď pro jeden model, jeden koncový bod, dvě repliky. Nic nedělá pro KV cache ani pro lokalitu prefixů.

vLLM Router (Rust, vydáno koncem roku 2025). Konzistentní hashování prefixu promptu, takže stejná konverzace přistane na stejné replice a mezipaměť prefixů zůstává aktivní. Pro flotilu, kde každý robot má svou vlastní konverzaci, ale všichni sdílejí dlouhý systémový prompt, je to správné řešení. Zásady jsou cache_aware, power_of_two, a round_robin; pro produkční flotily je výchozí nastavení rozpoznávání mezipaměti.

llm-d na Kubernetes. Předvyplňování/dekódování disagregace, plánování více replik, rozšíření inference brány. Správné řešení, když máte ≥4 repliky, smíšené typy modelů a operační tým nativní pro Kubernetes. Pro všechny ostatní je to zbytečné.

Afinita relace je rafinovaná otázka. Robot komunikující s plánovacím agentem těží z pevného směrování do stejné repliky (prefix cache). Robot, který spouští jednorázové tagy scény VLM, ne – ty jsou bezstavové, směrujte je kruhově. Správná odpověď je směrování podle typu požadavku, nikoli podle klienta: plánování s ohledem na mezipaměť, označování scén pomocí round robin. Směrovač vLLM podporuje obojí prostřednictvím politiky pro jednotlivé koncové body.

Paměť scény: kde se nachází kontext každého robota

Robot není klient bez státní příslušnosti. Pamatuje si, kde včera nechal klíč, kdo prošel dveřmi před hodinou a že kartonová krabice v uličce číslo 7 tam leží už tři dny. Tato vzpomínka musí někde žít a volba... kde je jedním z rozhodnutí o nosnosti při návrhu vozového parku.

Tři vzory:

Možnost A – pgvector pro každého robota na serveru. Každý robot má svou vlastní kolekci ve sdílené instanci Postgres+pgvector. Paměť je odolná, dotazovatelná ze strany serveru, přístupná pro správu vozového parku. Jednoduchá, škálovatelná na desítky robotů na jednom Postgresu. Soukromí je slabinou: každý bajt paměti každého robota je centralizovaný.

Možnost B — paměť scény na robotu s RAG na server. Robot uchovává svá vlastní vnoření v lokálním úložišti sqlite-vss nebo DuckDB. Když se dotazuje na serverový VLM, odešle relevantní načtené části jako součást výzvy. Paměť je lokální a soukromá; síť vidí pouze to, co se robot rozhodl odeslat. Vhodnější pro citlivá nasazení (zdravotnictví, obrana, kdekoli operátor nechce, aby robot opouštěl surovou paměť). Vyžaduje vyšší šířku pásma sítě na hovor.

Možnost C – sdílené úložiště scén s jmennými prostory. Všichni roboti zapisují a čtou z jednoho úložiště pgvector, definovaného v názvovém prostoru podle lokality nebo úkolu. Robot 2 se může zeptat „co robot 1 dnes ráno viděl v nakládací rampě?“ a získat užitečnou odpověď. Toto je jediná možnost, která podporuje skutečné kolaborativní úkoly. Je to také možnost, kdy poškozený zápis od jednoho robota znečišťuje světonázor ostatních.

Poctivý výchozí stav pro flotilu 3–8 robotů je Možnost C s přísnou kontrolou přístupu — roboti zapisují do svého vlastního jmenného prostoru, čtou ze sdíleného jmenného prostoru „svět“, který je spravován (správce vozového parku do něj po ověření přenáší pozorování). Pro nasazení citlivá na soukromí je to možnost B. Možnost A je cestou nejmenšího odporu a je vhodná, pokud není vyžadována spolupráce.

Strategie sdílení modelů

Výchozí nastavení – jeden model obsluhující N robotů – je vhodné pro většinu flotil. Roboti vykonávají podobné úkoly; základní model je stejný; rozdíly spočívají v promptech a načteném kontextu, nikoli ve vahách. Toto je nejlevnější cesta a poskytuje nejvyšší efektivitu dávkového zpracování.

Dva případy, kdy se to porouchá:

Jemně vyladěné hlavy pro každého robota. Robot 1 se nachází ve skladu a je vyladěn pro manipulaci s paletami. Robot 2 se nachází v laboratoři a je vyladěn pro manipulaci s přístroji. Obsluhujete stejný základní VLM s různými LoRA adaptéry nahranými na požadavek. vLLM podporuje obsluhu více LoRA (--enable-lora --max-loras N) s malou režií na požadavek a sdíleným dávkovým zpracováním základního modelu. Užitečné, když jemné doladění činí 0.1–1 % základních vah (typické pro LoRA) a máte 2–10 různých adaptérů.

Speciální modely pro každou třídu úkolu. Rozdíl model na úlohu — Qwen2.5-VL pro obecné uvažování o scénách, OpenVLA pro uchopení, vyladěná 7B pro dialog. Každý model má svůj vlastní koncový bod vLLM na svém vlastním řezu GPU. Trasy podle typu požadavku. Více VRAM, méně dávkování na model, více operační plochy. Správná odpověď, jakmile ověříte, že jeden model danou úlohu nezvládne, ne dříve.

Začněte s jedním modelem. Adaptéry LoRA přidejte, pokud máte naměřenou mezeru v kvalitě na robota. Speciální modely přidejte, pokud máte naměřenou mezeru na úkol, kterou LoRA nedokáže překlenout.

Správa robotického vozového parku (RFM) – vyberte produkt

Vytvoření vlastního RFM je past, do které většina týmů jednou padne. Funkce jsou sice zřejmé co do rozsahu, ale ve skutečnosti drahé: inventář, příjem telemetrie, ukládání časových řad, OTA kanál, směrování upozornění, přístup založený na rolích, auditní protokoly, multitenancy, pokud máte zákazníky. Malý tým si vytvoří verzi, která funguje pro jednu flotilu a pod druhou se rozbije. Kupte si raději jednu z nich a upravte ji podle ní.

Open-RMF spravuje od roku 2024 organizace Open Source Robotics Alliance a zabývá se alokací úkolů, řešením konfliktů a arbitráží sdílené infrastruktury (výtahy, dveře, chodby). Pro on-premise nasazení ve stylu Kentina se smíšenými roboty od různých dodavatelů – řekněme jeden Unitree G1, jeden Booster T1, jeden čtyřnohý Go2, všichni na stejném místě – je Open-RMF jedinou důvěryhodnou otevřenou cestou. Formant a Orbit jsou vynikající, ale jsou to SaaS a preferují svůj vlastní ekosystém.

Poctivý selhání: Open-RMF pro lokální smíšené dodavatele, Formant pro hostované systémy s vysokou pozorovatelností, Orbit pouze pro Boston Dynamics. Vytvářet si vlastní RFM je špatné, pokud RFM explicitně neprodáváte jako produkt.

Koordinace více robotů na drátě

Jmenné prostory ROS 2. Každý robot provozuje svůj ROS 2 stack pod unikátním jmenným prostorem (/r01/, /r02/, …). Témata, služby a parametry DDS jsou také rozděleny do jmenných prostorů. Roboti se přihlašují k odběru témat o stavu peerů (/r02/pose, /r03/pose) přímo přes DDS, bez brokera. DDS v ROS 2 je peer-to-peer a dobře se škáluje na desítky robotů v jedné lokální síti LAN; nad ~50 se objevovací provoz stává hlučným a je třeba buď rozdělit podle ID domény DDS, nebo přejít do režimu objevovacího serveru v ROS 2.

MQTT pro telemetrii nahoru, příkazy dolů. ROS 2 / DDS je skvělý pro nízkolatenční stav peerů v LAN. Není ideální pro „odesílání 0.5Hz telemetrie stavu do cloudu pro správu vozového parku přes nestabilní LTE backhaul“. MQTT je pro to ten správný nástroj – lehké, brokerem zprostředkované úrovně QoS pro garantované doručení, nativní podpora v každé platformě vozového parku. Typické rozdělení: DDS v LAN, MQTT (nebo HTTPS) přes WAN.

Přidělování úkolů. Dva přístupy skutečně používané ve flotilách roku 2026:

1. Centrální plánovač. Správce vozového parku přiřazuje úkoly na základě dostupnosti robota, baterie, umístění a kapacity. Jednoduché, předvídatelné, vhodné pro 90 % případů. Open-RMF to zvládne ihned po instalaci.
2. Na bázi aukce. Roboti přihazují na úkoly na základě cenové funkce (vzdálenost, baterie, aktuální zatížení). Nejnižší nabídka vyhrává. Lepší pro heterogenní flotily nebo dynamická prostředí. Nedávné práce ukazují, že aukční metody dosahují ~12% úspory energie oproti alokaci nejbližšího úkolu u flotil 2–20 robotů. U flotil 10+ robotů se složitost vyplatí; níže uvedené je zbytečné.

Zabránění srážkám. Každý robot zveřejňuje svou polohu s frekvencí 10 Hz; každý robot se přihlašuje k pozicím ostatních robotů. Lokální plánovači berou v úvahu trajektorie pohybu ostatních robotů. Pro flotily, kde dva roboti běžně sdílejí pracovní prostor o rozloze 1 m², je také potřeba koordinační vrstva (kanonickým řešením je řízení provozu v Open-RMF).

Řešení poruch v rozsahu vozového parku

Princip je jednoduchý: Poruchy by měly být izolovány, degradované režimy by měly být plynulé a obnova by měla být automatická. Praktické vzory:

Jeden robot umírá, ostatní pokračují. Každý robot je autonomní ve svém palubním počítači, což zajišťuje bezpečnost a reaktivní vnímání. Ztráta jednoho robota je ztrátou jednoho robota – kolegové na něj neblokují čekání. Správce vozového parku ho označí, přerozdělí mu úkoly a upozorní člověka.

Selže inferenční server. Každý robot by měl být schopen se uchýlit k režim pouze na palubě Když je server nedostupný: žádný velký VLM, žádné dlouhodobé plánování, ale lokální ovládání, vyhýbání se překážkám a předem nahrané kroky mise stále fungují. Robot se efektivně stává „slepým k jazyku“, ale nepadá. Počítejte s tím; testujte ho měsíčně se záměrným blokováním firewallu na straně serveru.

Probíhá aktualizace inferenčního serveru. Dvě repliky za routerem vLLM; vyprázdnit jednu, znovu nasadit, ověřit, vyprázdnit druhou, znovu nasadit. Roboti nevidí žádné viditelné přerušení, protože router vyprázdní pouze repliky bez požadavků za provozu. Modrá/zelená je také správné volání pro výměnu modelů – načíst nový model na replice B, přepnout ukazatel routeru, ověřit několik dotazů, vyřadit repliku A. Přeskočení zahřívacího kroku kousne všechny přesně jednou (viz I02 na rozcvičce (chytil jsem tě).

Pravidlo 1 z N. V libovolném okamžiku ve flotile N robotů předpokládejme, že jeden je ve stavu degradace, jeden je offline a jeden dělá něco neočekávaného. Naplánujte kapacitu pro N-2 efektivní roboti. Pokud N-2 nestačí pro danou pracovní zátěž, flotila je špatně dimenzována.

Pozorovatelnost v měřítku vozového parku

Řídicí panel, který skutečně chcete, seřazený podle priority:

1. Zdraví jednotlivých robotů. Baterie, teplota integrované grafické karty, časové razítko posledního sezení, aktuální úloha, poslední chyba. Jeden řádek na robota, aktualizace každých 5 sekund, stav červená/žlutá/zelená. Toto je první věc, na kterou se operátor každé ráno podívá.
2. Latence na robota k inferenčnímu serveru. Doba přenosu dat P50, P95, P99 pro volání VLM každého robota. Skoky v P99 jsou hlavním indikátorem degradace Wi-Fi, přetížení serveru nebo výměny modelu, která se nezahřála.
3. Hloubka fronty obsluhy modelu. vllm_num_requests_waiting na koncový bod. Trvalá nenulová hodnota je signálem, že flotila předbíhá server. Výstraha při 10+ po dobu delší než minutu.
4. Teplotní mapa využití vozového parku. Kteří roboti jsou zaneprázdněni, kde v budově a co dělají. Provozní pohled; informuje manažera, zda je flotila robotů vyvážená.
5. Vzorkování výstupu modelu. Malý zlomek (1–5 %) odpovědí modelu setrvával ve frontě pro kontrolu. Manuální namátková kontrola každý týden. Jediný způsob, jak zachytit tiché regrese kvality.

Prometheus + Grafana pro metriky; zobrazení stavu robota je obvykle takové, jaké RFM nabízí (Formant, Orbit nebo vaše vlastní Grafana). Relevantní série vLLM 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 — toto jsou informace o stavu na straně inference; exportér DCGM se zabývá stranou GPU.

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

Dvě pozorování:

• Kapitálové náklady na robota jsou od počtu 4 robotů výše zhruba stejné. Pod hodnotou 4 dominují fixní náklady na server. Nad hodnotou 4 platíte lineárně za výpočetní výkon úměrně zátěži. Ideální hodnota pro... První Server je 4–6 robotů.
• Kapitálové náklady na robota (které jsou samostatné a dominantní) se lineárně škálují. Výpočetní náklady jsou malou položkou, jakmile počet robotů ve vozovém parku přesáhne přibližně 3. Jediným velkým nákladovým faktorem je „potřebujete vůbec on-premise?“ (viz R08), nikoli „jaká velikost serveru“.

Výpočetní ekonomie silně argumentuje pro jeden velký K-AI server obsluhující 4–8 robotů na více menších serverech. Dva servery K-AI 256 jsou pro stejnou flotilu horší než jeden K-AI 256 s 8× Pro 6000, dokud nedosáhnete stropu kapacity serverů, který spouští DP=2. Křížení je specifické pro pracovní vytížení, ale při náročné práci s VLM-in-the-loop se pohybuje kolem 7–9 robotů.

Upřímný pohled

Flotily s více než pěti roboty představují jinou operační disciplínu než jednotlivé jednotky. Nejedná se o „pětkrát jeden robotický projekt“. Jedná se o jiný typ projektu, kde:

• Výpočet je malá položka; operace jsou to nejdůležitější
• Úzkým hrdlem je obvykle lidský problém (pozornost manažera), a to spíše než technický problém.
• Wi-Fi a plánování spotřeby energie jsou třikrát těžší než u vozového parku velikosti 1
• Náklady na jemné doladění každého robota jsou reálné; náklady na degradaci modelu v celém vozovém parku jsou reálnější.
• Vytvoření vlastního RFM je téměř vždy špatné; vyberte si jeden a upravte si ho.

Výpočetní stránka problému bude skutečně vyřešena do roku 2026. vLLM + router + dostatečně velký server K-AI zvládne flotily až do velikosti 8 humanoidů na jednom serveru. Kromě toho je škálování možné pomocí datového paralelismu (více serverů za routerem) – popsáno v K03Složité problémy nad velikostí flotily 5 jsou provozní, nikoli architektonické.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.