NVIDIA、ロボットAI開発を統合

ロボット開発者は、一つの計算問題に直面しているわけではありません。彼らは3つの問題に直面しています。ポリシーはGB200またはH100クラスターで訓練され、Isaac Sim上でRTX GPUを使ってテストされ、その後、実際のロボットに搭載されたJetsonで検証されます。各段階にはそれぞれ独自のクラスター、独自のスケジューラー、そして独自の連携スクリプトがあります。NVIDIA OSMOは、この断片化に対するNVIDIAの答えです。これはオープンソースのKubernetesネイティブなワークフローオーケストレーターで、チームがパイプライン全体を単一のYAMLファイルで記述し、インフラコードに触れることなくすべての段階で実行できるようにします。デプロイ可能か？はい。OSMOはApache-2.0ライセンスで提供され、HelmチャートとコンテナをNGCで提供し、KINDを備えたワークステーション上で完全なコントロールプレーンを実行するローカルクイックスタートも用意されています。これらにより、開発者はより効率的に作業を進められます。 物理AIを「3つのコンピューター問題」として捉えています。訓練はデータセンターのGPUで行われます。シミュレーション、物理演算、センサーレンダリングはワークステーションクラスのRTXハードウェアで行われます。デプロイとハードウェアインザループ（HIL）テストは、通常オンプレミスで、Jetson AGX Thorのようなエッジデバイスで行われます。各段階には通常、独自のツールが使われ、その引き渡し部分でカスタムスクリプトが蓄積されていきます。OSMOはこれら3つすべてを、1つのコントロールプレーンのバックエンドとして扱います。各バックエンドはCLIを通じて登録されたKubernetesクラスターです。ワークフローはクラスター名を指定しません。プラットフォーム名（例：gb200、rtx-pro-6000、またはjetson-agx-thor）を指定すると、OSMOがそのタスクを提供するプールにルーティングします。 ワークフローの例： リポジトリの典型的な例は、データによって連結された3つのタスクです。 シミュレーションはrtx-pro-6000上でIsaac Simコンテナを実行します。 train-policyは、シミュレーションタスクの出力を入力として、8つのGPUを備えたgb200上でPyTorchコンテナを実行します。 evaluate-thorは、訓練されたポリシーを利用し、結果を名前付きデータセットに書き込みながら、jetson-agx-thor上でROSアプリを実行します。 依存関係はinputsから、永続性はoutputsから、配置はplatformから来ます。ユーザーガイドには、直列および並列タスクグループ、パラメーター化されたワークフローのためのJinjaテンプレーティング、リトライポリシー、HIGH/NORMAL/LOWの優先度設定が記載されています。