Patakbuhin ang GR00T Inference Nang Walang Lokal na GPU

Ang isang Raspberry Pi ay sapat na upang paandarin ang isang sa pamamagitan ng serial bus at kumuha ng mga frame mula sa dalawang USB camera. Hindi ito sapat upang patakbuhin ang isang three billion parameter na : Ayon sa README ng NVIDIA, ang GR00T N1.7 inference ay nangangailangan ng isang GPU na may 16 GB o higit pa ng VRAM. Upang makita kung ano ang ginagawa ng iyong na-fine-tune na checkpoint sa braso nang hindi bumibili ng card, ilagay ang policy sa isang inupahang cloud GPU, panatilihin ang robot loop sa makina na may mga USB port, at ipadala ang mga obserbasyon at action chunks sa network.

Gumagana ito, hindi ito libre, at ang presyo ay hindi pantay na nakakalat sa iba't ibang gawain. Sa ibaba: Ang sariling policy server ng NVIDIA, ang async stack ng lerobot, ang aritmetika na nagsasabi nang maaga kung sapat ang bilis ng iyong uplink, at ang ruta ng platform. Lahat ng ito ay sinuri laban sa Isaac-GR00T main branch (N1.7 GA) at lerobot 0.6.1 noong 23 August 2026.

Bakit hindi magkakasya ang policy sa robot machine

Dalawa sa limang patakaran na kayang sanayin ng AY-Robots ay tumatakbo sa isang workstation card, tatlo ang hindi. Ang na column sa ibaba ay bawat hakbang ng aksyon, at iyan ang bilang na nakikipagkumpitensya sa iyong network round trip.

Basahin iyan bilang isang desisyon, hindi trivia. sa 20 ms bawat hakbang ay tumatakbo sa makina ng robot at hindi mo na ito iisipin pa. sa 485 ms ay gumugol ng isang-katlo ng isang segundo bago umalis ang isang packet sa iyong gusali. Ang at ay nagdaragdag ng panig ng katumpakan.

Ang dalawang client-server stack na umiiral na

Ang Isaac-GR00T ay nagpapadala ng ZeroMQ request-reply server; ang lerobot ay nagpapadala ng gRPC server na binuo sa paligid ng asynchronous inference. Pareho silang tumatanggap ng GR00T checkpoint. Ang listahan ng sinusuportahang policy ng lerobot sa async_inference/constants.py ay act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 at groot; ang listahan ng robot nito ay so100_follower, so101_follower, bi_so_follower at omx_follower.

Ang serialization row ay mas mahalaga kaysa sa tingin. Ang MsgSerializer ng GR00T ay tumatanggi sa object-dtype ndarray payloads sa parehong direksyon, dahil kung hindi ay ibibigay ng msgpack_numpy ang mga ito sa pickle. Sa halip, nagpi-pickle ang lerobot: tinatawag ng policy_server.py ang pickle.loads sa data ng kahilingan, at nagpi-pickle ang robot_client.py ng observation na ipinapadala nito. Depensable sa isang pinagkakatiwalaang LAN, hindi depensable kapag ang port ay naaabot na mula sa internet.

Route A: Sariling GR00T policy server ng NVIDIA

Ito ang landas na idinodokumento ng NVIDIA para sa SO-100 at SO-101 hardware, at ang gagamitin kung ang iyong checkpoint ay nagmula sa examples/finetune.sh na may --embodiment-tag NEW_EMBODIMENT. Idinagdag ng mga hakbang ang hindi kasama sa upstream README: ang pagkuha ng port sa robot nang hindi ito inilalantad sa iba.

1. 1
   I-install ang GR00T sa inupahang GPU box

   Kinakailangan ang mga submodule, at dapat mayroong git-lfs bago ang clone o ang mga parquet file sa demo_data ay darating bilang mga pointer. Ang flash-attn at TensorRT ay kasama sa default na pag-install. Ang bitag sa isang bagong pod image: Ang torchcodec 0.8.0 lamang ang sinusuportahang video backend at naglo-load lamang ng FFmpeg 4 hanggang 7. Ang Ubuntu 25.10 at 26.04 ay nagpapadala ng FFmpeg 8, kaya nabibigo ang GR00T na may Could not load libtorchcodec. Mag-install ng FFmpeg na mas mababa sa 8 at ilagay ang mga library nito sa 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
   Mag-authenticate laban sa gated backbone

   Ang bawat GR00T N1.7 checkpoint, kasama ang iyong sariling fine-tune, ay naglo-load ng gated nvidia/Cosmos-Reason2-2B sa unang paggamit. Humiling ng access sa pahina ng modelo at mag-log in sa pod, o mabibigo ang paglo-load na may GatedRepoError.

   bash

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

