Exécuter l'inférence GR00T sans GPU local

Un Raspberry Pi est suffisant pour piloter un via un bus série et récupérer des images de deux caméras USB. Il n'est pas suffisant pour exécuter un de trois milliards de paramètres : le README de NVIDIA indique que l'inférence de GR00T N1.7 nécessite un GPU avec 16 Go ou plus de VRAM. Pour voir ce que votre checkpoint affiné fait sur le bras sans acheter de carte, placez la politique sur un GPU cloud loué, maintenez la boucle du robot sur la machine avec les ports USB, et envoyez les observations et les fragments d'action sur le réseau.

Cela fonctionne, ce n'est pas gratuit, et le coût n'est pas réparti uniformément entre les tâches. Ci-dessous : le serveur de politique de NVIDIA, la pile asynchrone de lerobot, l'arithmétique qui indique à l'avance si votre liaison montante est suffisamment rapide, et la route de la plateforme. Tout cela a été vérifié par rapport à la branche principale d'Isaac-GR00T (N1.7 GA) et à lerobot 0.6.1 le 23 août 2026.

Pourquoi la politique ne tiendra pas sur la machine du robot

Deux des cinq politiques qu'AY-Robots peut entraîner s'exécutent sur une carte de station de travail, trois non. La colonne ci-dessous est par étape d'action, et c'est ce nombre qui est en concurrence avec votre temps d'aller-retour réseau.

Considérez cela comme une décision, pas comme une anecdote. à 20 ms par étape s'exécute sur la machine du robot et vous n'y pensez plus. à 485 ms a passé un tiers de seconde avant qu'un paquet ne quitte votre bâtiment. La et ajoutent le côté précision.

Les deux piles client-serveur qui existent déjà

Isaac-GR00T fournit un serveur ZeroMQ de type requête-réponse ; lerobot fournit un serveur gRPC construit autour de l'inférence asynchrone. Les deux acceptent un GR00T point de contrôle. La liste des politiques prises en charge par lerobot dans async_inference/constants.py est act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 et groot ; sa liste de robots est so100_follower, so101_follower, bi_so_follower et omx_follower.

La ligne de sérialisation est plus importante qu'il n'y paraît. Le MsgSerializer de GR00T refuse les charges utiles ndarray de type objet dans les deux sens, car msgpack_numpy les transmettrait autrement à pickle. lerobot utilise plutôt pickle : policy_server.py appelle pickle.loads sur les données de requête, robot_client.py utilise pickle pour l'observation qu'il envoie. Défendable sur un LAN de confiance, indéfendable une fois que le port est accessible depuis Internet.

Route A : Serveur de politique GR00T propre à NVIDIA

C'est le chemin documenté par NVIDIA pour le matériel SO-100 et SO-101, et celui à utiliser si votre checkpoint provient de examples/finetune.sh avec --embodiment-tag NEW_EMBODIMENT. Les étapes ajoutent ce que le README en amont omet : acheminer le port vers le robot sans l'exposer à tout le monde.

1. 1
   Installer GR00T sur la machine GPU louée

   Les sous-modules sont requis, et git-lfs doit exister avant le clonage, sinon les fichiers parquet dans demo_data arrivent comme des pointeurs. flash-attn et TensorRT sont inclus dans l'installation par défaut. Le piège sur une nouvelle image de pod : torchcodec 0.8.0 est le seul backend vidéo pris en charge et ne charge que FFmpeg 4 à 7. Ubuntu 25.10 et 26.04 livrent FFmpeg 8, donc GR00T échoue avec Could not load libtorchcodec. Installez un FFmpeg inférieur à 8 et placez ses bibliothèques sur 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
   S'authentifier auprès du backbone restreint

   Chaque checkpoint GR00T N1.7, y compris votre propre fine-tune, charge le modèle restreint nvidia/Cosmos-Reason2-2B lors de la première utilisation. Demandez l'accès sur la page du modèle et connectez-vous sur le pod, sinon le chargement échouera avec une GatedRepoError.

   bash

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

