• Глава 1: Baseline — считаем от Wan2.1-14B
• Как устроена модель
• DiT в числах
• Сколько токенов обрабатывает DiT?
• FLOPS на один шаг
• Калибровка по реальности
• Где мы сейчас
• Глава 2: Базовые ускорения — что можно сделать прямо сейчас
• FlashAttention + torch.compile
• Step Distillation: 50 → 4 шага
• CFG distillation
• Sparse Attention
• Суммарный эффект
• Глава 3: Квантизация — меньше бит, больше скорость
• Глава 4: Новое поколение карточек
• GPU Roadmap
• Пересчёт для новых GPU
• Глава 5: Мои предположения о будущих улучшениях
• Глава 6: А давайте всё на мобилку засунем
• Baseline:
• Текущие мобильные NPU
• Прогноз TOPS по годам
• Выводы

Глава 1: Baseline — считаем от Wan2.1-14B

Для расчётов нам нужна конкретная архитектура, которую можно разложить на числа. Берём Wan2.1-14B — одну из лучших open-source моделей для генерации видео. (Technical Report).

Как устроена модель

Генерация видео в Wan2.1 — это три этапа:

Этап 1: Text Encoder. Текстовый промпт кодируется через UMT5 (5.3B параметров) в 512 текстовых токенов. Это делается один раз и кэшируется.

Этап 2: DiT (Diffusion Transformer). Основной вычислительный блок. 14 миллиардов параметров. Берёт шум в latent space и за 50 steps превращает его в сжатое представление видео. Каждый шаг — полный forward pass через все 40 transformer layers.

Этап 3: VAE Decode. Wan-VAE (127M параметров) декодирует latent представление обратно в пиксели. Вычислительно дёшево по сравнению с DiT.

DiT в числах

Число параметров                14B
Transformer layers              40
Hidden dimension (d)            5120
Attention heads                 40 (head dim = 128)
Feedforward dimension (d_ff)    13,824

Сколько токенов обрабатывает DiT?

DiT работает не с пикселями, а с latent tokens — сжатым представлением видео. Считаем:

Формула: tokens = (1 + T/4) × (H/16) × (W/16)

720p (1280×720), 5 сек, 16 fps = 81 кадр:

Temporal: 1 + 80/4 = 21 latent кадров
Spatial:  (720/16) × (1280/16) = 45 × 80 = 3,600 latent пикселей на кадр
Tokens = 21 × 3,600 = 75,600

75 тысяч токенов — вот с чем работает DiT на каждом из 50 шагов деноизинга.

FLOPS на один шаг

Каждый из 40 layers DiT состоит из трёх блоков. Считаем FLOPS для каждого (S = 75,600, d = 5120):

Self-Attention:

QKV проекции:        8 × S × d²     = 8 × 75,600 × 5120²     ≈ 15.9 TFLOP
Attention (scores):  4 × S² × d     = 4 × 75,600² × 5120     ≈ 117.1 TFLOP
                                                        Итого: ≈ 133 TFLOP

Cross-Attention (текст → видео):

≈ 8.4 TFLOP per layer

FFN (feedforward):

4 × S × d × d_ff = 4 × 75,600 × 5120 × 13,824 ≈ 21.4 TFLOP

Итого на один layer:

133 + 8.4 + 21.4 = ~163 TFLOP

40 layers, один step:

40 × 163 = ~6,500 TFLOP = 6.5 PFLOP

Self-Attention = 82% всех вычислений. Обратите внимание на 4 × S² × d — квадратичная зависимость от числа токенов. Удвоение разрешения → учетверение attention compute.

Калибровка по реальности

Теоретические FLOPS — это хорошо, но давайте сверимся с реальными замерами.

Wan2.1-14B на 1×H100:

• 720p, 5 сек, 50 steps: 242 секунды
• На 8×H100 (FSDP + Ulysses): 7.7 секунд

Из реальных замеров: 1 секунда видео 720p ≈ 48 секунд на H100 (242 сек / 5 сек). Это наша калиброванная точка отсчёта — все дальнейшие расчёты масштабируем от неё.

Где мы сейчас

Глава 2: Базовые ускорения — что можно сделать прямо сейчас

Прежде чем менять железо, выжмем максимум из текущего решения. Для реальных цифр рекомендую глянуть блог от Morphic, где они подробно расписали ускорения и провели точные замеры

FlashAttention + torch.compile

FlashAttention не уменьшает FLOPS — он уменьшает обращения к памяти. Вместо материализации матрицы attention (75K × 75K ≈ 5.7 миллиардов элементов), считает блоками, не записывая промежуточные результаты в HBM.

torch.compile добавляет kernel fusion — объединяет операции в один GPU kernel.

Эффект: MFU с ~30% → ~50-60%. Speedup: ~1.5-2×.

