Roboter-Compute: on-board oder off-board?

Jeder Workload auf einem Roboter läuft an einem von zwei Orten: on-board, gespeist aus dem Akku und gekühlt von den Brustlüftern, oder off-board, auf einem netzbetriebenen Server einen LAN-Hop entfernt. Die schwierige Frage ist nicht, ob Sie beides brauchen – das tun Sie fast immer –, sondern welcher Workload wohin gehört und warum. R08 begründet, warum eine dedizierte Edge-Ebene überhaupt existiert. Dieser Artikel liefert die Entscheidung pro Workload: Motorsteuerung hierhin, VLM dorthin, STT je nach Fall – und so weiter.

Der Blickwinkel ist bewusst pointiert. Pro Workload gibt es eine richtige Antwort, und diese Antwort verschiebt sich, sobald das On-Board-Silizium aufholt. Wir sagen für jeden Baustein, in welche Richtung er sich 2026–2027 bewegt.

Die zwei Budgets, die alles entscheiden

Ein Workload kann genau dann on-board laufen, wenn er gleichzeitig in zwei Budgets passt: Leistung und Speicher. Latenz ist die dritte Randbedingung, verrät aber meist nur, in welche Richtung man einen ohnehin passenden Workload schiebt – nicht, ob er überhaupt passt.

Leistungsbudget eines Humanoiden. Ein Humanoid mit 30–50 kg trägt 700–900 Wh Akkukapazität. Dauerhaftes Gehen zieht 200–500 W aus den Aktuatoren, bei dynamischen Bewegungen sind Spitzen von über 800 W möglich. Stillstehen und Nachdenken kostet 80–150 W an den Aktuatoren (Haltemoment ist günstig, Haltung bewahren kostet). Damit bleiben rund 60–120 W für alles Übrige – Compute, Sensorik, Lüfter, Funk –, wenn Sie eine brauchbare Laufzeit von zwei Stunden anstreben. Innerhalb dieses Rahmens liegt das Compute-Budget bei 30–80 W im Dauerbetrieb. Wer den Jetson permanent auf MAX_N (60 W) fährt, halbiert die Laufzeit des Roboters. Das ist Physik, keine Designentscheidung.

Speicherbudget. Ein Jetson AGX Orin 64 GB bietet 64 GB LPDDR5, die sich CPU und GPU teilen. Davon gehen ab: das Betriebssystem (4–6 GB), ROS 2 und das Hersteller-SDK (2–4 GB), Wahrnehmungspuffer (2–4 GB für Stereo-Tiefendaten und Punktwolken) sowie der Anwendungscode. Realistisch bleiben 40–48 GB für LLM/VLM. Auf einem Jetson Thor 128 GB steigt die Obergrenze auf rund 96 GB nutzbar. Auf einem Orin NX 16 GB bricht sie auf rund 8–10 GB ein – genug für genau ein kleines Modell.

Off-board stellen sich beide Budgets ganz anders dar. Ein Kentino AI 96 (4× RTX 5090) verfügt über 128 GB dedizierten VRAM und 1.0–1.5 kW GPU-Leistung aus der Steckdose. Ein Kentino AI 256 (8× RTX 5090) verdoppelt beides. Leistung und Speicher sind schlicht keine Randbedingung mehr – dafür tauschen Sie sie gegen Investitionskosten, Raumklimatisierung und verkabeltes Netzwerk ein.

On-Board-Silizium: der Stand 2026

Diese On-Board-Optionen kommen heute in ernstzunehmenden Humanoiden und Vierbeinern tatsächlich zum Einsatz:

Thor ist ein Sprung, keine Iteration. Die Speicherobergrenze von 128 GB und die FP4-nativen Blackwell-Tensor-Cores verschieben die On-Board-Grenze in einer einzigen Generation von „7B-VLM, mit Mühe" auf „32B-VLM, sinnvoll nutzbar". Workloads, die 2025 strukturell off-board gehörten – mittelgroße VLMs, kontinuierliche Szenenbeschreibung, LLM-Planer mittlerer Größe –, werden 2026 zu On-Board-Kandidaten , sofern die Kühllösung des Roboters 100–130 W dauerhaft abführen kann.

