Rulează inferența GR00T Fără un GPU Local

Un Raspberry Pi este suficient pentru a controla un printr-un bus serial și pentru a prelua cadre de la două camere USB. Nu este suficient pentru a rula un model cu trei miliarde de parametri : README-ul NVIDIA plasează inferența GR00T N1.7 la un GPU cu 16 GB sau mai mult de VRAM. Pentru a vedea ce face punctul de control GR00T N1.7, antrenat fin, pe braț fără a cumpăra o placă, plasați politica pe un GPU cloud închiriat, mențineți bucla robotului pe mașina cu porturile USB și trimiteți observațiile și fragmentele de acțiune prin rețea.

Funcționează, nu este gratuit, iar prețul nu este distribuit uniform pe toate sarcinile. Mai jos: propriul server de politici al NVIDIA, stiva asincronă a lerobot, aritmetica ce indică în avans dacă uplink-ul dumneavoastră este suficient de rapid și ruta platformei. Toate acestea verificate în raport cu ramura principală Isaac-GR00T (N1.7 GA) și lerobot 0.6.1 la 23 august 2026.

De ce politica nu se va potrivi pe mașina robotului

Două dintre cele cinci politici pe care AY-Robots le poate antrena rulează pe o placă de stație de lucru, trei nu. Coloana de mai jos este per pas de acțiune, și acesta este numărul care concurează cu timpul de răspuns al rețelei dumneavoastră.

Citiți asta ca pe o decizie, nu ca pe o informație minoră. la 20 ms per pas rulează pe mașina robotului și nu vă mai gândiți la asta. la 485 ms a petrecut o treime de secundă înainte ca un pachet să părăsească clădirea dumneavoastră. Comparația și adaugă partea de precizie.

Cele două stive client-server care există deja

Isaac-GR00T livrează un server ZeroMQ de tip cerere-răspuns; lerobot livrează un server gRPC construit în jurul inferenței asincrone. Ambele acceptă un GR00T checkpoint. Lista de politici suportate de lerobot în async_inference/constants.py este act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 și groot; lista sa de roboți este so100_follower, so101_follower, bi_so_follower și omx_follower.

Rândul de serializare contează mai mult decât pare. MsgSerializer al GR00T refuză sarcini utile ndarray de tip obiect în ambele direcții, deoarece msgpack_numpy le-ar preda altfel lui pickle. lerobot folosește pickle în schimb: policy_server.py apelează pickle.loads pe datele cererii, robot_client.py folosește pickle pentru observația pe care o trimite. Apărabil într-o rețea LAN de încredere, de neapărat odată ce portul este accesibil de pe internet.

Ruta A: Serverul de politici GR00T propriu al NVIDIA

Aceasta este calea documentată de NVIDIA pentru hardware-ul SO-100 și SO-101, și cea de utilizat dacă punctul dvs. de control a rezultat din examples/finetune.sh cu --embodiment-tag NEW_EMBODIMENT. Pașii adaugă ceea ce README-ul upstream omite: obținerea portului către robot fără a-l expune tuturor celorlalți.

1. 1
   Instalați GR00T pe serverul GPU închiriat

   Submodulele sunt necesare, iar git-lfs trebuie să existe înainte de clonare, altfel fișierele parquet din demo_data ajung ca pointeri. flash-attn și TensorRT vin cu instalarea implicită. Capcana pe o imagine proaspătă de pod: torchcodec 0.8.0 este singurul backend video suportat și încarcă doar FFmpeg 4 până la 7. Ubuntu 25.10 și 26.04 livrează FFmpeg 8, astfel încât GR00T eșuează cu Could not load libtorchcodec. Instalați un FFmpeg sub versiunea 8 și plasați bibliotecile sale pe 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
   Autentificați-vă împotriva backbone-ului cu acces restricționat

   Fiecare punct de control GR00T N1.7, inclusiv propria dvs. ajustare fină, încarcă nvidia/Cosmos-Reason2-2B cu acces restricționat la prima utilizare. Solicitați acces pe pagina modelului și autentificați-vă pe pod, altfel încărcarea eșuează cu o GatedRepoError.

   bash

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

