physical-ai-infrastructure-setup-and-resilient-scaling

Physical AI インフラストラクチャのセットアップと回復性の高いスケーリング

Physical AI インフラストラクチャスタックの正規スキルです。このスキルを使用して、クラスター、推論、OSMO、ワークロードの各ステージを組み合わせ、再現可能な Physical AI SDG 環境を構築します。その後も環境を監視可能かつ復旧可能な状態に保ちます。

運用ルール

• 選択したターゲットに必要なコンポーネントのリファレンスのみを読み込みます。デフォルトですべてのコンポーネントを読み込まないでください。
• リポジトリを永続的な成果物として維持します。チェックイン済みの設定またはスクリプトを修正してから再実行してください。追跡されない一時的な変更で、失敗したインストールから復旧しないでください。
• クラスター、OSMO、Helm、Terraform、または Azure を変更する操作は、スクリプトが存在する場合、チェックイン済みのスクリプトを通じて実行します。読み取り専用の診断は許可されています。
• 最初に失敗したゲートで停止します。次の順序で、最も下位の担当レイヤーを修正します。 設定、スクリプト、スキルのガイダンス。
• 可能な場合は環境から値を導き出します。API キー、ターゲットの選択、クォータのトレードオフなど、推測できない値のみを確認します。
• シークレットは ${REPO_ROOT}/.env に保存します。ストレージ、データベース、Redis、エンドポイント名など、クラスターから取得する値は .env ではなく、Terraform の出力またはプラットフォームへの問い合わせから取得します。
• 事前チェック時には、デプロイ済みの状態が存在しないことが前提です。クラスター API、Terraform の出力、Helm リリース、OSMO プール、ワークフローの状態がないことを確認します。これらはデプロイ／検証ゲートで扱います。
• 生のキーをコマンド、YAML、ログ、トランスクリプトに表示、エコー、貼り付けしないでください。認証情報ハンドル、Kubernetes の secretKeyRef、実行時のみのシークレット注入を優先してください。共有する前に、scripts/scan_transcript_secrets.py で生のトランスクリプトのエクスポートをスキャンします。
• 絶対パスを使用します。git rev-parse --show-toplevel でリポジトリのルートを導き出します。

コンポーネントのリファレンス

各コンポーネントはこのスキル内に配置されているため、スタックの正規のトリガーは1つだけです。選択したターゲットで必要な要素に限り、コンポーネントのリファレンスを読み込みます。

対象	読み込むもの	アセット
ステージのマトリックスと旧ドライバーのメモ	components/driver/reference.md	なし
MicroK8s クラスター	components/cluster-microk8s/reference.md	components/cluster-microk8s/scripts/、components/cluster-microk8s/runtimeclass-nvidia-runc.yaml
Azure AKS クラスター	components/cluster-azure/reference.md	components/cluster-azure/scripts/、components/cluster-azure/terraform/
NIM Operator 推論	components/inference-nim-operator/reference.md	components/inference-nim-operator/scripts/、components/inference-nim-operator/nims/
NVCF 推論	components/inference-nvcf/reference.md	components/inference-nvcf/scripts/
Azure AI Foundry 推論	components/inference-azure/reference.md	components/inference-azure/scripts/
MicroK8s OSMO	components/osmo-k8s/reference.md	components/osmo-k8s/scripts/、上流の OSMO デプロイスクリプト
Azure OSMO	components/osmo-azure/reference.md	components/osmo-azure/scripts/、上流の OSMO デプロイスクリプトと Azure TF 出力
Azure アクセスのセットアップ	components/azure-access/reference.md	なし
OSMO CLI とワークフロー操作	components/osmo-cli/reference.md	components/osmo-cli/scripts/、components/osmo-cli/references/、components/osmo-cli/agents/、components/osmo-cli/tests/
OpenClaw Azure デバイスログイン	components/openclaw-azure-login/reference.md	なし

OSMO CLI のサポートファイル

