| 名称 | physical-ai-infrastructure-setup-and-resilient-scaling |
| 描述 | >- 当用户想要为本地 MicroK8s 或 Azure AKS 上的合成数据生成工作流设置、扩展、验证或加固 NVIDIA 物理 AI 基础设施时使用，包括 Kubernetes 集群、推理端点部署、OSMO 部署、工作负载提交就绪和基础设施故障恢复。触发关键词：physical ai infrastructure、resilient scaling、SDG infrastructure、microk8s、azure aks、NVCF deployment、NIM Operator、OSMO deploy、workflow scaling。不要触发：OSMO 日志摘要或仅执行工作负载操作，除非请求了基础设施设置、扩展、验证或恢复。 |
| 开源协议 | Apache-2.0 |
| 版本 | “1.0.0” tools: - Read - Shell compatibility: >- 需要所选组件的前置条件，通常为 kubectl 加上 MicroK8s 或 Azure CLI/Terraform，以及所选目标的 OSMO 或推理凭据。 metadata: |
| 作者 | NVIDIA Physical AI tags: - physical-ai - infrastructure - kubernetes - azure - microk8s - osmo - nim-operator - scaling domain: ai-ml languages: - bash - hcl - yaml |
物理AI基础设施搭建与弹性扩展
这是物理 AI 基础设施栈的规范技能。使用它可将集群、推理、OSMO 和工作负载阶段组合成可复现的物理 AI SDG 环境，并保持环境可观测、可恢复。
操作规则
- 仅读取所选目标需要的组件参考。默认不要加载每个组件。
- 将仓库作为持久化工件。修复已入库的配置或脚本，然后重新运行。不要通过未跟踪的一次性更改来恢复失败的安装。
- 当存在脚本时，通过已入库的脚本执行会改变集群、OSMO、Helm、Terraform 或 Azure 的操作。允许只读诊断。
- 在第一个红色门禁处停止。按此顺序修复最低的归属层：配置、脚本，然后技能指引。
- 尽可能从环境中获取值。只询问无法推断的值，例如 API 密钥、目标选择或配额权衡。
- 将密钥存储在
${REPO_ROOT}/.env中。从集群派生的值如存储、数据库、Redis 和端点名称来自 Terraform 输出或平台查询，而不是.env。 - 预检意味着无已部署状态：没有集群 API、Terraform 输出、Helm 发布、OSMO 池或工作流状态。这些都归属于部署/验证门禁。
- 切勿将原始密钥打印、回显或粘贴到命令、YAML、日志或转录中。优先使用凭据句柄、Kubernetes
secretKeyRef和仅运行时密钥注入。在共享前使用scripts/scan_transcript_secrets.py扫描原始转录导出。 - 使用绝对路径。使用
git rev-parse --show-toplevel获取仓库根目录。
组件参考
每个组件都位于此技能内部，使整个栈拥有一个规范触发点。仅当所选目标需要该部分时才加载对应组件参考。
| 关注点 | 加载 | 资产 |
|---|---|---|
| 阶段矩阵与旧驱动说明 | 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/, upstream OSMO 部署脚本 |
| Azure OSMO | components/osmo-azure/reference.md |
components/osmo-azure/scripts/, upstream 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 组件有二级支持文件，因为其命令和工作流涉及面较大。仅在明确的情况下直接加载。
| 文件 | 何时读取 |
|---|---|
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 schema、凭据、输出或提供程序字段时。 |
components/osmo-cli/references/workflow-patterns.md |
需要多任务、数据依赖、Jinja、串行或并行工作流设计时。 |
components/osmo-cli/references/advanced-patterns.md |
需要检查点、重试/退出行为或节点排除时。 |
components/osmo-cli/tests/orchestrator-runtime-failure.md |
验证或调试 OSMO 编排审查模式时。 |
目标选择
每个阶段恰好选择一个选项。阶段 2 跟随阶段 1。
- Kubernetes：
MicroK8s或Azure - OSMO：当 Kubernetes 为 MicroK8s 时使用
MicroK8s OSMO，当 Kubernetes 为 Azure 时使用Azure OSMO - 推理：
NIM Operator、NVCF、Azure AI Foundry或None - 工作负载：视频数据增强、缺陷图像生成、NuRec 产线适配、NRE、NCore、资产收割器或自定义工作流 YAML
在配置之前拒绝无效组合：
| 集群 | NIM Operator | NVCF | Azure AI Foundry |
|---|---|---|---|
| MicroK8s | 是 | 是 | 否，Foundry 需要 Azure 身份 |
| Azure | 是 | 是 | 是 |
对于 OpenClaw 或任何无法打开浏览器的纯聊天环境，请在处理 Azure 前置条件前阅读 components/openclaw-azure-login/reference.md。对于任何 Azure 目标，请在 Azure 组件预检前阅读 components/azure-access/reference.md。
设置流程
- 确认目标选择和工作负载计算需求。
- 加载所选组件参考。
- 预先解决前置条件，包括 API 密钥、Azure 访问、调用方 CIDR、GPU 配额、存储类和 OSMO 登录要求。
- 在配置前为每个选定的基础设施组件以及任何 OSMO CLI/工作负载预检运行
scripts/preflight.sh；根据结果制定实施计划，并在预检红时停止。 - 首先部署 Kubernetes。在集群门禁变绿之前，不启动其他任何操作。
- Kubernetes 之后部署 OSMO 和推理。一旦集群存在，这两者可以并行推进，但工作负载提交需等待两个选定门禁都通过。
- 仅在 OSMO、存储凭据、计算池和所选推理端点均验证后方可提交工作负载。对于 VDA，这包括
preflight_credentials.sh、带有已解析--set值的pre_submit_guard.py、非空的模型缓存前缀以及工作流命名空间端点冒烟检查。 - 持续监控直至完成。当工作流状态失败时，从
components/osmo-cli/reference.md检查事件和日志；不要盲目重新提交。
推理发现
避免过度部署昂贵的端点。
- 扫描所选工作流规范和默认值中的端点引用：
*.osmo-nims.svc.cluster.local、api.nvcf.nvidia.com/*、*.inference.ai.azure.com或*.cognitiveservices.azure.com。 - 将每个引用映射到选定的后端：
- NIM Operator：服务名称必须与
components/inference-nim-operator/nims/下的目录匹配。 - NVCF：函数 URL 或函数 ID 必须由环境提供。
- Azure AI Foundry：端点名称必须通过
components/inference-azure/scripts/install.sh部署。
- NIM Operator：服务名称必须与
- 如果工作流需要所选后端缺乏的能力，请停止并报告不匹配。不要静默替代其他模型。
验证门禁
每个阶段在组件参考中都有自己的“验证”章节。这些门禁是强制性的：
| 阶段 | 门禁 |
|---|---|
| Kubernetes | 集群 API 可访问，节点处于 Ready 状态，GPU 路径通告 GPU 容量，CPU+NVCF 路径已将 runtimeclass/nvidia 映射到 runc。 |
| 推理 | 工作负载引用的每个端点均可访问。NIM 就绪检查使用 /v1/health/ready；NVCF 和 Foundry 仍需要特定任务的认证检查。 |
| OSMO | OSMO Pod 处于 Ready，池 ONLINE，端口转发看门狗存活，存储凭据已配置，verify-hello 工作流已完成。 |
| 工作负载 | 所选工作负载在提交前通过预提交守卫。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 或 0 个 Ready 副本视为层故障。在重试同一命令之前，调查调度、存储、镜像凭据和相邻平台状态。
- 对于长时间部署或工作流监视，提供心跳更新，包括当前状态、已用时间、最后一次有效观察和下次检查。
工作负载路由
- 视频数据增强：使用
skills/physical-ai-video-data-augmentation/SKILL.md。 - 缺陷图像生成：使用
skills/physical-ai-defect-image-generation/SKILL.md。 - NuRec 产线适配：使用
skills/carline-adaptation/SKILL.md。 - NRE、NCore 和资产收割器位于
skills/INDEX.md列出的规范 NuRec 目录中。 - 自定义工作负载：在检查资源请求、镜像凭据、数据凭据和推理 URL 后，通过 OSMO 提交提供的工作流 YAML。
评估提示与结果
- 正面触发：“在 Azure AKS 上使用 NIM Operator 为 VDA 设置弹性物理 AI 基础设施。”预期：使用此技能。
- 负面触发：“为此工作流 ID 汇总最近的 OSMO 工作流日志。”预期：不使用此基础设施设置技能，除非请求还涉及基础设施栈的设置、扩展、验证或恢复。
最新静态审查：2026-05-26，描述关键词与上述预期路径匹配。