先に結論
AWSとNVIDIAが示した「物理AIモデル工場」の本質は、巨大モデルを一度だけ学習することではありません。現場の失敗を次の学習へ戻すサイクルを、データ収集、合成データ生成、ポストトレーニング、閉ループ評価、再学習として回し続けることです。SageMaker HyperPodが向くのは、このサイクルを複数チーム・複数GPUノードで継続する企業です。単発のファインチューニングなら、常設クラスターより一時的な学習ジョブの方が合理的な場合があります。
GLOBAL AI BRIEF ・ PROCESS
現場の失敗を次の学習へどう戻すか？
- STEP 01実データを集めるS3とFSxへ取り込む
- STEP 02不足場面を合成Superで学習条件を補う
- STEP 03方策を追加学習Nanoをポストトレーニング
- STEP 04閉ループで評価失敗例を次のデータへ戻す
AWSが公開したのは「モデル」ではなく継続運用の設計
AWSは、NVIDIA Cosmos 3をAmazon SageMaker HyperPod上で運用する参照構成を公開しました。対象はロボットや自動運転など、カメラ映像やセンサー情報を受け取り、現実空間で行動を返す「物理AI」です。
一般的な生成AIと違い、物理AIは現場の失敗が次の学習データになります。実データを取り込み、足りない場面を合成し、方策モデルを追加学習し、シミュレーションで失敗条件を見つけ、再びデータへ戻す。この循環が止まると、モデルは新しい環境や例外に追随できません。
したがって評価すべき対象は、単体モデルの精度だけではありません。データが学習へ戻る速さ、障害後に再開できるか、GPUをどれだけ有効に使えるか、チーム間で計算資源を安全に共有できるかまで含めて「工場」と呼んでいます。
Cosmos 3は映像・行動・音を同じ系列で扱う
NVIDIA Cosmos 3は、動画、画像、行動、音声を一つのトークン系列として扱う設計です。AWSの説明では、共通のTransformer本体を三つのモードで使い分けます。
一つ目は、行動を条件に次の映像を予測する世界モデルです。二つ目は、映像から行動ラベルを推定する逆ダイナミクスです。三つ目は、現在のフレームから次の行動を出す方策モデルです。同じ基盤で「環境を予測する」「行動を読み取る」「行動を選ぶ」をつなげられる点が、モデル工場の中核です。
モデル階層は、Cosmos3-Nanoが約16B、Cosmos3-Superが約64Bと説明されています。Nanoは密な8B規模のQwen3-VLバックボーン、Superは密な32B規模のバックボーンを使います。別系列としてCosmos3-Edge 4Bもあります。用途とGPU予算を分けず、すべてを同じモデルとして扱うと設計を誤ります。
4段階のフライホイールで失敗を次の学習へ戻す
公開構成は四段階です。まず実世界データをAmazon S3やFSx for Lustreへ取り込みます。次にSuperを教師として合成データを生成し、実データと合成データを混ぜてNanoの方策モデルをポストトレーニングします。最後に閉ループシミュレーションで評価し、失敗例を次のコーパスへ戻します。
この順序で重要なのは、合成データを増やすこと自体ではありません。不足条件を埋め、閉ループ評価で効果を確かめることです。失敗条件との対応がない合成データは、量が多くても改善につながるとは限りません。
HyperPodはGPUの速さより「止めずに回す」役割を担う
SageMaker HyperPodのEKS構成では、合成、学習、評価、可視化の各工程が一つの共有GPUプールを使います。データはS3を背後に持つFSx for Lustreで共有し、工程ごとのコピー待ちを減らします。
学習ジョブにはKubeflowのPyTorchJobを使い、障害時は最新の分散チェックポイントから自動再開します。ノード障害の検知、再起動または交換、EFAとNCCLによる複数ノード通信も運用部品に含まれます。必要ならKueueでチーム別の優先度や割当も管理できます。
つまりHyperPodの価値は、GPUを単純に速くすることではなく、復旧・資源競合・データ共有・監視を一つの運用面へまとめることにあります。
一次情報で確認できる実測値
AWSは公開DROIDデータセットを使い、Nanoのロボット方策学習、NanoのVision SFT、SuperのVision LoRAを実行しています。使用インスタンスはp5en.48xlargeで、1ノードあたりNVIDIA H200を8基搭載します。
| 確認項目 | AWS公開値 | 読み方 |
|---|---|---|
| Super LoRAの強スケーリング | 1〜4ノード（8〜32 GPU）で約0.97〜0.99 | ノード追加に対し、ほぼ線形に近い伸び |
| ステップ時間 | 構成間で約3%以内 | 規模拡大時のばらつきが小さい |
| MFU | Super約0.50、Nano Vision約0.24 | モデルと処理内容でGPU活用率が異なる |
| 検証規模 | 最大4ノード、32 GPU | この範囲を超える性能は未確認 |
これらはAWS自身の参照構成で得た値であり、独立ベンチマークではありません。自社データの解像度、系列長、チェックポイント頻度、ネットワーク、前処理で結果は変わります。
見るべきKPIはピーク性能ではなくgoodput
AWSは、予約したGPU時間のうち、実際に学習パイプラインが前進した割合をgoodputとして重視しています。GPU利用率が高くても、再試行、データ待ち、チェックポイント、障害復旧に時間を使えば、モデル工場全体の生産性は上がりません。
チェックポイント間隔にはYoung/Daly式の考え方が紹介されています。保存に30秒、平均故障間隔を24時間と仮定すると、例示された最適間隔は約2,300秒、約40分です。壁時計時間に対する負担は約1%とされています。
これは固定値ではありません。自社環境では保存時間と障害間隔を測り、失われる計算量と保存負担が釣り合う点を設定する必要があります。ダッシュボードもGPUテレメトリだけでなく、学習側の進捗指標と一緒に見るべきです。
単発学習と常設モデル工場は分けて判断する
| 条件 | 一時的な学習ジョブ | HyperPod型の常設運用 |
|---|---|---|
| 学習頻度 | 単発・低頻度 | 継続・複数工程 |
| 障害復旧 | ジョブ単位で対応 | チェックポイントとノード復旧を標準化 |
| GPU共有 | 案件ごとに確保 | チーム・工程間で統制 |
| 費用特性 | 使う時間だけ確保しやすい | クラスター所属中のインスタンスとFSxが継続課金 |
AWS自身も、一度限りのファインチューニングなら一時的なSageMaker Trainingの方が合う場合があると説明しています。常設クラスターは、フライホイールを継続し、予約容量を使い切れる組織向けです。
使わない時はGPUグループをゼロへ縮小するか、クラスターを削除します。FSxの削除前にはData Repository AssociationからS3へ必要データを出力できているか確認が必要です。可視化や推論PodがGPUノードを保持していないかも費用点検の対象です。
日本企業が導入前に決めるべき実務条件
GPU台数より先に、戻す失敗と期限を決める必要があります。たとえば把持失敗、照明変化、反射、作業者の割り込みなど、現場で価値がある失敗分類を先に定義します。
次に、実データと合成データの由来、利用権限、保存期間を記録します。工場映像や車載映像には、人物、施設情報、取引先設備が含まれ得ます。学習可能かどうかをデータ単位で追跡できなければ、モデル工場を高速化するほど権利確認が追いつかなくなります。
最後に、goodput、再開成功率、評価合格率、失敗データの再投入時間、GPU時間あたりの改善量を運用KPIにします。モデル精度だけでなく、改善サイクルが短くなったかを経営・現場・MLOpsで共有することが重要です。
PoCは「90日で工場を作る」より一周を閉じる
PoCでは対象タスクを一つに絞り、実データ取り込み、少量の合成、Nanoの追加学習、閉ループ評価、失敗例の再投入までを一周させます。最初から全工程を大規模化すると、どこが改善に効いたか分かりません。
成功条件は、単一ベンチマークの向上だけでは不十分です。障害後に自動再開できたか、データの由来を追えるか、失敗例を次の学習へ戻せたか、予約GPU時間のうち有効な進捗が増えたかを合わせて確認します。
一周が閉じた後に、Superを使う合成範囲、Nanoを使う方策、ノード数、評価シナリオを広げます。この順序なら、常設基盤が必要か、一時ジョブで十分かも実測で判断できます。
まだ分からないこと・適用しない条件
公開記事から確認できるのはAWSの参照構成と公開DROIDデータセットでの検証です。日本の工場、倉庫、車両、独自ロボットで同じスケーリングやMFUが得られることは確認されていません。
Cosmos 3の採用が常に最適とも限りません。既存の知覚モデルや方策学習基盤が安定しており、失敗データの回収頻度が低い場合は、基盤移行の費用が上回る可能性があります。導入判断は、自社の再学習頻度と停止損失を基準に行うべきです。
FAQ：よくある質問
Q. HyperPodを使えばモデル精度が自動で上がりますか？
A. いいえ。HyperPodは継続学習を運用しやすくする基盤です。データ設計、評価シナリオ、失敗例の選別が不十分なら、基盤だけでは精度は上がりません。
Q. Cosmos3-Superだけを使えばよいですか？
A. 役割が異なります。Superを教師・合成側、Nanoを展開可能な方策側として使う構成が示されています。推論制約と学習目的に合わせて分けます。
Q. 小規模な企業でも試せますか？
A. 一つのタスクと少数ノードで一周を検証できます。ただし常設クラスターの費用を正当化できる頻度がなければ、一時ジョブから始める方が安全です。
まとめ
物理AIモデル工場は、合成データを大量に作る仕組みではなく、現場の失敗を次の学習へ戻す運用システムです。AWSの公開値は、最大32 GPUでの拡張性と障害復旧を考える材料になりますが、自社での再現確認が必要です。
導入前には、対象失敗、データ権利、再学習周期、goodput、停止条件を決めてください。単発学習なら一時ジョブ、継続的な改善サイクルを複数チームで回すならHyperPod型という切り分けが、最初の判断軸になります。
出典と検証範囲
一次情報：AWS Machine Learning Blog「Build a physical AI model factory with NVIDIA Cosmos 3 on SageMaker HyperPod」（2026年9月6日確認）。数値・構成・費用条件はAWS公開記事に帰属します。第三者環境での性能、費用対効果、日本企業環境での再現性は未検証です。