Разработка физических ИИ-систем (Physical AI) и робототехники давно переросла стадию простых экспериментов. Сегодня это сложный инженерный процесс, требующий координации огромных вычислительных ресурсов. Но у разработчиков роботов есть не одна проблема вычислений, а три. Сначала политика (policy) обучается на мощных кластерах с GPU уровня GB200 или H100. Затем она тестируется в симуляторе Isaac Sim на рабочих станциях с RTX-видеокартами. И наконец, валидация происходит на реальном железе, например, на модуле Jetson, установленном внутри самого робота.
Каждый из этих этапов традиционно требует своего собственного кластера, своего планировщика задач и набора «склеивающих» скриптов, которые передают данные от одного этапа к другому. Эта фрагментация инфраструктуры создает огромные накладные расходы и ошибки. NVIDIA предлагает решение этой проблемы: OSMO. Это проект с открытым исходным кодом, нативный для Kubernetes, который позволяет команде описать весь конвейер в одном YAML-файле и запустить его на всех этапах, не касаясь низкоуровневого кода инфраструктуры.
01Три компьютера: корень проблемы фрагментации
NVIDIA определяет проблему физической ИИ-разработки как «проблему трех компьютеров». Это не просто метафора, а архитектурная реальность современных робототехнических проектов. Обучение моделей происходит в центрах обработки данных, где доступны тысячи GPU. Симуляция физики, рендеринг сенсоров и отработка поведения происходят на рабочем уровне оборудования (workstation-class), то есть на мощных видеокартах серии RTX. Развертывание и тестирование «железо-в-контуре» (Hardware-in-the-Loop, HIL) происходит на периферийных устройствах, таких как Jetson AGX Thor, часто прямо в цеху или на полигоне.
Каждый из этих уровней обычно получает свой собственный набор инструментов. Передача данных между ними — это место, где накапливаются кастомные скрипты, которые сложно поддерживать, масштабировать и отлаживать. Ошибки в этих «клеях» приводят к тому, что модель, отлично показавшая себя в симуляции, может оказаться непригодной для реального мира из-за несовпадения сред или потери данных при передаче.
OSMO рассматривает все три уровня как бэкенды единой плоскости управления (control plane). Каждый бэкенд представляет собой кластер Kubernetes, зарегистрированный через командную строку. Ключевая особенность подхода заключается в том, что рабочие процессы (workflows) никогда не называют конкретный кластер напрямую. Вместо этого они называют платформу (например, gb200, rtx-pro-6000 или jetson-agx-thor), и OSMO маршрутизирует задачу в пул ресурсов, который предлагает соответствующие возможности. Это абстрагирует разработчика от сложности сети и хранения данных.
02Как выглядит рабочий процесс в OSMO
Чтобы понять мощь подхода, рассмотрим канонический пример из репозитория проекта. Типичный пайплайн состоит из трех задач, связанных данными:
- Симуляция (simulation): Запускает контейнер Isaac Sim на платформе
rtx-pro-6000. Здесь генерируются данные для обучения. - Обучение политики (train-policy): Запускает контейнер PyTorch на платформе
gb200с использованием 8 GPU. Эта задача принимает на вход данные, полученные от задачи симуляции. - Оценка на Thor (evaluate-thor): Запускает приложение ROS на устройстве
jetson-agx-thor, потребляя обученную политику и записывая результаты в именованный набор данных.
Зависимости между задачами определяются через поле inputs, сохранность данных — через outputs, а размещение вычислений — через поле platform. Пользовательское руководство (user guide) подробно описывает поддержку последовательных и параллельных групп задач, использование шаблонов Jinja для параметризации рабочих процессов, политики повторных попыток (retry policies) и приоритеты HIGH/NORMAL/LOW с возможностью прерывания и «заимствования» GPU между пулами.
03Ключевые возможности платформы
OSMO — это не просто планировщик задач, а комплексная платформа, разработанная с учетом специфики работы с ИИ и робототехникой. Рассмотрим ее основные возможности подробнее.
Портативность и гибкость развертывания
Один и тот же YAML-файл может быть запущен как на ноутбуке (с использованием Docker/KIND), так и на облачных кластерах EKS, AKS, GKE, на локальных серверах или в изолированных (air-gapped) сетях. В релизе 6.3.0 был добавлен скрипт deploy-k8s.sh для мульти-провайдерного развертывания, который позволяет настроить OSMO на Azure AKS, AWS EKS, microk8s или любом существующем кластере. Особое внимание уделено интеграции хранилищ: поддерживается MinIO, Azure Blob, AWS S3 или использование собственных S3-совместимых хранилищ.
Интерактивная разработка
Для разработчиков критически важно иметь возможность быстро отлаживать задачи. OSMO позволяет запускать сессии VS Code, Jupyter или SSH на удаленных GPU-узлах, выполнять команду exec для входа в работающие задачи, пробрасывать порты сервисов и синхронизировать файлы в обоих направлениях. В версии 6.3.0 была добавлена команда osmo workflow rsync download с индикатором прогресса, что значительно упрощает работу с большими объемами данных.
Умное планирование (Scheduling)
По умолчанию OSMO использует NVIDIA KAI Scheduler. В релизе 6.2.8 была добавлена поддержка размещения задач с учетом топологии NVLink для многопроцессорных задач, что критично для высокой скорости обучения. В версии 6.3.0 таймауты exec_timeout и queue_timeout стали настраиваться для каждой группы задач. Это означает, что зависшая группа симуляции больше не будет убивать соседние группы обучения, что повышает стабильность всего кластера.
Работа с данными
Проект описывает контентно-адресуемые наборы данных (content-addressable datasets) с дедупликацией, которые, по заявлениям NVIDIA, могут сократить объем хранимых данных в 10–100 раз. Важно отметить: в версии 6.3.0 были объявлены устаревшими (deprecated) автономная команда osmo dataset и API /datasets. Они будут удалены в версии 6.4, и теперь управление наборами данных должно происходить через выходы рабочих процессов (workflow-managed dataset outputs). Разработчикам следует заранее планировать миграцию.
Безопасность и идентификация
С версии 6.2.8 OSMO поставляется со встроенным сайдкар-прокси авторизации RBAC, интеграцией OAuth2 с аутентификацией по device-code и маппингом пользователей из провайдеров идентичности. В релизе 6.3.0 добавлена терминация TLS на шлюзе Envoy и поддержка облачных рабочих идентичностей (Azure Workload Identity, AWS IRSA/Pod Identity). Это позволяет сервисам не монтировать ключи доступа к хранилищу как секреты Kubernetes, что значительно повышает безопасность.
osmo-user по умолчанию, ограничив ее доступом только к пулу по умолчанию. Это снижает риски несанкционированного доступа к ресурсам других команд.Интеграция с AI-агентами
Репозиторий содержит файл AGENTS.md, каталог skills и руководство по развертыванию MCP (Model Context Protocol). На конференции GTC 2026 NVIDIA объявила, что OSMO интегрируется с Claude Code, OpenAI Codex и Cursor. Это означает, что кодовые агенты (coding agents) могут самостоятельно отправлять, мониторить и отлаживать пайплайны, используя естественный язык. Это открывает путь к полностью автономной разработке робототехнических решений.
04Практическое применение и экосистема
OSMO уже прошел проверку на реальных проектах. Он используется в связке с GR00T (базовая модель для роботов), Isaac Lab, Isaac Sim и Isaac ROS. Существуют готовые интеграции с Azure и Nebius, что делает его доступным для корпоративных клиентов, использующих эти облачные платформы.
Для разработчиков, желающих начать работу, доступен локальный быстрый старт (local quickstart), который запускает всю плоскость управления на рабочей станции с использованием KIND. Лицензия Apache-2.0 делает проект привлекательным для коммерческого использования. Helm-чарты и контейнеры доступны на NGC (NVIDIA GPU Cloud), что упрощает развертывание в корпоративных средах.
05Что это значит на практике
Внедрение OSMO меняет парадигму разработки физических ИИ-систем. Вместо того чтобы нанимать отдельных DevOps-инженеров для каждого этапа (обучение, симуляция, деплой), команды могут использовать единый язык описания инфраструктуры. Это снижает порог входа для исследователей, которые теперь могут сосредоточиться на алгоритмах, а не на настройке Kubernetes.
Интеграция с AI-агентами — это следующий шаг к автономной инженерии. Представьте, что вы говорите Claude Code: «Запусти симуляцию падения кубика, обучи модель удержания равновесия и протестируй её на роботе». OSMO берет на себя всю маршрутизацию задач, управление ресурсами и передачу данных. Это сокращает время от идеи до работающего прототипа с недель до часов.
Для компаний, работающих с робототехникой, OSMO предлагает путь к стандартизации. Единый YAML-файл становится документацией, тестом и инструкцией по развертыванию одновременно. Это особенно важно в условиях, когда требования к безопасности и воспроизводимости результатов в промышленной робототехнике становятся все строже.
Если вы занимаетесь разработкой роботов или физических ИИ-систем, OSMO — это инструмент, который стоит изучить. Он решает реальные проблемы фрагментации инфраструктуры и предлагает путь к более эффективной и масштабируемой разработке. Начните с локального запуска на KIND, чтобы понять принципы работы, а затем масштабируйтесь на облачные или локальные кластеры Kubernetes.
Все материалы, документация, релизы и примеры (Cookbook) доступны на официальной странице NVIDIA OSMO и в GitHub-репозитории проекта. Рекомендуется также следить за обновлениями в социальных сетях NVIDIA и на специализированных форумах, таких как Reddit, чтобы быть в курсе последних изменений и лучших практик сообщества.
Источник: MarkTechPost ↗