Eseguire l'Inferenza GR00T Senza una GPU Locale

Un Raspberry Pi è sufficiente per pilotare un tramite un bus seriale e acquisire frame da due telecamere USB. Non è sufficiente per eseguire un modello con tre miliardi di parametri: il README di NVIDIA indica l'inferenza di GR00T N1.7 su una GPU con 16 GB o più di VRAM. Per vedere cosa fa il tuo checkpoint ottimizzato sul braccio senza acquistare una scheda, metti la policy su una GPU cloud noleggiata, mantieni il loop del robot sulla macchina con le porte USB e invia osservazioni e blocchi di azioni sulla rete.

Funziona, non è gratuito e il costo non è distribuito uniformemente tra i compiti. Di seguito: il server di policy di NVIDIA, lo stack asincrono di lerobot, l'aritmetica che indica in anticipo se il tuo uplink è abbastanza veloce e il percorso della piattaforma. Tutto verificato rispetto al branch principale di Isaac-GR00T (N1.7 GA) e lerobot 0.6.1 il 23 agosto 2026.

Perché la policy non si adatterà alla macchina del robot

Due delle cinque policy che AY-Robots può addestrare funzionano su una scheda workstation, tre no. La la colonna sottostante è per passo d'azione, ed è il numero che compete con il tempo di andata e ritorno della tua rete.

Leggilo come una decisione, non come una curiosità. a 20 ms per passo, funziona sulla macchina del robot e non ci pensi più. a 485 ms ha impiegato un terzo di secondo prima che un pacchetto lasci il tuo edificio. Il e aggiungono il lato della precisione.

I due stack client-server già esistenti

Isaac-GR00T fornisce un server request-reply ZeroMQ; lerobot fornisce un server gRPC costruito attorno all'inferenza asincrona. Entrambi accettano un GR00T checkpoint. L'elenco delle policy supportate da lerobot in async_inference/constants.py è act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 e groot; il suo elenco di robot è so100_follower, so101_follower, bi_so_follower e omx_follower.

La riga di serializzazione è più importante di quanto sembri. Il MsgSerializer di GR00T rifiuta payload ndarray con dtype oggetto in entrambe le direzioni, perché altrimenti msgpack_numpy li passerebbe a pickle. lerobot invece esegue il pickle: policy_server.py chiama pickle.loads sui dati della richiesta, robot_client.py esegue il pickle dell'osservazione che invia. Difendibile su una LAN fidata, indifendibile una volta che la porta è raggiungibile da internet.

Percorso A: il server di policy GR00T proprietario di NVIDIA

Questo è il percorso documentato da NVIDIA per l'hardware SO-100 e SO-101, e quello da usare se il tuo checkpoint è stato generato da examples/finetune.sh con --embodiment-tag NEW_EMBODIMENT. I passaggi aggiungono ciò che il README originale omette: portare la porta al robot senza esporla a tutti gli altri.

1. 1
   Installa GR00T sulla macchina GPU noleggiata

   I sottomoduli sono richiesti, e git-lfs deve esistere prima della clonazione o i file parquet in demo_data arriveranno come puntatori. flash-attn e TensorRT sono inclusi nell'installazione predefinita. La trappola su una nuova immagine del pod: torchcodec 0.8.0 è l'unico backend video supportato e carica solo FFmpeg da 4 a 7. Ubuntu 25.10 e 26.04 distribuiscono FFmpeg 8, quindi GR00T fallisce con Could not load libtorchcodec. Installa un FFmpeg inferiore a 8 e metti le sue librerie su 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
   Autenticati contro il backbone gated

   Ogni checkpoint GR00T N1.7, inclusa la tua messa a punto, carica il modello gated nvidia/Cosmos-Reason2-2B al primo utilizzo. Richiedi l'accesso sulla pagina del modello ed effettua il login sul pod, altrimenti il caricamento fallirà con un GatedRepoError.

   bash

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

