GR00T-Inferenz ohne lokale GPU ausführen

Ein Raspberry Pi reicht aus, um einen über einen seriellen Bus anzusteuern und Frames von zwei USB-Kameras abzurufen. Es reicht jedoch nicht aus, ein drei Milliarden Parameter umfassendes : NVIDIAs README gibt an, dass die GR00T N1.7 Inferenz eine GPU mit 16 GB oder mehr VRAM erfordert. Um zu sehen, was Ihr feinabgestimmter Checkpoint am Arm leistet, ohne eine Karte zu kaufen, legen Sie die Policy auf eine gemietete Cloud-GPU, lassen Sie die Roboterschleife auf dem Rechner mit den USB-Ports laufen und senden Sie Beobachtungen und Aktions-Chunks über das Netzwerk.

Es funktioniert, ist nicht kostenlos, und der Preis verteilt sich nicht gleichmäßig auf alle Aufgaben. Unten: NVIDIAs eigener Policy-Server, lerobots asynchroner Stack, die Arithmetik, die im Voraus angibt, ob Ihr Uplink schnell genug ist, und der Plattformweg. Alles überprüft mit dem Isaac-GR00T Main Branch (N1.7 GA) und lerobot 0.6.1 am 23. August 2026.

Warum die Policy nicht auf den Roboterrechner passt

Zwei der fünf Richtlinien, die AY-Robots trainieren kann, laufen auf einer Workstation-Karte, drei nicht. Die Spalte unten ist pro Aktionsschritt, und das ist die Zahl, die mit Ihrer Netzwerk-Roundtrip-Zeit konkurriert.

Betrachten Sie dies als Entscheidung, nicht als Nebensächlichkeit. mit 20 ms pro Schritt läuft auf der Robotermaschine, und Sie müssen nie wieder darüber nachdenken. mit 485 ms hat ein Drittel einer Sekunde verbraucht, bevor ein Paket Ihr Gebäude verlässt. Der und fügen die Genauigkeitsseite hinzu.

Die beiden bereits existierenden Client-Server-Stacks

Isaac-GR00T liefert einen ZeroMQ Request-Reply-Server; lerobot liefert einen gRPC-Server, der um asynchrone Inferenz herum aufgebaut ist. Beide akzeptieren einen GR00T Checkpoint. Die unterstützte Policy-Liste von lerobot in async_inference/constants.py ist act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 und groot; seine Roboterliste ist so100_follower, so101_follower, bi_so_follower und omx_follower.

Die Serialisierungszeile ist wichtiger, als es den Anschein hat. GR00Ts MsgSerializer lehnt object-dtype ndarray-Payloads in beide Richtungen ab, da msgpack_numpy sie sonst an pickle übergeben würde. lerobot verwendet stattdessen pickle: policy_server.py ruft pickle.loads auf Anfragedaten auf, robot_client.py pickelt die gesendete Beobachtung. Vertretbar in einem vertrauenswürdigen LAN, unvertretbar, sobald der Port aus dem Internet erreichbar ist.

Route A: NVIDIAs eigener GR00T Policy-Server

Dies ist der von NVIDIA dokumentierte Pfad für SO-100- und SO-101-Hardware und derjenige, der zu verwenden ist, wenn Ihr Checkpoint aus examples/finetune.sh mit --embodiment-tag NEW_EMBODIMENT stammt. Die Schritte ergänzen, was die ursprüngliche README weglässt: den Port zum Roboter zu bringen, ohne ihn für alle anderen freizugeben.

1. 1
   GR00T auf der gemieteten GPU-Box installieren

   Submodule sind erforderlich, und git-lfs muss vor dem Klonen vorhanden sein, sonst kommen die Parquet-Dateien in demo_data als Pointer an. flash-attn und TensorRT sind in der Standardinstallation enthalten. Die Falle bei einem frischen Pod-Image: torchcodec 0.8.0 ist das einzige unterstützte Video-Backend und lädt nur FFmpeg 4 bis 7. Ubuntu 25.10 und 26.04 liefern FFmpeg 8, daher schlägt GR00T mit Could not load libtorchcodec fehl. Installieren Sie ein FFmpeg unter Version 8 und legen Sie dessen Bibliotheken auf LD_LIBRARY_PATH ab.

   bash

   sudo apt install git-lfs && git lfs install
   curl -LsSf https://astral.sh/uv/install.sh | sh
   sudo apt-get update && sudo apt-get install -y ffmpeg
   
   git clone --recurse-submodules https://github.com/NVIDIA/Isaac-GR00T
   cd Isaac-GR00T
   uv sync --python 3.12
   uv run python -c "import gr00t; print('GR00T installed successfully')"

