Configuration et mise à l'échelle résiliente de l'infrastructure Physical AI

Skill canonical pour la pile d'infrastructure Physical AI. Utilisez-la pour composer les étapes cluster, inference, OSMO et workload dans un environnement Physical AI SDG reproductible, puis maintenez l'environnement observable et récupérable.

Règles d'exploitation

• Lisez uniquement les références de composant nécessaires pour la cible sélectionnée. Ne chargez pas tous les composants par défaut.
• Conservez le repo comme artefact durable. Corrigez la configuration ou les scripts validés, puis réexécutez. Ne récupérez pas une installation échouée avec des modifications ponctuelles non suivies.
• Exécutez les opérations mutantes cluster, OSMO, Helm, Terraform ou Azure via des scripts validés lorsqu'un script existe. Les diagnostics en lecture seule sont autorisés.
• Arrêtez-vous au premier portail rouge. Corrigez la couche propriétaire la plus basse dans cet ordre : config, script, puis guidance de skill.
• Dérivez les valeurs de l'environnement quand c'est possible. Demandez uniquement les valeurs qui ne peuvent pas être déduites, comme les clés API, le choix de cible ou les compromis de quota.
• Stockez les secrets dans ${REPO_ROOT}/.env. Les valeurs dérivées du cluster comme le stockage, la base de données, Redis et les noms de points de terminaison proviennent des sorties Terraform ou des requêtes de plateforme, pas de .env.
• Preflight signifie pas d'état déployé : pas d'API cluster, sorties Terraform, releases Helm, pools OSMO ou état de workflow. Ceux-ci appartiennent aux portails deploy/verify.
• Ne jamais afficher, afficher ou coller les clés brutes dans les commandes, YAML, logs ou transcriptions. Préférez les handles d'informations d'identification, les secretKeyRef Kubernetes et l'injection de secrets au moment de l'exécution. Scannez les exports de transcription bruts avec scripts/scan_transcript_secrets.py avant de partager.
• Utilisez des chemins absolus. Dérivez la racine du repo avec git rev-parse --show-toplevel.

Références de composant

Chaque composant réside dans cette skill pour que la pile ait un seul déclencheur canonical. Chargez la référence de composant uniquement quand la cible sélectionnée a besoin de cette tranche.

Fichiers de support OSMO CLI

Le composant OSMO CLI a des fichiers de support de deuxième niveau car sa surface de commande et de workflow est vaste. Chargez-les directement uniquement pour le cas indiqué.

Sélection de cible

Choisissez exactement une option par stage. Le stage 2 suit le stage 1.

1. Kubernetes : MicroK8s ou Azure
2. OSMO : MicroK8s OSMO quand Kubernetes est MicroK8s, Azure OSMO quand Kubernetes est Azure
3. Inference : NIM Operator, NVCF, Azure AI Foundry ou None
4. Workload : Video Data Augmentation, Defect Image Generation, NuRec Carline Adaptation, NRE, NCore, Asset Harvester ou workflow YAML personnalisé

Rejetez les combinaisons invalides avant le provisionnement :

Pour OpenClaw ou tout environnement chat uniquement qui ne peut pas ouvrir un navigateur, lisez components/openclaw-azure-login/reference.md avant les prérequis Azure. Pour toute cible Azure, lisez components/azure-access/reference.md avant les preflights de composant Azure.

Flux de configuration

