AWS、SageMaker HyperPod上で「NVIDIA Cosmos 3」を活用した物理AIモデルファクトリー構築手法を公開
要点
- AWSが、Amazon SageMaker HyperPod上でNVIDIAの基盤モデル「Cosmos 3」を用いた物理AI向けモデルファクトリーの構築手法を公式ブログで公開した。
- Cosmos 3は動画・画像・行動・音声を単一トランクで統合処理し、データ生成・ラベリング・行動制御の3つの役割を兼ねる。
- 従来は工程ごとに個別確保していたGPUリソースを単一のノードプールに統合し、時分割で効率的にパイプラインを実行可能にした。
- クラスタ設定やDROIDデータセットを用いたロボットポリシー学習のエンドツーエンドな検証コードがGitHub上で提供されている。
リード文
米Amazon Web Services（AWS）は2026年9月4日、機械学習に関する公式ブログ「AWS ML Blog」において、同社の分散学習基盤「Amazon SageMaker HyperPod」と米NVIDIAのオープン基盤モデル「NVIDIA Cosmos 3」を組み合わせた「物理AIモデルファクトリー」の構築手法を公開した。ロボットや自動運転システムに向けたデータ生成、事後トレーニング、シミュレーション評価という一連の開発サイクルを、単一のGPUクラスタ上で継続的かつ効率的に運用するアーキテクチャが解説されている。検証に必要なインフラテンプレートやジョブマニフェストを含むコードは、GitHub上でオープンに提供されている。
物理AI開発に求められる継続的パイプライン
ロボットや自動運転車（AV）のように、実世界のデータを取り込んで物理的な動作へと変換する物理AI（Physical AI）は、単一の学習ジョブを実行するだけでは構築できないとAWSは指摘している。実用的なシステムを実現するには、合成データの生成、認識および行動ポリシー（判断基準）モデルの事後トレーニング（post-training: 事前学習後のモデルを特定用途向けに調整する工程）、そして閉ループシミュレーションによる評価を繰り返す継続的なパイプラインが不可欠とされる。
このパイプラインを恒常的に稼働させ、実世界から次々に送られてくるデータを基にモデルの改善サイクルを回し続ける仕組みが「物理AIモデルファクトリー」である。しかし従来の開発環境では、合成データの生成、事後トレーニング、モデル評価の各工程に対して個別にGPUノードを調達・構築・破棄することが多く、リソースの運用管理や調達の面で非効率が生じやすかったという。
単一モデルで3役をこなす「NVIDIA Cosmos 3」の設計
今回の構成で中核を担うNVIDIA Cosmos 3は、動画、画像、行動、音声を単一のトークン列として扱うオープンなオムニモーダル世界基盤モデルである。Linux Foundationが定める「OpenMDW-1.1 license」の下で提供されている。
従来の一般的な世界モデルでは、動画生成用の拡散トランスフォーマーとテキスト条件付け用の視覚言語モデル（VLM）を別々に組み合わせる構成が多かった。これに対しCosmos 3は、Mixture-of-Transformers（MoT）構造や層ごとのジョイントアテンション機構、学習時と推論時の意図的な非対称性を採用し、すべての層でこれらを統合した単一のトランスフォーマートランクを持つ点に特徴がある。
この単一のトランクが、以下の3つの動作モードを同一ファミリー内で切り替えて実行する。
- 順力学世界モデル: 合成動画データの生成を担うモード
- 逆力学アクションラベラー: 収集・生成したデータに対する動作ラベル付けを行うモード
- デプロイ可能なアクションポリシー: 実機へ展開可能な行動制御モデルとして機能するモード
このように1つのモデルファミリーで生成・学習・評価の全工程をカバーできるため、工程ごとに独立したモデルや異なる計算資源を用意する必要がなくなるとしている。
SageMaker HyperPodとEKSによるリソース統合
AWSが提案するモデルファクトリーでは、Amazon Elastic Kubernetes Service（Amazon EKS: コンテナ環境を管理するAWSのマネージドサービス）と連携したSageMaker HyperPod上に、耐障害性を備えた単一の永続的なGPUノードプールを構築する。Cosmos 3が持つ3つのワークロードをこの単一のコントロールプレーン配下にスケジューリングし、リソースを時分割（タイムシェアリング）で共有させる仕組みとなっている。
インフラ構成としては、クラスタ環境と複数テラバイト規模の共有ストレージ層をセットアップする手順が示されている。さらに、代表的な3種類のワークロードにおける分散事後トレーニングについて解説されており、公開されているロボット操作データセット「DROID」を用いたロボットポリシー学習ステージのエンドツーエンドな実装手順も網羅されている。これらの環境を構築するためのマニフェストや設定ファイルは、AWSのGitHubリポジトリ「awsome-distributed-ai」内のpytorch/cosmos3ディレクトリで公開されている。
キャパシティ確保と「GPU Goodput」によるコスト評価
物理AIの開発サイクルを円滑に回すためには、計算リソースの確保方法も重要となる。記事では、各工程の実行ごとに個別でGPUを確保しようとすると、調達リードタイムや在庫の変動に左右され、データが存在する場所とは異なるリージョンやアベイラビリティゾーンにノードが割り当てられてしまうリスクがあると解説されている。
こうした無駄や混乱を避けるため、期限が決まったプロジェクトであれば柔軟なトレーニングプラン（flexible training plan）、長期的なプロジェクトであればキャパシティ予約（capacity reservation）を利用し、ループ全体に対して計算資源を固定的に確保するアプローチが推奨されている。
このようにリソースを常時確保した運用形態では、単一ジョブにおける瞬間的なピークスループットを追うだけではコスト効率を正しく測れないという。コスト評価において決定的な指標となるのは、予約したGPU時間全体に対してパイプラインがどれだけ有用な進捗を生み出せたかを示す「GPU goodput（有効進捗率）」であると論じられている。