2. 2
   Authentifizierung gegenüber dem geschützten Backbone

   Jeder GR00T N1.7 Checkpoint, einschließlich Ihrer eigenen Feinabstimmung, lädt beim ersten Gebrauch das geschützte nvidia/Cosmos-Reason2-2B. Fordern Sie Zugriff auf der Modellseite an und melden Sie sich auf dem Pod an, sonst schlägt das Laden mit einem GatedRepoError fehl.

   bash

   uv run huggingface-cli login
   # or:  export HF_TOKEN=<your_token>

3. 3
   Den Policy-Server starten

   Verweisen Sie --model-path auf Ihr Checkpoint-Verzeichnis; auf diesem Pfad ignoriert der Server --modality-config-path, das nur auf dem Replay-Pfad gelesen wird. Lassen Sie --model-path weg und übergeben Sie stattdessen --dataset-path plus --execution-horizon für eine ReplayPolicy, die aufgezeichnete Aktionen wiedergibt – die günstigste Methode, um die Funktionsweise der Verkabelung zu überprüfen.

   bash

   uv run python gr00t/eval/run_gr00t_server.py \
     --model-path /workspace/so100_finetune/checkpoint-10000 \
     --embodiment-tag NEW_EMBODIMENT \
     --device cuda:0 \
     --host 127.0.0.1 --port 5555

4. 4
   Port 5555 zur Robotermaschine tunneln

   Binden Sie wie oben an Loopback und leiten Sie den Port über SSH oder ein WireGuard-ähnliches Mesh weiter. Dies bietet die Verschlüsselung und Authentifizierung, die der ZeroMQ-Socket nicht bietet, für etwa eine Millisekunde.

   bash

   # on the robot machine
   ssh -N -L 5555:127.0.0.1:5555 root@<pod-host> -p <pod-ssh-port>
   
   # sanity check that something answers
   nc -vz 127.0.0.1 5555

5. 5
   Den Roboter-Client neben den Servos ausführen

   Der Client benötigt eine eigene uv-Umgebung: Er benötigt die Robotertreiber von lerobot, nicht den Trainings-Stack. eval_so100.py importiert so100_follower, so101_follower und koch_follower, übergeben Sie also den --robot.type, der Ihrem Arm entspricht (die ursprüngliche README verwendet so101_follower). Kameraschlüssel müssen mit dem Training übereinstimmen: Der Adapter liest genau front und wrist, und ein Vertauschen zeigt der Policy die falsche Ansicht.

   bash

   cd gr00t/eval/real_robot/SO100
   uv sync
   uv pip install --no-deps -e ../../../../
   
   uv run --no-sync python eval_so100.py \
     --robot.type=so100_follower \
     --robot.port=/dev/ttyACM0 \
     --robot.id=orange_follower \
     --robot.cameras="{ front: {type: opencv, index_or_path: 6, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 2, width: 640, height: 480, fps: 30}}" \
     --policy_host=127.0.0.1 \
     --policy_port=5555 \
     --lang_instruction="pick up the red block and put it in the bin"

Route B: lerobot asynchrone Inferenz

lerobot löst ein anderes Problem. Anstatt den Roboter zu blockieren, während das Modell nachdenkt, durchläuft der Client die bereits vorhandene Warteschlange weiter, während der Server den nächsten Chunk berechnet. Dies ist Aktions-Chunking, weiterentwickelt, der asynchrone Stack, der mit SmolVLA eingeführt wurde. Es funktioniert auch mit einem GR00T-Checkpoint.

# GPU machine
pip install -e ".[async]"
python -m lerobot.async_inference.policy_server \
     --host=127.0.0.1 \
     --port=8080

# robot machine, after tunnelling 8080
python -m lerobot.async_inference.robot_client \
    --server_address=127.0.0.1:8080 \
    --robot.type=so100_follower \
    --robot.port=/dev/ttyACM0 \
    --robot.id=follower_so100 \
    --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 1, width: 640, height: 480, fps: 30}}" \
    --task="pick up the red block and put it in the bin" \
    --policy_type=groot \
    --pretrained_name_or_path=<user>/my_groot_finetune \
    --policy_device=cuda \
    --actions_per_chunk=50 \
    --chunk_size_threshold=0.5 \
    --debug_visualize_queue_size=True

Der Server startet leer: Er weiß nicht, welche Richtlinie er bedient, bis der erste Handshake des Clients es ihm mitteilt, was auf einem gemieteten Pod praktisch ist. Die beiden Stellschrauben, die entscheiden, ob der Arm sich reibungslos bewegt, sind actions_per_chunk und chunk_size_threshold (die lerobot-Dokumentation nennt den zweiten g, nach dem SmolVLA-Paper), und die dokumentierten Werte stimmen nicht mit den ausgelieferten Werten überein.

