Unitree G1: Inferenz auf dem Gerät oder in der Cloud?

Ihr Vision-Modell liefert Ergebnisse, aber der Roboter reagiert nur, solange die Netzwerkverbindung stabil bleibt?

Schnellste Entscheidung: Lassen Sie sicherheitsrelevante Bewegungsregelung und andere zeitkritische Reaktionen auf dem Roboter laufen. Prüfen Sie Cloud-Inferenz für Aufgaben, die Verzögerungen verkraften, zentral verwaltet werden sollen oder mehr Rechenressourcen benötigen. Diese Woche sollten Sie für eine konkrete Aufgabe beide Varianten messen, bevor Sie die Architektur festlegen.

Dieser Leitfaden richtet sich an Algorithmusentwickler, die Vision, Planung oder Aktionsmodelle verteilen müssen.
Laborverantwortliche finden Kriterien, um Versuchsaufbau und Rechenaufwand abzuwägen.
Systemintegrationsteams erhalten Prüfpunkte für einen sicheren Betrieb bei Verbindungsproblemen.

Aufgabenzeit und Regelkreis

Die Entscheidung für Cloud-Inferenz beim Unitree G1 sollte von der Aufgabe ausgehen, nicht allein vom Robotermodell. „Läuft auf dem Roboter“ und „darf über ein Netzwerk laufen“ sind keine Eigenschaften eines Modells an sich. Sie ergeben sich daraus, was die Funktion steuert, welche Verzögerung tolerierbar ist und was bei einer fehlenden Antwort geschehen muss.

Ordnen Sie Ihre Arbeit zunächst drei Bereichen zu:

• Bewegung und Schutzreaktionen: Funktionen, bei denen eine verzögerte oder fehlende Antwort ein Risiko erzeugen könnte. Planen Sie diese so, dass sie lokal reagieren und einen definierten sicheren Zustand erreichen können. Ob ein bestimmter Pfad dafür zur Verfügung steht, müssen Sie anhand der offiziellen Entwicklungsunterlagen und Ihres konkreten Aufbaus überprüfen.
• Übergeordnete Wahrnehmung und Planung: Ein Modell kann Szenen interpretieren, Ziele vorschlagen oder eine längere Aufgabe strukturieren. Wenn das Ergebnis nicht unmittelbar einen Regelkreis schließt, lässt sich eine Cloud-Ausführung eher untersuchen. Der Roboter muss dennoch wissen, was bei einer ausbleibenden oder verspäteten Antwort zu tun ist.
• Auswertung ohne unmittelbare Steuerwirkung: Datenanalyse, Versuchsprotokolle oder die nachträgliche Auswertung von Aufnahmen können häufig außerhalb des Roboters stattfinden. Hier zählen eher Datenschutz, Speicherort, Kosten und der Aufwand für den Datentransfer als die unmittelbare Reaktionszeit.

Diese Trennung ist eine Architektur-Empfehlung, keine Zusage zur Kompatibilität einer G1-Konfiguration. Die offizielle Produktseite des Unitree G1 beschreibt das Produkt. Sie belegt nicht, dass eine bestimmte Cloud-Anbindung, ein bestimmtes Modell oder eine bestimmte Steuerschnittstelle unterstützt wird. Dafür müssen Sie die offiziellen Entwicklungs- und Schnittstellenunterlagen für Ihre konkrete Ausführung prüfen.

Antwortzeit und Netzstabilität

Ein Modell kann lokal schnell rechnen und trotzdem zu spät am Aktor ankommen. Umgekehrt sagt eine kurze Antwortzeit bei einer stabilen Verbindung wenig darüber aus, wie sich der Aufbau bei Schwankungen verhält. Bewerten Sie daher nicht nur die Modellinferenz, sondern die ganze Kette:

• Aufnahme und Bereitstellung der Sensordaten,
• Vorverarbeitung und Inferenz,
• Übertragung zur Cloud und zurück,
• Prüfung und Übergabe des Ergebnisses,
• Umsetzung der Anweisung durch die lokale Steuerung.

Die Antwort auf die Frage, ob ein Vision-Modell in der Cloud zusätzliche Verzögerung verursacht, ist daher nicht eine universelle Zahl. Sie hängt vom Sensorformat, den zu übertragenden Daten, dem Modell, dem Rechenort, der Netzwerkstrecke und der Verarbeitung am Roboter ab. Messen Sie die End-to-End-Zeit in Ihrem Versuch. Erfassen Sie außerdem Schwankungen und Ausreißer: Ein brauchbarer Mittelwert macht eine unvorhersehbare Antwortzeit nicht für einen sicherheitskritischen Regelkreis geeignet.

