Flottenbetrieb: Mehrere Roboter, gemeinsame Rechenleistung

Ein Roboter ist ein Projekt. Fünf Roboter sind ein System. Zwanzig Roboter sind ein Betrieb. Jedes Team, das über die erste Einheit hinauswächst, stellt fest, dass sich die technische Aufgabenstellung auf dem Weg nach oben zweimal grundlegend verändert – einmal bei etwa drei Robotern, ein zweites Mal bei zehn. Dieser Artikel beschreibt, was sich ändert, warum die KI-Server von Kentino besser skalieren als viele erwarten und welche operative Disziplin Sie ab Tag 1 von Flotte 2 mit Roboter 3 tatsächlich brauchen.

I01 behandelte das Zwei-Kisten-Problem für einen Roboter und einen Server. K03 beschrieb, wie vLLM ein Modell über mehrere GPUs verteilt. R08 begründete, warum On-Premises überhaupt sinnvoll ist. Dieser Beitrag baut auf allen dreien auf und beantwortet die nächste Frage: Sie wollen das Ganze jetzt N-mal tun – was bricht dabei?

Die drei Regime

Es gibt drei relevante Größenordnungen von Flotten. Die Übergänge zwischen ihnen sind operativer, nicht technischer Natur – die Hardware sieht ähnlich aus, die Art des Betriebs nicht.

Unverblümt formuliert: Planen Sie ab Roboter 3 eine Person ein, die den Robotikbetrieb hauptverantwortlich übernimmt. Die Grenze ist weder das Netzwerk noch der GPU-Server, sondern menschliche Aufmerksamkeit. Eine Person kann zwei Roboter nebenbei betreuen. Bei fünf wird aus dem Takt von „bei dem einen ist der Akku leer, beim zweiten driftet das Lidar, beim dritten flappt das Netzwerk“ eine Vollzeitaufgabe – und wer das ignoriert, verbrennt die erste Einstellung mit einer halbherzigen Teilzeitlösung.

Die Rechenökonomie – was ein 8-GPU-Kentino-AI-Server tatsächlich bedient

Die Kenngröße, an der sich Ihre Dimensionierung orientieren sollte, sind gleichzeitige VLM-Anfragen pro Sekunde und Roboter, nicht Roboter pro Server. Ein Roboter ist keine feste Last, sondern eine Lastklasse. Eine Greifaufgabe mit 2 Hz ist etwas anderes als eine Navigationsaufgabe mit 0.5 Hz und etwas anderes als ein Dialogagent mit 0.2 Hz.

Grobe Richtwerte für einen 8-GPU-Kentino AI 256 mit 8× RTX 5090 (FP8 / INT4 unter vLLM, ein Modell, Continuous Batching aktiv, Prefix-Cache aktiv; siehe I02 und K03):

Das sind Richtwerte, keine Zusagen. Die Zahlen verschieben sich mit der Promptlänge, der Bildauflösung, der Trefferquote des Prefix-Caches (im Flottenbetrieb deutlich höher, weil Roboter im selben Gebäude denselben Umgebungskontext teilen) und dem konkreten Verhältnis von Prefill zu Decode. Entscheidend ist das Muster: Workloads mit ausschließlich kleinen VLMs bedienen viele Roboter pro Server, Workloads mit großen VLMs in der Regelschleife nur wenige.

Eine reale Installation betreibt selten nur ein Modell. Eine Flotte, die sinnvolle Arbeit leistet, will meist ein 72B-VLM für das Szenenverständnis, ein 32B-LLM für die Planung und ein kleines VLA für die feingranulare Bewegungsabsicht. Der Kentino AI mit 8 GPUs betreibt alle drei gleichzeitig. Mit diesem Mix liegt die realistische Obergrenze eines Servers bei 4–6 Humanoiden in geschlossener VLM-Regelschleife. Mit dieser Zahl sollten Sie planen – nicht mit dem optimistischen „wir haben 24 gleichzeitige 7B-Anfragen gemessen“.

Der Batching-Hebel (und warum Flotten günstig sind)

