Flådeimplementering: Flere robotter, delt beregning

Én robot er et projekt. Fem robotter er et system. Tyve robotter er en operation. Hvert team, der er skaleret forbi den første enhed, opdager, at det tekniske problem ændrer form to gange på vej op – én gang omkring tre robotter, igen omkring ti. Denne artikel handler om, hvad der ændrer sig, hvorfor Kentino AI-serverne, som Kentino-skibe skalerer bedre, end folk forventer, og den operationelle disciplin, du rent faktisk har brug for på dag 1 af flåde 2 af robot 3.

I01 dækkede two-box-problemet for én robot og én server. K03 dækkede, hvordan vLLM skærer en model på tværs af GPU'er. R08 argumenterede for, hvorfor on-prem overhovedet skulle anvendes. Denne artikel lægger sig oven i alle tre og besvarer det næste spørgsmål: nu hvor du vil gøre det N gange, hvad går så i stykker?

De tre regimer

Der er tre meningsfulde regimer for flådestørrelse. Overgangene mellem dem er operationelle, ikke tekniske – hardwaren ligner hinanden; måden du kører den på, gør ikke.

Den ligefremme version: planlæg en dedikeret person til robotdrift omkring robot 3. Væggen er ikke netværket eller GPU-serveren; væggen er menneskelig opmærksomhed. Én operatør kan administrere to robotter ad hoc. Som femårig er kadensen "denne døde batteri, den andens lidar drev, den tredjes netværk flagrede" et fuldtidsjob, og at lade som om, det ikke var tilfældet, sveder bare den første ansættelse slemt og på deltid.

Beregningsøkonomien — hvad en 8-GPU Kentino AI rent faktisk tjener

Det tal, der skal styre din størrelsesbestemmelse, er samtidige VLM-anmodninger pr. sekund pr. robot , ikke robotter pr. server. En robot er ikke en fast belastning; det er en arbejdsbelastningsklasse. En plukkeopgave ved 2 Hz er ikke det samme som en navigationsopgave ved 0.5 Hz eller en dialogagent ved 0.2 Hz.

Grove konvolutter for en 8-GPU Kentino AI 256 med 8× RTX 5090 (FP8 / INT4 vLLM, enkelt model, kontinuerlig batching aktiveret, præfiks-cache aktiveret; se I02 og K03 ):

Dette er konvolutter, ikke løfter. Tallene ændrer sig med promptlængden, billedopløsningen, præfiks-cache-hitrate (meget højere i flådekontekster, fordi robotter i samme bygning deler miljøkontekst) og den præcise blanding af præudfyldning vs. afkodning. Det mønster, der betyder noget, er formen: små VLM-kun-arbejdsbelastninger betjener mange robotter pr. server; store VLM-in-the-loop-arbejdsbelastninger betjener få.

En rigtig installation kører sjældent én model. En flåde, der udfører nyttigt arbejde, har normalt brug for en 72B VLM til scene ræsonnement, en 32B LLM til planlægning og en lille VLA til finkornet bevægelsesintention. 8× Kentino AI'en kører alle tre samtidigt. Med den blanding er det realistiske loft på én server 4-6 humanoider, der udfører closed-loop VLM-arbejde . Det er tallet at planlægge i forhold til – ikke det optimistiske "vi målte 24 samtidige 7B anmodninger".

Batchhåndteringen (og hvorfor flåder er billige)

Grunden til, at en enkelt stor server slår mange små servere, er kontinuerlig batching . vLLM indeholder en rullende batch af in-flight-forespørgsler; ved hver fremadrettet gennemløb udfalder færdige anmodninger, og nye anmodninger tilføjes. Offentlige benchmarks viser, at vLLM opnår 2.3 gange så stor gennemløbshastighed som Text Generation Inference og 14-24 gange mere naiv PyTorch på den samme hardware, specifikt på grund af denne håndtag.

For en flåde forstærkes effekten. Fem robotter, der rammer det samme VLM-slutpunkt med lignende prompter, producerer et næsten ideelt batchmønster: de fleste anmodninger deler en lang systemprompt (præfikscache 80-95% rammet), ankomsttider er tilstrækkeligt dekorrekte til, at batchen forbliver fuld, og omkostningerne pr. anmodning amortiseres mod delt præudfyldningsarbejde.

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

