Бенчмарк для робототехнических симуляторов на GPU

Привет, Хабр! Меня зовут Дмитрий Юдин, я являюсь ведущим научным сотрудником лаборатории когнитивных систем искусственного интеллекта AIRI и заведую лабораторией интеллектуального транспорта в Центре когнитивного моделирования Института искусственного интеллекта МФТИ. В последние годы мы с коллегами системно занимаемся трехмерными симуляторами, которые, в том числе, позволяют промоделировать физические взаимодействия между мобильными роботами, манипуляторами или мобильными манипуляторами с объектами 3D‑сцены. 

В этой статье я расскажу про бенчмарк GPUSimBench, созданный вместе с коллегами из Shanghai AI Lab. Написать её мне помог Чжан Хучжэньюй, первый автор работы и выпускник аспирантуры Физтеха. Бенчмарк оценивает производительность, точность и детерминизм семи современных общедоступных робототехнических симуляторов при работе на графических процессорах, а для одной из симуляций мы даже провели настоящий физический эксперимент. Мы представили GPUSimBench на ведущей робототехнической конференции IROS’2026 (статья и код).

Почему 3D‑симуляторы — это важно?

В последние годы в разработку систем воплощённого ИИ пришло понимание, что дальнейшему прогрессу в этой области требуется всё больше данных для обучения. Лаборатории стараются внедрять роботов в как можно большее количество процессов физического мира, однако одного этого недостаточно. 

Сегодня большие надежды связывают с Real2Sim2Real подходами. Они позволяют сначала перевести реальные сенсорные данные робота в 3D‑симулятор, получив физически правдоподобную среду, далее в ней обучить нейросетевую модель управления роботом, и в конце преобразовать сгенерированные действия в управляющие сигналы реального робота. Это дает возможность преодолевать ограничения малого количества реальных демонстраций для обучения роботов: в симуляторе их можно сделать сколько угодно много даже с редкими сценариями действий, не рискуя повредить реальное оборудование. 

В этом направлении сейчас работает много ведущих исследователей по всему миру, можно отметить популярные свежие работы GenieSim 3.0 (статья и код) и Real2Render2Real (статья и код). У нас тоже есть наработки в этой области: несколько лет назад наша группа предложила метод RozumFormer (статья и код). А совсем недавно мы помогали коллегам из Центра робототехники Сбера создавать виртуальные среды в симуляторе на основе Isaac Sim для проведения соревнования GreenChallenge по обучению выполнения действий антропоморфного робота Green на кухне, складе и в магазине. Кстати, это соревнование проходит прямо сейчас в рамках конференции AIJourney, и я желаю всем участникам успешных результатов!

Зачем нужна параллельная симуляция и почему именно на GPU?

Обучение роботов требует огромного числа взаимодействий со средой. Например, стратегии обучения с подкреплением могут понадобиться миллионы шагов проб и ошибок, прежде чем робот перестанет ронять предметы. Число параллельных сред — самый прямой способ повлиять на время обучения: чем больше сцен обрабатываются параллельно, тем быстрее происходит обучение.

Традиционный подход — запускать множество независимых экземпляров симулятора на ядрах CPU, но он плохо масштабируется: экземпляры дублируют состояние сцены в памяти, постоянно имеют «накладные расходы» на синхронизацию и обмен данными, а доступные ядра быстро заканчиваются. GPU, напротив, по своей природе параллельны: тысячи ядер предназначены для одновременного выполнения одной программы над огромными объёмами данных. Именно на этом основаны симуляторы с GPU‑ускорением: они переносят весь конвейер физического моделирования — обнаружение столкновений, учет физических контактов и обновление состояния среды — на GPU и синхронно обрабатывают тысячи, а иногда и миллионы сред на одном устройстве.

Вычислительная мощность GPU уже позволяет создавать достаточное количество параллельных сред для обучения роботов. Но какие проблемы это порождает? Например, если 100 000 сред синхронно выполняют шаги на одном GPU, остаётся ли физика корректной? А если дважды провести в точности один и тот же эксперимент — с той же сценой, теми же начальными значениями генераторов случайных чисел и всеми прочими настройками, — получится ли в точности тот же результат?

В существующей литературе ни на один из этих двух вопросов не было систематического ответа, и именно поэтому мы и создали бенчмарк для робототехнических симуляторов, работающих на GPU, под названием GPUSimBench (статья и код). Предшественником этой публикации была наша статья LAMDEN на конференции по нейронным сетям IJCNN’2025 про систему навигации между этажами, использующая симулятор Isaac Sim для создания интерактивных сцен с лифтами.

