Warum Roboter dedizierte Edge-Rechenleistung brauchen

Ein Humanoid, der läuft, ist ein gelöstes Problem. Ein Humanoid, der versteht, was er sieht, eine mehrstufige Aufgabe plant und sich daran erinnert, was vor fünf Minuten geschah, ist es nicht. Die Rechenleistung, die diese Lücke schließt, passt nicht auf den Roboter – und die Cloud ist der falsche Ort dafür. Dieser Beitrag begründet technisch, warum ein dedizierter On-Premise-Inferenzserver im Jahr 2026 die Antwort am Puls der Zeit ist, und zwar für jeden Robotikeinsatz, der ernsthaft produktive Arbeit leisten soll.

I01 beschreibt, wie Roboter und Server miteinander verbunden werden. In diesem Beitrag geht es darum, warum Sie den Server überhaupt anschaffen sollten. Wenn Sie noch überlegen, ob On-Premise sinnvoll ist, lesen Sie zuerst hier weiter.

Das Latenzbudget der Entscheidung

Jede Aktion eines Roboters gehört zu einer von vier Latenzebenen. Jede Ebene hat ein Budget, das die Physik der Aufgabe vorgibt – wird es überschritten, bricht das Verhalten auf eine ganz bestimmte, gut erkennbare Weise zusammen.

Diese Werte sind nicht willkürlich. Sie ergeben sich aus der Bandbreite des Regelkreises, in dem die jeweilige Ebene sitzt.

Die reaktive Regelung läuft auf Gelenkebene mit 500 Hz bis 1 kHz, weil die Dynamik eines 30 kg schweren humanoiden Beins es verlangt – bei 100 Hz gerät die Gliedmaße in Resonanz und das Gangbild divergiert. Die reflexive Wahrnehmung erbt die Bildraten der Kameras (30–60 FPS = 16–33 ms pro Bild) und den Zeitmaßstab des physischen Kontakts (ein Finger, der auf ein Objekt drückt, schließt das Kontaktereignis in 20–40 ms ab). Die deliberative Planung ist durch menschliche Gesprächserwartungen begrenzt (eine Sekunde wirkt flüssig, zwei wirken träge) sowie durch die Modelllatenz eines brauchbaren VLM. Nur das strategische Schlussfolgern hat echten Spielraum – deshalb wollen alle die Planung dorthin verschieben und fallen auf die Nase, sobald ihr VLM nicht mithält.

Das ist keine Kentino-Meinung. Diese Vier-Ebenen-Aufteilung steckt in jedem ernstzunehmenden Robotik-Regelungs-Stack – ROS 2, Isaac, Drake, OCS2. Der Unterschied liegt darin, welche Hardware Sie hinter jede Ebene stellen.

Was die Rechenleistung an Bord leisten kann – und was nicht

Ein Humanoid des Jahres 2026 trägt im Spitzendatenblatt einen NVIDIA Jetson AGX Orin: 64 GB Unified Memory, bis zu 275 TOPS sparse INT8 (138 dense), 15–60 W konfigurierbare Leistung. Für ein Embedded-Modul ist das wirklich beeindruckend. Es ist zugleich weit entfernt von dem, was ein moderner VLM-gesteuerter Roboter braucht.

Rechnen Sie das für drei Modellklassen durch, die Sie auf einem Humanoiden tatsächlich einsetzen wollen würden:

Der Orin AGX mit 64 GB betreibt ein VLM der 32B-Klasse in INT4, sofern Sie langsame Inferenz, kein echtes Batching und keine parallelen Workloads akzeptieren. Er betreibt nicht die VLMs der 70B-Klasse, die 2026 beim Szenenverständnis den Stand der Technik markieren – Qwen2.5-VL 72B, die größeren Cosmos-Varianten, die proprietären Modelle, deren Gewichte die Anbieter nicht veröffentlichen. Gewichte, KV-Cache für langen visuellen Kontext und etwas Luft für ein zweites Modell passen zusammen schlicht nicht hinein.

