ロボットの「脳」をクラウドに置こうとしているなら、申込フォームを出す前に読んでほしい。
Hugging Faceのロボティクス部門には今、3万6,917個のモデルが並んでいる（10月20日に筆者が確認）。手元で動かせるロボット用のAIは、すでにこれだけ出回っている。
- 名前に「smolvla」を含むモデルが6,102個
- 名前に「pi05」（Physical Intelligenceのπ0.5）を含むモデルが3,520個
- 2つを合わせると26.1%。4つに1つを超える
ところが、そのπ0.5を作ったPhysical Intelligence（以下PI）は、10月13日に逆の道を選んだ。最新モデルを、クラウドのAPIで開いたのだ。発表の書き出しはこうだ。
We are making our latest models available for training and inference through the Pi API beta.
自分のロボットのデータを上げ、PIが管理する計算資源で微調整し、ホスト型のゲートウェイ越しに推論する。事前に使った会社は日本、スイス、米国各地に広がり、ユタ州では運転席に誰もいないホイールローダーが、資材をすくってダンプに積んでいる。発表によれば、公開した事例の大半がクラウドで推論していた。そして一部では通信の問題が起きたことも、PI自身が認めている。
そのAPIの申込フォームには、こんな質問がある。
Where do you need to run inference?
Cloud / Local (on your own hardware) / Both / Not sure yet
ロボットの脳を、どこに置くか。この1問に、数字で答えられるだろうか。
結論から言うと
1. 「Cloud」を選ぶ前に、自分のロボットからGPUまでの遅延を測り、行動の何ステップ分にあたるかを計算すること。
計算は d = ⌊遅延 ÷ 制御周期⌋ だけだ。PIの論文の設定（50Hz、1回の推論で50ステップ＝1秒分）なら、遅延200msで10ステップになる。
2. PIの論文値で試算すると、日米の往復を足した遅延は約208ms。PIが新しい学習方式で想定した上限200msの、ちょうど境目だ。
遠隔のH100で測った108msに、Azureの東日本から米国西部への往復100ms（中央値）を足した筆者の計算だ。一方、古い方式は+200msの遅延を足した実験でも劣化しなかった。
3. ただし怖いのは、平均の遅さより途切れることだ。1回の推論で手に入る行動は1秒分しかない。
しかもAPIの価格、GPUの場所、どちらの方式を使っているかは、どれも公表されていない。
図: PIの学習時RTCの論文の実測108msに、日米の往復100msを足した試算。GPUの場所ごとの遅延と合わせて筆者が作図
数字は2026年10月20日時点。APIの内容は、PIの発表（10月13日）と申込フォームによる。遅延の実測値はPIの2本の論文（2025年6月の推論時RTC、2025年12月の学習時RTC）から、往復時間はMicrosoftが公表しているAzureのリージョン間の中央値（2026年7月30日までの30日間）から借りた。APIで使われるモデルの名前、行動チャンクの長さ、どちらのRTCを使うか、GPUの場所、価格はいずれも公表されておらず、試算はすべて筆者の単純な足し算だ。筆者はPIのAPIもロボットも動かしていない。
数字で見るPi APIとロボットの遅延
| 項目 | 値 |
|---|---|
| Pi API β | 2026年10月13日公開。少数の会社から順番に受け入れ |
| 使い方 | データを上げる → PIの計算資源で微調整 → ホスト型ゲートウェイで推論 |
| 公開事例の推論 | 大半がクラウド（日本、スイス、米国各地） |
| モデル名・価格・GPUの場所 | 非公開 |
| 制御周期と行動チャンク | 50Hz（1ステップ20ms）、1回の推論で50ステップ＝1秒分（π0.5の論文設定） |
| LAN越しの総遅延（π0.5、RTX 4090） | 移動ロボット139ms、据え置き109ms |
| 遠隔H100での総遅延（π0.6、学習時RTC） | 108ms |
| 学習時RTCが想定する遅延 | 最大200ms（0〜10ステップ） |
| 東日本→米国西部2の往復（Azure） | 100ms（中央値） |
| Hugging Faceのロボティクス部門 | 3万6,917モデル（smolvla 6,102、pi05 3,520） |
同じ建物の中のGPUにつないでも、移動ロボットは推論1回に139msかかっている。50Hzなら139÷20＝6.95で、切り捨てて6ステップ。新しい指令が届くまでの間、ロボットは前の計画のまま6歩ぶん動いている。
ここまでは「ロボットのAIもAPIで借りられるようになった」という話。面白いのはその先だ。
なぜロボットは「1秒先」までまとめて動くのか
50Hzの世界で、VLAの推論は間に合わない
VLA（Vision-Language-Action）は、カメラの画像と指示文を受け取り、関節の動きを出力するモデルだ。PIのπ0.5は、1回の推論で50ステップ分の行動をまとめて出す。これを行動チャンクと呼ぶ。
理由は単純だ。π0.5の実験で使った制御周期は50Hz、つまり20msごとに次の指令が要る。ところがRTCの論文によると、RTX 4090で推論すると、モデル本体だけで76msかかる。1ステップごとに推論していたら間に合わない。
だから1秒分をまとめて出し、その間に次の1秒分を考える。問題はつなぎ目だ。
| つなぎ方 | 何が起きるか |
|---|---|
| 同期（使い切ってから次を推論） | 推論のたびにロボットが止まる。遅延が増えるほど作業が遅くなる |
| 重なりを平均する（temporal ensembling） | +100msの遅延で振動し、ロボットの保護停止が作動して動けなかった |
| そのまま切り替える | 新旧のチャンクが食い違い、急な加速やカクつきが出る |
平均でつなぐ方式について、論文はこう書いている。
both TE variants do not run at all due to causing such high oscillations that the robot’s protective stop is triggered
RTCは「もう変えられない未来」を固定して、残りを描き直す
PIが2025年6月に出したRTC（Real-Time Chunking）は、このつなぎ目を「穴埋め」の問題として解いた。
推論にかかる時間をδ、制御周期をΔtとすると、論文は遅延をステップ数で定義する。
d = ⌊δ / Δt⌋ （次のチャンクが届くまでに、前のチャンクのまま実行してしまうステップ数）
先頭のdステップは、新しいチャンクが届く前に必ず実行されるので、もう変えられない。RTCはここを前のチャンクの値に固定し、残りを新しい観測に合わせて描き直す。重みは固定部分で1、その先で1から0へ指数的に減らし、チャンクの後ろ側は0（自由に描き直す）にする。
もう1つ大事な制約がある。1本のチャンクから実行するステップ数をs、チャンクの長さをHとすると、非同期で回すには d ≤ s ≤ H − d が必要だ。ここから d ≤ H/2 が出る。H＝50なら d ≤ 25、遅延にして520ms未満が理論上の天井になる（論文の制約からの筆者の計算）。
# 推論時RTCの流れ（論文の説明を筆者が簡略化した擬似コード・未実行）
H, DT = 50, 0.020 # 1チャンク50ステップ、制御周期20ms（50Hz）
chunk = policy.sample(robot.observe())
while True:
obs = robot.observe()
d = floor(p99_latency() / DT) # 推論の間に進んでしまうステップ数
future = start_async( # 別スレッドで次のチャンクを推論
policy.inpaint, obs,
frozen=chunk[:d], # 必ず実行される部分は固定
weights=soft_mask(d, H)) # 1から0へ指数的に減る重み
execute(chunk[:d]) # 待つ間も、前のチャンクで動き続ける
chunk = future.result()[d:] # 届いたら、まだ実行していない部分から使う
実機の結果はこうだ。6種類の作業で、作業と方式の組ごとに10回ずつ試し、計480エピソード（約28時間）を比べた。+100ms（d≈11）、+200ms（d≈16）の遅延を足しても、RTCの作業効率は落ちなかった。
RTC is completely robust to injected delay, showing no degradation
同期方式は、遅延に比例して効率が落ちた。PIの解説ページは、マッチを擦る、イーサネットケーブルを挿すといった精密な作業を、300msを超える遅延で完了したとも書いている。
この実験の遅延の内訳も公開されている。モデルは別のRTX 4090マシンで動かし、ロボットとはLANでつないでいる。
| 内訳 | 移動ロボット | 据え置き |
|---|---|---|
| モデル（RTC込み） | 96.89ms | 97.43ms |
| 通信（LAN） | 21.20ms | 6.89ms |
| 画像の縮小（ロボット側のCPU） | 11.22ms | 1.44ms |
| その他 | 9.67ms | 3.00ms |
| 合計 | 138.98ms | 108.76ms |
移動ロボット側の計算機はIntel NUC、据え置き側はRyzen 9 7950Xのワークステーションだ。同じ建物の中でも、ロボット側の通信と計算機の差だけで約30ms（138.98 − 108.76 ＝ 30.22ms）開く。
新しい方式は「遅延の上限」を学習の時点で決める
2025年12月、PIは学習時RTCを出した。推論のたびに穴埋めの計算（逆伝播を含む）をする代わりに、学習中に遅延を模擬し、先頭の行動を条件として与えておく。推論時の追加の計算はなくなる。
ただし、模擬する遅延の幅は学習の時点で決める。論文の実機実験の設定はこうだ。
We sample delays uniformly between 0 and 10 during training, which supports a maximum latency of 200ms on a 50Hz robot.
論文は、この方式の弱点もはっきり書いている。
However, training-time RTC is fundamentally less flexible than inference-time RTC
| 項目 | 推論時RTC（2025年6月） | 学習時RTC（2025年12月） |
|---|---|---|
| 仕組み | 推論中に先頭dステップを固定し、残りを描き直す | 学習中に遅延を模擬し、先頭の行動を条件に与える |
| 推論時の追加計算 | あり（π0.5で76ms→97ms） | なし |
| 想定する遅延 | 理論上は d ≤ 25（H＝50）。+200ms（d≈16）まで劣化なし | 学習で模擬した0〜10ステップ（最大200ms） |
| 実験のモデルと総遅延 | π0.5、LAN越しのRTX 4090で139ms／109ms | π0.6、遠隔のH100で108ms（d≈5） |
| 想定より遅延が増えたら | 制約の範囲ならそのまま使える | 論文は挙動を報告していない |
π0.6の実験では、推論時RTCも135ms（d≈7）で動かし、2つの方式の作業成績は同程度だった。差が出るとすれば、遅延が想定を超えたときだ。
新しい方式ほど、遅延の上限を最初に決め打ちする。 クラウドに脳を置くなら、ここが効いてくる。
GPUを海の向こうに置いたら何msか（試算）
PIは、APIのGPUがどこにあるかを公表していない。ここからは仮定の計算だ。
材料は2つある。学習時RTCの論文で遠隔のH100を使ったときの実測108msと、Azureの公表値にあるリージョン間の往復時間（2026年7月30日までの30日間の中央値）だ。108msのうち通信が何msかは論文に書かれていないので、GPUが論文と同じくらい近い状態から、遠くなった分の往復をそのまま足す。
| GPUの場所（仮定） | 足す往復 | 合計 | d（50Hz） | 学習時RTCの想定（0〜10） | 推論時RTCの実験（+200msまで劣化なし） |
|---|---|---|---|---|---|
| 論文と同じ近さ | 0ms | 108ms | 5 | 内側 | 内側 |
| 国内の別リージョン（東日本→西日本） | 11ms | 119ms | 5 | 内側 | 内側 |
| 米国西部（東日本→米国西部2） | 100ms | 208ms | 10 | 境目 | 内側 |
| 米国東部（東日本→米国東部） | 162ms | 270ms | 13 | 外側 | 内側 |
日米の往復を足すと208ms。論文が書く「最大200ms」を8ms超えるが、ステップに直すと208÷20＝10.4で、切り捨ててd＝10。学習で模擬した0〜10の、ちょうど端に乗る。
移動ロボットならさらに厳しい。前の表で、移動ロボットは据え置きより約30ms遅かった。同じ差が乗れば238msでd＝11、学習の範囲の外に出る計算だ。
一方、推論時RTCの実験は+200msまで劣化がなかったので、米国東部の往復162msでもその範囲に収まる。同じ往復時間でも、方式によって「余裕」と「想定の外」に分かれる。 APIでどちらが使われているかは、公表されていない。
ロボットの中に置く側の数字もある。NVIDIAのモデルカードによると、GR00T N1.7の推論は、データセンター向けのH100で27.9ms、ロボット向けのJetson AGX Thorで93.8msだ（どちらもTensorRT、ノイズ除去4ステップ、カメラ1台）。差は65.9ms。このモデルなら、往復が約66msより長くなるクラウドのH100より、ロボットに載せたThorのほうが早く答えを返す（画像の転送時間などを含まない筆者の計算）。日米の往復100msは、この差を超えている。
正直に言えば、この試算はPIの研究用の構成の値とAzureのリージョン間の中央値を足しただけで、APIのモデル、チャンクの長さ、RTCの方式、GPUの場所はどれも公表されていないので、本当の値はAPIの上で測るしかない。
あなたのロボットからGPUまでの往復は、何msだった？ 構成（有線か無線か、どこのクラウドか）と一緒に、コメントで教えてほしい。
APIを待つ間に試すべき3つのこと
APIは順番待ちだ。だが、遅延の測り方とRTCの効き方は、今日、手元で確かめられる。
1. ロボットなしで、RTCが何をしているか見る
LeRobotにはRTCが組み込まれていて、データセットだけで効き方を図にできる。ドキュメントにあるコマンドはこうだ（CUDAのGPUが要る）。
# LeRobotのリポジトリを取得したディレクトリで
pip install -e ".[pi]"
python examples/rtc/eval_dataset.py \
--policy.path=lerobot/pi0_libero_finetuned \
--dataset.repo_id=HuggingFaceVLA/libero \
--rtc.execution_horizon=10 \
--rtc.max_guidance_weight=10.0 \
--device=cuda
通常の生成とRTCの生成が左右に並び、新しいチャンクの先頭が、前のチャンクの終わりに沿わされていく様子が見える。execution_horizonは前のチャンクと合わせるステップ数で、ドキュメントの目安は8〜12だ。
2. openpiで遠隔推論を組み、自分の遅延を分布で測る
openpiは、モデルを別のサーバーで動かし、WebSocketで行動を送る構成を最初から持っている。リモート推論の説明とsimple_clientを使えば、ロボットがなくても往復の時間を測れる。
# GPUマシン（openpiはUbuntu 22.04で検証。推論にはVRAM 8GB超）
git clone --recurse-submodules git@github.com:Physical-Intelligence/openpi.git
cd openpi
GIT_LFS_SKIP_SMUDGE=1 uv sync
GIT_LFS_SKIP_SMUDGE=1 uv pip install -e .
uv run scripts/serve_policy.py --env DROID
# 測る側のPC（同じリポジトリを用意する）。アドレスは例
uv run examples/simple_client/main.py --env DROID --host 192.168.0.10
simple_clientは、クライアント側で測った1回あたりの時間（client_infer_ms）を、平均、P50、P95、P99で表示する。見るべきは平均ではなくP99だ。 それを20msで割って切り捨てた数が、あなたの構成のdになる。
# 遅延予算の計算（筆者作成・未実行。値は本文の試算と同じ）
from math import floor
def delay_steps(latency_ms: float, hz: int = 50) -> int:
"""観測を送ってから次のチャンクが届くまでに進むステップ数 d"""
return floor(latency_ms / (1000 / hz))
H = 50 # 1チャンクのステップ数（π0.5の論文設定）
TRAINED_MAX = 10 # 学習時RTCが模擬した遅延の上限（論文の実機設定）
for name, ms in [("論文と同じ", 108), ("国内", 119), ("米国西部", 208), ("米国東部", 270)]:
d = delay_steps(ms)
print(name, ms, "ms -> d =", d,
"| 学習時RTCの範囲内:", d <= TRAINED_MAX,
"| 理論上の天井内:", d <= H // 2)
手計算では、dは順に5、5、10、13になり、学習時RTCの範囲を外れるのは米国東部だけだ（米国西部は端のd＝10）。
3. SmolVLAを、別のマシンから非同期で動かす
LeRobotの非同期推論は、推論サーバー（PolicyServer）とロボット側のクライアント（RobotClient）を分ける。ロボットは手持ちの行動を実行しながら、残りが閾値を切ったら次の観測を送る。ドキュメントのコマンドを、LAN内のGPUマシンにつなぐ形に書き換えるとこうなる（アドレス、ポート、ロボットとカメラの設定は例。筆者は実行していない）。
# GPUマシン側
python -m lerobot.async_inference.policy_server \
--host=192.168.0.10 \
--port=8080
# ロボット側（SO-100の例。カメラのキーはポリシーが期待する名前に合わせる）
python -m lerobot.async_inference.robot_client \
--server_address=192.168.0.10:8080 \
--robot.type=so100_follower \
--robot.port=/dev/tty.usbmodem585A0076841 \
--robot.id=follower_so100 \
--robot.cameras="{ laptop: {type: opencv, index_or_path: 0, width: 1920, height: 1080, fps: 30}}" \
--task="dummy" \
--policy_type=smolvla \
--pretrained_name_or_path=lerobot/smolvla_base \
--policy_device=cuda \
--actions_per_chunk=50 \
--chunk_size_threshold=0.5 \
--aggregate_fn_name=weighted_average \
--debug_visualize_queue_size=True
効くパラメータは2つだ。
-
actions_per_chunk：1回に出す行動の数。既定は50で、ドキュメントの典型値は10〜50 -
chunk_size_threshold：手持ちの行動がこの割合を切ったら、次の観測を送る。0に近いと同期と同じになり、1に近いと毎ステップ送る。ドキュメントは0.5〜0.6がうまくいったとしている
--debug_visualize_queue_size=Trueを付けると、手持ちの行動の残量の推移を描ける。残量が0に張り付くなら、推論の遅さに対して制御が速すぎる。 ドキュメントも、行動を使い切るならfpsを下げるよう勧めている。推論時のメモリは、π0の14GBに対してSmolVLAは約2GBで済む。
知らないと損する5つの罠
罠1：平均の遅延で予算を組む
PIの測定でも、通信と画像の縮小はばらついていた（50回の推論の平均±標準偏差）。
Network 21.20 ± 3.12ms (mobile)
Image resize 11.22 ± 5.00ms (mobile)
Azureの往復時間も中央値で、半分の時間はそれより遅い。dは平均ではなく、遅いほうの裾で決まる。学習時RTCなら、dが10を一瞬でも超えた瞬間、モデルは学習で見ていない状況に置かれる。
対策：simple_clientのP99（少なくともP95）でdを計算すること。
罠2：非同期にすれば、つなぎ目の問題も消えると思う
非同期推論は、推論の間にロボットが止まる問題を消す。だが、新旧のチャンクの食い違いは別の問題だ。LeRobotのRTCのドキュメントは、非同期推論は「待ち時間」を、RTCは「チャンクの不連続」を解くものだと整理している。そして重なりを平均するだけの方式は、PIの実験で+100msの遅延のときに保護停止を起こした。
対策：遅延が大きい構成では、非同期推論にRTCを重ねること。LeRobotなら実機の実行に--inference.type=rtcを付ける。ドキュメントも両方を一緒に使うよう勧めている。
罠3：回線が切れたら、手持ちは最大1秒
1本のチャンクは50ステップ、1秒分しかない。通信が切れれば、ロボットは手持ちの行動を使い切った時点で指令を失う。PIの発表も、早期の展開でこんな問題があったと書いている。
including network connectivity challenges for some
Googleは、7月に出したGemini Robotics On-Device 2をロボット側で動かす理由として、まさにこれを挙げている。
Many robotic applications need to operate without network latency or internet connectivity.
対策：手持ちの行動が尽きたら安全に止まる処理を、必ずロボット側に置くこと。止められない作業なら、ロボットの中で動く代わりのモデルを用意する。
罠4：APIのモデルが、知らないうちに新しくなる
PIは発表で、APIの裏のモデルを素早く更新し、最新のモデルを提供し続けると書いている。
Pi can update the models underpinning the API rapidly
版を固定できるのか、更新を知らせるのかは書かれていない。ロボットにとってモデルの更新は、動作が変わることそのものだ。昨日つかめた部品を、今日つかめなくなるかもしれない。
対策：代表的な作業を決めて、毎日同じ条件で成功率を測ること。結果は日時と一緒に残しておく。
罠5：上げたデータが、次のモデルの材料になるか分からない
申込フォームが聞くのは遠隔操作データと模擬データの時間数で、データの扱いには触れていない。一方、PIが2月に出したパートナーの記事には、パートナーのデータを事前学習に入れた場合と入れない場合を比べたグラフがある。
UPT = Ultra data included in pre-training (+UPT = included, -UPT = not included).
パートナーのデータがPIの事前学習に入った例は、すでにあるということだ。APIで上げたデータがどう扱われるかは、公開されている情報からは分からない。
対策：規約でデータの使い道を確認できるまで、人の顔や社外秘の工程が映った映像は上げないこと。
推論の置き場所3択と、今すぐ試せる代替5選
置き場所3択
| 置き場所 | 足される通信 | 推論の速さの例（公表値） | 強み | 弱み | 今使える例 |
|---|---|---|---|---|---|
| クラウド | WANの往復（東日本→米国西部2で100ms） | 非公開 | 最新モデル。GPUと微調整を任せられる | 切断と揺れ。価格とデータの扱いが非公開 | Pi API β（順番待ち） |
| 構内のGPU | LANで6.89〜21.20ms（PIの実測） | π0.5で97ms（RTX 4090、RTC込み） | 遅延が読める。データが外に出ない | GPUの運用。PIの公開重みはπ0.5まで | openpi、LeRobotの非同期推論 |
| ロボットの中 | なし | GR00T N1.7で93.8ms（Jetson AGX Thor、TensorRT） | 切断に強い | 載せられるモデルの大きさと速さに限りがある | GR00T N1.7、SmolVLA、Gemini Robotics On-Device 2（早期アクセスのパートナー限定） |
代替5選（Hugging Faceのデータ、10月20日に取得）
| モデル | 提供元 | パラメータ | ライセンス | 直近30日のDL | 名前を含むモデル数 | 推論の目安 |
|---|---|---|---|---|---|---|
| SmolVLA（lerobot/smolvla_base） | Hugging Face | 0.45B | Apache-2.0 | 150,095 | 6,102 | 推論時メモリ約2GB |
| GR00T N1.7（nvidia/GR00T-N1.7-3B） | NVIDIA | 3.1B | NVIDIA Open Model License | 108,706 | 443 | AGX Thorで93.8ms |
| π0.5（lerobot/pi05_base） | PI（LeRobotが移植） | 3.6B | Gemma | 18,027 | 3,520 | VRAM 8GB超（openpi） |
| MolmoAct2（allenai/MolmoAct2） | Ai2 | 5.4B | Apache-2.0（研究・教育向けと明記） | 14,951 | 308 | 設定によってはbf16で16GB未満 |
| OpenVLA（openvla/openvla-7b） | OpenVLAの研究チーム | 7.5B | MIT | 152,456 | 80 | 1回の推論で1ステップ分 |
パラメータはHugging FaceのAPIが返すsafetensorsの合計、直近30日のDLはモデルページの「Downloads last month」の値だ。名前を含むモデル数は、ロボティクス部門でsmolvla、groot、pi05、molmoact、openvlaを検索した件数で、派生モデルのおおまかな目安にすぎない。MolmoAct2のライセンスは、Hugging FaceのカードではなくGitHubの記載による。
表から読み取れること：
- 直近30日のDL数1位は、2024年6月に論文が出たOpenVLA（15万2,456）。 ただし1回の推論で1ステップ分しか出さないので、遠隔推論とは相性が悪い（筆者の見立て）。
- 派生が最も多いのはSmolVLA（6,102）。 0.45Bで、推論時のメモリは約2GB。ロボットの中に置くなら筆頭だ。
- π0.5の重みは、ApacheではなくGemmaの条件で配られている。 openpiのコード自体はApache-2.0だ。商用で使う前に条件を確かめること。
- PIの最新モデルは、この表のどこにもない。 openpiの公開重みはπ0、π0-FAST、π0.5までで、Hugging FaceのPIの組織ページにあるモデルはFASTトークナイザー1つだけだった。最新世代を使う道は、今のところAPIしかない。
構内のGPUやロボットの中で、微調整したπ0.5やSmolVLAをRTC付きで動かすなら、LeRobotのドキュメントにある実行コマンドがそのまま土台になる（ロボット、ポート、カメラ、タスクは例。筆者は実行していない）。
lerobot-rollout \
--strategy.type=base \
--policy.path=${HF_USERNAME}/policy_repo_id \
--inference.type=rtc \
--inference.rtc.execution_horizon=10 \
--inference.rtc.max_guidance_weight=10.0 \
--robot.type=so100_follower \
--robot.port=/dev/tty.usbmodem58FA0834591 \
--robot.cameras="{ gripper: {type: opencv, index_or_path: 1, width: 640, height: 480, fps: 30}, front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}" \
--task="Move green small object into the purple platform" \
--duration=120 \
--device=cuda
教訓：ロボットの脳は「速いGPU」より「近いGPU」に置く
✗ "クラウドのGPUのほうが速い" → GR00T N1.7はH100で27.9ms、Thorで93.8ms。差の66msは日米の往復100msで消える
✗ "同じ建物のLANなら遅延はほぼゼロ" → π0.5のLAN越し推論でも、移動ロボットで139ms
✗ "遅延は平均で見ればいい" → 学習時RTCが想定したのは最大200ms。裾が超えた瞬間は想定の外
✗ "チャンクは平均でつなげばいい" → +100msで振動し、ロボットの保護停止が作動した
✗ "APIのモデルは昨日と同じ" → Pi can update the models underpinning the API rapidly
PIのAPIは、ロボットの世界にLLMと同じ「頭脳をAPIで借りる」形を持ち込んだ。サンフランシスコのAlmondは、自社の双腕ロボットが自分の組み立てに使うスペーサーのバリ取りを、APIで4日試行錯誤したモデルにやらせている。自前のGPUなしで最新モデルを試せるのは、大きな前進だ。
ただ、チャットと違ってロボットは待ってくれない。50Hzの制御では20msが1ステップで、推論の遅れはそのまま「前の計画で動く時間」になる。今日、自分のロボットからGPUまでの往復をP99で測り、20msで割ってみてほしい。その数字が、申込フォームの答えになる。
参考リンク
Frontier Models for Every Robot: Announcing our API beta - Physical Intelligence
Pi API beta waitlist - Physical Intelligence
Real-Time Action Chunking with Large Models - Physical Intelligence
Real-Time Execution of Action Chunking Flow Policies - arXiv:2506.07339
Training-Time Action Conditioning for Efficient Real-Time Chunking - arXiv:2512.05964
The Physical Intelligence Layer - Physical Intelligence
openpi - GitHub
Running openpi models remotely - openpi
simple_client - openpi
Real-Time Chunking (RTC) - LeRobot Docs
Asynchronous Inference - LeRobot Docs
Azure network round-trip latency statistics - Microsoft Learn
GR00T-N1.7-3B - Hugging Face
Gemini Robotics 2 brings whole body intelligence to robots - Google DeepMind
Gemini Robotics On-Device 2 - Model Card - Google DeepMind
lerobot/smolvla_base - Hugging Face
lerobot/pi05_base - Hugging Face
MolmoAct2 - GitHub
openvla/openvla-7b - Hugging Face
Models: robotics - Hugging Face
Physical Intelligence - Hugging Face
この記事が役に立ったら、いいねと保存を！ PIのAPIに申し込もうとしているロボット屋の同僚にも、フォームを出す前にシェアしてあげてほしい。
コメントで教えてほしい。
- あなたのロボットの推論、Cloud？ Local？ Both？
- ロボットからGPUまでの往復、P99で何msだった？
- 最新モデルをクラウドで借りる？ それともSmolVLAやπ0.5を手元で回す？