Uruchamianie wnioskowania GR00T bez lokalnego GPU

Raspberry Pi wystarczy do sterowania SO-100 przez magistralę szeregową i pobierania klatek z dwóch kamer USB. Nie wystarczy jednak do uruchomienia trzymiliardowego parametru modelu wizualno-językowo-akcyjnego: plik README firmy NVIDIA określa wnioskowanie GR00T N1.7 na jednej karcie GPU z 16 GB lub więcej pamięci VRAM. Aby zobaczyć, co Twój dostrojony GR00T N1.7 punkt kontrolny robi na ramieniu bez kupowania karty, umieść politykę na wynajętej karcie GPU w chmurze, utrzymuj pętlę robota na maszynie z portami USB i wysyłaj obserwacje oraz fragmenty akcji przez sieć.

Działa, nie jest darmowe, a cena nie rozkłada się równomiernie na wszystkie zadania. Poniżej: własny serwer polityk firmy NVIDIA, asynchroniczny stos lerobot, arytmetyka, która z góry mówi, czy Twoje łącze wysyłające jest wystarczająco szybkie, oraz trasa platformy. Wszystko to sprawdzone w stosunku do głównej gałęzi Isaac-GR00T (N1.7 GA) i lerobot 0.6.1 z 23 sierpnia 2026 roku.

Dlaczego polityka nie zmieści się na maszynie robota

Dwie z pięciu polityk, które AY-Robots może trenować, działają na karcie stacji roboczej, trzy nie. Poniższa kolumna dotyczy jednego kroku akcji i jest to liczba, która konkuruje z czasem podróży pakietu w sieci.

Czytaj to jako decyzję, nie ciekawostkę. przy 20 ms na krok działa na maszynie robota i nigdy więcej o tym nie myślisz. przy 485 ms zużywa jedną trzecią sekundy, zanim pakiet opuści Twój budynek. i dodają stronę dokładności.

Dwa istniejące stosy klient-serwer

Isaac-GR00T dostarcza serwer żądanie-odpowiedź ZeroMQ; lerobot dostarcza serwer gRPC zbudowany wokół asynchronicznej inferencji. Oba akceptują GR00T punkt kontrolny. Lista obsługiwanych polityk lerobot w async_inference/constants.py to act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 i groot; jego lista robotów to so100_follower, so101_follower, bi_so_follower i omx_follower.

Wiersz serializacji ma większe znaczenie, niż się wydaje. GR00T's MsgSerializer odmawia obsługi ładunków ndarray typu obiektowego w obu kierunkach, ponieważ msgpack_numpy przekazałby je w przeciwnym razie do pickle. lerobot używa pickle zamiast tego: policy_server.py wywołuje pickle.loads na danych żądania, robot_client.py serializuje obserwację, którą wysyła. Możliwe do obrony w zaufanej sieci LAN, niemożliwe do obrony, gdy port jest dostępny z internetu.

Trasa A: Własny serwer polityk GR00T firmy NVIDIA

Jest to ścieżka, którą NVIDIA dokumentuje dla sprzętu SO-100 i SO-101, i której należy użyć, jeśli Twój punkt kontrolny pochodzi z examples/finetune.sh z --embodiment-tag NEW_EMBODIMENT. Kroki te dodają to, co pomija oryginalny plik README: jak przekazać port do robota, nie udostępniając go wszystkim innym.

1. 1
   Zainstaluj GR00T na wynajętym serwerze GPU

   Podmoduły są wymagane, a git-lfs musi istnieć przed klonowaniem, w przeciwnym razie pliki parquet w demo_data pojawią się jako wskaźniki. flash-attn i TensorRT są dostarczane z domyślną instalacją. Pułapka na świeżym obrazie poda: torchcodec 0.8.0 jest jedynym obsługiwanym backendem wideo i ładuje tylko FFmpeg w wersjach od 4 do 7. Ubuntu 25.10 i 26.04 dostarczają FFmpeg 8, więc GR00T zawodzi z komunikatem Could not load libtorchcodec. Zainstaluj FFmpeg w wersji poniżej 8 i umieść jego biblioteki w 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
   Uwierzytelnij się wobec bramkowanego rdzenia

   Każdy punkt kontrolny GR00T N1.7, w tym Twój własny dostrojony model, ładuje bramkowany nvidia/Cosmos-Reason2-2B przy pierwszym użyciu. Poproś o dostęp na stronie modelu i zaloguj się na podzie, w przeciwnym razie ładowanie zakończy się błędem GatedRepoError.

   bash

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