Как выяснилось, оба эффекта поддаются измерению, носят систематический характер и проявляются по‑разному в каждом симуляторе.

Три вопроса к симулятору

GPUSimBench охватывает семь симуляторов с GPU‑ускорением: Isaac Lab, ManiSkill, Genesis, Madrona, MuJoCo Warp, MJX и MuJoCo Playground. Платформы, использующие параллелизм только на CPU, например Gazebo или PyBullet, в исследование не вошли. Для каждого симулятора мы оцениваем три характеристики (рисунок 1):

• Масштабируемость — суммарная производительность (FPS) и объём используемой памяти GPU при увеличении числа параллельных сред;

• Физическая согласованность — соответствие распределений результатов симуляции и аналогичного эксперимента в реальном мире;

• Детерминированность — дают ли параллельные среды в одном запуске одинаковые результаты (вариативность между параллельными средами, Parallel Variability) и дают ли независимые запуски одной конфигурации одинаковые результаты (вариативность между запусками, Run‑to‑Run Variability).

Эксперименты на одной видеокарте RTX 5070

Все эксперименты проводились на одной рабочей станции с GPU Nvidia RTX 5070. Для оценки масштабируемости были разработаны две сцены: свободно падающий массив кубиков 3×3×3 — простейшая сцена с контактными взаимодействиями — и манипулятор Franka Panda со случайными целевыми положениями суставов, создающий нагрузку на расчёт динамики сочленённых тел (рисунок 2).

Центральным экспериментом стало исследование столкновений на наклонной плоскости (см рисунок 3). Во всех тестах рендеринг отключён: мы измеряем только время расчёта физических шагов, используя во всех симуляторах фиксированный шаг 0,01 с.

Количественный анализ мы проводим на эксперименте со столкновением на наклонной плоскости. Стальной шар скатывается по деревянной поверхности с углом наклона 20° и врезается в стенку из 27 деревянных кубиков; через пять секунд мы фиксируем положение каждого кубика. Сцена проста, недорога в реализации и крайне хаотична: крошечные различия усиливаются и приводят к заметно разным перемещениям кубиков. Главное — мы также построили её реальный аналог с той же геометрией и материалами, а коэффициенты трения и восстановления определили в лабораторных условиях. Шестнадцать реальных испытаний дают эталонное распределение, а шестнадцать параллельных симулируемых сред — результат симулятора. Мы сравниваем их с помощью расстояния EMD (Earth Mover’s Distance) на горизонтальной плоскости, измеряемого в сантиметрах. Помимо точности, эта же установка позволяет оценить согласованность результатов каждого симулятора между параллельными средами в одном запуске и между независимыми запусками.

Возможности параллельного выполнения

На рисунке 4 показаны основные полученные экспериментальные результаты: 

Из них можно сделать такие основные выводы:

• Симулятор Genesis — лидер по производительности для моделирования роботов‑манипуляторов: около 11,1 млн FPS с манипулятором Franka при 131 072 параллельных средах — на обычном GPU с 12 ГБ памяти.

• Симуляторы MJX и MuJoCo Warp превосходят остальные по числу сред: каждый достиг 524 288 параллельных сред с Franka‑манипуляторов.

• Симулятор Madrona смог поддерживать 262 144 сред в сцене свободного падения при производительности около 481 тыс. FPS, но в нашей конфигурации не поддерживает манипуляционные роботы.

• Симулятор Isaac Lab показал сбалансированный результат: примерно 472 тыс. FPS в сцене свободного падения при использовании всего 3,3 ГБ памяти GPU.

• MuJoCo Playground оказался самым медленным по скорости расчёта шагов свободного падения: около 35 FPS при максимальных для него 256 средах. Прекрасное напоминание о том, что GPU‑ускорение вовсе не означает быстрое выполнение.

Разрыв Sim2Real у GPU‑симуляторов

Здесь два вывода. Сначала хорошая новость: в хаотичной задаче со столкновением на наклонной плоскости результаты пяти из семи симуляторов отклоняются от реальности примерно в пределах пяти сантиметров (см. рисунок 5) — в целом базовая физика контактов работает неплохо. Второй вывод связан с показательным исключением: в нашей конфигурации решатель XPBD в Madrona не воспроизводит трение на деревянной плоскости, поэтому кубики почти не замедляются и уезжают более чем на два метра. Один неучтённый эффект трения — и разрыв между симуляцией и реальностью увеличивается в пятьдесят раз. Такие различия не видны в бенчмарках успешности выполнения задач: захваченная чашка в любом случае считается захваченной.

