Voer GR00T Inferentie Uit Zonder Lokale GPU

Een Raspberry Pi is voldoende om een aan te sturen via een seriële bus en frames van twee USB-camera's te halen. Het is niet voldoende om een drie miljard parameter : NVIDIA's README vermeldt GR00T N1.7 inferentie op één GPU met 16 GB of meer VRAM. Om te zien wat uw fijn afgestelde checkpoint doet op de arm zonder een kaart te kopen, plaatst u het beleid op een gehuurde cloud-GPU, houdt u de robotlus op de machine met de USB-poorten en stuurt u observaties en actiefragmenten over het netwerk.

Het werkt, het is niet gratis, en de prijs is niet gelijkmatig verdeeld over taken. Hieronder: NVIDIA's eigen beleidsserver, lerobot's asynchrone stack, de rekenkunde die vooraf aangeeft of uw uplink snel genoeg is, en de platformroute. Dit alles gecontroleerd tegen de Isaac-GR00T main branch (N1.7 GA) en lerobot 0.6.1 op 23 augustus 2026.

Waarom het beleid niet op de robotmachine past

Twee van de vijf beleidsregels die AY-Robots kan trainen, draaien op een werkstationkaart, drie niet. De kolom hieronder is per actiestap, en dat is het getal dat concurreert met uw netwerkroundtrip.

Lees dit als een beslissing, niet als trivia. met 20 ms per stap draait op de robotmachine en daar hoef je nooit meer over na te denken. met 485 ms heeft een derde van een seconde besteed voordat een pakket uw gebouw verlaat. De en voegen de nauwkeurigheidskant toe.

De twee reeds bestaande client-server stacks

Isaac-GR00T levert een ZeroMQ request-reply server; lerobot levert een gRPC server gebouwd rond asynchrone inferentie. Beide accepteren een GR00T checkpoint. lerobot's ondersteunde beleidslijst in async_inference/constants.py is act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 en groot; de robotlijst is so100_follower, so101_follower, bi_so_follower en omx_follower.

De serialisatierij is belangrijker dan het lijkt. GR00T's MsgSerializer weigert object-dtype ndarray payloads in beide richtingen, omdat msgpack_numpy ze anders aan pickle zou overhandigen. lerobot gebruikt in plaats daarvan pickle: policy_server.py roept pickle.loads aan opgevraagde data, robot_client.py serialiseert de observatie die het verstuurt. Verdedigbaar op een vertrouwd LAN, onverdedigbaar zodra de poort bereikbaar is vanaf het internet.

Route A: NVIDIA's eigen GR00T beleidsserver

Dit is het pad dat NVIDIA documenteert voor SO-100 en SO-101 hardware, en degene die je moet gebruiken als je checkpoint afkomstig is van examples/finetune.sh met --embodiment-tag NEW_EMBODIMENT. De stappen voegen toe wat de upstream README weglaat: de poort naar de robot krijgen zonder deze aan iedereen anders bloot te stellen.

1. 1
   Installeer GR00T op de gehuurde GPU-box

   Submodules zijn vereist, en git-lfs moet bestaan vóór de kloon, anders komen de parquet-bestanden in demo_data aan als pointers. flash-attn en TensorRT worden geleverd met de standaardinstallatie. De valkuil op een verse pod-image: torchcodec 0.8.0 is de enige ondersteunde video-backend en laadt alleen FFmpeg 4 tot 7. Ubuntu 25.10 en 26.04 leveren FFmpeg 8, dus GR00T faalt met Could not load libtorchcodec. Installeer een FFmpeg onder versie 8 en plaats de bibliotheken ervan op LD_LIBRARY_PATH.

   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
   Authenticeer tegen de gated backbone

   Elk GR00T N1.7 checkpoint, inclusief je eigen fine-tune, laadt de gated nvidia/Cosmos-Reason2-2B bij het eerste gebruik. Vraag toegang aan op de modelpagina en log in op de pod, anders mislukt het laden met een GatedRepoError.

   bash

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