3. 3
   Uruchom serwer polityk

   Skieruj --model-path na katalog z punktem kontrolnym; na tej ścieżce serwer ignoruje --modality-config-path, który jest odczytywany tylko na ścieżce odtwarzania. Pomiń --model-path i zamiast tego przekaż --dataset-path oraz --execution-horizon dla ReplayPolicy, która odtwarza zarejestrowane akcje, co jest najtańszym sposobem na sprawdzenie poprawności połączeń.

   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
   Tuneluj port 5555 do maszyny robota

   Powiąż z interfejsem loopback, jak powyżej, i przenieś port przez SSH lub sieć typu WireGuard. Zapewnia to szyfrowanie i uwierzytelnianie, których gniazdo ZeroMQ nie oferuje, za około milisekundę.

   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
   Uruchom klienta robota obok serwomechanizmów

   Klient potrzebuje własnego środowiska uv: chce sterowników robota lerobot, a nie stosu treningowego. eval_so100.py importuje so100_follower, so101_follower i koch_follower, więc przekaż --robot.type pasujący do Twojego ramienia (oryginalny plik README używa so101_follower). Klucze kamer muszą odpowiadać tym z treningu: adapter odczytuje dokładnie front i wrist, a ich zamiana pokazuje polityce niewłaściwy widok.

   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"

Trasa B: asynchroniczne wnioskowanie lerobot

lerobot rozwiązuje inny problem. Zamiast blokować robota, gdy model myśli, klient kontynuuje przetwarzanie kolejki, którą już posiada, podczas gdy serwer oblicza następny fragment. Jest to fragmentowanie akcji rozwinięte dalej, stos asynchroniczny wprowadzony wraz ze SmolVLA. Działa również z punktem kontrolnym 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

Serwer uruchamia się pusty: nie wie, jaką politykę obsługuje, dopóki pierwsze uzgadnianie klienta mu tego nie powie, co jest wygodne na wynajętym podzie. Dwa pokrętła, które decydują o płynnym ruchu ramienia, to actions_per_chunk i chunk_size_threshold (dokumentacja lerobot nazywa drugi z nich g, po artykule SmolVLA), a udokumentowane wartości i dostarczone wartości nie zgadzają się.

Arytmetyka, która decyduje, czy twoje łącze jest wystarczająco szybkie

Ludzie to pomijają, a potem spędzają dzień na . Zajmuje to dwie minuty i prawie zawsze jest decydujące.

Skomentowany słownik obserwacji w pliku NVIDIA eval_so100.py mówi, co trafia do sieci: dwie tablice o kształcie (480, 640, 3) w formacie uint8, sześć zmiennoprzecinkowych wartości stawów, ciąg znaków języka. To 921 600 bajtów na klatkę, 1 843 200 bajtów dla dwóch kamer, około 14.7 Mbit, i żaden stos tego nie kompresuje JPEG. Fragment danych powracający to kilkadziesiąt kroków po 6 wartości zmiennoprzecinkowych. Twój upload decyduje o wszystkim, nie download.

Budżet, w którym musisz się zmieścić

Klient GR00T SO-100 jest synchroniczny: wywołuje policy.get_action(obs), wykonuje pierwsze action_horizon kroki fragmentu z prędkością 30 FPS, a następnie wywołuje ponownie. Rozmiar fragmentu i horyzont to różne liczby: przewodnik wdrożeniowy NVIDIA zaleca rozmiar fragmentu akcji wynoszący 16, co najmniej 32 w połączeniu z fragmentowaniem w czasie rzeczywistym, podczas gdy eval_so100.py dostarcza horyzont wykonania wynoszący 8. Osiem kroków przy 30 FPS to 267 ms ruchu na wywołanie, a wszystko inne musi się w tym zmieścić.

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

Zwiększenie horyzontu to proste, ale nie darmowe rozwiązanie: ramię działa na podstawie obserwacji, która jest już przestarzała. Zasadowym rozwiązaniem jest fragmentowanie w czasie rzeczywistym (real-time chunking - RTC), które oblicza następny fragment, podczas gdy bieżący jest wykonywany, zamraża akcje gwarantowane do wykonania i uzupełnia resztę; artykuł o RTC donosi, że jest ono odporne na opóźnienia wnioskowania bez konieczności ponownego trenowania. Sprawdź najpierw, jak to wygląda. NVIDIA oznacza RTC jako eksperymentalne, prymityw modelu niskiego poziomu dostępny poprzez action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), niepodłączony do Gr00tPolicy ani ścieżki serwer-klient, gdzie options jest niewykorzystywane, bez testów i przykładów. Przez serwer polityki uzyskujesz asynchroniczne wykonanie, a nie RTC.

Zmierz, zanim zaufasz

Każda z powyższych liczb to przewidywanie. Cztery polecenia zamieniają ją w pomiar, który warto wykonać, zanim poświęcisz godzinę poda na zadanie, które nigdy nie miało szans zadziałać.

1. 1
   Uzyskaj surowy czas podróży w obie strony

   Wobec poda, nie CDN. Obserwuj odchylenie tak samo uważnie jak średnią: to jitter powoduje zacinanie się ramienia, a nie średnie opóźnienie.

   bash

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

