Kjør GR00T-inferens uten lokal GPU

En Raspberry Pi er nok til å drive en SO-100 over en seriell buss og hente rammer fra to USB-kameraer. Det er ikke nok til å kjøre en tre milliarder parameter syn-språk-handlingsmodell: NVIDIAs README angir GR00T N1.7 inferens til én GPU med 16 GB eller mer VRAM. For å se hva din finjusterte GR00T N1.7 sjekkpunkt gjør på armen uten å kjøpe et kort, plasser policyen på en leid sky-GPU, hold robotloopen på maskinen med USB-portene, og send observasjoner og handlingsbiter over nettverket.

Det fungerer, det er ikke gratis, og prisen er ikke jevnt fordelt over oppgavene. Nedenfor: NVIDIAs egen policy-server, lerobots asynkrone stack, regnestykket som på forhånd sier om opplinken din er rask nok, og plattformruten. Alt sjekket mot Isaac-GR00T main branch (N1.7 GA) og lerobot 0.6.1 den 23. august 2026.

Hvorfor policyen ikke vil passe på robotmaskinen

To av de fem policyene AY-Robots kan trene kjører på et arbeidsstasjonskort, tre gjør det ikke. Kolonnen for nedenfor er per handlingstrinn, og det er tallet som konkurrerer med nettverkets rundturtid.

Les dette som en beslutning, ikke trivia. på 20 ms per trinn kjører på robotmaskinen, og du trenger aldri å tenke på det igjen. på 485 ms har brukt en tredjedel av et sekund før en pakke forlater bygningen din. og legger til nøyaktighetssiden.

De to klient-server-stakkene som allerede eksisterer

Isaac-GR00T leverer en ZeroMQ forespørsel-svar-server; lerobot leverer en gRPC-server bygget rundt asynkron inferens. Begge aksepterer et GR00T sjekkpunkt. lerobots støttede policy-liste i async_inference/constants.py er act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 og groot; dens robotliste er so100_follower, so101_follower, bi_so_follower og omx_follower.

Serialiseringsraden betyr mer enn den ser ut til. GR00T's MsgSerializer nekter object-dtype ndarray-nyttelast i begge retninger, fordi msgpack_numpy ellers ville overlevert dem til pickle. lerobot bruker pickle i stedet: policy_server.py kaller pickle.loads på forespørselsdata, robot_client.py pickler observasjonen den sender. Forsvarlig på et betrodd LAN, uforsvarlig når porten er tilgjengelig fra internett.

Rute A: NVIDIAs egen GR00T policy-server

Dette er stien NVIDIA dokumenterer for SO-100 og SO-101 maskinvare, og den du skal bruke hvis sjekkpunktet ditt kom ut av examples/finetune.sh med --embodiment-tag NEW_EMBODIMENT. Trinnene legger til det den oppstrøms README utelater: å få porten til roboten uten å eksponere den for alle andre.

1. 1
   Installer GR00T på den leide GPU-boksen

   Submoduler er påkrevd, og git-lfs må eksistere før klonen, ellers vil parquet-filene i demo_data ankomme som pekere. flash-attn og TensorRT følger med standardinstallasjonen. Fellen på et ferskt pod-image: torchcodec 0.8.0 er den eneste støttede videobackenden og laster kun FFmpeg 4 til 7. Ubuntu 25.10 og 26.04 leveres med FFmpeg 8, så GR00T feiler med Could not load libtorchcodec. Installer en FFmpeg under 8 og legg bibliotekene dens 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
   Autentiser mot den gatede ryggraden

   Hvert GR00T N1.7 sjekkpunkt, inkludert din egen finjustering, laster den gatede nvidia/Cosmos-Reason2-2B ved første bruk. Be om tilgang på modellsiden og logg inn på pod-en, ellers vil lasting feile med en GatedRepoError.

   bash

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

