Edge-KI-Architektur: Wie ein Roboter mit einem On-Prem-Inferenzserver spricht

Wer 2026 einen humanoiden oder vierbeinigen Roboter kauft, erhält mit der Einheit nur die Hälfte des Systems. Die andere Hälfte ist die Rechenleistung, auf der die großen Modelle laufen, die der Roboter selbst nicht hosten kann. Dieser Artikel erklärt, was tatsächlich wo liegt, warum es den On-Prem-Weg überhaupt gibt, wenn Cloud-APIs doch günstig sind, und wie die beiden Hälften physisch und logisch miteinander verbunden werden.

Der Artikel richtet sich an Käufer und Integratoren, die sich vor der Bestellung ein klares Bild machen wollen – noch nicht an Entwickler, die den Glue-Code schreiben.

Das Zwei-Box-Problem

Ein moderner Humanoid wie der Unitree G1 oder der Booster T1 trägt ein eingebettetes Compute-Modul an Bord: typischerweise einen Jetson Orin (Klasse NX oder AGX) oder ein SoC der Snapdragon-Klasse, häufig ergänzt um einen kleinen dedizierten MCU für den Motorregelkreis. Vierbeiner wie der Unitree Go2 nutzen denselben Aufbau in kleinerem Maßstab.

Diese On-Board-Rechenleistung genügt für:

• Echtzeit-Motorsteuerung – Gelenkmoment, Balance, Gangbild. Das läuft mit 500 Hz bis 1 kHz und verträgt keinen einzigen Netzwerk-Hop. Es bleibt lokal, Punkt.
• Unmittelbare Sicherheitsreflexe – Sturzschutz, Not-Aus, Kontaktreaktion. Gleiche Randbedingung, gleiche Antwort.
• Wahrnehmung mit geringer Latenz – Tiefeninformation aus Stereo oder RGB-D, IMU-Fusion, einfache Objekterkennung (meist eine kleine YOLO- oder MobileNet-Variante).
• Sprach-Wake-Word und einfaches Routing von Befehlen.

Was die On-Board-Rechenleistung sinnvollerweise nicht leisten kann:

• Große Vision-Language-Modelle (VLMs) wie Qwen2.5-VL 72B, NVIDIA Cosmos oder OpenVLA. Sie brauchen zig GB VRAM und sind für eine akkubetriebene Plattform schlicht zu stromhungrig.
• Große Sprachmodelle (LLMs) für Dialog oder Planung oberhalb der quantisierten 7B–8B-Klasse.
• Diffusions- oder autoregressive Bewegungsplaner die mit einem Kontext von mehreren hundert Millisekunden arbeiten.
• Szenengedächtnis und Aufgabengraphen über lange Zeithorizonte.

Diese Aufteilung ist keine Meinung von Kentino. Sie ist die tatsächliche Partitionierung, mit der heute jede ernstzunehmende Humanoid-Plattform ausgeliefert wird. Das On-Board-Modul ist auf Sicherheit und Latenz ausgelegt; das schwere Denken wandert nach außen.

Das Ziel „außerhalb“ kann die Cloud sein (OpenAI, Anthropic, gehostetes NVIDIA Cosmos) oder ein On-Prem-Inferenzserver. Im weiteren Verlauf geht es darum, wann und warum Sie die On-Prem-Variante wollen.

Was wo liegt – die praktische Aufteilung

Die Zwei-Box-Aufteilung: Die lokale Regelung bleibt auf dem Roboter; schwere Inferenz und Training wandern über das LAN auf den On-Prem-Server.

Drei Punkte verdienen Beachtung:

1. Der Roboter braucht keinen GPU-Server, um zu laufen. Fällt das LAN aus, steht die Einheit weiterhin auf, hält die Balance und fährt nicht gegen die Wand. Die externe Pipeline erweitert die Fähigkeiten – Sprache, Planung, Aufgaben über lange Zeithorizonte –, sie ersetzt die lokale Regelung nicht.
2. Manche Workloads sind Verhandlungssache. Ein kleines VLM (etwa Qwen2.5-VL 7B quantisiert) läuft durchaus auf einem Jetson Orin AGX. Ob Sie es an Bord oder nach außen verlagern, ist eine Abwägung zwischen Leistungsaufnahme, Thermik und Latenz. Es gibt keine allgemein richtige Antwort.
3. Der Server leistet mehr als reine Inferenz. Eine ernsthafte Installation betreibt zusätzlich Training (Feinabstimmung auf eine konkrete Umgebung), Simulation (Isaac Sim für die Policy-Iteration) sowie Szenengedächtnis und Retrieval. „Inferenzserver“ ist die Kurzform für „GPU-Compute-Backend“.

Das Latenzbudget

Die eine Zahl, die darüber entscheidet, ob Ihre Architektur funktioniert, ist die Round-Trip-Zeit vom Roboter zum Server und zurück.

Die Zahlen, die das Budget dominieren, sind die serverseitige Modelllatenz und – falls Sie drahtlos arbeiten – der Wi-Fi-Jitter. Der Transport selbst ist in einem kabelgebundenen LAN selten der Engpass. Deshalb arbeiten die meisten ernsthaften Roboterinstallationen mit einem Kabel-Tether oder einem dedizierten Wi-Fi-6/6E-Access-Point in Sichtverbindung zum Arbeitsbereich.

Wenn Ihr Roboter einen gesprochenen Befehl in unter einer Sekunde beantworten muss, sieht die Rechnung ungefähr so aus:

Audioaufnahme          ~ 50 ms\nWake-Word + STT        100–250 ms  (an Bord oder extern, Ihre Wahl)\nLLM-TTFT (Planung)     200–500 ms  (serverseitig)\nLLM-Stream 20 Tokens   600–1200 ms\nTTS                    100–300 ms\nAudioausgabe           ~ 50 ms\n                       --------------\n                       ~ 1.1 – 2.3 s

Mit einem 70B-LLM in der Schleife ist „unter einer Sekunde Ende-zu-Ende“ heute nicht zu schaffen. Sie akzeptieren entweder die Latenz, setzen on-prem ein kleineres Modell ein (Klasse 8B–13B) oder teilen die Antwort auf (sofort quittieren, im Hintergrund planen).

Das ist genau die Art von Abwägung, die nichts mit dem Netzwerk und alles mit der Modellwahl zu tun hat. Und es ist genau die Art von Abwägung, bei der ein eigener Server zählt: Sie können Modelle tauschen, mehrere parallel betreiben, anders batchen. Bei einer Cloud-API nehmen Sie, was der Anbieter liefert.

Warum überhaupt On-Prem

Cloud-Inferenz ist günstig, skaliert mühelos und verlangt keinerlei Investition. Warum also sollte jemand einen Server mit vier oder acht GPUs kaufen, wenn ein OpenAI-API-Key fünfzig Dollar kostet?

Es gibt vier echte Gründe, grob danach sortiert, wie oft sie die Entscheidung tatsächlich treiben:

1. Die Daten verlassen das Gebäude nicht. In Industrie, Verteidigung, Gesundheitswesen und bei DSGVO-sensiblen Installationen in der EU dürfen rohe Sensordaten oft nicht an eine fremde Cloud gehen. Der Roboter sieht eine Fertigungshalle, ein Patientenzimmer, eine Laborbank. Dieses Videomaterial ist entweder vertraulich, reguliert oder wettbewerbsrelevant. On-Prem-Inferenz löst das sauber. Die Cloud nicht.

2. Die Latenzuntergrenze. Jeder Cloud-Aufruf bringt zusätzlich zur Modelllatenz 15–40 ms WAN-RTT mit. Für die meisten Robotikaufgaben ist das unkritisch. Für reaktive Regelung im geschlossenen Kreis – Pick-and-Place unter Zeitdruck, Balancerückgewinnung nach einem Stoß, feine Manipulation – ist die WAN-Untergrenze zu hoch. On-Prem drückt sie unter 1 ms.

