VLM – VLA – World Models – Physical AI

Нейроночки в последнее время заполонили всё. Ну, почти всё. Вот, сейчас п��дбираются к роботам. И реального прогресса там почти так же много как нейрослопа, пиара и преувеличений . Короче, прогресс есть, о нём и поговорим.

Если 2022–2023 годы можно уверенно назвать периодом взрывного роста больших языковых моделей (LLM), то 2024 и начало 2025 года, на мой взгляд, стал переломным именно для визуально-языковых моделей — Visual Language Models (VLM). Из них выросли VLA — Visual Language Action модели (это когда вместо текстового аутпута поток токенов управления).

Брендинг не стоит на месте, надо придумывать что-то новое, так что в следующем году нас ждёт больше World Models и Physical AI. Что это такое люди пока не договорились, так что поговорим об этом через годик.

В статье мы поговорим как обучить VLA, когда лучше обучать VLA а когда VLM, какая разница есть во всём этом зоопарке. Всё это будет происходить на примере:

• Quake

• Вот этого чудного робота

Ладно-ладно, нейрослопа больше не будет!

Что такое VLA

Управлять роботом End-to-End заманчиво. Мы подаём на вход картинку с камеры робота, добавляем текстовый промпт вроде «поезжай к двери» или «возьми предмет со стола», и дальше модель сама выдаёт команды управления.

И сделать это не сложно. Даже без обучения. Недавно было тут. Автор показывал, как он использовал VLM-модель для навигации робота, вообще не обучая её под эту задачу — просто подавая на вход изображения и текстовый запрос.Но и выходных команд было мало.

На первый взгляд всё выглядит довольно убедительно. Но если попробовать повторить подобные эксперименты на практике, довольно быстро становится понятно, почему такой подход плохо масштабируется.

Почему VLM «из коробки» плохо управляют роботами

Проблема здесь не в том, что VLM-модели «глупые» или «плохо обучены». Наоборот — для своего класса задач они работают очень хорошо. Проблема в другом.

Как только задача требует:

• пространственного понимания сцены,

• навигации во времени,

• понимания физики робота

• понимания 3д вокруг

• удержания долгосрочного контекста,

• точности действий

качество резко падает.

Я в какой-то момент специально сделал простой эксперимент: попросил разные модели (ChatGPT, Gemini, Qwen) построить траекторию движения робота за плюшевую игрушку к песочным часам по изображению сцены. Результаты получились… скажем так, очень наглядные.

Я тестировал с десяток разных промптов, накладывал разные линейки, и.т.д. Результат один – ни разу ни одна модель не попала в точку с соблюдением критериев.

Проблема тут и в восприятии и в архитектуре. И есть хорошая иллюстрация:

Clock Benchmark и проблема восприятия

Здесь полезно упомянуть ещё один важный момент. Существует специализированный бенчмарк — Clock Benchmark — который как раз тестирует способность нейросетей:

• корректно воспринимать визуальную информацию,

• понимать пространственные отношения,

• адекватно интерпретировать контекст.

Результаты там довольно показательные.
Если человек на этом бенчмарке показывает точность порядка 95%, то большинство современных моделей — меньше 40%.

И это не баг, а почти фича. Если модель специально не обучали под такие задачи, она и не обязана с ними справляться. У модели нет понимания логики и пространства.

Да, можно дообучить модель, добавить примеры, повысить точность. Именно так и обучаются многие VLM-модели. Но при этом страдает генерализация: модель начинает хорошо работать на знакомых сценариях, но плохо переносит знания на новые.

А если робот становится чуть сложнее — не просто «вперёд / назад / влево / вправо», а несколько степеней свободы, сложная кинематика, взаимодействие с объектами — опять дообучение.

Архитектура

Пришло время небольшого обзора как роботами управляют сегодня.

Вместо одной «универсальной» модели обычно используют пайплайн из нескольких уровней:

Высокоуровневая модель-планировщик
Чаще всего это лингвистическая или мультимодальная модель, которая умеет разбивать задачу на подзадачи.
Например:

1. подъехать к раковине,

2. взять тряпку,

3. протереть первый стол,

4. протереть второй стол,

5. взять веник,

6. подмести кухню,

7. вернуть веник на место.

Низкоуровневые VLA-модели
Для каждой конкретной подзадачи используется отдельная модель, которая:

• уже понимает локальный контекст,

• работает с сенсорами,

• напрямую управляет моторами и приводами.

Такая логика сейчас встречается во многих современных архитектурах, но говорить тут мы будем про VLA, вторую часть. Её окно обычно ограничивается от нескольких секунд до десятков.

VLA

Вообще, если кому-то интересно глубоко, то я бы порекомендовал вот эти два видео:

• https://www.youtube.com/watch?v=8dZUOo5xWFw – тут целиком