3. 3
   Start de beleidsserver

   Wijs --model-path naar je checkpoint-directory; op dat pad negeert de server --modality-config-path, die alleen wordt gelezen op het replay-pad. Laat --model-path weg en geef in plaats daarvan --dataset-path plus --execution-horizon door voor een ReplayPolicy die opgenomen acties afspeelt, de goedkoopste manier om te bewijzen dat de bedrading werkt.

   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
   Tunnel poort 5555 naar de robotmachine

   Bind aan loopback, zoals hierboven, en transporteer de poort via SSH of een WireGuard-achtig mesh-netwerk. Dit voorziet in de encryptie en authenticatie die de ZeroMQ-socket niet biedt, voor ongeveer een milliseconde.

   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
   Draai de robotclient naast de servo's

   De client heeft zijn eigen uv-omgeving nodig: het wil de robotdrivers van lerobot, niet de trainingsstack. eval_so100.py importeert so100_follower, so101_follower en koch_follower, dus geef de --robot.type door die overeenkomt met je arm (de upstream README gebruikt so101_follower). Cameratoetsen moeten overeenkomen met de training: de adapter leest precies front en wrist, en het verwisselen ervan toont het beleid de verkeerde weergave.

   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 inferentie

lerobot lost een ander probleem op. In plaats van de robot te blokkeren terwijl het model nadenkt, blijft de client de wachtrij doorlopen die het al heeft terwijl de server het volgende brokje berekent. Dit is actie-chunking, verder uitgewerkt, de asynchrone stack geïntroduceerd met SmolVLA. Het werkt ook met een 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

De server start leeg: hij weet niet welk beleid hij dient totdat de eerste handshake van de client dit vertelt, wat handig is op een gehuurde pod. De twee knoppen die bepalen of de arm soepel beweegt zijn actions_per_chunk en chunk_size_threshold (de lerobot-documentatie noemt de tweede g, naar het SmolVLA-artikel), en de gedocumenteerde waarden en de geleverde waarden komen niet overeen.

De rekenkunde die bepaalt of uw verbinding snel genoeg is

Mensen slaan dit over en besteden dan een dag aan . Het duurt twee minuten en is bijna altijd doorslaggevend.

Het becommentarieerde observatiedict in NVIDIA's eval_so100.py zegt wat er over de lijn gaat: twee arrays met vorm (480, 640, 3) in uint8, zes joint floats, een taalstring. Dat is 921.600 bytes per frame, 1.843.200 bytes voor twee camera's, ongeveer 14,7 Mbit, en geen van beide stacks comprimeert het met JPEG. Het terugkomende stuk is een paar dozijn stappen van 6 floats. Uw upload bepaalt alles, niet uw download.

Het budget waarbinnen u moet blijven

De GR00T SO-100 client is synchroon: deze roept policy.get_action(obs) aan, voert de eerste action_horizon stappen van de chunk uit met 30 FPS, en roept dan opnieuw aan. Chunkgrootte en horizon zijn verschillende getallen: NVIDIA's implementatiegids beveelt een actie-chunkgrootte van 16 aan, minstens 32 in combinatie met real-time chunking, terwijl eval_so100.py een uitvoeringshorizon van 8 levert. Acht stappen bij 30 FPS is 267 ms beweging per aanroep, en al het andere moet daarbinnen passen.

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

Het verhogen van de horizon is de botte oplossing en niet zonder kosten: de arm reageert op een observatie die nu oud is. De principiële oplossing is real-time chunking, dat de volgende chunk berekent terwijl de huidige loopt, de gegarandeerd uit te voeren acties bevriest en de rest aanvult; het RTC-paper rapporteert het als robuust tegen inferentievertraging zonder hertraining. Controleer eerst de status daarvan. NVIDIA markeert RTC als experimenteel, een low-level modelprimitief dat bereikbaar is via action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), niet gekoppeld aan Gr00tPolicy of het server-clientpad, waar options ongebruikt is, zonder tests en zonder voorbeeld. Via een beleidsserver krijg je asynchrone uitvoering, geen RTC.

Meet het voordat je het vertrouwt

Elk getal hierboven is een voorspelling. Vier commando's veranderen het in een meting, die de moeite waard is om uit te voeren voordat je een pod-uur toewijst aan een taak die nooit zou werken.

1. 1
   Haal de ruwe round trip op

   Tegen de pod, niet een CDN. Let net zo goed op de afwijking als op het gemiddelde: jitter zorgt ervoor dat een arm stottert, niet de gemiddelde latentie.

   bash

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

