GR00T következtetés futtatása helyi GPU nélkül

Egy Raspberry Pi elegendő ahhoz, hogy meghajtson egy soros buszon keresztül, és képkockákat húzzon le két USB kameráról. Nem elegendő egy hárommilliárd paraméteres : Az NVIDIA README-je szerint a GR00T N1.7 következtetéshez egy GPU szükséges 16 GB vagy több VRAM-mal. Ahhoz, hogy lássa, mit csinál a finomhangolt ellenőrzőpont a karon anélkül, hogy kártyát vásárolna, helyezze a szabályzatot egy bérelt felhő GPU-ra, tartsa a robot hurkot az USB portokkal rendelkező gépen, és küldje az észleléseket és akció darabokat a hálózaton keresztül.

Működik, nem ingyenes, és az ár nem oszlik el egyenletesen a feladatok között. Alább: az NVIDIA saját szabályzati szervere, a lerobot aszinkron stackje, az aritmetika, amely előre megmondja, hogy az uplinkje elég gyors-e, és a platform útvonal. Mindez ellenőrizve az Isaac-GR00T fő ágával (N1.7 GA) és a lerobot 0.6.1-gyel 2026. augusztus 23-án.

Miért nem fér el a szabályzat a robotgépen

Az AY-Robots által betanítható öt irányelv közül kettő munkaállomás-kártyán fut, három nem. A következtetési késleltetés oszlop alább műveleti lépésenként értendő, és ez az a szám, amely versenyez a hálózati oda-vissza útjával.

Ezt döntésként értelmezze, nem érdekességként. ACT 20 ms/lépés sebességgel fut a robotgépen, és soha többé nem kell gondolnia rá. Pi0.5 485 ms-nál egyharmad másodpercet töltött el, mielőtt egy csomag elhagyja az épületét. A irányelv összehasonlítás és GR00T N1.7 vs Pi0.5 hozzáadják a pontossági oldalt.

A két már létező kliens-szerver verem

Az Isaac-GR00T egy ZeroMQ kérés-válasz szervert szállít; a lerobot egy gRPC szervert szállít, amely aszinkron következtetés köré épül. Mindkettő elfogad egy GR00T ellenőrzőpontot. A lerobot támogatott irányelvlistája a async_inference/constants.py a act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 és groot; robotlistája pedig a so100_follower, so101_follower, bi_so_follower és omx_follower.

A szerializációs sor fontosabb, mint amilyennek látszik. A GR00T MsgSerializer elutasítja az objektum-dtype ndarray hasznos adatokat mindkét irányban, mert a msgpack_numpy egyébként átadná őket a pickle-nek. A lerobot ehelyett pickle-t használ: policy_server.py hívja a pickle.loads függvényt a kérés adatokon, a robot_client.py pickle-zi az általa küldött megfigyelést. Megvédhető egy megbízható LAN-on, de védhetetlen, ha a port elérhető az internetről.

A útvonal: Az NVIDIA saját GR00T irányelv szervere

Ez az az útvonal, amelyet az NVIDIA dokumentál az SO-100 és SO-101 hardverekhez, és ezt kell használni, ha a checkpointja a examples/finetune.sh fájlból származik, a --embodiment-tag NEW_EMBODIMENT paraméterrel. A lépések kiegészítik azt, amit az upstream README kihagy: a port eljuttatása a robothoz anélkül, hogy mindenki más számára elérhetővé tennénk.

1. 1
   GR00T telepítése a bérelt GPU dobozra

   Az almodulok szükségesek, és a git-lfs-nek léteznie kell a klónozás előtt, különben a demo_data parquet fájljai mutatókként érkeznek. A flash-attn és a TensorRT az alapértelmezett telepítéssel érkezik. Egy friss pod image-en a csapda: a torchcodec 0.8.0 az egyetlen támogatott videó backend, és csak az FFmpeg 4-7-et tölti be. Az Ubuntu 25.10 és 26.04 az FFmpeg 8-at szállítja, így a GR00T hibát jelez Could not load libtorchcodec üzenettel. Telepítsen egy 8 alatti FFmpeg-et, és tegye a könyvtárait az LD_LIBRARY_PATH-ra.

   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
   Hitelesítés a zárt gerinchálózat ellen

   Minden GR00T N1.7 checkpoint, beleértve a saját finomhangolását is, az első használatkor betölti a zárt nvidia/Cosmos-Reason2-2B modellt. Kérjen hozzáférést a modell oldalán, és jelentkezzen be a podon, különben a betöltés GatedRepoError hibával meghiúsul.

   bash

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

