Εκτέλεση συμπερασμάτων GR00T χωρίς τοπική GPU

Ένα Raspberry Pi είναι αρκετό για να οδηγήσει ένα μέσω σειριακού διαύλου και να τραβήξει καρέ από δύο κάμερες USB. Δεν είναι αρκετό για να εκτελέσει ένα μοντέλο τριών δισεκατομμυρίων παραμέτρων : το README της NVIDIA αναφέρει ότι η εξαγωγή συμπερασμάτων του GR00T N1.7 απαιτεί μία GPU με 16 GB ή περισσότερο VRAM. Για να δείτε τι κάνει το βελτιστοποιημένο σας checkpoint στον βραχίονα χωρίς να αγοράσετε κάρτα, τοποθετήστε την πολιτική σε μια ενοικιαζόμενη GPU στο cloud, κρατήστε τον βρόχο του ρομπότ στη μηχανή με τις θύρες USB και στείλτε παρατηρήσεις και τμήματα δράσης μέσω του δικτύου.

Λειτουργεί, δεν είναι δωρεάν και η τιμή δεν κατανέμεται ομοιόμορφα σε όλες τις εργασίες. Παρακάτω: ο δικός της διακομιστής πολιτικής της NVIDIA, η ασύγχρονη στοίβα του lerobot, η αριθμητική που λέει εκ των προτέρων αν η σύνδεσή σας είναι αρκετά γρήγορη και η διαδρομή της πλατφόρμας. Όλα αυτά ελέγχθηκαν έναντι του κύριου κλάδου του Isaac-GR00T (N1.7 GA) και του lerobot 0.6.1 στις 23 Αυγούστου 2026.

Γιατί η πολιτική δεν θα χωρέσει στη μηχανή του ρομπότ

Δύο από τις πέντε πολιτικές που μπορεί να εκπαιδεύσει η AY-Robots τρέχουν σε κάρτα workstation, τρεις όχι. Η στήλη παρακάτω είναι ανά βήμα ενέργειας, και αυτός είναι ο αριθμός που ανταγωνίζεται τον χρόνο μετάδοσης του δικτύου σας.

Διαβάστε το ως απόφαση, όχι ως ασήμαντη πληροφορία. στα 20 ms ανά βήμα τρέχει στη μηχανή του ρομπότ και δεν το σκέφτεστε ποτέ ξανά. στα 485 ms έχει περάσει το ένα τρίτο του δευτερολέπτου πριν ένα πακέτο φύγει από το κτίριό σας. Η και προσθέτουν την πλευρά της ακρίβειας.

Οι δύο στοίβες client-server που υπάρχουν ήδη

Το Isaac-GR00T παρέχει έναν διακομιστή αιτήσεων-απαντήσεων ZeroMQ· το lerobot παρέχει έναν διακομιστή gRPC χτισμένο γύρω από ασύγχρονη συμπερασματολογία. Και οι δύο δέχονται ένα GR00T σημείο ελέγχου. Η λίστα υποστηριζόμενων πολιτικών του lerobot στο async_inference/constants.py είναι act, smolvla, diffusion, tdmpc, vqbet, pi0, pi05 και groot· η λίστα ρομπότ του είναι so100_follower, so101_follower, bi_so_follower και omx_follower.

Η σειρά σειριοποίησης έχει μεγαλύτερη σημασία από ό,τι φαίνεται. Το MsgSerializer του GR00T αρνείται φορτία ndarray τύπου αντικειμένου και στις δύο κατευθύνσεις, επειδή το msgpack_numpy θα τα παρέδιδε διαφορετικά στο pickle. Το lerobot χρησιμοποιεί pickle αντ' αυτού: το policy_server.py καλεί το pickle.loads σε δεδομένα αιτήματος, το robot_client.py κάνει pickle την παρατήρηση που στέλνει. Υπερασπίσιμο σε ένα αξιόπιστο LAN, ανυπεράσπιστο μόλις η θύρα είναι προσβάσιμη από το διαδίκτυο.

Διαδρομή Α: Ο διακομιστής πολιτικής GR00T της NVIDIA

Αυτή είναι η διαδρομή που τεκμηριώνει η NVIDIA για το υλικό SO-100 και SO-101, και αυτή που πρέπει να χρησιμοποιήσετε εάν το checkpoint σας προήλθε από το examples/finetune.sh με --embodiment-tag NEW_EMBODIMENT. Τα βήματα προσθέτουν όσα παραλείπει το αρχικό README: τη μεταφορά της θύρας στο ρομπότ χωρίς να την εκθέσετε σε όλους τους άλλους.

