NVIDIA の Lyra 2.0 を NVIDIA Brev 上の H100 環境で動かしてみた

こんにちは、atsu です。
NVIDIA の Lyra 2.0 を NVIDIA Brev 上の H100 環境で動かしました。

https://research.nvidia.com/labs/sil/projects/lyra2/
https://github.com/nv-tlabs/lyra

Lyra 2.0 に注目した理由は、ロボット開発で使うシミュレーション環境の作成に応用できる可能性があると感じたためです。ロボットの認識、ナビゲーション、操作系を検証するには、実機だけでなくシミュレーション環境も重要です。ただ、生活空間や作業現場に近い 3D 環境を複数パターン用意するには、モデリング、テクスチャ、物理設定、シーン配置などに手間がかかります。

Lyra 2.0 は、単一画像から探索可能な 3Dワールドを生成するためのプロジェクトです。生成結果をそのままロボットシミュレータへ入れられるわけではありませんが、3Dシーン候補を作る入口として使えるかは試す価値があります。

この記事では、まず Brev 上に Lyra 2.0 の実行環境を作り、サンプル画像と独自入力画像から動画を生成するところまでを扱います。

Lyra 2.0 とは

Lyra は NVIDIA Spatial Intelligence Lab が公開している、生成 3Dワールドモデルのプロジェクトです。公式 README では、Lyra 2.0 は長い時間軸で 3D一貫性のある探索可能な生成 3Dワールドを扱うバージョンとして紹介されています。

Hugging Face のモデルカードでは、Lyra 2.0 は単一画像から長距離の動画を合成し、その生成シーケンスを明示的な 3D 表現へ再構成する二段構成として説明されています。出力は 3D Gaussian Scene、つまり 3D Gaussian Splatting のプリミティブ群として扱われ、.ply のような形で利用できます。

なお、Lyra のソースコードは GitHub 側では Apache-2.0 として公開されていますが、Lyra 2.0 のモデル重みは Hugging Face のモデルカード上で NVIDIA Internal Scientific Research and Development Model License とされています。生成物や派生物の公開・配布・商用利用については、実際に公開する前に最新のライセンス条項を確認する必要があります。

https://huggingface.co/nvidia/Lyra-2.0

Cosmos との違い

同じ NVIDIA の Physical AI / world model 文脈では、Cosmos も比較対象になります。ただし、Lyra 2.0 と Cosmos は役割が違います。

Lyra 2.0 は、単一画像からカメラ軌道に沿った探索動画を生成し、その動画列を 3D Gaussian Splatting へ再構成する研究寄りのフレームワークです。この記事のように「生成した空間をロボットシミュレータへ近づけられるか」を見る題材として扱いやすいです。

一方、Cosmos は Physical AI 向けの world foundation model 群と開発基盤です。公式ドキュメントでは、Cosmos-Predict、Cosmos-Transfer、Cosmos-Reason などの複数コンポーネントが説明されています。たとえば Cosmos-Transfer は depth や segmentation などの制御入力を使う video-to-video 変換を想定しており、既存シミュレーション映像の多様化やフォトリアル化に向いています。

今回の検証では、まず Lyra 2.0 を選びました。理由は、最終的に .ply のような明示的な 3D 表現へ進められるためです。Unitree G1 や Isaac Lab につなげたい場合、動画だけでなく「床面・壁・障害物を持つシーン」として扱えるかが重要になります。

https://www.nvidia.com/en-us/ai/cosmos/

なぜ Brev を使うか

Lyra 2.0 のような GPU 前提のプロジェクトでは、環境構築だけで時間を使いがちです。CUDA、GPU ドライバ、PyTorch、モデル重み、コンテナ内の GPU 認識などをそろえる必要があります。

今回はローカル環境を直接変更せず、検証用の GPU 環境を短時間で用意するために NVIDIA Brev を使いました。

https://developer.nvidia.com/brev

検証環境

今回使った環境は以下です。

