Jetson-PI:北京大学発オープンソースのVLAエッジリアルタイム制御、Jetson Orinで制御周波数が8.66倍に

·Toolin 編集部

北京大学 AIRS と PrimeBot が Jetson-PI(Apache-2.0)をオープンソース化。FAAC 非同期推論 + 確信度スケジューリング + llama.cpp エンジンの三段構えで、π0.5 を Jetson Orin 上で 0.70Hz から 6.06Hz へ引き上げ、精度は落としません。

Jetson-PI:北京大学発オープンソースのVLAエッジリアルタイム制御、Jetson Orinで制御周波数が8.66倍に

VLA(Vision-Language-Action)モデルを RTX 4090 のワークステーションからロボットの機体上へ移すことは、具身知能(embodied AI)実装の難所であり続けてきました。π0.5 が NVIDIA Jetson Orin 上で1回推論するのに約1.4秒かかり、対応する制御周波数はわずか約 0.7 Hz——ロボットの動きは緩慢で、連続するアクションチャンクの間には目に見える止まりが生じます。北京大学、AIRS と PrimeBot Research Institute が共同でオープンソース化した Jetson-PI(Apache-2.0)は、一式そろった解を提示します。量子化にも、プルーニングにも頼らず、非同期推論アルゴリズム・モデルスケジューリング・低レベル推論エンジンの3層に同時に手を入れ、π0.5 の Jetson Orin 上での制御周波数を 6.06 Hz(8.66倍) まで引き上げ、しかも精度を落としません。これは「研究室のデモ」から「工業グレードで長時間動き続けられる」へ向かう、決定的な一歩です。

論文:https://arxiv.org/abs/2607.12659 非同期推論コード:https://github.com/PKU-SEC-Lab/Jetson-PI エッジ推論エンジン:https://github.com/PKU-SEC-Lab/Jetson-PI-Edge

問題:エッジ側 VLA の課題は「推論が遅い」だけではない

従来の同期推論では、ロボットはモデルが完全なアクションチャンクを生成し終えるのを待ってから実行を始めねばならず、エッジデバイスの算力は限られているため、推論遅延はそのまま長い停止として現れます。自然な解法が非同期推論です:現在のアクションチャンクを実行している間に、モデルが次のアクションチャンクを並列で予測する。しかし非同期推論は2つの新しい問題を持ち込みます。

  1. 知覚—実行のズレ:モデルが次のアクションチャンクを予測するのに使うのは推論開始時点の画像ですが、アクションが実際に実行される頃にはロボットと環境はすでに変化しており、遅延が長いほどズレは大きくなります。
  2. 反応時間が長すぎる:並列化しても、環境変化(物体の滑り、位置の変化)への応答は、依然として VLA 推理一式の遅延に律速されます。エッジ側の1回の推論はしばしば1秒を超えます。

従来の非同期手法は、時間軸上で新旧の軌道を融合させて平滑性を高めようとしましたが、アクション予測そのものは上記の2問題を抱えたままでした。Jetson-PI は違う道を進みます。軌道を融合するのではなく、未来の環境表現を直接予測し、未来の時点からアクションの予測を始めるのです。

コアアルゴリズム:FAAC(先見整合型非同期補正)

Foresight-Aligned Asynchronous Correction(FAAC) は Jetson-PI の手法の核心です。チームは軽量な 未来補正モジュール(Future Correction Module) を訓練しました:

  • 入力:現在時刻に VLM が生成した環境表現 + すでにロボットへ提出済みで、これから実行されるアクション列
  • 出力:これらのアクションの実行が終わった未来の時刻における環境の VLM 環境表現
  • アクションエキスパートは、過去の現在観測に依拠する代わりに、予定された未来時点からアクション列の生成を始める

設計上の抑制も効いています:

  • 完全な未来画像は生成しない(計算コストが高すぎる)
  • VLM の KV Cache 全体を層ごとには補正しない(これも大量の追加推論を招く)
  • VLM の最終層の環境表現だけを圧縮・予測し、補正情報をアクションエキスパートへ送る

未来補正モジュール全体は約 40M パラメータで、完全な VLA モデルのパラメータ量の約 1% にすぎず、エッジデバイスに過大な負担をかけません。訓練時には未来の時間幅をランダムにサンプリングするため、同じ1つの補正モジュールで、Jetson Orin、Jetson Thor、あるいはより高性能な GPU といった異なる遅延に適応できます。

確信度スケジューリング:ロボットに「いつもう一度見るべきか」を学ばせる