1. 1
   Εγκαταστήστε το GR00T στο ενοικιαζόμενο GPU box

   Τα υπομονάδες είναι απαραίτητα, και το git-lfs πρέπει να υπάρχει πριν από το clone, αλλιώς τα αρχεία parquet στο demo_data θα φτάσουν ως δείκτες. Το flash-attn και το TensorRT περιλαμβάνονται στην προεπιλεγμένη εγκατάσταση. Η παγίδα σε μια νέα εικόνα pod: το torchcodec 0.8.0 είναι το μόνο υποστηριζόμενο backend βίντεο και φορτώνει μόνο 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
   Επαληθεύστε την ταυτότητα έναντι του gated backbone

   Κάθε checkpoint GR00T N1.7, συμπεριλαμβανομένου του δικού σας fine-tune, φορτώνει το gated nvidia/Cosmos-Reason2-2B στην πρώτη χρήση. Ζητήστε πρόσβαση στη σελίδα του μοντέλου και συνδεθείτε στο pod, αλλιώς η φόρτωση αποτυγχάνει με ένα GatedRepoError.

   bash

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

3. 3
   Εκκινήστε τον διακομιστή πολιτικής

   Δείξτε το --model-path στον κατάλογο του checkpoint σας· σε αυτή τη διαδρομή ο διακομιστής αγνοεί το --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 ή ενός δικτύου τύπου 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"

Διαδρομή Β: ασύγχρονη εξαγωγή συμπερασμάτων με lerobot

Το lerobot επιλύει ένα διαφορετικό πρόβλημα. Αντί να μπλοκάρει το ρομπότ ενώ το μοντέλο σκέφτεται, ο πελάτης συνεχίζει να προχωρά στην ουρά που ήδη έχει, ενώ ο διακομιστής υπολογίζει το επόμενο κομμάτι. Αυτό είναι τεμαχισμός ενέργειας προχωρημένο, η ασύγχρονη στοίβα που εισήχθη με το SmolVLA. Λειτουργεί και με ένα 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

Ο διακομιστής ξεκινά κενός: δεν γνωρίζει ποια πολιτική εξυπηρετεί μέχρι το πρώτο handshake του πελάτη να του το πει, κάτι που είναι βολικό σε έναν ενοικιαζόμενο κόμβο. Οι δύο ρυθμίσεις που αποφασίζουν αν ο βραχίονας κινείται ομαλά είναι actions_per_chunk και chunk_size_threshold (τα έγγραφα του lerobot αναφέρουν το δεύτερο ως g, από την εργασία SmolVLA), και οι τεκμηριωμένες τιμές και οι τιμές που παρέχονται δεν συμφωνούν.

Η αριθμητική που αποφασίζει αν η σύνδεσή σας είναι αρκετά γρήγορη

Οι άνθρωποι το παραλείπουν αυτό και μετά ξοδεύουν μια μέρα σε . Χρειάζονται δύο λεπτά και είναι σχεδόν πάντα καθοριστικό.

Το σχολιασμένο λεξικό παρατηρήσεων στο eval_so100.py της NVIDIA λέει τι μεταδίδεται: δύο πίνακες σχήματος (480, 640, 3) σε uint8, έξι δεκαδικοί αριθμοί αρθρώσεων, μια συμβολοσειρά γλώσσας. Αυτό είναι 921.600 bytes ανά καρέ, 1.843.200 bytes για δύο κάμερες, περίπου 14.7 Mbit, και καμία στοίβα δεν το συμπιέζει με JPEG. Το κομμάτι που επιστρέφει είναι μερικές δεκάδες βήματα των 6 δεκαδικών αριθμών. Η μεταφόρτωσή σας αποφασίζει τα πάντα, όχι η λήψη σας.

Ο προϋπολογισμός στον οποίο πρέπει να χωρέσετε

Ο πελάτης GR00T SO-100 είναι σύγχρονος: καλεί policy.get_action(obs), εκτελεί τα πρώτα action_horizon βήματα του τμήματος στα 30 FPS, και μετά καλεί ξανά. Το μέγεθος του τμήματος (chunk size) και ο ορίζοντας (horizon) είναι διαφορετικοί αριθμοί: ο οδηγός ανάπτυξης της NVIDIA συνιστά μέγεθος τμήματος δράσης 16, τουλάχιστον 32 όταν συνδυάζεται με real-time chunking, ενώ eval_so100.py παρέχει έναν ορίζοντα εκτέλεσης 8. Οκτώ βήματα στα 30 FPS είναι 267 ms κίνησης ανά κλήση, και όλα τα άλλα πρέπει να χωρέσουν μέσα σε αυτό.

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 αναφέρει ότι είναι ανθεκτικό στην καθυστέρηση συμπερασμάτων χωρίς επανεκπαίδευση. Ελέγξτε πρώτα πού βρίσκεται αυτό. Η NVIDIA χαρακτηρίζει το RTC πειραματικό, μια πρωτόγονη λειτουργία μοντέλου χαμηλού επιπέδου προσβάσιμη μέσω action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), μη ενσωματωμένο στο Gr00tPolicy ή στη διαδρομή server-client, όπου options δεν χρησιμοποιείται, χωρίς δοκιμές και χωρίς παράδειγμα. Μέσω ενός policy server αποκτάτε ασύγχρονη εκτέλεση, όχι RTC.

Μετρήστε το πριν το εμπιστευτείτε

Κάθε αριθμός παραπάνω είναι μια πρόβλεψη. Τέσσερις εντολές τη μετατρέπουν σε μέτρηση, αξίζει να τις εκτελέσετε πριν δεσμεύσετε μια ώρα pod σε μια εργασία που δεν επρόκειτο ποτέ να λειτουργήσει.

