Обучение VLA-моделей для робототехники: сколько GPU и сколько времени

Что такое VLA-модель

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

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

Размерности к 2026 году устоялись в два лагеря. Компактные модели на 1–7 миллиардов параметров работают на борту после квантования и закрывают манипуляцию и навигацию. Крупные, от 30 до 70 с лишним миллиардов, дают заметно лучшее понимание инструкций и планирование, но на борт целиком не помещаются и живут либо на стационарном вычислителе рядом, либо в двухуровневой схеме: тяжёлый планировщик работает редко, лёгкий контроллер — часто.

Чем это отличается от обучения обычной языковой модели

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

Второе — плотность токенов. Один кадр видео после визуального энкодера превращается в 128–729 токенов в зависимости от разрешения и архитектуры. Эпизод длиной 10 секунд при частоте записи 5 Гц — это 50 кадров, то есть от 6 до 36 тысяч токенов на один эпизод против примерно 750 токенов на страницу текста. Видео дорого в обучении именно из-за этого множителя.

Третье — требования к темпу на выходе. Языковой модели можно отвечать секунду, контуру управления манипулятором нужен такт 10–50 Гц. Это влияет на архитектуру: тяжёлую часть считают редко, лёгкую голову действий — часто, и обучать эти части нередко приходится по-разному.

Четвёртое — оценка качества. У языковой модели есть бенчмарки, которые считаются за минуты. У VLA основная метрика — успешность выполнения задачи на реальном стенде, и она требует физического робота, времени и человека. Планируя ресурсы, закладывайте, что на каждый цикл обучения придётся отдельный цикл проверки, который GPU не ускоряет.

Сколько данных и как перевести их в токены

Публичные корпуса дают точку отсчёта: объединённые датасеты уровня Open X-Embodiment — это порядка миллиона эпизодов с десятков платформ, собранных множеством лабораторий. Практический корпоративный датасет под конкретную задачу и конкретный захват — обычно 10–100 тысяч эпизодов; ниже 5 тысяч модель уверенно не обобщает даже при дообучении.

Переводим в токены на конкретном примере. Возьмём 50 тысяч эпизодов по 10 секунд, запись при 5 Гц, две камеры, по 128 визуальных токенов на кадр с камеры. Получаем 50 кадров × 2 камеры × 128 = 12 800 токенов на эпизод и 50 000 × 12 800 = 640 миллионов токенов на одну эпоху. Для сравнения: это примерно 850 тысяч страниц текста — при том, что физически это всего около 140 часов видео.

Отсюда сразу видно, за что вы платите. Удвоение частоты записи с 5 до 10 Гц удваивает стоимость обучения. Переход со 128 на 729 токенов на кадр, то есть повышение разрешения визуального энкодера, умножает её почти в шесть раз. Третья камера добавляет 50 %. Эти решения принимаются на этапе сбора данных, а платить за них приходится на каждой последующей итерации обучения — поэтому считать их стоит заранее.

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

Сколько памяти нужно под обучение

Рабочее правило для полного дообучения в BF16 с оптимизатором Adam — примерно 16 байт на параметр: 2 байта веса, 2 байта градиента, по 4 байта на два момента Adam и 4 байта на мастер-копию весов в FP32. Активации сверху зависят от батча, длины последовательности и от того, включён ли пересчёт активаций.

Для модели на 7 миллиардов параметров это 112 ГБ только под состояния — то есть на одну карту с 80 ГБ полное дообучение не помещается в принципе. Нужен шардинг между картами: формально хватает двух, практично — четыре, а с видеоактивациями и осмысленным батчем комфортно на восьми.

Для 70 миллиардов параметров те же 16 байт дают 1 120 ГБ. Это минимум шестнадцать карт по 80 ГБ, забитых под завязку одними состояниями, поэтому реальные конфигурации — 32 или 64 карты, где остаётся место под активации и не приходится жертвовать батчем. Здесь же становится критичным межсоединение: на таких масштабах экономия на InfiniBand превращает дорогие карты в наполовину простаивающие.