Für ROS-2-basierte Datenwege sollten Sie die Qualitätsmerkmale der Übertragung nicht als nebensächliche Konfiguration behandeln. Die ROS-2-Dokumentation zu Quality of Service erläutert unter anderem Zuverlässigkeit, Deadline und Lebensdauer von Nachrichten. Diese Einstellungen helfen dabei, festzulegen, wie Nachrichten behandelt werden. Sie ersetzen jedoch weder die Messung Ihres Netzes noch eine sichere lokale Ausfallreaktion.

Prüfen Sie die Cloud-Variante unter den Bedingungen, die im späteren Betrieb tatsächlich vorkommen können. Dazu gehören schwankende Verbindung, Paketverlust und vollständige Unterbrechung. Testen Sie nicht nur, ob sich die Verbindung nach einer Unterbrechung wiederherstellt. Beobachten Sie auch, ob veraltete Ergebnisse verworfen werden, ob Befehle doppelt ausgeführt werden können und ob der Roboter bei fehlenden Daten in einem vorher festgelegten Zustand bleibt.

Legen Sie vor dem Versuch fest, welche Zeitgrenzen Ihre Anwendung akzeptiert. Diese Grenzen müssen aus dem konkreten Bewegungsablauf und der Gefährdungsbewertung Ihres Teams stammen, nicht aus einer allgemeinen Empfehlung. Trennen Sie außerdem die Verzögerung, die Ihre Anwendung tatsächlich beeinflusst, von nebensächlichen Zeiten: Eine lange Auswertung nach Abschluss einer Aufgabe ist anders zu bewerten als eine verspätete Antwort, die einen laufenden Ablauf unterbrechen soll. Notieren Sie, welcher Schritt die Antwort blockiert, und ob die lokale Steuerung währenddessen weiter sicher arbeiten kann.

Rechenbedarf und Änderungsaufwand

Inferenz am Gerät begrenzt den Datentransfer und hält Aufgaben näher an Sensoren und Steuerung. Gleichzeitig stehen nur die tatsächlich verfügbare Rechenleistung, der Arbeitsspeicher und die unterstützte Softwareumgebung Ihrer konkreten Konfiguration zur Verfügung. Ein Modell, das auf einem Entwicklungsrechner läuft, ist deshalb nicht automatisch auf dem Roboter lauffähig. Auch ein erfolgreicher Start sagt noch nichts über die Laufzeit im Zusammenspiel mit Sensoren und Steuerung aus.

Cloud-Verarbeitung kann sinnvoll sein, wenn Sie Berechnungen zentral bündeln oder ein Modell für mehrere Entwicklungsaufgaben bereitstellen wollen. Modellwechsel und zentrale Wartung können dadurch organisatorisch einfacher werden. Dafür entstehen zusätzliche Abhängigkeiten: Daten müssen übertragen werden, der Netzwerkpfad muss erreichbar sein und Zugriffsrechte sowie Protokollierung benötigen einen festen Betrieb. Ein kurzfristiger Test kann außerdem andere Voraussetzungen haben als ein dauerhaft genutzter Dienst.

Vergleichen Sie deshalb nicht abstrakt „Edge gegen Cloud“, sondern zwei getestete Konfigurationen. Verwenden Sie dasselbe Modell, denselben Datensatz und dieselbe Aufgabe. Halten Sie Modellversion, Framework, Vorverarbeitung und Hardware fest. Ein Benchmark auf einem allgemeinen Beschleuniger ist kein G1-Benchmark; eine Messung an einer abweichenden Konfiguration beweist keine Leistung Ihres Roboters.

Ein Ergebnis ist erst dann übertragbar, wenn Sie die Unterschiede benennen können: Welche Sensoren waren aktiv? Welche Daten wurden übertragen? Welche Verarbeitung lief lokal? Welche Netzwerkbedingungen galten? Dokumentieren Sie diese Punkte im Versuch. Prüfen Sie bei Änderungen der G1-Hardware, der offiziellen Software oder der verwendeten Schnittstellen erneut, ob Ihre Annahmen noch stimmen.

Berücksichtigen Sie neben der reinen Modelllaufzeit auch den Betriebsaufwand. Bei lokaler Ausführung muss Ihr Team Softwarestände, Abhängigkeiten und Modellaktualisierungen auf dem Zielsystem kontrollieren. Bei einer Cloud-Variante kommen Verwaltung des Zugangs, Überwachung der Verbindung und Fehleranalyse über mehrere Systeme hinzu. Fragen Sie deshalb nicht nur, wo das Modell am schnellsten läuft, sondern auch, welche Variante Sie unter den Bedingungen Ihres Labors reproduzierbar betreiben und bei Bedarf zurücksetzen können.