Согласованность результатов симуляции

Мы измеряем два вида согласованности: согласованность параллельных сред (дают ли одинаково инициализированные параллельные среды в одном запуске одинаковые результаты) и согласованность между запусками (воспроизводится ли агрегированный результат при повторении той же конфигурации). В этих экспериментах мы везде фиксировали начальные значения генераторов случайных чисел и отключали всю рандомизацию домена: сцены и начальные условия были идентичны. Наивно было бы ожидать одинаковых результатов во всех случаях, но на практике получились четыре режима из таблицы 1.

Таблица 1. Четыре эмпирически наблюдаемых режима стохастичности симуляторов при фиксированных начальных значениях генераторов случайных чисел и одинаковых начальных условиях

Почему это важно? Если вы оцениваете стратегию A в средах 1–4096, а стратегию B — в средах 4097–8192 одного запуска Isaac Lab, часть измеренной разницы обусловлена шумом симулятора, а не качеством стратегий. Разброс между средами в 4–5 см в задаче, где вся сцена помещается в полметра, — вовсе не погрешность округления. А в процессах переноса из симуляции в реальность, где настраивают параметры контактов и сравнивают показатели разных запусков, вариативность между запусками незаметно становится частью разрыва Sim2Real.

Мы не ставили целью строго проверить механизмы, лежащие в основе этих режимов, поэтому далее предлагаем скорее правдоподобное объяснение, нежели установленный результат. Вычисления на GPU, использующие атомарные или параллельные операции, могут суммировать числа с плавающей точкой в порядке, зависящем от планировщика (scheduler); итерационные решатели (solvers) могут идти немного разными путями от запуска к запуску; а в сценах с большим числом физических контактов такие микроскопические различия способны накапливаться и приводить к заметным сдвигам распределений. При этом ошибки в программе может и не быть — просто параллельные численные вычисления встречаются с негладкой динамикой.

Так какой симулятор выбрать?

Единственного победителя нет — в этом отчасти и состоит смысл исследования. Рисунок 6 показывает компромиссы по шести нормированным осям: на каждой большее значение означает лучший результат.

В связи с этим наши практические рекомендации выглядят так.

Если не знаете, с чего начать, берите Isaac Lab: это сбалансированный вариант, который подходит для большинства задач. Если вам важна воспроизводимость, то есть повторные запуски должны давать одинаковые результаты, чтобы эксперименты можно было честно сравнивать, лучше подойдут MJX или Genesis.

Для переноса стратегий управления из симуляции на реальных роботов, особенно в сценах с большим количеством контактов (захваты, столкновения, взаимодействие с объектами), выбор зависит от того, как вы работаете. Если вы многократно перезапускаете эксперименты и подбираете параметры сцены, удобнее MJX. Если достаточно оценить результат за один запуск, обратите внимание на ManiSkill или MuJoCo Playground.

Если нужно запускать как можно больше параллельных симуляций, тоже есть два варианта. Для роботов‑манипуляторов лучше всего масштабируется Genesis, для простых агентов максимальный параллелизм даёт Madrona. Наконец, если видеокарта небольшая по памяти, а огромный параллелизм не нужен, разумный компромисс — MuJoCo Warp.

Общий вывод: неограниченное масштабирование может незаметно ухудшать воспроизводимость. Увеличивая число сред, следите не только за FPS, но и за вариативностью результатов.

Пара слов о конференции IROS’2026

Работа про GPUSimBench, напомню, была принята на конференцию IROS’2026. Она проходила в этом году в Питсбурге, США, поэтому поехать туда очно не удалось из‑за визовых ограничений, но постер все равно повесили на площадке (см. рисунок 7), а также представили доклад онлайн (см. видео). 

В этом году на IROS из 4348 поданных статей было принято 1585 (доля принятых работ уменьшилась до 36,45%, в 2025 году этот показатель был 46,24%). Радует, что среди них оказались и статьи российских ученых из МФТИ, AIRI, Сколтеха.

Вместо заключения

Робототехническое сообщество продолжает стремиться к повышению эффективности обучения VLA‑моделей управления роботами, и симуляторы с GPU‑ускорением становятся всё более заметным самостоятельным направлением исследований. Надеемся, что эта статья окажется полезной исследователям, работающим с робототехническими симуляторами. Мы же продолжим заниматься разработкой и совершенствованием симуляторов с параллельным выполнением на GPU.