3. 3
   Az irányelv szerver indítása

   Mutasson a --model-path paraméterrel a checkpoint könyvtárára; ezen az útvonalon a szerver figyelmen kívül hagyja a --modality-config-path paramétert, amelyet csak a visszajátszási útvonalon olvas be. Hagyja el a --model-path paramétert, és adja át helyette a --dataset-path és a --execution-horizon paramétereket egy ReplayPolicy-hoz, amely rögzített műveleteket játszik vissza, ami a legolcsóbb módja annak, hogy bebizonyítsa a bekötés működését.

   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
   Az 5555-ös port alagutazása a robotgéphez

   Kösse a loopback-hez, ahogy fentebb, és vigye át a portot SSH-n vagy egy WireGuard-szerű hálózaton keresztül. Ez biztosítja azt a titkosítást és hitelesítést, amit a ZeroMQ socket nem, körülbelül egy milliszekundum alatt.

   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
   A robot kliens futtatása a szervók mellett

   A kliensnek saját uv környezetre van szüksége: a lerobot robotmeghajtóit akarja, nem a képzési stack-et. Az eval_so100.py importálja az so100_follower, so101_follower és koch_follower modulokat, ezért adja át a karjának megfelelő --robot.type paramétert (az upstream README az so101_follower-t használja). A kamera kulcsoknak meg kell egyezniük a képzéssel: az adapter pontosan a front és wrist kulcsokat olvassa, és ezek felcserélése rossz nézetet mutat az irányelvnek.

   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"

B útvonal: lerobot aszinkron következtetés

A lerobot egy másik problémát old meg. Ahelyett, hogy blokkolná a robotot, amíg a modell gondolkodik, a kliens folyamatosan lépteti a már meglévő sorát, miközben a szerver kiszámítja a következő darabot. Ez az akció darabolás továbbfejlesztett változata, az aszinkron verem, amelyet a SmolVLA vezetett be. GR00T ellenőrzőponttal is működik.

# 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

A szerver üresen indul: nem tudja, milyen irányelvet szolgál ki, amíg az ügyfél első kézfogása nem közli vele, ami kényelmes egy bérelt podon. A két gomb, amely eldönti, hogy a kar simán mozog-e, a actions_per_chunk és a chunk_size_threshold (a lerobot dokumentációja a másodikat g-nek nevezi, a SmolVLA tanulmány után), és a dokumentált értékek és a szállított értékek nem egyeznek.

Az aritmetika, amely eldönti, hogy a kapcsolata elég gyors-e

Az emberek ezt kihagyják, majd egy napot töltenek azzal, hogy egy olyan irányelvvel, amely mozgás közben lefagy. Két percet vesz igénybe, és szinte mindig döntő.

Az NVIDIA eval_so100.py kommentált megfigyelési szótára leírja, mi kerül a vezetékre: két (480, 640, 3) alakú uint8 tömb, hat ízületi lebegőpontos szám, egy nyelvi karakterlánc. Ez 921 600 bájt képkockánként, 1 843 200 bájt két kamerához, körülbelül 14,7 Mbit, és egyik verem sem JPEG-tömöríti. A visszatérő adatcsomag néhány tucat lépés 6 lebegőpontos számmal. A feltöltésed dönt el mindent, nem a letöltésed.

A költségvetés, amibe bele kell férnie

A GR00T SO-100 kliens szinkron: meghívja a policy.get_action(obs), végrehajtja az első action_horizon lépését a szeletnek 30 FPS-en, majd újra meghívja. A szelet mérete és a horizont különböző számok: az NVIDIA telepítési útmutatója 16-os akció szeletméretet javasol, legalább 32-t valós idejű szeleteléssel kombinálva, míg a eval_so100.py 8-as végrehajtási horizonttal érkezik. Nyolc lépés 30 FPS-en 267 ms mozgást jelent hívásonként, és minden másnak bele kell férnie ebbe.

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

A horizont növelése egy durva, és nem ingyenes megoldás: a kar egy már elavult megfigyelés alapján cselekszik. Az elvi megoldás a valós idejű szeletelés (real-time chunking, RTC), amely kiszámítja a következő szeletet, miközben az aktuális fut, befagyasztja a garantáltan végrehajtandó akciókat, és kiegészíti a többit; az RTC tanulmány szerint robusztus az inferencia késleltetésével szemben, újratanítás nélkül. Először ellenőrizze, hol tart ez. Az NVIDIA az RTC-t kísérletinek jelöli, egy alacsony szintű modell primitívának, amely elérhető a action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), nincs bekötve a Gr00tPolicy-ba vagy a szerver-kliens útvonalba, ahol az options nincs használva, tesztek és példa nélkül. Egy policy szerveren keresztül aszinkron végrehajtást kap, nem RTC-t.

Mérje meg, mielőtt megbízik benne

Minden fenti szám egy előrejelzés. Négy parancs méréssé alakítja, amit érdemes lefuttatni, mielőtt egy pod-órát egy olyan feladatra szánnánk, ami sosem fog működni.

1. 1
   A nyers oda-vissza út lekérése

   A pod ellen, nem CDN ellen. Figyelje a szórást olyan szorosan, mint az átlagot: a jitter okozza a kar akadozását, nem az átlagos késleltetést.

   bash

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