Eine zweite Zahl wird gern übergangen: die Leistungsaufnahme. Die 275 TOPS des Orin setzen den MAX_N-Modus (60 W) voraus. Das ist eine akkubetriebene Plattform, die zusätzlich zu 200–800 W Aktuatorlast 60 W für Rechenleistung verheizt. Dauerhafter MAX_N-Betrieb halbiert die Laufzeit des Roboters. In der Praxis verbringt der Orin die meiste Zeit im 30-W-Modus, was die TOPS ungefähr halbiert und die ohnehin grenzwertige Inferenz endgültig unbrauchbar macht.

Übersetzt heißt das: Der Jetson an Bord ist auf die reaktive und die reflexive Ebene dimensioniert. Als VLM-Host ist er es nicht. Wer Ihnen erzählt, sein Humanoid „lässt Qwen2.5-VL an Bord laufen", betreibt entweder die 3B- oder 7B-Variante und nennt das ausreichend, oder das größere Modell mit 0.5 FPS und nennt das eine Demo. Beides ist für bestimmte Anwendungsfälle legitim. Universelle Roboterwahrnehmung ist keines von beiden.

Warum die Cloud für geschlossene Regelkreise die falsche Antwort ist

Cloud-Inferenz ist günstig, skaliert mühelos und erfordert keinerlei Investition. Für einen Roboter hat sie vier Probleme, grob nach Schwere geordnet.

1. Die Latenzuntergrenze im WAN. Ein gut abgestimmter Cloud-Aufruf innerhalb der EU erreicht 15–40 ms Round-Trip allein im WAN, plus 5–15 ms Overhead für TLS, HTTP und Load Balancer, plus die Inferenzzeit des Modells, plus den Rückweg. Transatlantisch kommen 80–120 ms Round-Trip obendrauf. Bei einer reflexiven Wahrnehmungsabfrage – „Ist da ein Hindernis vor mir?" – sprengen 30–50 ms, bevor das Modell überhaupt rechnet, das Budget. Bei deliberativer Planung mit 200–500 ms lässt sich das vielleicht verschmerzen, doch jedes verlorene Paket, jede Neuübertragung, jeder Funkzellenwechsel katapultiert Sie eine Ebene höher.

2. Jitter. Die WAN-Umlaufzeit ist keine Konstante, sondern eine Verteilung. Median 25 ms, P99 250 ms, P99.9 mehrere Sekunden. Ein Roboter, der in der realen Welt handelt, kann sich keine mehrsekündige Pause leisten, nur weil eine BGP-Route geflattert ist. Im LAN vor Ort liegt P99.9 bei 1–2 ms.

3. Kosten unter Dauerlast. Eine einzelne Inferenz eines 70B-VLM kostet einen Cloud-Anbieter fast nichts – berechnet werden ein paar Cent. Ein Roboter, der „permanent wahrnimmt", setzt im aktiven Betrieb alle 100–500 ms einen VLM-Aufruf ab. Das sind 7,000–36,000 Aufrufe pro Stunde und Roboter. Eine Flotte von drei Robotern mit acht Betriebsstunden täglich kommt am oberen Ende auf 850,000 Aufrufe. Selbst bei nur 0.005 US-Dollar pro Aufruf an einem gehosteten 72B-Endpunkt sind das 4,250 US-Dollar pro Tag und 125.000 US-Dollar pro Monat. Ein On-Premise-Server mit 8 GPUs hat sich bei dieser Last in weniger als drei Monaten amortisiert.

4. Datensouveränität. Der Roboter sieht eine Fertigungshalle, ein Patientenzimmer, ein Forschungslabor, ein Lager mit vertraulichem Bestandslayout, einen militärischen Übungsplatz. Dieses Videomaterial ist schutzwürdig oder unterliegt der DSGVO, HIPAA, ITAR oder schlicht dem Wettbewerbsgeheimnis. Es in eine fremde Cloud zu schicken – selbst in eine mit Auftragsverarbeitungsvertrag – ist entweder untersagt oder ein erheblicher Compliance-Aufwand. On-Premise-Inferenz lässt die Frage der Datensouveränität verschwinden: Die Bytes verlassen das Gebäude nie.

Es gibt ein fünftes, weicheres Problem: Vendor-Lock-in. Cloud-APIs liefern die Modelle, die der Anbieter liefern will – mit den Quantisierungen und Kontextfenstern, die er gewählt hat. Sie können kein feinjustiertes VLM auf dem Endpunkt von OpenAI betreiben. Sie können keinen bestimmten Commit eines Open-Weight-Modells festschreiben. Sie können in einer Pipeline keine Modelle konkurrierender Anbieter mischen. Zum Prototyping sind diese Einschränkungen in Ordnung. Für einen produktiven Robotikeinsatz, der über Jahre berechenbar bleiben muss, sind sie es nicht.

