Kör GR00T-slutledning utan en lokal GPU

En Raspberry Pi räcker för att driva en över en seriell buss och hämta bilder från två USB-kameror. Det räcker inte för att köra en tre miljarder parameter : NVIDIAs README anger GR00T N1.7 inferens till en GPU med 16 GB eller mer VRAM. För att se vad din finjusterade checkpoint gör på armen utan att köpa ett kort, placera policyn på en hyrd moln-GPU, behåll robotloopen på maskinen med USB-portarna och skicka observationer och åtgärdsbitar över nätverket.

Det fungerar, det är inte gratis, och priset är inte jämnt fördelat över uppgifter. Nedan: NVIDIAs egen policy-server, lerobots asynkrona stack, aritmetiken som i förväg säger om din upplänk är tillräckligt snabb, och plattformsrutten. Allt kontrollerat mot Isaac-GR00T main branch (N1.7 GA) och lerobot 0.6.1 den 23 augusti 2026.

Varför policyn inte får plats på robotmaskinen

Två av de fem policyer AY-Robots kan träna körs på ett arbetsstationskort, tre gör det inte. Kolumnen för nedan är per åtgärdssteg, och det är det tal som konkurrerar med din nätverksrundtur.

Se det som ett beslut, inte kuriosa. på 20 ms per steg körs på robotmaskinen och du behöver aldrig tänka på det igen. på 485 ms har förbrukat en tredjedels sekund innan ett paket lämnar din byggnad. och lägger till noggrannhetssidan.

De två klient-server-stackarna som redan existerar

Isaac-GR00T levererar en ZeroMQ request-reply-server; lerobot levererar en gRPC-server byggd kring asynkron inferens. Båda accepterar en GR00T checkpoint. lerobots lista över stödda policyer i async_inference/constants.py är act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 och groot; dess robotlista är so100_follower, so101_follower, bi_so_follower och omx_follower.

Serialiseringsraden är viktigare än den ser ut. GR00T:s MsgSerializer vägrar object-dtype ndarray-nyttolaster i båda riktningarna, eftersom msgpack_numpy annars skulle lämna över dem till pickle. lerobot använder pickle istället: policy_server.py anropar pickle.loads på förfrågningsdata, robot_client.py picklar observationen den skickar. Försvarbart på ett betrott LAN, oförsvarbart när porten är nåbar från internet.

Rutt A: NVIDIAs egen GR00T policy-server

Detta är sökvägen NVIDIA dokumenterar för SO-100 och SO-101 hårdvara, och den att använda om din checkpoint kom från examples/finetune.sh med --embodiment-tag NEW_EMBODIMENT. Stegen lägger till det som den ursprungliga README-filen utelämnar: att få porten till roboten utan att exponera den för alla andra.

1. 1
   Installera GR00T på den hyrda GPU-boxen

   Submoduler krävs, och git-lfs måste finnas innan kloningen, annars kommer parquet-filerna i demo_data som pekare. flash-attn och TensorRT ingår i standardinstallationen. Fällan på en ny pod-avbildning: torchcodec 0.8.0 är den enda videobackend som stöds och laddar endast FFmpeg 4 till 7. Ubuntu 25.10 och 26.04 levereras med FFmpeg 8, så GR00T misslyckas med Could not load libtorchcodec. Installera en FFmpeg under version 8 och lägg dess bibliotek på 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
   Autentisera mot den gated backbone

   Varje GR00T N1.7 checkpoint, inklusive din egen finjustering, laddar den gated nvidia/Cosmos-Reason2-2B vid första användningen. Begär åtkomst på modellsidan och logga in på podden, annars misslyckas laddningen med en GatedRepoError.

   bash

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

