Physical AI Infrastructure Setup And Resilient Scaling
NVIDIAOfficialCreated by NVIDIA Physical AI
- Skill
- Workflow
- Cloud and DevOps
- Apache-2.0
- Medium risk
- Has scripts
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a comprehensive framework for deploying, scaling, and validating the infrastructure required for NVIDIA Physical AI synthetic data generation (SDG) workflows. It manages the lifecycle of Kubernetes clusters (MicroK8s or Azure AKS), OSMO orchestration, and inference backends (NIM Operator, NVCF, or Azure AI Foundry). The skill enforces strict preflight checks, reproducible configuration management, and systematic recovery procedures to ensure reliable workload execution.
What it does
- Provisions and configures Kubernetes clusters on MicroK8s or Azure AKS.
- Deploys and manages OSMO orchestration layers for workload submission.
- Sets up inference endpoints using NIM Operator, NVCF, or Azure AI Foundry.
- Executes mandatory preflight checks to validate infrastructure readiness.
- Provides structured recovery paths for failed workflow states or infrastructure issues.
- Ensures secure credential handling and environment-aware configuration.
When to use it
- When setting up a new Physical AI SDG environment from scratch.
- When scaling existing infrastructure to meet new workload demands.
- When validating the health and readiness of cluster, inference, or OSMO components.
- When troubleshooting and recovering from infrastructure or workflow deployment failures.
Advantages
- Standardizes infrastructure deployment across different cloud and local environments.
- Reduces configuration drift by using checked-in scripts and reproducible patterns.
- Improves reliability through mandatory preflight and verification gates.
- Provides a unified interface for complex multi-component stacks.
Usage examples
- “Set up resilient Physical AI infrastructure for VDA on Azure AKS with NIM Operator.”
- The agent will initiate the setup flow for Azure AKS, configure the necessary OSMO and NIM Operator components, run preflight checks, and prepare the environment for VDA workload submission.
- “My MicroK8s cluster for SDG is failing to schedule jobs; help me validate and recover.”
- The agent will guide you through the verification gates for the MicroK8s cluster, inspect OSMO pod status, check storage credentials, and identify the root cause of the scheduling failure.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/nvidia/physical-ai-infrastructure-setup-and-resilient-scaling/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip physical-ai-infrastructure-setup-and-resilient-scaling.zip -d .agents/skills
Documentation by NVIDIA Physical AI
Physical AI Infrastructure Setup And Resilient Scaling
Canonical skill for the Physical AI infrastructure stack. Use it to compose cluster, inference, OSMO, and workload stages into a reproducible Physical AI SDG environment, then keep the environment observable and recoverable.
Operating Rules
Read only the component references needed for the selected target. Do not load every component by default.
Keep the repo as the durable artifact. Fix checked-in config or scripts, then rerun. Do not recover a failed install with untracked one-off changes.
Run mutating cluster, OSMO, Helm, Terraform, or Azure operations through checked-in scripts when a script exists. Read-only diagnostics are allowed.
Stop at the first red gate. Fix the lowest owning layer in this order: config, script, then skill guidance.
Derive values from the environment when possible. Ask only for values that cannot be inferred, such as API keys, target choice, or quota tradeoffs.
Store secrets in
${REPO_ROOT}/.env. Cluster-derived values such as storage, database, Redis, and endpoint names come from Terraform outputs or platform queries, not.env.Preflight means no deployed state: no cluster API, Terraform outputs, Helm releases, OSMO pools, or workflow state. Those belong to deploy/verify gates.
Never print, echo, or paste raw keys into commands, YAML, logs, or transcripts. Prefer credential handles, Kubernetes
secretKeyRef, and runtime-only secret injection. Scan raw transcript exports withscripts/scan_transcript_secrets.pybefore sharing.Use absolute paths. Derive repo root with
git rev-parse --show-toplevel.
Component References
Each component lives inside this skill so the stack has one canonical trigger. Load the component reference only when the selected target needs that slice.
| Concern | Load | Assets |
|---|---|---|
| Stage matrix and old driver notes | components/driver/reference.md | None |
| MicroK8s cluster | components/cluster-microk8s/reference.md | components/cluster-microk8s/scripts/, components/cluster-microk8s/runtimeclass-nvidia-runc.yaml |
| Azure AKS cluster | components/cluster-azure/reference.md | components/cluster-azure/scripts/, components/cluster-azure/terraform/ |
| NIM Operator inference | components/inference-nim-operator/reference.md | components/inference-nim-operator/scripts/, components/inference-nim-operator/nims/ |
| NVCF inference | components/inference-nvcf/reference.md | components/inference-nvcf/scripts/ |
| Azure AI Foundry inference | components/inference-azure/reference.md | components/inference-azure/scripts/ |
| MicroK8s OSMO | components/osmo-k8s/reference.md | components/osmo-k8s/scripts/, upstream OSMO deploy scripts |
| Azure OSMO | components/osmo-azure/reference.md | components/osmo-azure/scripts/, upstream OSMO deploy scripts plus Azure TF outputs |
| Azure access setup | components/azure-access/reference.md | None |
| OSMO CLI and workflow operations | components/osmo-cli/reference.md | components/osmo-cli/scripts/, components/osmo-cli/references/, components/osmo-cli/agents/, components/osmo-cli/tests/ |
| OpenClaw Azure device login | components/openclaw-azure-login/reference.md | None |
OSMO CLI Support Files
The OSMO CLI component has second-level support files because its command and workflow surface is large. Load these directly only for the stated case.
| File | Read when |
|---|---|
components/osmo-cli/agents/workflow-expert.md | Spawning a workflow-generation or workflow-failure subagent. |
components/osmo-cli/agents/logs-reader.md | Spawning a log summarization subagent for OSMO workflow failures. |
components/osmo-cli/references/cli-commands.md | Exact OSMO CLI flags, payloads, or command syntax are needed. |
components/osmo-cli/references/workflow-spec.md | Workflow YAML schema, credentials, outputs, or provider fields are needed. |
components/osmo-cli/references/workflow-patterns.md | Multi-task, data dependency, Jinja, serial, or parallel workflow design is needed. |
components/osmo-cli/references/advanced-patterns.md | Checkpointing, retry/exit behavior, or node exclusion is needed. |
components/osmo-cli/tests/orchestrator-runtime-failure.md | Validating or debugging the OSMO orchestration review pattern. |
Target Selection
Pick exactly one option per stage. Stage 2 follows stage 1.
Kubernetes:
MicroK8sorAzureOSMO:
MicroK8s OSMOwhen Kubernetes is MicroK8s,Azure OSMOwhen Kubernetes is AzureInference:
NIM Operator,NVCF,Azure AI Foundry, orNoneWorkload: Video Data Augmentation, Defect Image Generation, NuRec Carline Adaptation, NRE, NCore, Asset Harvester, or custom workflow YAML
Reject invalid combinations before provisioning:
| Cluster | NIM Operator | NVCF | Azure AI Foundry |
|---|---|---|---|
| MicroK8s | yes | yes | no, Foundry requires Azure identities |
| Azure | yes | yes | yes |
For OpenClaw or any chat-only environment that cannot open a browser, read
components/openclaw-azure-login/reference.md before Azure prerequisites.
For any Azure target, read components/azure-access/reference.md before Azure
component preflights.
Setup Flow
Confirm target choices and workload compute requirements.
Load the selected component references.
Resolve prerequisites up front, including API keys, Azure access, caller CIDR, GPU quota, storage class, and OSMO login requirements.
Run
scripts/preflight.shfor every selected infrastructure component plus any OSMO CLI/workload preflight before provisioning; build the implementation plan from the results and stop on red preflight.Deploy Kubernetes first. Nothing else starts until the cluster gate is green.
Deploy OSMO and inference after Kubernetes. These can proceed in parallel once the cluster exists, but workload submission waits for both selected gates.
Submit the workload only after OSMO, storage credentials, compute pool, and selected inference endpoints are verified. For VDA, this includes
preflight_credentials.sh,pre_submit_guard.pywith resolved--setvalues, non-empty model-cache prefixes, and workflow-namespace endpoint smoke checks.Monitor through completion. On failed workflow state, inspect events and logs from
components/osmo-cli/reference.md; do not resubmit blindly.
Inference Discovery
Avoid over-deploying expensive endpoints.
Scan the chosen workflow spec and default values for endpoint references:
*.osmo-nims.svc.cluster.local,api.nvcf.nvidia.com/*,*.inference.ai.azure.com, or*.cognitiveservices.azure.com.Map each reference to the selected backend:
NIM Operator: service name must match a directory under
components/inference-nim-operator/nims/.NVCF: function URL or function ID must be supplied by the environment.
Azure AI Foundry: endpoint name must be deployed through
components/inference-azure/scripts/install.sh.
If the workflow needs a capability the selected backend lacks, stop and report the mismatch. Do not silently substitute another model.
Verification Gates
Each stage has its own Verify section in the component reference. These gates are mandatory:
| Stage | Gate |
|---|---|
| Kubernetes | Cluster API reachable, nodes Ready, GPU capacity advertised for GPU paths, and CPU+NVCF paths have runtimeclass/nvidia mapped to runc. |
| Inference | Every endpoint referenced by the workload is reachable. NIM readiness uses /v1/health/ready; NVCF and Foundry still need task-specific authenticated checks. |
| OSMO | OSMO pods Ready, pool ONLINE, port-forward watchdogs alive, storage credentials configured, and verify-hello workflow COMPLETED. |
| Workload | Selected workload pre-submit guards pass before submit. osmo workflow query <id> reports COMPLETED and every task is green. Failed terminal states require events and logs before retry. |
Resilient Scaling
Size the cluster from workload needs before provisioning. For Azure, check CPU and GPU quota for the selected VM families before
terraform apply.For NIM Operator, deploy only the NIMServices referenced by the workload. Each service pins GPU and model-cache storage for the lifetime of the cluster.
Keep OSMO storage URL schemes aligned with the active backend. Local MicroK8s uses MinIO, Azure uses Blob-backed configuration.
Treat Pending, Unknown, ImagePullBackOff, unbound PVCs, or 0 Ready replicas as layer failures. Investigate scheduling, storage, image credentials, and adjacent platform state before retrying the same command.
For long deploys or workflow watches, provide heartbeat updates with current state, elapsed time, last useful observation, and next check.
Workload Routing
Video Data Augmentation: use
skills/physical-ai-video-data-augmentation/SKILL.md.Defect Image Generation: use
skills/physical-ai-defect-image-generation/SKILL.md.NuRec carline adaptation: use
skills/carline-adaptation/SKILL.md.NRE, NCore, and Asset Harvester live in the canonical NuRec catalog listed in
skills/INDEX.md.Custom workload: submit the provided workflow YAML through OSMO after checking resource requests, image credentials, data credentials, and inference URLs.
Evaluation Prompts And Results
Positive trigger: "Set up resilient Physical AI infrastructure for VDA on Azure AKS with NIM Operator." Expected: use this skill.
Negative trigger: "Summarize recent OSMO workflow logs for this workflow ID." Expected: do not use this infrastructure setup skill unless the request also involves setup, scaling, validation, or recovery of the infrastructure stack.
Latest static review: 2026-05-26, description keywords match the expected routes above.
Files
- ATTRIBUTION.mdAdded by AutoGineer1.0 KiB
- BENCHMARK.md6.3 KiB
- LICENSELicence file added by AutoGineer11.2 KiB
- SKILL.md10.9 KiB
- components/azure-access/reference.md3.0 KiB
- components/cluster-azure/.gitignore103 B
- components/cluster-azure/reference.md5.9 KiB
- components/cluster-azure/scripts/helmfile.yaml354 B
- components/cluster-azure/scripts/main.tf25.4 KiB
- components/cluster-azure/scripts/outputs.tf1.6 KiB
- components/cluster-azure/scripts/preflight.shScript7.9 KiB
- components/cluster-azure/scripts/setup.shScript4.1 KiB
- components/cluster-azure/scripts/storage-class-nfs.yaml2.3 KiB
- components/cluster-azure/scripts/system_node_capacity_test.shScript915 B
- components/cluster-azure/scripts/terraform.tfvars.example568 B
- components/cluster-azure/scripts/variables.tf2.6 KiB
- components/cluster-azure/scripts/versions.tf588 B
- components/cluster-azure/terraform/main.tf8.0 KiB
- components/cluster-azure/terraform/modules/README.md705 B
- components/cluster-azure/terraform/outputs.tf3.9 KiB
- components/cluster-azure/terraform/prerequisites/az-sub-init.shScript2.2 KiB
- components/cluster-azure/terraform/prerequisites/install-terraform.shScript1.8 KiB
- components/cluster-azure/terraform/prerequisites/register-azure-providers.shScript6.8 KiB
- components/cluster-azure/terraform/prerequisites/robotics-azure-resource-providers.txt336 B
- components/cluster-azure/terraform/terraform.tfvars.example7.6 KiB
- components/cluster-azure/terraform/variables.tf9.1 KiB
- components/cluster-azure/terraform/versions.tf779 B
- components/cluster-microk8s/reference.md1.8 KiB
- components/cluster-microk8s/runtimeclass-nvidia-runc.yaml223 B
- components/cluster-microk8s/scripts/preflight.shScript4.5 KiB
- components/driver/reference.md8.6 KiB
- components/inference-azure/reference.md2.6 KiB
- components/inference-azure/scripts/install.shScript5.9 KiB
- components/inference-azure/scripts/preflight.shScript5.5 KiB
- components/inference-nim-operator/nims/cosmos-predict/nimservice.yaml2.4 KiB
- components/inference-nim-operator/nims/cosmos-reason/nimservice.yaml1.1 KiB
- components/inference-nim-operator/nims/cosmos-transfer/nimservice.yaml1.1 KiB
- components/inference-nim-operator/nims/qwen-image-edit-nvpcb-ovsl2sl/nimservice.yaml2.5 KiB
- components/inference-nim-operator/nims/qwen-image-edit/nimservice.yaml1.2 KiB
- components/inference-nim-operator/nims/qwen25-14b/hf-download-job.yaml2.0 KiB
- components/inference-nim-operator/nims/qwen25-14b/nimservice.yaml1.9 KiB
- components/inference-nim-operator/nims/qwen25-14b/pvc.yaml892 B
- components/inference-nim-operator/nims/qwen3-235b/hf-download-job.yaml1.7 KiB
- components/inference-nim-operator/nims/qwen3-235b/nimservice.yaml1.7 KiB
- components/inference-nim-operator/nims/qwen3-235b/pvc.yaml704 B
- components/inference-nim-operator/nims/qwen3-vl/hf-download-job.yaml2.6 KiB
- components/inference-nim-operator/nims/qwen3-vl/nimservice.yaml4.7 KiB
- components/inference-nim-operator/nims/qwen3-vl/pvc.yaml964 B
- components/inference-nim-operator/reference.md5.5 KiB
- components/inference-nim-operator/scripts/install.shScript11.8 KiB
- components/inference-nim-operator/scripts/preflight.shScript3.0 KiB
- components/inference-nvcf/reference.md3.2 KiB
- components/inference-nvcf/scripts/preflight.shScript2.7 KiB
- components/openclaw-azure-login/reference.md2.8 KiB
- components/osmo-azure/reference.md4.4 KiB
- components/osmo-azure/scripts/preflight.shScript5.9 KiB
- components/osmo-cli/agents/logs-reader.md3.5 KiB
- components/osmo-cli/agents/workflow-expert.md4.0 KiB
- components/osmo-cli/reference.md42.1 KiB
- components/osmo-cli/references/advanced-patterns.md2.4 KiB
- components/osmo-cli/references/cli-commands.md14.6 KiB
- components/osmo-cli/references/workflow-patterns.md8.0 KiB
- components/osmo-cli/references/workflow-spec.md8.5 KiB
- components/osmo-cli/scripts/preflight.shScript2.4 KiB
- components/osmo-cli/tests/orchestrator-runtime-failure.md11.0 KiB
- components/osmo-k8s/reference.md2.5 KiB
- components/osmo-k8s/scripts/preflight.shScript2.8 KiB
- evals/evals.json2.9 KiB
- skill-card.md3.4 KiB
- skill.oms.sig21.3 KiB
components/osmo-cli/agents/workflow-expert.md
OSMO Workflow Expert Agent
Spawn a subagent with access to the OSMO CLI component reference and pass these instructions as the prompt. This agent handles workflow creation, resource checking, submission, and failure diagnosis — then RETURNS the workflow ID. It does NOT monitor workflows. The calling agent handles monitoring inline.
You are a workflow specialist for the OSMO platform. You handle the heavy lifting — workflow generation, resource selection, submission, and failure diagnosis — then return control so the calling agent can monitor inline with live status updates visible to the user.
Read components/osmo-cli/reference.md and its support files for all CLI
procedures. Use those procedures directly; do not reinvent them.
Mode 1: Setup and Submit (default)
Execute these steps using the osmo skill procedures:
Resource Check — Follow the "Check Available Resources" use case. Pick the pool with the best GPU match for the user's needs.
Workflow Generation — If
workflow.yamlalready exists and the user referenced it, submit it as-is. Do NOT modify the YAML — no adding/removing tasks, renaming tasks, changing resource values, or altering the script contents. If you spot an obvious issue (e.g. wrong template variable), flag it in your return message but still submit the original unchanged. Otherwise, follow the "Generate and Submit a Workflow" use case to create one.Submit — Follow the submission steps from the skill. Skip user confirmation if pre-authorized. On validation errors, auto-adjust resources per the skill's sizing rules and resubmit.
Return — After successful submission, return a structured response:
Workflow ID and pool name
OSMO Web link: <workflow overview link>
Output URLs/datasets the workflow will produce (from YAML
outputs)
Do NOT poll or monitor the workflow. Return immediately after submission.
Mode 2: Diagnose and Fix (via resume)
When resumed with a failure context (workflow ID + status):
Analyze logs — Analyze the logs summary that is provided to you first. If the summary is not informational enough for root-cause analysis, fetch more detailed logs with
osmo workflow logs <workflow_id> -n 200. Note: for multi-task workflows, the calling agent should delegate log fetching to logs-reader subagents before resuming you — request this if the logs summary is insufficient.Root-cause analysis — Identify the failure (OOM/exit 137, script error, image pull failure, NCCL timeout, template variable errors, etc.)
Proactive review — When fixing a script error, review the ENTIRE script for other potential issues that would cause a runtime failure — not just the line that failed. Fix all such issues in a single pass to minimize retry cycles. Limit fixes to things that would break execution (missing commands, wrong template variables, syntax errors, bad paths). Do NOT change resource values (CPU, GPU, memory), task structure, or make optimizations the user did not ask for.
Explain the fix — State what failed, what you changed, and any other issues you caught proactively. Use plain language.
Resubmit — Submit to the same pool.
Return — Provide the new workflow ID (same format as Mode 1 step 4), plus a summary of what was fixed.
Track retries across resume invocations. After 3 failures, ask the user.
Guidelines
Use plain language — no Kubernetes jargon.
Run commands yourself — do not tell the user to run them.
When in doubt about user intent, ask before submitting.
Learnings to Report
After each successful workflow cycle (submit or diagnose+fix), include these observations in your return message so the calling agent can track them:
Pool performance: Which pool was used, queue time, any reliability issues
Error patterns: Failures seen and the fixes that resolved them
Resource sizing: GPU/CPU/memory/storage values that worked for the workload
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs an API key, Needs Node.js
The author says: Requires the selected component prerequisites, usually kubectl plus either MicroK8s or Azure CLI/Terraform, and OSMO or inference credentials for the chosen target.
Security
What our scanner noticed· Medium risk
- Large base64-encoded blobs
- Instructions that use the network
- Scripts that your agent may run
This skill includes scripts that your agent may run. Read them before you use it.
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- NVIDIA Physical AI
- Publisher
- NVIDIA (Official)
- Source
- NVIDIA/skills · skills/physical-ai-infrastructure-setup-and-resilient-scaling · commit fce3cca
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE-APACHE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Also distributed in
- openai/plugins
AutoGineer is not affiliated with or endorsed by NVIDIA Physical AI or NVIDIA.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download physical-ai-infrastructure-setup-and-resilient-scaling.zip