NVIDIAの最新自動運転AI「Alpamayo 2 Super」にグランツーリスモ7を見せたら、ちゃんと車を見つけた話

TL;DR

NVIDIAが2026年8月4日にリリースした自動運転基盤モデル Alpamayo 2 Super（34Bパラメータ） をDGX Sparkに載せて、グランツーリスモ7の走行映像を食わせてみた。

結果:

✅ 66.7GBでGPUに載った（121.6GB中）
✅ ゲーム映像の車両をバウンディングボックス付きで検出した
❌ ただし「運転判断」としては車を無視した
🤔 ゲームか実写かは判断できなかった

※ネタ実験だよ!!

はじめに

「NVIDIAの自動運転AIにレースゲームの映像を見せたらどうなるか？」

これは真面目で不真面目な実験である。最新のVLA（Vision-Language-Action）モデルがどの程度の汎化性能を持つのかとかカッコよく言うことも出来るが、学習データと異なるゲーム世界に対してどこまで機能するかってのと同時にリアルなゲームであればAI学習素材やテストとして使えるよねって話

Alpamayo 2 Superとは何か

Alpamayo 2 Superは、NVIDIAが Alpamayo Open Platform の一部としてリリースしたVLAモデルだ。

項目	スペック
パラメータ	34B（VLMバックボーン32B + Diffusion Expert 2.3B）
アーキテクチャ	Transformer（Vision-Language-Action）
ベース	Cosmos 3 Super Reasoner
ライセンス	OpenMDW-1.1（商用利用可）
リリース日	2026年8月4日
ソースコード	NVlabs/alpamayo2

VLA = 1つのモデルが「見て・理解して・判断する」。 従来の自動運転パイプライン（YOLO→追跡→予測→計画）を34Bの単一モデルに統合したのがこのアーキテクチャの本質だ。

革ジャンがウキウキで出していたやつね

本来の設計思想

Alpamayo 2 Superは本来、以下の入力を前提としている:

入力:
  - 6方向同期カメラ映像 × 4フレーム時系列
  - ego-motion（自車の位置・姿勢・速度の履歴）
  - カメラキャリブレーション

出力:
  - 64ウェイポイント（6.4秒先まで0.1秒刻みの軌道予測）
  - Chain-of-Causation推論（「なぜその判断をしたか」）
  - 2Dバウンディングボックス（物体検出）
  - メタアクション（加速/減速/車線変更等の高レベル判断）

つまり、実車に6台のカメラとセンサーをフル搭載して初めて本領を発揮するモデルだ。

残念ながら筆者の財力では実験用の車は用意できない。
なので今回はグランツーリスモ7の録画映像から、無理やり検証してみることにした。

※GT7自体普通に遊ぶので手元にあったゲームの中で手っ取り早かったのでコレで・・・
　時間が有ればアンリアルエンジン5とかで検証組んでも良いけど、今は車関係のお仕事していないし緩くやる

Alpamayo 2 Super の5つのモードと今回の制約

Alpamayo 2 Superは単一モデルでありながら、5つの異なるタスクを実行できる。それぞれ必要な入力が異なる。

モード	機能	必要入力	今回の実行
Trajectory	6.4秒先まで64ウェイポイントの軌道予測	6カメラ×4フレーム + ego-motion + キャリブレーション	❌ センサーなし
Meta-action	高レベル運転判断（加速/減速/車線変更）	6カメラ×4フレーム + ego-motion	❌ センサーなし
Auto-labeling	シーンの構造化JSON注釈	6カメラ×4フレーム + ego-motion + 将来軌道	❌ 将来軌道なし
Grounding	2Dバウンディングボックス付き物体検出	6カメラ×4フレーム	△ 部分的に動作
VQA	画像に対する自由質問応答	6カメラ×4フレーム	✅ 今回使用

なぜ VQA モードだけが使えたのか

上位モード（Trajectory / Meta-action）は 「自車がどこにいて、どう動いているか」 を知っている必要がある。具体的には:

ego-motion: 過去数フレームの自車位置(x,y,z) + 姿勢(3×3回転行列) + タイムスタンプ
カメラキャリブレーション: 各カメラの内部/外部パラメータ
時刻同期: 7カメラ×4フレームの正確なタイムスタンプ

PS5でGT7を録画しても、これらのデータは当然取得できない。

VQAモードは「画像 + 質問テキスト」だけで応答するタスクなので、最も制約が緩い。ただし、それでもパイプライン的には 7カメラ×4フレーム のテンソル構造を要求するため、今回はGT7の1フレームを全カメラ分に複製して入力した。

入力の無茶苦茶とその影響で今回はVQAだけにするね

本来、モデルは以下のように7方向の 異なる 映像を受け取る設計だ:

本来の入力:
  カメラ0: 左前方 120°   → 左側の車両や壁が見える
  カメラ1: 正面広角 120°  → 前方の道路状況
  カメラ2: 右前方 120°   → 右側の車両や壁が見える
  カメラ3: 左後方 70°    → 後続車の接近
  カメラ4: 後方望遠 30°   → 遠方の後続車
  カメラ5: 右後方 70°    → 後続車の接近
  カメラ6: 前方望遠 30°   → 遠方の前走車

今回の入力:
  カメラ0〜6: 全て同じGT7の正面画像
  → 「左を見ても右を見ても後ろを見ても同じ景色」という矛盾した状態

通常は想定されない動作なので本来はモデルは 「入力が信頼できない」と判断し、運転判断を安全側に倒す という行動を取ったと推測される。
「車が見えるが報告しない」のではなく、「入力がおかしいので判断を保留する」という、自動運転AIとして正しい振る舞いだ。

実験環境

ハードウェア

項目	スペック
マシン	NVIDIA DGX Spark
GPU	NVIDIA GB10（Blackwell）
メモリ	121.6GB 統合メモリ
CUDA	13.0
Compute Capability	12.1（sm_121）

ソフトウェア

項目	バージョン
PyTorch	2.10.0+cu130
Transformers	4.57.6
alpamayo2_super	0.1.0（--no-deps install）
flash-attn	未インストール（PyTorch SDPA fallback）

⚠️ PyTorchはsm_121に対して警告を出すが、推論は問題なく動作した。flash-attnのビルドをスキップしてもSDPA（Scaled Dot-Product Attention）にフォールバックするため、推論品質への影響はない。

入力データ

ゲーム: グランツーリスモ7（PS5）
コース: Tokyo Expressway
視点: バンパーカメラ（ドライバー視点相当）
解像度: 1920 × 1080

こんな感じね。

実験1: モデルは載るか

まず最も基本的な問い — 34Bモデルが DGX Spark に載るか？

Loading checkpoint shards: 100%|██████████| 15/15 [08:12]
Model loaded! VRAM: 66.7 GB

結果: あたりまえだけど余裕で載る。 66.7GB使用（55GB余裕）。BF16精度でフル搭載。量子化なしの素のモデルだ。

ロード時間は約8分。15シャード（各約4.5GB）をストレージからGPUメモリに転送する時間がボトルネック。一度載せてしまえば、以降の推論は8〜10秒程度で完了する。

しかしこのサイズを考えるとRTX5090でも検証ムズいので完全に法人の開発者向け

実験2: ゲーム映像で「運転判断」を聞いてみる

GT7の走行映像から5フレーム（3秒目/15秒目/30秒目/45秒目/60秒目）を抽出し、VQAモードで質問した。

質問: "Describe what you see on the road. Are there any vehicles ahead or nearby? What driving action would you recommend and why?"

フレーム	推論時間	回答
3秒目	9.7s	No vehicles observed ahead or nearby
15秒目	8.5s	No vehicles observed ahead or nearby
30秒目	8.5s	No vehicles observed ahead or nearby
45秒目	8.5s	No vehicles observed ahead or nearby
60秒目	8.6s	No vehicles observed ahead or nearby

全フレームで同一回答。だが、30秒目と45秒目には明確に他車が映っている。

モデルは車を「見えていない」のか？次の実験でそれを確認する。

実験3: 「車を探せ」と聞き方を変える

同じフレーム（30秒目・45秒目）に対して、質問を変えて再推論した。

質問: "List all vehicles visible in this image. Describe their position relative to the ego vehicle."

30秒目の結果

[{"bbox_2d": [133, 310, 735, 999], "label": "Car"}]

1台検出。 バウンディングボックス座標付きで車両を返してきた。
結構無理な渡し方なので車集団として認知したのだろうか？？？

45秒目の結果

[
  {"bbox_2d": [554, 486, 575, 509], "label": "Car"},
  {"bbox_2d": [499, 478, 534, 519], "label": "Car"}
]

2台検出。 遠方の小さな車（約20×30ピクセル）まで捉えている。

BOX位置がズレているのは先に出したカメラ映像をわざと偽っている都合
逆にBOXの位置関係から前方2台をかなり正確に見えている事が分かる

発見: 「見えているが、脅威と認識しない」

ここが今回の実験で最も面白い発見だ。

質問の種類	結果
「運転としてどうすべき？」	車を無視
「車両をリストアップせよ」	BBox付きで正確に検出

同じモデル、同じ画像、同じ推論エンジン で、質問を変えただけで挙動が180度変わる。

なぜこうなるか — タスク分離の構造