3. 3
   Starta policy-servern

   Peka --model-path mot din checkpoint-katalog; på den sökvägen ignorerar servern --modality-config-path, som endast läses på replay-sökvägen. Utelämna --model-path och skicka istället --dataset-path plus --execution-horizon för en ReplayPolicy som spelar upp inspelade åtgärder, det billigaste sättet att bevisa att kopplingen fungerar.

   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
   Tunna port 5555 till robotmaskinen

   Bind till loopback, som ovan, och överför porten via SSH eller ett WireGuard-liknande nät. Detta tillhandahåller den kryptering och autentisering som ZeroMQ-socketen inte gör, för ungefär en millisekund.

   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
   Kör robotklienten bredvid servona

   Klienten behöver sin egen uv-miljö: den vill ha lerobots robotdrivrutiner, inte träningsstacken. eval_so100.py importerar so100_follower, so101_follower och koch_follower, så skicka --robot.type som matchar din arm (den ursprungliga README använder so101_follower). Kameranycklar måste matcha träningen: adaptern läser exakt front och wrist, och att byta dem visar policyn fel vy.

   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"

Rutt B: lerobot asynkron inferens

lerobot löser ett annat problem. Istället för att blockera roboten medan modellen tänker, fortsätter klienten att stega igenom kön den redan har medan servern beräknar nästa del. Detta är åtgärdssegmentering vidareutvecklat, den asynkrona stacken som introducerades med SmolVLA. Det fungerar även med en 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

Servern startar tom: den vet inte vilken policy den ska tillhandahålla förrän klientens första handskakning berättar det, vilket är bekvämt på en hyrd pod. De två inställningarna som avgör om armen rör sig smidigt är actions_per_chunk och chunk_size_threshold (lerobot-dokumentationen kallar den andra g, efter SmolVLA-artikeln), och de dokumenterade värdena och de levererade värdena stämmer inte överens.

Aritmetiken som avgör om din länk är tillräckligt snabb

Folk hoppar över detta och lägger sedan en dag på . Det tar två minuter och är nästan alltid avgörande.

Den kommenterade observationsordlistan i NVIDIAs eval_so100.py anger vad som skickas över nätverket: två arrayer med formen (480, 640, 3) i uint8, sex led-flyttal, en språksträng. Det är 921 600 byte per bildruta, 1 843 200 byte för två kameror, cirka 14,7 Mbit, och ingen av stackarna JPEG-komprimerar det. Datablocket som kommer tillbaka är ett par dussin steg med 6 flyttal. Din uppladdning avgör allt, inte din nedladdning.

Budgeten du måste hålla dig inom

GR00T SO-100-klienten är synkron: den anropar policy.get_action(obs), exekverar de första action_horizon steg av chunken med 30 FPS, och anropar sedan igen. Chunkstorlek och horisont är olika siffror: NVIDIAs distributionsguide rekommenderar en action chunk-storlek på 16, minst 32 i kombination med realtidschunking, medan eval_so100.py levererar en exekveringshorisont på 8. Åtta steg vid 30 FPS motsvarar 267 ms rörelse per anrop, och allt annat måste rymmas inom det.

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

Att höja horisonten är en grov lösning och inte gratis: armen agerar utifrån en observation som nu är gammal. Den principiella lösningen är realtidschunking, som beräknar nästa chunk medan den nuvarande körs, fryser de åtgärder som garanterat kommer att exekveras och fyller i resten; RTC-rapporten rapporterar att det är robust mot inferensfördröjning utan omträning. Kontrollera först var det står. NVIDIA markerar RTC som experimentellt, en lågnivåmodell-primitiv som kan nås via action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), inte inkopplad i Gr00tPolicy eller server-klient-vägen, där options är oanvänd, utan tester och utan exempel. Över en policy-server får du asynkron exekvering, inte RTC.

Mät det innan du litar på det

Varje siffra ovan är en förutsägelse. Fyra kommandon förvandlar den till en mätning, värd att köra innan du lägger en pod-timme på en uppgift som aldrig skulle fungera.

1. 1
   Få den råa tur och retur-tiden

   Mot podden, inte en CDN. Följ avvikelsen lika noga som medelvärdet: jitter får en arm att hacka, inte genomsnittlig latens.

   bash

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

2. 2
   Mät upplänken du har, inte den du betalar för

   Bostadsanslutningens uppladdningshastighet är vanligtvis en bråkdel av nedladdningshastigheten, och det är det numret i bandbreddstabellen ovan.

   bash

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

