รัน GR00T Inference โดยไม่ต้องใช้ GPU ในเครื่อง

Raspberry Pi เพียงพอที่จะขับเคลื่อน SO-100 ผ่านบัสอนุกรมและดึงเฟรมจากกล้อง USB สองตัว แต่ไม่เพียงพอที่จะรันโมเดลที่มีพารามิเตอร์สามพันล้านตัวอย่าง โมเดลวิสัยทัศน์-ภาษา-การกระทำ: README ของ NVIDIA ระบุว่าการอนุมานของ GR00T N1.7 ต้องใช้ GPU หนึ่งตัวที่มี VRAM 16 GB ขึ้นไป หากต้องการดูว่าเช็คพอยต์ GR00T N1.7 ที่ปรับแต่งแล้วของคุณทำงานอย่างไรบนแขนหุ่นยนต์โดยไม่ต้องซื้อการ์ด ให้วางนโยบายบน GPU คลาวด์ที่เช่าไว้ รักษาลูปหุ่นยนต์ไว้บนเครื่องที่มีพอร์ต USB และส่งข้อมูลการสังเกตและส่วนของการกระทำผ่านเครือข่าย

มันใช้งานได้จริง ไม่ฟรี และราคาไม่ได้กระจายอย่างสม่ำเสมอในแต่ละงาน ด้านล่าง: เซิร์ฟเวอร์นโยบายของ NVIDIA เอง, สแต็กอะซิงโครนัสของ lerobot, การคำนวณที่บอกล่วงหน้าว่าอัปลิงก์ของคุณเร็วพอหรือไม่ และเส้นทางแพลตฟอร์ม ทั้งหมดนี้ได้รับการตรวจสอบกับ Isaac-GR00T main branch (N1.7 GA) และ lerobot 0.6.1 ณ วันที่ 23 สิงหาคม 2026

ทำไมนโยบายจึงไม่สามารถติดตั้งบนเครื่องหุ่นยนต์ได้

นโยบายสองในห้าข้อที่ AY-Robots สามารถฝึกได้ทำงานบนการ์ดเวิร์กสเตชัน ส่วนอีกสามข้อไม่ทำงาน The เวลาแฝงของการอนุมาน คอลัมน์ด้านล่างนี้คือต่อขั้นตอนการดำเนินการ และเป็นตัวเลขที่แข่งขันกับการเดินทางไปกลับของเครือข่ายของคุณ

อ่านสิ่งนี้เป็นการตัดสินใจ ไม่ใช่เรื่องเล็กน้อย ACT ที่ 20 มิลลิวินาทีต่อขั้นตอนทำงานบนเครื่องหุ่นยนต์และคุณจะไม่ต้องคิดถึงมันอีกเลย Pi0.5 ที่ 485 มิลลิวินาทีใช้เวลาไปหนึ่งในสามของวินาทีก่อนที่แพ็กเก็ตจะออกจากอาคารของคุณ The การเปรียบเทียบนโยบาย และ GR00T N1.7 vs Pi0.5 เพิ่มด้านความแม่นยำ

สแต็กไคลเอนต์-เซิร์ฟเวอร์สองชุดที่มีอยู่แล้ว

Isaac-GR00T มาพร้อมกับเซิร์ฟเวอร์ ZeroMQ request-reply; 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 MsgSerializer ปฏิเสธเพย์โหลด ndarray ชนิด object-dtype ทั้งสองทิศทาง เนื่องจาก msgpack_numpy จะส่งต่อให้ pickle แทน lerobot ใช้ pickle แทน: policy_server.py เรียกใช้ pickle.loads กับข้อมูลคำขอ robot_client.py ใช้ pickle กับข้อมูลการสังเกตที่ส่งไป สามารถป้องกันได้ใน LAN ที่เชื่อถือได้ แต่ไม่สามารถป้องกันได้เมื่อพอร์ตสามารถเข้าถึงได้จากอินเทอร์เน็ต

เส้นทาง A: เซิร์ฟเวอร์นโยบาย GR00T ของ NVIDIA เอง

นี่คือเส้นทางที่ NVIDIA จัดทำเอกสารสำหรับฮาร์ดแวร์ SO-100 และ SO-101 และเป็นเส้นทางที่ควรใช้หากจุดตรวจสอบของคุณมาจาก examples/finetune.sh พร้อม --embodiment-tag NEW_EMBODIMENT ขั้นตอนเหล่านี้จะเพิ่มสิ่งที่ README ต้นฉบับละเว้นไป: การส่งพอร์ตไปยังหุ่นยนต์โดยไม่เปิดเผยให้ผู้อื่นทราบ

