ローカルGPUなしでGR00T推論を実行する

Raspberry Piは、シリアルバス経由でを駆動し、2台のUSBカメラからフレームを取得するのに十分です。しかし、30億パラメータのを実行するには不十分です。NVIDIAのREADMEによると、GR00T N1.7の推論には16 GB以上のVRAMを搭載したGPUが1枚必要です。カードを購入せずに、ファインチューニングされたのチェックポイントがアーム上で何をするかを確認するには、ポリシーをレンタルしたクラウドGPUに配置し、ロボットループをUSBポートのあるマシン上で実行し、観測データとアクションチャンクをネットワーク経由で送信します。

この方法は機能しますが、無料ではなく、タスク間でコストが均等に分散されるわけではありません。以下に、NVIDIA独自のポリシーサーバー、lerobotの非同期スタック、アップリンクが十分に高速であるかを事前に判断する計算、およびプラットフォームルートについて説明します。これらすべては、2026年8月23日時点のIsaac-GR00Tメインブランチ（N1.7 GA）とlerobot 0.6.1に対して検証済みです。

ポリシーがロボットマシンに収まらない理由

AY-Robotsがトレーニングできる5つのポリシーのうち2つはワークステーションカードで動作し、3つは動作しません。以下の列はアクションステップごとの値であり、これはネットワークのラウンドトリップと競合する数値です。

それは些細なことではなく、決定事項として捉えてください。 ACTは、ロボットマシン上で20 ms/ステップで動作し、その後は気にする必要がありません。 Pi0.5は、パケットが建物を出るまでに485 ms、つまり3分の1秒を費やしています。 ポリシー比較とGR00T N1.7 vs Pi0.5が精度面を追加します。

既存の2つのクライアント・サーバー・スタック

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です。

シリアライゼーションの行は見た目以上に重要です。GR00TのMsgSerializerは、msgpack_numpyがそれらをpickleに渡してしまうため、object-dtypeのndarrayペイロードを双方向で拒否します。その代わりに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はデフォルトのインストールに含まれています。新しいポッドイメージでの落とし穴：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をロボットマシンにトンネルする

   上記のようにループバックにバインドし、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

サーバーは空の状態で起動します。クライアントの最初のハンドシェイクがポリシーを伝えるまで、どのポリシーを提供するかわかりません。これはレンタルポッドで便利です。アームがスムーズに動くかどうかを決定する2つの調整項目はactions_per_chunkとchunk_size_threshold（lerobotのドキュメントでは、SmolVLAの論文にちなんで後者をgと呼んでいます）であり、ドキュメントに記載されている値と実際に提供されている値は一致しません。

リンクが十分に高速であるかを決定する計算

これを飛ばして、その後一日中に費やしています。これは2分で済み、ほとんどの場合、決定的な解決策となります。

NVIDIAのeval_so100.pyにあるコメント付きの観測辞書は、ワイヤー上で何が起こるかを示しています。uint8形式の(480, 640, 3)の形状を持つ2つの配列、6つの関節フロート、そして言語文字列です。これはフレームあたり921,600バイト、2つのカメラで1,843,200バイト、約14.7 Mbitに相当し、どちらのスタックもJPEG圧縮を行いません。返ってくるチャンクは、6つのフロートからなる数十ステップです。ダウンロードではなく、アップロードがすべてを決定します。

適合させるべき予算

GR00T SO-100クライアントは同期型です。policy.get_action(obs)を呼び出し、最初のaction_horizonステップを30 FPSで実行し、再度呼び出します。チャンクサイズとホライズンは異なる数値です。NVIDIAのデプロイメントガイドでは、アクションチャンクサイズとして16を推奨しており、リアルタイムチャンキングと組み合わせる場合は少なくとも32を推奨しています。一方、eval_so100.pyは実行ホライズンとして8を出荷しています。30 FPSで8ステップは、呼び出しごとに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

ホライズンを増やすのは、腕が古い観測に基づいて動作するため、根本的な解決策ではなく、代償を伴います。原理的な解決策はリアルタイムチャンキングです。これは、現在のチャンクが実行されている間に次のチャンクを計算し、実行が保証されているアクションを固定し、残りを補完します。RTCの論文では、再学習なしで推論遅延に対してロバストであると報告されています。まず、その現状を確認してください。NVIDIAはRTCを実験的と位置付けており、action_head.get_action(..., options={"rtc_overlap_steps": ..., "rtc_frozen_steps": ...})を介してアクセス可能な低レベルのモデルプリミティブであり、Gr00tPolicyやサーバー・クライアントパスには組み込まれていません。そこではoptionsは使用されておらず、テストも例もありません。ポリシーサーバーを介すると、RTCではなく非同期実行が得られます。

