Ejecutar inferencia GR00T sin una GPU local

Una Raspberry Pi es suficiente para controlar un a través de un bus serie y extraer fotogramas de dos cámaras USB. No es suficiente para ejecutar un de tres mil millones de parámetros: el README de NVIDIA sitúa la inferencia de GR00T N1.7 en una GPU con 16 GB o más de VRAM. Para ver lo que hace su punto de control ajustado en el brazo sin comprar una tarjeta, coloque la política en una GPU en la nube alquilada, mantenga el bucle del robot en la máquina con los puertos USB y envíe las observaciones y los fragmentos de acción a través de la red.

Funciona, no es gratis y el precio no se distribuye uniformemente entre las tareas. A continuación: el propio servidor de políticas de NVIDIA, la pila asíncrona de lerobot, la aritmética que indica de antemano si su enlace ascendente es lo suficientemente rápido y la ruta de la plataforma. Todo ello comprobado con la rama principal de Isaac-GR00T (N1.7 GA) y lerobot 0.6.1 el 23 de agosto de 2026.

Por qué la política no cabrá en la máquina del robot

Dos de las cinco políticas que AY-Robots puede entrenar se ejecutan en una tarjeta de estación de trabajo, tres no. La columna siguiente es por paso de acción, y ese es el número que compite con el tiempo de ida y vuelta de su red.

Léalo como una decisión, no como una trivialidad. a 20 ms por paso se ejecuta en la máquina del robot y nunca más tendrá que preocuparse por ello. a 485 ms ha consumido un tercio de segundo antes de que un paquete salga de su edificio. La y añaden el lado de la precisión.

Las dos pilas cliente-servidor que ya existen

Isaac-GR00T incluye un servidor ZeroMQ de solicitud-respuesta; lerobot incluye un servidor gRPC construido alrededor de inferencia asíncrona. Ambos aceptan un GR00T checkpoint. La lista de políticas soportadas por lerobot en async_inference/constants.py es act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 y groot; su lista de robots es so100_follower, so101_follower, bi_so_follower y omx_follower.

La fila de serialización importa más de lo que parece. El MsgSerializer de GR00T rechaza cargas útiles de ndarray de tipo de objeto en ambas direcciones, porque msgpack_numpy de lo contrario las entregaría a pickle. lerobot usa pickle en su lugar: policy_server.py llama a pickle.loads en los datos de la solicitud, robot_client.py serializa la observación que envía. Defendible en una LAN de confianza, indefendible una vez que el puerto es accesible desde internet.

Ruta A: Servidor de políticas GR00T propio de NVIDIA

Esta es la ruta que NVIDIA documenta para el hardware SO-100 y SO-101, y la que debe usar si su punto de control salió de examples/finetune.sh con --embodiment-tag NEW_EMBODIMENT. Los pasos añaden lo que el README original omite: llevar el puerto al robot sin exponerlo a todos los demás.

1. 1
   Instalar GR00T en la caja GPU alquilada

   Los submódulos son obligatorios, y git-lfs debe existir antes de la clonación o los archivos parquet en demo_data llegarán como punteros. flash-attn y TensorRT vienen con la instalación predeterminada. La trampa en una imagen de pod nueva: torchcodec 0.8.0 es el único backend de video compatible y solo carga FFmpeg 4 a 7. Ubuntu 25.10 y 26.04 incluyen FFmpeg 8, por lo que GR00T falla con Could not load libtorchcodec. Instale un FFmpeg inferior a 8 y coloque sus bibliotecas en 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
   Autenticarse contra el backbone restringido

   Cada punto de control de GR00T N1.7, incluyendo su propio ajuste fino, carga el modelo restringido nvidia/Cosmos-Reason2-2B en el primer uso. Solicite acceso en la página del modelo e inicie sesión en el pod, o la carga fallará con un GatedRepoError.

   bash

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