OSMO CLI コンポーネントは、コマンドとワークフローの範囲が広いため、サポートファイルが第 2 階層にあります。記載されたケースに限り、これらを直接読み込んでください。

ファイル	読み込むタイミング
components/osmo-cli/agents/workflow-expert.md	ワークフロー生成またはワークフロー失敗を担当するサブエージェントを起動する場合。
components/osmo-cli/agents/logs-reader.md	OSMO ワークフローの失敗ログを要約するサブエージェントを起動する場合。
components/osmo-cli/references/cli-commands.md	OSMO CLI の正確なフラグ、ペイロード、またはコマンド構文が必要な場合。
components/osmo-cli/references/workflow-spec.md	ワークフロー YAML スキーマ、認証情報、出力、またはプロバイダーフィールドが必要な場合。
components/osmo-cli/references/workflow-patterns.md	複数タスク、データ依存関係、Jinja、逐次または並列のワークフロー設計が必要な場合。
components/osmo-cli/references/advanced-patterns.md	チェックポイント、再試行／終了時の動作、またはノードの除外が必要な場合。
components/osmo-cli/tests/orchestrator-runtime-failure.md	OSMO オーケストレーションのレビューパターンを検証またはデバッグする場合。

ターゲットの選択

各段階で選択するオプションは 1 つだけです。ステージ 2 はステージ 1 の選択に従います。

1. Kubernetes：MicroK8s または Azure
2. OSMO：Kubernetes が MicroK8s の場合は MicroK8s OSMO、Kubernetes が Azure の場合は Azure OSMO
3. 推論：NIM Operator、NVCF、Azure AI Foundry、または None
4. ワークロード：Video Data Augmentation、Defect Image Generation、NuRec Carline Adaptation、NRE、NCore、Asset Harvester、またはカスタムのワークフロー YAML

プロビジョニングの前に、無効な組み合わせを拒否してください。

クラスター	NIM Operator	NVCF	Azure AI Foundry
MicroK8s	はい	はい	いいえ。Foundry には Azure ID が必要です
Azure	はい	はい	はい

ブラウザーを開けない OpenClaw やチャット専用の環境では、Azure の前提条件を確認する前に components/openclaw-azure-login/reference.md を読んでください。 Azure をターゲットにする場合は、Azure コンポーネントの事前チェックを行う前に components/azure-access/reference.md を読んでください。

セットアップの流れ

1. ターゲットの選択内容とワークロードのコンピューティング要件を確認します。
2. 選択したコンポーネントのリファレンスを読み込みます。
3. API キー、Azure アクセス、呼び出し元 CIDR、GPU クォータ、ストレージクラス、OSMO のログイン要件など、前提条件を事前に解決します。
4. プロビジョニングの前に、選択した各インフラストラクチャコンポーネントと、OSMO CLI／ワークロードの事前チェックを scripts/preflight.sh で実行します。結果に基づいて実装計画を立て、事前チェックが赤の場合は停止します。
5. まず Kubernetes をデプロイします。クラスターのゲートが緑になるまで、ほかの処理を開始しないでください。
6. Kubernetes の後に OSMO と推論をデプロイします。クラスターが作成された後であれば並行して進められますが、ワークロードの送信は、選択した両方のゲートが通過するまで待ってください。
7. OSMO、ストレージ認証情報、コンピュートプール、選択した推論エンドポイントを検証してから、ワークロードを送信します。VDA の場合、これには preflight_credentials.sh、解決済みの --set 値を指定した pre_submit_guard.py、空でないモデルキャッシュのプレフィックス、ワークフローネームスペースからのエンドポイントのスモークテストが含まれます。
8. 完了まで監視します。ワークフローの状態が失敗になった場合は、components/osmo-cli/reference.md を参照してイベントとログを調べてください。確認せずに再送信しないでください。

推論の検出

コストの高いエンドポイントを過剰にデプロイしないようにしてください。