1. 1
   Λάβετε τον ακατέργαστο χρόνο μετ' επιστροφής

   Ενάντια στο pod, όχι σε ένα CDN. Παρακολουθήστε την απόκλιση τόσο στενά όσο και τον μέσο όρο: το jitter κάνει ένα ρομποτικό βραχίονα να κολλάει, όχι ο μέσος χρόνος καθυστέρησης.

   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 καταγράφει την καθυστέρηση από τον διακομιστή στον πελάτη και τον χρόνο αποσειριοποίησης για κάθε κομμάτι. Στη διαδρομή Β δεν χρειάζεστε εξωτερικά εργαλεία.

   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

Τι κοστίζει μια απομακρυσμένη συνεδρία inference

Δύο αριθμοί έχουν σημασία: η ωριαία τιμή της κάρτας και πόσο καιρό την αφήνετε να λειτουργεί. Ο πρώτος δημοσιεύεται· ο δεύτερος εκπλήσσει τους ανθρώπους.

Αυτές οι τιμές διαβάστηκαν από τη σελίδα τιμολόγησης της Runpod στις 23 Αυγούστου 2026, και οι αγορές spot μεταβάλλονται. Η 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 GB, 1 έως 3 USD για SmolVLA ή ACT. Μια συνεδρία συμπερασματολογίας είναι πιο οικονομική από μια εκτέλεση εκπαίδευσης μόνο αν την σταματήσετε, για αυτό υπάρχει ο επόπτης αδράνειας. Δείτε τα έγγραφα χρέωσης και τη σελίδα τιμολόγησης.

Αν προτιμάτε να μην έχετε το δίκτυο στον βρόχο

Η απομακρυσμένη εξαγωγή συμπερασμάτων λύνει ένα πρόβλημα υλικού και δημιουργεί ένα πρόβλημα καθυστέρησης. Μερικές φορές η καλύτερη απάντηση είναι μια πολιτική που ταιριάζει στο υλικό που διαθέτετε.

• ACT, περίπου 80 M παραμέτρους και 20 ms ανά βήμα ενέργειας, 50 επεισόδια ελάχιστο, οποιαδήποτε κάρτα 24 GB. Σε μια επαναλαμβανόμενη ρύθμιση μονής εργασίας συχνά ξεπερνά ένα απομακρυσμένο μοντέλο 3 B, επειδή δεν περιμένει ποτέ ένα πακέτο.
• SmolVLA, περίπου 450 M παραμέτρους και 245 ms ανά βήμα ενέργειας, 30 επεισόδια ελάχιστο. Διατηρεί την γλωσσική προσαρμογή που λείπει από το ACT, και τα lerobot docs το τοποθετούν περίπου στα 2 GB κατά τον χρόνο εξαγωγής συμπερασμάτων έναντι περίπου 14 GB για το PI0.
• ACT vs GR00T N1.7 για το μισό της ακρίβειας της ανταλλαγής.

Υπάρχει επίσης μια μέση οδός: εκπαίδευση στο cloud, αξιολόγηση τοπικά. Βελτιστοποίηση χρειάζεται την κάρτα 80 GB και δεν ενδιαφέρεται για την καθυστέρηση, οπότε η εκπαίδευση του GR00T N1.7 σε ένα SO-100 απομακρυσμένα είναι αδιαμφισβήτητη. Μόνο ο βρόχος αξιολόγησης έχει περιορισμό πραγματικού χρόνου· τα έγγραφα εκπαίδευσης και μήτρα μοντέλου και βραχίονα καλύπτουν αυτό το μισό.

Συχνές ερωτήσεις

Η σύντομη εκδοχή

Η απομακρυσμένη συμπερασματολογία για ένα 3 B πολιτική είναι ένα λυμένο μηχανολογικό πρόβλημα με ένα άλυτο φυσικό πρόβλημα συνδεδεμένο. Η μηχανική είναι δύο εντολές και ένα SSH tunnel. Η φυσική είναι ότι μια παρατήρηση 1.8 MB πρέπει να φτάσει σε μια GPU σε άλλη χώρα και να επιστρέψει πριν ο βραχίονας ξεμείνει από ενέργειες. Κάντε τους υπολογισμούς πριν νοικιάσετε οτιδήποτε, επιλέξτε μια εργασία που ανέχεται μια παρωχημένη παρατήρηση και αυξήστε τον ορίζοντα εκτέλεσης αντί να ελπίζετε ότι η σύνδεση θα βελτιωθεί.

Εάν δεν έχετε καταγράψει ακόμα ένα σύνολο δεδομένων, καταγράψτε το πρώτο σας σύνολο δεδομένων και ο οδηγός εγκατάστασης SO-100 προηγούνται, και η μορφή συνόλου δεδομένων LeRobot καταχώριση εξηγεί τι καταγράφει ο καταγραφέας. Το υπόβαθρο βρίσκεται στα μοντέλα όρασης-γλώσσας-δράσης και την εργασία πολιτικής flow-matching· η καταχώριση arena συνδέει κάθε αριθμό αναφοράς με μια πηγή.