AWSが発表した、フィジカルAI開発で必要となる専用ツールチェーン

　Amazon Web Services（以下、AWS）は、フィジカルAIの開発から実環境へのデプロイまでを一貫支援するという「Physical AI Toolchain on AWS」を発表した。フィジカルAIの開発ライフサイクル全体をAWS上で運用するための、リファレンスアーキテクチャ、Infrastructure as Code（IaC）、デプロイ自動化機能を1つにまとめ、NVIDIA Physical AIスタックと統合したオープンソースのソリューションだという。

フィジカルAIには専用のツールチェーンが必要

　フィジカルAIの開発プロセスでは、物理的な力学特性、リアルタイムの制約、センサーノイズ、安全上の境界、遅延を、加えて現実世界におけるテストでは、ハードウェアの破損の可能性がありコストがかかる現実を考慮する必要があるという。

　フィジカルAIには、汎用的なMLOpsの前提が通用しない。AWSは、目的特化型のインフラストラクチャが必要となる5つの課題を以下に示している。

1. 様々な計算資源の混在：1つのフィジカルAIのワークフローの中で、基盤モデルトレーニングのための高帯域のGPUクラスター、物理シミュレーションのための柔軟な中位クラスのGPU容量、ロボット上のリアルタイム推論のためのエッジGPUが使われる。1つの計算サービスですべてをカバーすることはできない
2. アーティファクトの乱立：各ロボットリリースには、データセット、シミュレーションシーン、ロボットURDF記述、キャリブレーションデータ、トレーニングコンテナ、チェックポイント、評価結果、デプロイ可能なエッジパッケージが含まれる。それぞれのステップを横断し、アーティファクトの昇格が制御されていないと、数週間のうちに再現性が失われる
3. 検証の深さ：故障したロボットが再起動した時には、物理世界の状況はすでに変化している。フィジカルAIは、シミュレーション、監督下での実機テスト、管理された実環境での展開を経て、段階的に昇格させる必要がある。ロボットアームにはシンプルなブルーグリーンデプロイメントに相当するものはない
4. データの経済性：実機ロボットのデータの収集にはコストがかかる。実環境グレードのポリシーは何百もの異なる環境への対応が求められる。デモンストレーションデータを、合成データによる拡張や強化学習によって増幅していくループが必要
5. 制御経路の配置：物理的な動きを決定する推論は、ロボット上の遅延、電力の予算、熱の制約に縛られる。クラウドはトレーニングやロボット群の管理を担うが、安全に関わる物理タスクの制御ループとなることはできない

　5つの課題はすべて相関しているとのこと。ツールチェーンの価値は、トレーニングスクリプトが1つ増えることではなく、データの取り込みからシミュレーション、エッジデプロイに至る整合性のある検証済みのプロセスであり、多くのチームが時間を費やす引き継ぎの部分を担う点にあるとしている。

Physical AI Toolchain on AWS

　AWS上でのフィジカルAI開発ライフサイクル専用に設計された、リファレンスアーキテクチャ、IaC、デプロイ自動化機能を組み合わせ、NVIDIAのロボティクスソフトウェアスタック―視覚・言語・行動（VLA）トレーニング用「GR00T」、物理シミュレーション用「Isaac Sim」、大規模強化学習用「Isaac Lab」、合成データ生成用「Cosmos」、ワークフローオーケストレーション用「OSMO」―を再現性のある単一のパイプラインに統合。AWSマネージドサービス上で展開するという。

　ユーザーとそのチームは、引継ぎのたびに基盤を構築し直すことなく、再現性のある方法でデータ、モデル、シミュレーションジョブ、デプロイメントアーティファクトをステージ間で移行できるとのことだ。

オープンスタンダードに基づく構築

　同ツールチェーンは、NVIDIAのコンポーネントに加えて、ロボティクスチームがすでに利用している公開ツールの上に構築されているという。Zarr形式の生データを読み込んでコミュニティ標準のLeRobot形式に標準化し、PyTorchとHugging Faceで学習を行い、Gymnasiumで強化学習タスクを定義し、URDFでロボットを記述し、移植性の高いエッジ推論のためにONNX形式でエクスポートするとのことだ。ロボット上の制御は、モデルから ROS 2に引き継がれる。これにより、データやモデルを移植性の高いオープンなフォーマットで保持できるとしている。

設計原則

　以下3つの設計原則に基づいているという。