未来補正を導入すれば、理論上は1回の VLM 観測の後、未来補正モジュールとアクションエキスパートを繰り返し呼ぶだけでアクションを生成し続けられます。しかし未来補正には誤差があり、それだけに頼り続けると誤りが蓄積していきます。

Jetson-PI の洞察は、VLM とアクションエキスパートの役割分担を読み替えたことです:

  • VLM の主な役目は環境を改めて観察すること。外部世界に対する理解を校正します
  • アクションエキスパート は高頻度のアクション生成を担い、推論が速い

そこで生まれたのが**確信度ベースのスケジューリング機構(Confidence-based Scheduling)**です。未来補正モジュールは、未来の表現を予測すると同時に確信度も出力します。

  • 確信度が閾値より高い → VLM をスキップし、補正済み表現で直接アクションエキスパートを呼ぶ(ロボットはより頻繁に新しいアクションを生成できる)
  • 確信度が閾値を下回る → VLM を再度呼び、環境表現・KV Cache・後続の予測に必要な状態キャッシュを更新する

実測では、アクションが平稳で環境変化を予測しやすい局面では確信度はおおむね高く、つかむ・接触する・置くといった重要ステップでは確信度がはっきり下がり、VLM の再観察が発火します。これは、ロボットが「いつ既存の認識で続めてよく、いつ必ずもう一度見直すべきか」を自分で判断できるようになったことに相当します。

Jetson-PI-Edge:llama.cpp ベースでエッジ推論エンジンを作り直す

アルゴリズムは「いつモデルを呼ぶか」を解決しましたが、π0 / π0.5 を本当にエッジ側のリアルタイム制御に届かせるには、下層の推論システムも作り直す必要がありました。チームは llama.cpp をベースに Jetson-PI-Edge を開発し、VLA 実行の特性に合わせた3つのコア最適化を施しています。

1. 計算グラフの再利用(Graph Reuse)

従来の言語モデルは出力長がデコードの過程で動的に変わり、計算グラフの形も変わります。VLA 推論は違います。カメラ数、画像解像度、アクション次元が固定なら、大部分の入力テンソルは固定サイズで、言語指示も通常短く固定長へパディングできます。そこで最初の推論時に CUDA Graph を構築し、以降は直接再利用することで、制御のたびのグラフ再構築を回避します。

2. GPU 常駐の中間バッファ(GPU-resident Intermediate Buffers)

ViT / LLM / アクションエキスパートの間では、視覚 embedding や KV Cache といった中間結果をやり取りします。汎用の推論フレームワークはこれらを CPU メモリへ書き戻し、次のモジュールが改めて GPU へコピーします——メモリ帯域が限られるエッジデバイスでは、この種の H2D / D2H の往復オーバーヘッドは無視できません。Jetson-PI-Edge は固定サイズの中間結果のために GPU バッファを確保し、ViT、LLM、アクションエキスパートが GPU 上のデータを直接再利用できるようにします。

3. Flow Matching の展開(Flow Unrolling)

π 系のアクションエキスパートは複数回の flow matching デノイズを実行します。1ステップごとに個別に計算グラフを呼ぶと、重複したスケジューリングと kernel launch のオーバーヘッドが発生します。Jetson-PI-Edge は複数回のデノイズを統一の計算グラフへ展開します——初回の構築コストはやや高くなるものの、以降は持続的に再利用でき、ロボットの長時間実行の制御ループに特に向いています。

ベンチマーク:8.66倍の高速化、LIBERO 平均 SR は業界首位

エッジ側の遅延(NVIDIA Jetson Orin, MAXN, ms)

段階PI0.5 総遅延PI0 総遅延
Naive1420.8(ViT 152.3 / LLM 631.0 / AE 536.8)1250.9
+Schedule optimization1420.81251.5
+Graph reuse476.1444.4
+Buffer + Unroll412.9(ViT 79.5 / LLM 210.3 / AE 123.1)394.5(ViT 75.4 / LLM 200.3 / AE 118.8)

確信度スケジューリングと組み合わせると、システムの反応時間はさらに 165.1 ms まで下がり、制御周波数は 6.06 Hz に達します。素の PyTorch(0.70 Hz)比で 8.66倍です。注意したいのは、この高速化は量子化やプルーニングを前提としないという点で、理論上は量子化・プルーニングと組み合わせてさらなる遅延低減も可能です。

LIBERO(π0.5)4サブセットの平均成功率 SR

Jetson-PI(Ours+Sched)は4つのサブセットすべてで首位でした:

サブセットJetson-PI SR
SPATIAL97.4
OBJECT98.6
GOAL96.8
LIBERO-1092.5

非同期遅延が大きくなるにつれ、ロボットの未来状態だけを予測する VLASH の性能は明確に下滑します。Δ=9 のとき、Jetson-PI は4サブセット平均で VLASH 比 45.6ポイント、RTC 比 7.0ポイント 高く、全体平均では VLASH 比 14.8 pp、RTC 比 3.9 pp 高いという結果でした。この実験が示すのは、エッジ側 VLA は「推論を速くする」だけでなく、遅延の間にロボットが実行するアクションが未来の環境をどう変えるかを、モデルが理解できるようにしなければならない、ということです。

実機ロボット実験

PrimeBot X2-W ロボット(頭部カメラ1 + 腕部カメラ2、224×224、15 Hz でアクション実行)を使い、タスクを衣類のピックアップ / 広げて畳む / 整理してしまうの3サブタスクに分割しました。Jetson-PI の軌跡はより連続で、衣類の操作もより滑らかになり、重要段階で知覚—実行のズレによる失敗が起きません。

訓練側を動かす:Jetson-PI(JAX/Python 3.11)

環境要件

  • OS:Ubuntu 22.04
  • GPU:VRAM 48 GB 以上の NVIDIA GPU(batch 16 の三段階フル訓練)
  • CUDA:12.x(プロジェクト依存として同梱、システム CUDA は不要)
  • Python:3.11(uv / JAX)

インストール

git clone --recurse-submodules https://github.com/PKU-SEC-Lab/Jetson-PI
cd Jetson-PI
git submodule update --init --recursive

export PYTHONNOUSERSITE=1
GIT_LFS_SKIP_SMUDGE=1 uv sync
GIT_LFS_SKIP_SMUDGE=1 uv pip install -e .