3. 3
   Porniți serverul de politici

   Indicați --model-path către directorul dvs. de puncte de control; pe acea cale serverul ignoră --modality-config-path, care este citit doar pe calea de reluare. Omiteți --model-path și transmiteți în schimb --dataset-path plus --execution-horizon pentru o ReplayPolicy care reia acțiunile înregistrate, cel mai ieftin mod de a demonstra că cablajul funcționează.

   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
   Tunelați portul 5555 către mașina robotului

   Conectați-vă la loopback, ca mai sus, și transportați portul prin SSH sau o rețea de tip WireGuard. Aceasta asigură criptarea și autentificarea pe care socket-ul ZeroMQ nu le oferă, pentru aproximativ o milisecundă.

   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
   Rulați clientul robotului lângă servomotoare

   Clientul are nevoie de propriul său mediu uv: dorește driverele de robot ale lerobot, nu stiva de antrenament. eval_so100.py importă so100_follower, so101_follower și koch_follower, deci transmiteți --robot.type care se potrivește cu brațul dvs. (README-ul upstream folosește so101_follower). Cheile camerei trebuie să se potrivească cu antrenamentul: adaptorul citește exact front și wrist, iar inversarea lor arată politicii o vizualizare greșită.

   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"

Ruta B: inferență asincronă lerobot

lerobot rezolvă o problemă diferită. În loc să blocheze robotul în timp ce modelul gândește, clientul continuă să parcurgă coada pe care o are deja în timp ce serverul calculează următorul segment. Aceasta este fragmentare de acțiuni dusă mai departe, stiva asincronă introdusă cu SmolVLA. Funcționează și cu un checkpoint GR00T.

# 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

Serverul pornește gol: nu știe ce politică servește până când primul handshake al clientului îi spune, ceea ce este convenabil pe un pod închiriat. Cele două setări care decid dacă brațul se mișcă lin sunt actions_per_chunk și chunk_size_threshold (documentația lerobot o numește pe a doua g, după lucrarea SmolVLA), iar valorile documentate și valorile livrate nu concordă.

Aritmetica ce decide dacă legătura dumneavoastră este suficient de rapidă

Oamenii sar peste asta și apoi petrec o zi pe . Durează două minute și este aproape întotdeauna decisiv.

Dicționarul de observații comentat din eval_so100.py de la NVIDIA spune ce se transmite prin rețea: două array-uri de formă (480, 640, 3) în uint8, șase float-uri de articulație, un șir de caractere pentru limbă. Asta înseamnă 921.600 de octeți pe cadru, 1.843.200 de octeți pentru două camere, aproximativ 14,7 Mbit, și niciun stack nu le comprimă JPEG. Blocul care se întoarce conține câteva zeci de pași de 6 float-uri. Upload-ul tău decide totul, nu download-ul.

Bugetul în care trebuie să te încadrezi

Clientul GR00T SO-100 este sincron: apelează policy.get_action(obs), execută primii action_horizon pași ai blocului la 30 FPS, apoi apelează din nou. Dimensiunea blocului și orizontul sunt numere diferite: ghidul de implementare NVIDIA recomandă o dimensiune a blocului de acțiuni de 16, cel puțin 32 atunci când este combinată cu chunking în timp real, în timp ce eval_so100.py livrează un orizont de execuție de 8. Opt pași la 30 FPS înseamnă 267 ms de mișcare per apel, iar tot restul trebuie să se încadreze în acest interval.

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

Creșterea orizontului este o soluție brută și nu una gratuită: brațul acționează pe baza unei observații care este acum veche. Soluția principială este chunking-ul în timp real (real-time chunking - RTC), care calculează următorul bloc în timp ce cel curent rulează, îngheață acțiunile garantate a fi executate și completează restul; lucrarea RTC raportează că este robust la întârzierile de inferență fără a necesita reantrenare. Verificați mai întâi stadiul acestuia. NVIDIA marchează RTC ca experimental, o primitivă de model de nivel scăzut accesibilă prin action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), neintegrată în Gr00tPolicy sau în calea server-client, unde options este neutilizată, fără teste și fără exemplu. Printr-un server de politici obțineți execuție asincronă, nu RTC.

Măsurați înainte de a vă încrede

Fiecare număr de mai sus este o predicție. Patru comenzi îl transformă într-o măsurătoare, care merită executată înainte de a aloca o oră de pod unei sarcini care nu ar fi funcționat niciodată.

1. 1
   Obțineți timpul de răspuns brut

   Împotriva pod-ului, nu a unui CDN. Urmăriți deviația la fel de atent ca și media: jitter-ul face un braț să se blocheze, nu latența medie.

   bash

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