3. 3
   Démarrer le serveur de politique

   Pointez --model-path vers votre répertoire de checkpoint ; sur ce chemin, le serveur ignore --modality-config-path, qui n'est lu que sur le chemin de relecture. Omettez --model-path et passez plutôt --dataset-path plus --execution-horizon pour une ReplayPolicy qui rejoue les actions enregistrées, le moyen le moins cher de prouver que le câblage fonctionne.

   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
   Tunneliser le port 5555 vers la machine robot

   Lie au loopback, comme ci-dessus, et transportez le port via SSH ou un maillage de type WireGuard. Cela fournit le chiffrement et l'authentification que la socket ZeroMQ n'offre pas, pour environ une milliseconde.

   bash

   # sur la machine robot
   ssh -N -L 5555:127.0.0.1:5555 root@<pod-host> -p <pod-ssh-port>
   
   # vérification que quelque chose répond
   nc -vz 127.0.0.1 5555

5. 5
   Exécuter le client robot à côté des servomoteurs

   Le client a besoin de son propre environnement uv : il veut les pilotes de robot de lerobot, pas la pile d'entraînement. eval_so100.py importe so100_follower, so101_follower et koch_follower, alors passez le --robot.type correspondant à votre bras (le README en amont utilise so101_follower). Les clés de caméra doivent correspondre à l'entraînement : l'adaptateur lit exactement front et wrist, et les échanger montre à la politique la mauvaise vue.

   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"

Route B : inférence asynchrone lerobot

lerobot résout un problème différent. Au lieu de bloquer le robot pendant que le modèle réfléchit, le client continue de traiter la file d'attente qu'il possède déjà pendant que le serveur calcule le prochain morceau. C'est le découpage d'actions poussé plus loin, la pile asynchrone introduite avec SmolVLA. Cela fonctionne aussi avec un point de contrôle 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

Le serveur démarre vide : il ne sait pas quelle politique il sert avant que le premier handshake du client ne le lui indique, ce qui est pratique sur un pod loué. Les deux paramètres qui décident si le bras se déplace en douceur sont actions_per_chunk et chunk_size_threshold (la documentation lerobot appelle le second g, d'après l'article SmolVLA), et les valeurs documentées et les valeurs livrées ne concordent pas.

L'arithmétique qui détermine si votre liaison est suffisamment rapide

Les gens sautent cette étape et passent ensuite une journée sur . Cela prend deux minutes et c'est presque toujours décisif.

Le dictionnaire d'observation commenté dans le fichier eval_so100.py de NVIDIA indique ce qui transite sur le réseau : deux tableaux de forme (480, 640, 3) en uint8, six flottants d'articulation, une chaîne de caractères de langue. Cela représente 921 600 octets par image, 1 843 200 octets pour deux caméras, soit environ 14,7 Mbit, et aucune pile ne le compresse en JPEG. Le bloc de données renvoyé correspond à quelques dizaines d'étapes de 6 flottants. Votre débit d'envoi décide de tout, pas votre débit de téléchargement.

Le budget dans lequel vous devez vous inscrire

Le client GR00T SO-100 est synchrone : il appelle policy.get_action(obs), exécute les premières action_horizon étapes du chunk à 30 FPS, puis rappelle. La taille du chunk et l'horizon sont des nombres différents : le guide de déploiement de NVIDIA recommande une taille de chunk d'action de 16, au moins 32 lorsqu'elle est combinée avec le chunking en temps réel, tandis que eval_so100.py fournit un horizon d'exécution de 8. Huit étapes à 30 FPS représentent 267 ms de mouvement par appel, et tout le reste doit s'y intégrer.

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

Augmenter l'horizon est une solution grossière et non sans coût : le bras agit sur une observation qui est désormais ancienne. La solution de principe est le chunking en temps réel (RTC), qui calcule le chunk suivant pendant que le chunk actuel s'exécute, fige les actions garanties d'être exécutées et complète le reste ; l'article sur le RTC le décrit comme robuste aux délais d'inférence sans réentraînement. Vérifiez d'abord où en est cette fonctionnalité. NVIDIA marque le RTC comme expérimental, une primitive de modèle de bas niveau accessible via action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), non intégrée à Gr00tPolicy ou au chemin serveur-client, où options est inutilisé, sans tests ni exemple. Avec un serveur de politique, vous obtenez une exécution asynchrone, pas le RTC.

Mesurez-le avant de lui faire confiance

Chaque nombre ci-dessus est une prédiction. Quatre commandes le transforment en une mesure, qu'il est utile d'exécuter avant d'allouer une heure de pod à une tâche qui n'aurait jamais fonctionné.

1. 1
   Obtenez le temps d'aller-retour brut

   Contre le pod, pas un CDN. Surveillez l'écart aussi attentivement que la moyenne : la gigue fait bégayer un bras, pas la latence moyenne.

   bash

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