1. 1
   ติดตั้ง GR00T บนเครื่อง GPU ที่เช่า

   จำเป็นต้องมี Submodules และ git-lfs ต้องมีอยู่ก่อนการโคลน มิฉะนั้นไฟล์ parquet ใน demo_data จะมาถึงในรูปแบบของพอยน์เตอร์ flash-attn และ TensorRT มาพร้อมกับการติดตั้งเริ่มต้น ข้อควรระวังสำหรับอิมเมจพ็อดใหม่: torchcodec 0.8.0 เป็นแบ็กเอนด์วิดีโอที่รองรับเพียงตัวเดียวและโหลด 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
   ยืนยันตัวตนกับแบ็กโบนแบบมีเกต

   จุดตรวจสอบ GR00T N1.7 ทุกจุด รวมถึงการปรับแต่งของคุณเอง จะโหลด nvidia/Cosmos-Reason2-2B แบบมีเกตในการใช้งานครั้งแรก ขอสิทธิ์เข้าถึงบนหน้าโมเดลและเข้าสู่ระบบบนพ็อด มิฉะนั้นการโหลดจะล้มเหลวพร้อมข้อความ 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 socket ไม่มีให้ โดยใช้เวลาประมาณหนึ่งมิลลิวินาที

   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"

เส้นทาง B: การอนุมานแบบอะซิงโครนัสของ lerobot

lerobot แก้ปัญหาที่แตกต่างออกไป แทนที่จะบล็อกหุ่นยนต์ในขณะที่โมเดลกำลังประมวลผล ไคลเอนต์จะดำเนินการตามคิวที่มีอยู่ต่อไปในขณะที่เซิร์ฟเวอร์คำนวณส่วนถัดไป นี่คือการแบ่งกลุ่มการกระทำที่พัฒนาต่อยอดไปอีกขั้น ซึ่งเป็นสแต็กแบบอะซิงโครนัสที่นำมาใช้กับ SmolVLA และยังทำงานร่วมกับ GR00T checkpoint ได้ด้วย

# 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's eval_so100.py ระบุสิ่งที่ส่งผ่านสาย: อาร์เรย์สองชุดขนาด (480, 640, 3) ในรูปแบบ uint8, ค่า float ของข้อต่อหกค่า, และสตริงภาษา นั่นคือ 921,600 ไบต์ต่อเฟรม, 1,843,200 ไบต์สำหรับกล้องสองตัว, ประมาณ 14.7 Mbit, และไม่มีสแต็กใดบีบอัดด้วย JPEG ส่วนข้อมูลที่ส่งกลับมาคือค่า float 6 ค่าจำนวนหลายสิบขั้นตอน การอัปโหลดของคุณเป็นตัวตัดสินทุกอย่าง ไม่ใช่การดาวน์โหลดของคุณ

งบประมาณที่คุณต้องคำนึงถึง

ไคลเอนต์ GR00T SO-100 เป็นแบบซิงโครนัส: โดยจะเรียกใช้ policy.get_action(obs), ดำเนินการ action_horizon ขั้นตอนแรกของส่วนข้อมูลที่ 30 FPS จากนั้นจึงเรียกใช้อีกครั้ง ขนาดส่วนข้อมูลและขอบเขตเป็นตัวเลขที่แตกต่างกัน: คู่มือการปรับใช้ของ NVIDIA แนะนำขนาดส่วนข้อมูลการดำเนินการที่ 16 อย่างน้อย 32 เมื่อรวมกับการแบ่งส่วนข้อมูลแบบเรียลไทม์ ในขณะที่ eval_so100.py มาพร้อมกับขอบเขตการดำเนินการที่ 8 แปดขั้นตอนที่ 30 FPS คือการเคลื่อนไหว 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

วัดก่อนเชื่อ

ทุกตัวเลขข้างต้นเป็นเพียงการคาดการณ์ สี่คำสั่งต่อไปนี้จะเปลี่ยนการคาดการณ์ให้เป็นการวัดผลจริง ซึ่งควรดำเนินการก่อนที่จะใช้เวลา pod-hour ไปกับงานที่ไม่สามารถทำสำเร็จได้

1. 1
   รับค่า round trip ดิบ

   ทดสอบกับ pod โดยตรง ไม่ใช่ CDN สังเกตค่าเบี่ยงเบนให้ใกล้เคียงกับค่าเฉลี่ย: การกระตุกของแขนหุ่นยนต์เกิดจาก jitter ไม่ใช่ค่า latency เฉลี่ย

   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
   อ่านบันทึก latency ของไคลเอนต์เอง

   ไคลเอนต์หุ่นยนต์ lerobot จะบันทึกค่า latency จากเซิร์ฟเวอร์ไปยังไคลเอนต์และเวลา deserialization สำหรับแต่ละ chunk ในเส้นทาง 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

ประโยชน์ที่แท้จริงของการอนุมานระยะไกล