En fordobling af robotter er ikke en fordobling af beregningsomkostningerne, når de deler en backend. Dette er belastningsargumentet for én stor server frem for mange små. Læg det til capex-argumentet (én 8× 5090-boks er ~15-25% billigere end to 4× 5090-bokse på styklisten) og driftsargumentet (én server til overvågning, ikke to), og matematikken er ensidig for flåder på op til omkring otte robotter.

Efter otte har du alligevel brug for en anden server, og spørgsmålet bliver, hvordan man deler trafikken – det dækkes nedenfor.

Arkitekturen for en flåde af 3-8 robotter

Tre planer på én fysisk vært (under ~8 robotter): flådestyring, koordinering og inferens. Hvert plan er logisk adskilt; opdelt på tværs af værter ud over denne størrelse.

Tre planer, ikke én boks. Flådestyringsplanet er det operatørvendte lag - robotlager, telemetri, OTA-opdateringer, advarsler. Koordinationsplanet er laget mellem robotter - delte kort, opgaveallokering, scenehukommelse. Inferensplanet er det modelserverende lag - vLLM bag en router. De kører på den samme fysiske Kentino AI-vært for flåder under ~8 robotter, på separate værter ud over det.

Anmodningsrouting: hvad der ligger foran vLLM

En naiv opsætning med ét vLLM-slutpunkt, fire robotter og en TCP-round-robin fungerer i en uge og falder så over første gang, en anmodning tager 8 sekunder, og de næste fire sekunder står i kø bagved. Routeren er det, der forhindrer det.

Tre muligheder, i rækkefølge efter kompleksitet:

Almindelig nginx med least_conn. Round-robin er forkert; du vil have mindst aktive forbindelser, så en langsom anmodning ikke trækker hele flåden bag sig. Fem linjer med konfiguration. Korrekt svar for én model, ét slutpunkt, to replikaer. Gør ingenting for KV-cache eller præfikslokalitet.

vLLM Router (Rust, udgivet sidst i 2025). Konsekvent hashing på promptpræfiks, så den samme samtale lander på den samme replika, og præfikscachen forbliver varm. For en flåde, hvor hver robot har sin egen samtale, men de alle deler en lang systemprompt, er dette det rigtige valg. Politikkerne er cache_aware, power_of_twoog round_robin; cache-aware er standardindstillingen for produktionsflåder.

llm-d på Kubernetes. Forudfyldnings-/afkodningsdisaggregation, planlægning af flere replikaer, gateway-inferensudvidelser. Det rigtige svar, når du har ≥4 replikaer, blandede modeltyper og et Kubernetes-native operationsteam. Overkill for alle andre.

Sessionsaffinitet er det subtile spørgsmål. En robot, der kommunikerer med en planlægningsagent, drager fordel af sticky routing til den samme replika (præfikscache). En robot, der udløser one-shot VLM-scenetags, gør det ikke – de er statsløse, send dem round-robin. Det rigtige svar er routing efter anmodningstype, ikke efter klient : planlægning til cache-bevidst, scenetagging til round-robin. vLLM-routeren understøtter begge dele via en politik pr. endpoint.

Scenehukommelse: hvor hver robots kontekst befinder sig

En robot er ikke en statsløs klient. Den husker, hvor den efterlod skruenøglen i går, hvem der gik ind ad døren for en time siden, at papkassen på gang 7 har været der i tre dage. Den erindring skal bo et sted, og valget af hvor er en af ​​de bærende beslutninger i et flådedesign.

Tre mønstre:

Mulighed A — pgvector pr. robot på serveren. Hver robot har sin egen samling i en delt Postgres+pgvector-instans. Hukommelsen er holdbar, kan forespørges fra serversiden og er tilgængelig for flådestyring. Enkel, skalerbar til snesevis af robotter på én Postgres. Privatliv er det svage punkt: hver byte i hver robots hukommelse er centraliseret.