3. 3
   Simulan ang policy server

   Ituro ang --model-path sa iyong checkpoint directory; sa landas na iyon ay binabalewala ng server ang --modality-config-path, na binabasa lamang sa replay path. Alisin ang --model-path at ipasa ang --dataset-path kasama ang --execution-horizon sa halip para sa isang ReplayPolicy na nagre-replay ng mga naitalang aksyon, ang pinakamurang paraan upang patunayan na gumagana ang wiring.

   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
   I-tunnel ang port 5555 sa robot machine

   Mag-bind sa loopback, tulad ng nasa itaas, at dalhin ang port sa SSH o isang WireGuard-style mesh. Nagbibigay iyon ng encryption at authentication na hindi ibinibigay ng ZeroMQ socket, sa loob ng humigit-kumulang isang millisecond.

   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
   Patakbuhin ang robot client sa tabi ng mga servo

   Kailangan ng client ang sarili nitong uv environment: gusto nito ang mga robot driver ng lerobot, hindi ang training stack. Ini-import ng eval_so100.py ang so100_follower, so101_follower at koch_follower, kaya ipasa ang --robot.type na tumutugma sa iyong braso (ginagamit ng upstream README ang so101_follower). Dapat tumugma ang mga camera key sa training: binabasa ng adapter nang eksakto ang front at wrist, at ang pagpapalit ng mga ito ay nagpapakita sa policy ng maling view.

   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: lerobot asynchronous inference

Nilulutas ng lerobot ang ibang problema. Sa halip na harangan ang robot habang nag-iisip ang modelo, patuloy na naglalakad ang client sa queue na mayroon na ito habang kinukwenta ng server ang susunod na chunk. Ito ay pag-chunk ng aksyon na mas pinahusay pa, ang asynchronous stack na ipinakilala sa SmolVLA. Gumagana rin ito sa isang 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

Ang server ay nagsisimula nang walang laman: hindi nito alam kung aling patakaran ang inihahatid nito hanggang sa sabihin ito ng unang handshake ng client, na maginhawa sa isang inupahang pod. Ang dalawang kontrol na nagpapasya kung ang braso ay gumagalaw nang maayos ay actions_per_chunk at chunk_size_threshold (tinatawag ng mga dokumento ng lerobot ang pangalawa na g, mula sa papel ng SmolVLA), at ang mga dokumentadong halaga at ang mga naipadala na halaga ay hindi magkatugma.

Ang aritmetika na nagpapasya kung sapat na ba ang bilis ng iyong link

Nilalaktawan ito ng mga tao at pagkatapos ay gumugugol ng isang araw sa . Tumatagal ito ng dalawang minuto at halos palaging mahalaga.

Ang naka-comment na observation dict sa eval_so100.py ng NVIDIA ay nagsasabi kung ano ang dumadaan sa wire: dalawang array na may hugis (480, 640, 3) sa uint8, anim na joint float, isang language string. Iyan ay 921,600 bytes bawat frame, 1,843,200 bytes para sa dalawang camera, humigit-kumulang 14.7 Mbit, at walang stack ang nag-JPEG-compress nito. Ang chunk na bumabalik ay ilang dosenang hakbang ng 6 na float. Ang iyong upload ang nagpapasya sa lahat, hindi ang iyong download.

Ang budget na kailangan mong pagkasya

Ang GR00T SO-100 client ay sabay-sabay (synchronous): tinatawag nito ang policy.get_action(obs), isinasagawa ang unang action_horizon na hakbang ng chunk sa 30 FPS, pagkatapos ay tumatawag muli. Ang laki ng chunk at horizon ay magkaibang numero: Inirerekomenda ng deployment guide ng NVIDIA ang laki ng action chunk na 16, hindi bababa sa 32 kapag isinama sa real-time chunking, habang ang eval_so100.py ay nagbibigay ng execution horizon na 8. Ang walong hakbang sa 30 FPS ay 267 ms ng galaw bawat tawag, at ang lahat ng iba pa ay kailangang magkasya doon.

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

Ang pagtaas ng horizon ay isang diretsong solusyon at hindi libre: ang braso ay kumikilos batay sa isang obserbasyon na luma na. Ang prinsipyong solusyon ay real-time chunking, na kinakalkula ang susunod na chunk habang tumatakbo ang kasalukuyan, pinapatigil ang mga aksyon na garantisadong maisasagawa at pinupunan ang natitira; iniulat ng papel ng RTC na ito ay matatag sa pagkaantala ng inference nang walang retraining. Tingnan muna kung nasaan iyon. Minarkahan ng NVIDIA ang RTC bilang eksperimental, isang low-level na model primitive na naaabot sa pamamagitan ng action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), hindi nakakonekta sa Gr00tPolicy o sa server-client path, kung saan ang options ay hindi ginagamit, walang mga pagsubok at walang halimbawa. Sa isang policy server makakakuha ka ng asynchronous execution, hindi RTC.

Sukatin bago pagkatiwalaan

Ang bawat numero sa itaas ay isang prediksyon. Apat na utos ang magpapalit nito sa isang pagsukat, na nararapat patakbuhin bago maglaan ng pod-hour sa isang gawain na hindi naman talaga gagana.