หากการรันระยะไกลสะดุดที่จุดเดียวกันในทุกๆ Episode เครือข่ายอาจไม่ใช่สาเหตุ นโยบายที่ลังเลที่มุมข้อต่อเดียวกันทุกครั้งมักเป็นปัญหาข้อมูล ดูที่ หน้าโหมดความล้มเหลว, โดยเฉพาะ นโยบายที่ทำงานได้ในบางการตั้งค่าเท่านั้น และ Loss ลดลงแต่นโยบายไม่ทำงาน.

การทำด้วยตัวเองเทียบกับการทำบน AY-Robots

ค่าใช้จ่ายของการอนุมานระยะไกล

มีสองตัวเลขที่สำคัญ: อัตราค่าบริการรายชั่วโมงของการ์ด และระยะเวลาที่คุณปล่อยให้มันทำงาน ตัวเลขแรกมีการเผยแพร่แล้ว; ส่วนตัวเลขที่สองมักทำให้คนประหลาดใจ

อัตราเหล่านี้อ่านจากหน้าการกำหนดราคาของ Runpod เมื่อวันที่ 23 สิงหาคม 2026 และตลาดแบบสปอตมีการเปลี่ยนแปลง 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 เซสชันการอนุมานจะคุ้มค่ากว่าการรันการฝึกอบรมก็ต่อเมื่อคุณหยุดมัน ซึ่งเป็นหน้าที่ของ idle watchdog ดูเอกสารการเรียกเก็บเงิน และ หน้าการกำหนดราคา.

หากคุณไม่ต้องการให้เครือข่ายอยู่ในวงจร

การอนุมานระยะไกลช่วยแก้ปัญหาฮาร์ดแวร์และสร้างปัญหาความหน่วง บางครั้งคำตอบที่ดีกว่าคือการใช้นโยบายที่เหมาะสมกับฮาร์ดแวร์ที่คุณมี

• ACT, มีพารามิเตอร์ประมาณ 80 ล้านตัว และใช้เวลา 20 มิลลิวินาทีต่อขั้นตอนการดำเนินการ, อย่างน้อย 50 episodes, ใช้การ์ด 24 GB ใดก็ได้ ในการตั้งค่าแบบงานเดียวซ้ำๆ มักจะเอาชนะโมเดล 3 B ระยะไกลได้ เพราะไม่ต้องรอแพ็กเก็ต
• SmolVLA, มีพารามิเตอร์ประมาณ 450 ล้านตัว และใช้เวลา 245 มิลลิวินาทีต่อขั้นตอนการดำเนินการ, อย่างน้อย 30 episodes มันยังคงรักษาการปรับสภาพภาษาที่ ACT ขาดไป และเอกสารของ lerobot ระบุว่าใช้หน่วยความจำประมาณ 2 GB ในเวลาอนุมาน เทียบกับประมาณ 14 GB สำหรับ PI0
• ACT vs GR00T N1.7 สำหรับครึ่งหนึ่งของการแลกเปลี่ยนที่เน้นความแม่นยำ

นอกจากนี้ยังมีทางสายกลาง: ฝึกฝนในคลาวด์ ประเมินผลในเครื่อง ต้องการการ์ด 80 GB และไม่สนใจเรื่องความหน่วง ดังนั้น จากระยะไกลเป็นสิ่งที่ไม่มีข้อโต้แย้ง มีเพียงลูปการประเมินผลเท่านั้นที่มีข้อจำกัดด้านเวลาจริง; และ ครอบคลุมส่วนนั้น

คำถามที่พบบ่อย

สรุปสั้นๆ

การอนุมานระยะไกลสำหรับ 3 B นโยบาย เป็นปัญหาทางวิศวกรรมที่แก้ไขได้แล้ว แต่มีปัญหาทางฟิสิกส์ที่ยังไม่ได้รับการแก้ไขพ่วงมาด้วย งานวิศวกรรมคือคำสั่งสองคำสั่งและ SSH tunnel ส่วนฟิสิกส์คือข้อมูลการสังเกตการณ์ขนาด 1.8 MB จะต้องไปถึง GPU ในประเทศอื่นและกลับมาก่อนที่แขนจะหมดการกระทำ คำนวณให้ดีก่อนที่จะเช่าอะไร, เลือกงานที่ทนต่อข้อมูลการสังเกตการณ์ที่ล้าสมัยได้, และเพิ่มขอบเขตการดำเนินการแทนที่จะหวังว่าลิงก์จะดีขึ้น

หากคุณยังไม่ได้บันทึกชุดข้อมูล และ มาก่อน และ อธิบายสิ่งที่เครื่องบันทึกเขียนไว้ ข้อมูลพื้นฐานอยู่ใน และ ; เชื่อมโยงตัวเลขเกณฑ์มาตรฐานแต่ละรายการเข้ากับแหล่งที่มา