• https://youtu.be/J4wpO0EdCZs?si=ff0MqgFQ-sVRRe9d&t=2755 – тут сокращённая версия

А тут попробую лоу-левыл рассказать.

Если сфокусироваться именно на моделях, которые решают задачу не планирования, а непосредственного управления роботом, то чаще всего их делают так:

• VLM отвечает за восприятие сцены и понимание контекста (изображение + текст),

• из неё извлекаются эмбеддинги,

• дальше отдельная, сравнительно небольшая модель преобразует эти эмбеддинги в последовательность действий робота. В обычном VLM там стоит большой декодер в текст.

Такую архитектуру можно воспринимать как:

• либо отдельную модель поверх замороженного бэкбона,

• либо как разновидность LoRA-подхода,

• либо как набор нескольких «голов», каждая из которых отвечает за свою подзадачу.

Это можно сделать по разному. Из видео выше нагло упру:

Почему этот подход хорошо работает

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

Если у нас робот, которому нужно:

• принимать команды десятки или сотни раз в секунду,

• при этом обрабатывать визуальный контекст сравнительно редко,

то схема выглядит примерно так:

• VLM-бэкбон считается, условно, 500ms раз в секунду,

• дальше action-head генерирует, например, 100 микродвижений за 100ms на следующую секунду

• В следующий инференс мы контекстом кладём все эти команды.

• Когда приходит результат – мы диначмически переключаемся на текущую

В итоге:

• мы экономим вычисления,

• получаем низкую латентность,

• и можем управлять достаточно быстрыми системами.

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

Именно поэтому подобный подход сейчас используется во многих проектах и библиотеках. Один из самых известных примеров — Small VLA, который интегрирован в экосистему LeRobot и используется как базовая модель во множестве экспериментов и туториалов.

Минусы VLA

При всех плюсах у этого решения есть и довольно серьёзные ограничения.

Во-первых, это сложность пайплайна:

• отдельная модель (с кучей кастомного кода вокруг)

• отдельный формат данных,

• отдельный экспорт,

• отдельный инференс.

Во-вторых, такие модели обычно:

• плохо масштабируются,

• жёстко завязаны на конкретную механику робота,

• и требуют очень аккуратной настройки при переносе на другую платформу.

Ну и, наконец, инфраструктурный момент.
Не понятно на каком железе как запускать и что поддержет. На этом месте многие внезапно обнаруживают, что инференс VLA-моделей — это отдельная инженерная задача, и далеко не всегда приятная.

Но вобще-то… Можно не париться и взять VLM

Nvidia пару месяцев назад обучила просто обычный VLM и внезапно оказалось что всё что городили последний год в VLA хуже. Это всё что надо знать про текущий уровень развития.

Вообще можно всё это пооптимизировать, сделать гибрид и аблейшн стади, получить что-то такое. Так что VLA-0 это скорее хороший концепт.

Основной прикол VLM всё же, не в точности.

Любая VLM-мод��ль автоматически наследует огромную экосистему инструментов:

• Инференс:

  • vLLM,

  • llama.cpp,

  • TensorRT-LLM,

  • итд

• Обучение

  • Unsloth,

  • LLaMA-Factory,

  • Axolotl,

  • итд

Запустить через большую часть из них VLA сложно. На VLA из коробки это не заработает.

Ну и да. VLM вы можете на десятке разных NPU запустить из коробки. А для VLA придётся попотеть

Практика: зачем вообще Quake и причём тут роботы

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

С одной стороны — полностью синтетические среды, где всё слишком стерильно и слишком далеко от реального мира. Мне нравятся MuJoCo и ManySkills, но это синтетика. Nvidia имеет хорошие симуляторы которые могут выглядеть реалистично. Но для них надо много настраивать что.

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

В итоге я остановился на довольно банальном, но, как оказалось, очень показательном варианте — Quake 3.

На первый взгляд идея может показаться странной: зачем тащить шутер двадцатилетней давности в разговор про VLA и робототехнику? Но если посмотреть чуть внимательнее, Quake неожиданно оказывается очень удобной тестовой средой.

Во-первых, это:

• непрерывное пространство,

• визуально сложная сцена,

• навигация в реальном времени,

• управление с высокой частотой.

Во-вторых, это полностью контролируемая среда:

• легко собирать данные,

• легко повторять эксперименты,

• легко масштабировать количество эпизодов.

Ну и, в-третьих, это просто хороший способ быстро понять, что модель реально умеет, а что — нет.

(Отдельный бонус — мой пятилетний сын умеет немного в Quake 3, так что я устроил битву между ним и роботом. Спойлер: пока что он выигрывает.)

Эксперимент 1: Small VLA и обучение в Quake

В первом эксперименте я решил пойти по классическому пути и использовать модель класса Small VLA — то есть VLM-бэкбон плюс action head.