Step Distillation: 50 → 4 шага

Каждый step — полный forward pass через 14B модель. Consistency distillation обучает модель делать то же за меньше шагов:

• 50 → 8 steps: качество почти не падает
• 50 → 4 steps: минимальная деградация
• 50 → 1 step: заметная потеря, но usable для preview

Эффект: 50/4 = 12.5×. Консервативно: ~10×.

CFG distillation

CFG делает два forward pass на каждый step (с промптом и без). Guidance distillation учит модель генерировать "guided" за один проход.

Эффект: ~2× speedup.

Sparse Attention

Не все пары токенов одинаково важны. VSA (Variable Sparse Attention) и Block Sparse пропускают ненужные пары. TurboDiffusion комбинирует sparse attention со step distillation и показывает 100-200× суммарный speedup.

Консервативная оценка sparse attention отдельно: ~3-6×.

Суммарный эффект

Baseline (1 сек видео 720p):     48 сек на 1×H100

Flash + compile:     ×1.7    → 28 сек
Step distillation:   ×10     → 2.8 сек
CFG removal:         ×2      → 1.4 сек
Sparse attention:    ×4      → 0.35 сек ✅

Результат: 720p realtime на одном H100 достижим с aggressive optimization (4 steps, sparse, no CFG).

Реалистичный сценарий (8 steps, moderate sparse, partial CFG):

×1.7 × 6 × 1.5 × 3 = ×46
48 / 46 ≈ 1.0 сек — на границе realtime

Глава 3: Квантизация — меньше бит, больше скорость

Современные GPU имеют физически разные Tensor Cores для разных числовых форматов. FP8 Tensor Cores выдают ровно 2× throughput по сравнению с FP16.

Compute: меньше бит → больше операций в секунду.

H100:  FP16 = 989 TFLOP/s  |  FP8 = 1,979 TFLOP/s (×2)
B200:  FP16 = 2,250        |  FP8 = 4,500   |  FP4 = 9,000 (×4)

Memory: меньше бит → меньше данных через шину.

14B модель: FP16 = 28 GB  |  FP8 = 14 GB  |  FP4 = 7 GB

FP8: потеря качества < 1%, стандарт индустрии. FP4: требует calibration, работает на Blackwell через microscaling.

Пересчёт с FP8:

Aggressive opt, FP16:  0.35 сек → с FP8: 0.18 сек ✅
Moderate opt, FP16:    1.0 сек  → с FP8: 0.5 сек ✅

Глава 4: Новое поколение карточек

⚡ Граница: H100 и B200 — реальность, можно купить/арендовать сегодня. B300 объявлен, поставки H2 2025. Всё дальше — экстраполяция на основе NVIDIA roadmap и исторических трендов.

GPU Roadmap

NVIDIA анонсировала roadmap на GTC 2025: Blackwell Ultra (B300), Rubin (2026), Rubin Ultra (2027), Feynman (2028).

Исторический тренд: ~2× achievable FLOPS каждые ~18 месяцев. Memory bandwidth растёт медленнее (~1.5× за поколение), но новые форматы (HBM4, HBM4E) компенсируют.

*экстраполяция по тренду ~2× за 18 мес

Пересчёт для новых GPU

Вывод главы 4: 720p realtime уже достигнут на 1×H100 с оптимизациями. 1080p realtime — 8×H100 уже сейчас или 1×Rubin в 2026. Дальше — запас.

Глава 5: Мои предположения о будущих улучшениях

По моей интуиции, сейчас основных bottleneck видео-генерации является не эффективное представление данных — видео из 81 кадра != 81 изображению по объему информации и даже темпоральное сжатие не сильно помогает, так как к примеру использование видео-кодеков позволяет сжатие видео намного сильнее. По этому мне интересно следить за подходами, которые используют более эффективное предстваление видео, к примеру CoPE-VideoLM

Поэтому хочется сделать предположение, что для видео генерации будет использоваться более сжатое представления, и как ориентир взять Wan2.2 VAE. Таким образом:

Wan2.1 VAE: compression 8×8 spatial → 75,600 tokens для 720p.

Wan2.2 VAE: compression 16×16 spatial:

• Tokens в (16/8)² = 4× меньше → ~18,900 tokens
• Attention compute: 4² = 16× меньше (квадратичная зависимость!)
• Weighted average (attention ~82%): ~13.6× суммарное ускорение

С patchification 2×2: total compression 32×32×4 → ещё 4× меньше.

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

Пока писался этот пост вышла realtime видео генерация в 1080p на базе LTX2.3 https://haoailab.com/blogs/fastvideo_realtime_1080p/. А у LTX сжатие 32x пространственное и 8x темпоральное

Глава 6: А давайте всё на мобилку засунем

