LLMs und VLA-Modelle On-Robot 2026: Was passt, was nicht

Der Software-Stack eines Roboters umfasst mindestens fünf verschiedene Aufgaben, und nur zwei davon sind heute plausibles Terrain für ein LLM oder VLA. „KI in der Robotik" als undifferenzierten Block zu behandeln ist der häufigste Framing-Fehler in der Berichterstattung über dieses Feld — er führt zur falschen Frage („Kann es ein LLM ausführen?") statt zur nützlichen Frage („Welche dieser fünf Aufgaben übernimmt das Modell tatsächlich, und mit welcher Rate?").

Die fünf Aufgaben, in der Reihenfolge des Datenflusses: Wahrnehmung (Kamera-/Lidar-/IMU-Daten in eine strukturierte Weltdarstellung umwandeln), Zustandsschätzung (diese Daten über die Zeit zu einer stabilen Schätzung der eigenen Pose des Roboters und des Weltzustands fusionieren), Aufgabenplanung (entscheiden, *was* als Nächstes zu tun ist — „die blaue Tasse greifen", „zur Verladerampe navigieren"), Bewegungsplanung (eine Aufgabe in eine machbare Trajektorie übersetzen — Gelenkwinkel, ein Pfad, ein Greifansatz) und Regelung (die geplante Trajektorie fortlaufend in Motorbefehle umsetzen, während Störungen kompensiert werden).

Wahrnehmung ist der Bereich, in dem VLMs und leichtgewichtige Vision-Modelle bereits echte Arbeit leisten — Objekterkennung, Szenenbeschreibung, semantische Kennzeichnung — meist im Bereich von 5–30 Hz, den ein Kamerabild liefert. Aufgabenplanung ist der Bereich, in dem ein VLA oder LLM echten Mehrwert bietet: ein natürlichsprachliches oder visuelles Ziel in ein symbolisches Teilziel übersetzen, auf das ein nachgelagertes System reagieren kann. Das sind die zwei Aufgaben, die dieser Artikel als legitimes VLA-/LLM-Terrain behandelt.

Zustandsschätzung, Bewegungsplanung und Regelung sind grundlegend anders. Zustandsschätzung läuft typischerweise über ein Kalman- oder Partikelfilter — deterministische, gut verstandene Mathematik, die ein neuronales Netz für das Kernschätzungsproblem nicht verbessert. Bewegungsplanung wird von klassischen Trajektorienoptimierern (CHOMP, RRT*, MPC-basierte Planer) dominiert, gerade weil sie verifizierbare Constraint-Erfüllung bieten — eine Eigenschaft, die die Ausgabe eines Sprachmodells nicht hat. Regelung ist am schnellsten und am wenigsten modellgeeignet von allen: Sie führt eine Feedback-Schleife gegen Sensorfehler mit Raten aus, die ein Transformer-Forward-Pass nicht erreichen kann.

Die begrenzende Größe für das, was ein Roboter mit einem VLA leisten kann, ist die erreichbare Anzahl von Entscheidungen pro Sekunde des Modells — nicht die maximale TOPS-Angabe des Beschleunigers. Ein Hardware-Datenblatt mit 100 TOPS sagt nichts darüber aus, wie oft pro Sekunde ein VLA mit 2–7 Mrd. Parametern einen vollständigen Forward-Pass durchführen und eine nutzbare Aktion erzeugen kann; diese Zahl hängt von Modellgröße, Quantisierung, Batchgröße, Kameraanzahl und Speicherbandbreite zusammen ab und liegt meist weit unter dem, was die TOPS-Zahl für eine Single-Stream-Aufgabe mit niedriger Latenz suggeriert.

Verschiedene Regelschleifen tolerieren stark unterschiedliche Latenz. Eine Balance-Regelschleife bei einem Lauf- oder selbstbalancierenden Roboter braucht Korrekturen im einstelligen Millisekundenbereich — das ist eine 100–1.000-Hz-Regelschleife, und keine veröffentlichte VLA-Architektur läuft mit dieser Rate. Eine Aufgabenplanungsschleife für Manipulation (entscheiden „nach der Tasse greifen" vs. „nach der Schüssel greifen") toleriert 100–1.000 ms Latenz, ohne das Verhalten sichtbar zu verschlechtern — das ist der 1–10-Hz-Bereich, in dem ein VLA realistisch arbeitet. Eine Neuplanungsschleife auf Navigationsebene (Umwegplanung um ein Hindernis) toleriert oft mehrere Sekunden.

Deshalb ist die Ausgaberate des Modells, nicht die zugrunde liegenden Modell-FLOPs, die Zahl, gegen die budgetiert werden sollte. Zwei VLAs mit ähnlicher Parameteranzahl können sehr unterschiedliche erreichbare Hz-Werte haben, je nachdem, wie viel der Pipeline (Vision-Encoder, Action-Decoder, Tokenisierung) auf dem kritischen Pfad pro Entscheidung liegt — und je nachdem, wie viele Kamera-Streams denselben Forward-Pass speisen, da die meisten VLA-Architekturen jede zusätzliche Kamera als zusätzlichen Kontext behandeln, nicht als zusätzliche Parallelität.

Ein Modell in der Regelschleife ist ein Sicherheitsrisiko, nicht nur ein Performance-Problem. Ausgaben neuronaler Netze sind nicht formal verifizierbar, wie es die Stabilitätsmargen eines PID- oder MPC-Reglers sind — es gibt keinen Beweis, dass ein Transformer für eine unbekannte Eingabeverteilung niemals eine unsichere Aktion erzeugt. Das ist der Kerngrund, warum sicherheitsrelevante Stopps, Drehmomentbegrenzungen und Kollisionsvermeidungs-Verriegelungen in jedem uns bekannten produktiven Roboter-Stack in deterministischem Regelungscode bleiben, unabhängig davon, wie leistungsfähig das Reasoning-Modell wird: Eine zertifizierbare Sicherheitsfunktion braucht Verhalten, das erschöpfend charakterisiert werden kann, und das kann ein großes neuronales Netz derzeit nicht garantieren.

Nutzen Sie den folgenden Rechner, um abzuschätzen, welche Entscheidungsrate eine bestimmte Kombination aus Hardware und Kameraanzahl tatsächlich erreichen kann, bevor Sie sich auf ein Modell oder ein Board festlegen. Die Schätzungen sind technische Näherungswerte für die frühe Budgetierung, keine Hersteller-Benchmarks — validieren Sie sie gegen das tatsächliche Modell und die Hardware, bevor Sie ein Design finalisieren.

Fünf VLA-Modelle decken den größten Teil der offenen und halboffenen Landschaft ab, die Robotik-Teams 2026 bewerten, plus ein Modell mit eingeschränktem Zugang, das man im Auge behalten sollte, um zu sehen, wohin sich das Feld entwickelt. Parameterzahlen unten, die mit „~" markiert sind, stammen aus Sekundärquellen statt aus einem primären Herstellerdatenblatt — behandeln Sie sie als Richtwert, nicht als exakt.

NVIDIA Isaac GR00T N1 und die Revision N1.5 sind humanoiden-orientierte VLA-Modelle, offen veröffentlicht, mit etwa ~2,2 Mrd. Parametern (Sekundärquelle). NVIDIA gibt ausdrücklich an, dass GR00T N1.5 auf seinem Jetson-Thor-Board läuft — das ist ein herstellerbestätigtes Onboard-Einsatzziel, kein abgeleitetes.

Physical Intelligences π0 (pi-zero) ist ein Flow-Matching-VLA mit etwa ~3 Mrd. Parametern (Sekundärquelle), mit offenen Gewichten veröffentlicht, aufgebaut auf einem Vision-Language-Backbone der PaliGemma-Klasse (Detail aus Sekundärquelle). Es hat Aufmerksamkeit erregt für flüssige, hochfrequente Aktionsgenerierung im Vergleich zu früheren VLA-Designs.

OpenVLA mit 7 Mrd. Parametern ist die gängige akademische Baseline für VLA-Forschung — offen, gut dokumentiert, breit als Benchmark genutzt. Seine Größe macht es zum Referenzpunkt für „wie groß muss ein leistungsfähiges VLA sein", typischerweise nicht die erste Wahl für ein knappes Onboard-Latenzbudget.

Google DeepMinds Gemini Robotics On-Device hat eine nicht veröffentlichte Parameterzahl und eingeschränkten/Partner-Zugang — es ist für die meisten Teams heute keine Option. Was es dennoch beobachtenswert macht: Google DeepMind gibt an, dass es ausdrücklich entwickelt wurde, um lokal auf dem Roboter ohne Internetverbindung zu laufen. Das ist das klarste Signal eines großen Labors, dass On-Robot-Inferenz jetzt ein erstklassiges Einsatzziel ist, kein Forschungs-Nachgedanke, der auf ein Cloud-first-System aufgesetzt wurde.

SmolVLA ist ein kompaktes, offenes VLA mit etwa ~450 Mio. Parametern (Sekundärquelle) — die realistische Option, wenn die Ziel-Hardware wirklich Low-Power ist (ein kleiner Beschleuniger statt eines vollständigen Jetson-Boards), wo der Speicherbedarf und die Forward-Pass-Latenz eines 2–7-Mrd.-Modells schlicht nicht ins Budget passen.

Octo und RT-2 sind VLA-Architekturen früherer Generationen, hauptsächlich nützlich, um historisch einzuordnen, wie das Feld zu den aktuellen Flow-Matching- und tokenisierten Aktionsdesigns kam — keine aktuelle Empfehlung für eine Einsatzentscheidung 2026.

Über die VLA-Kategorie hinaus gibt NVIDIA an, dass allgemeine Llama-, Qwen- und DeepSeek-Modelle (LLMs) sowie Qwen2.5-VL und Llama 3.2 Vision (VLMs) auf Jetson Thor laufen. Diese übernehmen die Sprachverständnis- und Szenenbeschreibungsebene in einem Roboter-Stack, wo ein vollständiges VLA unnötig ist — ein Serviceroboter, der eine mündliche Frage beantwortet, oder ein Manipulationsarm, der ein Textetikett liest, braucht überhaupt kein Modell mit Aktionsausgabe.

ROS 2 ist die praktische Grenze zwischen der langsamen Reasoning-Ebene und der schnellen Regelungsebene in den meisten produktiven Roboter-Stacks. Ein VLA-Knoten veröffentlicht eine Absicht auf Aufgabenebene — eine Zielpose, ein Teilziel, einen Greifpunkt — als ROS-2-Nachricht, und ein separater, klassischer Regelungsknoten abonniert diese Nachricht und führt sie mit Regelschleifen-Raten aus. Das VLA spricht nie direkt mit den Motoren; es spricht mit einem Topic, und ein deterministischer Knoten besitzt alles, was diesem Topic nachgelagert ist.

Auf NVIDIA-Hardware (Jetson-Orin- und Thor-Klassen) sind TensorRT und TensorRT-LLM der Standard-Laufzeitpfad, um ein quantisiertes VLA oder LLM auf seine erreichbare Inferenzrate zu bringen — sie übernehmen Kernel-Fusion, Präzisionskalibrierung (FP8/INT8/INT4) und hardwarespezifische Optimierung, die eine naive PyTorch-Inferenzschleife ungenutzt lässt. Diesen Schritt zu überspringen ist der häufigste Grund, warum ein Modell, das auf dem Papier eine Ziel-Hz-Rate „erreichen sollte", das in der Praxis nicht tut.

Für kleinere Onboard-Ziele, die nicht auf NVIDIA basieren — ein Hailo-10H-Beschleuniger oder ein kompaktes ARM-basiertes Board — sind ExecuTorch und llama.cpp die relevanten Laufzeitpfade für die Sprach-/Wahrnehmungskomponenten. Keines von beiden ist heute eine Drop-in-VLA-Laufzeit; Teams, die diese kleineren Boards anvisieren, betreiben häufiger ein kompaktes VLM (für Wahrnehmung/Szenenbeschreibung) als ein vollständiges VLA, wobei die Aufgabenplanung entweder auf regelbasierte Logik vereinfacht oder seltener mit einer Kadenz ausgeführt wird, die der kleinere Beschleuniger tragen kann.

Das praktische Integrationsmuster, der Reihe nach: (1) Der VLA-/VLM-Knoten läuft asynchron mit seiner erreichbaren Hz-Rate und veröffentlicht Absichten an ein ROS-2-Topic; (2) ein klassischer Planer abonniert dies und wandelt die Absicht in eine Trajektorie um; (3) ein Regelungsknoten führt die Trajektorie mit 100–1.000 Hz aus, mit eigener Sensor-Feedback-Schleife — ohne je auf die nächste VLA-Ausgabe zu warten, um zu handeln. Stockt oder verzögert sich der VLA-Knoten, führt der Regelungsknoten die letzte gültige Trajektorie fort oder hält sicher die Position; er blockiert nicht auf die langsame Ebene.

Autonome mobile Roboter (AMRs) in Lagerhäusern und landwirtschaftliche Maschinen repräsentieren die tatsächliche Einsatzrealität von Roboterautonomie heute — Humanoide erhalten die mediale Aufmerksamkeit, sind aber die am wenigsten eingesetzte Maschinenklasse in diesem Artikel. Diese Lücke ist relevant für alle, die entscheiden müssen, wo sie Engineering-Zeit investieren: Die rechenintensivste, meistdiskutierte Roboterkategorie ist zugleich die mit den wenigsten Einheiten, die derzeit tatsächlich in Produktionsumgebungen laufen.

Humanoide sind die rechenintensivste, am wenigsten eingesetzte Klasse: Sie tragen die meisten Sensoren, die meisten Freiheitsgrade und entsprechend die schwerste Reasoning-Ebenen-Last (mehrere Kamera-Streams, Ganzkörper-Aufgabenplanung) — genau deshalb sind sie das primäre Ziel für die neueste, leistungsfähigste Onboard-Chiptechnik (Jetson Thor) und die neuesten VLA-Architekturen (GR00T N1.5). Ihr Einsatzvolumen ist heute klein im Verhältnis zur Aufmerksamkeit, die sie erhalten.

Autonome mobile Roboter (AMRs) — die Radroboter, die Inventar in Lagerhäusern bewegen — werden seit Jahren kommerziell in relevantem Maßstab ausgeliefert und betreiben klassische Navigations- und Hindernisvermeidungs-Stacks. Was sich 2026 ändert, ist das Hinzufügen einer Sprach-/Vision-Schnittstellenebene auf einem bereits ausgereiften Autonomie-Stack: ein VLM für Szenenbeschreibung oder eine leichtgewichtige Aufgabenplanungsebene, die einem Menschen erlaubt, eine natürlichsprachliche Anweisung zu geben — kein kompletter Ersatz der zugrunde liegenden Navigationslogik.

Industrieroboterarme in festen Fertigungszellen liegen zwischen diesen Extremen: Bewegungsplanung und Regelung sind typischerweise seit Jahrzehnten vollständig klassisch (ein Schweiß- oder Pick-and-Place-Arm braucht kein VLA, um eine eingelernte Trajektorie zu wiederholen), aber Wahrnehmungsebenen — Fehlererkennung, Teileidentifikation — nutzen zunehmend leichtgewichtige Vision-Modelle, bei denen eine feste Kameraposition und eine begrenzte Aufgabe ein kleineres, zweckdediziertes Modell ohne vollständiges VLA ausreichen lassen.

Landwirtschaftliche Maschinen sind die Einsatzklasse, die in der Berichterstattung über „KI-Robotik" am häufigsten übersehen wird, obwohl sie seit Jahren kommerzielle Autonomie ausliefern — GPS-gestützte Lenkung, Hinderniserkennung bei Traktoren und Erntemaschinen — in großem Maßstab, lange vor der aktuellen VLA-Welle. Was jetzt hinzugefügt wird, folgt demselben Muster wie bei AMRs: eine Sprach-/Vision-Schnittstellenebene (Ernte- oder Unkrauterkennung, natürlichsprachliche Bedienerbefehle) auf Navigations- und Regelungssystemen, die bereits autonom und bereits klassisch waren.

Drei Hardware-Kategorien decken den größten Teil eines On-Robot-Inferenz-Aufbaus ab: ein Jetson-Entwicklungskit für die Reasoning-Ebene, eine oder mehrere Tiefen-/Stereokameras für die Wahrnehmungseingabe und eine Roboter-Entwicklungsplattform, auf der alles montiert wird. Dieser Abschnitt nennt Kategorien, keine konkreten Artikelnummern, Preise oder Herstellerangaben — prüfen Sie aktuelle Spezifikationen und Preise direkt beim jeweiligen Hersteller vor dem Kauf, da sich beides schneller ändert, als ein Artikel es verfolgen kann.

Jetson-Orin- und Jetson-Thor-Entwicklungskits sind der Standardausgangspunkt zur Bewertung eines Onboard-VLA oder -VLM — siehe Edge-AI-Hardware für lokale LLMs für die stufenweise Aufschlüsselung (Orin Nano bis AGX Thor) mit Leistungsklasse und relativer Rechenleistung.

Tiefen- oder Stereokameras sind die Standard-Wahrnehmungseingabe für ein VLA — die meisten veröffentlichten VLA-Forschungsarbeiten und Hersteller-Referenzdesigns setzen RGB-D- oder Stereoeingaben statt reiner monokularer RGB-Eingaben voraus, da Tiefeninformation die Greifpunkt- und Hindernisabstandsschätzung vereinfacht, auf der die Aktionsausgabeebene basiert.

Eine Roboter-Entwicklungsplattform — eine Rad- oder armbasierte Referenzplattform statt eines mechanischen Aufbaus von Grund auf — ist der praktische Ausgangspunkt für ein Team, das eine VLA-Integration validiert, bevor es sich auf kundenspezifische Hardware festlegt.

Vier Arbeitslasten bleiben auch bei einer aggressiv lokal-orientierten Architektur außerhalb des Roboters: Flotten-Lernen, Modell-Updates, roboterübergreifender Kontextaustausch und aufwendige Simulation. Keine davon ist so latenzsensibel wie Wahrnehmung oder Aufgabenplanung, und alle profitieren von Rechenleistung und Daten, auf die ein einzelner Roboter keinen Zugriff hat.

Flotten-Lernen — die Aggregation von Erfahrung über viele eingesetzte Roboter, um eine gemeinsame Policy oder ein gemeinsames Modell zu verbessern — braucht naturgemäß Daten von mehr Einheiten, als ein einzelner Roboter trägt, und die dafür nötige Trainingsleistung liegt weit über dem Budget oder Zweck eines Onboard-Beschleunigers.

Modell-Updates (ein neuer VLA-Checkpoint, ein feinabgestimmtes Wahrnehmungsmodell) werden auf den Roboter gepusht, statt auf ihm trainiert zu werden; der Roboter ist ein Inferenzziel, kein Trainingsknoten, in praktisch jedem heute genutzten produktiven Einsatzmuster.

Roboterübergreifender Kontext — ein Roboter profitiert von dem, was ein anderer Roboter derselben Flotte gerade beobachtet hat — braucht ein gemeinsames Backend, da es keinen nützlichen Onboard-Mechanismus gibt, damit ein Roboter direkt auf die Sensorhistorie eines anderen zugreift.

Aufwendige Simulation — die groß angelegten Physik- und Rendering-Workloads, die zur Erzeugung von Trainingsdaten oder zur Validierung einer Policy vor dem Einsatz verwendet werden — läuft aus demselben Grund auf Rechenzentrums-Rechenleistung wie Flotten-Lernen: Das Rechenbudget hat kein Onboard-Äquivalent.

In der EU wird eine KI-Komponente, die als Sicherheitsbauteil einer Maschine fungiert, unter der EU-KI-Verordnung als hochriskant eingestuft, und die EU-Maschinenverordnung (2023/1230) — anwendbar ab Januar 2027 — verlangt separat eine Konformitätsbewertung für Maschinen mit KI-gesteuerter Sicherheitsfunktion. Ein Roboter mit einem Modell im Pfad einer Sicherheitsfunktion muss möglicherweise beide Regelwerke erfüllen, nicht nur eines.

Hier folgt unsere eigene, begründete Einschätzung, keine veröffentlichte regulatorische Leitlinie: Die in diesem Artikel durchgängig beschriebene Zwei-Ebenen-Architektur — Sicherheitsfunktionen (Not-Aus, Drehmomentbegrenzungen, Kollisionsverriegelungen) in deterministischem, klassischem Regelungscode zu halten und die VLA-/LLM-Reasoning-Ebene auf beratende oder aufgabenbezogene Rollen zu beschränken, die nie direkt eine Sicherheitsfunktion auslösen — reduziert plausibel den Aufwand der Konformitätsbewertung, weil eine zertifizierbare Sicherheitsfunktion Verhalten braucht, das im Voraus erschöpfend charakterisiert werden kann, was deterministischer Code bieten kann und ein großes neuronales Netz derzeit nicht kann. Uns ist nicht bekannt, dass ein Regulierer spezifische Leitlinien veröffentlicht hat, die dieses Framing bestätigen; behandeln Sie es als ein technisch-compliance-bezogenes Argument, das Sie mit Ihrem eigenen Rechtsbeistand prüfen sollten, nicht als Compliance-Garantie.

Dies ist keine Rechtsberatung. Der Umfang der Konformitätsbewertung, anwendbare harmonisierte Normen und die konkrete Einstufung der Sicherheitsfunktionen eines bestimmten Roboters hängen vom tatsächlichen Systemdesign und der Verkaufsjurisdiktion ab — konsultieren Sie qualifizierten Rechts- und Regulierungsbeistand, bevor Sie eine Compliance-Entscheidung für ein konkretes Produkt treffen. Diese Passage ersetzt keine DSGVO- oder Mittelstands-Beratung; sie behandelt ausschließlich Maschinensicherheit und Produktzertifizierung, nicht Datenschutzrecht.