信頼する前に測定する

上記のすべての数値は予測です。4つのコマンドでこれを測定値に変えることができます。決して機能しないタスクにポッド時間を費やす前に、これらを実行する価値があります。

1. 1
   生のラウンドトリップを取得する

   CDNではなく、ポッドに対して。平均値と同じくらい偏差に注目してください。平均遅延ではなく、ジッターがアームの動きをぎこちなくさせます。

   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を渡すと、クライアントは実行時にキューサイズをプロットします。繰り返しゼロになる場合、予算オーバーです。fpsを下げ、actions_per_chunkを増やすか、chunk_size_thresholdを上げて観測がより頻繁に出力されるようにしてください。

   bash

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

リモート推論が実際に役立つこと

リモート実行がすべてのエピソードで同じ箇所で途切れる場合、ネットワークが原因ではない可能性が高い。毎回同じ関節角度でポリシーがためらうのは、通常データの問題である。以下の失敗モードのページ、特に特定のセットアップでのみ動作するポリシーおよび損失は減少するがポリシーが何も動作しないを参照のこと。

AY-Robotsで実行する場合と自分で実行する場合

リモート推論セッションのコスト

重要な数字は2つあります。カードの時間料金と、それをどれだけ長く稼働させるかです。前者は公開されていますが、後者は人々を驚かせます。

これらの料金は2026年8月23日にRunpodの料金ページから読み取られたものであり、スポット市場は変動します。AY-Robotsは代わりに全実行の見積もりを出しています：A100またはH100ティアで1時間あたり1.20～2.00 USDで3～6時間、GR00TまたはPi0.5の実行で約4～12 USD；24 GBティアで1時間あたり0.30～0.60 USDで2～5時間、SmolVLAまたはACTで1～3 USD。推論セッションがトレーニング実行よりもコスト面で優位になるのは、停止した場合のみであり、そのためにアイドルウォッチドッグがあります。参照：請求ドキュメント および 料金ページ。

ネットワークを介したくない場合

リモート推論はハードウェアの問題を解決しますが、レイテンシの問題を引き起こします。時には、お持ちのハードウェアに合ったポリシーがより良い解決策となります。

• ACT、約80Mパラメータ、アクションステップあたり20ms、最低50エピソード、24GB以上のカード。反復的な単一タスクのセットアップでは、パケットを待つことがないため、リモートの3Bモデルを頻繁に上回ります。
• SmolVLA、約450Mパラメータ、アクションステップあたり245ms、最低30エピソード。ACTにはない言語条件付けを保持しており、lerobotのドキュメントによると、推論時のメモリ使用量はPI0の約14GBに対し、約2GBです。
• ACT vs GR00T N1.7トレードオフの精度側については。

中間的な方法もあります。クラウドで学習し、ローカルで評価する方法です。ファインチューニングには80GBのカードが必要で、レイテンシは問題にならないため、SO-100でGR00T N1.7を学習することは問題ありません。評価ループのみがリアルタイム制約を持ちます。学習ドキュメントとモデルとアームの対応表がその半分をカバーしています。

よくある質問

要するに

3 Bのポリシーは、未解決の物理問題が伴う、解決済みのエンジニアリング問題です。エンジニアリングは2つのコマンドとSSHトンネルで済みます。物理的な問題は、1.8 MBの観測データが、アームがアクションを使い果たす前に、別の国のGPUに到達して戻ってこなければならないことです。何かをレンタルする前に計算を行い、古い観測データに耐えられるタスクを選び、リンクの改善を期待するのではなく、実行ホライズンを長くしてください。

まだデータセットを記録していない場合は、最初のデータセットを記録するとSO-100セットアップガイドが先に来ます。そしてLeRobotデータセット形式のエントリでは、レコーダーが何を書き込むかを説明しています。背景については、ビジョン言語アクションモデルとフローマッチングポリシーの作業を参照してください。また、アリーナのエントリでは、すべてのベンチマーク番号がソースにリンクされています。