Mulighed B — scenehukommelse på robotten med RAG til serveren. Robotten opbevarer sine egne indlejringer i et lokalt sqlite-vss- eller DuckDB-lager. Når den forespørger serverens VLM, sender den de relevante hentede chunks som en del af prompten. Hukommelsen er lokal og privat; netværket ser kun, hvad robotten valgte at sende. Bedre til følsomme implementeringer (medicinsk, forsvarsmæssigt, hvor som helst operatøren ikke ønsker, at rå hukommelse forlader robotten). Koster mere netværksbåndbredde pr. opkald.

Mulighed C — delt scenelager med navneafstand. Alle robotter skriver til og læser fra ét pgvector-lager, navneafstand efter sted eller opgave. Robot 2 kan spørge "hvad så robot 1 i læsserampen i morges?" og få et brugbart svar. Dette er den eneste mulighed, der understøtter faktiske samarbejdsopgaver. Det er også den mulighed, hvor en forgiftet skrivning fra én robot forurener de andres verdensbillede.

Den ærlige standard for en robotflåde på 3-8 er mulighed C med streng adgangskontrol – robotter skriver til deres eget navnerum og læses fra et delt "verdens"-navnerum, der er kurateret (flådeadministratoren fremmer observationer til det efter validering). For privatlivsfølsomme implementeringer er mulighed B. Mulighed A er den mindste modstands vej og er fin, hvis samarbejde ikke er et krav.

Strategier for modeldeling

Standardmodellen – én model, der betjener N robotter – er den rigtige for de fleste flåder. Robotterne udfører lignende opgaver; basismodellen er den samme; forskellene findes i prompter og hentet kontekst, ikke i vægte. Dette er den billigste vej og giver den højeste batcheffektivitet.

To tilfælde hvor det går i stykker:

Finjusterede hoveder per robot. Robot 1 befinder sig på lageret og er finjusteret til pallehåndtering. Robot 2 befinder sig i laboratoriet og er finjusteret til instrumentmanipulation. Du betjener den samme basis-VLM med forskellige LoRA-adaptere indlæst pr. anmodning. vLLM understøtter multi-LoRA-servering (--enable-lora --max-loras N) med et lille overhead pr. anmodning og delt batching af basismodellen. Nyttig, når finjusteringerne er 0.1-1 % af basisvægtene (typisk for LoRA), og du har 2-10 forskellige adaptere.

Specialmodeller pr. opgaveklasse. En forskellig model pr. opgave — Qwen2.5-VL til generel scene-ræsonnement, OpenVLA til grebning, en finjusteret 7B til dialog. Hver model får sit eget vLLM-slutpunkt på sin egen GPU-slice. Ruter efter anmodningstype. Mere VRAM, mindre batching pr. model, mere operationel overflade. Rigtigt svar, når du har valideret, at én model ikke kan udføre jobbet, ikke før.

Start med én model. Tilføj LoRA-adaptere, når du har et målt kvalitetsforskel pr. robot. Tilføj specialmodeller, når du har et målt kvalitetsforskel pr. opgave, som LoRA ikke lukker.

Robotflådestyring (RFM) — vælg et produkt

At bygge sin egen RFM er en fælde, som de fleste teams falder i én gang. Funktionerne er åbenlyse i omfang, men dyre i virkeligheden: lagerstyring, telemetriindtagelse, tidsserielagring, OTA-pipeline, alarmrouting, rollebaseret adgang, revisionslogfiler og multi-tenancy, hvis du har kunder. Et lille team vil bygge en version, der fungerer til én flåde og ikke fungerer under den anden. Køb i stedet en af ​​disse, og tilpas den omkring den.

Open-RMF har været administreret af Open Source Robotics Alliance siden 2024 og håndterer opgaveallokering, konfliktløsning og voldgift i delt infrastruktur (elevatorer, døre, korridorer). For en Kentino-lignende on-prem implementering med blandede leverandører af robotter – f.eks. én Unitree G1, én Booster T1, én Go2 quadruped, alle på samme sted – er Open-RMF den eneste troværdige åbne løsning. Formant og Orbit er fremragende, men de er SaaS, og de foretrækker deres eget økosystem.