3. 3
   Avvia il server di policy

   Punta --model-path alla tua directory del checkpoint; su quel percorso il server ignora --modality-config-path, che viene letto solo sul percorso di replay. Ometti --model-path e passa invece --dataset-path più --execution-horizon per una ReplayPolicy che riproduce azioni registrate, il modo più economico per dimostrare che il cablaggio funziona.

   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
   Tunnelizza la porta 5555 alla macchina del robot

   Associa all'interfaccia di loopback, come sopra, e trasporta la porta tramite SSH o una mesh in stile WireGuard. Questo fornisce la crittografia e l'autenticazione che il socket ZeroMQ non offre, per circa un millisecondo.

   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
   Esegui il client del robot accanto ai servi

   Il client necessita del proprio ambiente uv: vuole i driver del robot di lerobot, non lo stack di training. eval_so100.py importa so100_follower, so101_follower e koch_follower, quindi passa il --robot.type corrispondente al tuo braccio (il README originale usa so101_follower). Le chiavi della telecamera devono corrispondere all'addestramento: l'adattatore legge esattamente front e wrist, e scambiarle mostra alla policy la vista sbagliata.

   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"

Percorso B: inferenza asincrona lerobot

lerobot risolve un problema diverso. Invece di bloccare il robot mentre il modello elabora, il client continua a eseguire i passi della coda che ha già, mentre il server calcola il prossimo chunk. Questo è suddivisione delle azioni in chunk portato avanti, lo stack asincrono introdotto con SmolVLA. Funziona anche con un 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

Il server si avvia vuoto: non sa quale policy serve finché il primo handshake del client non glielo comunica, il che è comodo su un pod noleggiato. I due parametri che decidono se il braccio si muove fluidamente sono actions_per_chunk e chunk_size_threshold (la documentazione di lerobot chiama il secondo g, dal paper SmolVLA), e i valori documentati e i valori forniti non concordano.

L'aritmetica che decide se il tuo collegamento è abbastanza veloce

Le persone saltano questo passaggio e poi passano un giorno su . Ci vogliono due minuti ed è quasi sempre decisivo.

Il dizionario di osservazione commentato in eval_so100.py di NVIDIA indica cosa viene trasmesso: due array di forma (480, 640, 3) in uint8, sei float per le giunture, una stringa di linguaggio. Sono 921.600 byte per frame, 1.843.200 byte per due telecamere, circa 14.7 Mbit, e nessuno stack lo comprime in JPEG. Il blocco che torna indietro è di poche decine di passi di 6 float. Il tuo upload decide tutto, non il tuo download.

Il budget in cui devi rientrare

Il client GR00T SO-100 è sincrono: chiama policy.get_action(obs), esegue i primi action_horizon passi del chunk a 30 FPS, quindi richiama. La dimensione del chunk e l'orizzonte sono numeri diversi: la guida di deployment di NVIDIA raccomanda una dimensione del chunk di azione di 16, almeno 32 se combinata con il chunking in tempo reale, mentre eval_so100.py fornisce un orizzonte di esecuzione di 8. Otto passi a 30 FPS corrispondono a 267 ms di movimento per chiamata, e tutto il resto deve rientrare in questo intervallo.

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

Aumentare l'orizzonte è una soluzione drastica e non priva di costi: il braccio agisce su un'osservazione che è ormai vecchia. La soluzione più rigorosa è il chunking in tempo reale (RTC), che calcola il chunk successivo mentre quello corrente è in esecuzione, blocca le azioni garantite per l'esecuzione e completa il resto; il paper sull'RTC lo riporta come robusto al ritardo di inferenza senza necessità di riaddestramento. Verificare prima lo stato di questa funzionalità. NVIDIA contrassegna l'RTC come sperimentale, una primitiva di modello di basso livello raggiungibile tramite action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), non integrata in Gr00tPolicy o nel percorso server-client, dove options non è utilizzato, senza test né esempi. Tramite un server di policy si ottiene l'esecuzione asincrona, non l'RTC.

Misuralo prima di fidarti

Ogni numero sopra è una previsione. Quattro comandi lo trasformano in una misurazione, che vale la pena eseguire prima di dedicare un'ora di pod a un'attività che non avrebbe mai funzionato.

1. 1
   Ottieni il tempo di andata e ritorno grezzo

   Contro il pod, non una CDN. Osserva la deviazione con la stessa attenzione della media: il jitter fa balbettare un braccio, non la latenza media.

   bash

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