2. 2
   Zmierz łącze wysyłania, które masz, a nie to, za które płacisz

   Prędkość wysyłania w sieciach domowych to zazwyczaj ułamek prędkości pobierania i jest to liczba z powyższej tabeli przepustowości.

   bash

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

3. 3
   Odczytaj własny log opóźnień klienta

   Klient robota lerobot loguje opóźnienie serwer-klient i czas deserializacji dla każdego fragmentu. Na trasie B nie potrzebujesz żadnych zewnętrznych narzędzi.

   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
   Obserwuj opróżnianie kolejki akcji

   Przekaż --debug_visualize_queue_size=True, a klient wykreśli rozmiar kolejki w czasie rzeczywistym. Jeśli wielokrotnie osiąga zero, oznacza to, że przekroczyłeś budżet: zmniejsz fps, zwiększ actions_per_chunk lub zwiększ chunk_size_threshold, aby obserwacje były wysyłane częściej.

   bash

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

Do czego tak naprawdę przydaje się zdalna inferencja

Jeśli zdalne uruchomienie zacina się w tym samym miejscu w każdym odcinku, sieć prawdopodobnie nie jest przyczyną. Polityka wahająca się za każdym razem przy tym samym kącie stawu jest zazwyczaj problemem z danymi; zobacz strony trybów awarii, w szczególności politykę, która działa tylko w jednej konfiguracji i spadek straty, ale polityka nic nie robi.

Robienie tego samemu kontra robienie tego na AY-Robots

Ile kosztuje zdalna sesja inferencji

Liczą się dwie liczby: stawka godzinowa karty i czas, przez jaki ją pozostawiasz włączoną. Pierwsza jest publikowana; druga zaskakuje ludzi.

Te stawki zostały odczytane ze strony cennika Runpod 23 sierpnia 2026 roku, a rynki spotowe są zmienne. AY-Robots podaje zamiast tego koszt całego uruchomienia: od 3 do 6 godzin po 1.20 do 2.00 USD za godzinę na warstwie A100 lub H100, około 4 do 12 USD za uruchomienie GR00T lub Pi0.5; od 2 do 5 godzin po 0.30 do 0.60 USD za godzinę na warstwie 24 GB, od 1 do 3 USD dla SmolVLA lub ACT. Sesja wnioskowania przewyższa uruchomienie treningowe pod względem kosztów tylko wtedy, gdy ją zatrzymasz, do czego służy mechanizm nadzoru bezczynności. Zobacz dokumentację rozliczeniową i stronę z cennikiem.

Jeśli wolisz nie mieć sieci w pętli

Zdalna inferencja rozwiązuje problem sprzętowy i tworzy problem opóźnień. Czasami lepszym rozwiązaniem jest polityka dopasowana do posiadanego sprzętu.

• ACT, około 80 M parametrów i 20 ms na krok akcji, minimum 50 epizodów, dowolna karta 24 GB. W konfiguracji powtarzalnych zadań jednostkowych często przewyższa zdalny model 3 B, ponieważ nigdy nie czeka na pakiet.
• SmolVLA, około 450 M parametrów i 245 ms na krok akcji, minimum 30 epizodów. Zachowuje warunkowanie językowe, którego brakuje ACT, a dokumentacja lerobot podaje, że zajmuje około 2 GB podczas inferencji w porównaniu do około 14 GB dla PI0.
• ACT vs GR00T N1.7 dla połowy kompromisu dotyczącej dokładności.

Istnieje również droga pośrednia: trenuj w chmurze, oceniaj lokalnie. Dostrajanie wymaga karty 80 GB i nie dba o opóźnienia, więc trenowanie GR00T N1.7 na SO-100 zdalnie jest bezsporne. Tylko pętla ewaluacyjna ma ograniczenie czasowe; dokumentacja szkoleniowa i macierz modeli i ramion obejmują tę połowę.

Często zadawane pytania

Wersja skrócona

Zdalne wnioskowanie dla 3 B polityki to rozwiązany problem inżynierski z nierozwiązanym problemem fizycznym. Inżynieria to dwa polecenia i tunel SSH. Fizyka polega na tym, że obserwacja o rozmiarze 1.8 MB musi dotrzeć do GPU w innym kraju i wrócić, zanim ramię wyczerpie dostępne akcje. Wykonaj obliczenia przed wynajęciem czegokolwiek, wybierz zadanie, które toleruje nieaktualną obserwację, i zwiększ horyzont wykonania, zamiast liczyć na poprawę łącza.

Jeśli jeszcze nie nagrałeś zbioru danych, nagraj swój pierwszy zbiór danych oraz przewodnik konfiguracji SO-100 są najważniejsze, a format zbioru danych LeRobot wpis wyjaśnia, co zapisuje rejestrator. Tło znajduje się w modelach wizualno-językowo-akcyjnych oraz pracy nad polityką dopasowania przepływu; wpis na arenie łączy każdą liczbę benchmarku ze źródłem.