Executar Inferência GR00T Sem uma GPU Local

Uma Raspberry Pi é suficiente para controlar um através de um barramento serial e extrair quadros de duas câmeras USB. Não é suficiente para executar um modelo de três bilhões de parâmetros : o README da NVIDIA indica a inferência do GR00T N1.7 em uma GPU com 16 GB ou mais de VRAM. Para ver o que seu checkpoint faz no braço robótico sem comprar uma placa, coloque a política em uma GPU de nuvem alugada, mantenha o loop do robô na máquina com as portas USB e envie observações e blocos de ação pela rede.

Funciona, não é gratuito, e o preço não é distribuído uniformemente entre as tarefas. Abaixo: o próprio servidor de políticas da NVIDIA, a pilha assíncrona do lerobot, a aritmética que diz antecipadamente se seu uplink é rápido o suficiente e a rota da plataforma. Tudo isso verificado em relação ao branch principal do Isaac-GR00T (N1.7 GA) e lerobot 0.6.1 em 23 de agosto de 2026.

Por que a política não caberá na máquina do robô

Duas das cinco políticas que a AY-Robots pode treinar rodam em uma placa de workstation, três não. A coluna abaixo é por etapa de ação, e esse é o número que compete com o tempo de ida e volta da sua rede.

Leia isso como uma decisão, não como curiosidade. a 20 ms por etapa, roda na máquina do robô e você nunca mais pensa nisso. a 485 ms, gastou um terço de segundo antes que um pacote saia do seu edifício. A e adicionam o lado da precisão.

As duas pilhas cliente-servidor que já existem

Isaac-GR00T fornece um servidor ZeroMQ de requisição-resposta; lerobot fornece um servidor gRPC construído em torno de inferência assíncrona. Ambos aceitam um GR00T checkpoint. A lista de políticas suportadas pelo lerobot em async_inference/constants.py é act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 e groot; sua lista de robôs é so100_follower, so101_follower, bi_so_follower e omx_follower.

A linha de serialização importa mais do que parece. O GR00T's MsgSerializer recusa payloads ndarray de tipo de objeto em ambas as direções, porque o msgpack_numpy os passaria para o pickle. O lerobot usa pickle em vez disso: policy_server.py chama pickle.loads nos dados da requisição, robot_client.py serializa a observação que envia. Defensável em uma LAN confiável, indefensável uma vez que a porta é acessível pela internet.

Rota A: Servidor de política GR00T próprio da NVIDIA

Este é o caminho que a NVIDIA documenta para o hardware SO-100 e SO-101, e o que deve ser usado se o seu checkpoint veio de examples/finetune.sh com --embodiment-tag NEW_EMBODIMENT. Os passos adicionam o que o README original omite: levar a porta ao robô sem expô-la a todos os outros.

1. 1
   Instalar o GR00T na máquina GPU alugada

   Submódulos são necessários, e o git-lfs deve existir antes do clone ou os arquivos parquet em demo_data chegarão como ponteiros. flash-attn e TensorRT vêm com a instalação padrão. A armadilha em uma imagem de pod nova: torchcodec 0.8.0 é o único backend de vídeo suportado e carrega apenas FFmpeg 4 a 7. Ubuntu 25.10 e 26.04 vêm com FFmpeg 8, então o GR00T falha com Could not load libtorchcodec. Instale um FFmpeg abaixo de 8 e coloque suas bibliotecas em 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
   Autenticar-se contra o backbone restrito

   Cada checkpoint GR00T N1.7, incluindo o seu próprio fine-tune, carrega o modelo restrito nvidia/Cosmos-Reason2-2B no primeiro uso. Solicite acesso na página do modelo e faça login no pod, ou o carregamento falhará com um GatedRepoError.

   bash

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

