Kør GR00T Inferens Uden en Lokal GPU

En Raspberry Pi er nok til at drive en over en seriel bus og trække billeder fra to USB-kameraer. Den er ikke nok til at køre en tre milliarder parameter : NVIDIAs README angiver GR00T N1.7 inferens til én GPU med 16 GB eller mere VRAM. For at se, hvad dit finjusterede checkpoint gør på armen uden at købe et kort, skal du placere politikken på en lejet cloud-GPU, holde robotløkken på maskinen med USB-portene og sende observationer og handlingssegmenter over netværket.

Det virker, det er ikke gratis, og prisen er ikke jævnt fordelt på tværs af opgaver. Nedenfor: NVIDIAs egen politikserver, lerobots asynkrone stak, den aritmetik, der på forhånd fortæller, om din uplink er hurtig nok, og platformruten. Alt sammen kontrolleret mod Isaac-GR00T main-grenen (N1.7 GA) og lerobot 0.6.1 den 23. august 2026.

Hvorfor politikken ikke passer på robotmaskinen

To af de fem politikker AY-Robots kan træne, kører på et arbejdsstationskort, tre gør ikke. Kolonnen nedenfor er pr. handlingstrin, og det er det tal, der konkurrerer med din netværks-roundtrip.

Læs det som en beslutning, ikke som trivia. på 20 ms pr. trin kører på robotmaskinen, og du tænker aldrig over det igen. på 485 ms har brugt en tredjedel af et sekund, før en pakke forlader din bygning. Sammenligningen af og tilføjer nøjagtighedsaspektet.

De to klient-server-stakke, der allerede eksisterer

Isaac-GR00T leverer en ZeroMQ request-reply server; lerobot leverer en gRPC server bygget omkring asynkron inferens. Begge accepterer et GR00T checkpoint. lerobots understøttede politikliste 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.

Serialiseringsrækken betyder mere, end den ser ud til. GR00T's MsgSerializer afviser object-dtype ndarray-nyttelast i begge retninger, fordi msgpack_numpy ellers ville give dem videre til pickle. lerobot bruger pickle i stedet: policy_server.py kalder pickle.loads på anmodningsdata, robot_client.py bruger pickle til den observation, den sender. Forsvarligt på et betroet LAN, uforsvarligt når porten er tilgængelig fra internettet.

Rute A: NVIDIAs egen GR00T policy-server

Dette er den sti, NVIDIA dokumenterer for SO-100 og SO-101 hardware, og den du skal bruge, hvis dit checkpoint kom fra examples/finetune.sh med --embodiment-tag NEW_EMBODIMENT. Trinene tilføjer, hvad den oprindelige README udelader: at få porten til robotten uden at eksponere den for alle andre.

1. 1
   Installer GR00T på den lejede GPU-boks

   Submoduler er påkrævet, og git-lfs skal eksistere før kloningen, ellers ankommer parquet-filerne i demo_data som pointere. flash-attn og TensorRT følger med standardinstallationen. Fælden på et nyt pod-image: torchcodec 0.8.0 er den eneste understøttede video-backend og indlæser kun FFmpeg 4 til 7. Ubuntu 25.10 og 26.04 leveres med FFmpeg 8, så GR00T fejler med Could not load libtorchcodec. Installer en FFmpeg under 8 og placer dens biblioteker 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
   Autentificer mod den gatede backbone

   Hvert GR00T N1.7 checkpoint, inklusive din egen finjustering, indlæser den gatede nvidia/Cosmos-Reason2-2B ved første brug. Anmod om adgang på modelsiden og log ind på pod'en, ellers mislykkes indlæsningen med en GatedRepoError.

   bash

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