Datenschutz und Ausfallschutz

Klären Sie vor der ersten Cloud-Übertragung, welche Daten Ihren Standort verlassen. Kamerabilder können Personen, Laborbereiche oder nicht veröffentlichte Versuchsaufbauten zeigen. Statusdaten und Aufgabenbeschreibungen können ebenfalls sensible Informationen enthalten, auch wenn kein vollständiges Bild übertragen wird. Legen Sie fest, ob Sie Rohdaten, zugeschnittene Ausschnitte, Merkmale oder nur ein abgeleitetes Ergebnis übermitteln müssen.

Für einen kontrollierten Datenfluss gehören mindestens diese Fragen in die Planung:

• Wer darf Modelle, Roboter und Cloud-Endpunkte konfigurieren?
• Werden Daten auf dem Übertragungsweg geschützt, und wie werden Zugangsdaten verwaltet?
• Welche Eingaben und Ergebnisse landen in Protokollen?
• Wer kann auf diese Protokolle zugreifen, und wie lange müssen sie aufbewahrt werden?
• Welche lokale Funktion bleibt verfügbar, wenn Verbindung oder Cloud-Dienst ausfallen?

Wenn personenbezogene Daten verarbeitet werden, beziehen Sie die Datenschutzanforderungen Ihres Einsatzortes und Ihrer Organisation ein. Halten Sie außerdem Datenminimierung und Zugriffsbeschränkung im Versuchsplan fest. Die NIST-Veröffentlichung zur Risikobewertung kann als zusätzliche Referenz für die strukturierte Betrachtung von Risiken dienen; sie ersetzt weder die rechtliche Prüfung noch Ihre konkrete Sicherheitsanalyse.

Für geschützte Verbindungen ist eine aktuelle, sorgfältig konfigurierte TLS-Umsetzung relevant. Die Empfehlungen in RFC 9325 behandeln die sichere Verwendung von TLS und DTLS. Verschlüsselung allein löst jedoch keine Fragen zu Berechtigungen, Protokollzugriff, Aufbewahrung oder sicherem Verhalten bei einem Verbindungsabbruch. Planen Sie diese Punkte zusammen, statt Schutz auf den Transportkanal zu reduzieren.

Ein sicherer Ausfallpfad braucht eine klare Zuständigkeit. Wenn der Cloud-Dienst keine Antwort liefert, darf nicht offenbleiben, ob der Roboter weiterfährt, auf das letzte Ergebnis vertraut oder anhält. Bestimmen Sie, welche Komponente den Zustand bewertet, wie lange ein Ergebnis gültig bleibt und wie ein kontrollierter Neustart erfolgt. Prüfen Sie diese Regeln mit absichtlich unterbrochener Verbindung, statt nur einen störungsfreien Ablauf zu beobachten.

Bedingte Auswahl für Ihre Architektur

Nutzen Sie die folgenden Bedingungen als Entscheidungshilfe für die KI-Bereitstellung in der Robotik. Gehen Sie die Punkte für jede einzelne Modellfunktion durch. Wenn mehrere Bedingungen zutreffen, wählen Sie nicht automatisch nur eine Seite. Eine geteilte Architektur kann besser zu Ihrer Aufgabe passen.

• [ ] Wenn eine Funktion ohne Netzantwort sicher reagieren muss, wählen Sie lokale Ausführung oder einen lokalen sicheren Ersatz. Das betrifft vor allem Funktionen, die Bewegung unmittelbar beeinflussen oder einen sicheren Zustand herstellen müssen.
• [ ] Wenn eine Aufgabe eine Netzwerkunterbrechung übersteht und zentral verwaltet werden soll, prüfen Sie Cloud-Ausführung. Legen Sie vorher fest, welche lokale Reaktion greift, wenn das Ergebnis ausbleibt oder zu spät eintrifft.
• [ ] Wenn große Datenmengen für Analyse oder Modellpflege anfallen, prüfen Sie zuerst, ob sich die Verarbeitung vom aktiven Steuerungspfad trennen lässt. Nicht jede Auswertung muss während der Bewegung stattfinden.
• [ ] Wenn Datenschutz oder Richtlinien eine Übertragung ausschließen, bleibt die Verarbeitung lokal. Verkleinerte oder abgeleitete Daten sind nur dann eine Alternative, wenn das für Ihren Versuch tatsächlich genügt.
• [ ] Wenn weder Cloud-Ausfall noch begrenzte lokale Ressourcen tolerierbar sind, testen Sie einen zweigleisigen Entwurf. Die lokale Seite sichert den Betrieb; die Cloud übernimmt nur Aufgaben, deren Ergebnis rechtzeitig und vollständig verfügbar sein kann.
• [ ] Wenn Sie eine Schnittstelle oder Softwarekomponente nicht anhand offizieller Unterlagen verifizieren können, geben Sie keine Kompatibilität als gegeben aus. Verschieben Sie die Architekturentscheidung bis zu einem kontrollierten Funktionstest.