Der Grund, warum ein großer Server mehrere kleine schlägt, heißt Continuous Batching. vLLM hält einen rollierenden Batch laufender Anfragen vor; bei jedem Forward-Pass fallen fertige Anfragen heraus und neue kommen hinzu. Öffentliche Benchmarks zeigen für vLLM den 2.3-fachen Durchsatz von Text Generation Inference und den 14- bis 24-fachen von naivem PyTorch auf derselben Hardware – genau wegen dieses Hebels.

Im Flottenbetrieb verstärkt sich der Effekt. Fünf Roboter, die denselben VLM-Endpunkt mit ähnlichen Prompts ansprechen, erzeugen ein nahezu ideales Batching-Muster: Die meisten Anfragen teilen sich einen langen System-Prompt (Prefix-Cache-Trefferquote 80–95 %), die Ankunftszeiten sind ausreichend unkorreliert, damit der Batch gefüllt bleibt, und die Kosten pro Anfrage amortisieren sich über die gemeinsame Prefill-Arbeit.

1 Roboter  = 1.00× Rechenlast (Basis)
2 Roboter  = ~1.6× Rechenlast (Batching hilft)
4 Roboter  = ~2.5× Rechenlast
8 Roboter  = ~4.0× Rechenlast

Doppelt so viele Roboter bedeuten nicht doppelte Rechenkosten, wenn sie sich ein Backend teilen. Das ist das lastseitige Argument für einen großen statt vieler kleiner Server. Nehmen Sie das Investitionsargument hinzu (eine Kiste mit 8× 5090 ist in der Stückliste rund 15–25 % günstiger als zwei Kisten mit je 4× 5090) sowie das Betriebsargument (ein Server zu überwachen statt zwei), und die Rechnung fällt für Flotten bis etwa acht Robotern eindeutig aus.

Jenseits von acht brauchen Sie ohnehin einen zweiten Server, und die Frage wird, wie Sie den Traffic aufteilen – dazu weiter unten mehr.

Die Architektur für eine Flotte aus 3–8 Robotern

Drei Ebenen auf einem physischen Host (bis ~8 Roboter): Flottenmanagement, Koordination und Inferenz. Jede ist logisch eigenständig; ab dieser Größe werden sie auf mehrere Hosts verteilt.

Drei Ebenen, nicht eine Kiste. Die Flottenmanagement-Ebene ist die Schicht für die Betreiberseite – Roboterinventar, Telemetrie, OTA-Updates, Alarme. Die Koordinationsebene ist die Schicht zwischen den Robotern – gemeinsame Karten, Aufgabenverteilung, Szenengedächtnis. Die Inferenzebene ist die Modell-Serving-Schicht – vLLM hinter einem Router. Bei Flotten unter ~8 Robotern laufen alle drei auf demselben physischen Kentino AI Host, darüber auf getrennten Hosts.

Request-Routing: was vor vLLM sitzt

Ein naiver Aufbau mit einem vLLM-Endpunkt, vier Robotern und TCP-Round-Robin funktioniert eine Woche lang und kippt dann beim ersten Request, der 8 Sekunden braucht und die nächsten vier hinter sich aufstaut. Genau das verhindert der Router.

Drei Optionen, nach Komplexität geordnet:

Einfaches nginx mit least_conn. Round-Robin ist die falsche Wahl; Sie wollen Least-Active-Connections, damit ein langsamer Request nicht die gesamte Flotte hinter sich herzieht. Fünf Zeilen Konfiguration. Die richtige Antwort für ein Modell, einen Endpunkt, zwei Replikate. Für KV-Cache oder Prefix-Lokalität bringt es nichts.

vLLM Router (in Rust, veröffentlicht Ende 2025). Consistent Hashing über das Prompt-Präfix, sodass dieselbe Konversation immer auf demselben Replikat landet und der Prefix-Cache warm bleibt. Für eine Flotte, in der jeder Roboter eine eigene Konversation führt, alle aber denselben langen System-Prompt teilen, ist das die richtige Wahl. Die Policies heißen cache_aware, power_of_twound round_robin; Cache-Aware ist der Standard für Produktivflotten.

llm-d auf Kubernetes. Prefill/Decode-Disaggregation, Scheduling über mehrere Replikate, Gateway-Inference-Extensions. Die richtige Antwort, wenn Sie ≥4 Replikate, gemischte Modelltypen und ein Kubernetes-erprobtes Betriebsteam haben. Für alle anderen überdimensioniert.