3. 3
   Iniciar o servidor de política

   Aponte --model-path para o seu diretório de checkpoint; nesse caminho, o servidor ignora --modality-config-path, que é lido apenas no caminho de replay. Omita --model-path e passe --dataset-path mais --execution-horizon em vez disso para uma ReplayPolicy que reproduz ações gravadas, a maneira mais barata de provar que a fiação funciona.

   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
   Tunelar a porta 5555 para a máquina do robô

   Vincule ao loopback, como acima, e transporte a porta via SSH ou uma malha estilo WireGuard. Isso fornece a criptografia e autenticação que o socket ZeroMQ não oferece, por cerca de um milissegundo.

   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
   Executar o cliente do robô ao lado dos servos

   O cliente precisa de seu próprio ambiente uv: ele quer os drivers de robô do lerobot, não a pilha de treinamento. eval_so100.py importa so100_follower, so101_follower e koch_follower, então passe o --robot.type que corresponde ao seu braço (o README original usa so101_follower). As chaves da câmera devem corresponder ao treinamento: o adaptador lê exatamente front e wrist, e trocá-las mostra à política a visão errada.

   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"

Rota B: inferência assíncrona com lerobot

lerobot resolve um problema diferente. Em vez de bloquear o robô enquanto o modelo pensa, o cliente continua processando a fila que já possui enquanto o servidor calcula o próximo chunk. Isso é chunking de ações levado adiante, a pilha assíncrona introduzida com SmolVLA. Funciona também com um checkpoint 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

O servidor inicia vazio: ele não sabe qual política serve até que o primeiro handshake do cliente o informe, o que é conveniente em um pod alugado. Os dois parâmetros que decidem se o braço se move suavemente são actions_per_chunk e chunk_size_threshold (a documentação do lerobot chama o segundo de g, em referência ao artigo SmolVLA), e os valores documentados e os valores fornecidos não concordam.

A aritmética que decide se sua conexão é rápida o suficiente

As pessoas pulam esta parte e depois passam um dia em . Leva dois minutos e é quase sempre decisivo.

O dicionário de observação comentado em eval_so100.py da NVIDIA diz o que vai para o fio: dois arrays de forma (480, 640, 3) em uint8, seis floats de junta, uma string de linguagem. Isso é 921.600 bytes por quadro, 1.843.200 bytes para duas câmeras, cerca de 14.7 Mbit, e nenhuma pilha o compacta em JPEG. O bloco que retorna são algumas dezenas de passos de 6 floats. Seu upload decide tudo, não seu download.

O orçamento que você precisa encaixar

O cliente GR00T SO-100 é síncrono: ele chama policy.get_action(obs), executa os primeiros action_horizon passos do chunk a 30 FPS, então chama novamente. O tamanho do chunk e o horizonte são números diferentes: o guia de implantação da NVIDIA recomenda um tamanho de chunk de ação de 16, pelo menos 32 quando combinado com chunking em tempo real, enquanto eval_so100.py entrega um horizonte de execução de 8. Oito passos a 30 FPS são 267 ms de movimento por chamada, e todo o resto tem que caber nisso.

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

Aumentar o horizonte é a solução bruta e não é gratuita: o braço age com base em uma observação que agora está antiga. A solução baseada em princípios é o chunking em tempo real (RTC), que calcula o próximo chunk enquanto o atual está em execução, congela as ações garantidas para serem executadas e preenche o restante; o artigo sobre RTC relata que é robusto a atrasos de inferência sem necessidade de retreinamento. Verifique primeiro a situação disso. A NVIDIA marca o RTC como experimental, uma primitiva de modelo de baixo nível acessível através de action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), não conectado ao Gr00tPolicy ou ao caminho servidor-cliente, onde options não é usado, sem testes e sem exemplo. Através de um servidor de política, você obtém execução assíncrona, não RTC.

Meça antes de confiar

Cada número acima é uma previsão. Quatro comandos o transformam em uma medição, que vale a pena executar antes de dedicar uma hora de pod a uma tarefa que nunca funcionaria.

1. 1
   Obtenha o tempo de ida e volta bruto

   Contra o pod, não uma CDN. Observe o desvio tão de perto quanto a média: o jitter faz um braço gaguejar, não a latência média.

   bash

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