Hailo und die Klasse der dedizierten NPUs sind keine LLM-Beschleuniger. Sie lagern die Vision-Pipeline aus: Der Haupt-Jetson bleibt für das größere Modell frei, während die dauerhaft laufende Kamera-Bildverarbeitung (Objekterkennung, Tracking, einfaches VLM-Lite) auf einem 3-W-Chip abläuft.

Die QRB-Klasse von Snapdragon ist die Antwort für sprachzentrierte Roboter – Wake-Word, Beamforming, STT –, wo ein Jetson überdimensioniert und ein Cortex-M zu schwach wäre. Nützlich, eng umrissen und zunehmend verbreitet.

Off-board: die Kentino AI Klasse als Referenz

Als Off-Board-Referenz dient in dieser Serie durchgehend die Kentino AI Reihe – netzbetrieben, 4U oder 5U im Rack, 4 oder 8 GPUs auf EPYC oder Xeon, an einem 10-GbE-Switch einen Hop vom Roboter entfernt. Die drei für die Robotik relevanten Ausbaustufen:

Die Entscheidungsmatrix

Jeder Robotik-Workload lässt sich sauber einer von fünf Kategorien zuordnen: immer on-board, bevorzugt on-board, beides möglich, bevorzugt off-boardund ausschließlich off-board. Ausschlaggebend ist jeweils die bindende Randbedingung – Leistung, Speicher oder Latenz.

Drei Erkenntnisse aus dieser Tabelle verdienen besondere Beachtung.

Die Zeilen „immer on-board" sind Physik. Keine noch so große Bandbreite repariert einen Regelkreis, der 1 kHz braucht. Diese Zeilen ändern sich nie, egal wie gut Netzwerk oder Off-Board-Compute werden.

In den Zeilen „beides möglich" findet das eigentliche Engineering statt. Hier liegen die meisten interessanten Abwägungen. Ob ein 7B-VLM on-board oder off-board läuft, prägt das Verhalten des Gesamtsystems spürbar. Eine allgemeingültige richtige Antwort gibt es nicht.

Die Zeilen „ausschließlich off-board" bewegen sich langsam. Ein 72B-Modell wird vermutlich auch 2027 noch ausschließlich off-board laufen. Ein 32B-Modell wandert on-board, sobald Thor in Stückzahlen verfügbar ist. Die Grenze dessen, was on-device passt, verschiebt sich etwa alle 18–24 Monate um eine Modellgrößenklasse.

Zuordnung der Latenzklassen

Das vierstufige Latenzbudget aus I01 lässt sich direkt auf die Platzierung übertragen:

In den beiden mittleren Klassen fallen die eigentlichen Architekturentscheidungen. Ein reflexiver Workload, der gerade so in 50 ms passt, kann über ein kabelgebundenes LAN off-board funktionieren (0.5 ms Hinweg + 40 ms Inferenz + 0.5 ms Rückweg = 41 ms), sprengt das Budget über Wi-Fi 6E unter Last aber deutlich (8 ms × 2 + 40 ms = 56 ms, zuzüglich Jitter). Genau deshalb sind kabelgebundene Tether in der Entwicklung so wertvoll: Sie zeigen, ob ein Workload grundsätzlich off-board passt, bevor Sie sich mit dem Funknetz herumschlagen.

Was das Netzwerk wirklich leistet

Off-board funktioniert nur, wenn das Netzwerk mitspielt. Die konkreten Zahlen:

Für deliberative Workloads (Budget 100 ms – 1 s) genügt Wi-Fi 6E auf einer dedizierten SSID mit einem AP in Sichtverbindung. Für reflexive Workloads (10–50 ms) ist Kabel die sichere und Wi-Fi 6E die riskante Antwort. Planen Sie entsprechend: Hat die Aufgabe eines Roboters irgendeinen reflexiven Off-Board-Anteil, sehen Sie für die Entwicklung eine Kabelverbindung und für den Ernstfall einen Rückfallmodus bei schwächelndem WLAN vor.

Das Hybridmuster – die Fast/Slow-Aufteilung

Das Muster, auf das die meisten ernsthaften Deployments 2026 hinauslaufen, ist die Fast/Slow-Aufteilung beim VLM: ein kleines VLM on-board für sofortiges Feedback, ein großes VLM off-board für wohlüberlegte Entscheidungen – beide speisen denselben Planer.

Konkret sieht das so aus:

Fast/Slow-Aufteilung: Das 7B-Modell on-board übernimmt die unmittelbare Reaktion, das 72B-Modell off-board das durchdachte Schlussfolgern und die Planaktualisierung.

Das schnelle Modell erledigt „da läuft jemand auf mich zu, langsamer werden". Das langsame Modell erledigt „die Person, die auf mich zukommt, ist die Bedienerin, die mich gebeten hat anzuhalten, wenn sie sich mit dem roten Klemmbrett nähert – und das ist ein rotes Klemmbrett, also anhalten". Das schnelle Modell legt sich zuerst auf sicheres Verhalten fest; das langsame Modell verfeinert es.

Die Migration – was 2026–2027 on-board wandert

Drei Kräfte lassen die Off-Board-Seite schrumpfen: Thor kommt in Stückzahlen (2070 FP4 TFLOPS, 128 GB Unified Memory, 130 W Leistungsrahmen – ein struktureller Sprung gegenüber Orin); die VLM-Effizienz verbessert sich weiter (ein „gutes" Wahrnehmungs-VLM brauchte 2024 noch 70B+, liegt 2026 bei 32B und dürfte 2027 bei 13B–20B landen); und Speculative Decoding mit kleinen Drafter-Modellen liefert die Qualität großer Modelle bei der Latenz kleiner Modelle.

Diese Workloads wandern in den nächsten 18 Monaten am ehesten on-board: Szenen-VLMs der 7B-Klasse (bereits im Umzug), LLM-Planer mit 13B (Thor macht sie komfortabel), STT-LLM-TTS mit kurzem Kontext für Sprache sowie domänenspezifisch feinabgestimmte 7B-VLMs.

Diese Workloads wandern nicht : alles ab 70B, Szenengedächtnis auf Flottenebene, Training und Simulation, Mehrstrom-VLM-Fusion. Sie bleiben mindestens bis 2027 off-board. Speicherbandbreite und Akkuleistung entwickeln sich schlicht nicht so schnell.

Zwei konkrete Konfigurationen

Einzelner G1 EDU, Forschungslabor. On-board läuft auf einem AGX Orin ROS 2, YOLOv11-s mit 30 FPS, Whisper-distil STT sowie Qwen2.5-VL 7B INT4 mit 5–8 FPS (deliberativ). Off-board betreibt ein Kentino AI 96 (4× RTX 5090, 128 GB VRAM) vLLM mit Qwen2.5-VL 72B und Qwen2.5 32B (nur Text), ein pgvector-Szenengedächtnis sowie Isaac Sim auf den ungenutzten GPUs.

Kleine Flotte, 3 Humanoide, On-Board der Thor-Klasse. Jede Einheit nutzt einen Hailo-15 Vision-SoC für die dauerhafte Mehrkamera-Erkennung, Whisper-small on-device sowie Qwen2.5-VL 32B INT4 mit 10–15 FPS – nativ und nicht mehr grenzwertig. Off-board hostet ein Kentino AI 256 (8× RTX 5090, 256 GB VRAM) ein gemeinsames Qwen2.5-VL 72B und Llama-3.1 70B für die Planung, einen gemeinsamen pgvector-Speicher für alle drei Roboter und zwei GPUs, die für nächtliches LoRA-Fine-Tuning reserviert sind.

Wo reine Einzelebenen-Deployments tatsächlich funktionieren

Rein on-board funktioniert bei Vierbeinern mit eng umrissener Aufgabe (Perimeterstreife mit YOLO + Wärmebildkamera), teleoperierten Robotern (der Bediener ist der Planer, kein VLM im Regelkreis), Demo- und Lehrrobotern mit den kleinsten Modellen sowie überall dort, wo gar kein Netzwerk verfügbar ist (Außeninspektion, abgelegene Standorte).

Rein cloudbasiert funktioniert bei rein sprachgesteuerten Roboterassistenten ohne geschlossenen Wahrnehmungskreis, bei Prototypen, bei denen Geschwindigkeit in der Einrichtung alles schlägt, und bei Deployments, deren Daten ohnehin gezielt in einen Cloud-Workload fließen.

Hybrid ist die Antwort für alles dazwischen – und das sind rund 90% der ernsthaften Robotik im Jahr 2026. Wer irgendetwas mit VLM-gestützter Wahrnehmung im Regelkreis baut, landet zwangsläufig bei beiden Ebenen. Planen Sie das von Tag eins an ein.

---

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