הפעל הסקת GR00T ללא GPU מקומי

Raspberry Pi מספיק כדי להניע דרך אפיק טורי ולשלוף פריימים משתי מצלמות USB. זה לא מספיק כדי להריץ מודל של שלושה מיליארד פרמטרים מסוג : קובץ ה-README של NVIDIA מציין שביצוע הסקה של GR00T N1.7 דורש GPU אחד עם 16 GB או יותר של VRAM. כדי לראות מה נקודת הבדיקה (checkpoint) המכווננת של עושה על הזרוע בלי לקנות כרטיס, שים את המדיניות על GPU ענן שכור, השאר את לולאת הרובוט על המכונה עם יציאות ה-USB, ושלח תצפיות ונתחי פעולה דרך הרשת.

זה עובד, זה לא בחינם, והמחיר אינו מתחלק באופן שווה בין המשימות. להלן: שרת המדיניות של NVIDIA עצמה, ערימת ה-async של lerobot, החישוב שקובע מראש אם ה-uplink שלך מהיר מספיק, ונתיב הפלטפורמה. כל זה נבדק מול הענף הראשי של Isaac-GR00T (N1.7 GA) ו-lerobot 0.6.1 בתאריך 23 August 2026.

מדוע המדיניות לא תתאים למכונת הרובוט

שתיים מתוך חמש המדיניות ש-AY-Robots יכולה לאמן רצות על כרטיס תחנת עבודה, שלוש לא. השהיית הסקה העמודה למטה היא לכל שלב פעולה, וזה המספר שמתחרה בזמן ההלוך-חזור של הרשת שלך.

קרא זאת כהחלטה, לא כטריוויה. ACT ב-20 אלפיות השנייה לכל שלב, רץ על מכונת הרובוט ואתה לא חושב על זה שוב. Pi0.5 ב-485 אלפיות השנייה, בילה שליש שנייה לפני שחבילה עוזבת את הבניין שלך. השוואת מדיניות ו-GR00T N1.7 vs Pi0.5 מוסיפים את צד הדיוק.

שתי ערימות הלקוח-שרת הקיימות

Isaac-GR00T מספק שרת ZeroMQ מסוג בקשה-תגובה; lerobot מספק שרת gRPC הבנוי סביב הסקה אסינכרונית. שניהם מקבלים נקודת ביקורת. רשימת המדיניות הנתמכת של 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 מסוג object-dtype בשני הכיוונים, מכיוון ש-msgpack_numpy היה מעביר אותם אחרת ל-pickle. lerobot מבצעת pickle במקום זאת: policy_server.py קורא ל-pickle.loads על נתוני הבקשה, robot_client.py מבצעת pickle לתצפית שהיא שולחת. ניתן להגנה ברשת מקומית מהימנה, בלתי ניתן להגנה ברגע שהפורט נגיש מהאינטרנט.

נתיב א': שרת המדיניות GR00T של NVIDIA

זהו הנתיב ש-NVIDIA מתעדת עבור חומרת SO-100 ו-SO-101, והנתיב לשימוש אם נקודת הבדיקה שלך נוצרה מתוך examples/finetune.sh עם --embodiment-tag NEW_EMBODIMENT. השלבים מוסיפים את מה שה-README המקורי משמיט: העברת הפורט לרובוט מבלי לחשוף אותו לכל השאר.

1. 1
   התקן את GR00T על תיבת ה-GPU השכורה

   מודולי משנה נדרשים, ו-git-lfs חייב להתקיים לפני השיבוט או שקובצי parquet ב-demo_data יגיעו כמצביעים. flash-attn ו-TensorRT מגיעים עם ההתקנה המוגדרת כברירת מחדל. המכשול בתמונת pod חדשה: torchcodec 0.8.0 הוא ה-backend היחיד הנתמך לווידאו וטוען רק FFmpeg 4 עד 7. אובונטו 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
   אמת מול ה-backbone המגודר

   כל נקודת בדיקה של GR00T N1.7, כולל ה-fine-tune שלך, טוענת את nvidia/Cosmos-Reason2-2B המגודר בשימוש הראשון. בקש גישה בדף המודל והתחבר ל-pod, אחרת הטעינה תיכשל עם GatedRepoError.

   bash

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

3. 3
   הפעל את שרת המדיניות

   כוון את --model-path לספריית נקודות הבדיקה שלך; בנתיב זה השרת מתעלם מ---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. זה עובד גם עם נקודת בקרה של 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

השרת מתחיל ריק: הוא אינו יודע איזו מדיניות הוא משרת עד שהלחיצת יד הראשונה של הלקוח מודיעה לו, וזה נוח על פוד שכור. שני המשתנים שקובעים אם הזרוע נעה בצורה חלקה הם actions_per_chunk ו-chunk_size_threshold (תיעוד lerobot מכנה את השני g, על שם מאמר SmolVLA), והערכים המתועדים והערכים שנשלחו אינם תואמים.

האריתמטיקה שמחליטה אם הקישור שלך מהיר מספיק

אנשים מדלגים על זה ואז מבלים יום שלם ב-. זה לוקח שתי דקות וזה כמעט תמיד מכריע.

מילון התצפיות המפורט בקוד של NVIDIA ב-eval_so100.py מציין מה עובר בחיבור: שני מערכים בצורת (480, 640, 3) בפורמט uint8, שישה ערכי float של מפרקים, ומחרוזת שפה. זה 921,600 בתים לפריימים, 1,843,200 בתים לשתי מצלמות, כ-14.7 מגה-ביט, ואף ערימה לא דוחסת את זה ב-JPEG. החבילה שחוזרת היא כמה עשרות צעדים של 6 ערכי float. המהירות העלאה שלך קובעת הכל, לא המהירות הורדה שלך.