Damit beantworten Sie auch die Frage, ob der Unitree G1 grundsätzlich Cloud-Inferenz nutzen kann: Eine solche Anbindung kann für passende Aufgaben geprüft werden. Ob sie in Ihrer Konfiguration funktioniert und für Ihren Anwendungsfall geeignet ist, hängt von den verfügbaren Schnittstellen, Ihrer Software und Messungen ab. Die Produktbezeichnung allein ist kein Kompatibilitätsnachweis.

Verwenden Sie die Liste nicht als pauschale Freigabe. Ein Häkchen bei Cloud-Verwaltung bedeutet beispielsweise nicht, dass auch eine bewegungsnahe Funktion über denselben Pfad laufen sollte. Ordnen Sie jedes Modell und jedes Ergebnis einer konkreten Rolle zu. Wenn die Messung, die Sicherheitsprüfung und die Betriebsanforderungen zu unterschiedlichen Ergebnissen führen, trennen Sie die Funktionen, statt einen Kompromiss für die gesamte Anwendung zu erzwingen.

Testablauf für die Entscheidung

Führen Sie den Vergleich als begrenzten Versuch durch, bevor Sie einen produktiven Ablauf davon abhängig machen.

1. Wählen Sie eine konkrete Aufgabe. Beschreiben Sie Eingabe, gewünschtes Ergebnis und die Handlung, die daraus folgt. Trennen Sie eine unverbindliche Empfehlung von einer Anweisung, die Bewegung beeinflusst.
2. Definieren Sie die Abnahmekriterien. Legen Sie vor dem Test fest, welche Antwortzeit, Erfolgsrate, Ausfallreaktion und Wartbarkeit für diese Aufgabe akzeptabel sind. Verwenden Sie Werte aus den Anforderungen Ihres Teams, nicht aus einem fremden Benchmark.
3. Prüfen Sie die technische Grundlage. Dokumentieren Sie G1-Ausführung, Softwarestand, Schnittstellen, Modellversion und Framework. Gleichen Sie die Annahmen mit den offiziellen Entwicklungsunterlagen ab.
4. Vergleichen Sie beide Ausführungsorte. Führen Sie dieselbe Aufgabe mit derselben Eingabe lokal und über den vorgesehenen Cloud-Pfad aus. Halten Sie Vorverarbeitung, Rückübertragung und Umsetzung getrennt fest, damit eine Verzögerung nicht fälschlich allein dem Modell zugeschrieben wird.
5. Simulieren Sie schlechte Verbindung und Abbruch. Prüfen Sie, wie sich Zeitüberschreitungen, verspätete Ergebnisse und fehlende Antworten auswirken. Verifizieren Sie, dass ein lokaler Schutzmechanismus nicht auf die Cloud warten muss.
6. Bewerten Sie Daten und Betriebskosten. Erfassen Sie Übertragungsbedarf, Speicher- und Protokollierungsanforderungen, Zugriffsverwaltung sowie den Aufwand für Modellwechsel und Fehleranalyse. Berücksichtigen Sie auch die Pflege der lokalen Laufzeitumgebung.
7. Dokumentieren Sie eine Rückfalloption. Halten Sie fest, wie Sie zum letzten sicheren Zustand oder zur bewährten lokalen Variante zurückkehren. Ändern Sie produktive Abläufe erst, wenn das Team die Prüfergebnisse nachvollziehen kann.

Ein aussagekräftiger Versuch braucht mehr als einen erfolgreichen Durchlauf. Protokollieren Sie Antwortzeiten über den gesamten Pfad, Aufgabenerfolg, Verhalten bei Netzstörungen und den Aufwand für die Betreuung. Wiederholen Sie den Vergleich, wenn sich Modell, Datenaufbereitung oder Netzwerkbedingungen ändern. So entsteht keine vermeintlich allgemeingültige Leistungszahl, sondern ein belastbarer Befund für genau Ihren Aufbau.