Das Argument für den dedizierten Edge-Server

Ein dedizierter On-Premise-Inferenzserver steht im LAN, ein bis zwei Hops vom Roboter entfernt. Bei der Kentino AI Serie ist das ein 4U-Rackserver mit EPYC- oder Xeon-Host, 4× oder 8× GPU, angebunden an einen 10-GbE-Switch. Die Zahlen, die er mitbringt:

Die beiden Spalten, in denen die On-Premise-Variante klar dominiert, sind Dauerdurchsatz und Modellauswahl. Genau diese beiden Spalten sind für die gleich folgenden Workloads am wichtigsten.

Ein typischer Kentino AI 256 Turin Dual mit 8× RTX 5090 verfügt über 256 GB VRAM im Verbund und 1.0–1.5 kW GPU-Leistung unter Last. Das genügt, um gleichzeitig zu betreiben:

• Qwen2.5-VL 72B in INT4 (~45–50 GB Gewichte + 10–20 GB KV je GPU-Paar, tensorparallel über 4 GPUs)
• Qwen2.5 32B rein textbasiert (Planung, Dialog) auf 2 GPUs
• ein kleines VLA (OpenVLA 7B oder Cosmos-Reason 7B) auf 1 GPU für die Bewegungsabsicht
• Szenengedächtnis / RAG-Speicher (pgvector oder ChromaDB) auf der Host-CPU
• Kapazität für Online-Fine-Tuning der Policy auf der verbleibenden GPU, während der Roboter in der Dockingstation steht

Die TTFT des VLM liegt für Qwen2.5-VL 72B auf dieser Hardware bei einzelnen Anfragen im Bereich von 200–400 ms und steigt unter hoher paralleler Last auf 1–4 Sekunden. Das Token-Streaming erreicht 25–50 tok/s. Damit lässt sich ein 72B-VLM bei einem einzelnen Roboter in der Ebene der deliberativen Planung (100 ms – 1 s) und bei einer kleinen Flotte in der Ebene des strategischen Schlussfolgerns (1 s – mehrere s) ansiedeln. Beide Ebenen sind unkritisch; die reaktive und die reflexive Ebene bleiben an Bord, wo sie hingehören.

Die Fähigkeitslücke: was nur die dedizierte Edge-Ebene abdeckt

Der Server vor Ort ist nicht einfach „derselbe Roboter, nur schneller". Er ermöglicht eine Klasse von Workloads, die die beiden anderen Ebenen strukturell nicht tragen können. Die ehrliche Liste:

1. Szenenverständnis in Echtzeit als Rückkopplung. Ein 72B-VLM schaut alle 200–500 ms durch die Kamera des Roboters und liefert eine strukturierte Szenenbeschreibung, die der Planer verarbeitet. Die Cloud schafft das wegen WAN-Jitter und Kosten nicht in der Breite. An Bord geht es nicht, weil das Modell nicht hineinpasst. Vor Ort schließt sich der Kreis in insgesamt 250–500 ms.

2. VLM-Fusion über mehrere Kameras. Ein Humanoid hat 3–5 Kameras (Kopf, zwei Handgelenke, zwei am Körper bzw. an der Brust). Ein VLM gleichzeitig über alle laufen zu lassen – für räumliche Verankerung, den Umgang mit Verdeckungen oder die Hand-Auge-Koordination – bedeutet die fünffache Inferenzlast. Die Cloud begrenzt die Rate oder rechnet pro Stream ab. An Bord passt ein Stream in kleinem Maßstab. Vor Ort laufen alle fünf gebündelt über denselben VLM-Endpunkt.

3. Aufgabenplanung über lange Horizonte mit dauerhaftem Szenengedächtnis. „Gestern habe ich den Schraubenschlüssel im zweiten Regalfach liegen lassen. Finde ihn." Dafür müssen VLM, LLM und Vektorspeicher zusammenarbeiten und den Zustand über Robotersitzungen hinweg behalten. Dieser Zustand braucht einen Ort, der stabil, abfragbar und schnell ist. Das ist eine Datenbank auf dem Server – kein Kontextfenster, das pro Cloud-Aufruf entsteht, und keine 4 GB RAM auf dem Jetson.