# π0.5 PyTorch/JAX 互換性パッチを適用
cp -r ./src/openpi/models_pytorch/transformers_replace/* \
  .venv/lib/python3.11/site-packages/transformers/

重みのダウンロード(ModelScope)

重みリポジトリ zebinyang/Jetson-PI-pi05 には pi05_libero/ と future_correction_module/ の2つのディレクトリがあり、params ツリーをマージしてはいけません。

pip install modelscope
python -c "from modelscope import snapshot_download; snapshot_download('zebinyang/Jetson-PI-pi05', local_dir='./checkpoints/jetson-pi-pi05')"

export PI0_CHECKPOINT=./checkpoints/jetson-pi-pi05/pi05_libero
export WM=./checkpoints/jetson-pi-pi05/future_correction_module

訓練のデフォルトレシピ(π0.5-LIBERO 三段階)

Stageステップ数訓練内容
Stage 130000Action Expert + token reducer(L_act)
Stage 215000Future correction module(L_cond、logvar head なし)
Stage 355000L_cond(reducer なし)+ Pi0 AE 上の L_act + LLM 全体(μ は detached)

handover は H=10、max_delta_t=10、action_encoder=transformer_block で固定します。

bash scripts/train_wm_libero_spatial_four_stage.sh

STAGE1_STEPS / STAGE2_STEPS / STAGE3_STEPS / BATCH_SIZE / NUM_WORKERS / EXP_NAME は上書き(override)でき、ログは logs/<EXP_NAME>.log に出ます。

単発の評価

export PI0_CHECKPOINT=PATH/TO/CHECKPOINT/pi05_libero
export PY_SERVER=PATH/TO/PYTHON   # JAX 入りの venv を指定すること
export WM=PATH/TO/future-correction-module
export CUDA_VISIBLE_DEVICES=0
export PORT=8000

bash scripts/eval_wm_libero_spatial.sh

デフォルトは libero_spatial、1タスク50 trials、H=10, K=9, overlap=1。

確信度スケジューリング(適応的マルチロールアウト):

export LIBERO_WM_EVAL_ADAPTIVE_KAPPA=1
export LIBERO_WM_EVAL_KAPPA_DELTA=0.4
bash scripts/eval_wm_libero_spatial.sh

他のタスクスイートへの切り替え:export LIBERO_WM_EVAL_TASK_SUITE=libero_object|libero_goal|libero_10。

💡 注意点:

  • ModuleNotFoundError: jax → PY_SERVER に JAX 入りの venv を指定する
  • OOM → BATCH_SIZE を下げる / XLA_PYTHON_CLIENT_MEM_FRACTION=0.85 / NUM_WORKERS=0
  • norm_stats が見つからない → --pi0-norm-checkpoint-dir を assets/physical-intelligence/libero/norm_stats.json を含むツリーへ向ける
  • EGL/display の問題 → xvfb を入れるか MUJOCO_GL=egl を指定する

エッジ推論を動かす:Jetson-PI-Edge(llama.cpp)

ビルド

CPU のみ:

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --target llama-server -j

Jetson / CUDA:

cmake -S . -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build --target llama-server -j

フォアグラウンドサーバーの起動

PI_MODEL は auto | pi0 | pi05 をサポートします(デフォルトの auto は GGUF metadata とテンソル名から識別):

PI_MODEL=auto ./build/bin/llama-server \
  -m /path/to/pi_llm.gguf --mmproj /path/to/mmproj.gguf \
  -ngl 99 --host 0.0.0.0 --port 8080

HTTP で単発推論を呼ぶ

順番どおり4ステップです:

  1. POST /foreground/reset — セッションを初期化
  2. POST /foreground/image(2回呼ぶ。2つのカメラ視点分)
  3. PUT /foreground/state(32次元のロボット状態を CSV で)
  4. POST /foreground/infer body {"text":"pick up the object and place it into the tray"}

応答には action_final と encode_ms / decode_ms / total_ms / timing_breakdown_ms が含まれており、モジュールごとに遅延を切り分けられます。

Python Foreground クライアント(制御ステップをまたいで session を再利用)

from jetson_pi_foreground import ManagedForegroundSession

session = ManagedForegroundSession(
    server_path=...,
    model_path=...,
    mmproj_path=...,
    gpu=0,
    port=8080,
    timeout=300,
)

action, metadata = session.predict(
    image_paths=[IMG, IMG],
    prompt='/do something',
    state=state_np_float32,
    reset=True,
)

session.close()

同じ session を再利用すれば、毎ステップの CUDA context 再構築を避けられます——制御ループでは非常に効いてくる、ひとつのはずせない性能節約です。

FlashRT 統合(任意)

C API provider を経由すると、同じ GGUF ランタイムをフロントの HTTP を立てずに FlashRT の Python インターフェースへ公開できます。cmake には -DFLASHRT_CPP_WITH_JETSON_PI=ON -DJETSON_PI_ROOT=/path/to/Jetson-PI-Edge -DGGML_CUDA=ON -DGGML_CUDA_FA=ON を設定し、libflashrt_cpp_llama_cpp_provider_c.so をビルドします。

Roadmap 上のモデル

Jetson-PI フレームワークは π0 / π0.5 に固定されておらず、今後対応が予定されています:

  • NVIDIA Isaac GR00T N1.7
  • LingBot-VLA 2.0
  • Qwen-RobotManip
  • DreamZero
  • FastWAM

適用シーンと限界

向いているケース:

  • Jetson Orin / Thor などのエッジデバイスに VLA をデプロイし、消費電力とバッテリー駆動時間に敏感なモバイルロボットのプロジェクト
  • π0.5 の訓練 + 評価の全流れを通しで回したい具身知能の研究者
  • VLA 推論をリアルタイム制御ループ(15Hz+)に組み込みたいエンジニアリングチーム

現在の限界:

  • 訓練側のハードウェア障壁が高い(VRAM 48 GB 以上)
  • エッジ側の最適化は llama.cpp アーキテクチャに強く結びついており、深いカスタマイズには C++ の経験が要る
  • 実機ロボットの実験データはいまのところ衣類の畳みタスクに集中しており、より多くのタスク種別はコミュニティによる検証待ち

おわりに

Jetson-PI の関心は、VLA のパラメータをより大きく押し上げることではなく、より実際のロボット実装に近い問題を解くことにあります。すなわち、モデルが消費電力・帯域・放熱のすべてに制限された機載デバイス上で動かねばならないとき、どうすれば十分に速い反応速度を保てるのか。答えは3つの部分から成ります。未来の環境表現で非同期推論の知覚—実行ズレを緩和する。確信度スケジューリングで不要な VLM 呼び出しを減らす。VLA の特性に合わせたシステム最適化でエッジ側の実行オーバーヘッドを圧縮する。コード、エンジン、重み、訓練スクリプトがすべてオープンソースです。具身知能に取り組む開発者にとって、2026年にいきなり fork して起点にする価値のあるプロジェクトといえます。

論文:https://arxiv.org/abs/2607.12659 非同期推論コード:https://github.com/PKU-SEC-Lab/Jetson-PI エッジ推論エンジン:https://github.com/PKU-SEC-Lab/Jetson-PI-Edge