Die Arithmetik, die entscheidet, ob Ihre Verbindung schnell genug ist

Leute überspringen dies und verbringen dann einen Tag mit . Es dauert zwei Minuten und ist fast immer entscheidend.

Das kommentierte Beobachtungs-Dict in NVIDIAs eval_so100.py besagt, was über die Leitung geht: zwei Arrays der Form (480, 640, 3) in uint8, sechs Gelenk-Floats, ein Sprach-String. Das sind 921.600 Bytes pro Frame, 1.843.200 Bytes für zwei Kameras, etwa 14,7 Mbit, und keiner der Stacks JPEG-komprimiert es. Der zurückkommende Datenblock besteht aus einigen Dutzend Schritten von 6 Floats. Ihr Upload entscheidet alles, nicht Ihr Download.

Das Budget, in das Sie passen müssen

Der GR00T SO-100 Client ist synchron: er ruft policy.get_action(obs), führt die ersten action_horizon Schritte des Chunks mit 30 FPS aus und ruft dann erneut auf. Chunk-Größe und Horizont sind unterschiedliche Zahlen: NVIDIAs Bereitstellungshandbuch empfiehlt eine Action-Chunk-Größe von 16, mindestens 32 in Kombination mit Echtzeit-Chunking, während eval_so100.py einen Ausführungshorizont von 8 liefert. Acht Schritte bei 30 FPS entsprechen 267 ms Bewegung pro Aufruf, und alles andere muss darin Platz finden.

observation upload   14.7 Mbit / 100 Mbit/s   = 147 ms
network round trip                            =  30 ms
model inference (AY-Robots figure, N1.7)      = 152 ms
action chunk return + deserialize             =  ~2 ms
                                                -------
total per call                                  331 ms

budget at action_horizon = 8   ->  267 ms   FAIL, arm pauses ~64 ms per chunk
budget at action_horizon = 16  ->  533 ms   fits, with headroom
budget at action_horizon = 32  -> 1067 ms   fits, observations now ~1 s stale

Den Horizont zu erhöhen ist die grobe Lösung und keine kostenlose: Der Arm agiert auf einer Beobachtung, die nun veraltet ist. Die prinzipielle Lösung ist Echtzeit-Chunking, das den nächsten Chunk berechnet, während der aktuelle läuft, die garantiert auszuführenden Aktionen einfriert und den Rest ergänzt; das RTC-Paper berichtet, dass es robust gegenüber Inferenzverzögerungen ist, ohne erneutes Training. Prüfen Sie zuerst, wie der Stand der Dinge ist. NVIDIA kennzeichnet RTC als experimentell, ein Low-Level-Modellprimitiv, das über action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), nicht in Gr00tPolicy oder den Server-Client-Pfad integriert, wo options ungenutzt ist, ohne Tests und ohne Beispiel. Über einen Policy-Server erhalten Sie asynchrone Ausführung, nicht RTC.

Messen Sie es, bevor Sie ihm vertrauen

Jede der oben genannten Zahlen ist eine Vorhersage. Vier Befehle verwandeln sie in eine Messung, die es wert ist, ausgeführt zu werden, bevor man eine Pod-Stunde für eine Aufgabe aufwendet, die ohnehin nie funktioniert hätte.

1. 1
   Den rohen Roundtrip erhalten

   Gegen den Pod, nicht gegen ein CDN. Beobachten Sie die Abweichung so genau wie den Mittelwert: Jitter lässt einen Arm stottern, nicht die durchschnittliche Latenz.

   bash

   ping -c 50 <pod-host>
   # the mdev column is the number that predicts stutter

2. 2
   Messen Sie den Uplink, den Sie haben, nicht den, für den Sie bezahlen

   Der Upload im Privatbereich ist in der Regel ein Bruchteil des Downloads, und es ist die Zahl in der obigen Bandbreitentabelle.

   bash

   # on the pod
   iperf3 -s
   
   # on the robot machine, -R omitted so this measures upload
   iperf3 -c <pod-host> -t 30

3. 3
   Das eigene Latenzprotokoll des Clients lesen

   Der LeRobot-Roboterclient protokolliert die Server-zu-Client-Latenz und die Deserialisierungszeit für jeden Chunk. Auf Route B benötigen Sie keine externen Tools.

   text

   Received action chunk for step #240 | Latest action: #232 |
     Incoming actions: 240:289 |
     Network latency (server->client): 187.44ms |
     Deserialization time: 3.10ms