Die subtile Frage ist die Session-Affinität. Ein Roboter, der mit einem Planungsagenten spricht, profitiert von Sticky Routing auf dasselbe Replikat (Prefix-Cache). Ein Roboter, der einzelne VLM-Szenen-Tags abfeuert, nicht – diese Aufrufe sind zustandslos und können per Round-Robin verteilt werden. Die richtige Antwort lautet: nach Anfragetyp routen, nicht nach Client: Planung cache-aware, Szenen-Tagging per Round-Robin. Der vLLM Router unterstützt beides über eine Policy je Endpunkt.

Szenengedächtnis: wo der Kontext jedes Roboters liegt

Ein Roboter ist kein zustandsloser Client. Er weiß noch, wo er gestern den Schraubenschlüssel liegen gelassen hat, wer vor einer Stunde durch die Tür kam und dass der Karton in Gang 7 dort seit drei Tagen steht. Dieses Gedächtnis muss irgendwo liegen, und die Frage, wo , gehört zu den tragenden Entscheidungen eines Flottenentwurfs.

Drei Muster:

Variante A – pgvector je Roboter auf dem Server. Jeder Roboter erhält eine eigene Collection in einer gemeinsamen Postgres-Instanz mit pgvector. Das Gedächtnis ist dauerhaft, serverseitig abfragbar und für das Flottenmanagement zugänglich. Einfach, skaliert auf einer Postgres-Instanz bis zu Dutzenden Robotern. Schwachpunkt ist der Datenschutz: Jedes Byte des Gedächtnisses jedes Roboters liegt zentral.

Variante B – Szenengedächtnis auf dem Roboter mit RAG zum Server. Der Roboter hält seine Embeddings lokal in einem sqlite-vss- oder DuckDB-Store. Fragt er das Server-VLM an, schickt er die relevanten abgerufenen Abschnitte als Teil des Prompts mit. Das Gedächtnis bleibt lokal und privat; über das Netz geht nur, was der Roboter bewusst sendet. Die bessere Wahl für sensible Einsätze (Medizin, Verteidigung oder überall dort, wo der Betreiber keine Rohdaten des Gedächtnisses aus dem Roboter herauslassen will). Kostet mehr Netzwerkbandbreite pro Aufruf.

Variante C – gemeinsamer Szenenspeicher mit Namespaces. Alle Roboter schreiben in einen gemeinsamen pgvector-Store und lesen aus ihm, getrennt nach Standort oder Aufgabe. Roboter 2 kann fragen: „Was hat Roboter 1 heute Morgen in der Laderampe gesehen?“ – und erhält eine brauchbare Antwort. Nur diese Variante unterstützt echte kollaborative Aufgaben. Sie ist zugleich die Variante, in der ein fehlerhafter Schreibvorgang eines Roboters das Weltbild aller anderen verfälscht.

Der ehrliche Standard für eine Flotte aus 3–8 Robotern ist Variante C mit strenger Zugriffskontrolle – jeder Roboter schreibt in seinen eigenen Namespace und liest aus einem gemeinsamen, kuratierten „World“-Namespace (der Flottenmanager übernimmt Beobachtungen erst nach Prüfung dorthin). Für datenschutzsensible Einsätze Variante B. Variante A ist der Weg des geringsten Widerstands und völlig in Ordnung, solange Zusammenarbeit keine Anforderung ist.

Strategien zur Modellnutzung

Der Standard – ein Modell bedient N Roboter – ist für die meisten Flotten richtig. Die Roboter erledigen ähnliche Aufgaben, das Basismodell ist dasselbe, die Unterschiede stecken in Prompts und abgerufenem Kontext, nicht in den Gewichten. Das ist der günstigste Weg und liefert die höchste Batching-Effizienz.

Zwei Fälle, in denen das nicht mehr trägt:

Feinabgestimmte Köpfe je Roboter. Roboter 1 steht im Lager und ist auf Palettenhandling feinabgestimmt. Roboter 2 steht im Labor und ist auf die Handhabung von Messgeräten feinabgestimmt. Sie betreiben dasselbe Basis-VLM und laden je Anfrage unterschiedliche LoRA-Adapter. vLLM unterstützt Multi-LoRA-Serving (--enable-lora --max-loras N) mit geringem Zusatzaufwand pro Anfrage und gemeinsamem Batching auf dem Basismodell. Sinnvoll, wenn die Feinabstimmungen 0.1–1 % der Basisgewichte ausmachen (typisch für LoRA) und Sie 2–10 verschiedene Adapter haben.