Серверные GPU — хорошо, но телефон в кармане — другая история. Хочется взять телефон и например сделать свой персональный Subwafe Surfer симулятор, чтобы мотивировать себя заниматься бегом. Давайте глянем насколько мы далеко от реальности. За основу возьмем архитектуру 1.3B, т.к на мобильных устройствах слабее железо

Baseline:

Модель: 1.3B, INT8 = 1.4 GB
Разрешение: 480p
FPS на H100 FP8: 24.8
Computational Power H100: 3,958 TFLOPS (FP8)

Текущие мобильные NPU

Давайте глянем на вычислительную мощность современных мобильных чипов.

Qualcomm X2 Elite  │ 80 TOPS = 80 TFLOPS (FP8)
Snapdragon 8 Elite │ 45 TOPS = 45 TFLOPS (FP8)
Apple A18 Pro      │ 35 TOPS = 35 TFLOPS (FP8)

Прогноз TOPS по годам

Да, всё выглядит грустно, однако, давайте сделаем прогноз по годам

Прогноз TOPS: исторический тренд ~2× каждые 2 года. Следуя данному прогнозу мы получим:

2025: 45-80 TOPS (реальность)
2027: ~150 TOPS (Intel Nova Lake анонс + тренд)
2029: ~250 TOPS (экстраполяция ×2 от 2027)
2030: ~400 TOPS
2031: ~600 TOPS
2033: ~1,500 TOPS

Вывод: мобильный realtime с текущим AR подходом — это долгая история. 480p@1FPS: ~2027. 480p@12FPS: ~2031-2033. 720p realtime на мобилке — не раньше 2033-2035.

Но: это без учёта будущих архитектурных прорывов (smaller models, better compression, hardware-aware architectures). Каждое 10× improvement в model efficiency сдвигает timeline на ~3 года влево.

Выводы

Глядя на вычисления, качественная реалтайм генерация на серверах вопрос ближайших 2 лет. Отсюда можно дальше прогнозировать, когда появятся реалтайм игры, я бы поиграл в бесконечный Euro Truck Simulator или Subnautica. Надеюсь это будет к 2030 году.

Для меня оказалось неожиданным насколько мы далеки до realtime генерации на мобильных устройствах в 2030-е года не выглядит как AGI завтра. Возможно мы получим её за счёт качественного сдвига в инференсе - специальные чипы более оптимизированные архитектуры, где будут решены две проблемы: attention и более эффективное представление видео. Тут прогнозирую ближе к 2030 году

Добавлю, что расчеты для архитектуры Wan не слишком реалистичны, потому что более бОльшие архитектуры показывают качественный рост в консистентности, prompt following и эстетике. Чтобы учесть этот фактор и посмотреть, когда будет реалтайм на 30B, 200B архитектурах или попытаться использовать свою интуицию, чтобы оценить время realtime переходите на интерактивное демо.

1. Введение

В нашем предыдущем обзоре мы рассмотрели, как Reinforcement Learning (RL) помогает управлять сложными роботехническими конструкциями, такими как четвероногие роботы. Важную роль в здесь играет дизайн функции награды (reward) — именно награда определяет, какую задачу будет решать агент.

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

Конечно, для вышеперечисленных проблем у нас есть методы imitation learning, посвященные обучению политики, имитирующей демонстрации эксперта (им может выступать как какая-то другая политика, так и человек — в этом случае подразумевается наличие датасета демонстраций от человека). Из описаний видно, что главный недостаток этих методов — необходимость достаточного количества экспертных демонстраций, и собрать эти демонстрации, особенно если речь идет о реальных роботах, может быть довольно сложно.

На тему комбинации навыков (skill combination) работы существуют (например, первая и вторая), также, возможно, сюда подходит и Hierarchical Reinforcement Learning (тык на survey), но это все пока что, насколько мне известно, не особо исследованные в контексте роботехники направления.

Поэтому, вдохновившись показателями уровня знаний, заложенных в LLM, и их результатами в reasoning-задачах, исследователи задались вопросом:

2. Reward Design with Language Models (Kwon et al., 2023)

Link

Начнем немного издалека, кратко рассмотрев данную работу из начала 2023 года. Авторы исследуют задачу формализации "неформальных" поведений агента в небольших текстовых играх на тему экономики и бизнес-переговоров с помощью LLM. Сами авторы называют подобных агентов objective-aligned agents. Пример поведений: быть более настойчивым в переговорах, или наоборот, более пассивным.

Идея заключается в том, чтобы использовать LLM, а именно, GPT-3, в качестве, как они сами её называют, прокси-функцией награды. Конкретно, предлагается следующая схема:

По результатам авторы показали, что с помощью такого подхода вполне можно достичь уровня RL-агента, обученного с помощью ground truth-наград, и требует это меньше примеров в промптах, чем данных для supervised learning-бейзлайна. Целевых "стилизованных" поведений также удалось достичь (или, по крайней мере убедить в этом группу из 10 человек).

3. SayTap: Language to Quadrupedal Locomotion (Tang et al., 2023)

Link

В данной работе авторы рассматривают задачу управления роботом-собакой с помощью LLM. Управление подразумевает как выполнение простых команд, например, "Иди вперед" или "Иди назад", так и менее структурированных и более "стилизованных", как в предыдущей работе, например, "Радуйся, мы идем на пикник!" или "Осторожно, перед тобой белка, отойди!" (отличные видосики смотрите на сайте работы).

Предложенный подход состоит из двух главных блоков:

1. Блок генерации паттерна (шаблона) походки на основе LLM: языковая модель на основе промпта генерирует шаблон, то есть некоторое описание походки для робота. Важно отметить, что этот блок не требует никакого обучения.
2. Контроллер походки: принимает на вход сгенерированный паттерн и отвечает за то, чтобы робот двигался в соответствии этому паттерну. Данный блок обучается с помощью RL-я, во время обучения генерируются случайные паттерны.

Пример на картинке ниже:

Блог генерации паттерна, получив команду "Good news, we are going to a picnic this weekend", создает последовательность, говорящую роботу, что ты должен прыгать от радости :) Контроллер, принимая, этот паттерн исполняет его и мы видим, как прыгает робот

Паттерн походки имеет вид последовательностей из T (число дискретных шагов) нулей и единиц для каждой из ног робота, где 0 означает, что нога должна быть поднята, а 1 — что она должна касаться земли. На рисунках выше ноги обозначены как FL — front left (передняя левая), FR — front right (передняя правая), RL — rear left (задняя левая), RR — rear right (задняя правая). Имхо, чем-то это напоминает игру Guitar Hero :)

Теперь самое интересное — как эти паттерны предлагается генерировать. Авторы использовали GPT-4 и промпты, состоящие из следующих блоков:

1. Общее описание задачи
2. Общее описание того, что вообще такое походка, базовая классификация типов походок для робособак
3. Общие правила генерации шаблона и походки и его формат. Здесь также указывается, что общая скорость тела робота задается дискретными значениями — это помогает обрабатывать неформальные запросы типа "быстрее" или "медленнее".
4. Блок с примерами

В итоге, взаимодействие с человеком выглядит следующим образом:

1. Пользователь вводит команду для робота
2. LLM на основе базового промпта и введенной команды пользователя генерирует паттерн походки
3. Сгенерированный паттерн походки "исполняется" контроллером походки.

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

4. Language to Rewards for Robotic Skill Synthesis (Yu et al., 2023)

Link; пост в блоге Google Research

Данная работа также посвящена управлению и генерации навыков для роботов с помощью LLM, однако, помимо четвероного робота, рассматривается также управление манипулятором. В предыдущей статье "связующим звеном" между LLM и роботом выступал паттерн походки и соответствующий контроллер; в этой же работе таким звеном выступает контроллер на основе подхода Model Predictive Control (MPC).

В предыдущих постах мы уже упоминали MPC, и в целом он заслуживает отдельного поста, поскольку совмещение MPC и Deep Learning-методов тема довольно интересная. Для тех, кому прямо сейчас интересен более подробный разбор MPC — добро пожаловать в дополнительный раздел после заключения ( через идею шахмат вы легко поймете MPC).Здесь же для краткости просто скажу так: MPC оптимизирует последовательность действий агента за счет минимизации функции стоимости (cost), либо максимизации функции награды (последняя формулировка используется реже, хоть и понятия взаимозаменяемы, но авторы пользуется именно ей). MPC не требует обучения — процесс оптимизации сам по себе является политикой, выдающей действия для агента. Но взамен для этой оптимизации требуется модель агента, и, в зависимости от задачи, среды.

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

Обращение к LLM (в данном случае — GPT-4) состоит из двух этапов (в тексте это упоминается как использование двух LLM): Motion Description и Reward Coding. Вместе эту схему генерации авторы называют Reward Translator, а MPC-контроллер — Motion Controller.

Motion Description подразумевает описание требуемого движения робота. Цель — получить от LLM высокоуровневое описание движения робота в соответствии с заданным шаблоном. Промпт имеет следующую структуру:

1. Шаблон, по которому должныо генерироваться описание движения (motion template)
2. Разъяснения по шаблону и дополнительные правила для генерации (rules)

Reward Coder принимает сгенерированное описание движения с предыдущего этапа, и генерирует необходимые функции награды и их параметры. Промпт имеет следующую структуру:

1. Описание доступных функций наград и их аргументов (reward API): предполагается, что у нас есть некая библиотека доступных функций наград и краткая документация к ней — за что какая функция отвечает и какие у неё есть аргументы. Задача LLM — подобрать нужные функции и значения их аргументов.
2. Блок с примерами
3. Блок с правилами для генерации

Как и в предыдущем случае, Reward Translator не требует какого-либо дообучения. Motion Controller на основе MPC также не требует обучения, но зато требует отдельной настройки, как в общем-то любой "классический" контроллер.

Тесты проводились в симуляторе MuJoCo на четвероногом роботе и манипуляторе, а также на реальном манипуляторе. Как показывают авторы, получилось достичь лучших результатов, чем с Code-as-Policies (об этом подходе речь пойдет далее).

5. Code as Policies: Language Model Programs for Embodied Control (Liang et al., 2023)

Link

Вообще, первая версия данной работы вышла раньше, чем Language-to-Rewards, но по смыслу, учитывая остальные рассматриваемые работы, будет удобнее поместить её после. Авторы предлагают применять LLM для генерации программ (такие программы они называют Language Model Programs — LMP) для роботов, использующих как first-party библиотеки (т.е. "внутренняя" библиотека с функциями и классами, касающимися непосредственно управлением роботом), так и third-party библиотеки (сторонние библиотеки, такие как NumPy, Shapely, и др.). В целом, идея заставить LLM генерировать код для решения какой-либо задачи, не связанной напрямую с программированием, не нова (см., например, ViperGPT и Toolformer). Одно из преимуществ такого подхода — код в общем-то является довольно универсальной и интерпретируемой формой, которая при этом явно предоставляет LLM информацию о возможностях целевой платформы (в частности, как мы увидим далее, за счет описания API и примеров в промптах).

First-party библиотека состоит из двух компонентов: Perception API — функции, касающиеся детекции объектов (в частности, использовались open-vocabulary детекторы ViLD и MDETR) и оценки состояния робота, и Control API — функции, касающиеся управления роботом. Важно отметить, что обе эти библиотеки написаны и затюнены людьми.

Предлагаемый подход также подразумевает иерархическую генерацию кода, подразумевающую как простое использование API-функций, так и генерацию вспомогательных функций и их объединение в основной программе. LLM, использовавшиеся в работе — варианты OpenAI Codex и GPT-3.

Промпты довольно сложные. В основном состоят из подсказок (hints — по сути просто аннотации того, что делает пример) и примеров (examples). Примеры делятся на две группы: низкоуровневые (low-level) и высокоуровневые (high-level).

Низкоуровневые примеры показывают LLM, как работать с third-party и first-party библиотеками.

Также к низкоуровневым примерам авторы относят примеры reasoning-а, например, соотношение объектов с их описаниями.

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

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

Оценка качества генерации кода проводилась на кастомных бенчмарках, и сгенерированные программы-политики запускались на реальных роботах, в частности, для решения задач манипуляции и навигации.

Предложенный подход частично похож на подход из Language-to-Rewards. Если в последнем был фокус на генерацию скорее псевдокода из списка функций наград и их параметров, то здесь происходит генерация полноценного кода.

6. Заключение

В данном разборе мы увидели, как можно построить "мост" между LLM и реальным железом. Предложенные подходы имеют разную степень универсальности, но одно из их главных общих преимуществ — возможность сократить потребность в обучении агента. Представленные результаты также говорят о том, что LLM способны производить некий reasoning относительно представлений о движении роботов. В будущем, как отмечают многие авторы, одним из главных направлений исследований в этой области станет применение мультимодальных моделей, которые позволят расширить промпты за пределы текстовой модальности.

Автор: @TimeEscaper

7 Supplementary: подробнее про MPC

Для начала, приведем небольшую аналогию. Представьте, что вы играете в шахматы. Чаще всего, вы планируете свои действия на несколько ходов вперед, на основе некоторых представлений — то есть модели — действий противника. Имея в голове план на несколько ходов вперед, вы, в соответствии с правилами игры, делаете лишь один ход. Далее, в зависимости от хода противника, вы либо придерживаетесь своего текущего плана, либо составляете новый план, если видите, что действия противника сильно отклоняются от ваших ожиданий. MPC работает по схожей схеме: его задача состоит в создании плана на H шагов вперед (либо H секунд, если мы работаем с непрерывной задачей) в соответствии с заранее известной моделью процессов. Обычно величину H называют горизонтом.