3. 3
   Start policy-serveren

   Pek --model-path til sjekkpunktkatalogen din; på den stien ignorerer serveren --modality-config-path, som kun leses på replay-stien. Utelat --model-path og send --dataset-path pluss --execution-horizon i stedet for en ReplayPolicy som spiller av innspilte handlinger, den billigste måten å bevise at kablingen fungerer.

   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 port 5555 til robotmaskinen

   Bind til loopback, som ovenfor, og overfør porten over SSH eller et WireGuard-lignende nett. Dette gir krypteringen og autentiseringen ZeroMQ-socketen ikke har, for omtrent et 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
   Kjør robotklienten ved siden av servoene

   Klienten trenger sitt eget uv-miljø: den ønsker lerobots robotdrivere, ikke treningsstakken. eval_so100.py importerer so100_follower, so101_follower og koch_follower, så send --robot.type som samsvarer med armen din (den oppstrøms README bruker so101_follower). Kameranøkler må samsvare med treningen: adapteren leser nøyaktig front og wrist, og å bytte dem viser policyen feil visning.

   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"

Rute B: lerobot asynkron inferens

lerobot løser et annet problem. I stedet for å blokkere roboten mens modellen tenker, fortsetter klienten å behandle køen den allerede har mens serveren beregner neste del (chunk). Dette er handlings-chunking tatt videre, den asynkrone stakken introdusert med SmolVLA. Det fungerer også med et GR00T-sjekkpunkt.

# 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

Serveren starter tom: den vet ikke hvilken policy den betjener før klientens første håndtrykk forteller den det, noe som er praktisk på en leid pod. De to innstillingene som avgjør om armen beveger seg jevnt er actions_per_chunk og chunk_size_threshold (lerobot-dokumentasjonen kaller den andre g, etter SmolVLA-artikkelen), og de dokumenterte verdiene og de leverte verdiene stemmer ikke overens.

Aritmetikken som avgjør om koblingen din er rask nok

Folk hopper over dette og bruker deretter en dag på en policy som fryser midt i bevegelsen. Det tar to minutter og er nesten alltid avgjørende.

Den kommenterte observasjons-dicten i NVIDIAs eval_so100.py sier hva som går over nettverket: to arrays med form (480, 640, 3) i uint8, seks ledd-floats, en språkstreng. Det er 921,600 bytes per bilde, 1,843,200 bytes for to kameraer, omtrent 14.7 Mbit, og ingen av stakkene JPEG-komprimerer det. Datapakken som kommer tilbake er noen titalls trinn med 6 floats. Din opplasting bestemmer alt, ikke din nedlasting.

Budsjettet du må holde deg innenfor

GR00T SO-100-klienten er synkron: den kaller policy.get_action(obs), utfører de første action_horizon trinn av blokken med 30 FPS, og kaller deretter igjen. Blokkstørrelse og horisont er forskjellige tall: NVIDIAs distribusjonsguide anbefaler en handlingsblokkstørrelse på 16, minst 32 når kombinert med sanntids-chunking, mens eval_so100.py leverer en utførelseshorisont på 8. Åtte trinn med 30 FPS er 267 ms bevegelse per kall, og alt annet må passe innenfor 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

Å heve horisonten er en grov løsning og ikke en gratis en: armen handler basert på en observasjon som nå er gammel. Den prinsippielle løsningen er sanntids-chunking (RTC), som beregner neste blokk mens den nåværende kjører, fryser handlingene som garantert vil utføres og fyller inn resten; RTC-artikkelen rapporterer den som robust mot inferensforsinkelse uten omskolering. Sjekk hvor det står først. NVIDIA merker RTC som eksperimentell, en lavnivå modellprimitiv som er tilgjengelig via action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), ikke koblet inn i Gr00tPolicy eller server-klient-banen, der options er ubrukt, uten tester og uten eksempel. Over en policy-server får du asynkron utførelse, ikke RTC.

Mål det før du stoler på det

Hvert tall ovenfor er en prediksjon. Fire kommandoer gjør det om til en måling, verdt å kjøre før du forplikter en pod-time til en oppgave som aldri kom til å fungere.

1. 1
   Få den rå rundturen

   Mot pod-en, ikke en CDN. Følg avviket like nøye som gjennomsnittet: jitter får en arm til å hakke, ikke gjennomsnittlig latens.

   bash

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