Spezialmodelle je Aufgabenklasse. Ein anderes Modell je Aufgabe – Qwen2.5-VL für allgemeines Szenenverständnis, OpenVLA fürs Greifen, ein feinabgestimmtes 7B für den Dialog. Jedes Modell bekommt seinen eigenen vLLM-Endpunkt auf seinem eigenen GPU-Anteil. Das Routing erfolgt nach Anfragetyp. Mehr VRAM, weniger Batching je Modell, mehr Betriebsaufwand. Die richtige Antwort erst, wenn Sie nachweislich festgestellt haben, dass ein einzelnes Modell die Aufgabe nicht löst – vorher nicht.

Beginnen Sie mit einem Modell. Ergänzen Sie LoRA-Adapter, sobald Sie eine gemessene Qualitätslücke je Roboter haben. Ergänzen Sie Spezialmodelle, sobald Sie eine gemessene Lücke je Aufgabe haben, die LoRA nicht schließt.

Robot Fleet Management (RFM) – kaufen Sie ein Produkt

Ein eigenes RFM zu bauen, ist eine Falle, in die die meisten Teams einmal tappen. Der Funktionsumfang wirkt überschaubar, ist in der Umsetzung aber teuer: Inventar, Telemetrie-Ingest, Zeitreihenspeicher, OTA-Pipeline, Alarm-Routing, rollenbasierte Zugriffsrechte, Audit-Logs, Mandantenfähigkeit, sobald Sie Kunden haben. Ein kleines Team baut eine Version, die für eine Flotte funktioniert und an der zweiten zerbricht. Kaufen Sie stattdessen eines der folgenden Produkte und passen Sie es an.

Open-RMF wird seit 2024 von der Open Source Robotics Alliance betreut und übernimmt Aufgabenverteilung, Konfliktauflösung und die Vergabe gemeinsam genutzter Infrastruktur (Aufzüge, Türen, Korridore). Für einen On-Premises-Einsatz nach Kentino-Vorbild mit Robotern mehrerer Hersteller – etwa ein Unitree G1, ein Booster T1 und ein Go2-Vierbeiner am selben Standort – ist Open-RMF der einzige glaubwürdige offene Weg. Formant und Orbit sind hervorragend, aber eben SaaS und auf ihr jeweiliges Ökosystem ausgerichtet.

Der ehrliche Standard: Open-RMF für On-Premises mit gemischten Herstellern, Formant für gehostete Setups mit starkem Observability-Bedarf, Orbit für reine Boston-Dynamics-Flotten. Ein eigenes RFM zu bauen, ist falsch – es sei denn, Sie verkaufen RFM ausdrücklich als Produkt.

Koordination mehrerer Roboter auf der Leitung

ROS-2-Namespaces. Jeder Roboter betreibt seinen ROS-2-Stack unter einem eigenen Namespace (/r01/, /r02/, …). Auch DDS-Topics, Services und Parameter sind namespaced. Roboter abonnieren die Zustands-Topics ihrer Nachbarn (/r02/pose, /r03/pose) direkt über DDS, ganz ohne Broker. Das DDS von ROS 2 arbeitet Peer-to-Peer und skaliert in einem LAN problemlos auf einige Dutzend Roboter; jenseits von ~50 wird der Discovery-Traffic laut, und Sie sollten entweder nach DDS-Domain-ID partitionieren oder auf den Discovery-Server-Modus von ROS 2 wechseln.

MQTT für Telemetrie nach oben, Befehle nach unten. ROS 2 / DDS eignet sich hervorragend für latenzarmen Zustandsaustausch im LAN. Für „0.5-Hz-Zustandstelemetrie über einen wackeligen LTE-Backhaul an die Flottenmanagement-Cloud schicken“ taugt es nicht. Dafür ist MQTT das richtige Werkzeug – leichtgewichtig, brokervermittelt, mit QoS-Stufen für garantierte Zustellung und nativer Unterstützung in jeder Flottenplattform. Die übliche Aufteilung: DDS im LAN, MQTT (oder HTTPS) über das WAN.