Lyra 2.0 の公式 INSTALL.md では、Ubuntu 22.04、CUDA 12.8、NVIDIA H100 GPU でテスト済みとされています。今回の Brev 環境は H100 と CUDA 12.8 は一致しましたが、OS は Ubuntu 24.04.2 でした。そのため、この記事の結果は「公式に近いが、完全に同一ではない環境」での検証として読んでください。

Brev で H100 インスタンスを作る

まず手元の Brev CLI を確認します。

brev --version

今回の手元環境では以下でした。

Current Version: v0.6.327

次に Brev へログインします。

brev login --skip-browser

ログイン後、既存インスタンスを確認します。

brev ls

既存の H100 インスタンスを誤って起動すると課金が増えるので、今回は新しく作る検証用インスタンスだけを使いました。

H100 の候補を検索して、今回は scaleway_H100 を選びました。

brev search gpu --gpu-name H100 --sort price --wide
brev create lyra-2-brev --type scaleway_H100 --mode vm --timeout 600

今回検索した時点では、scaleway_H100 が H100 80GB の候補の中で最も安価でした。Brev の検索結果では $3.96/hr、1TB disk、起動目安 2 分という表示でした。

インスタンスに入ったら、まず GPU が見えているか確認します。

nvidia-smi

Lyra 2.0 をセットアップする

Lyra のリポジトリを取得します。公式手順では SSH URL が使われていますが、Brev 上で手早く試すため、ここでは HTTPS で clone しました。

git clone --recursive https://github.com/nv-tlabs/lyra.git
cd lyra/Lyra-2

Lyra 2.0 の公式手順では、conda で Python 3.10 環境を作成し、CUDA 12.8、PyTorch 2.7.1、Flash Attention、VIPE、Depth Anything 3 などを入れます。

conda create -n lyra2 python=3.10 pip cmake ninja libgl ffmpeg packaging -c conda-forge -y
conda activate lyra2
CONDA_BACKUP_CXX="" conda install gcc=13.3.0 gxx=13.3.0 eigen zlib -c conda-forge -y

conda install cuda -c nvidia/label/cuda-12.8.0 -y
export CUDA_HOME=$CONDA_PREFIX

pip install torch==2.7.1 torchvision==0.22.1 --extra-index-url https://download.pytorch.org/whl/cu128

今回使った Lyra は、作業時点で clone した main の以下の commit です。

9fffc9adc37004091ecf26ef03abfb3abdf4d59a
9fffc9a 2026-07-20 Revise README for Lyra 2.0 release and citation

ここでいう「最新」は、PyTorch や Transformer Engine を全部最新版に上げるという意味ではなく、Lyra リポジトリの最新 main を使うという意味です。依存関係は、まず Lyra 公式の INSTALL.md に寄せました。

最終的に、主要依存の import と推論エントリポイントの起動確認までは通りました。

torch: 2.7.1+cu128 cuda: True
flash_attn: 2.6.3
all imports OK

PYTHONPATH=. python -m lyra_2._src.inference.lyra2_zoomgs_inference --help
PYTHONPATH=. python -m lyra_2._src.inference.vipe_da3_gs_recon --help

モデル重みは Hugging Face から取得します。

huggingface-cli login
huggingface-cli download nvidia/Lyra-2.0 --include "checkpoints/*" --local-dir .

Hugging Face へログインしたあと、チェックポイントは取得できました。取得結果は 75 ファイル、合計 91GB でした。

サンプル画像から動画を生成する

README のサンプルに近い形で sample_id 4 を実行しました。ブログ用の動作確認なので、まずは高速な --use_dmd を付けています。

export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

PYTHONPATH=. python -m lyra_2._src.inference.lyra2_zoomgs_inference \
  --input_image_path assets/samples \
  --sample_id 4 \
  --experiment lyra2 \
  --checkpoint_dir checkpoints/model \
  --prompt_dir assets/samples \
  --output_path outputs/zoomgs \
  --num_frames_zoom_in 81 \
  --num_frames_zoom_out 81 \
  --zoom_in_strength 0.5 \
  --zoom_out_strength 1.0 \
  --use_dmd