2. 2
   Mesurez la liaison montante que vous avez, pas celle que vous payez

   Le téléchargement résidentiel est généralement une fraction du téléchargement, et c'est le nombre dans le tableau de bande passante ci-dessus.

   bash

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

3. 3
   Lisez le journal de latence du client

   Le client robot lerobot enregistre la latence serveur-client et le temps de désérialisation pour chaque bloc. Sur la route B, vous n'avez pas besoin d'outils externes.

   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
   Surveillez la vidange de la file d'attente d'actions

   Passez --debug_visualize_queue_size=True et le client trace la taille de la file d'attente à l'exécution. S'il atteint zéro à plusieurs reprises, vous êtes hors budget : réduisez les ips, augmentez actions_per_chunk, ou augmentez chunk_size_threshold afin que les observations soient envoyées plus souvent.

   bash

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

À quoi sert réellement l'inférence à distance

Si une exécution à distance saccade au même point dans chaque épisode, le réseau n'est probablement pas la cause. Une politique qui hésite au même angle articulaire à chaque fois est généralement un problème de données ; voir les pages sur les modes de défaillance, en particulier une politique qui ne fonctionne que dans une seule configuration et la perte diminue mais la politique ne fait rien.

Le faire soi-même ou le faire sur AY-Robots

Ce que coûte une session d'inférence à distance

Deux chiffres comptent : le tarif horaire de la carte et la durée pendant laquelle vous la laissez fonctionner. Le premier est publié ; le second surprend les gens.

Ces tarifs ont été relevés sur la page de tarification de Runpod le 23 août 2026, et les marchés spot sont fluctuants. AY-Robots propose plutôt une exécution complète : 3 à 6 heures à 1.20 à 2.00 USD par heure sur le niveau A100 ou H100, environ 4 à 12 USD pour une exécution GR00T ou Pi0.5 ; 2 à 5 heures à 0.30 à 0.60 USD par heure sur le niveau 24 Go, 1 à 3 USD pour SmolVLA ou ACT. Une session d'inférence n'est plus avantageuse qu'une exécution d'entraînement en termes de coût que si vous l'arrêtez, ce à quoi sert le chien de garde d'inactivité. Consultez les documents de facturation et la page de tarification.

Si vous préférez ne pas avoir le réseau dans la boucle

L'inférence à distance résout un problème matériel et en crée un de latence. Parfois, la meilleure réponse est une politique qui correspond au matériel dont vous disposez.

• ACT, environ 80 M paramètres et 20 ms par étape d'action, 50 épisodes minimum, toute carte de 24 Go. Dans une configuration répétitive à tâche unique, il surpasse fréquemment un modèle distant de 3 B, car il n'attend jamais de paquet.
• SmolVLA, environ 450 M paramètres et 245 ms par étape d'action, 30 épisodes minimum. Il conserve le conditionnement linguistique qui manque à ACT, et la documentation de lerobot l'estime à environ 2 Go au moment de l'inférence contre environ 14 Go pour PI0.
• ACT vs GR00T N1.7 pour la moitié précision du compromis.

Il existe également une voie médiane : entraîner dans le cloud, évaluer localement. Réglage fin nécessite la carte de 80 Go et ne se soucie pas de la latence, donc l'entraînement de GR00T N1.7 sur un SO-100 à distance est incontestable. Seule la boucle d'évaluation a une contrainte en temps réel ; les documents de formation et la matrice modèle-et-bras couvrent cette moitié.

Questions fréquemment posées

En bref

L'inférence à distance pour un modèle de 3 B politique est un problème d'ingénierie résolu auquel s'ajoute un problème de physique non résolu. L'ingénierie se résume à deux commandes et un tunnel SSH. La physique veut qu'une observation de 1,8 Mo doive atteindre un GPU dans un autre pays et revenir avant que le bras ne manque d'actions. Faites le calcul avant de louer quoi que ce soit, choisissez une tâche qui tolère une observation périmée, et augmentez l'horizon d'exécution plutôt que d'espérer que la liaison s'améliore.

Si vous n'avez pas encore enregistré de jeu de données, enregistrez votre premier jeu de données et le guide de configuration du SO-100 viennent en premier, et l'entrée sur le format de jeu de données LeRobot explique ce que l'enregistreur écrit. Le contexte se trouve dans les modèles vision-langage-action et les travaux sur les politiques de correspondance de flux; l'entrée de l' arène lie chaque chiffre de benchmark à une source.