2. 2
   Meet de uplink die je hebt, niet degene waarvoor je betaalt

   Residentiële upload is meestal een fractie van de download, en het is het getal in de bandbreedtetabel hierboven.

   bash

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

3. 3
   Lees het eigen latentielogboek van de client

   De lerobot robotclient logt server-naar-client latentie en deserialisatietijd voor elke chunk. Op route B heb je geen externe tooling nodig.

   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
   Bekijk hoe de actiewachtrij leegloopt

   Geef --debug_visualize_queue_size=True mee en de client plot de wachtrijgrootte tijdens runtime. Als deze herhaaldelijk nul bereikt, zit je buiten je budget: verlaag de fps, verhoog actions_per_chunk, of verhoog chunk_size_threshold zodat observaties vaker worden verzonden.

   bash

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

Waar remote inference eigenlijk goed voor is

Als een externe uitvoering hapert op hetzelfde punt in elke episode, is het netwerk waarschijnlijk niet de oorzaak. Een beleid dat elke keer aarzelt bij dezelfde gewrichtshoek is meestal een dataprobbleem; zie de pagina's met storingsmodi, in het bijzonder een beleid dat alleen werkt in één opstelling en verlies daalt maar het beleid doet niets.

Zelf doen versus het doen op AY-Robots

Wat een inferentiesessie op afstand kost

Twee getallen zijn van belang: het uurtarief van de kaart en hoe lang je deze laat draaien. Het eerste is gepubliceerd; het tweede verrast mensen.

Deze tarieven zijn gelezen van Runpod's prijspagina op 23 augustus 2026, en spotmarkten bewegen. AY-Robots citeert in plaats daarvan een hele run: 3 tot 6 uur à 1.20 tot 2.00 USD per uur op de A100- of H100-tier, ongeveer 4 tot 12 USD voor een GR00T- of Pi0.5-run; 2 tot 5 uur à 0.30 tot 0.60 USD per uur op de 24 GB-tier, 1 tot 3 USD voor SmolVLA of ACT. Een inferentiesessie is alleen voordeliger dan een trainingsrun als je deze stopt, waarvoor de idle watchdog dient. Zie de documentatie over facturering en de prijspagina.

Als je het netwerk liever niet in de lus hebt

Inferentie op afstand lost een hardwareprobleem op en creëert een latentieprobleem. Soms is het betere antwoord een beleid dat past bij de hardware die je hebt.

• ACT, ongeveer 80 M parameters en 20 ms per actiestap, minimaal 50 episodes, elke 24 GB kaart. In een repetitieve opstelling met één taak verslaat het vaak een 3 B model op afstand, omdat het nooit op een pakket wacht.
• SmolVLA, ongeveer 450 M parameters en 245 ms per actiestap, minimaal 30 episodes. Het behoudt de taalconditionering die ACT mist, en de lerobot documentatie schat het op ongeveer 2 GB tijdens inferentie, tegenover ongeveer 14 GB voor PI0.
• ACT vs GR00T N1.7 voor de nauwkeurigheidshelft van de afweging.

Er is ook een middenweg: trainen in de cloud, lokaal evalueren. Fijnafstemming heeft de 80 GB kaart nodig en geeft niet om latentie, dus GR00T N1.7 trainen op een SO-100 op afstand is onomstreden. Alleen de evaluatielus heeft een real-time beperking; de trainingsdocumentatie en de model- en armmatrix behandelen die helft.

Veelgestelde vragen

De korte versie

Inferentie op afstand voor een 3 B beleid is een opgelost engineeringprobleem met een onopgelost natuurkundig probleem eraan vast. De engineering bestaat uit twee commando's en een SSH-tunnel. De natuurkunde is dat een 1.8 MB waarneming een GPU in een ander land moet bereiken en terug moet komen voordat de arm geen acties meer heeft. Doe de berekeningen voordat u iets huurt, kies een taak die een verouderde waarneming tolereert, en verhoog de uitvoeringshorizon in plaats van te hopen dat de verbinding verbetert.

Als je nog geen dataset hebt opgenomen, neem je eerste dataset op en de SO-100 installatiegids komen eerst, en de LeRobot datasetformaat vermelding legt uit wat de recorder schrijft. Achtergrondinformatie is te vinden in visie-taal-actiemodellen en het flow-matching beleidswerk; de arena vermelding linkt elk benchmarknummer aan een bron.