3. 3
   Läs klientens egen latenslogg

   Lerobot-robotklienten loggar server-till-klient-latens och deserialiseringstid för varje chunk. På rutt B behöver du inga externa verktyg.

   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
   Se åtgärdskön tömmas

   Skicka med --debug_visualize_queue_size=True och klienten ritar upp köstorleken vid körning. Om den upprepade gånger når noll har du slut på budget: sänk fps, höj actions_per_chunk, eller höj chunk_size_threshold så att observationer skickas ut oftare.

   bash

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

Vad fjärrinferens faktiskt är bra för

Om en fjärrkörning hackar vid samma punkt i varje episod, är nätverket förmodligen inte orsaken. En policy som tvekar vid samma ledvinkel varje gång är oftast ett dataproblem; se sidorna om fellägen, i synnerhet en policy som bara fungerar i en enda konfiguration och förlusten minskar men policyn gör ingenting.

Att göra det själv kontra att göra det på AY-Robots

Vad en fjärrinferenssession kostar

Två siffror spelar roll: kortets timpris, och hur länge du låter det vara igång. Den första är publicerad; den andra överraskar folk.

Dessa priser lästes från Runpods prissida den 23 augusti 2026, och spotmarknaderna rör sig. AY-Robots anger istället en hel körning: 3 till 6 timmar till 1.20 till 2.00 USD per timme på A100- eller H100-nivån, cirka 4 till 12 USD för en GR00T- eller Pi0.5-körning; 2 till 5 timmar till 0.30 till 0.60 USD per timme på 24 GB-nivån, 1 till 3 USD för SmolVLA eller ACT. En inferenssession slår en träningskörning kostnadsmässigt endast om du stoppar den, vilket är vad den inaktiva vakthunden är till för. Se faktureringsdokumentationen och prissidan.

Om du hellre inte vill ha nätverket i loopen

Fjärrinferens löser ett hårdvaruproblem och skapar ett latensproblem. Ibland är det bättre svaret en policy som passar den hårdvara du har.

• ACT, ungefär 80 M parametrar och 20 ms per åtgärdssteg, minst 50 episoder, valfritt 24 GB-kort. I en repetitiv en-uppgiftskonfiguration överträffar den ofta en fjärrstyrd 3 B-modell, eftersom den aldrig väntar på ett paket.
• SmolVLA, ungefär 450 M parametrar och 245 ms per åtgärdssteg, minst 30 episoder. Den behåller språkkonditioneringen som ACT saknar, och lerobot-dokumentationen anger den till cirka 2 GB vid inferenstid jämfört med ungefär 14 GB för PI0.
• ACT vs GR00T N1.7 för den noggrannhetsmässiga halvan av avvägningen.

Det finns också en medelväg: träna i molnet, utvärdera lokalt. Finjustering behöver 80 GB-kortet och bryr sig inte om latens, så att träna GR00T N1.7 på en SO-100 på distans är okontroversiellt. Endast utvärderingsloopen har en realtidsbegränsning; träningsdokumentationen och modell- och armmatrisen täcker den halvan.

Vanliga frågor

Kortversionen

Fjärrinferens för en 3 B policy är ett löst ingenjörsproblem med ett olöst fysikproblem kopplat till sig. Ingenjörsarbetet består av två kommandon och en SSH-tunnel. Fysiken är att en 1.8 MB observation måste nå en GPU i ett annat land och komma tillbaka innan armen får slut på åtgärder. Gör beräkningarna innan du hyr något, välj en uppgift som tolererar en föråldrad observation, och höj exekveringshorisonten snarare än att hoppas att länken förbättras.

Om du inte har spelat in en datamängd än, spela in din första datamängd och SO-100 installationsguide kommer först, och LeRobot datamängdsformat förklarar vad inspelaren skriver. Bakgrunden finns i syn-språk-handlingsmodeller och arbetet med flödesmatchande policyer; arena-posten länkar varje benchmark-nummer till en källa.