2. 2
   Măsurați uplink-ul pe care îl aveți, nu pe cel pentru care plătiți

   Viteza de upload rezidențială este de obicei o fracțiune din cea de download și este numărul din tabelul de lățime de bandă de mai sus.

   bash

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

3. 3
   Citiți jurnalul de latență al clientului

   Clientul robot lerobot înregistrează latența server-client și timpul de deserializare pentru fiecare fragment. Pe ruta B nu aveți nevoie de instrumente externe.

   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
   Urmăriți golirea cozii de acțiuni

   Transmiteți --debug_visualize_queue_size=True și clientul va afișa grafic dimensiunea cozii în timpul execuției. Dacă atinge în mod repetat zero, ați depășit bugetul: reduceți fps-ul, măriți actions_per_chunk sau măriți chunk_size_threshold pentru ca observațiile să fie trimise mai des.

   bash

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

La ce este de fapt bună inferența la distanță

Dacă o rulare la distanță sacadează în același punct în fiecare episod, rețeaua probabil nu este cauza. O politică care ezită la același unghi articular de fiecare dată este de obicei o problemă de date; vezi paginile despre modurile de eșec, în special o politică ce funcționează doar într-o singură configurație și pierderea scade, dar politica nu face nimic.

Făcând-o tu însuți vs făcând-o pe AY-Robots

Cât costă o sesiune de inferență la distanță

Două numere contează: tariful orar al plăcii și cât timp o lași să ruleze. Primul este publicat; al doilea surprinde oamenii.

Aceste tarife au fost citite de pe pagina de prețuri a Runpod pe 23 august 2026, iar piețele spot sunt volatile. AY-Robots citează o rulare completă în schimb: 3 până la 6 ore la 1.20 până la 2.00 USD pe oră pe nivelul A100 sau H100, aproximativ 4 până la 12 USD pentru o rulare GR00T sau Pi0.5; 2 până la 5 ore la 0.30 până la 0.60 USD pe oră pe nivelul de 24 GB, 1 până la 3 USD pentru SmolVLA sau ACT. O sesiune de inferență depășește o rulare de antrenament la cost doar dacă o opriți, ceea ce este scopul watchdog-ului de inactivitate. Consultați documentația de facturare și pagina de prețuri.

Dacă preferați să nu aveți rețeaua în buclă

Inferența la distanță rezolvă o problemă hardware și creează o problemă de latență. Uneori, răspunsul mai bun este o politică care se potrivește hardware-ului pe care îl aveți.

• ACT, aproximativ 80 M parametri și 20 ms per pas de acțiune, minim 50 episoade, orice placă de 24 GB. Într-o configurație repetitivă cu o singură sarcină, depășește frecvent un model de 3 B la distanță, deoarece nu așteaptă niciodată un pachet.
• SmolVLA, aproximativ 450 M parametri și 245 ms per pas de acțiune, minim 30 de episoade. Păstrează condiționarea lingvistică care lipsește ACT, iar documentația lerobot o estimează la aproximativ 2 GB la momentul inferenței, față de aproximativ 14 GB pentru PI0.
• ACT vs GR00T N1.7 pentru jumătatea de precizie a compromisului.

Există și o cale de mijloc: antrenament în cloud, evaluare locală. Fine-tuning necesită placa de 80 GB și nu-i pasă de latență, așa că antrenarea GR00T N1.7 pe un SO-100 la distanță este necontroversată. Doar bucla de evaluare are o constrângere în timp real; documentația de antrenament și matricea model-și-braț acoperă această jumătate.

Întrebări frecvente

Pe scurt

Inferența la distanță pentru o 3 B politică este o problemă de inginerie rezolvată, cu o problemă de fizică nerezolvată atașată. Ingineria constă în două comenzi și un tunel SSH. Fizica este că o observație de 1.8 MB trebuie să ajungă la un GPU dintr-o altă țară și să se întoarcă înainte ca brațul să rămână fără acțiuni. Faceți calculele înainte de a închiria ceva, alegeți o sarcină care tolerează o observație învechită și măriți orizontul de execuție în loc să sperați că legătura se va îmbunătăți.

Dacă nu ați înregistrat încă un set de date, înregistrați primul dumneavoastră set de date și ghidul de configurare SO-100 vin mai întâi, iar formatul setului de date LeRobot explică ce înregistrează înregistratorul. Contextul se găsește în modelele viziune-limbaj-acțiune și lucrarea despre politica de potrivire a fluxului; intrarea în arenă leagă fiecare număr de benchmark de o sursă.