Запуск вывода GR00T без локального GPU

Raspberry Pi достаточно для управления по последовательной шине и получения кадров с двух USB-камер. Однако его недостаточно для запуска с тремя миллиардами параметров: в README NVIDIA указано, что инференс GR00T N1.7 требует одной GPU с 16 ГБ или более VRAM. Чтобы увидеть, что делает ваш дообученный чекпоинт на манипуляторе без покупки карты, разместите политику на арендованном облачном GPU, оставьте цикл робота на машине с USB-портами и отправляйте наблюдения и фрагменты действий по сети.

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

Почему политика не поместится на машине робота

Две из пяти политик AY-Robots, которые можно обучить, работают на рабочей станции, три — нет. столбец ниже указан для каждого шага действия, и это число, которое конкурирует с вашим временем отклика сети.

Воспринимайте это как решение, а не как мелочь. со скоростью 20 мс на шаг работает на роботе, и вы больше никогда об этом не думаете. со скоростью 485 мс тратит треть секунды, прежде чем пакет покинет ваше здание. и добавляют сторону точности.

Два уже существующих клиент-серверных стека

Isaac-GR00T поставляет сервер запрос-ответ ZeroMQ; lerobot поставляет gRPC-сервер, построенный на асинхронном выводе. Оба принимают контрольную точку. Список поддерживаемых политик lerobot в async_inference/constants.py это act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 и groot; его список роботов — so100_follower, so101_follower, bi_so_follower и omx_follower.

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

Маршрут A: собственный сервер политик 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 или mesh-сеть в стиле 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"

Маршрут B: асинхронный вывод 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 Мбит, и ни один стек не сжимает это в JPEG. Возвращаемый фрагмент — это несколько десятков шагов по 6 плавающих значений. Ваша загрузка решает все, а не ваша скачивание.

Бюджет, в который нужно уложиться

Клиент GR00T SO-100 синхронен: он вызывает policy.get_action(obs), выполняет первые action_horizon шагов чанка со скоростью 30 FPS, затем вызывает снова. Размер чанка и горизонт — это разные числа: руководство по развертыванию NVIDIA рекомендует размер чанка действия 16, не менее 32 при использовании с чанкингом в реальном времени, в то время как eval_so100.py поставляется с горизонтом выполнения 8. Восемь шагов при 30 FPS — это 267 мс движения за вызов, и все остальное должно уложиться в это время.

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

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

Измерьте, прежде чем доверять

Каждое число выше — это предсказание. Четыре команды превращают его в измерение, которое стоит выполнить, прежде чем выделять машинное время на задачу, которая изначально не могла быть выполнена.

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 ГБ, 1–3 USD за SmolVLA или ACT. Сессия инференса превосходит сессию обучения по стоимости только в том случае, если вы ее остановите, для чего и предназначен сторожевой таймер простоя. См. документацию по оплате и страницу с ценами.

Если вы предпочитаете не использовать сеть в цикле

Удаленный вывод решает проблему с оборудованием и создает проблему с задержкой. Иногда лучшим решением является политика, соответствующая имеющемуся у вас оборудованию.

• ACT, примерно 80 млн параметров и 20 мс на шаг действия, минимум 50 эпизодов, любая карта на 24 ГБ. В условиях повторяющейся однозадачной настройки она часто превосходит удаленную модель 3 B, потому что никогда не ждет пакета.
• SmolVLA, примерно 450 млн параметров и 245 мс на шаг действия, минимум 30 эпизодов. Она сохраняет языковое обусловливание, которого не хватает ACT, а документация lerobot указывает на потребление около 2 ГБ во время вывода против примерно 14 ГБ для PI0.
• ACT vs GR00T N1.7 для половины компромисса, связанной с точностью.

Существует также промежуточный путь: обучение в облаке, оценка локально. требует карту на 80 ГБ и не заботится о задержке, поэтому удаленно является бесспорным. Только цикл оценки имеет ограничение реального времени; и охватывают эту половину.

Часто задаваемые вопросы

Краткая версия

Удаленный инференс для 3 B политики — это решенная инженерная задача с нерешенной физической проблемой. Инженерная часть — это две команды и SSH-туннель. Физическая часть заключается в том, что наблюдение размером 1.8 MB должно достичь GPU в другой стране и вернуться до того, как у манипулятора закончатся действия. Выполните расчеты, прежде чем что-либо арендовать, выберите задачу, которая допускает устаревшее наблюдение, и увеличьте горизонт выполнения, вместо того чтобы надеяться на улучшение связи.

Если вы еще не записали набор данных, запишите свой первый набор данных и руководство по настройке SO-100 идут первыми, а формат набора данных LeRobot объясняет, что записывает рекордер. Справочная информация находится в моделях зрения-языка-действия и работе с политиками сопоставления потоков; запись арены связывает каждое число бенчмарка с источником.