NVIDIA abre o código do OSMO: um YAML orquestra treinamento, simulação e testes de robôs

Quem desenvolve robôs e sistemas de IA física não enfrenta um único problema de computação — enfrenta três. O modelo é treinado em clusters de GPUs como o GB200 ou H100, testado em simulação no Isaac Sim sobre GPUs RTX de estação de trabalho e, por fim, validado em um Jetson embarcado dentro do robô real. Cada camada tem seu próprio cluster, seu próprio agendador e seus próprios scripts de integração. É nessa fragmentação que o OSMO, recém-liberado em código aberto pela NVIDIA, ataca.

O problema dos três computadores

A NVIDIA descreve a IA física como um problema de três computadores. O treinamento acontece em GPUs de data center; a simulação de física e de sensores roda em hardware RTX de classe workstation; a implantação e os testes hardware-in-the-loop (HIL) acontecem em dispositivos de borda como o Jetson AGX Thor, geralmente no local da operação. Em vez de unificar, cada camada costuma ganhar ferramental próprio — e é nos pontos de transição entre elas que scripts personalizados se acumulam.

O OSMO trata os três como backends de um único plano de controle. Cada backend é um cluster Kubernetes registrado pela CLI. Os fluxos de trabalho não nomeiam um cluster: nomeiam uma plataforma — por exemplo, gb200, rtx-pro-6000 ou jetson-agx-thor — e o OSMO roteia a tarefa para o pool que oferece essa plataforma.

Um YAML, três camadas

O exemplo canônico do repositório encadeia três tarefas por dados:

• simulation: executa um contêiner do Isaac Sim em rtx-pro-6000;
• train-policy: roda um contêiner PyTorch no gb200 com 8 GPUs, consumindo a saída da simulação como entrada;
• evaluate-thor: roda uma aplicação ROS no jetson-agx-thor, consumindo a política treinada e gravando os resultados em um dataset nomeado.

Dependências vêm de entradas, persistência vem de saídas e posicionamento vem da plataforma. O guia cobre grupos de tarefas seriais e paralelos, templating Jinja para fluxos parametrizados, políticas de retry e prioridades HIGH/NORMAL/LOW com preempção e empréstimo de GPUs entre pools.

O que o OSMO entrega

• Portabilidade: o mesmo YAML roda em um notebook (Docker/KIND) ou em EKS, AKS, GKE, clusters on-premise ou air-gapped. A versão 6.3.0 trouxe um deploy-k8s.sh multi-provedor (Azure AKS, AWS EKS, microk8s) com integração de storage para MinIO, Azure Blob e AWS S3.
• Desenvolvimento interativo: sessões de VS Code, Jupyter ou SSH em GPU remota, execução em tarefas em andamento, port-forward e rsync nos dois sentidos.
• Agendamento: usa o NVIDIA KAI Scheduler por padrão. A versão 6.2.8 adicionou posicionamento ciente de topologia NVLink para tarefas multi-GPU; a 6.3.0 tornou exec_timeout e queue_timeout por grupo.
• Dados: datasets endereçáveis por conteúdo com deduplicação que, segundo o projeto, pode reduzir o armazenamento em 10 a 100 vezes.
• Segurança: RBAC via sidecar, integração OAuth2, TLS no gateway Envoy e identidade de workload em nuvem (Azure Workload Identity, AWS IRSA).
• Agentes: integração com Claude Code, OpenAI Codex e Cursor, além de suporte a MCP, para que agentes de código submetam e depurem pipelines.

Por que isso importa agora

O licenciamento é Apache-2.0, com Helm charts e contêineres publicados no NGC, e um quickstart local que sobe todo o plano de controle em uma estação de trabalho com KIND. A versão mais recente é a 6.3.1 (junho de 2026), já usada em projetos como GR00T, Isaac Lab, Isaac Sim e Isaac ROS, com integrações para Azure e Nebius.

Para o ecossistema brasileiro — forte em pesquisa em robótica, agronegócio e automação industrial — a relevância é direta: equipes menores ganham um caminho padronizado para levar um modelo do treinamento em nuvem até o teste em hardware real, sem reescrever a infraestrutura em cada etapa. É uma redução de fricção semelhante à que o Kubernetes trouxe para o backend tradicional, agora aplicada à robótica.

Pontos de atenção

Nem tudo são flores. A CLI autônoma do dataset (osmo dataset) e a API /datasets foram descontinuadas na 6.3.0 e devem ser removidas na 6.4 — quem depende delas precisa planejar a migração para datasets gerenciados por workflow. E, como em qualquer orquestrador novo, a promessa de “um YAML para tudo” ainda precisa ser validada em produção fora dos casos de referência da própria NVIDIA.