
DGX Spark で NVIDIA Cosmos 世界基盤モデルを動かしてみた
はじめに
こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。
「テキストを入力したら、物理法則に従った動画が生成される」と聞いたら、気になる方も多いのではないでしょうか。NVIDIA が公開している Cosmos は、まさにそうした「世界基盤モデル」を実現するためのプラットフォームです。テキストや画像から動画を生成する Predict 2.5、動画の内容を理解して因果関係や空間構造を推論する Reason2 など、複数のモデルで構成されています。
ただ、世界基盤モデルはメモリ消費が大きく、動かすには A100 や H100 といったデータセンター GPU が必要とされてきました。そこで今回は、128GB の統合メモリを持つ DGX Spark でどこまで動くのかを検証してみました。結論から言うと、2B モデルは快適に動作し、14B モデルは 3 回のシステムフリーズを経て断念という結果になりました。。。
この記事では Cosmos Predict 2.5 による動画生成と Cosmos Reason2 による動画理解の両方を試し、128GB 統合メモリの恩恵と限界を具体的な数値とともにお伝えします。
Cosmos ファミリーの全体像
Cosmos は「Physical AI」の開発を加速するためのプラットフォームで、用途の異なる複数のモデルが用意されています。今回検証した 2 つを中心に、ファミリー全体を整理してみます。
Predict 2.5 で「未来を予測する」
Predict 2.5 はテキストや画像を入力として、物理的に妥当な動画を生成するモデルです。自動運転シミュレーションやロボティクスの学習データ生成を想定して開発されていますが、純粋にテキストから動画を作るツールとしても面白いですね。
入力の種類によって 3 つのモードがあり、テキストのみから動画を作る Text2World、画像を起点に動きを付ける Image2World、動画の続きを生成する Video2World が用意されています。モデルサイズは 2B と 14B の 2 種類で、14B のほうが高品質な出力が期待できます。
Reason2 で「動画を理解する」
Reason2 は動画の内容を分析し、因果関係や時間推移、空間構造を推論する VLM(Vision-Language Model)です。Qwen2.5-VL をベースにファインチューニングされており、「この動画で次に何が起きるか」「物体同士の位置関係はどうなっているか」といった問いに自然言語で回答します。2B と 8B の 2 サイズが提供されています。
Transfer 2.5 は今回見送り
制御信号(エッジマップ、深度マップなど)からリアルな映像を生成する Transfer 2.5 も試みましたが、2B モデルでも 65.4GB の VRAM を必要とし、DGX Spark では OOM でプロセスが kill されました。こちらは別の機会に改めて挑戦したいと思います。
検証環境
| 項目 | 値 |
|---|---|
| デバイス | NVIDIA DGX Spark |
| SoC | Grace Blackwell GB10 |
| メモリ | 128GB 統合メモリ(CPU/GPU 共有) |
| CUDA | 13.0.2 |
| ドライバ | 580.126.09 |
| OS | Ubuntu 24.04(DGX OS) |
DGX Spark の特徴は CPU と GPU がメモリを共有する「統合メモリアーキテクチャ」です。通常の GPU サーバーでは GPU メモリ(VRAM)と CPU メモリ(RAM)が物理的に分かれていますが、DGX Spark では 128GB を柔軟に割り当てられます。これにより、VRAM 24GB の RTX 4090 では OOM になるモデルでも、そのまま動かせる可能性があるわけですね。
Cosmos Predict 2.5 を動かす
セットアップ
公式リポジトリでは Docker と uv の 2 つのセットアップ方法が用意されています。今回は uv を使いました。
git clone https://github.com/nvidia-cosmos/cosmos-predict2.5.git
cd cosmos-predict2.5
git lfs pull
uv sync --extra=cu130
DGX Spark は ARM64(aarch64)+ CUDA 13.0 という組み合わせのため、--extra=cu130 の指定が必要です。CUDA 12.8(x86_64 向け)では動きません。
モデルのダウンロードには HuggingFace の NVIDIA Open Model License への同意が必要です。事前に Cosmos-Predict2.5-2B のモデルページでライセンスに同意し、HF_TOKEN を環境変数に設定しておきます。
推論スクリプトは examples/inference.py を使用します。公式 README には scripts/diffusers_inference.py も記載されていますが、執筆時点の diffusers 0.35.2 には Cosmos 2.5 用のパイプラインが実装されておらず、ImportError になりました。
Text2World で動画を生成する
まずはテキストだけから動画を生成してみます。入力は JSON ファイルで指定します。
{
"prompt": "Water slowly pouring from a glass bottle into a clear glass on a wooden table. Close-up view, natural lighting from a window.",
"inference_type": "text2world",
"num_steps": 35,
"seed": 42
}
.venv/bin/python examples/inference.py \
--model 2B/post-trained \
--batch_input_path inputs/water_pour.json \
--batch_output_path outputs/ \
--disable-guardrails
--disable-guardrails は Cosmos-Guardrail1 による入出力フィルタリングを無効化するオプションです。Guardrail を有効にすると、入力プロンプトを Blocklist と Qwen3Guard(LLM ベース)で安全性チェックし、生成された動画も VideoContentSafetyFilter で検査した上で、検出された顔に自動でぼかしをかける仕組みが働きます。Guardrail モデルは別途ライセンス同意とダウンロードが必要で、今回は動画生成の検証が目的のためスキップしました。
初回はモデルのダウンロードが走るので少し待ちます。2B の Text2World チェックポイントは約 5GB です。
生成は 36 ステップのデノイジングで進み、1 ステップあたり約 53 秒。トータルで約 32 分かかりました。
| 指標 | 値 |
|---|---|
| 生成時間 | 約 32 分(36 ステップ) |
| GPU メモリ | 27.7GB |
| GPU 使用率 | 96% |
| 消費電力 | 88W |
| GPU 温度 | 82°C |
| 出力解像度 | 1280x704 |
| フレーム数 | 93 フレーム(16fps) |