1. 選択したワークフロー仕様とデフォルト値をスキャンし、エンドポイントへの参照を探します。 *.osmo-nims.svc.cluster.local、api.nvcf.nvidia.com/*、 *.inference.ai.azure.com、または *.cognitiveservices.azure.com。
2. 各参照を選択したバックエンドに対応付けます。
   • NIM Operator：サービス名は components/inference-nim-operator/nims/ 内のディレクトリと一致している必要があります。
   • NVCF：関数 URL または関数 ID を環境から指定する必要があります。
   • Azure AI Foundry：エンドポイント名は components/inference-azure/scripts/install.sh を通じてデプロイする必要があります。
3. ワークフローで必要な機能が選択したバックエンドにない場合は、停止して不一致を報告します。別のモデルに黙って置き換えないでください。

検証ゲート

各ステージには、コンポーネントリファレンス内に独自の検証セクションがあります。以下のゲートは必須です。

ステージ	ゲート
Kubernetes	クラスター API に到達できること、ノードが Ready であること、GPU を使用するパスでは GPU 容量がアドバタイズされていること、CPU および NVCF のパスでは runtimeclass/nvidia が runc にマッピングされていること。
推論	ワークロードが参照するすべてのエンドポイントに到達できること。NIM のレディネスでは /v1/health/ready を使用します。NVCF と Foundry では、タスク固有の認証済みチェックも必要です。
OSMO	OSMO ポッドが Ready であること、プールが ONLINE であること、ポートフォワードのウォッチドッグが稼働していること、ストレージ認証情報が設定されていること、verify-hello ワークフローが COMPLETED であること。
ワークロード	選択したワークロードの送信前ガードが、送信前にすべてパスすること。osmo workflow query <id> の結果が COMPLETED で、すべてのタスクが成功状態であること。終端状態が失敗の場合は、再試行する前にイベントとログを確認してください。

レジリエントなスケーリング

• プロビジョニングの前に、ワークロードのニーズに合わせてクラスターの規模を決定します。Azure では、terraform apply の前に、選択した VM ファミリーの CPU と GPU のクォータを確認してください。
• NIM Operator では、ワークロードが参照する NIMServices のみをデプロイします。各サービスは、クラスターの稼働期間中、GPU とモデルキャッシュ用ストレージを確保します。
• OSMO のストレージ URL スキームは、使用中のバックエンドに合わせます。ローカルの MicroK8s では MinIO を使用し、Azure では Blob ベースの設定を使用します。
• Pending、Unknown、ImagePullBackOff、バインドされていない PVC、または Ready レプリカ数が 0 の場合は、レイヤーの障害として扱います。同じコマンドを再試行する前に、スケジューリング、ストレージ、イメージ認証情報、および隣接するプラットフォームの状態を調査してください。
• 長時間のデプロイやワークフローの監視では、現在の状態、経過時間、直近の有用な観察結果、次回の確認内容を含むハートビート更新を提供します。

ワークロードのルーティング

• Video Data Augmentation：skills/physical-ai-video-data-augmentation/SKILL.md を使用します。
• Defect Image Generation：skills/physical-ai-defect-image-generation/SKILL.md を使用します。
• NuRec carline adaptation：skills/carline-adaptation/SKILL.md を使用します。
• NRE、NCore、Asset Harvester は、skills/INDEX.md に記載されている正式な NuRec カタログにあります。
• カスタムワークロード：リソース要求、イメージ認証情報、データ認証情報、推論 URL を確認した後、提供されたワークフロー YAML を OSMO 経由で送信します。

評価プロンプトと結果

• 肯定的なトリガー：「NIM Operator を使用して、Azure AKS 上に VDA 向けのレジリエントな Physical AI インフラストラクチャをセットアップしてください。」 期待される結果：このスキルを使用します。
• 否定的なトリガー：「このワークフロー ID の最近の OSMO ワークフローログを要約してください。」 期待される結果：依頼にインフラストラクチャスタックのセットアップ、スケーリング、検証、または復旧も含まれていない限り、このインフラストラクチャセットアップスキルは使用しません。

最新の静的レビュー：2026-05-26。説明のキーワードは、上記の想定ルートと一致しています。