2. 2
   Misura l'uplink che hai, non quello per cui paghi

   L'upload residenziale è solitamente una frazione del download, ed è il numero nella tabella della larghezza di banda sopra.

   bash

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

3. 3
   Leggi il log di latenza del client

   Il client robot lerobot registra la latenza server-client e il tempo di deserializzazione per ogni chunk. Sulla rotta B non hai bisogno di strumenti esterni.

   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
   Guarda la coda delle azioni svuotarsi

   Passa --debug_visualize_queue_size=True e il client traccia la dimensione della coda in fase di esecuzione. Se raggiunge ripetutamente lo zero, sei fuori budget: abbassa gli fps, aumenta actions_per_chunk o aumenta chunk_size_threshold in modo che le osservazioni vengano inviate più spesso.

   bash

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

A cosa serve realmente l'inferenza remota

Se un'esecuzione remota balbetta nello stesso punto in ogni episodio, la rete probabilmente non è la causa. Una policy che esita sempre allo stesso angolo di giunto è solitamente un problema di dati; vedi le pagine sulle modalità di fallimento, in particolare una policy che funziona solo in una configurazione e la loss diminuisce ma la policy non fa nulla.

Far da sé vs farlo su AY-Robots

Quanto costa una sessione di inferenza remota

Due numeri contano: la tariffa oraria della scheda e per quanto tempo la lasci in funzione. Il primo è pubblicato; il secondo sorprende le persone.

Queste tariffe sono state lette dalla pagina dei prezzi di Runpod il 23 agosto 2026, e i mercati spot sono soggetti a variazioni. AY-Robots invece propone un'intera esecuzione: da 3 a 6 ore a 1.20 a 2.00 USD all'ora sul livello A100 o H100, circa da 4 a 12 USD per un'esecuzione GR00T o Pi0.5; da 2 a 5 ore a 0.30 a 0.60 USD all'ora sul livello da 24 GB, da 1 a 3 USD per SmolVLA o ACT. Una sessione di inferenza è più conveniente di un'esecuzione di training solo se la si interrompe, ed è a questo che serve il watchdog di inattività. Vedi la documentazione di fatturazione e la pagina dei prezzi.

Se preferisci non avere la rete nel ciclo

L'inferenza remota risolve un problema hardware e ne crea uno di latenza. A volte la risposta migliore è una policy che si adatta all'hardware che si possiede.

• ACT, circa 80 M parametri e 20 ms per passo d'azione, 50 episodi minimi, qualsiasi scheda da 24 GB. In una configurazione ripetitiva a singola attività, spesso supera un modello remoto da 3 B, perché non attende mai un pacchetto.
• SmolVLA, circa 450 M parametri e 245 ms per passo d'azione, 30 episodi minimi. Mantiene il condizionamento linguistico che manca ad ACT, e la documentazione di lerobot lo colloca a circa 2 GB al momento dell'inferenza contro circa 14 GB per PI0.
• ACT vs GR00T N1.7 per la metà dell'accuratezza del compromesso.

Esiste anche una via di mezzo: addestrare nel cloud, valutare localmente. Il fine-tuning richiede la scheda da 80 GB e non si preoccupa della latenza, quindi addestrare GR00T N1.7 su un SO-100 in remoto è incontestabile. Solo il ciclo di valutazione ha un vincolo in tempo reale; la documentazione sull'addestramento e la matrice modello-braccio coprono questa metà.

Domande frequenti

La versione breve

L'inferenza remota per una 3 B policy è un problema di ingegneria risolto con un problema di fisica irrisolto annesso. L'ingegneria consiste in due comandi e un tunnel SSH. La fisica è che un'osservazione di 1.8 MB deve raggiungere una GPU in un altro paese e tornare prima che il braccio esaurisca le azioni. Fai i calcoli prima di noleggiare qualsiasi cosa, scegli un compito che tolleri un'osservazione obsoleta e aumenta l'orizzonte di esecuzione piuttosto che sperare che il link migliori.

Se non hai ancora registrato un dataset, e la vengono prima, e la voce spiega cosa scrive il registratore. Il contesto è in e il ; la collega ogni numero di benchmark a una fonte.