2. 2
   Meça o uplink que você tem, não o que você paga

   O upload residencial é geralmente uma fração do download, e é o número na tabela de largura de banda acima.

   bash

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

3. 3
   Leia o log de latência do próprio cliente

   O cliente de robô lerobot registra a latência do servidor para o cliente e o tempo de desserialização para cada chunk. Na rota B, você não precisa de ferramentas externas.

   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
   Observe a fila de ações esvaziar

   Passe --debug_visualize_queue_size=True e o cliente plotará o tamanho da fila em tempo de execução. Se ele atingir zero repetidamente, você está sem orçamento: diminua o fps, aumente actions_per_chunk ou aumente chunk_size_threshold para que as observações sejam enviadas com mais frequência.

   bash

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

Para que a inferência remota realmente serve

Se uma execução remota engasga no mesmo ponto em cada episódio, a rede provavelmente não é a causa. Uma política que hesita no mesmo ângulo de junta toda vez é geralmente um problema de dados; veja as páginas de modos de falha, em particular uma política que só funciona em uma configuração e a perda diminui, mas a política não faz nada.

Fazer você mesmo vs fazer na AY-Robots

Quanto custa uma sessão de inferência remota

Dois números importam: a taxa horária da placa e por quanto tempo você a deixa funcionando. O primeiro é publicado; o segundo surpreende as pessoas.

Essas taxas foram lidas na página de preços da Runpod em 23 de agosto de 2026, e os mercados spot são voláteis. A AY-Robots, em vez disso, cota uma execução completa: 3 a 6 horas a 1,20 a 2,00 USD por hora no nível A100 ou H100, cerca de 4 a 12 USD para uma execução GR00T ou Pi0.5; 2 a 5 horas a 0,30 a 0,60 USD por hora no nível de 24 GB, 1 a 3 USD para SmolVLA ou ACT. Uma sessão de inferência supera uma execução de treinamento em custo apenas se você a interromper, para o que serve o watchdog de inatividade. Veja os documentos de faturamento e a página de preços.

Se você preferir não ter a rede no circuito

A inferência remota resolve um problema de hardware e cria um problema de latência. Às vezes, a melhor resposta é uma política que se adapta ao hardware que você possui.

• ACT, aproximadamente 80 M parâmetros e 20 ms por passo de ação, 50 episódios mínimo, qualquer placa de 24 GB. Em uma configuração de tarefa única repetitiva, frequentemente supera um modelo remoto de 3 B, porque nunca espera por um pacote.
• SmolVLA, aproximadamente 450 M parâmetros e 245 ms por passo de ação, 30 episódios mínimo. Mantém o condicionamento de linguagem que falta ao ACT, e a documentação do lerobot o coloca em cerca de 2 GB no tempo de inferência contra aproximadamente 14 GB para PI0.
• ACT vs GR00T N1.7 para a metade da precisão da troca.

Há também um caminho intermediário: treinar na nuvem, avaliar localmente. Fine-tuning precisa da placa de 80 GB e não se importa com a latência, então treinar GR00T N1.7 em um SO-100 remotamente é incontestável. Apenas o loop de avaliação tem uma restrição de tempo real; a documentação de treinamento e a matriz de modelo e braço cobrem essa metade.

Perguntas frequentes

A versão resumida

A inferência remota para uma política de 3 B política é um problema de engenharia resolvido com um problema de física não resolvido anexado. A engenharia são dois comandos e um túnel SSH. A física é que uma observação de 1.8 MB tem que chegar a uma GPU noutro país e voltar antes que o braço fique sem ações. Faça as contas antes de alugar qualquer coisa, escolha uma tarefa que tolere uma observação desatualizada e aumente o horizonte de execução em vez de esperar que a ligação melhore.

Se ainda não gravou um conjunto de dados, grave seu primeiro conjunto de dados e o guia de configuração do SO-100 vêm primeiro, e a entrada do formato de conjunto de dados LeRobot explica o que o gravador escreve. O contexto está em modelos de visão-linguagem-ação e o trabalho de política de flow-matching; a entrada da arena liga cada número de benchmark a uma fonte.