NVIDIA开源OSMO：单YAML统一调度物理AI全栈流程

破解物理AI的‘三机问题’

NVIDIA将物理AI开发概括为典型的‘三机问题’：策略训练依赖数据中心级GPU（如GB200或H100集群），物理仿真与传感器渲染运行在RTX工作站级GPU上，而硬件在环（HIL）测试与部署则发生在Jetson AGX Thor等边缘设备中。传统方案中，每个层级拥有独立集群、独立调度器和大量定制胶水脚本，导致流程割裂、迁移成本高。OSMO的核心理念是将这三层抽象为同一控制平面下的不同后端——所有Kubernetes集群通过CLI注册，工作流不指定具体集群，而仅声明所需平台类型（如`gb200`、`rtx-pro-6000`或`jetson-agx-thor`），由OSMO自动路由至匹配资源池。

单YAML驱动全栈流水线

OSMO的典型工作流由三个数据链式任务构成：`simulation`在`rtx-pro-6000`上运行Isaac Sim容器；`train-policy`在`gb200`集群（8卡）上运行PyTorch训练任务，以仿真输出为输入；`evaluate-thor`则在`jetson-agx-thor`上执行ROS应用，加载训练所得策略并写入命名数据集。任务依赖由输入定义，持久化由输出保障，资源放置由平台标签驱动。用户指南涵盖串行/并行任务组、Jinja参数化模板、重试策略，以及支持抢占与跨池GPU借用的HIGH/NORMAL/LOW三级优先级调度。

关键能力全面覆盖开发与生产需求

可移植性：同一份YAML可在本地Docker/KIND环境、EKS/AKS/GKE公有云、私有集群乃至气隙环境中运行；6.3.0版新增`deploy-k8s.sh`脚本，支持一键部署至Azure AKS、AWS EKS、microk8s等任意现有集群，并适配MinIO、Azure Blob、AWS S3等多种存储后端。交互式开发：支持远程GPU节点启动VS Code、Jupyter或SSH会话，实时exec进入运行中任务、端口转发及双向rsync文件同步；6.3.0起新增带进度条的`osmo workflow rsync download`命令。智能调度：默认集成NVIDIA KAI Scheduler；6.2.8版引入NVLink拓扑感知的多卡任务放置；6.3.0版将`exec_timeout`与`queue_timeout`细化至任务组粒度，避免仿真卡顿阻塞训练任务。数据管理：采用内容寻址数据集，宣称可减少存储占用10–100倍；但需注意：独立`osmo dataset` CLI及`/datasets` API已在6.3.0中弃用，计划于6.4版移除，后续统一由工作流管理的数据集输出替代。安全与身份：自6.2.8起内置RBAC授权边车、OAuth2代理（支持设备码登录）及身份提供商用户映射；6.3.0新增Envoy网关TLS终止及云原生工作负载身份（Azure Workload Identity、AWS IRSA/Pod Identity），服务不再以Kubernetes Secret挂载存储密钥；6.3.1进一步收紧默认`osmo-user`角色权限至默认资源池。智能体集成：项目仓库提供`AGENTS.md`文档、技能目录及MCP部署指南；NVIDIA在GTC 2026宣布OSMO已支持Claude Code、OpenAI Codex与Cursor等编码智能体，使其可直接提交、监控与调试整条流水线。

已经落地验证，面向规模化生产

OSMO已在NVIDIA GR00T大模型训练框架、Isaac Lab、Isaac Sim与Isaac ROS等核心物理AI项目中实战验证，并完成与Azure及Nebius云平台的集成。当前最新稳定版为6.3.1（发布于2026年6月），提供GitHub源码、完整文档、发布日志、实战菜谱及官网专属页面。

> 编者观点：OSMO并非通用AI工作流工具，而是直击机器人与具身智能研发中基础设施碎片化的痛点。对中国AI硬件厂商与机器人初创公司而言，其Kubernetes原生架构与多云/边缘兼容性，意味着可快速构建自主可控的物理AI研发中台，降低对单一云厂商或闭源调度系统的依赖。