Общая схема выглядела примерно так:

• на вход подаётся изображение из игры,

• нажатые кнопки на момент кадра,

• дополнительно — текстовое описание задачи (но так как описание было одно и то же – выкинул),

• на выходе — действия игрока: повороты, движение, стрельба.

Датасет выглядет примерно так:

{
  "segment_start": "2026-01-18T02:42:42",
  "duration_s": 5.0,
  "fps": 10,
  "frame_count": 50,
  "keys": [
    {
      "key": "u0444",
      "press_time": 0.0,
      "release_time": 0.1316
    },
    {
      "key": "Key.space",
      "press_time": 0.262,
      "release_time": 0.4161
    },
    {
      "key": "u0439",
      "press_time": 0.6297,
      "release_time": 0.7606
    },
    {
      "key": "u0432",
      "press_time": 0.3976,
      "release_time": 1.4558
..........
 "mouse": {
    "moves": [
      {
        "t": 0.1132,
        "x": 960,
        "y": 539,
        "dx": 0,
        "dy": -1,
        "source": "raw"
      },
      {
        "t": 0.2016,
        "x": 960,
        "y": 538,
        "dx": 0,
        "dy": -1,
        "source": "raw"
      },
      {
        "t": 0.2571,
        "x": 961,
        "y": 538,
        "dx": 1,
        "dy": 0,
        "source": "raw"
      },
....
    "buttons": [
      {
        "button": "Button.left",
        "press_time": 4.5354,
        "release_time": 4.727,
        "press_x": 959,
        "press_y": 538,
        "release_x": 959,
        "release_y": 539
      }
    ],
    "move_source": "raw"
  },
  "video_file": "video.mp4"
}

Я сознательно не усложнял постановку задачи:

• никакого сложного планирования,

• никакой тактики,

• только базовая навигация и реакция на сцену.

Цель была не «научить бота играть в Quake», а проверить, насколько это всё вообще работает.

Что получилось

Результат, в целом, работал.

Модель:

• довольно быстро научилась базовым перемещениям,

• начала ориентироваться в коридорах,

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

Но при этом начали проявляться и типичные проблемы:

• отсутствие долгосрочного контекста,

• плохое восстановление после ошибок,

• часть действий модель не обучилась/не поняла. Например – стрельба

Здесь как раз очень хорошо видно, почему такие модели (которые пробуют повторить действия) сложно напрямую переносить на реальных роботов. В симуляции агент может бесконечно «переигрывать» ситуацию. В реальном мире каждая ошибка имеет физическую цену и требует коррекции. Но если этих ошибок нет в обучении – модель не знает как их компенсировать. Если они есть – модель будет подражать и совершать их.
Это лечиться через правильную разметку или использования RL. Но это уже сложно.

Почему Small VLA всё равно важен

Несмотря на ограничения, Small VLA — это очень полезный класс моделей.

Во-первых, они:

• относительно быстрые,

• хорошо ложатся на реальные контроллеры,

• позволяют управлять роботами с высокой частотой.

Во-вторых, именно на них сейчас строится большая часть открытых туториалов и библиотек. Если вы хотите:

• разобраться, как вообще устроено обучение VLA,

• пощупать пайплайн,

• собрать первый прототип,

то такой подход остаётся самым прямым и понятным.

Если кто хочет более подробно посмотреть на данные или код, вот тут есть статья. Вот тут код. А вот тут видео:

Эксперимент 2: попытка повторить то же самое с Qwen-VL

После этого логично было попробовать второй подход — цельную VLM без отдельной action-модели.

На бумаге всё выглядело красиво:

• берём Qwen-VL,

• подаём на вход изображения,

• просим модель выдавать действия в текстовом или структурированном виде,

• обучаем через стандартный фреймворк.

Но на практике меня здесь ждало довольно быстрое разочарование:

Модель не успевает в риалтай по жесткому. Инферю на 1 действие – 500ms. На пять действий – 1.3 секунды. Не хватает. Я понимал что можно было оптимизировать (например я подавал несколькор кадров, а можно было и один). Но разница была такая большая что забил.

Переход к реальному роботу

Короче, был у меня дома один робот небольшой (не хотелось связывать с далеко стоящими руками, хотя мне предлагали доступ). Про этого робота я писал вот тут.

Если в двух словах – я взял робота где-то в конце осени/лета. А месяца назад собрал и настроил телеоп для бабушек с внуками играть (мы в Германии, они в разных страных). В целом свою цель робот выполнил.

Про телеоп роботов мелких можно долго рассказывать, попробую просто в двух словах о том как этот рынок развивается:

• Два года назад на рынке таких роботов вообще не было

• Пол года назад когда я заказал робота и запланировал всё – я смог найти телеоп роботов для питомцев, но не для детей

• За эти пол года в продаже появилось несколько роботов оптимизированных именно под детей.

Так что сегодня я бы такое не делал и купил готовый.

Но, он был у меня на руках – решил начать с ним.

Используем его для VLM

Идея здесь была проста:

• минимальное число степеней свободы,

• медленное движение,

• относительно статичная сцена,

• отсутствие требований к управлению с высокой частотой.

Задача которой я решил обучить:

Робот начинает ехать в произвольном месте, надо въехать в арку.

• модель получает визуальный контекст,

• на выходе — структурированное описание действия

Вот так выглядет датасет. Обзорная камера + камера с робота = действие сделанное. Датасет содержал ~40 примеров. В примерах от 2х кадров до 10.

Записал где-то за час.

Про тренировку я подробнее тут рассказал. По сути:

• Unsloth в качестве энджина

• Подаю две картинки на вход (две камеры)

• Текстовый промпт исключаю

• Так как датасет маленький – визуалку заморозил

• Решил полный файнтюнинг делать а не лору – точность была повыше существенно

Для инференса vllm. Пример как ездит:

Ездит не идеально. Так как датасет маленький любая аномалия выбивает робота:

• Свет из окна – сразу крутит в другую сторону

• По-другому закрытые двери – едет в другую сторону

• Нет отсечки “я доехал”

Но в целом, как видите – более менее работает.

Статью полную выше дал, тут наверное хватит а то много будет. Ещё можно в этом видео посмотреть:

Зачем?!

Так. Пришла пора разобраться а зачем вообще всё эти VLM модели нужны. Вот например видео того что мы делали лет пять назад:

И у нас там даже было обучение почти на лету. И скорости там были куда больше чем любая VLM модель выдаст. Ни одной VLM/VLA не пострадало.

Зачем VLM нужны сегодня?

Глобально, это 3-4 причины:

• Гуманоиды. Им слишком сложно модели делать кастомные. Осей подвижности десятки. Сложное моделирование, дорогой сбор данных. Нужен End-to-end

• Сложные задачи, где нельзя разметить в рамках простой логики. Например хватание тканей или перекладывание произвольных объектов. Часто логика “повторяй за мной” работает сильно лучше

• Иногда можно упростить существующие пайпланы обучения

• Все верят что когда-нибудь в будущем появлятся достаточно общие модели – и не надо будет обучать с нуля. Но пока что скорее это так.

Так что мне VLA/VLM скорее интересны как объект наблюдения + те задачи где они перформят лучше. Но интеграция как основная модель для роборуки сомнительна.

Да, крупные компании пытаются зп��скать в прод. Вот это пример который Figure AI сделали со своим роботом:

Но на настоящих пайплайнах это не работает. Вот скорости настоящих конвееров (тут АлиЭкспресс):

Тут Амазон:

Когда компании считают “а внедрить ли нам робота” – они смотрят на скорость его работы и число ошибок. Пока что гуманоиды не могут превзойти людей почти нигде.

И так везде. VLA/VLM пока что дороги, медленны в обучении, менее точны чем классические модели. Но они определённо открывают доступ к новым скилам. И, скорее всего, за несколько лет простота использования улучшиться. Вообще это тема для длинных размышлений. Если кому интересно, то вот тут вот свой взгляд рассказывал.

Как собирают датасеты VLM/VLA

Наверное, это тема для большой статьи. Но без краткого упоминания эта статья будет неполна.
То как я собирал датасет – идеализированный вариант. Такая халява почти невозможна. Главные пайплайны обучения:

• Виртуальное управление. Вот тут хорошие примеры (Neo,Fourier,Unitree). US и EU компании часто стесняются эту чернуху показывать, но для китайских роботов можно много найти. Суть обучения – просто учим робота повторять что и человек.

• Симуляции. Сейчас очень много симуляторов. Часто через симулятр можно добавть RL, что значительно улучшает восстановление робота из аномальных ситуаций. Так же RL может ускорить обучения. Но у RL просто прорва своих проблем. И настроить реальную сцену в симуляторе сложно (текстуры, физика, и.т.д.).

• Трансфер лёнинг. Робот смотрит на то как люди делают что-то и пытается повторить. По сути вариация первого пункта, но без сложных данных для сбора (примеры датасетов 1,2)

• RL но без симуляции. Дорого-богато. Если у вас очень много роботов, то можете позволить. Решает часть проблем того что симуляции неидеальны. Но сильно дороже.

Саммари

Прогресс неостановим. Не только в нейронках, но и в железе. Я уверен что более-менее разумные гуманоидные роботы/руки в ближайшие годы будут более чем целесообразны.

Нужно ли учить VLA/VLM или простую сетку – это отдельный вопрос. И обычно его нельзя решить пока не посмотреть на саму задачу.