4. Online-Fine-Tuning der Policy. Der Roboter sammelt tagsüber Aufgabendemonstrationen. Über Nacht, während er in der Dockingstation steht, laufen LoRA-Fine-Tunings auf den Tagesdaten gegen ein Basis-VLA; der aktualisierte Adapter wird eingespielt, und am nächsten Tag ist der Roboter besser. Das braucht den 2- bis 5-fachen Speicherbedarf gegenüber der Inferenz. Die Cloud berechnet Training und Speicher separat. Vor Ort steckt beides in derselben Box.

5. Koordination einer Roboterflotte. Zwei oder drei Roboter teilen sich ein Szenengedächtnis, stimmen Aufgaben ab und beobachten den Zustand der anderen. Die Koordinationsschicht zwischen den Robotern verlangt Latenzen unter 10 ms. Ein gemeinsamer Server im LAN liefert das. Die Cloud nicht – jede Aktualisierung geht in eine Region, kommt zurück und erreicht erst dann den nächsten Roboter.

6. Iteration von Sim zu Real. Isaac Sim läuft auf denselben GPUs, die auch die Inferenz bedienen, erzeugt synthetische Trainingsdaten und validiert Policy-Updates, bevor sie den echten Roboter erreichen. In der Cloud dauert eine Iteration allein durch die Datenbewegung einen halben Tag, vor Ort schließt sich die Schleife in 30 Minuten.

Nichts davon ist Science-Fiction. Das alles sind Workloads, die Robotik-Integratoren 2026 bereits produktiv fahren. Und keiner davon läuft auf einer der beiden anderen Ebenen sauber.

Warum das 2026 die Antwort am Puls der Zeit ist

Der Stand der Technik bei der Roboterwahrnehmung heißt 2026 VLM-in-the-Loop. Das Modell betrachtet die Welt, denkt sprachlich darüber nach, gibt strukturierte Pläne aus, und die Policy führt sie aus. 2023 war das eine Forschungsidee, 2024 eine Produktdemo – 2025/2026 ist es produktive Praxis.

Der Trend, der die Ebene vor Ort erzwingt, ist simpel: Die VLMs, die wirklich funktionieren, werden größer, nicht kleiner. Qwen2.5-VL 7B ist gut. Qwen2.5-VL 72B ist spürbar besser. Die proprietären Modelle, die die führenden Labore nicht veröffentlichen, sind noch größer. Den Weg des „kleinen VLM, das auf dem Gerät läuft" gibt es und wird es weiter geben, doch er hinkt der Spitze um 12 bis 18 Monate und um eine merkliche Fähigkeitslücke hinterher. Wer das Verhalten der Spitzenklasse will, muss das Spitzenmodell hosten. Und das passt nicht auf einen Jetson.

Theoretisch könnte die Cloud mithalten. Praktisch tut sie es nicht – aus den vier genannten Gründen (Latenz, Jitter, Kosten, Souveränität) und weil die führenden Labore ihre größten Modelle hinter Partnerstufen verriegeln, zu denen ein Robotik-Start-up keinen Zugang hat. Open-Weight-VLMs der 70B-Klasse existieren tatsächlich, lassen sich hosten und laufen auf handelsüblichen 8-GPU-Servern gut. Genau dieses Zusammentreffen – Open-Weight-Modelle der Spitzenklasse plus handelsübliche Multi-GPU-Hardware – macht On-Premise heute zur richtigen Antwort, die es 2023 noch nicht war.

Auch das ist keine Kentino-Meinung. Die Inferenzebene vor Ort ist das, worum herum NVIDIAs Isaac-Stack gebaut ist, wofür die großen Robotikplattformen Referenzarchitekturen ausliefern und was jeder ernstzunehmende Integrator, mit dem wir in den letzten sechs Monaten gesprochen haben, gerade beschafft. Der Markt hat zur Hardware aufgeschlossen, die Hardware zu den Modellen – und 2026 ist das Jahr, in dem sich alles fügt.

Wann On-Premise die falsche Antwort ist

Der Ehrlichkeit halber: In einigen realen Fällen ist die dedizierte Edge-Ebene überdimensioniert.