3. 3
   Start policy-serveren

   Peg --model-path mod din checkpoint-mappe; på den sti ignorerer serveren --modality-config-path, som kun læses på replay-stien. Udelad --model-path og send i stedet --dataset-path plus --execution-horizon for en ReplayPolicy, der afspiller optagede handlinger, den billigste måde at bevise, at forbindelsen virker.

   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 via SSH eller et WireGuard-lignende mesh. Det leverer den kryptering og autentificering, som ZeroMQ-socket'en ikke gør, for omkring 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
   Kør robotklienten ved siden af servoerne

   Klienten har brug for sit eget uv-miljø: den ønsker lerobots robotdrivere, ikke træningsstakken. eval_so100.py importerer so100_follower, so101_follower og koch_follower, så send --robot.type, der matcher din arm (den oprindelige README bruger so101_follower). Kameranøgler skal matche træningen: adapteren læser præcis front og wrist, og at bytte dem viser policy'en den forkerte 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 andet problem. I stedet for at blokere robotten, mens modellen tænker, fortsætter klienten med at behandle den kø, den allerede har, mens serveren beregner den næste del. Dette er handlings-chunking taget videre, den asynkrone stak introduceret med SmolVLA. Det virker også med et 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

Serveren starter tom: den ved ikke, hvilken politik den skal betjene, før klientens første handshake fortæller den det, hvilket er praktisk på en lejet pod. De to parametre, der afgør, om armen bevæger sig jævnt, er actions_per_chunk og chunk_size_threshold (lerobot-dokumentationen kalder den anden g, efter SmolVLA-papiret), og de dokumenterede værdier og de leverede værdier stemmer ikke overens.

Aritmetikken der afgør, om din forbindelse er hurtig nok

Folk springer dette over og bruger derefter en dag på . Det tager to minutter, og det er næsten altid afgørende.

Den kommenterede observation dict i NVIDIAs eval_so100.py siger, hvad der sendes over netværket: to arrays med form (480, 640, 3) i uint8, seks joint floats, en sprogstreng. Det er 921.600 bytes per frame, 1.843.200 bytes for to kameraer, omkring 14.7 Mbit, og ingen af stakkene JPEG-komprimerer det. Den klump, der kommer tilbage, er et par dusin trin med 6 floats. Din upload bestemmer alt, ikke din download.

Det budget, du skal holde dig inden for

GR00T SO-100-klienten er synkron: den kalder policy.get_action(obs), udfører de første action_horizon trin af chunken ved 30 FPS, og kalder derefter igen. Chunk-størrelse og horisont er forskellige tal: NVIDIAs implementeringsguide anbefaler en action chunk-størrelse på 16, mindst 32 når kombineret med real-time chunking, mens eval_so100.py leverer en udførelseshorisont på 8. Otte trin ved 30 FPS er 267 ms bevægelse per kald, og alt andet skal passe ind i 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

At hæve horisonten er den grove løsning og ikke en gratis en: armen handler ud fra en observation, der nu er gammel. Den principielle løsning er real-time chunking, som beregner den næste chunk, mens den nuværende kører, fryser de handlinger, der garanteres udført, og udfylder resten; RTC-artiklen rapporterer det som robust over for inferensforsinkelse uden genoptræning. Tjek først, hvor det står. NVIDIA markerer RTC som eksperimentel, en lavniveau modelprimitiv, der kan nås via action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), ikke forbundet til Gr00tPolicy eller server-klient-stien, hvor options er ubrugt, uden tests og uden eksempel. Over en policy-server får du asynkron udførelse, ikke RTC.

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

Hvert tal ovenfor er en forudsigelse. Fire kommandoer forvandler det til en måling, som er værd at køre, før man afsætter en pod-time til en opgave, der aldrig ville have fungeret.