LoRA меняет картину радикально. Обучаются только низкоранговые адаптеры, базовые веса лежат замороженными: для 7B это около 14 ГБ весов в BF16 плюс единицы гигабайт на адаптеры и их оптимизатор — помещается на одну карту с 80 ГБ вместе с активациями. Для 70B замороженные веса занимают около 140 ГБ, то есть нужны две-четыре карты вместо шестнадцати. Разница в стоимости входа — на порядок.

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

Расчёт GPU-часов: формула и проверка

Для оценки вычислений работает стандартная формула: полные затраты примерно равны 6 × N × D, где N — число параметров, D — число обработанных токенов, а шестёрка учитывает прямой и обратный проход. Считаем наш пример: 7 миллиардов параметров × 640 миллионов токенов × 6 = 2,7 × 10^19 операций с плавающей точкой на одну эпоху.

Теперь переводим в часы. H100 даёт около 990 TFLOPS в BF16 на бумаге, но реальная утилизация на мультимодальном обучении — 35–45 %, то есть примерно 400 TFLOPS, или 4 × 10^14 операций в секунду. Делим: 2,7 × 10^19 / 4 × 10^14 ≈ 67 500 секунд, около 19 GPU-часов на эпоху. За 20 эпох получается примерно 375 GPU-часов — это и есть источник диапазона 150–500 в таблице сценариев.

На узле из восьми H100 это 375 / 8 ≈ 47 часов, то есть двое суток. Полное дообучение той же модели на вдвое большем датасете обходится примерно вчетверо дороже — больше токенов и ниже эффективность из-за шардинга, — отсюда диапазон 800–3 000 GPU-часов и срок от четырёх суток до двух недель на одном узле.

Для 70B масштабируем: в десять раз больше параметров и, как правило, впятеро больше данных дают 1,35 × 10^21 операций на эпоху-эквивалент, то есть около 940 GPU-часов за проход и 15–40 тысяч GPU-часов за полный цикл обучения. На парке из 64 карт H100, который выдаёт 1 536 GPU-часов в сутки, это 10–26 суток непрерывного счёта — при условии, что сеть и подача данных не станут узким местом.

Честные оговорки к этим числам. Формула 6ND — оценка порядка величины, она не учитывает затраты визуального энкодера отдельно от языковой части, накладные расходы шардинга и время на валидацию. Утилизация 35–45 % оптимистична для первой попытки: на неоптимизированном конвейере легко получить 20 %, и тогда все сроки удваиваются. И ни одна из этих цифр не включает время на сбор данных, которое в реальных проектах обычно превышает время обучения.

Как подобрать конфигурацию под свою задачу

Порядок действий простой. Сначала определите режим: LoRA или полное обучение — это решение меняет требования в десять раз. Затем посчитайте память по правилу 16 байт на параметр (или 2 байта, если базовые веса заморожены) и получите минимальное число карт. Затем оцените токены по формуле из раздела о данных и прогоните их через 6ND, чтобы получить GPU-часы. И только после этого умножайте на цену карты или GPU-часа.

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

Ключевой параметр выбора для VLA — объём памяти карты, а не пиковые флопсы. Разница между 80 и 141 ГБ (H100 против H200) определяет, поместится ли модель без шардинга, а шардинг стоит и производительности, и сложности. Если считаете полное обучение крупной модели, смотрите ещё и на межсоединение: без быстрой сети между узлами масштабирование выше шестнадцати карт начинает буксовать. Разница режимов подробно разобрана в гайде обучение или инференс: как выбрать GPU, а лобовое сравнение флагманов — в материале H100 против H200 и B200.

И последнее по порядку, первое по важности для бюджета: обучение VLA — это волны, а не постоянная загрузка. Между итерациями идёт сбор и разметка данных, и купленный кластер в это время простаивает. Под такой профиль аренда вычислительных мощностей часто оказывается дешевле владения, а покупка начинает выигрывать при устойчивой загрузке выше примерно 60–70 % — эту точку удобно проверить на своих числах в гайде о покупке и аренде.