3. 3
   Iniciar el servidor de políticas

   Apunte --model-path a su directorio de punto de control; en esa ruta el servidor ignora --modality-config-path, que solo se lee en la ruta de reproducción. Omita --model-path y pase --dataset-path más --execution-horizon en su lugar para una ReplayPolicy que reproduce acciones grabadas, la forma más económica de probar que el cableado 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
   Tunelizar el puerto 5555 a la máquina del robot

   Enlace a loopback, como se indicó anteriormente, y transporte el puerto a través de SSH o una malla tipo WireGuard. Eso proporciona el cifrado y la autenticación que el socket ZeroMQ no ofrece, por aproximadamente un milisegundo.

   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
   Ejecutar el cliente del robot junto a los servos

   El cliente necesita su propio entorno uv: quiere los controladores de robot de lerobot, no la pila de entrenamiento. eval_so100.py importa so100_follower, so101_follower y koch_follower, así que pase el --robot.type que coincida con su brazo (el README original usa so101_follower). Las claves de la cámara deben coincidir con el entrenamiento: el adaptador lee exactamente front y wrist, e intercambiarlas muestra a la política la vista incorrecta.

   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: inferencia asíncrona con lerobot

lerobot resuelve un problema diferente. En lugar de bloquear el robot mientras el modelo piensa, el cliente sigue avanzando a través de la cola que ya tiene mientras el servidor calcula el siguiente fragmento. Esto es fragmentación de acciones, llevado más allá, la pila asíncrona introducida con SmolVLA. También funciona con un checkpoint de 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

El servidor arranca vacío: no sabe qué política sirve hasta que el primer handshake del cliente se lo indica, lo cual es conveniente en un pod alquilado. Los dos parámetros que deciden si el brazo se mueve suavemente son actions_per_chunk y chunk_size_threshold (la documentación de lerobot llama al segundo g, en referencia al artículo de SmolVLA), y los valores documentados y los valores implementados no coinciden.

La aritmética que decide si tu enlace es lo suficientemente rápido

La gente se salta esto y luego pasa un día con . Lleva dos minutos y casi siempre es decisivo.

El diccionario de observación comentado en el eval_so100.py de NVIDIA dice lo que se transmite: dos arrays de forma (480, 640, 3) en uint8, seis floats de articulación, una cadena de idioma. Eso son 921.600 bytes por fotograma, 1.843.200 bytes para dos cámaras, aproximadamente 14,7 Mbit, y ninguna pila lo comprime con JPEG. El fragmento que regresa son unas pocas docenas de pasos de 6 floats. Tu subida lo decide todo, no tu descarga.

El presupuesto en el que debes encajar

El cliente GR00T SO-100 es síncrono: llama a policy.get_action(obs), ejecuta los primeros action_horizon pasos del fragmento a 30 FPS, luego vuelve a llamar. El tamaño del fragmento y el horizonte son números diferentes: la guía de despliegue de NVIDIA recomienda un tamaño de fragmento de acción de 16, al menos 32 cuando se combina con el chunking en tiempo real, mientras que eval_so100.py incluye un horizonte de ejecución de 8. Ocho pasos a 30 FPS son 267 ms de movimiento por llamada, y todo lo demás tiene que encajar dentro de eso.

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 el horizonte es la solución burda y no gratuita: el brazo actúa sobre una observación que ahora es antigua. La solución basada en principios es el chunking en tiempo real (RTC), que calcula el siguiente fragmento mientras se ejecuta el actual, congela las acciones garantizadas para su ejecución y rellena el resto; el artículo de RTC lo reporta como robusto al retraso de inferencia sin necesidad de reentrenamiento. Verifique primero dónde se encuentra eso. NVIDIA marca RTC como experimental, una primitiva de modelo de bajo nivel accesible a través de action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), no conectado a Gr00tPolicy ni a la ruta servidor-cliente, donde options no se utiliza, sin pruebas y sin ejemplo. Sobre un servidor de políticas se obtiene ejecución asíncrona, no RTC.

Mídelo antes de confiar en él

Cada número anterior es una predicción. Cuatro comandos lo convierten en una medición, que vale la pena ejecutar antes de dedicar una hora de pod a una tarea que nunca iba a funcionar.

1. 1
   Obtén el tiempo de ida y vuelta sin procesar

   Contra el pod, no una CDN. Observa la desviación tan de cerca como la media: la fluctuación (jitter) hace que un brazo tartamudee, no la latencia promedio.

   bash

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

