로컬 GPU 없이 GR00T 추론 실행

라즈베리 파이 하나로 을(를) 직렬 버스로 구동하고 두 개의 USB 카메라에서 프레임을 가져오는 데는 충분합니다. 하지만 30억 개 매개변수 을(를) 실행하기에는 부족합니다. NVIDIA의 README에 따르면 GR00T N1.7 추론에는 16GB 이상의 VRAM을 가진 GPU 하나가 필요합니다. 카드 구매 없이 미세 조정된 체크포인트가 로봇 팔에서 어떻게 작동하는지 확인하려면, 정책을 임대 클라우드 GPU에 올리고, 로봇 루프는 USB 포트가 있는 머신에서 유지하며, 관측값과 행동 청크를 네트워크를 통해 전송하십시오.

이 방법은 작동하지만 무료가 아니며, 비용이 작업별로 균등하게 분배되지 않습니다. 아래 내용은 NVIDIA 자체 정책 서버, lerobot의 비동기 스택, 업링크 속도가 충분한지 미리 알려주는 계산법, 그리고 플랫폼 경로입니다. 이 모든 것은 2026년 8월 23일 Isaac-GR00T 메인 브랜치 (N1.7 GA) 및 lerobot 0.6.1을 기준으로 확인되었습니다.

정책이 로봇 머신에 맞지 않는 이유

AY-Robots가 훈련할 수 있는 5가지 정책 중 2가지는 워크스테이션 카드에서 실행되고, 3가지는 그렇지 않습니다. 아래 열은 각 액션 단계당이며, 이는 네트워크 왕복 시간과 경쟁하는 숫자입니다.

이것을 사소한 정보가 아닌 결정으로 받아들이십시오. ACT는 단계당 20ms로 로봇 머신에서 실행되며, 다시는 신경 쓸 필요가 없습니다. Pi0.5는 485ms로, 패킷이 건물 밖으로 나가기 전에 이미 3분의 1초를 소비합니다. 정책 비교 및 GR00T N1.7 vs Pi0.5는 정확도 측면을 추가합니다.

이미 존재하는 두 가지 클라이언트-서버 스택

Isaac-GR00T는 ZeroMQ 요청-응답 서버를 제공하며, lerobot은 비동기 추론을 중심으로 구축된 gRPC 서버를 제공합니다. 둘 다 GR00T 체크포인트. lerobot이 지원하는 정책 목록은 async_inference/constants.py이며, 로봇 목록은 so100_follower, so101_follower, bi_so_follower 및 omx_follower입니다.

직렬화 방식은 겉보기보다 중요합니다. GR00T의 MsgSerializer는 양방향으로 객체-dtype ndarray 페이로드를 거부합니다. msgpack_numpy가 그렇지 않으면 이를 pickle에 넘겨주기 때문입니다. lerobot은 대신 pickle을 사용합니다: policy_server.py는 pickle.loads를 요청 데이터에 대해 호출하고, robot_client.py는 전송하는 관측값을 pickle합니다. 신뢰할 수 있는 LAN에서는 방어할 수 있지만, 포트가 인터넷에서 접근 가능해지면 방어할 수 없습니다.

경로 A: NVIDIA 자체 GR00T 정책 서버

이것은 NVIDIA가 SO-100 및 SO-101 하드웨어에 대해 문서화한 경로이며, 체크포인트가 examples/finetune.sh에서 --embodiment-tag NEW_EMBODIMENT로 생성된 경우 사용해야 하는 경로입니다. 이 단계들은 상위 README에서 빠진 내용을 추가합니다: 포트를 다른 사람들에게 노출하지 않고 로봇으로 가져오는 방법입니다.

1. 1
   임대 GPU 박스에 GR00T 설치

   서브모듈이 필요하며, 클론하기 전에 git-lfs가 존재해야 합니다. 그렇지 않으면 demo_data의 parquet 파일이 포인터로 도착합니다. flash-attn 및 TensorRT는 기본 설치에 포함되어 있습니다. 새로운 pod 이미지의 함정: 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를 로드합니다. 모델 페이지에서 접근을 요청하고 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 터널링

   위와 같이 루프백에 바인딩하고 SSH 또는 WireGuard 스타일 메시를 통해 포트를 전달하십시오. 이는 ZeroMQ 소켓이 제공하지 않는 암호화 및 인증을 약 1밀리초 동안 제공합니다.

   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 체크포인트와도 작동합니다.