2. 2
   Mérje meg a meglévő feltöltési sebességet, ne azt, amiért fizet

   Az otthoni feltöltési sebesség általában a letöltési sebesség töredéke, és ez az a szám a fenti sávszélesség táblázatban.

   bash

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

3. 3
   Olvassa el a kliens saját késleltetési naplóját

   A lerobot robot kliens naplózza a szerver-kliens késleltetést és a deszerializációs időt minden adatcsomaghoz. B útvonalon nincs szüksége külső eszközökre.

   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
   Figyelje az akciósor kiürülését

   Adja át a --debug_visualize_queue_size=True paramétert, és a kliens futásidőben ábrázolja a sor méretét. Ha ismételten nullát ér el, kifogyott a keretből: csökkentse az fps-t, növelje az actions_per_chunk értékét, vagy növelje a chunk_size_threshold értékét, hogy a megfigyelések gyakrabban kerüljenek kiküldésre.

   bash

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

Mire is jó valójában a távoli következtetés

Ha egy távoli futtatás minden epizódban ugyanazon a ponton akadozik, valószínűleg nem a hálózat az ok. Egy szabályzat, amely minden alkalommal ugyanazon az ízületi szögnél habozik, általában adatprobléma; lásd a hibamódok oldalai, különösen a egy szabályzat, amely csak egy beállításban működik és a veszteség csökken, de a szabályzat nem tesz semmit.

Csináld magad vs. csináld az AY-Robots-on

Mennyibe kerül egy távoli következtetési munkamenet

Két szám számít: a kártya óradíja, és az, hogy mennyi ideig hagyja futni. Az elsőt közzéteszik; a második meglepi az embereket.

Ezeket az árakat a Runpod árképzési oldaláról olvastuk le 2026. augusztus 23-án, és a spot piacok változnak. Az AY-Robots ehelyett egy teljes futtatásra ad árajánlatot: 3-6 óra 1,20-2,00 USD/óra áron az A100 vagy H100 szinten, körülbelül 4-12 USD egy GR00T vagy Pi0.5 futtatásért; 2-5 óra 0,30-0,60 USD/óra áron a 24 GB-os szinten, 1-3 USD a SmolVLA vagy ACT futtatásért. Egy következtetési munkamenet csak akkor veri meg a képzési futtatást költségben, ha leállítja, amire az üresjárati figyelő (idle watchdog) szolgál. Lásd a számlázási dokumentációt és az árképzési oldalt.

Ha inkább nem szeretné, hogy a hálózat is benne legyen a körben

A távoli következtetés hardverproblémát old meg és késleltetési problémát hoz létre. Néha a jobb válasz egy olyan irányelv, amely illeszkedik a meglévő hardverhez.

• ACT, nagyjából 80 M paraméter és 20 ms műveleti lépésenként, 50 epizód minimum, bármilyen 24 GB-os kártya. Ismétlődő, egyfeladatos beállítás esetén gyakran felülmúl egy távoli 3 B modellt, mert soha nem vár csomagra.
• SmolVLA, nagyjából 450 M paraméter és 245 ms műveleti lépésenként, 30 epizód minimum. Megtartja azt a nyelvi kondicionálást, ami az ACT-ből hiányzik, és a lerobot dokumentációja szerint körülbelül 2 GB-ot igényel következtetéskor, szemben a PI0 nagyjából 14 GB-jával.
• ACT vs GR00T N1.7 a kompromisszum pontossági feléhez.

Létezik egy középső út is: képzés a felhőben, kiértékelés helyben. Finomhangolás igényli a 80 GB-os kártyát és nem törődik a késleltetéssel, így GR00T N1.7 képzése egy SO-100-on távolról vitathatatlan. Csak a kiértékelési ciklusnak van valós idejű korlátja; a képzési dokumentáció és a modell- és kar-mátrix fedi le ezt a felét.

Gyakran ismételt kérdések

A rövid változat

Távoli következtetés egy 3 B irányelv egy megoldott mérnöki probléma, amelyhez egy megoldatlan fizikai probléma is társul. A mérnöki rész két parancs és egy SSH alagút. A fizika az, hogy egy 1,8 MB-os megfigyelésnek el kell jutnia egy másik országban lévő GPU-hoz, és vissza kell térnie, mielőtt a kar kifutna a cselekvésekből. Végezze el a számításokat, mielőtt bármit bérelne, válasszon olyan feladatot, amely tolerálja az elavult megfigyelést, és növelje a végrehajtási horizontot ahelyett, hogy reménykedne a kapcsolat javulásában.

Ha még nem rögzítettél adathalmazt, és az jön először, és a bejegyzés elmagyarázza, mit ír a rögzítő. A háttér a és a ; az minden benchmark számot egy forráshoz kapcsol.