1 本の動画に 32 分は決して速くはありませんが、A100 や H100 を使わずにデスクトップサイズの機器で動画生成ができているのはありがたいですね。メモリ使用量は 27.7GB で、128GB に対してまだまだ余裕があります。
Image2World で画像を動かす
次に、静止画を入力として動画を生成する Image2World を試します。公式サンプルのバスターミナル画像と、ロボット溶接の画像の 2 つで検証しました。

.venv/bin/python examples/inference.py \
--model 2B/post-trained \
--batch_input_path inputs/bus_terminal_i2w.json \
--batch_output_path outputs/ \
--disable-guardrails
Image2World では入力画像の雰囲気を保ちつつ、プロンプトに沿った動きが付加されます。バスターミナルの画像からはバスがゆっくり発車する動画が、溶接ロボットの画像からは火花が散り続ける動画が生成されました。
2 つの素材での生成時間とファイルサイズは以下のとおりです。
| 素材 | 生成時間 | ファイルサイズ |
|---|---|---|
| バスターミナル | 約 31 分 | 823KB |
| ロボット溶接 | 約 33 分 | 1.7MB |

Text2World と比べて生成時間はほぼ同等です。入力画像があるぶん、構図やカラーパレットが安定する印象がありました。「自分で撮った写真を動かしてみたい」という用途には Image2World のほうが向いていそうです。
14B モデルに挑戦して 3 回フリーズした話
2B が安定して動いたので、次は 14B モデルに挑戦しました。リサーチ時点では 14B Text2World の VRAM 目安が約 49GB とされており、128GB の統合メモリなら動くはずだと考えていました。
結果から言うと、3 回試して 3 回ともシステムがフリーズし、毎回電源ケーブルを抜く羽目になりました。
| 試行 | 条件 | 結果 |
|---|---|---|
| 1 回目 | オプションなし | モデルロード中に OOM → システムフリーズ |
| 2 回目 | --offload-tokenizer、不要サービス停止 |
モデルロード成功(51GB)→ 推論開始直後にフリーズ |
| 3 回目 | --offload-diffusion-model + --offload-tokenizer |
モデルロード成功(106GB/121GB)→ 推論開始直後にフリーズ |
3 回目は diffusion model を CPU にオフロードするオプションまで使い、モデルロード自体は成功しました。しかし、推論が始まった瞬間に autoregressive generation の中間テンソルでメモリが溢れ、システムが応答しなくなります。
DGX Spark の統合メモリでは、GPU メモリが枯渇するとシステム全体が道連れになります。通常の GPU サーバーなら GPU プロセスだけが kill されて OS は生きていますが、DGX Spark では GPU と CPU がメモリを共有しているため、GPU 側の OOM がカーネルレベルのハングを引き起こします。ソフトリブートでも GSP ファームウェアの初期化に失敗して GPU が復旧しないこともあり、電源を物理的に切るコールドリブートが必要な時もありました。。。
14B モデルの動作には 128GB では足りないという結論です。おそらく 256GB 以上の統合メモリか、マルチノード構成が必要になるでしょう。
Cosmos Reason2 で動画を理解する
DGX Spark での環境構築
Predict 2.5 が「動画を作る」モデルなら、Reason2 は「動画を読む」モデルです。Reason2-8B は Qwen2.5-VL ベースの VLM で、動画に映る事象の因果関係や時間推移を推論します。
DGX Spark で Reason2 を動かすには少し工夫が要りました。Reason2 は Qwen2.5-VL ベースのマルチモーダルモデルで、FlashAttention の sm_121a カーネルが未提供のため vLLM サーバーモードでは起動できません。transformers で直接推論する構成を採用しました。
from transformers import Qwen2_5_VLForConditionalGeneration
model = Qwen2_5_VLForConditionalGeneration.from_pretrained(
"nvidia/Cosmos-Reason2-8B",
torch_dtype=torch.bfloat16,
attn_implementation="eager", # FlashAttention は sm_121a 未対応
).to("cuda")
attn_implementation="eager" がポイントです。デフォルトの SDPA や FlashAttention は DGX Spark の GPU(Blackwell, sm_121a)でカーネルが提供されておらず、cuDNN のエラーで落ちます。eager attention に切り替えることで回避できました。モデルサイズは BF16 で約 17.5GB、ロード時間は約 89 秒です。
3 つの素材で推論してみる
因果推論、時間推移、空間推論の 3 種類の動画で Reason2 の実力を試しました。
水が溢れる動画で因果推論

