NVIDIA відкрила код OSMO: один YAML-файл оркеструє навчання Physical AI, симуляцію та тестування роботів

Розробники роботів мають не одну проблему з обчислювальними ресурсами. Їх 3. Політика навчається на кластерах GB200 або H100, тестується в Isaac Sim на RTX-GPU, а потім перевіряється на Jetson, встановленому всередині справжнього робота. Кожен рівень має власний кластер, власний планувальник і власні інтеграційні скрипти. NVIDIA OSMO — це відповідь NVIDIA на таку фрагментацію: оркестратор робочих процесів із відкритим кодом, нативний для Kubernetes, який дає змогу команді описати весь конвеєр в одному YAML-файлі та запускати його на кожному рівні, не торкаючись коду інфраструктури.

Готовий до розгортання? Так. OSMO ліцензований за ліцензією Apache-2.0, постачається з Helm-чартами й контейнерами на NGC, а також має локальний швидкий старт, який запускає всю площину керування на робочій станції за допомогою KIND.

Проблема трьох комп’ютерів

NVIDIA описує фізичний ШІ як проблему трьох комп’ютерів. Навчання відбувається на GPU у дата-центрах. Симуляція, фізика та візуалізація даних із сенсорів виконуються на RTX-обладнанні класу робочих станцій. Розгортання та тестування за принципом «апаратне забезпечення в контурі» (HIL) відбуваються на периферійних пристроях, таких як Jetson AGX Thor, зазвичай локально. Кожен рівень зазвичай отримує власний набір інструментів, а саме під час передачі між ними накопичуються спеціальні скрипти.

OSMO розглядає всі 3 як бекенди єдиної площини керування. Кожен бекенд є кластером Kubernetes, зареєстрованим через CLI. Робочі процеси ніколи не вказують назву кластера. Вони вказують платформу (наприклад, gb200, rtx-pro-6000 або jetson-agx-thor), а OSMO спрямовує завдання до пулу, який її підтримує.

Як виглядає робочий процес

Канонічний приклад репозиторію — це 3 завдання, пов’язані ланцюжком даних:

simulation запускає контейнер Isaac Sim на rtx-pro-6000
train-policy запускає контейнер PyTorch на gb200 із 8 GPU, використовуючи як вхідні дані результат завдання simulation
evaluate-thor запускає ROS-застосунок на jetson-agx-thor, використовуючи навчену політику та записуючи результати до іменованого набору даних

Залежності визначаються через inputs, збереження — через outputs, а розміщення — через platform. У посібнику користувача описано послідовні та паралельні групи завдань, шаблонізацію Jinja для параметризованих робочих процесів, політики повторних спроб, а також пріоритети HIGH/NORMAL/LOW із випереджувальним виконанням і запозиченням GPU між пулами.

Ключові можливості

Переносимість: Той самий YAML працює на ноутбуці (Docker/KIND) або в EKS, AKS, GKE, локальних чи ізольованих від мережі кластерах. У випуску 6.3.0 додано мультипровайдерний deploy-k8s.sh, який розгортає OSMO в Azure AKS, AWS EKS, microk8s або будь-якому наявному кластері, з налаштуванням сховища для MinIO, Azure Blob, AWS S3 або власного S3.
Інтерактивна розробка: Розробники можуть запускати VS Code, Jupyter або SSH-сеанси на віддаленому GPU-вузлі, виконувати exec у запущених завданнях, перенаправляти порти сервісів і передавати файли за допомогою rsync в обох напрямках. У версії 6.3.0 додано osmo workflow rsync download із індикатором перебігу в реальному часі.
Планування: За замовчуванням OSMO використовує NVIDIA KAI Scheduler. У випуску 6.2.8 додано розміщення для завдань із кількома GPU з урахуванням топології NVLink. У випуску 6.3.0 параметри exec_timeout і queue_timeout стали окремими для кожної групи, тож група симуляції, що зависла, більше не зупиняє сусідні групи навчання.
Дані: Проєкт описує набори даних із адресацією за вмістом і дедуплікацією, які, за його твердженням, можуть скоротити обсяг сховища в 10–100 разів. Зверніть увагу: окремі CLI osmo dataset та API /datasets в 6.3.0 визнано застарілими, а їхнє видалення заплановано у версії 6.4; заміною стануть вихідні дані наборів, якими керують робочі процеси.
Безпека та ідентифікація: Починаючи з версії 6.2.8 OSMO постачається з додатковим компонентом авторизації RBAC, інтеграцією з проксі OAuth2 із входом за кодом пристрою та зіставленням користувачів із постачальником ідентифікації. У випуску 6.3.0 додано завершення TLS на шлюзі Envoy і ідентифікацію хмарних робочих навантажень (Azure Workload Identity, AWS IRSA/Pod Identity), тож сервіси більше не монтують ключі сховища як Kubernetes Secrets. У випуску 6.3.1 стандартну роль osmo-user обмежено стандартним пулом.
Інтеграція з агентами: Репозиторій містить файл AGENTS.md, каталог skills і посібник із розгортання MCP. На GTC 2026 NVIDIA заявила, що OSMO інтегрується з Claude Code, OpenAI Codex і Cursor, тож агенти програмування можуть надсилати, відстежувати та налагоджувати конвеєри.

Інтерактивне пояснення: подивіться, як OSMO спрямовує один робочий процес через 3 рівні обчислень

Натисніть Запустити робочий процес, щоб побачити, як OSMO планує завдання з прикладу README одне за одним. Натисніть будь-який рівень або номер кроку, щоб переглянути, що там відбувається.

Основні висновки

OSMO оркеструє завдання навчання, симуляції та периферійного HIL з одного YAML-файлу в гетерогенних кластерах Kubernetes
Apache-2.0, Helm-чарти в NGC, останній випуск 6.3.1 (червень 2026 року), доступний локальний швидкий старт із KIND
Типовий планувальник — KAI Scheduler, розміщення з урахуванням NVLink, тайм-аути для окремих груп, вбудовані RBAC та OAuth2
Перевірено на GR00T, Isaac Lab, Isaac Sim та Isaac ROS; доступні інтеграції з Azure і Nebius
CLI наборів даних у 6.3 визнано застарілим, а в 6.4 його буде видалено; відповідно плануйте міграції

Перегляньте GitHub, документацію, випуски, Cookbook та сторінку NVIDIA OSMO. Уся подяка досліднику цього проєкту. Також підписуйтеся на нас у Twitter і не забудьте приєднатися до нашого сабреддіту про машинне навчання зі 150 тис.+ учасників та підписатися на нашу розсилку. Стривайте! Ви є в Telegram? тепер ви також можете приєднатися до нас у Telegram.

Потрібно співпрацювати з нами для просування вашого репозиторію GitHub, сторінки на Hugging Face, випуску продукту, вебінару тощо? Зв’яжіться з нами

Перекладено автоматично з англійської. Оригінал статті — за посиланням нижче.