На изображении выше представлена базовая математическая формулировка задачи MPC (в дискретном и детерминированном случае; непрерывные и стохастические варианты MPC тоже существуют). Здесь векторы состояний (states) и управлений (controls) имеют те же значения, что и состояния и действия (actions) в RL-е — разница в названиях сложилась исторически. Состояние может включать в себя как непосредственно состояние агента, так и состояние среды, управления же обычно относятся только к агенту. Модель представляет собой математическое выражение того, как изменяется состояние агента (и, возможно, среды) в зависимости от приложенного управления. Эта модель может иметь вид как, например, простейших кинематических формул из школьного курса физики, так и сложную систему дифференциальных уравнений. Модель — это тот компонент, который считается неизвестным в model-free RL.

Следующий важный компонент — это функция стоимости (cost). Стоимость в MPC играет ту же роль, что и награда (reward) в RL — инкапсулируют нашу задачу. Функцию награды на два компонента: стоимость на этапе (stage cost), т.е. стоимость на каждом шаге горизонта, и финальную стоимость (final cost) т.е. стоимость в конечном состоянии горизонта, как показано на изображении выше, но это уже детали реализации.

Важно отметить, как именно происходит минимизация стоимости. Поскольку у нас в явном виде известны и функция стоимости, и наша модель, то у нас в общем-то есть вполне определенная задача оптимизации, и, соответственно, мы можем воспользоваться аппаратом методов оптимизации. Оптимизация в MPC — отдельная большая тема, поэтому пока что лишь кратко упомяну, что здесь довольно популярны алгоритмы выпуклой оптимизации и нелинейного программирования. Существуют также и альтернативные методы решения данной задачи, например, за счет динамического программирования или сэмплирования, но об этом, возможно, тоже в отдельном посте. Пока что важно усвоить отличие от RL-я: здесь мы не используем никакого обучения, а напрямую решаем нашу задачу минимизации стоимости в соответствии с используемой моделью.

Последний важный компонент в MPC — это ограничения (constraints). Использование методов оптимизации, многие из которых подразумевают решение задачи оптимизации с ограничениями, позволяет нам в явном виде учитывать ограничения системы, с которой мы работаем — это одна из главных причин, по которой MPC стал популярен в индустрии. В простейшем виде ограничения могут иметь вид, например, отрезков, в которых могут находится компоненты вектора управлений (конкретный пример — ограничения на управляющий сигнал скорости робота). Ограничения можно наложить и на состояния агента — возвращаясь к примеру с навигацией мобильного робота, мы можем наложить ограничения на положение робота для избежания столкновений с объектами на карте.

Выше мы упоминали, что на выходе MPC выдает план — этот план имеет вид последовательности управлений на H шагов вперед. На практике, из этой последовательности применяется только первое управление, после чего вновь начинается процесс планирования (вспоминаем пример с шахматами выше). Такая схема позволяет, с одной стороны, выработать управление, которое будет оптимально в контексте будущего, и, с другой стороны, быть более устойчивым к внезапным изменениям во внешней среде.

TLDR: Обзор трех работ от одной из ведущих лабораторий ETH Zürich, посвященных управлению четвероногими роботами с помощью RL-я.

Всем привет! В этом посте перейдем непосредственно к более детальному рассмотрению применения ML в роботехнике, а именно - рассмотрим, как RL помогает управлять робо-собаками (они же legged robots, они же quadruped robots), разобрав 3 статьи от авторов из ETH Zürich. Я выбрал их, т.к. они сами по себе довольно влиятельные, а также хорошо демонстрируют ряд приемов, помогающих RL-ю работать в реальном мире.

Ко всем разобранным статьям настоятельно рекомендую смотреть видео-презентации, чтобы так сказать сфьюзить информацию из данного разбора и информацию от самих авторов работ, и в целом понять, о каких проблемах идет речь.

1. Зачем нам вообще здесь RL?

Как мы обсуждали в вводном посте, для управления движением роботов используются аппарат теории управления, а также теории оптимального управления. Для управления четвероногими роботами существуют довольно сильные "классические" бейзлайны, в частности, на основе Model Predictive Control (MPC, более детально этот метод, я думаю, мы рассмотрим в следующих постах). Главный недостаток подобных методов - это их сложность. Математические модели для данного типа роботов очень сложные (в отличие, например, от большинства колесных роботов), особенно, если попробовать учесть изменяющиеся параметры внешней среды; для этих моделей сложно определять параметры. Поэтому одна из основных областей робототехники, где был популяризирован RL - это именно четвероногие роботы.

2. Learning agile and dynamic motor skills for legged robots (Hwangbo et al., 2019)

Link

В первой работе, которую мы рассмотрим, авторы решают 3 типа задач с помощью RL:

• Command-conditioned locomotion (движение в соответствии командам с пульта);
• High-speed locomotion ("бег галопом" — движение, обычно, вдоль прямой на высокой скорости);
• Recovery from a fall (учили робота вставать с колен подниматься из "лежачего" или "полулежачего" положения).