התקציב שעליך לעמוד בו

לקוח GR00T SO-100 הוא סינכרוני: הוא קורא ל-policy.get_action(obs), מבצע את ה-action_horizon הצעדים הראשונים של הנתח ב-30 פריימים לשנייה, ואז קורא שוב. גודל הנתח והאופק הם מספרים שונים: מדריך הפריסה של NVIDIA ממליץ על גודל נתח פעולה של 16, לפחות 32 בשילוב עם חלוקה לנתחים בזמן אמת, בעוד ש-eval_so100.py מספק אופק ביצוע של 8. שמונה צעדים ב-30 פריימים לשנייה הם 267 אלפיות שנייה של תנועה לכל קריאה, וכל השאר צריך להיכנס לזה.

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 או לנתיב שרת-לקוח, כאשר options אינו בשימוש, ללא בדיקות וללא דוגמה. דרך שרת מדיניות מקבלים ביצוע אסינכרוני, לא RTC.

מדוד את זה לפני שאתה סומך על זה

כל מספר לעיל הוא חיזוי. ארבע פקודות הופכות אותו למדידה, שכדאי להריץ לפני הקצאת שעת-פוד למשימה שמעולם לא הייתה עובדת.

1. 1
   קבל את זמן הלוך-חזור הגולמי

   מול הפוד, לא מול CDN. עקוב אחר הסטייה באותה מידה כמו הממוצע: ריצוד גורם לזרוע לגמגם, לא השהיה ממוצעת.

   bash

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

2. 2
   מדוד את ה-uplink שיש לך, לא את זה שאתה משלם עליו

   העלאה ביתית היא בדרך כלל שבריר מההורדה, וזהו המספר בטבלת רוחב הפס לעיל.

   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 מתעד את השהיית שרת-ללקוח ואת זמן הדה-סריאליזציה עבור כל חבילה. בנתיב B אינך זקוק לכלי עבודה חיצוניים.

   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

מה עולה סשן הסקה מרחוק

שני מספרים חשובים: התעריף השעתי של הכרטיס, וכמה זמן אתה משאיר אותו פועל. הראשון מפורסם; השני מפתיע אנשים.

מחירים אלו נקראו מדף התמחור של Runpod ב-23 באוגוסט 2026, ושוקי הספוט משתנים. AY-Robots מצטטת ריצה שלמה במקום זאת: 3 עד 6 שעות ב-1.20 עד 2.00 דולר לשעה בשכבת A100 או H100, כ-4 עד 12 דולר לריצת GR00T או Pi0.5; 2 עד 5 שעות ב-0.30 עד 0.60 דולר לשעה בשכבת 24 GB, 1 עד 3 דולר עבור SmolVLA או ACT. סשן הסקה עולה פחות מריצת אימון רק אם עוצרים אותו, ולשם כך נועד ה-idle watchdog. ראו את תיעוד החיובים ואת דף התמחור.

אם אתם מעדיפים שלא תהיה הרשת בלולאה

הסקה מרחוק פותרת בעיית חומרה ויוצרת בעיית חביון. לפעמים התשובה הטובה יותר היא מדיניות שמתאימה לחומרה הקיימת.

• ACT, בערך 80 מיליון פרמטרים ו-20 אלפיות השנייה לצעד פעולה, מינימום 50 אפיזודות, כל כרטיס 24 GB. בהגדרה של משימה יחידה חוזרת, הוא מנצח לעיתים קרובות מודל 3 B מרוחק, מכיוון שהוא לעולם אינו ממתין לחבילה.
• SmolVLA, בערך 450 מיליון פרמטרים ו-245 אלפיות השנייה לצעד פעולה, מינימום 30 אפיזודות. הוא שומר על התניית השפה שחסרה ל-ACT, ותיעוד ה-lerobot מציג אותו בכ-2 GB בזמן הסקה לעומת כ-14 GB עבור PI0.
• ACT vs GR00T N1.7 עבור מחצית הדיוק של הפשרה.

יש גם דרך ביניים: אימון בענן, הערכה מקומית. כוונון עדין דורש כרטיס 80 GB ואינו מתייחס לחביון, ולכן אימון GR00T N1.7 על SO-100 מרחוק אינו שנוי במחלוקת. רק ללולאת ההערכה יש אילוץ זמן אמת; התיעוד האימון ו-מטריצת מודל-וזרוע מכסים את החצי הזה.

שאלות נפוצות

הגרסה הקצרה

הסקה מרוחקת עבור 3 B מדיניות היא בעיה הנדסית פתורה עם בעיית פיזיקה בלתי פתורה צמודה. ההנדסה היא שתי פקודות ומנהרת SSH. הפיזיקה היא שתצפית של 1.8 MB צריכה להגיע ל-GPU במדינה אחרת ולחזור לפני שהזרוע נגמרת מפעולות. בצע את החישובים לפני השכרת כל דבר, בחר משימה הסובלת תצפית מיושנת, והרחב את אופק הביצוע במקום לקוות שהקישור ישתפר.

אם עדיין לא הקלטתם מערך נתונים, ו- קודמים, ו- מסביר מה המקליט כותב. הרקע נמצא ב- ו-; ה- מקשר כל מספר ביצועים למקור.