2. 2
   Mål opplastingen du har, ikke den du betaler for

   Opplasting i boligområder er vanligvis en brøkdel av nedlasting, og det er tallet i båndbreddetabellen ovenfor.

   bash

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

3. 3
   Les klientens egen latenslogg

   LeRobot-robotklienten logger server-til-klient-latens og deserialiseringstid for hver chunk. På rute B trenger du ingen eksterne verktøy.

   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 handlingskøen tømmes

   Send med --debug_visualize_queue_size=True og klienten plotter køstørrelsen under kjøring. Hvis den gjentatte ganger treffer null, er du tom for budsjett: senk fps, øk actions_per_chunk, eller øk chunk_size_threshold slik at observasjoner sendes ut oftere.

   bash

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

Hva fjerninferens faktisk er bra for

Hvis en fjernkjøring hakker på samme punkt i hver episode, er nettverket sannsynligvis ikke årsaken. En policy som nøler ved samme leddvinkel hver gang, er vanligvis et dataproblem; se feilmodussidene, spesielt en policy som bare fungerer i ett oppsett og tapet faller, men policyen gjør ingenting.

Gjøre det selv vs. gjøre det på AY-Robots

Hva en fjerninferensøkt koster

To tall er viktige: timeprisen for kortet, og hvor lenge du lar det kjøre. Det første er publisert; det andre overrasker folk.

Disse prisene ble lest fra Runpods prisside den 23. august 2026, og spotmarkedene er i bevegelse. AY-Robots oppgir en hel kjøring i stedet: 3 til 6 timer til 1.20 til 2.00 USD per time på A100- eller H100-nivået, omtrent 4 til 12 USD for en GR00T- eller Pi0.5-kjøring; 2 til 5 timer til 0.30 til 0.60 USD per time på 24 GB-nivået, 1 til 3 USD for SmolVLA eller ACT. En inferensøkt slår en treningskjøring på kostnad bare hvis du stopper den, noe som er formålet med den inaktive vakthunden. Se faktureringsdokumentasjon og prissiden.

Hvis du heller ikke vil ha nettverket i loopen

Fjerninferens løser et maskinvareproblem og skaper et latensproblem. Noen ganger er det bedre svaret en policy som passer maskinvaren du har.

• ACT, omtrent 80 M parametere og 20 ms per handlingstrinn, 50 episoder minimum, ethvert 24 GB-kort. I et repeterende enkelt-oppsett slår den ofte en ekstern 3 B-modell, fordi den aldri venter på en pakke.
• SmolVLA, omtrent 450 M parametere og 245 ms per handlingstrinn, 30 episoder minimum. Den beholder språkkondisjoneringen som ACT mangler, og lerobot-dokumentene anslår den til omtrent 2 GB ved inferenstid mot omtrent 14 GB for PI0.
• ACT vs GR00T N1.7 for nøyaktighetshalvdelen av avveiningen.

Det finnes også en mellomvei: tren i skyen, evaluer lokalt. Finjustering trenger 80 GB-kortet og bryr seg ikke om latens, så trening av GR00T N1.7 på en SO-100 eksternt er ukontroversielt. Bare evalueringssløyfen har en sanntidsbegrensning; treningsdokumentasjonen og modell- og armmatrisen dekker den halvdelen.

Ofte stilte spørsmål

Kortversjonen

Ekstern inferens for en 3 B policy er et løst ingeniørproblem med et uløst fysikkproblem knyttet til. Ingeniørarbeidet er to kommandoer og en SSH-tunnel. Fysikken er at en 1.8 MB observasjon må nå en GPU i et annet land og komme tilbake før armen går tom for handlinger. Gjør regnestykket før du leier noe, velg en oppgave som tåler en utdatert observasjon, og øk utførelseshorisonten i stedet for å håpe at koblingen forbedres.

Hvis du ikke har spilt inn et datasett ennå, spill inn ditt første datasett og SO-100 oppsettguide kommer først, og LeRobot datasettformat oppføringen forklarer hva opptakeren skriver. Bakgrunn finnes i visjon-språk-handling-modeller og arbeidet med flyt-matching policy; arenaoppføringen lenker hvert benchmark-nummer til en kilde.