- Cosmos 3は映像・画像・行動・音声を1つのトークン列で扱う
- HyperPod上でデータ生成・訓練・評価を1つのGPUプールに統合
- Nano 16B、Super 64B、Edge 4Bの3規模を提供
発表の概要
Amazon Web Servicesは2026年9月4日付けのブログで、NVIDIA Cosmos 3とAmazon SageMaker HyperPodを組み合わせた「Physical AIモデル工場」の構築方法を公開した。ここでいうPhysical AIとは、ロボットや自動運転車のように実世界のデータを物理的な行動に変換するAIシステムを指す。
ブログは、このようなシステムは1回の学習ジョブでは完成せず、実データの収集とキュレーション、合成データの生成、ポリシーの追加学習、シミュレーションでの評価を循環させる継続的なパイプラインが必要だと説明している。そのループ全体を実行する仕組みが、モデル工場という考え方だ。
Cosmos 3の技術的特徴
Cosmos 3の最大の特徴は、映像・画像・行動・音声を単一のトークン列として扱うオムニモーダル世界基盤モデルである点だ。従来は映像生成に拡散トランスフォーマー、テキスト条件付けに視覚言語モデルを組み合わせる構成が一般的だったが、Cosmos 3は1つのトランクに統合し、層ごとに注意機構で結合する「Mixture-of-Transformers」を採用している。
さらに、学習時と推論時で計算量を意図的に変える非対称設計を導入している。学習時は全拡散ステップとビデオ復号を実行する一方、ロボット上での推論時は数ステップの拡散のみでビデオ復号を省略し、行動トークンだけを出力する。これにより、同じモデルを前方ダイナミクス（世界モデル）、逆ダイナミクス（行動ラベリング）、ポリシー（配備用）の3モードで使い分けられる。
HyperPod上での実装
ブログで紹介するモデル工場は4段階で構成される。まず実データをS3とFSx for Lustreに取り込んでキュレーションし、次にCosmos3-Super教師モデルで合成データを生成する。続いて合成データと実データを用いてCosmos3-Nanoポリシーを追加学習し、最後にクローズドループシミュレーションで評価するという流れだ。評価で見つかった失敗例は次の世代のデータとしてコーパスに戻され、ループが継続する。
SageMaker HyperPodはEKSでクラスタをオーケストレーションするため、生成、学習、評価の各ステージを1つの共有GPUプール上のKubernetesワークロードとして実行できる。FSx for LustreをEFA経由でマウントし、S3のデータリポジトリ連携を組むことで、ステージ間のデータ移動を減らしている。HyperPodの障害ノード自動検出・置き換えやジョブ自動再開も、この継続運用を支える要素だ。
既存手法との比較
従来のPhysical AIパイプラインでは、データ生成、追加学習、評価の各ステージに対して個別のGPUクラスタを用意し、それぞれ起動・停止する運用が一般的だった。Cosmos 3は1つのモデルが複数モードを持つため、こうした分離が不要になり、1つの永続クラスタ上で各ステージを時分割で実行できる。
ブログは、コストの指標は単一ジョブのピークスループットではなく、予約したGPU時間あたりの有効なパイプライン進捗（GPUグッドプット）だと指摘する。このため、柔軟なトレーニングプランやキャパシティ予約でループ全体に容量をコミットすることが重要だとしている。
現時点での注意点
ブログには設定ファイルや実行可能なコードが付属しているが、実際のクラスタ規模やコスト、性能値は明記されていない。Cosmos 3の各モードが求められる品質を満たすかは、ユーザー自身のデータとワークロードで検証する必要がある。
また、Cosmos 3はLinux FoundationのOpenMDW-1.1ライセンスで公開されている。商用利用の条件や派生モデルの扱いはライセンス本文を確認しなければならない。AWSでの利用方法は示されているが、特定リージョンや日本国内での可用性はブログだけでは判断できない。
| 項目 | Cosmos3-Nano | Cosmos3-Super | Cosmos3-Edge |
|---|---|---|---|
| パラメータ数 | 16B | 64B | 4B |
| バックボーン | Qwen3-VL（8B） | Qwen3-VL（32B） | 独自（約2B） |
| 想定用途 | 配備可能なポリシー | 教師モデルによる合成データ生成 | オンデバイス推論 |
A Physical AI system, such as a robot or autonomous vehicle (AV) that translates real-world data into physical actions, can’t be built in a single training job.
ロボットや自動運転車のように実世界のデータを物理的行動に変換するPhysical AIシステムは、単一のトレーニングジョブでは構築できない。
今後の見通し
今後、Cosmos 3がPhysical AI開発の標準的な選択肢となるかどうかは、モデル工場を実際のプロジェクトで運用し、どれだけ継続的にモデルを改善できるかにかかっているとみられる。次に注目すべきは、NVIDIAが公開するベンチマーク結果や、Edgeモデルの実機性能、OpenMDW-1.1ライセンスの解釈が具体的に示されることだ。また、AWSだけでなく他のクラウドや既存ロボット開発スタックとの統合事例が増えれば、比較検討が容易になるだろう。
日本の開発者・IT企業にとっての意味
日本のIT企業がロボットや自動運転のAI開発を進める際、従来はデータ生成、モデル学習、評価をそれぞれ別のGPU環境で運用し、その間のデータ移動やキャパシティ管理にコストがかかっていた。Cosmos 3とSageMaker HyperPodの組み合わせは、これらを1つのクラスタに統合できる可能性を示しており、開発ループを高速化できる点で実務的な意味がある。特に、物理データを扱う企業にとっては、合成データ生成と実データの追加学習を同じインフラで循環させられるため、開発環境の再設計につながる。ただし、導入にはOpenMDW-1.1ライセンスの確認や、自社ワークロードでの性能検証が不可欠であり、まずはAWSのブログが公開しているコードを試しながら評価するのが現実的な出発点になるだろう。
気になる点
- Cosmos 3の実行に必要な設定やコードはどこで入手できますか？
- AWSブログの付属リポジトリ「awsome-distributed-ai」に、インフラストラクチャのテンプレートと各ステージのジョブ定義が含まれています。モデル自体はNVIDIAがLinux FoundationのOpenMDW-1.1ライセンスで公開しており、NVIDIAの提供チャネルから取得することになります。
- 1つのクラスタで生成・学習・評価を同時に回すと混雑しないのでしょうか？
- ブログでは、Cosmos 3が1つのモデルをモード違いで動かすため、同一GPUプール上で時分割にスケジュールできると説明しています。ただし、具体的な同時実行数や混雑時の挙動は記載されておらず、実際のワークロードに応じてノード数やスケジューリングを調整する必要があります。
- 既存のプロジェクトをCosmos 3に移行できますか？
- ブログでは移行手順そのものは解説していませんが、モデル工場を構成する方法として、データのS3/FSx for Lustreへの配置、HyperPodクラスタの構築、各モード用のジョブ定義を置き換える方式が示されています。既存のパイプラインが別々のGPU環境を使っている場合、統合は個別の設計判断が必要とみられます。
用語解説
- Physical AI
- ロボットや自動運転車など、実世界のデータを物理的な行動に変換するAIシステム全般を指す。
- 世界モデル
- 環境の状態遷移を予測するモデル。将来の映像や状態を生成することで、行動計画やシミュレーションに使われる。
- Mixture-of-Transformers
- 複数のトランスフォーマーを組み合わせる技術。Cosmos 3では各層でreasonerとgeneratorを注意機構により結合している。
- オムニモーダル
- テキスト、画像、音声、行動など複数のモダリティを同時に扱うこと。Cosmos 3はこれらを単一のトークン列に統合する。
- GPUグッドプット
- 予約したGPU時間あたりに得られる有効なパイプラインの進捗量。ピーク性能ではなく継続運用の効率を示す指標。
出典
Build a Physical AI model factory with NVIDIA Cosmos 3 on SageMaker HyperPod
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する