Изпълнение на GR00T извод без локален GPU

Един Raspberry Pi е достатъчен, за да управлява през серийна шина и да извлича кадри от две USB камери. Не е достатъчно да се изпълнява тримилиарден параметър : README на NVIDIA поставя извода на GR00T N1.7 на един GPU с 16 GB или повече VRAM. За да видите какво прави вашият фино настроен чекпойнт на ръката, без да купувате карта, поставете политиката на нает облачен GPU, запазете цикъла на робота на машината с USB портовете и изпращайте наблюдения и части от действия по мрежата.

Работи, не е безплатно и цената не е равномерно разпределена между задачите. По-долу: собственият сървър за политики на NVIDIA, асинхронният стек на lerobot, аритметиката, която предварително казва дали вашата връзка за качване е достатъчно бърза, и маршрутът на платформата. Всичко това е проверено спрямо основния клон на Isaac-GR00T (N1.7 GA) и lerobot 0.6.1 на 23 август 2026 г.

Защо политиката няма да се побере на машината на робота

Две от петте политики, които AY-Robots може да обучи, работят на работна станция, три не. Колоната по-долу е за стъпка на действие и това е числото, което се конкурира с времето за двупосочно пътуване на вашата мрежа.

Разглеждайте това като решение, а не като любопитен факт. при 20 ms на стъпка работи на машината на робота и никога повече не мислите за това. при 485 ms е изразходвал една трета от секундата, преди пакет да напусне вашата сграда. Сравнението на и добавят страната на точността.

Двата клиент-сървър стека, които вече съществуват

Isaac-GR00T предоставя ZeroMQ сървър за заявки-отговори; lerobot предоставя gRPC сървър, изграден около асинхронно извеждане. И двата приемат GR00T контролна точка. Поддържаният списък с политики на lerobot в async_inference/constants.py е act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 и groot; неговият списък с роботи е so100_follower, so101_follower, bi_so_follower и omx_follower.

Редът за сериализация е по-важен, отколкото изглежда. MsgSerializer на GR00T отказва полезни товари от ndarray с тип обект в двете посоки, защото в противен случай msgpack_numpy би ги предал на pickle. lerobot вместо това използва pickle: policy_server.py извиква pickle.loads върху данните от заявката, robot_client.py сериализира наблюдението, което изпраща. Защитимо в доверена LAN мрежа, незащитимо, след като портът е достъпен от интернет.

Маршрут А: Собствен GR00T сървър за политики на NVIDIA

Това е пътят, който NVIDIA документира за хардуер SO-100 и SO-101, и този, който да използвате, ако вашата контролна точка е създадена от examples/finetune.sh с --embodiment-tag NEW_EMBODIMENT. Стъпките добавят това, което README нагоре по веригата пропуска: как да прехвърлите порта към робота, без да го излагате на всички останали.

1. 1
   Инсталирайте GR00T на наетия GPU сървър

   Подмодулите са задължителни, а git-lfs трябва да съществува преди клонирането, иначе parquet файловете в demo_data ще пристигнат като указатели. flash-attn и TensorRT идват с инсталацията по подразбиране. Капанът при ново изображение на под: torchcodec 0.8.0 е единственият поддържан видео бекенд и зарежда само FFmpeg 4 до 7. Ubuntu 25.10 и 26.04 идват с FFmpeg 8, така че GR00T се проваля с Could not load libtorchcodec. Инсталирайте FFmpeg под версия 8 и поставете неговите библиотеки в 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
   Удостоверяване срещу затворения гръбнак

   Всяка контролна точка на GR00T N1.7, включително вашата собствена фина настройка, зарежда затворения nvidia/Cosmos-Reason2-2B при първо използване. Заявете достъп на страницата на модела и влезте в пода, в противен случай зареждането ще се провали с GatedRepoError.

   bash

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