1. 1
   Kunin ang hilaw na round trip

   Laban sa pod, hindi sa CDN. Bantayan ang paglihis nang kasing-lapit ng mean: ang jitter ang nagiging sanhi ng pagkaantala ng braso, hindi ang average latency.

   bash

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

2. 2
   Sukatin ang uplink na mayroon ka, hindi ang binabayaran mo

   Ang residential upload ay karaniwang isang bahagi lamang ng download, at ito ang numero sa talahanayan ng bandwidth sa itaas.

   bash

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

3. 3
   Basahin ang sariling latency log ng client

   Ang lerobot robot client ay nagla-log ng server-to-client latency at deserialization time para sa bawat chunk. Sa ruta B, hindi mo kailangan ng panlabas na kagamitan.

   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
   Panoorin ang pagkaubos ng action queue

   Ipasa ang --debug_visualize_queue_size=True at ipinapakita ng client ang laki ng queue sa runtime. Kung paulit-ulit itong umabot sa zero, ubos na ang iyong budget: babaan ang fps, itaas ang actions_per_chunk, o itaas ang chunk_size_threshold upang mas madalas lumabas ang mga obserbasyon.

   bash

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

Para saan nga ba talaga ang remote inference

Kung ang isang remote na pagpapatakbo ay nagiging putol-putol sa parehong punto sa bawat episode, malamang na hindi ang network ang sanhi. Ang isang patakaran na nag-aalangan sa parehong joint angle sa bawat pagkakataon ay karaniwang problema sa data; tingnan ang mga pahina ng failure-mode, partikular ang isang patakaran na gumagana lamang sa isang setup at bumababa ang loss ngunit walang ginagawa ang patakaran.

Paggawa nito nang mag-isa kumpara sa paggawa nito sa AY-Robots

Magkano ang gastos ng isang remote inference session

Dalawang numero ang mahalaga: ang hourly rate ng card, at kung gaano katagal mo ito pinapatakbo. Ang una ay nai-publish; ang pangalawa ay nakakagulat sa mga tao.

Ang mga rate na iyon ay nabasa mula sa pricing page ng Runpod noong 23 Agosto 2026, at gumagalaw ang mga spot market. Sa halip, ang AY-Robots ay nagbibigay ng presyo para sa buong run: 3 hanggang 6 na oras sa 1.20 hanggang 2.00 USD bawat oras sa A100 o H100 tier, humigit-kumulang 4 hanggang 12 USD para sa isang GR00T o Pi0.5 run; 2 hanggang 5 oras sa 0.30 hanggang 0.60 USD bawat oras sa 24 GB tier, 1 hanggang 3 USD para sa SmolVLA o ACT. Mas matipid ang isang inference session kaysa sa isang training run kung ititigil mo ito, na siyang layunin ng idle watchdog. Tingnan ang mga dokumento ng pagsingil, at ang pahina ng pagpepresyo.

Kung mas gusto mong hindi kasama ang network sa proseso

Ang remote inference ay lumulutas ng problema sa hardware at lumilikha ng problema sa latency. Minsan, ang mas mahusay na sagot ay isang patakaran na akma sa hardware na mayroon ka.

• ACT, humigit-kumulang 80 M parameters at 20 ms bawat hakbang ng aksyon, 50 episodes minimum, anumang 24 GB card. Sa isang paulit-ulit na single-task setup, madalas nitong talunin ang isang remote na 3 B model, dahil hindi ito naghihintay ng packet.
• SmolVLA, humigit-kumulang 450 M parameters at 245 ms bawat hakbang ng aksyon, 30 episodes minimum. Pinapanatili nito ang language conditioning na kulang sa ACT, at inilalagay ito ng lerobot docs sa humigit-kumulang 2 GB sa oras ng inference laban sa humigit-kumulang 14 GB para sa PI0.
• ACT vs GR00T N1.7 para sa kalahati ng trade na nauugnay sa katumpakan.

Mayroon ding gitnang landas: magsanay sa cloud, suriin nang lokal. ay nangangailangan ng 80 GB card at hindi alintana ang latency, kaya ang nang remote ay hindi kontrobersyal. Tanging ang evaluation loop ang may real-time na limitasyon; ang at ang ang sumasaklaw sa kalahating iyon.

Mga madalas itanong

Ang maikling bersyon

Ang remote inference para sa isang 3 B patakaran ay isang nalutas na problema sa engineering na may nakakabit na hindi pa nalulutas na problema sa physics. Ang engineering ay dalawang command at isang SSH tunnel. Ang physics ay kailangang makarating ang isang 1.8 MB na obserbasyon sa isang GPU sa ibang bansa at makabalik bago maubusan ng aksyon ang braso. Gawin ang aritmetika bago umarkila ng anuman, pumili ng gawain na kayang tiisin ang isang lumang obserbasyon, at itaas ang execution horizon sa halip na umasa na bubuti ang link.

Kung hindi ka pa nakakapag-record ng dataset, at ang ang unahin, at ang na entry ay nagpapaliwanag kung ano ang isinusulat ng recorder. Ang background ay nasa at ang ; ang ay nagli-link ng bawat benchmark number sa isang source.