3. Kosten bei Dauerlast. Ein einzelner 70B-VLM-Aufruf kostet den Cloud-Anbieter fast nichts; Ihnen werden ein paar Cent berechnet. Doch ein Roboter, der „ständig denkt“, erzeugt Tausende Aufrufe pro Stunde. Ein Forschungslabor mit Training und einer Flotte von Robotern, die gegen dieselben Modelle inferieren, kann problemlos 5,000–15,000 $/Monat an Cloud-Kosten verursachen. Ein On-Prem-Server mit 4× oder 8× GPU amortisiert sich bei dieser Last in weniger als zwölf Monaten.

4. Modellwahl und Anpassung. Sie wollen ein VLM auf Ihre konkrete Umgebung feinabstimmen. Sie wollen ein Modell betreiben, das die Cloud-Anbieter nicht hosten. Sie wollen Open-Weight-Modelle verschiedener Anbieter in einer eigenen Pipeline kombinieren. On-Prem gibt Ihnen das. Cloud-APIs nicht.

Wenn keiner dieser vier Punkte auf Ihre Installation zutrifft, sollten Sie die Cloud nutzen. Die ehrliche Antwort lautet: Vielleicht 30–40 % der Robotikkäufer brauchen On-Prem wirklich; der Rest entscheidet sich aus Prestigegründen dafür oder weil dem eigenen Einkauf die Cloud nicht geheuer ist. Auch das sind legitime Gründe – aber wir tun nicht so, als wäre es anders.

Netzwerktopologie

Netzwerktopologie: Roboter über Wi-Fi 6E → dedizierter AP → 10-GbE-Switch → Inferenzserver. Egress und WAN sind optional.

Ein paar praktische Hinweise, die viele überraschen:

• Wi-Fi 6E ist die Untergrenze, nicht die Obergrenze. Das 6-GHz-Band ist das einzige, das in Umgebungen mit vielen anderen Geräten durchgängig niedrige Latenzen liefert. Rechnen Sie mit einem AP je rund 50 m² Arbeitsfläche des Roboters, möglichst in Sichtverbindung.
• Kabelgebunden ist immer noch besser. Bietet der Roboter eine Tether-Option (manche Humanoide für die Forschung tun das, Vierbeiner in der Regel nicht), nutzen Sie sie während der Entwicklung. Mit einem LAN im Submillisekundenbereich arbeitet es sich deutlich angenehmer als im Kampf mit WLAN.
• Egress ist optional, aber nützlich. Selbst bei einer reinen On-Prem-Installation wollen Sie meist WAN-Egress: für Modell-Updates, Kartendaten, NVIDIA-NGC-Container und Telemetrie an Ihr eigenes Monitoring. Riegeln Sie ihn streng per Firewall ab und exponieren Sie weder Roboter noch Server im Internet.
• Zeitsynchronisierung zählt. Betreiben Sie einen lokalen NTP-Server. Sensorfusion und Bewegungsplanung versagen auf subtile Weise, sobald die Uhren von Roboter, Server und etwaigen Edge-Geräten auseinanderlaufen.

Strom und Kühlung

Ein Kentino AI Server mit 4 GPUs (4× RTX 5090 oder 4× RTX Pro 6000 Blackwell) zieht unter Last dauerhaft 1.8–2.4 kW. Ein Server mit 8 GPUs zieht 3.5–4.5 kW. Das sind keine Desktop-Werte; sie erfordern 16-A-Stromkreise und eine ordentliche Rack-Belüftung.

Für ein Robotiklabor sieht die grobe Kalkulation so aus:

Planen Sie den Raum vor der Installation, nicht danach. Die meisten Labore, die „später GPU-Compute ergänzt“ haben, fliegen im ersten Monat aus den Sicherungen.

Der Luftstrom zählt ebenso viel wie die Wattzahl. Die Kentino AI Server arbeiten mit industriellem Front-to-Back-Rack-Luftstrom und 120-mm-Lüftern und sind ausdrücklich für Dauerlast im 24/7-Betrieb ausgelegt. Sie sind keine Desktop-Tower-Builds und bringen die Klimatechnik eines kleinen Raums an ihre Grenzen. Stellen Sie sie entweder mit eigener Kühlung in einen Technikraum oder in einen separaten Raum und ziehen Sie eine 10-GbE-Strecke.

Software-Stack – was tatsächlich läuft

Hier sitzt die Umsetzung. Das Bild von oben:

Software-Aufteilung: ROS 2 auf dem Roboter kommuniziert über gRPC mit dem Inferenzserver, auf dem vLLM / SGLang läuft.

Ein paar dezidierte Empfehlungen:

• vLLM ist der Standard-Serving-Stack für transformerbasierte VLMs und LLMs. Es ist schneller als naive HuggingFace-Inferenz und unterstützt Continuous Batching und Prefix Caching. SGLang ist eine starke Alternative, wenn Sie strukturierte Ausgaben oder agentenartige Workflows brauchen.
• llama.cpp ist die richtige Wahl, wenn Sie ein kleines Modell (Klasse 7B–13B) auf einer GPU betreiben, mit der vLLM sich schwertut (etwa eine RTX 4090 mit eigenwilliger Tensor-Parallelität) – oder direkt auf dem Roboter.
• NVIDIA Triton ist aufwendiger einzurichten, aber die richtige Entscheidung, wenn Sie verschiedene Modelltypen mischen (LLM + Vision + Sprache) und eine einzige Serving-Schicht darüber legen wollen.
• ROS 2 Humble ist die gemeinsame Sprache. Hersteller-SDKs (Unitree, Booster, EngineAI) liefern ROS-2-Wrapper mit. Bauen Sie Ihre Integration auf der ROS-2-Seite auf, nicht auf dem proprietären Protokoll des Herstellers – es sei denn, Sie haben einen konkreten Grund.

Ein konkretes Beispiel

Stellen Sie sich den einfachsten produktionstauglichen Aufbau vor: ein Humanoid (Unitree G1), ein Inferenzserver (Kentino AI 256 Turin Dual mit 8× RTX 5090), ein Switch, ein Access Point – in einem Labor von 30 m².

Hardware:\n- Unitree G1 (eine Einheit, ~1 kW Ladeleistung)\n- Kentino AI 256 Turin Dual / 8× RTX 5090 (dauerhaft ~4 kW)\n- 10-GbE-Switch (5 Ports, ~30 W)\n- Wi-Fi-6E-AP (~15 W)\n- 32-A-Drehstrom oder 2× 16-A-Wechselstromkreis\n- ~6 kW dedizierte Kühlung (Split-Klimagerät)\n\nSoftware auf dem Server:\n- Ubuntu 22.04, CUDA 13, Docker\n- vLLM mit Qwen2.5-VL 72B in INT4\n- vLLM mit Qwen2.5 32B (nur Text, für die Planung)\n- pgvector für das Szenengedächtnis\n- Isaac Sim für die Policy-Arbeit\n- Prometheus + Grafana\n\nSoftware auf dem Roboter:\n- ROS-2-Treiber von Unitree\n- Eigener ROS-2-Node als Befehls-Router\n- gRPC-Client für die vLLM-Endpunkte\n- Lokales YOLO für schnelle Hinderniserkennung

Das ist eine reale, tragfähige Architektur, die Sie kaufen und in zwei bis drei Wochen in Betrieb nehmen können. Das Gesamtbudget für die Compute-Seite (Server, Netzwerk, Elektrik, Kühlungsaufschlag) liegt je nach Konfiguration bei 60–90 T€. Der Roboter ist eine eigene Position.