Den ærlige standard: Open-RMF til on-prem blandede leverandører, Formant til hosted observerbarhed-tung, Orbit kun til Boston Dynamics. Det er forkert at bygge sin egen RFM, medmindre man eksplicit sælger RFM som et produkt.

Koordinering mellem flere robotter på wiren

ROS 2 navneafstand. Hver robot kører sin ROS 2-stak under et unikt navnerum (/r01/, /r02/, …). DDS-emner, tjenester og parametre er også navngivet. Robotter abonnerer på peers tilstandsemner (/r02/pose, /r03/pose) direkte over DDS, ingen broker. ROS 2's DDS er peer-to-peer og skalerer fint til snesevis af robotter på ét LAN; over ~50 bliver discovery-trafikken støjende, og du vil enten partitionere efter DDS-domæne-ID eller skifte til ROS 2's discovery-server-tilstand.

MQTT til telemetri op, kommandoer ned. ROS 2 / DDS er fantastisk til peer-tilstand med lav latenstid på LAN'et. Det er ikke fantastisk til "send 0.5 Hz sundhedstelemetri til flådestyringsclouden over en ustabil LTE-backhaul." MQTT er det rigtige værktøj til det - letvægts, mæglermedieret, QoS-niveauer for garanteret levering, native support i alle flådeplatforme. Den typiske opdeling: DDS på LAN'et, MQTT (eller HTTPS) over WAN'et.

Opgavefordeling. To tilgange, der faktisk anvendes i flåder i 2026:

1. Central planlægger. Flådeadministratoren tildeler opgaver baseret på robottens tilgængelighed, batteri, placering og kapacitet. Enkel, forudsigelig og passer til 90 % af tilfældene. Open-RMF gør dette direkte fra starten.
2. Auktionsbaseret. Robotter byder på opgaver baseret på en omkostningsfunktion (afstand, batteri, strømbelastning). Det laveste bud vinder. Bedre til heterogene flåder eller dynamiske miljøer. Nyere arbejde viser, at auktionsmetoder opnår ~12% energibesparelser i forhold til nærmeste opgaveallokering på flåder på 2-20 robotter. Værd at være kompleksiteten ved flåder på 10+; overkill nedenfor.