1. Confirmez les choix de cible et les exigences de calcul de workload.
2. Chargez les références de composant sélectionnées.
3. Résolvez les prérequis à l'avance, y compris les clés API, l'accès Azure, le CIDR de l'appelant, la quota GPU, la classe de stockage et les exigences de connexion OSMO.
4. Exécutez scripts/preflight.sh pour chaque composant d'infrastructure sélectionné plus tout preflight CLI/workload OSMO avant le provisionnement ; construisez le plan de mise en œuvre à partir des résultats et arrêtez-vous sur le preflight rouge.
5. Déployez Kubernetes en premier. Rien d'autre ne démarre jusqu'au portail cluster vert.
6. Déployez OSMO et inference après Kubernetes. Ceux-ci peuvent procéder en parallèle une fois le cluster existant, mais la soumission de workload attend les deux portails sélectionnés.
7. Soumettez le workload uniquement après la vérification d'OSMO, des informations d'identification de stockage, du pool de calcul et des points de terminaison d'inference sélectionnés. Pour VDA, cela inclut preflight_credentials.sh, pre_submit_guard.py avec des valeurs --set résolues, des préfixes de cache de modèle non vides et des tests de fumée de points de terminaison de namespace de workflow.
8. Surveillez jusqu'à la fin. En cas d'état de workflow échoué, inspectez les événements et les logs de components/osmo-cli/reference.md ; ne soumettez pas à nouveau à l'aveugle.

Découverte d'inference

Évitez le sur-déploiement de points de terminaison coûteux.

1. Scannez la spec de workflow choisie et les valeurs par défaut pour les références de points de terminaison : *.osmo-nims.svc.cluster.local, api.nvcf.nvidia.com/*, *.inference.ai.azure.com ou *.cognitiveservices.azure.com.
2. Mappez chaque référence au backend sélectionné :
   • NIM Operator : le nom du service doit correspondre à un répertoire sous components/inference-nim-operator/nims/.
   • NVCF : l'URL de fonction ou l'ID de fonction doit être fourni par l'environnement.
   • Azure AI Foundry : le nom du point de terminaison doit être déployé via components/inference-azure/scripts/install.sh.
3. Si le workflow a besoin d'une capacité que le backend sélectionné n'a pas, arrêtez et rapportez la non-correspondance. Ne substituez pas silencieusement un autre modèle.

Portails de vérification

Chaque stage a sa propre section Verify dans la référence du composant. Ces portails sont obligatoires :

Mise à l'échelle résiliente

• Dimensionnez le cluster à partir des besoins de workload avant le provisionnement. Pour Azure, vérifiez la quota CPU et GPU pour les familles VM sélectionnées avant terraform apply.
• Pour NIM Operator, déployez uniquement les NIMServices référencés par le workload. Chaque service épingle GPU et stockage de cache de modèle pour la durée de vie du cluster.
• Maintenez les schémas d'URL de stockage OSMO alignés avec le backend actif. MicroK8s local utilise MinIO, Azure utilise une configuration sauvegardée par Blob.
• Traitez Pending, Unknown, ImagePullBackOff, PVCs non liés ou 0 Ready replicas comme des échecs de couche. Enquêtez sur la planification, le stockage, les informations d'identification d'image et l'état de plateforme adjacent avant de réessayer la même commande.
• Pour les déploiements longs ou les watches de workflow, fournissez des mises à jour de battement cardiaque avec l'état actuel, le temps écoulé, la dernière observation utile et la prochaine vérification.

Routage de workload

• Video Data Augmentation : utilisez skills/physical-ai-video-data-augmentation/SKILL.md.
• Defect Image Generation : utilisez skills/physical-ai-defect-image-generation/SKILL.md.
• Adaptation carline NuRec : utilisez skills/carline-adaptation/SKILL.md.
• NRE, NCore et Asset Harvester vivent dans le catalogue NuRec canonical listée dans skills/INDEX.md.
• Workload personnalisé : soumettez le workflow YAML fourni via OSMO après vérification des demandes de ressources, des informations d'identification d'image, des informations d'identification de données et des URL d'inference.

Prompts d'évaluation et résultats

• Déclencheur positif : « Configurer une infrastructure Physical AI résiliente pour VDA sur Azure AKS avec NIM Operator. » Attendu : utilisez cette skill.
• Déclencheur négatif : « Résumer les logs de workflow OSMO récents pour cet ID de workflow. » Attendu : n'utilisez pas cette skill de configuration d'infrastructure sauf si la demande implique également la configuration, la mise à l'échelle, la validation ou la récupération de la pile d'infrastructure.

Dernière revue statique : 2026-05-26, les mots clés de description correspondent aux routes attendues ci-dessus.