• Teleoperierte Roboter. Der Mensch ist der Planer, der Roboter eine Marionette mit Steuerverbindung. Es gibt kein VLM im Regelkreis; die wenige Inferenz, die anfällt (Posenschätzung, latenzarme Videocodierung), läuft auf dem Jetson. Für Schwergewichtiges lässt sich bei Bedarf die Cloud hinzunehmen. Ein GPU-Server ist nicht nötig.
• Einfache Inspektions-Vierbeiner. Ein Roboter der Spot- oder Go2-Klasse, der eine feste Patrouillenroute abläuft, mit Erkennung auf YOLO-Niveau und einer Wärmebildkamera, braucht kein 72B-VLM. Der Jetson an Bord erledigt das. Die Daten gehen nach der Patrouille zur Auswertung in die Cloud, nicht währenddessen.
• Demos und einmalige Pilotprojekte. Sie brauchen das System für eine Messe, einen Kundentermin, einen dreiwöchigen Proof of Concept. Mit der Cloud steht es an einem Nachmittag. Investitionen vor Ort sind für einen Workload falsch, der in einem Monat wieder abgebaut wird.
• Hobby und Lehre. Ein Universitätslabor mit einem G1 EDU, knappem Budget und Schwerpunkt auf RL-Training statt Inferenz. Der Jetson und eine einzelne Workstation mit 4090 tragen genug für sinnvolle Forschung. Die volle Kentino AI Stufe mit 8 GPUs ist hier die falsche Rechnung.
• Reine Sprach-Workloads. Ein Roboter, der spricht, aber nicht sieht – ein Sprachassistent auf Beinen. Eine Cloud-LLM-API genügt. Das Latenzbudget ist ein Gesprächsbudget, kein geschlossener Regelkreis.

Das Muster: Läuft in Ihrem geschlossenen Wahrnehmungskreis kein echtes VLM, brauchen Sie die dedizierte Edge-Ebene nicht. Läuft eines, brauchen Sie sie.

Wann sich On-Premise rechnet

Die dedizierte Edge-Ebene wird zur richtigen Antwort, sobald mindestens einer der folgenden Punkte zutrifft – idealerweise zwei oder mehr:

1. Ein echtes VLM sitzt im geschlossenen Regelkreis. Nicht „für gelegentliche Fragen", sondern in der Schleife von Wahrnehmung zu Aktion, alle 100–500 ms ausgeführt. Das ist der strukturelle Grund, warum es On-Premise gibt.
2. Dauerlast. Acht Stunden am Tag, fünf Tage die Woche, auf unbestimmte Zeit. Die Investition amortisiert sich. Cloud-Kosten pro Aufruf laufen dagegen endlos weiter.
3. Die Daten dürfen das Gebäude nicht verlassen. DSGVO, HIPAA, ITAR, Wettbewerbsgründe oder schlichte Vorsicht. Die Bytes bleiben im LAN. Nicht verhandelbar.
4. Mehrere Roboter. Zwei oder mehr Einheiten, die sich ein Szenengedächtnis teilen oder Aufgaben abstimmen. Der gemeinsame Server amortisiert sich pro Roboter, und das Latenzbudget zwischen den Robotern schrumpft drastisch.
5. Anpassbarkeit zählt. Feinjustierte VLMs, festgeschriebene Modellversionen, eigene Köpfe auf offenen Backbones, ausgefallene Quantisierungen. Diese Freiheit ist das eigentliche Produkt.
6. Iterationsgeschwindigkeit zählt. Das Team liefert Policy-Updates wöchentlich oder häufiger aus. Simulation und Training auf derselben Hardware wie die Inferenz verkürzen den Zyklus von Tagen auf Stunden.

Treffen drei oder mehr dieser Punkte zu, lautet die Frage nicht mehr ob On-Premise, sondern in welcher Größe. Die Vier-GPU-Stufe Kentino AI 96 (RTX 4090 oder 5090) reicht für einen Roboter im echten Einsatz. Die Acht-GPU-Stufe Kentino AI 256 (5090 oder Pro 6000 Blackwell) ist die passende Größe für eine kleine Flotte, für die größten VLMs oder für jeden Einsatz, bei dem zur Inferenz noch Training hinzukommt.

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.