Kollisionsundgåelse. Hver robot offentliggør sin position ved 10 Hz; hver robot abonnerer på peer-positioner. Lokale planlæggere tager højde for peer-baner. For flåder, hvor to robotter rutinemæssigt deler et arbejdsområde på 1 m², har du også brug for et koordineringslag (Open-RMF's trafikstyring er det kanoniske svar).

Håndtering af fejl på flådeniveau

Princippet er enkelt: fejl skal isoleres, degraderede tilstande skal være problemfrie, og genoprettelse skal være automatisk. De praktiske mønstre:

Én robot dør, andre fortsætter. Hver robot er autonom på sin indbyggede computer af sikkerhedsmæssige årsager og reaktiv opfattelse. Tab af én robot er tab af én robot – andre robotter blokerer ikke for at vente på den. Flådechefen markerer den, omfordeler dens opgaver og advarer et menneske.

Inferensserveren fejler. Enhver robot skal kunne falde tilbage til on-board-only-tilstand, når serveren ikke kan nås: ingen store VLM'er, ingen langsigtet planlægning, men lokal kontrol, forhindringsundgåelse og forudindlæste missionstrin fungerer stadig. Robotten bliver effektivt "blind for sprog", men går ikke ned. Planlæg for dette; test det månedligt med en bevidst serverside firewallblokering.

Rullende opdatering af inferensserver. To replikaer bag vLLM-routeren; dræn den ene, genimplementer, verificer, dræn den anden, genimplementer. Robotter ser ingen synlig afbrydelse, fordi routeren kun dræner replikaer uden anmodninger under flyvning. Blå/grøn er også det rigtige valg til modelswaps - indlæs den nye model på replika B, skift routerpointer, verificer et par forespørgsler, træk replika A tilbage. At springe opvarmningstrinnet over bider alle præcis én gang (se I02 om opvarmningsfacittet).

1-af-N-reglen. Antag på et hvilket som helst tidspunkt i en flåde af N robotter, at én er degraderet, én er offline, og én gør noget uventet. Planlæg kapacitet for N-2 effektive robotter. Hvis N-2 er ikke nok til arbejdsbyrden, flåden er forkert dimensioneret.

Observerbarhed på flådeniveau

Det dashboard, du rent faktisk ønsker, i prioriteret rækkefølge:

1. Sundhed per robot. Batteri, indbygget GPU-temperatur, sidst set tidsstempel, aktuel opgave, sidste fejl. Én række pr. robot, opdater hvert 5. sekund, rød/gul/grøn status. Dette er det første, operatøren ser på hver morgen.
2. Latens pr. robot til inferensserver. P50, P95, P99 rundturstid for hver robots VLM-kald. Spring i P99 er den ledende indikator for Wi-Fi-forringelse, serveroverbelastning eller et modelskift, der ikke varmede op.
3. Model servering kødybde. vllm_num_requests_waiting pr. slutpunkt. Vedvarende forskellig fra nul er signalet om, at flåden overhaler serveren. Alarm ved 10+ i over et minut.
4. Varmekort over flådeudnyttelse. Hvilke robotter er optaget, hvor i bygningen, og laver hvad. Driftsoversigt; fortæller lederen, om flåden er i balance.
5. Model output sampling. En lille del (1-5%) af modelsvarene blev ved med at blive vist i en gennemgangskø. Manuel stikprøvekontrol ugentligt. Den eneste måde at fange tavse kvalitetsregressioner på.

Prometheus + Grafana for metrikker; sundhedsvisningen pr. robot er normalt den, som RFM leverer (Formant, Orbit eller din egen Grafana). De relevante vLLM-serier er 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 — dette er sundhedshistorien på inferenssiden; DCGM-eksportøren dækker GPU-siden.

Omkostningsskalering i virkeligheden

To observationer:

• Investeringsudgifterne pr. robot er nogenlunde uændrede fra 4 robotter og opefter. Under 4 dominerer serverens faste omkostninger. Over 4 betaler du lineært for beregning proportionalt med belastningen. Det optimale punkt for første Serveren er 4-6 robotter.
• Robot capex (som er separat og dominerende) skaleres lineært. Beregning er den lille post, når flåden er over ~3 robotter. Den eneste store omkostningsløfter er "har du overhovedet brug for on-prem" (se R08), ikke "hvilken størrelse server".

Beregningsøkonomien argumenterer stærkt for én stor Kentino AI-server, der betjener 4-8 robotter over flere mindre servere. To Kentino AI 256-bokse er værre end én Kentino AI 256 med 8× Pro 6000 for den samme flåde, indtil man rammer et serverkapacitetsloft, der udløser DP=2. Crossover'en er arbejdsbelastningsspecifik, men lander omkring 7-9 robotter på tungt VLM-in-the-loop-arbejde.

Den ærlige holdning

Flåder med over fem robotter er en anden operationel disciplin end enkeltstående enheder. De er ikke "fem gange et projekt med én robot". De er en anden projektform, hvor:

• Compute er en lille linjepost; operationer er den store
• Flaskehalsen er normalt en menneskelig en (lederens opmærksomhed), før den er en teknisk en.
• Wi-Fi og strømstyringsplanlægning er tre gange hårdere end ved flådestørrelse 1
• Omkostningerne ved en finjustering pr. robot er reelle; omkostningerne ved modelforringelse på tværs af flåden er mere reelle.
• Det er næsten altid forkert at bygge din egen RFM; vælg en og tilpas den

Problemets beregningsmæssige side er reelt løst inden 2026. vLLM + en router + en Kentino AI-server af god størrelse håndterer flåder på op til omkring 8 humanoider på én boks. Derudover kan skalering ske via dataparallelisme (flere servere bag routeren) – dækket i K03 . De vanskelige problemer over flådestørrelse 5 er operationelle, ikke arkitektoniske.

---

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.