NVIDIA Cosmos 3 ファミリーの使い分けマップを整理してみた
はじめに
こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。
DGX Spark で NVIDIA Cosmos 3 を動かしてみた で、NVIDIA Cosmos 3 を Reasoner Tower と Generator Tower の 2 つを 1 モデルに収めた omnimodel として取り上げました。連載のまとめとなる本稿では、Cosmos 3 を「現場でどう使い分けるか」という観点で整理しつつ、理解担当の Reasoner Tower を VLM として動かしたときの日本語視覚推論ベンチも実測してみます。
Cosmos 3 は Nano と Super という 2 つの omnimodel を軸に、生成特化の派生モデルやロボット制御向けモデルがそろっています。さらに既存の Cosmos Reason 2 が VSS（NVIDIA Video Search and Summarization）の VLM コンポーネントとして広く使われている状況も踏まえると、「いまある Reason 2 をどこまで活かすか、どこから Cosmos 3 に乗り換えるか」が現実的な判断軸になります。
Cosmos 3 ファミリーと Cosmos Reason 2
まず Cosmos 3 で公開されているモデル群と、既存の Cosmos Reason 2 を 1 枚の地図に並べてみます。
ここで押さえておきたいのが、Cosmos 3 では理解担当の Reasoner Tower と生成担当の Generator Tower が 1 つの omnimodel に統合されたという点です。前世代では映像理解を担う Cosmos Reason、動画生成を担う Cosmos Predict、と用途ごとにモデルが分かれていましたが、Cosmos 3 はこれを Nano / Super という omnimodel に集約しました。理解だけ使いたいときは、推論時に Reasoner Tower だけを切り出して VLM として動かせます。
機能と規模の早見表として、こんな整理になりそうです。
| モデル | パラメータ | メモリ目安 | 主な役割 | DGX Spark 単体 |
|---|---|---|---|---|
| Cosmos Reason 2 | 8B | ~17 GB | VLM 専用（理解・構造化出力） | ✅ |
| Cosmos 3 Nano | 16B | ~30 GB | omnimodel（理解 + 生成 + 制御）。Reasoner Tower 切り出しで VLM 単体運用も | ✅ |
| Cosmos 3 Super | 64B | ~120 GB+ | omnimodel 大型版 | ⚠️（KV cache で圧迫） |
| Super-Image2Video | 64B 派生 | ~120 GB+ | 画像 → 動画の生成特化 | ⚠️ |
| Super-Text2Image | 64B 派生 | ~120 GB+ | テキスト → 画像の生成特化 | ⚠️ |
| Nano-Policy-DROID | 16B | ~30 GB | DROID プラットフォーム向けロボット制御ポリシー | ✅ |
| Cosmos 3 Edge | 4B | ~8 GB | エッジ向け軽量版（coming soon） | ✅（予定） |
Nano は DGX Spark™ 128 GB ユニファイドメモリに余裕で乗るサイズ感、Super 系は omnimodel も生成特化派生も DGX Spark 単体だと窮屈です。Super を実運用に乗せるなら、Brev H100 や DGX Station 級の環境を想定しておくのが安全です。近日提供予定の Cosmos 3 Edge は 4B 級と小さく、Jetson のようなエッジ GPU を視野に入れた選択肢になりそうですね。
DGX Spark で動かせる組み合わせ
128 GB ユニファイドメモリという DGX Spark の予算の中で、何をどう組み合わせて常駐させるかを考えてみます。
実機で動かした感触としては、Cosmos 3 Nano の Reasoner Tower だけを切り出すと約 17 GB でロードできるので、Cosmos Reason 2（~17 GB）と並べても 35 GB 程度に収まります。Reasoner Tower のサービングは vllm serve nvidia/Cosmos3-Nano --hf-overrides '{"architectures": ["Cosmos3ReasonerForConditionalGeneration"]}' のように architecture を上書きして起動する形で、--gpu-memory-utilization を絞れば KV cache を含めても一台に同居できます。omnimodel 全体を生成まで含めて動かす場合は ~30 GB を見ておけば DGX Spark 単体で十分です。
逆に Cosmos 3 Super は omnimodel も生成特化派生も、単体で DGX Spark の予算をほぼ使い切ってしまうので、本気で動かすなら別ノードに任せる前提になります。DGX Spark を選ぶときの判断基準としては、「Nano を主役にして Cosmos Reason 2 と切り替え運用できる単一ノード環境」というのがいちばん収まりが良い、という結論です。Super 系は別環境にオフロードする設計を最初から組み込んでおくと、後で苦労が少なそうです。
Cosmos 3 Nano の Reasoner を実測してみる
使い分けの前に、理解担当の Reasoner Tower がどれくらいの実力なのかを実測しておきます。GB10 の DGX Spark 上で Cosmos 3 Nano の Reasoner Tower をサービングし、日本語視覚推論ベンチの Heron-Bench と JMMMU、それからロボット軌道の CoT（思考連鎖、Chain-of-Thought）と Embodied Reasoning を回してみました。比較対象は VSS デフォルトの Cosmos Reason 2 です。
まず Heron-Bench（自由記述を LLM が採点するベンチ）の結果です。質問カテゴリ別と画像カテゴリ別で並べてみました。
平均スコアは Cosmos 3 Nano が 2.777 で、Cosmos Reason 2 とほぼ重なります。質問カテゴリ（conversation / detail / complex）でも画像カテゴリ（anime / art / culture など 7 種）でも、どちらかが一方的に勝つ形ではなく、カテゴリごとに小さく上下する拮抗した結果でした。自由記述の日本語応答という観点では、両者は同じ水準にあると見てよさそうです。
続いて JMMMU（28 分野の多肢選択を exact match で採点）の結果です。
全体の exact match は Cosmos 3 Nano が 0.498 で、Cosmos Reason 2 をわずかに上回りました。分野ごとに見ると World History のように両者とも強い分野がある一方で、Music や Mechanical Engineering のように揃って苦手な分野もあり、得意・不得意の傾向はよく似ています。多肢選択でも両者の精度はほぼ並ぶ、というのが実測から見えた結論です。
構造化出力も確認しました。ロボット軌道の CoT（画像から把持・配置のウェイポイントを点列で出させるタスク）では、8 枚の入力に対して有効な JSON を返した割合が 0.62、1 枚あたりの推論時間が平均 8.3 秒ほどでした。軌道生成が 10 秒を切る程度なら、SO-ARM101 や Reachy Mini のような小型アームにデモ・インタラクション用途で組み込む現実味があります。
Embodied Reasoning の probe では、<think>...</think> タグの中に推論を引き出せるかをプロンプトの型を変えて見てみました。素のプロンプトでは思考タグはほとんど出ませんが、CoT を明示的に求める書き方や安全観点を指定する書き方にすると、4 件とも安定して <think> の中に実体的な推論が現れました。
まとめると、Reasoner Tower の精度は Cosmos Reason 2 と拮抗していて、乗り換えの判断軸は「精度の差」ではなく「Cosmos 3 にしか乗っていない性質」になる、というのがここでの実測からわかる印象です。
Cosmos Reason 2 をそのまま使うべき場面
最初は「Cosmos Reason 2 を継続して使うべきケース」です。前節で見たとおり、Cosmos 3 Nano の Reasoner Tower と Cosmos Reason 2 はベンチマーク上ほぼ同じ精度水準なので、無理に乗り換える必要はないシナリオがいくつかあります。
まず筆頭は、既存の VSS パイプラインに組み込まれているケースです。VSS 3.1.0 EA では DGX Spark 向け hw env として cosmos-reason2-8b が標準で同梱されていて、VLM-as-Verifier / Event Reviewer / Alert Bridge のいずれも Cosmos Reason 2 前提でビルドされた compose を提供しています。以前の VSS 3.1.0 EA 検証記事 でも触れたように、ここを Cosmos 3 系で置き換えるには NVIDIA 側のロードマップ整備を待つのが順当です。
次に、Jetson Orin Nano / AGX Thor のようなエッジ環境で動かしているケース。Cosmos Reason 2 は ARM64 と量子化（FP8 / NVFP4）の実績があり、エッジ展開のレシピもそろっています。Cosmos 3 系は現時点では BF16 が中心で、エッジ向けの軽量版 Cosmos 3 Edge はまだ提供前です。Jetson で動かす前提なら、当面は Cosmos Reason 2 が手堅い選択になります。
3 つ目は、複数カメラの並列ストリーミング監視のように、ストリーム数を稼ぐ用途。VSS Blueprint のベンチでも DGX Spark と AGX Thor の組み合わせで 14 並列ストリームが Cosmos Reason 2 で回せることが示されていて、密度の高い監視用途では実績重視で選ぶ場面です。
4 つ目は、PPE 検出・異常検知・動作分類のように、構造化 JSON で完結する事象検出。Cosmos 3 Nano も同じプロンプトで同じ JSON 構造を返してくれるので「乗り換えても精度は変わらない」のですが、逆に言えば「乗り換えても得るものが小さい」とも言えます。既存のパイプラインが回っているなら、わざわざモデルを差し替える理由はあまりありません。
総じて Cosmos Reason 2 は、軽量・低レイテンシ・既存実績重視というポジションで当面強みが残ります。VSS の標準セットを Cosmos 3 系に切り替える機運が NVIDIA から出てくるまでは、これが安定運用の最適解、というのが個人的な見立てです。
Cosmos 3 Nano に置き換える価値がある場面
逆に、Cosmos Reason 2 から Cosmos 3 Nano に乗り換える価値がある場面も明確にあります。精度自体は誤差レベルで並んでいるので、判断軸は「精度の差」ではなく「Cosmos 3 Nano にしか乗っていない性質」になります。
1 つ目は、因果推論や CoT が必要なシナリオ。「なぜこの異常が起きたか」「次にどう動くべきか」を段階的に説明させたい場面では、Reasoner Tower の reasoning chain が効きます。前節の Embodied Reasoning で見たとおり、プロンプト側で具体的なリスク観点や手順を指定すると <think> の中に実体的な推論を引き出せます。
2 つ目は、ロボティクスの軌道計画。Robot CoT で計測した 8 秒前後の軌道生成は、SO-ARM101 や Reachy Mini のような小型アームに「画像入力 → 軌道生成 → ACT / GR00T へ橋渡し」というインタラクティブな流れを組むときに使える速度感です。
3 つ目は、多モーダル同時 reasoning。Cosmos 3 Nano は 256K の長コンテキストに加えて、omnimodel として画像・動画・音声・action までを 1 つのモデルで扱えます。複数の画像と動画とテキストを横断する長時間レポート生成や、製造ラインの 1 日分の映像サマリーのような入力を、モダリティをまたいで処理したい場面で効いてきます。
4 つ目は、世界基盤モデル由来の物理推論が要る場面。Cosmos 3 Nano の Reasoner Tower は Generator Tower と shared latent representations（共有の中間表現）でつながっているので、生成側の物理学習が間接的に染み出してきます。生成までは要らないけれど物理感は持っていてほしい、というニッチな要件にハマります。
実装の現実性としては、JSON 出力の構造が Cosmos Reason 2 と互換なので、VLM-as-Verifier の Sidecar 互換性や本番運用の安定性さえ詰めれば、既存の Cosmos Reason 2 パイプラインを Cosmos 3 Nano に置き換える改修は最小限で済みそうです。
Cosmos 3 Nano を omnimodel として投入すべき場面
ここまでは Reasoner Tower を VLM として使う話でしたが、Cosmos 3 Nano は理解と生成を 1 モデルに同居させた omnimodel です。理解と生成を同時に動かす必要があるユースケースでこそ真価を発揮しそうです。
代表的なのが、観察 → 計画 → 生成 → 制御の一気通貫ワークフロー。DGX Spark で NVIDIA Cosmos 3 を動かしてみた で見た Policy Model がまさにこれで、観測動画と自然言語のタスク指示から、予測動画とロボットの action sequence を同時に出力します。記事 1 で公式の golden 基準（MSE 0.05）を MSE 0.013 で通過したことを考えると、軽量ロボットアームの VLA（Vision-Language-Action）バックボーンとしては実用域に届きそうな手応えがあります。Reachy Mini や SO-ARM101 のような小型ロボットへの組み込みは、今後のロボティクス連載でも継続して扱っていきたい方向です。
合成データ生成も omnimodel ならではの用途です。観察した映像から「もしこの状態から放置したら何が起きるか」「異常イベントが進行したらどう見えるか」を動画として可視化できるので、製造業のコンプライアンス教材や安全教育素材の自動生成に効きそうです。VSS Event Reviewer で抽出した異常イベントを Cosmos 3 Nano の生成モードに渡す、という組み合わせが現実的に見えてきます。
Sim2Real ロボティクスのデータ拡張も、生成側を活かすシナリオです。LeRobot v3 形式の synthetic episodes を Cosmos 3 で量産して policy 学習に回す流れができれば、実機テレオペでのデータ収集ボトルネックを大きく緩和できます。DGX Spark で動かす場合は Cosmos 3 Nano が現実解で、Super はパラメータ規模・メモリ要求の両面で別の GPU 環境を用意する前提になります。
Generator 機能が中心になる場面
生成側に重心を置きたい場面もあります。動画・画像・音声・action の生成は、前世代までは Cosmos Predict 2.5 や Cosmos Transfer といった別モデルに分かれていました。Cosmos 3 はこれを omnimodel に統合し、さらに画像 → 動画特化の Super-Image2Video、テキスト → 画像特化の Super-Text2Image といった生成特化の派生も用意しています。過去の Cosmos Predict 2.5 系の用途は、概ね Cosmos 3 でカバーできる方向に動いていきそうです。
特に Sim2Real のデータ拡張では、Cosmos Predict 2.5 で動画生成 → policy で行動推論、という 2 段パイプラインを組んでいた部分が、Cosmos 3 Nano なら 1 推論に集約できます。以前 Predict 2.5 を動かしたときは、2B モデルで 1280×704 の動画を 36 ステップ生成するのに約 30 分かかっていました。これに対して、記事 1 で測った Cosmos 3 Nano の Policy Model は出力規模こそ小さめ（640×480 × 17 frames）ですが、21 秒で動画と action を同時に出してくれる、という違いが出ています。出力規模が違うので単純比較はできませんが、ワークフロー全体としての体感は別物に近い印象です。
ただし、超高解像度の長尺動画生成（4K × 30 秒のような映画系用途）は Cosmos 3 の射程から外れています。これは Veo や Wan のようなクラウドベースの専用映像生成モデルに任せる領域なので、Cosmos 3 で「何でも作れる」と思って入っていくと用途のずれが生じます。Cosmos 3 はあくまで Physical AI のバックボーンとして設計されているので、ロボティクス・自動運転・産業シミュレーションに向いた解像度・フレーム数で運用するのが向いています。
まとめ
NVIDIA Cosmos 3 の使い分けマップを、Reasoner Tower の実測を交えて整理しました。整理するとこんな流れでした。
まず Cosmos 3 は Nano / Super という omnimodel を軸に、生成特化派生やロボット制御モデルがそろい、近日 Cosmos 3 Edge も加わる構成です。DGX Spark で実用的に動かせるのは Nano が中心で、Super 系は別環境にオフロードする前提になります。次に、Reasoner Tower の日本語視覚推論は Heron-Bench 2.777・JMMMU 0.498 と Cosmos Reason 2 に拮抗していて、乗り換えの判断軸は精度ではなく「Cosmos 3 にしかない性質」になります。具体的には、因果推論・CoT・omnimodel ならではの多モーダル入力・物理推論が活きる場面が乗り換えどころです。さらに観察 → 計画 → 生成 → 制御の一気通貫が要るロボティクスや合成データ生成では、omnimodel として Cosmos 3 Nano を投入する価値が出てきます。
DGX Spark 128 GB ユニファイドメモリという単一ノード環境を前提にしたとき、Cosmos Reason 2 を継続するか、Cosmos 3 Nano に乗り換えるかを場面ごとに切り分けて、同居・切り替え運用にするというのが、いまの段階での現実解だと感じています。Reason 2 を主軸に据えつつ、Reasoner Tower の reasoning chain や Policy Model が効きそうな新規ユースケースから順次取り込んでいく、というアプローチが安全そうです。
参考リンク
- NVIDIA Cosmos プラットフォーム概要
- NVIDIA Cosmos 3 公式発表（NVIDIA Blog）
- Cosmos 3 のライセンス（OpenMDW 1.1 / Linux Foundation）
- DGX Spark で NVIDIA Cosmos 3 を動かしてみた
- DGX Spark で Cosmos 世界基盤モデルを動かしてみた（Predict 2.5 + Reason 2 入門）
- Cosmos-Reason2 で画像と動画の構造化分析を DGX Spark で試してみた
- Cosmos-Reason2-8B を DGX Spark で PPE 検出向けにファインチューニングしてみた
- VSS 3.1.0 EA とハノーバーメッセで見えた製造業 VSS の今を調べてみた
- NVIDIA VSS + AI Agents + Skills の身近な現場での使いどころを考えてみた