Alpamayo 2 Superは1つのモデルに複数のタスクが統合されている:

┌─────────────────────────────────────────┐
│         Alpamayo 2 Super (34B)          │
├─────────────────────────────────────────┤
│  VLMバックボーン (Qwen3-VL 32B)          │
│    └─ 視覚理解・言語理解・推論         　 │
├─────────────────────────────────────────┤
│  Diffusion Expert (2.3B)                │
│    └─ 軌道予測（Flow Matching）          │
├─────────────────────────────────────────┤
│  タスクヘッド                            │
│    ├─ VQA（質問応答）                    │
│    ├─ Grounding（物体検出・BBox）        │← 今回ここが反応
│    ├─ Meta-action（運転判断）            │← 今回ここは反応せず
│    ├─ Auto-labeling（シーン注釈）        │
│    └─ Trajectory（軌道予測）             │
└─────────────────────────────────────────┘

「運転判断」タスクは、入力が正式なマルチカメラ+ego-motion構成でないと発動しない安全設計になっていると推測される。一方「物体検出」タスクは、単一画像からでもある程度機能する。

これは安全面から理にかなっている — 不完全な入力に基づいて運転判断を下すくらいなら、「何もない」と報告する方が安全だ。

おまけ: ゲームか実写か聞いてみた

質問: "Is this a real road or a video game? What visual elements help you decide?"

回答: "No real road or video details provided"（判断材料がない）

グランツーリスモ7のレンダリング品質は、自動運転AIが「実写ではないと断言できない」レベルに達していることを意味する。これはSim-to-Real転移の議論において「十分にリアルなシミュレータは実世界と区別がつかない」ことの一つの傍証になる。

じゃあ実際の車にはどれくらいのGPUが要るのか？

今回の実験で得られた数字から、実用的な自動運転に必要な計算性能を逆算してみよう。

我々の実測値

項目	値
モデルサイズ	34B（66.7GB VRAM）
VQA推論時間	約8.5秒/フレーム

ただし、今回我々がやったのはVQAモード — いわば チャットAIのように「これ何が見える？」と質問しただけ だ。本来のTrajectoryモード（常時未来予測）とは要求される速度の考え方が異なる。

本来の速度要件: 「未来予測の更新に追いつけばいい」

Alpamayo 2 SuperのTrajectoryモードは 6.4秒先までの64ウェイポイント を出力する。つまり車は常に「6.4秒先までの計画」を持って走っている。

これは「毎フレーム100msで処理しろ」という単純な要件とは少し違う。概念的には:

常時予測モード:
  t=0s  → 「t=0.1〜t=6.4s」の軌道を予測
  t=0.1s → 「t=0.2〜t=6.5s」の軌道を更新
  t=0.2s → 「t=0.3〜t=6.6s」の軌道を更新
  ...

→ 予測が「期限切れ」する前に次の予測が完了すればいい
→ 理論上は6.4秒の余裕がある（ただし安全マージンを考えると100ms以下が目標）

実際、Alpamayoファミリーの車載向け蒸留版 Alpamayo-R1 はRTX 6000 Pro Blackwell上で 99ms を達成している（arXiv論文より）。これは10fpsの更新頻度に相当し、常に6秒以上先の計画を保持し続けられる。

Alpamayo 2 Super は車に載せるモデルではない

NVIDIAの公式ブログに明確に書かれている:

"The resulting distilled models can then be optimized for efficient, real-time inference in production vehicles."

Alpamayo 2 Super は 「インストラクター」 だ。このモデルが自分でハンドルを握るのではなく、その知識を小さいモデル（生徒）に教え込み、卒業した生徒が実車で走る:

┌─────────────────────────────────────────────────────────┐
│  クラウド / データセンター（H100 / DGX Spark）            │
│                                                         │
│  Alpamayo 2 Super (34B)                                 │
│    └─ 走行データにラベル付け（auto-labeling）            │
│    └─ 小さいモデルに知識を蒸留（distillation）           │
│    └─ シミュレーション評価（AlpaSim）                    │
└──────────────────────┬──────────────────────────────────┘
                       │ 蒸留
                       ▼
┌─────────────────────────────────────────────────────────┐
│  車載 / DRIVE AGX Thor                                   │
│                                                         │
│  蒸留済みモデル（数B〜十数Bパラメータ）                   │
│    └─ リアルタイム推論（<100ms）                         │
│    └─ 軌道予測 + 物体検出 + 運転判断                     │
└─────────────────────────────────────────────────────────┘

実際、同じAlpamayoファミリーの小型版 Alpamayo-R1 はRTX 6000 Pro Blackwell上で 99ms のレイテンシを達成している（arXiv論文より）。

車に載るGPU: NVIDIA DRIVE AGX Thor