4. 4
   Beobachten, wie die Aktionswarteschlange abläuft

   Übergeben Sie --debug_visualize_queue_size=True, und der Client zeichnet die Warteschlangengröße zur Laufzeit auf. Wenn sie wiederholt Null erreicht, ist Ihr Budget erschöpft: Reduzieren Sie die fps, erhöhen Sie actions_per_chunk oder erhöhen Sie chunk_size_threshold, damit Beobachtungen häufiger gesendet werden.

   bash

   python -m lerobot.async_inference.robot_client \
       ... \
       --debug_visualize_queue_size=True

Wofür Remote-Inferenz tatsächlich gut ist

Wenn ein Remote-Lauf in jeder Episode an derselben Stelle stottert, ist das Netzwerk wahrscheinlich nicht die Ursache. Eine Policy, die jedes Mal am selben Gelenkwinkel zögert, ist normalerweise ein Datenproblem; siehe die Fehlermodus-Seiten, insbesondere eine Policy, die nur in einem Setup funktioniert und Verlust sinkt, aber die Policy tut nichts.

Es selbst tun vs. es auf AY-Robots tun

Was eine Remote-Inferenzsitzung kostet

Zwei Zahlen sind entscheidend: der Stundensatz der Karte und wie lange Sie sie laufen lassen. Die erste ist veröffentlicht; die zweite überrascht die Leute.

Diese Preise wurden am 23. August 2026 von der Runpod-Preisseite entnommen, und Spotmärkte sind volatil. AY-Robots gibt stattdessen einen gesamten Lauf an: 3 bis 6 Stunden zu 1,20 bis 2,00 USD pro Stunde auf der A100- oder H100-Stufe, etwa 4 bis 12 USD für einen GR00T- oder Pi0.5-Lauf; 2 bis 5 Stunden zu 0,30 bis 0,60 USD pro Stunde auf der 24 GB-Stufe, 1 bis 3 USD für SmolVLA oder ACT. Eine Inferenzsitzung ist nur dann kostengünstiger als ein Trainingslauf, wenn Sie sie stoppen, wofür der Leerlauf-Watchdog da ist. Siehe die Abrechnungsdokumentation und die Preisseite.

Wenn Sie das Netzwerk lieber nicht in der Schleife haben möchten

Remote-Inferenz löst ein Hardwareproblem und erzeugt ein Latenzproblem. Manchmal ist die bessere Antwort eine Policy, die zu der vorhandenen Hardware passt.

• ACT, ungefähr 80 M Parameter und 20 ms pro Aktionsschritt, mindestens 50 Episoden, jede 24-GB-Karte. In einem repetitiven Einzelaufgaben-Setup übertrifft es häufig ein entferntes 3-B-Modell, da es nie auf ein Paket warten muss.
• SmolVLA, ungefähr 450 M Parameter und 245 ms pro Aktionsschritt, mindestens 30 Episoden. Es behält die Sprachkonditionierung bei, die ACT fehlt, und die lerobot-Dokumentation gibt an, dass es zur Inferenzzeit etwa 2 GB gegenüber ungefähr 14 GB für PI0 benötigt.
• ACT vs GR00T N1.7 für die Genauigkeitshälfte des Kompromisses.

Es gibt auch einen Mittelweg: in der Cloud trainieren, lokal evaluieren. Fine-Tuning benötigt die 80-GB-Karte und kümmert sich nicht um Latenz, daher ist das Training von GR00T N1.7 auf einem SO-100 remote unumstritten. Nur die Evaluationsschleife hat eine Echtzeitbeschränkung; die Trainingsdokumentation und die Modell- und Arm-Matrix decken diese Hälfte ab.

Häufig gestellte Fragen

Die Kurzversion

Remote-Inferenz für eine 3 B Policy ist ein gelöstes Ingenieurproblem mit einem ungelösten Physikproblem. Die Ingenieurarbeit besteht aus zwei Befehlen und einem SSH-Tunnel. Die Physik besagt, dass eine 1.8 MB große Beobachtung eine GPU in einem anderen Land erreichen und zurückkommen muss, bevor dem Arm die Aktionen ausgehen. Machen Sie die Rechnung, bevor Sie etwas mieten, wählen Sie eine Aufgabe, die eine veraltete Beobachtung toleriert, und erhöhen Sie den Ausführungshorizont, anstatt zu hoffen, dass die Verbindung besser wird.

Wenn Sie noch keinen Datensatz aufgezeichnet haben, zeichnen Sie Ihren ersten Datensatz auf und der SO-100 Einrichtungsleitfaden stehen an erster Stelle, und der Eintrag zum LeRobot Datensatzformat erklärt, was der Recorder schreibt. Hintergrundinformationen finden Sie in den Vision-Sprach-Aktionsmodellen und der Arbeit zu Flow-Matching-Policies; der Arena-Eintrag verlinkt jede Benchmark-Zahl zu einer Quelle.