NVIDIA rilascia OSMO: un YAML per orchestrare training, simulazione e test robotici

Cosa è accaduto

NVIDIA ha pubblicato come open source il progetto OSMO, un workflow orchestrator Kubernetes-native pensato per il cosiddetto "three computer problem" della robotica: training su GPU per data center, simulazione su workstation con RTX e validazione HIL su dispositivi Jetson. OSMO permette a un team di descrivere l'intera pipeline — simulazione, addestramento e testing su robot reali — in un unico file YAML e di eseguirla su backend eterogenei senza modificare lo script infrastrutturale.

Perché è importante

La frammentazione degli stack di calcolo è un ostacolo pratico per lo sviluppo di modelli robotici: ogni tier spesso richiede cluster, scheduler e script distinti. OSMO affronta questa complessità trattando ciascun tier come un backend registrato nel piano di controllo; i workflow non nominano cluster specifici ma piattaforme (ad esempio gb200, rtx-pro-6000, jetson-agx-thor) e il controllo distribuisce i task su pool che offrono quelle piattaforme.

Il progetto è rilasciato con licenza Apache-2.0, fornisce Helm chart e container su NGC e include un quickstart locale (KIND) che consente di avviare l'intero control plane su una workstation. Le release 6.3.x citate nella fonte introducono integrazioni operative e di sicurezza che mirano a rendere OSMO immediatamente distribuibile in ambienti reali.

Possibili impatti

Per team di ricerca e sviluppo robotico, OSMO può ridurre il tempo speso a mantenere script di integrazione tra diversi ambienti di esecuzione: la stessa definizione YAML può essere usata su laptop di sviluppo, cluster cloud o infrastrutture on-premise. Questo facilita iterazioni più rapide tra simulazione, addestramento e test HIL.

Dal punto di vista infrastrutturale, OSMO si integra con il KAI Scheduler di NVIDIA, supporta placement sensibile alla topologia NVLink per multi-GPU e introduce funzionalità per gestione delle priorità, timeout per gruppi di task e meccanismi di preemption e borrowing di GPU tra pool. Queste caratteristiche sono rilevanti per carichi distribuiti che richiedono coordinamento di risorse accelerative specializzate.

Sul versante dei dati e della sicurezza, la piattaforma propone una gestione dei dataset basata su content-addressable storage con deduplicazione e mette a disposizione componenti di identità e autorizzazione (RBAC sidecar, integrazione OAuth2, TLS al gateway Envoy e cloud workload identity) per ridurre l'esposizione di credenziali nelle istanze Kubernetes.

Una possibile lettura

OSMO rappresenta un tentativo pratico di standardizzare l'orchestrazione delle pipeline di Physical AI collegando tre livelli di calcolo spesso gestiti separatamente. Se adottato, può diminuire la complessità operativa nelle fasi di sperimentazione e accelerare il passaggio dal prototipo alla validazione su hardware reale. Tuttavia, l'efficacia dipenderà dalla capacità dei team di integrare OSMO nei processi esistenti e dalla maturità delle integrazioni con provider cloud e soluzioni on-premise.

La deprecazione del CLI standalone per i dataset (annunciata nelle note di rilascio citate) suggerisce inoltre la necessità di pianificare le migrazioni per chi gestisce flussi di dati consolidati: le pipeline dovranno adeguarsi alla gestione dei dataset come output di workflow per mantenere compatibilità con le versioni future.

Fonte: MarkTechPost