3. 3
   Стартирайте сървъра за политики

   Насочете --model-path към вашата директория с контролни точки; по този път сървърът игнорира --modality-config-path, който се чете само по пътя за преиграване. Пропуснете --model-path и вместо това предайте --dataset-path плюс --execution-horizon за ReplayPolicy, която преиграва записани действия, най-евтиният начин да докажете, че окабеляването работи.

   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
   Тунелирайте порт 5555 към машината на робота

   Свържете се с loopback, както по-горе, и пренесете порта през SSH или мрежа от типа на WireGuard. Това осигурява криптирането и удостоверяването, които ZeroMQ сокетът не предоставя, за около милисекунда.

   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
   Стартирайте клиента на робота до сервомоторите

   Клиентът се нуждае от собствена uv среда: той иска драйверите за роботи на lerobot, а не стека за обучение. eval_so100.py импортира so100_follower, so101_follower и koch_follower, така че предайте --robot.type, съответстващ на вашата ръка (README нагоре по веригата използва so101_follower). Ключовете на камерата трябва да съответстват на обучението: адаптерът чете точно front и wrist, а размяната им показва на политиката грешен изглед.

   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"

Маршрут Б: асинхронен извод с lerobot

lerobot решава различен проблем. Вместо да блокира робота, докато моделът мисли, клиентът продължава да преминава през опашката, която вече има, докато сървърът изчислява следващия сегмент. Това е разделяне на действията на сегменти развито по-нататък, асинхронният стек, въведен със SmolVLA. Работи и с 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

Сървърът стартира празен: той не знае каква политика обслужва, докато първото ръкостискане на клиента не му каже, което е удобно на нает под. Двата регулатора, които решават дали ръката се движи плавно, са actions_per_chunk и chunk_size_threshold (документацията на lerobot нарича второто g, по името на статията SmolVLA), а документираните и доставените стойности не съвпадат.

Аритметиката, която решава дали вашата връзка е достатъчно бърза

Хората пропускат това и след това прекарват един ден в . Отнема две минути и почти винаги е решаващо.

Коментираният речник за наблюдение в eval_so100.py на NVIDIA казва какво се предава по мрежата: два масива с форма (480, 640, 3) в uint8, шест плаващи стойности за ставите, езиков низ. Това са 921,600 байта на кадър, 1,843,200 байта за две камери, около 14.7 Mbit, и нито един стек не го компресира с JPEG. Връщащият се пакет е няколко десетки стъпки от 6 плаващи стойности. Вашият ъплоуд решава всичко, а не вашият даунлоуд.

Бюджетът, в който трябва да се впишете

Клиентът GR00T SO-100 е синхронен: той извиква policy.get_action(obs), изпълнява първите action_horizon стъпки от блока при 30 FPS, след което извиква отново. Размерът на блока и хоризонтът са различни числа: ръководството за внедряване на NVIDIA препоръчва размер на блока за действие от 16, поне 32 при комбиниране с chunking в реално време, докато eval_so100.py предоставя хоризонт на изпълнение от 8. Осем стъпки при 30 FPS са 267 ms движение на извикване и всичко останало трябва да се побере в това време.

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

Увеличаването на хоризонта е грубо решение и не е безплатно: ръката действа въз основа на наблюдение, което вече е старо. Принципното решение е chunking в реално време (real-time chunking), което изчислява следващия блок, докато текущият се изпълнява, замразява действията, гарантирани за изпълнение, и довършва останалите; документът за RTC го описва като устойчиво на забавяне на извода без преобучение. Проверете първо какво е състоянието му. NVIDIA отбелязва RTC като експериментално, ниско ниво на моделна примитива, достъпна чрез action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), не е свързано с Gr00tPolicy или пътя сървър-клиент, където options е неизползвано, без тестове и без пример. Чрез сървър за политики получавате асинхронно изпълнение, а не RTC.

Измерете го, преди да му се доверите

Всяко число по-горе е прогноза. Четири команди го превръщат в измерване, което си струва да се изпълни, преди да се ангажира pod-час за задача, която никога нямаше да проработи.