コップに水を注ぎ続けて溢れる動画を入力し、「この動画で何が起きているか」と質問しました。
Reason2 はコップに水が満たされていく過程を時系列で説明し、水面が泡立ちながら上昇して縁まで達する様子や、光の屈折といった細かな観察まで含めた回答を返してくれました。
| 言語 | トークン数 | 推論時間 | TPS |
|---|---|---|---|
| 英語 | 73 | 21.4 秒 | 3.4 |
| 日本語 | 197 | 33.9 秒 | 5.8 |
Reason2 の日本語レスポンス(水を注ぐ動画)
銀色のシンクに置かれた透明なガラスコップが、上から流れ落ちる水によって満たされていく様子が映されています。コップの中にはすでに一部の水が入っており、新しい水流がそれを押し上げながらさらに多くの水を含みます。水面は泡立ちながらゆっくりと上昇し、最終的にはコップの縁まで達します。このプロセスでは、水がコップに入り込むことでその内部空間が埋められていき、結果として水位が上がっていくことが観察できます。また、コップの外側にもわずかな水滴が残り、その表面に反射や屈折による光の効果も見られます。
卵を割る動画で時間推移

卵を割ってフライパンに落とす動画では、すでにフライパンにある卵黄と白身を認識した上で、別の手が次の卵を割り入れている動作を読み取っていました。複数の卵を同時に調理しようとしている状況を捉えており、時間的な推移の理解が伺えます。
| 言語 | トークン数 | 推論時間 | TPS |
|---|---|---|---|
| 英語 | 142 | 28.7 秒 | 5.0 |
| 日本語 | 80 | 21.0 秒 | 3.8 |
Reason2 の日本語レスポンス(卵を割る動画)
フライパンにはもう一つ卵黄と白身がたまっています。一方で別の手はすでに割った殻を持ちながら次の一枚目の卵を入れています。残り半分も入っている途中です。この時点で一気に二つの卵を作ろうとしていますので、その後すぐに両方とも固まります。
駐車場の俯瞰動画で空間推論

駐車場を上から撮影した動画では、全体のレイアウト(車列の並び、列間の緑地帯、歩道や周辺の植物など)は概ね正確に読み取れていました。ただし、具体的な台数(76 台)については正確ではない可能性があり、素材的にもちょっと不適切だったかもしれません。。。
| 言語 | トークン数 | 推論時間 | TPS |
|---|---|---|---|
| 英語 | 512 | 67.9 秒 | 7.5 |
| 日本語 | 228 | 37.1 秒 | 6.1 |
Reason2 の日本語レスポンス(駐車場の俯瞰動画)
画像には76台の車が見えます。これらの車は、整然とした並び方で駐車されています。左側から右側へと、縦に並んでいます。各列の間に緑色のスペースがあり、その中に木々が植えられています。また、駐車場の周りには歩道があり、そこを通る人々も見えます。駐車場の外周には、草むらや他の植物が見られます。
8B モデルの GPU メモリ使用量は 18.1GB で安定しており、Predict 2.5 の 2B(27.7GB)より軽量です。両方のモデルを交互に使っても 128GB には十分な余裕があります。
まとめ
DGX Spark の 128GB 統合メモリで Cosmos ファミリーを動かした結果を振り返ります。
Predict 2.5 の 2B モデルは Text2World、Image2World ともに安定して動作しました。1 本の動画生成に約 30 分かかるものの、A100 や H100 を使わずにデスクサイドで世界基盤モデルの動画生成を試せるのは、個人的にはかなり面白い体験でした。
一方、14B モデルは 3 回のシステムフリーズを経て断念しました。--offload-diffusion-model で CPU にオフロードしても推論時の中間テンソルが 128GB を超えてしまうため、シングルの DGX Spark では動作しません。14B を動かすには 256GB 以上の環境か、マルチノード構成が必要になりそうです。
Reason2 の 8B は 18.1GB で軽快に動作し、因果推論や時間推移の分析で実用的な品質を見せてくれました。日本語の出力品質が高いのも嬉しい発見です。
128GB の統合メモリは「RTX 5090 でも両方同時には動かせないが、H100 を用意するほどでもない」モデルをデスクサイドで試せる環境です。Predict 2.5 の 2B + Reason2 の 8B を合わせても 45GB 程度で、まだ余裕がある状態です。世界基盤モデルに興味がある方の環境選びの参考になれば嬉しいです。