# 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 문서에서는 SmolVLA 논문을 따라 두 번째 것을 g라고 부릅니다), 그리고 문서화된 값과 실제 제공되는 값이 일치하지 않습니다.

링크 속도가 충분한지 결정하는 계산

사람들은 이것을 건너뛰고 하루 종일 에 매달립니다. 2분이면 충분하며 거의 항상 결정적입니다.

NVIDIA의 eval_so100.py에 주석 처리된 관측 딕셔너리는 전송되는 내용을 보여줍니다: uint8 형식의 (480, 640, 3) 모양 배열 두 개, 6개의 조인트 부동 소수점 값, 언어 문자열. 이는 프레임당 921,600바이트, 두 대의 카메라에 대해 1,843,200바이트이며 약 14.7Mbit입니다. 어떤 스택도 이를 JPEG 압축하지 않습니다. 돌아오는 청크는 6개의 부동 소수점 값으로 구성된 수십 단계입니다. 다운로드가 아닌 업로드가 모든 것을 결정합니다.

맞춰야 할 예산

GR00T SO-100 클라이언트는 동기식입니다. 즉, policy.get_action(obs)를 호출하고, 청크의 첫 action_horizon 단계를 30 FPS로 실행한 다음 다시 호출합니다. 청크 크기와 호라이즌은 다른 숫자입니다. NVIDIA의 배포 가이드는 액션 청크 크기를 16으로 권장하며, 실시간 청킹과 결합할 경우 최소 32를 권장합니다. 반면 eval_so100.py는 실행 호라이즌을 8로 제공합니다. 30 FPS에서 8단계는 호출당 267ms의 동작이며, 다른 모든 것은 그 안에 맞춰져야 합니다.

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

호라이즌을 늘리는 것은 단순한 해결책이며 공짜가 아닙니다. 로봇 팔은 이제 오래된 관측값에 따라 작동하게 됩니다. 원칙적인 해결책은 실시간 청킹(RTC)입니다. 이는 현재 청크가 실행되는 동안 다음 청크를 계산하고, 실행이 보장된 액션을 고정하며, 나머지를 채워 넣습니다. RTC 논문은 재훈련 없이 추론 지연에 강건하다고 보고합니다. 먼저 그 현황을 확인하십시오. NVIDIA는 RTC를 실험적인 기능으로 표시하며, 다음을 통해 접근할 수 있는 저수준 모델 프리미티브입니다. action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...}), Gr00tPolicy 또는 서버-클라이언트 경로에 연결되어 있지 않으며, 여기서 options는 사용되지 않고 테스트나 예제도 없습니다. 정책 서버를 통해 비동기 실행을 얻을 수 있으며, RTC는 아닙니다.

신뢰하기 전에 측정하십시오

위에 제시된 모든 숫자는 예측입니다. 네 가지 명령을 통해 이를 측정값으로 바꿀 수 있으며, 애초에 작동하지 않을 작업에 pod-hour를 투입하기 전에 실행해 볼 가치가 있습니다.

1. 1
   원시 왕복 시간 얻기

   CDN이 아닌 pod를 대상으로 합니다. 평균만큼 편차를 면밀히 관찰하십시오. 평균 지연 시간이 아니라 지터가 로봇 팔을 버벅거리게 만듭니다.

   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 로봇 클라이언트는 모든 청크에 대해 서버-클라이언트 지연 시간과 역직렬화 시간을 기록합니다. 경로 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를 전달하면 클라이언트가 런타임에 큐 크기를 플로팅합니다. 큐 크기가 반복적으로 0에 도달하면 예산이 부족한 것입니다. 이 경우 fps를 낮추거나, actions_per_chunk를 높이거나, chunk_size_threshold를 높여 관측값이 더 자주 전송되도록 하십시오.

   bash

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