Für ein Forschungslabor mit 2–4 Robotern skaliert derselbe Server – vLLM verarbeitet gleichzeitige Anfragen problemlos, und zum Engpass wird entweder der GPU-Speicher (wenn Sie mehr Modelle parallel vorhalten wollen) oder die Anschlussleistung.

Was schiefgeht

Eine ehrliche Liste der Fehlerbilder, die wir gesehen haben, grob nach Häufigkeit sortiert:

• Wi-Fi-Jitter unter Last. Ein bislang unauffälliges Netz wird überlastet, sobald ein neues Gerät dazukommt, die Latenz springt von 5 ms auf 80 ms und das reaktive Verhalten des Roboters leidet. Abhilfe: eigene SSID für die Robotik, ausschließlich 6 GHz, AP in Sichtverbindung.
• Der Modellwechsel legt das System lahm. Sie aktualisieren das VLM, vLLM muss neu laden, die Befehls-Pipeline des Roboters läuft in einen Timeout. Abhilfe: Blue/Green-Serving, zwei Endpunkte, immer nur einen tauschen.
• Thermisches Throttling des Servers. Bei dauerhaftem Training plus Inferenz kommt die Raumklimatisierung nicht hinterher und die GPUs drosseln. Die Inferenzlatenz verdoppelt sich unbemerkt. Abhilfe: Kühlung auf das 1.3-Fache der Dauerlast auslegen, GPU-Temperaturen überwachen, Alarm bei 80 °C.
• Defekte Kabel und Stecker auf der Roboterseite. Roboter vibrieren. Leitungen ermüden. Rechnen Sie bei intensiv genutzten Einheiten mit einem defekten Netzwerk- oder Sensorkabel pro Roboter und Quartal. Halten Sie Ersatz bereit.
• Versionskonflikt zwischen NVIDIA-Treiber und CUDA nach einem apt-get-Upgrade. Das erwischt jeden genau einmal. Pinnen Sie Ihre Treiberversion, arbeiten Sie mit Containern und führen Sie auf einem laufenden Server kein apt-get dist-upgrade aus.
• Uhrendrift zwischen Roboter und Server. Sensor-Zeitstempel driften um mehrere zehn Millisekunden auseinander, die Sensorfusion liefert Unsinn und niemand versteht warum. Abhilfe: lokales NTP, überwachen, Alarm bei einer Drift > 5 ms.

Nichts davon ist katastrophal. Alles davon ist vorhersehbar, sobald man es einmal erlebt hat.

Wann der On-Prem-Weg die falsche Antwort ist

Der Ehrlichkeit halber: Der On-Prem-Inferenzserver ist die falsche Antwort, wenn –

• Ihr Roboter ausschließlich teleoperiert wird und Ihr Bediener ohnehin an einer Cloud-Workstation sitzt. Nutzen Sie einfach die Cloud.
• Sie einen einzelnen Vierbeiner für eine Inspektionsaufgabe im Freien einsetzen und keine Inferenz großer Modelle brauchen; die Rechenleistung an Bord genügt.
• Ihr Modell tatsächlich auf den Jetson Orin AGX passt (50–70 W TDP) und Ihr Latenzbudget den Betrieb an Bord erlaubt. Der Orin fährt ein 7B-Modell in INT4 mit brauchbarer Geschwindigkeit.
• Sie eine einmalige Demo aufsetzen. Die Cloud ist schneller eingerichtet, bei null Last günstiger und lässt sich an einem Nachmittag wieder abbauen.

Der On-Prem-Weg ist richtig, wenn der Betrieb dauerhaft läuft, die Daten sensibel sind, das Latenzbudget knapp ist oder echter Anpassungsbedarf besteht. Ernsthafte Robotikprojekte treffen 2026 fast immer mindestens einen dieser Punkte.

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.