項目	DRIVE AGX Thor	DGX Spark（今回）	比較
アーキテクチャ	Blackwell（車載版）	Blackwell（GB10）	同世代
AI性能	1,000 INT8 TOPS	N/A（統合メモリ）	—
FP4性能	2,000 TFLOPS	—	—
メモリ	64GB LPDDR5X	121.6GB 統合	車載は半分
帯域	273 GB/s	—	—
消費電力	350W	〜200W	車載のほうが大きい
動作温度	0〜45°C	データセンター	車載は過酷
安全認証	ASIL-D	なし	車載必須

DRIVE Hyperion 10（L4自動運転プラットフォーム） はこのThorを 2基搭載 する。つまり:

2,000 TOPS / 4,000 FP4 TFLOPS
消費電力約700W（2基合計）
14カメラ + 9レーダー + 1 LiDAR + 12超音波

計算してみる: 34Bモデルを車に載せるには？

仮にAlpamayo 2 Superをそのまま（蒸留なしで）リアルタイム化するとしたら:

必要高速化: 85倍（8.5s → 100ms）

手段の組み合わせ:
  - FP4量子化: 約2-4倍
  - TensorRT最適化: 約2-3倍  
  - バッチ並列化: 約2倍
  - Flash Attention: 約1.5倍
  - 専用HW（DRIVE Thor）: 約3-5倍
  ──────────────────────
  理論上の合計: 36-180倍 → ギリギリ到達圏内

だが現実的には 蒸留して小型化 するのが正解。34B → 8B程度に蒸留すれば、DRIVE AGX Thor 1基で余裕を持ってリアルタイム推論が可能になる。

つまりGT7を100msで処理するには

方式	必要GPU	消費電力	現実性
34Bフルモデル（今回）	DGX Spark相当	〜200W	❌ 車載不可
34B + TensorRT + FP4	DRIVE AGX Thor ×2	〜700W	△ 理論上可能
蒸留モデル（推奨）	DRIVE AGX Thor ×1	350W	✅ NVIDIAの想定パス
極小蒸留版	DRIVE Orin（254 TOPS）	60W	✅ L2+用途

結論: 自動運転AIの「脳」は、データセンターで育てて車では小さくして使う。 我々が今回DGX Sparkでやったのは、そのインストラクターに「グランツーリスモの映像どう思います？」とチャットAIのように話しかけた、という実験だ。本来はセンサーフル搭載の実車からデータを流し込み、常時未来予測を回し続けるのがこのモデルの本領だ。

Alpamayo 2 Superは自動運転AIの「ドライバー」ではなく「インストラクター」だ。
教習所（クラウド）で生徒（蒸留モデル）に運転を教え、卒業した生徒が実車（DRIVE AGX Thor）のハンドルを握る。

まとめ

問い	答え
34BモデルはDGX Sparkに載る？	✅ 66.7GB / 121.6GB
ゲーム映像から車を検出できる？	✅ BBox付きで検出
ゲーム映像で運転判断できる？	❌ 「車なし」と報告（安全設計）
ゲームと実写の区別は？	判断つかず（GT7のリアルさ）
車に載せるには？	蒸留→DRIVE AGX Thor（350W）

我々が今回やったのは、インストラクターにグランツーリスモの映像を見せて「これどう思います？」と聞いた、というネタ実験である。

本来の使い方との対比

今回の実験は、あくまで公式推奨構成の外で行ったものだ。正式なセットアップ（6カメラ同期 + ego-motion + キャリブレーション）であれば、6.4秒先までの軌道予測が可能であり、今回とは全く異なる結果になる。

しかし「正式な使い方から外れたときに何が起こるか」を観察することで、モデルの設計思想 — 何を安全とみなし、何を危険とみなすか — が浮き彫りになる。

Alpamayo 2 Superは「見えていても確信がなければ動かない」モデルだ。これは自動運転AIとして正しい姿勢だと思う。

環境構築メモ（再現したい人向け）

# DGX Spark / NVIDIA GB10 環境を想定

# 1. venv作成
python3 -m venv env_alpamayo
source env_alpamayo/bin/activate

# 2. PyTorch（CUDA 13.0対応版）
pip install torch torchvision --index-url https://download.pytorch.org/whl/cu130

# 3. Alpamayo 2 Super（flash-attnスキップ）
pip install git+https://github.com/NVlabs/alpamayo2.git --no-deps
pip install transformers accelerate einops hydra-core pillow numpy scipy pandas

# 4. モデルダウンロード（67GB）
huggingface-cli download nvidia/Alpamayo2-Super --local-dir ./alpamayo2-super

# 5. 推論（VQAモード）
python3 vqa_test.py

参考リンク