원격 추론이 실제로 유용한 경우

원격 실행이 모든 에피소드에서 동일한 지점에서 끊긴다면, 네트워크가 원인이 아닐 가능성이 높습니다. 매번 동일한 관절 각도에서 주저하는 정책은 일반적으로 데이터 문제입니다. 실패 모드 페이지, 특히 특정 설정에서만 작동하는 정책 및 손실은 감소하지만 정책이 아무것도 하지 않는 경우.

직접 하는 것과 AY-Robots에서 하는 것

원격 추론 세션 비용

두 가지 숫자가 중요합니다: 카드의 시간당 요금과 얼마나 오랫동안 실행하는지입니다. 첫 번째는 공개되어 있지만, 두 번째는 사람들을 놀라게 합니다.

이 요금은 2026년 8월 23일 Runpod의 가격 책정 페이지에서 확인되었으며, 현물 시장은 변동합니다. AY-Robots는 대신 전체 실행 시간을 기준으로 견적을 제시합니다: A100 또는 H100 티어에서 시간당 1.20~2.00 USD로 3~6시간, GR00T 또는 Pi0.5 실행에 약 4~12 USD; 24 GB 티어에서 시간당 0.30~0.60 USD로 2~5시간, SmolVLA 또는 ACT에 1~3 USD. 추론 세션은 유휴 감시자가 존재하는 이유인, 세션을 중지할 경우에만 훈련 실행보다 비용 효율적입니다. 결제 문서 및 가격 책정 페이지를 참조하십시오.

네트워크를 루프에 포함시키지 않으려면

원격 추론은 하드웨어 문제를 해결하고 지연 시간 문제를 발생시킵니다. 때로는 보유한 하드웨어에 맞는 정책이 더 나은 해결책이 될 수 있습니다.

• ACT, 약 8천만 개의 매개변수와 액션 단계당 20ms, 최소 50 에피소드, 모든 24GB 카드. 반복적인 단일 작업 설정에서 패킷을 기다리지 않기 때문에 원격 3B 모델을 자주 능가합니다.
• SmolVLA, 약 4억 5천만 개의 매개변수와 액션 단계당 245ms, 최소 30 에피소드. ACT에 부족한 언어 조건화를 유지하며, lerobot 문서는 추론 시 약 2GB를 차지하며 PI0의 약 14GB와 비교됩니다.
• ACT 대 GR00T N1.7 (정확도 측면)

중간 경로도 있습니다: 클라우드에서 훈련하고 로컬에서 평가하는 것입니다. 미세 조정은 80GB 카드가 필요하며 지연 시간에 신경 쓰지 않으므로 SO-100에서 GR00T N1.7 훈련 원격으로 하는 것은 논란의 여지가 없습니다. 평가 루프만이 실시간 제약 조건을 가집니다. 훈련 문서와 모델 및 암 매트릭스가 그 절반을 다룹니다.

자주 묻는 질문

요약

3 B 정책에 대한 원격 추론은 해결된 공학적 문제이지만, 해결되지 않은 물리적 문제가 수반됩니다. 공학적 측면은 두 개의 명령과 SSH 터널입니다. 물리적 측면은 1.8 MB의 관측값이 다른 나라에 있는 GPU에 도달하여 로봇 팔이 동작을 다하기 전에 돌아와야 한다는 것입니다. 무엇이든 임대하기 전에 계산을 하고, 오래된 관측값을 허용하는 작업을 선택하며, 링크가 개선되기를 바라기보다는 실행 지평을 높이십시오.

아직 데이터셋을 기록하지 않았다면, 첫 데이터셋 기록하기 및 SO-100 설정 가이드를 먼저 참조하고, LeRobot 데이터셋 형식 항목에서 레코더가 기록하는 내용을 설명합니다. 배경 지식은 시각-언어-행동 모델 및 플로우 매칭 정책 작업; 아레나 항목에서 모든 벤치마크 숫자가 출처에 연결되어 있습니다.