結果として、zoom-in、zoom-out、結合動画の3本が生成されました。

Saved zoom_in video: outputs/zoomgs/04/zoom_in.mp4
Saved zoom_out video: outputs/zoomgs/04/zoom_out.mp4
Saved combined video: outputs/zoomgs/videos/04.mp4
Done.

H100 80GB 上では、VAE の stream decode 時にピークで約 64.6GiB の GPU メモリを使っていました。NNPACK の警告は大量に出ましたが、生成自体は完了しました。

独自入力画像でも試す

サンプルだけだと、Lyra 2.0 が動いたことは確認できますが、ロボット開発に使えるかという観点では少し弱いです。そこで、移動ロボットのカメラ視点を想定した独自入力画像を3種類用意しました。

それぞれの入力画像に対して、画像ファイルと同名の .txt を置き、Lyra の --prompt_dir から読み込ませました。たとえば、住宅の廊下画像では次のようなプロンプトにしています。

A mobile robot moves from an apartment hallway toward a living room. Extend the indoor route forward while keeping doorway geometry, furniture placement, and floor scale consistent.

実行コマンドはサンプルと同じ条件にそろえました。--input_image_path に3枚を置いたディレクトリを指定し、--num_samples 3 でまとめて処理します。

PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True \
PYTHONPATH=. python -m lyra_2._src.inference.lyra2_zoomgs_inference \
  --input_image_path assets/custom_blog_inputs/custom_inputs \
  --num_samples 3 \
  --sample_start_idx 0 \
  --experiment lyra2 \
  --checkpoint_dir checkpoints/model \
  --prompt_dir assets/custom_blog_inputs/custom_inputs \
  --output_path outputs/custom_blog \
  --num_frames_zoom_in 81 \
  --num_frames_zoom_out 81 \
  --zoom_in_strength 0.5 \
  --zoom_out_strength 1.0 \
  --use_dmd

生成結果は以下です。3本とも、zoom-in 81フレームと zoom-out 81フレームを結合した動画一部です。

入力	出力動画	解像度	fps	フレーム数	尺	ファイルサイズ
住宅の廊下		832x480	16	162	10.125秒	538KB

この時点で、Brev 上で Lyra 2.0 を動かし、ロボット開発を意識した入力から動画を生成するところまで確認できました。

Lyra 2.0セットアップでつまずいたところ

セットアップ中に、再現時にも注意したいポイントがいくつかありました。

Flash Attention のソースビルド中は、pip のログだけを見ると止まっているように見えます。実際には、以下のように別シェルでプロセスを見ると進んでいるか確認できます。

ps -eo pid,ppid,stat,pcpu,pmem,comm,args \
  | grep -E "(nvcc|cicc|gcc|g\\+\\+|pip|ninja)" \
  | grep -v grep

今回の環境では、ninja -j 16 の下で compute_80 と compute_90 の CUDA カーネルがコンパイルされており、途中時点でコンパイル系プロセスが 37 個、合計 CPU 使用率が約 1620% ありました。ログの表示が止まって見えても、プロセス側ではビルドが進んでいるケースがあります。

Brev インスタンスの片付け

今回作った lyra-2-brev は、後から停止しようとしたところ stop に対応していませんでした。

instance "lyra-2-brev" does not support stop.

この場合、環境を残したまま停止できないため、必要な生成物をローカルへコピーしたうえで削除しました。

brev delete lyra-2-brev

GPU インスタンスを使った検証では、セットアップ手順だけでなく、最後にどう止めるか、何をローカルへ退避してから削除するかも作業手順に入れておくべきだと感じました。

まとめ

Brev 上に H100 環境を用意し、Lyra 2.0 のセットアップ、サンプル動画生成、独自入力画像3種での動画生成まで確認しました。

Lyra 2.0 は依存関係が重く、チェックポイントも 91GB と大きいため、ローカル環境を直接変更せずに試せる Brev は相性がよいと感じました。一方で、H100 80GB でも GPU メモリを大きく使うため、インスタンス種別と課金停止の扱いは事前に確認しておく必要があります。