1. 1
   Получете необработеното време за двупосочно пътуване

   Спрямо пода, а не CDN. Следете отклонението толкова внимателно, колкото и средната стойност: трептенето кара ръката да заеква, а не средната латентност.

   bash

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

2. 2
   Измерете връзката за качване, която имате, а не тази, за която плащате

   Качването в жилищни условия обикновено е част от изтеглянето и това е числото в таблицата за честотна лента по-горе.

   bash

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

3. 3
   Прочетете собствения лог за латентност на клиента

   Клиентът на робота lerobot записва латентността от сървър към клиент и времето за десериализация за всеки блок. По маршрут B не се нуждаете от външни инструменти.

   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
   Наблюдавайте изпразването на опашката за действия

   Подайте --debug_visualize_queue_size=True и клиентът ще изчертае размера на опашката по време на изпълнение. Ако многократно достига нула, значи сте извън бюджета: намалете fps, увеличете actions_per_chunk или увеличете chunk_size_threshold, така че наблюденията да се изпращат по-често.

   bash

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

За какво всъщност е добър отдалеченият инференс

Ако отдалечено изпълнение заеква в една и съща точка във всеки епизод, мрежата вероятно не е причината. Политика, която се колебае при един и същ ъгъл на ставата всеки път, обикновено е проблем с данните; вижте страниците за режими на отказ, по-специално политика, която работи само в една настройка и загубата намалява, но политиката не прави нищо.

Да го направите сами срещу да го направите на AY-Robots

Какво струва една отдалечена инференс сесия

Две числа са от значение: почасовата ставка на картата и колко дълго я оставяте да работи. Първото е публикувано; второто изненадва хората.

Тези цени са прочетени от страницата за цени на Runpod на 23 август 2026 г. и спот пазарите се променят. AY-Robots вместо това цитира цяло изпълнение: от 3 до 6 часа при 1.20 до 2.00 USD на час на ниво A100 или H100, около 4 до 12 USD за изпълнение на GR00T или Pi0.5; от 2 до 5 часа при 0.30 до 0.60 USD на час на ниво 24 GB, от 1 до 3 USD за SmolVLA или ACT. Сесията за инференция превъзхожда тренировъчното изпълнение по отношение на разходите само ако я спрете, за което служи idle watchdog. Вижте документацията за таксуване и страницата за цени.

Ако предпочитате мрежата да не е в цикъла

Отдалеченият инференс решава хардуерен проблем и създава проблем с латентността. Понякога по-добрият отговор е политика, която отговаря на хардуера, с който разполагате.

• ACT, приблизително 80 M параметъра и 20 ms на стъпка на действие, минимум 50 епизода, всяка 24 GB карта. При повтаряща се настройка за една задача често превъзхожда отдалечен 3 B модел, защото никога не чака пакет.
• SmolVLA, приблизително 450 M параметъра и 245 ms на стъпка на действие, минимум 30 епизода. Той запазва езиковото кондициониране, което липсва на ACT, а документацията на lerobot го оценява на около 2 GB по време на инференс срещу приблизително 14 GB за PI0.
• ACT vs GR00T N1.7 за половината от компромиса, свързана с точността.

Има и среден път: обучение в облака, оценка локално. изисква 80 GB карта и не се интересува от латентност, така че отдалечено е безспорно. Само цикъла за оценка има ограничение в реално време; и покриват тази половина.

Често задавани въпроси

Накратко

Отдалечен извод за 3 B политика е решен инженерен проблем с нерешен физически проблем. Инженерната част са две команди и SSH тунел. Физиката е, че наблюдение от 1.8 MB трябва да достигне до GPU в друга държава и да се върне, преди ръката да изчерпи действията си. Направете изчисленията, преди да наемете каквото и да е, изберете задача, която толерира остаряло наблюдение, и увеличете хоризонта на изпълнение, вместо да се надявате връзката да се подобри.

Ако все още не сте записали набор от данни, , а е на първо място, и обяснява какво записва рекордерът. Контекстът е в и ; свързва всеки бенчмарк номер с източник.