Aufgabenverteilung. Zwei Ansätze sind in Flotten des Jahres 2026 tatsächlich im Einsatz:

1. Zentraler Scheduler. Der Flottenmanager vergibt Aufgaben nach Verfügbarkeit, Akkustand, Position und Fähigkeiten der Roboter. Einfach, berechenbar, passt für 90 % der Fälle. Open-RMF bringt das ab Werk mit.
2. Auktionsbasiert. Roboter bieten auf Aufgaben anhand einer Kostenfunktion (Entfernung, Akkustand, aktuelle Auslastung). Das niedrigste Gebot gewinnt. Besser für heterogene Flotten oder dynamische Umgebungen. Aktuelle Arbeiten zeigen für Auktionsverfahren rund 12 % Energieeinsparung gegenüber der Vergabe an den nächstgelegenen Roboter, bei Flotten von 2–20 Einheiten. Ab 10 Robotern ist der Mehraufwand gerechtfertigt, darunter überzogen.

Kollisionsvermeidung. Jeder Roboter veröffentlicht seine Pose mit 10 Hz, jeder Roboter abonniert die Posen der anderen. Die lokalen Planer berücksichtigen die Trajektorien der Nachbarn. In Flotten, in denen sich zwei Roboter regelmäßig einen Quadratmeter Arbeitsfläche teilen, brauchen Sie zusätzlich eine Koordinationsschicht (das Verkehrsmanagement von Open-RMF ist hier die kanonische Antwort).

Fehlerbehandlung im Flottenbetrieb

Das Prinzip ist einfach: Fehler müssen isoliert bleiben, Notbetriebsarten müssen sanft greifen, die Wiederherstellung muss automatisch erfolgen. Die praktischen Muster:

Ein Roboter fällt aus, die anderen laufen weiter. Jeder Roboter ist auf seiner Onboard-Rechenleistung autonom, was Sicherheit und reaktive Wahrnehmung angeht. Der Ausfall eines Roboters ist der Ausfall genau eines Roboters – die anderen blockieren nicht und warten nicht auf ihn. Der Flottenmanager markiert ihn als ausgefallen, verteilt seine Aufgaben neu und alarmiert einen Menschen.

Der Inferenzserver fällt aus. Jeder Roboter muss in einen reinen Onboard-Modus zurückfallen können, wenn der Server nicht erreichbar ist: kein großes VLM, keine langfristige Planung, aber lokale Regelung, Hindernisvermeidung und vorab geladene Missionsschritte funktionieren weiter. Der Roboter wird faktisch „sprachblind“, stürzt aber nicht ab. Planen Sie das ein und testen Sie es monatlich mit einer bewusst gesetzten Firewall-Sperre auf Serverseite.

Rolling Update des Inferenzservers. Zwei Replikate hinter dem vLLM Router; eines aus dem Verkehr nehmen, neu ausrollen, prüfen, dann das andere. Die Roboter merken nichts davon, weil der Router nur Replikate ohne laufende Anfragen herausnimmt. Für Modellwechsel ist Blue/Green die richtige Wahl – das neue Modell auf Replikat B laden, den Router umschalten, ein paar Abfragen prüfen, Replikat A stilllegen. Den Warmup-Schritt zu überspringen, kostet jeden genau einmal Lehrgeld (siehe I02 zum Warmup-Stolperstein).

Die 1-von-N-Regel. Gehen Sie zu jedem Zeitpunkt davon aus, dass in einer Flotte von N Robotern einer eingeschränkt läuft, einer offline ist und einer etwas Unerwartetes tut. Planen Sie die Kapazität für N-2 einsatzfähige Roboter. Reichen N-2 nicht für den Arbeitsumfang, ist die Flotte falsch dimensioniert.

Observability im Flottenbetrieb

Das Dashboard, das Sie wirklich brauchen, nach Priorität geordnet:

1. Zustand je Roboter. Akkustand, Onboard-GPU-Temperatur, Zeitstempel des letzten Lebenszeichens, aktuelle Aufgabe, letzter Fehler. Eine Zeile pro Roboter, Aktualisierung alle 5 Sekunden, Statusanzeige in Rot/Gelb/Grün. Das ist das Erste, worauf der Betreiber jeden Morgen schaut.
2. Latenz je Roboter zum Inferenzserver. P50, P95 und P99 der Round-Trip-Zeit für die VLM-Aufrufe jedes Roboters. Sprünge im P99 sind der Frühindikator für nachlassendes WLAN, Serverüberlastung oder einen Modellwechsel ohne Warmup.
3. Warteschlangentiefe beim Modell-Serving. vllm_num_requests_waiting je Endpunkt. Dauerhaft von null verschiedene Werte signalisieren, dass die Flotte dem Server davonläuft. Alarm ab 10 über mehr als eine Minute.
4. Auslastungs-Heatmap der Flotte. Welche Roboter beschäftigt sind, wo im Gebäude und womit. Die operative Sicht; sie zeigt dem Manager, ob die Flotte ausgewogen ausgelastet ist.
5. Stichproben der Modellausgaben. Ein kleiner Anteil (1–5 %) der Modellantworten wird in eine Prüf-Queue geschrieben. Wöchentliche manuelle Stichprobe. Nur so lassen sich schleichende Qualitätsverschlechterungen überhaupt bemerken.

Prometheus und Grafana für die Metriken; die Zustandsansicht je Roboter liefert üblicherweise das RFM (Formant, Orbit oder Ihr eigenes Grafana). Die relevanten vLLM-Serien sind vllm:num_requests_running, vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_secondsund vllm:time_per_output_token_seconds – sie erzählen die Gesundheitsgeschichte der Inferenzseite; die GPU-Seite deckt der DCGM-Exporter ab.

Wie sich die Kosten wirklich entwickeln

Zwei Beobachtungen:

• Die Investition pro Roboter ist ab vier Robotern nahezu konstant. Darunter dominieren die Fixkosten des Servers. Darüber zahlen Sie linear für Rechenleistung proportional zur Last. Der Sweetspot für den ersten Server liegt bei 4–6 Robotern.
• Die Investition in die Roboter selbst (die separat anfällt und überwiegt) skaliert linear. Rechenleistung ist ab etwa drei Robotern der kleine Posten. Der einzige große Kostenhebel ist die Frage „brauchen wir On-Premises überhaupt“ (siehe R08), nicht „welche Servergröße“.

Die Rechenökonomie spricht klar für einen großen Kentino AI Server für 4–8 Roboter statt mehrerer kleiner Server. Zwei Kentino AI 256 sind für dieselbe Flotte schlechter als ein einzelner Kentino AI 256 mit 8× Pro 6000 – bis Sie die Kapazitätsgrenze des Servers erreichen, die DP=2 erzwingt. Der Übergangspunkt hängt vom Workload ab, liegt bei anspruchsvoller VLM-Arbeit in der Regelschleife aber bei etwa 7–9 Robotern.

Die ehrliche Einschätzung

Flotten oberhalb von fünf Robotern erfordern eine ganz andere operative Disziplin als Einzelgeräte. Sie sind nicht „fünfmal ein Ein-Roboter-Projekt“. Sie sind ein Projekt anderer Art, bei dem gilt:

• Rechenleistung ist ein kleiner Posten, der Betrieb ist der große
• Der Engpass ist meist ein menschlicher (die Aufmerksamkeit der verantwortlichen Person), bevor er ein technischer wird
• WLAN- und Stromplanung schlagen dreimal härter zu als bei Flottengröße 1
• Die Kosten einer Feinabstimmung je Roboter sind real; die Kosten einer Modellverschlechterung über die gesamte Flotte sind noch realer
• Ein eigenes RFM zu bauen, ist fast immer falsch; wählen Sie eines aus und passen Sie es an

Die Rechenseite des Problems ist 2026 tatsächlich gelöst. vLLM plus Router plus ein sauber dimensionierter Kentino AI Server bewältigt Flotten bis etwa 8 Humanoiden auf einer einzigen Maschine. Darüber skalieren Sie über Datenparallelität (mehr Server hinter dem Router) – behandelt in K03. Die schwierigen Probleme jenseits von fünf Robotern sind operativer, nicht architektonischer Natur.

Dieser Beitrag ist Teil des Kentino Wiki, einer Referenzreihe zu KI-Compute, Robotik und den Systemen, die beides verbinden. Anmerkungen und Korrekturen gern an info@kentino.com.