Во всех задачах использовался алгоритм Proximal Policy Optimization (PPO) — популярный RL-алгоритм, возможно, известный многим по RLHF. Все сети внутри PPO (если совсем упрощенно, то это сети актора — отвечает за выходные действия агента, и критика — отвечает за оценку состояния; именно первую сеть мы далее будем называть политикой) имеют вид простых MLP.

Наблюдения включали в себя историю положений и скоростей "тела" робота (имеется в виду основной корпус, к которому крепятся ноги), состояния суставов и ряд вспомогательных компонентов в зависимости от задачи (см. картинку ниже).

Команда представляет собой вектор, состоящий из:

• Поступательную скорость (forward velocity, м/c) - компонент скорости, направленный вдоль тела робота;
• Боковую скорость (lateral velocity, м/c) — компонент скорости, направленный перпендикулярно телу;
• Скорость поворота (turning rate, рад/c) — по сути, угловая скорость тела робота.

Так, команда [1., 1., 0.] заставит робота пройтись по диагонали без поворота корпуса, а команда [1., 0., 0.5] — завернуть направо (или налево, в зависимости от ориентации координат). В реальном мире эти скорости задаются с помощью пульта управления, а во время обучения в симуляторе — сэмплируются из равномерного распределения с началом каждого нового эпизода.

Функция награды представляет собой взвешенную сумму довольно большого количества компонентов (специально ограничиваюсь смысловым описанием, для тех, кому знакомы основы теоретической механики и хочет разобраться подробнее — добро пожаловать в supplementary materials статьи):

• Ошибка по линейным и угловым скоростям: очевидно, что reward должен поощрять соответствие актуальных скоростей тела входной команде
• Штрафы на моменты на выходе приводов и скорости суставов: это своего рода регуляризация, ограничивающая величины соответствующих моментов и скоростей. Идея в следующем: мы хотим достигать скорости не за счет использования больших мощностей в лоб, а за счет более "умного" переставления ног — эти штрафы как раз "вдохновляют" агента искать эти более умные схемы.
• Штрафы на положения и скорости ступней: мы хотим избежать проскальзывания ступней, а также их высокого отрыва от земли
• Штраф на ориентацию тела робота: для большей устойчивости, мы хотим, чтобы тело робота всегда находилось как можно более параллельно земле
• Штраф за резкое изменение моментов на выходе приводов: мы хотим достичь более гладкого движения робота, поэтому штрафуем большие разности моментов между двумя последовательными шагами в эпизоде

Самые интересные детали статьи касаются приемов, которые применялись, чтобы вся эта RL-ная история заработала в реальном мире.

Первое - это использование самописного симулятора RaiSim (сейчас он является отдельным проектом этой лаборатории), который, как утверждают авторы, очень точно моделирует динамику твердого тела, и при этом эффективен с точки зрения вычислений, что также позволяет ускорить обучение.

Второе - это предложенный способ моделирования приводов (actuators) робота. Как упоминают авторы, задача моделирования приводов, в частности, гидравлических и электрических, которые очень часто применяются в лучших робо-собаках, очень сложна, в связи с чем достичь реалистичной симуляции становится намного сложнее. Авторы предложили следующий интересный подход: они собрали датасет с входными и выходными (т.е. моментами) сигналами на реальных приводах, и обучили соответствующую нейросеть. В итоге они получили нейросетевую модель приводов, которая далее была использована в симуляторе, что позволило сделать симуляцию более реалистичной.

Третье - применение техники Domain Randomization. Как показывает практика, это один из самых эффективных методов решения проблемы sim-to-real transfer и повышения robustness RL-политики (в какой-то степени, его можно сравнить с теми же аугментациями из supervised learning). Идея довольно проста: в ходе обучения в симуляторе рандомизируются разные параметры симуляционной модели, в нашем случае, например, параметры массы робота, трения, начальных положений робота и др.

3. Learning quadrupedal locomotion over challenging terrain (Lee et al., 2020)

Link

Эта статья развивает идеи предыдущей работы. Если в предыдущей работе рассматривалось управление роботом только на ровных поверхностях в indoor-средах, то в этой работе авторы поставили цель выйти "на природу", причем довольно экстремальную. То есть, цель работы - расширить предложенный RL-подход на "неровные" ourtdoor-среды.

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

Первое - это применение техники на основе подхода Learning by Cheating.