2. 2
   Mide el uplink que tienes, no el que pagas

   La subida residencial suele ser una fracción de la descarga, y es el número en la tabla de ancho de banda anterior.

   bash

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

3. 3
   Lee el registro de latencia del propio cliente

   El cliente de robot lerobot registra la latencia de servidor a cliente y el tiempo de deserialización para cada fragmento. En la ruta B no necesitas herramientas 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
   Observa cómo se vacía la cola de acciones

   Pasa --debug_visualize_queue_size=True y el cliente grafica el tamaño de la cola en tiempo de ejecución. Si repetidamente llega a cero, te has quedado sin presupuesto: baja los fps, aumenta actions_per_chunk, o aumenta chunk_size_threshold para que las observaciones se envíen con más frecuencia.

   bash

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

¿Para qué sirve realmente la inferencia remota?

Si una ejecución remota tartamudea en el mismo punto en cada episodio, la red probablemente no sea la causa. Una política que duda en el mismo ángulo de articulación cada vez suele ser un problema de datos; consulta las páginas de modos de fallo, en particular una política que solo funciona en una configuración y la pérdida disminuye pero la política no hace nada.

Hacerlo tú mismo vs hacerlo en AY-Robots

Cuánto cuesta una sesión de inferencia remota

Dos números importan: la tarifa por hora de la tarjeta y cuánto tiempo la dejas funcionando. El primero se publica; el segundo sorprende a la gente.

Esas tarifas se leyeron de la página de precios de Runpod el 23 de agosto de 2026, y los mercados spot son volátiles. AY-Robots en su lugar cotiza una ejecución completa: de 3 a 6 horas a 1.20 a 2.00 USD por hora en el nivel A100 o H100, aproximadamente de 4 a 12 USD para una ejecución de GR00T o Pi0.5; de 2 a 5 horas a 0.30 a 0.60 USD por hora en el nivel de 24 GB, de 1 a 3 USD para SmolVLA o ACT. Una sesión de inferencia supera a una ejecución de entrenamiento en costo solo si la detienes, para lo cual sirve el 'idle watchdog'. Consulta los y la .

Si prefieres no tener la red en el bucle

La inferencia remota resuelve un problema de hardware y crea un problema de latencia. A veces, la mejor respuesta es una política que se adapte al hardware que tienes.

• ACT, aproximadamente 80 M parámetros y 20 ms por paso de acción, 50 episodios mínimo, cualquier tarjeta de 24 GB. En una configuración repetitiva de una sola tarea, a menudo supera a un modelo remoto de 3 B, porque nunca espera un paquete.
• SmolVLA, aproximadamente 450 M parámetros y 245 ms por paso de acción, 30 episodios mínimo. Mantiene el condicionamiento de lenguaje del que carece ACT, y la documentación de lerobot lo sitúa en aproximadamente 2 GB en tiempo de inferencia frente a aproximadamente 14 GB para PI0.
• ACT vs GR00T N1.7 para la mitad de precisión del compromiso.

También hay un camino intermedio: entrenar en la nube, evaluar localmente. Ajuste fino necesita la tarjeta de 80 GB y no le importa la latencia, por lo que entrenar GR00T N1.7 en un SO-100 de forma remota es indiscutible. Solo el bucle de evaluación tiene una restricción de tiempo real; la documentación de entrenamiento y la matriz de modelos y brazos cubren esa mitad.

Preguntas frecuentes

La versión corta

La inferencia remota para una política es un problema de ingeniería resuelto con un problema de física sin resolver adjunto. La ingeniería son dos comandos y un túnel SSH. La física es que una observación de 1.8 MB tiene que llegar a una GPU en otro país y regresar antes de que el brazo se quede sin acciones. Haz los cálculos antes de alquilar cualquier cosa, elige una tarea que tolere una observación obsoleta y eleva el horizonte de ejecución en lugar de esperar que el enlace mejore.

Si aún no has grabado un conjunto de datos, graba tu primer conjunto de datos y la guía de configuración del SO-100 son lo primero, y la entrada del formato de conjunto de datos LeRobot explica lo que escribe el grabador. El contexto se encuentra en los modelos de visión-lenguaje-acción y el trabajo sobre políticas de coincidencia de flujo; la entrada de la arena enlaza cada número de referencia a una fuente.