Halten Sie in Ihrem Versuchsprotokoll auch fest, was nicht getestet wurde. Wenn Sie beispielsweise keine vollständige Trennung simuliert oder keine zweite Modellversion geprüft haben, sollte das Ergebnis nicht als allgemeine Freigabe für den späteren Betrieb gelten. Eine kurze Begründung für die gewählte Variante hilft außerdem, wenn Teammitglieder den Aufbau später warten oder an eine geänderte Aufgabe anpassen müssen.

Fragen aus der Praxis

Kann der Unitree G1 KI-Inferenz aus einer Cloud beziehen?

Grundsätzlich lässt sich eine Cloud-Anbindung für geeignete Aufgaben prüfen. Daraus folgt jedoch keine bestätigte Kompatibilität einer bestimmten G1-Konfiguration oder Schnittstelle. Klären Sie zuerst anhand der offiziellen Entwicklungsunterlagen, welche Daten- und Steuerpfade verfügbar sind. Testen Sie anschließend Übertragung, Rückmeldung und Ausfallverhalten mit Ihrem Modell. Echtzeitnahe Bewegungs- und Sicherheitsfunktionen sollten lokal abgesichert bleiben.

Welche Steuerungsaufgaben sollten auf dem Roboter bleiben?

Auf dem Roboter sollten Aufgaben bleiben, deren Ausführung nicht auf eine Netzwerkantwort warten darf: insbesondere sicherheitsbezogene Reaktionen und Regelkreise für Bewegung. Die konkrete Grenze hängt von der Steuerungsarchitektur und den verfügbaren Schnittstellen ab. Trennen Sie dabei die unmittelbare Reaktion von übergeordneten Zielen: Eine Cloud darf beispielsweise einen Vorschlag liefern, aber nicht der einzige Ort sein, an dem ein sicherer Zustand hergestellt wird.

Was muss bei einem Netzausfall mit Cloud-Inferenz passieren?

Legen Sie vor dem Versuch fest, welche lokale Funktion bei Verzögerung, Paketverlust oder vollständiger Trennung übernimmt. Die sichere Reaktion darf nicht davon abhängen, dass die Cloud noch eine letzte Nachricht sendet. Je nach Aufgabe bedeutet das, einen Vorgang anzuhalten, in einen definierten sicheren Zustand zu wechseln oder eine lokal verfügbare Ersatzfunktion zu nutzen. Prüfen Sie jede Variante kontrolliert und protokollieren Sie den Übergang.

Wie wirkt sich eine Cloud auf die Verzögerung eines Robotik-Vision-Modells aus?

Eine einzelne feste Verzögerungszahl wäre ohne Messung Ihrer gesamten Verarbeitungskette nicht belastbar. Zur Übertragungszeit kommen Sensoraufnahme, Vorverarbeitung, Inferenz, Rückweg und Umsetzung am Roboter hinzu; außerdem können Netzschwankungen die Antwortzeit verändern. Messen Sie deshalb die End-to-End-Zeit im tatsächlichen Versuchsaufbau und vergleichen Sie lokale Ausführung und Cloud-Anbindung unter denselben Bedingungen.

Der nächste Entwicklungsschritt

Wenn Ihr Team derzeit alles auf einer lokalen Entwicklungsmaschine bündelt, können belegte Rechenressourcen, Wartungsaufwand und eine schwer reproduzierbare Umgebung den Testbetrieb erschweren. Eine ungeprüfte Cloud-Steuerung schafft dagegen neue Abhängigkeiten von Netz, Datenübertragung und Zugriffsverwaltung. Für die unmittelbare Regelung bleibt der Roboter maßgeblich; ein zusätzlicher Entwicklungsrechner ersetzt weder G1-Schnittstellen noch lokale Sicherheitsfunktionen.

Wenn Sie für Modellpflege, Auswertung oder Entwicklungswerkzeuge vorübergehend eine separate Umgebung benötigen, kann ein gemieteter Mac von Hashvps eine Alternative zu einem dauerhaft gebundenen lokalen Rechner sein. Prüfen Sie vorab, ob Betriebssystem, Framework und benötigte Werkzeuge zu Ihrem Ablauf passen; daraus folgt keine Eignung als Laufzeitumgebung für den Unitree G1 oder für Echtzeitsteuerung. Informationen zur Nutzung und zu den Rahmenbedingungen finden Sie im Hilfezentrum von Hashvps; die verfügbaren Umgebungsoptionen können Sie in den Paketdetails von Hashvps prüfen. Entscheiden Sie erst nach dem Aufgaben- und Schnittstellentest, ob eine solche Umgebung Ihren Entwicklungsprozess tatsächlich vereinfacht.