1. 1
   Få den rå returtid

   Mod pod'en, ikke en CDN. Hold øje med afvigelsen lige så tæt som gennemsnittet: jitter får en arm til at hakke, ikke gennemsnitlig latenstid.

   bash

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

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

   Upload i boliger er normalt en brøkdel af download, 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
   Læs klientens egen latenstid-log

   LeRobot-robotklienten logger server-til-klient latenstid og deserialiseringstid for hver chunk. På rute B behøver du ingen eksterne værktøjer.

   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
   Overvåg handlingkøen tømmes

   Send --debug_visualize_queue_size=True, og klienten plotter køstørrelsen under kørsel. Hvis den gentagne gange rammer nul, er du løbet tør for budget: sænk fps, øg actions_per_chunk, eller øg chunk_size_threshold, så observationer sendes ud oftere.

   bash

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

Hvad fjerninferens faktisk er godt for

Hvis en fjernkørsel hakker på samme punkt i hver episode, er netværket sandsynligvis ikke årsagen. En politik, der tøver ved den samme ledvinkel hver gang, er normalt et dataproblem; se siderne om fejltyper, især en politik, der kun virker i én opsætning og tab falder, men politikken gør intet.

Gør det selv vs. gør det på AY-Robots

Hvad en fjerninferenssession koster

To tal er vigtige: kortets timepris, og hvor længe du lader det køre. Det første er offentliggjort; det andet overrasker folk.

Disse priser blev aflæst fra Runpods prisside den 23. august 2026, og spotmarkederne bevæger sig. AY-Robots angiver i stedet en hel kørsel: 3 til 6 timer til 1,20 til 2,00 USD per time på A100- eller H100-niveauet, omkring 4 til 12 USD for en GR00T- eller Pi0.5-kørsel; 2 til 5 timer til 0,30 til 0,60 USD per time på 24 GB-niveauet, 1 til 3 USD for SmolVLA eller ACT. En inferenssession slår en træningskørsel på omkostninger kun hvis du stopper den, hvilket er det, den inaktive watchdog er til for. Se faktureringsdokumentation og prissiden.

Hvis du hellere vil undgå netværket i løkken

Fjerninferens løser et hardwareproblem og skaber et latenstidsproblem. Nogle gange er det bedre svar en politik, der passer til den hardware, du har.

• ACT, cirka 80 M parametre og 20 ms pr. handlingstrin, 50 episoder minimum, ethvert 24 GB kort. I et gentagende enkelt-opgave setup slår den ofte en fjern 3 B model, fordi den aldrig venter på en pakke.
• SmolVLA, cirka 450 M parametre og 245 ms pr. handlingstrin, 30 episoder minimum. Den bevarer den sprogkonditionering, som ACT mangler, og lerobot-dokumentationen angiver den til omkring 2 GB ved inferenstid mod cirka 14 GB for PI0.
• ACT vs GR00T N1.7 for nøjagtighedshalvdelen af kompromiset.

Der er også en mellemvej: træn i skyen, evaluer lokalt. Finjustering kræver et 80 GB kort og er ligeglad med latenstid, så træning af GR00T N1.7 på en SO-100 eksternt er ukontroversielt. Kun evalueringssløjfen har en realtidskonstraint; træningsdokumentationen og model- og armmatrixen dækker den halvdel.

Ofte stillede spørgsmål

Den korte version

Fjerninferens for en 3 B politik er et løst ingeniørproblem med et uløst fysikproblem tilknyttet. Ingeniørarbejdet er to kommandoer og en SSH-tunnel. Fysikken er, at en 1.8 MB observation skal nå en GPU i et andet land og komme tilbage, før armen løber tør for handlinger. Lav regnestykket, før du lejer noget, vælg en opgave, der tolererer en forældet observation, og hæv udførelseshorisonten i stedet for at håbe, at forbindelsen forbedres.

Hvis du endnu ikke har optaget et datasæt, optag dit første datasæt og SO-100 opsætningsguide kommer først, og LeRobot datasætformat forklarer, hvad optageren skriver. Baggrunden findes i vision-language-action-modeller og flow-matching policy-arbejdet; arena-indlægget linker hvert benchmark-nummer til en kilde.