1. モノリシックでなくモジュラー型：各コンポーネント（基盤、Isaac Sim、Isaac Lab、GR00T、OSMO）は独立したTerraformモジュールになっており、1つずつ段階的に導入することも、パイプライン全体に展開することも可能。モジュールはSSMパラメータを通じてコンフィギュレーションを共有するが、厳密な依存関係はない
2. AWSインフラストラクチャ上のNVIDIAネイティブ：ツールチェーンは、AWSのコンピュート、ストレージ、ネットワーキング、セキュリティサービス上でNVIDIA Physical AIスタックを実行する。直接NVIDIAのドキュメンテーションをフォローしても、クラウドネイティブなデプロイ自動化のメリットを享受できる
3. リニアなパイプラインではなくフライホイール・アウェア：基盤によってフィジカルAI開発の持つ反復的な特性をサポート。デプロイからフィードバックされたデータが新たなシミュレーションシナリオに活用される。生成された合成データが学習に活用されるとのこと。学習済みモデルが検証に活用される。ツールチェーンは決まった順序を強制するのではなく、フライホイール内のあらゆる移行に対応する基盤を提供する

アーキテクチャ

　基盤にある複雑さを抽象化し、開発のフライホイールをAWSソリューションに当てはめると述べている。このアーキテクチャは意図的に垂直構造にして、各ピラーが独自にAWSのマネージド基盤上でNVIDIAドメインレイヤーを備える形になっているとのこと。アーキテクチャ全体のボトムレイヤーはStrandsエージェントレイヤーで、Strands Agents SDKをもとに構築されたAIドリブンなオーケストレーションレイヤーだとしている。

　ユーザとそのチームは、個別に1つのピラーを採用することも、エージェントオーケストレーションで移行を管理し、ピラーを連携させてエンドツーエンドの完全なパイプライン全体を構築することも可能とのことだ。

　データは、各ピラーを左から右へと流れる。遠隔操作装置の生データがAmazon Simple Storage Service（Amazon S3）に届き、Amazon Elastic Kubernetes Service（Amazon EKS）やAWS BatchとNVIDIA Cosmosで合成世界の生成が行われ、AWS BatchとAmazon SageMakerでNVIDIA Isaac LabおよびIsaac GR00Tを使ってポリシー学習、Amazon Elastic Compute Cloud（Amazon EC2）上の NVIDIA Isaac Simで検証を実行し、最終デプロイで、AWS IoT Greengrassを使用して、最適化されたモデルをNVIDIA Jetsonハードウェアにプッシュする。Amazon SageMakerやAWS Batchで学習や微調整ジョブを実行することで、実装コストを最適化するという。

　Strandsエージェントレイヤーは、一般に公開されているStrands Agents SDKをもとに構築され、ツールチェーン全体にAIネイティブなインターフェースを提供。チームは各パイプラインのバリエーション向けにカスタムのオーケストレーションスクリプトを書く代わりに、自然言語や構造化されたプロンプトで意図を記述するだけで済むとのことだ。あとはエージェントレイヤーが、呼び出すべきコンポーネントを判断し、必要なコンピューティングリソースを割り当て、データの受け渡しを管理し、結果を報告するとしている。

NVIDIA Physical AI スタックの統合

　NVIDIAはドメイン特化型レイヤーを提供するとのことだ。

• Isaac Sim：シーン構成、物理的に正確なレンダリング、リアルタイムシミュレーション
• Isaac Lab：数千の並列環境での大規模強化学習
• Isaac GR00T：デモンストレーションに基づく視覚・言語・行動（VLA）モデルの微調整
• Cosmos：世界生成と合成データセットの規模拡大のための視覚データの拡張
• OSMO：異種コンピューティング環境（クラウド、オンプレミス、エッジ）にわたるワークフローのオーケストレーション
• Jetson / RTX：リアルタイム制約下におけるエッジ推論向けのターゲット実行環境ハードウェア

　AWSは実行環境を提供するという。

• Amazon EC2（NVIDIA GPU インスタンス）：シミュレーションおよび合成データ生成
• Amazon SageMaker / AWS Batch：自動プロビジョニング機能を備え、アイドル時コストがゼロのマネージド型トレーニング
• Amazon EKS：GPUスケジューリングを活用した、スケーラブルかつ分散型のOSMOおよびクラスターワークロード向け
• Amazon S3、Amazon Elastic Container Registry（Amazon ECR）、Amazon FSx for Lustre：データセット、コンテナ、高スループットなトレーニングデータの配信
• Amazon CloudWatch、AWS Secrets Manager、AWS Key Management Service（AWS KMS）、AWS IoT Greengrass：オブザーバビリティ、セキュリティ、エッジデプロイメント

　ツールチェーンは、これら2つのスタック間の境界における摩擦を軽減。AWSはインフラストラクチャのプロビジョニング、デプロイの自動化、セキュリティ・プリミティブ、マネージドサービスの統合に対応するという。NVIDIAは、フィジカルAI担当チームがすでに使用しているシミュレーションエンジン、基盤モデル、オーケストレーションレイヤーを扱うとのことだ。

【関連記事】
・日立、社会インフラでフィジカルAIを安全に運用するためのガードレール技術を開発
・NTTPC、フィジカルAI開発支援のため「占有環境」でGPUリソースを提供へ
・ミス・遅延が許されないフィジカルAIの世界で、AMDが出した技術・製品による“回答”とは？