Суть состоит в следующем: есть две политики - политика-учитель (teacher policy) и политика-студент (student policy). Политика-учитель обучается с помощью RL-я, и её пространство наблюдений состоит из двух компонентов. Первый включает непосредственно те наблюдения, которые будут использоваться на реальном роботе. Авторы называют их проприоцептивными (proprioceptive) наблюдениями, что, говоря простым языком, означает наличие информации только о состоянии робота (в частности, положение тела робота и положения суставов) и отсутствие явных наблюдений о внешнем мире (таких как изображения с камер или данные о контактах ног с поверхностью). Соответственно, политика, которая использует только проприоцептивные наблюдения, называется проприоцептивной политикой. Второй компонент авторы называют привилегированной информацией (privileged information) - это некая ground truth-информация, которую практически невозможно извлечь в реальном мире, но легко извлечь в симуляторе (в частности, она включала в себя информацию о контактах ног робота с поверхностью, профиль поверхности, параметры трения и др.). Привилегированная информация позволяет значительно упростить процесс обучения, и достичь очень хорошего перформанса в симуляторе.

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

Второй прием - это domain randomization и curriculum learning.

Идея curriculum learning в контексте RL, а точнее, как указывают авторы, automatic curriculum learning, заключается в постепенном усложнении среды по мере улучшения перформанса агента. Также наоборот, среду можно упрощать, если вдруг перформанс агента начинает проседать.

Здесь авторы рандомизируют форму поверхности, используя три паттерна: "впадинки" (steps), лесенки (stairs) и холмики (hills). Для оценки перформанса агента нужна какая-то эвристика, и зачастую ей выступает какая-то статистика наград. Но награды зачастую тяжело интерпретировать, чтобы построить правила и параметры для curriculum-а. Поэтому, авторы предлагают использовать намного более интерпретируемую оценку - проходимость поверхности текущей политикой робота, из которой далее выводятся параметры для сэмплирования поверхностей.

4. Learning robust perceptive locomotion for quadrupedal robots in the wild (Miki et al., 2022)

Link

Наконец, третья статья из 2022 года завершит логическую цепочку в данном обзоре. Настоятельно рекомендую к просмотру видео-презентацию!

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

Экстероцептивные информация имеет следующий вид. С помощью LiDAR-а и/или стереокамеры выполняется построения локальной карты высот (elevation map) - эта карта показывает уровень "возвышенностей" на поверхности вокруг робота. Из этой карты сэмплируется множество точек в окрестностях ног робота - это множество относительных высот и является используемой далее информацией о мире (назовем это экстероцептивным наблюдением).

Схема обучения также основана на предыдущих статьях - применяется и learning by cheating, и другие приемы. Однако, структуры и политики-учителя, и политики-студента, модифицированы:

• Политика-учитель, помимо проприоцептивного наблюдения и ground truth-привилегированной информации, также получает GT-экстероцептивное наблюдение, и так же обучается с помощью PPO по схеме с curriculum.
• Политика-студент получает проприоцептивное наблюдение и зашумленное экстероцептивное наблюдение. Теперь студент не пытается "вслепую" повторять за учителем, а пытается сначала оценить привилегированную информацию на основе экстероцептивных наблюдений, и далее использовать эту оценку —точнее, её латент, который авторы называют belief state — для повторения за учителем.

За эту оценку отвечает автоэнкодер-подобная структура из блоков belief encoder (используется при обучении и деплое) и belief decoder (используется только при обучении). Декодер обучается восстанавливать привилегированную информацию и исходное экстероцептивное наблюдение с помощью reconstruction loss — расстоянием между GT и восстановленными данными. Цель всей этой схемы — связать belief state с недоступными GT-экстероцептивным наблюдением и привилигерованной информацией. Второй лосс - behaviour loss - отвечает за соответствие выходных действий политике-учителю, как в предыдущей работе.

Важно отметить роль attention-а в belief encoder: сколько использовать информации из экстероцептивного наблюдения. Проблема в том, что построенная карта высот может не всегда быть надежной — из-за шума или от природы самой поверхности. Авторы приводят интересный пример со снегом: на карте он выглядит как возвышенность, но по факту, наступив на него, робот проваливается. В этом случае за счет attention-а и рекуррентной структуры энкодер поймет, что экстероцептивному наблюдению нельзя сильно доверять, и будет использовать больше проприоцептивной информации.

5. Заключение

На примере данных работ я хотел показать, какие техники позволяют запускать RL в сложных задачах управления на реальных роботах, а также эффективно использовать информацию от различных сенсоров. От этой и других рисерч групп в ETH есть много других статей на тему ML-я для четвероногих роботов (так, они уже вовсю рассматривают возможность использования подобных роботов на Марсе), а также развивают и более классические бейзлайны. Вообще, эта тема довольно популярная, и у других лабораторий тоже есть прикольные результаты (например, работа RMA: Rapid Motor Adaptation for Legged Robots от ребят из Berkley и CMU).

Также стоит учесть, что ETH фокусируется на роботах семейства ANYmal - одних из самых продвинутых и крупных в своем роде. Однако, многие из описанных выше методов применялись и для более простых роботов.

Stay tuned!

Автор: @TimeEscaper