Омнимодель для Алисы AI: как нам удалось подружить VLM и LLM

Ещё недавно Алиса отвечала на текст и на картинку будто двумя разными голосами. Под капотом и правда жили две генеративные модели: текстовая LLM и визуальная VLM, а между ними — стена из непрозрачного роутинга, разных форматов ответов и разной вёрстки. 

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

Меня зовут Алексей Григорьев, я представляю большую команду разработки омнимодели Яндекса. Вместе с моим коллегой Данилой Кашиным я расскажу про все технические грабли не со стороны наблюдателя, а как их непосредственный собиратель. Но рассказывать я буду с акцентом не на красивом замысле, а на самой болезненной части — алайнменте.

Предпосылки к объединению модальностей

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

Что такое мультимодальность и омни. Мультимодальная модель принимает на вход и отдаёт на выходе разные типы данных — текст, картинки, видео, речь. Но омни — это не просто «LLM, которую научили смотреть на картинки»: в такой модели разные модальности живут нативно, в одном наборе весов, а не «приклеены» отдельным энкодером.

Тренд на объединение. В 2025 году весь опенсорс увлечённо мерджил генеративные модели: Qwen‑Omni сводил LLM/ASR/TTS, Transfusion и Mercury — LLM с диффузиями, Qwen‑Image объединял генерацию и редактирование картинок, а Qwen 3.5 замахнулся на нативную мультимодальность из коробки. Где‑то выходила настоящая синергия, где‑то — откровенно странно. О проприетарных GPT и Gemini известно мало, и мнения о том, насколько они «честно омни» внутри, расходятся.

Омни — это хорошо. Здесь аргументов несколько.

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

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

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

• Эмерджентные свойства. У совместно обученной модели появляются навыки, которых не было ни у текстовой, ни у визуальной модели по отдельности, — например, рассуждение о картинке текстовыми приёмами. 

• Вера в The Bitter Lesson — тренд, который раз за разом наказывает тех, кто ставит на ручные эвристики против масштаба и общих архитектур. 

Подробнее о предпосылках и мотивации перехода на омни мы уже рассказывали на Saturday ML Party.

Омни — это тяжело. Технических граблей здесь, конечно, много, но главная сложность возникает ещё до первой строчки кода, и она организационная: за LLM и VLM отвечают разные команды разработки со своими процессами и привычками, а теперь все они должны буквально заговорить на одном языке. 

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

Тем не менее мы взялись за эту глобальную работу. И сейчас можно с полной уверенностью сказать, что, несмотря на все трудности, игра стоила свеч. Дальше я расскажу, как мы шаг за шагом приближались к омнимодели в Алисе AI.

Рецепт омни: почему он последовательный

Ещё полгода назад существовал прототип омнимодели, без мультимодальности в первой стадии претрейна и RL. По сути, это была хорошая заготовка к текущему релизу: SoTA‑метрики по LLM при компромиссном качестве VLM, которое достигалось из‑за отсутствия картинок на стадиях претрейна и RL. 

Раньше пайплайны расходились сразу после первой стадии претрейна: у LLM был свой претрейн, свой SFT, свой RL, у VLM — свои (про VLM‑претрейн мы рассказывали на прошлогодней PML). Две независимые ветки, две команды, две картины мира. 

Новый замысел выпрямил эту вилку в одну цепочку:

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

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

Омнипретрейн

Претрейн — это фундамент: именно на нём модель набирает базовые способности, и всё, что заложено здесь, потом определяет её поведение на всех следующих стадиях. Поэтому здесь вопрос был не «как дообучить готовую текстовую модель смотреть на картинки», а «как с самого фундамента растить модель, которая одинаково уверенно работает и с текстами, и с изображениями».

Отсюда два жёстких ограничения:

• Визуальную модальность нужно было завести во все стадии обучения, а не добавлять отдельным шагом в конце (иначе картинки так и остались бы надстройкой над текстовой моделью, а не её родной частью). 

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

Визуальную модальность мы учили с нуля, а не наследовали от готовой опенсорс‑реализации VLM.

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

Вернуться к этой задаче помог переход на MoE‑архитектуру. Возможно, её дополнительная ёмкость дала модели больше пространства для размещения сигналов разных модальностей. У нас даже появилась гипотеза о частичной специализации экспертов, но ярко выраженного разделения на «текстовых» и «визуальных» экспертов мы не увидели. Поэтому нельзя сказать, что MoE автоматически решает проблему мультимодальности. Однако именно на этой архитектуре нам впервые удалось совместить текст и изображения без значимой потери текстового качества.

Теперь поговорим о практических вызовах, которые встретились нам на пути к омнипретрейну.

Вызов I: научить разные команды воспроизводить одно и то же обучение

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

Это сложнее, чем кажется: модели, датасеты и сами метрики постоянно меняются. Пока одна команда завершает эксперимент, другая может обновить бенчмарк, третья — поменять датасет, а четвёртая — перенести обучение на новый код. Поэтому нам понадобилась единая система претрейн‑ и алайнмент‑метрик, которая позволяла бы заранее оценивать качество будущего релиза. При оценке успешности эксперимента мы смотрели на три сотни градусников качества модели (бенчмарков)!

Проверять каждую гипотезу полным обучением слишком дорого, поэтому мы учились моделировать финальный результат на меньших экспериментах: последовательно увеличивали объём вычислений, данных и размер модели и смотрели, сохраняется ли эффект. Это не классические scaling laws для обучения с нуля, а способ проверить, переживёт ли найденное улучшение масштабирование.

Вызов II: построить инфраструктуру, на которой можно экспериментировать

Исторически VLM‑релизы у нас строились поверх готовых LLM. В омни изображения должны были попасть непосредственно в претрейн — ещё до того, как его сетапы окончательно сформировались.

Инфраструктура к этому не была готова, и разрыв пришлось закрывать в темпе «пятилетку — в четыре года». В частности, потребовалось совместить мультимодальное обучение с context parallel, tensor parallel и sequence parallel в MoE‑архитектуре. Прежде чем проверять содержательные гипотезы о данных и качестве, нужно было добиться, чтобы такие обучения в принципе стабильно запускались.

Вызов III: понять, что хорошая VLM и хорошая омнимодель требуют разных данных

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

В VLM можно оптимизировать данные прежде всего под работу с изображениями, потому что текстовая основа уже приехала из готовой LLM. В омни каждая часть датасета влияет на обе модальности. Вместо условных N визуальных метрик приходится оптимизировать 2N: каждый выигрыш на изображениях проверять на отсутствие деградации текста.

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

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

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

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

Омниалайнмент

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

Это не про лень и не про плохое планирование, а про природу больших совместных релизов: чем больше модальностей, команд и метрик надо синхронизировать, тем дольше всё «варится» до состояния, которое не стыдно катить.

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

Этап I — стенды алайнмента

Первый этап был про фундамент. До него наработки по выравниванию визуальной модели под продукт — то, что мы называем VLM‑алайнментом (SFT‑ и RL‑дообучение VLM после претрейна) — жили в разрозненных сетапах. У каждой задачи была своя конфигурация обучения — данные, гиперпараметры, пайплайн. Их надо было свести воедино, перевести на свежий омнипретрейн и собрать удобный стенд — экспериментальную площадку на модели поменьше, где такие сетапы можно быстро и дёшево прогонять, прежде чем катить на большую модель.

Что получилось уже здесь: заметный рост на геометрии — +5 п. п. относительно прода, при этом VLM‑алайнмент остался «серым» по текстовым метрикам, то есть новые наработки в мультимодальности не привели к статзначимой деградации текстовых способностей модели. Это принципиально важно: одно из главных требований к омни — не улучшать одну модальность ценой другой.

Итог этапа был осязаемым: собранный стенд поехал в апрельском релизе решателя учебных задач в Alice AI — это сценарий, когда пользователь присылает фото задачи, например по геометрии или математике, а модель разбирает решение по шагам. Релиз дал статзначимо зелёный A/B — прокрас по SPU (sessions per user) Alice AI VLM. И это было уже не первое подтверждение того, что мы копаем в правильную сторону, а не пишем в стол: ещё в рассказе про октябрьский релиз Alice AI LLM мы отмечали, что текстовый RL чрезвычайно полезен для мультимодальной модели. 

Этап II — улучшение VLM‑алайнмента

Дальше нужно было на собранном стенде вырастить VLM‑сигнал, снова не навредив текстовым метрикам. Мы заводили VLM RL сразу по нескольким направлениям — и у каждого была своя природа сигнала.

• Общая полезность — «умность» ответов, подтверждённость картинками и ссылками на источники. Верифицируемого сигнала тут нет, это RLHF: награду выдаёт обученная на асессорских предпочтениях реворд‑модель.

• Образование — геометрия, визуальная математика, генерация графиков. Здесь работает RLVR (RL with verifiable rewards): ответ модели можно проверить автоматически — сверить с эталоном, распарсить численный результат. Реворд бинарный/пороговый — за корректность. В основном мы использовали библиотеку Math‑Verify, но были и эксперименты с LLMaJ/VLMaJ (LLM/VLM как судья), в которых реворд был получен от отдельной модели‑оценщика.

• Базовые навыки — та же общая умность и OCR. Например, OCR снова верифицируемый (сверка распознанного текста с эталоном), здесь относительно просто составить набор тривиальных правил, которые лягут в основу реворда: exact match / CER / корректность latex.

Алгоритм RL мы долго не выбирали: взяли GSPO, который уже стоял в LLM‑сетапе RL. Пробовать альтернативы было некогда — сроки поджимали, поэтому опирались на то, что уже работало и было отлажено на текстовом сетапе алайнмента, и вкладывались не в перебор алгоритмов, а в дизайн ревордов и данные. 

За несколько недель мы прогнали множество RL‑экспериментов, удачных и неудачных. И, пожалуй, главный актив, который остаётся после такой гонки, — это не отдельные чекпойнты, а накопленная экспертиза: понимание, какие реворды заводятся, какие капризничают, где сигнал устойчив, а где рассыпается. Хорошо обученный RL — одна из главных причин удачного релиза.

Параллельно решалась инфраструктурная задача — как вообще учить RL для большой кастомной VLM в verl (опенсорс‑фреймворке для RL). Здесь пришлось выбирать между двумя компромиссами.

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

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

Этап III — VLM‑сведение: переносимость на большую модель

Вся предыдущая работа велась на сравнительно небольшом экспериментальном стенде. Настоящая проверка — это перенос на большую модель. И тут мы вышли на интересную асимметрию.

SFT переносится в основном хорошо. Большинство наработок доехали до большой модели. Что‑то с оговорками, а отдельные вещи ломались (например, часть text‑rich‑сценариев).

RL переносится по‑разному. Это ключевое наблюдение. Реворды с верифицируемым сигналом (RLVR) — визуальная математика, геометрия, OCR — смерджились сравнительно легко. А вот RLHF — обучение на асессорских предпочтениях — оказалось капризным: реворд‑модель, обученная на 32b, не переносилась на RL большой модели. Более сильная модель быстро находила слабые места реворда и начинала его «хакать» — набирать высокую награду, не улучшая, а то и ухудшая реальное качество ответов. Спасло то, что мы перешли на эмбеддинги (общий реворд для LLM и VLM сигналов), где текстовые данные стабилизировали обучение, но и после этого RLHF оставался неустойчивым по приростам.

Из этой асимметрии мы сделали три вывода.

• RLHF сложно завести в сжатые сроки.

• Переносить RLHF на большую модель тяжелее, чем RLVR. Всё дело в сигнале: реворд RLVR (сходится с эталоном или нет) хакнуть нельзя, поэтому такие реворды переезжают почти без изменений. А обучаемую реворд‑модель приходится переделывать под новый масштаб, чтобы избежать «хакинга».

• RLHF должен учиться в том же формате, что и в продукте, то есть с тем же шаблоном префикса (систем‑промпт, внешние контексты, разметка входа). Иначе то, что качается в обучении, не совпадает с тем, что видит пользователь.

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

Этап IV — омнисведение: собираем LLM и VLM вместе

Финальный этап — соединить актуальные визуальную и текстовую половины в одну модель. Само сведение — самая насыщенная инженерная часть всей истории: как мерджить экспертов актуальных чекпойнтов LLM и VLM в одну модель и что при этом происходит со стороны текстовой модели. Про это — и про метод сведения экспертов, и про наработки LLM — пожалуй, расскажем в отдельной статье. 

Верхнеуровнево картина такая: сводить пришлось каждую стадию алайнмента по отдельности — и SFT, и RL. Никакой магии здесь не было, только аккуратные аблейшены и кропотливая работа: на каждом шаге проверяли, что приросты одной половины не оборачиваются просадкой другой. Мы собрали десятки релиз‑кандидатов — от красных по VLM‑ и LLM‑метрикам до «всех оттенков серого», из которых несколько лучших уехали в A/B. И у самых удачных из них проступало то, ради чего всё и затевалось: две половинки модели не просто переставали мешать друг другу, а начинали друг друга усиливать в самых неожиданных местах. Но об этом — в следующем разделе (про синергию).

Напоследок расскажу небольшой фан‑факт про грабли, которые вылезли уже на финальном этапе сведения омни‑RL. У Alice AI VLM недавно появился полезный навык — подтверждать ответ картинкой и ссылкой на источник. Сейчас он работает только за счёт SFT‑данных, но в RL его не было — и после обновления омни‑RL он предсказуемо «размывался». В релизе ситуацию спасли удачно подобранным систем‑промптом, но это все же костыль, а не решение.

Отсюда и вырос самый тонкий вывод из уроков алайнмента: в RL должны присутствовать все важные для продукта сигналы.

Что дала омни: синергия и её пределы

Ради чего всё это затевалось? Ради синергии, конечно же. И она действительно проявилась.

Главное — общий стиль. Больше нет «слома» характера на стыке текста и картинки: модель говорит одинаково, в единой манере, вне зависимости от того, есть ли на входе изображение. Визуальная половина переняла у текстовой проактивность и общение на «ты», а текстовая перестала отнекиваться, что «не умеет работать с картинками». 

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

Синергия синергией, но в какой‑то момент нужно честно поставить модель рядом с конкурентами и посмотреть, кто кого. Мы перешли к замерам side‑by‑side: асессоры вслепую сравнивали пары ответов по сложной инструкции на корзине запросов, которая напоминает наш реальный мультимодальный поток. Так что тут мы использовали не абстрактные бенчмарки, а срез, максимально близкий к тому, с чем модель встречается в проде. Мы прогнали через него финального кандидата против нашей же версии полугодичной давности и других внешних моделей — картина получилась отрезвляюще мотивирующей.

Против собственной февральской версии рост был уверенный — 57% против 43% в пользу омнимодели. За полугодие мы действительно сдвинулись, а не потоптались на месте. 

Дальше — внешние. Qwen 3.5 397B в режиме no‑thinking обыгрываем с заметным отрывом — 59% против 41% (причём ещё в апреле здесь был серый паритет). То есть там, где пару релизов назад мы шли вровень, теперь мы вырвались вперёд.

А вот дальше начинается зона роста, и прятать её нет смысла. Против Gemini 3 Flash и Google AI Mode мы пока серые. Против сильнейших конфигураций — Qwen 3.5 в режиме thinking (47% против 53%) и флагманского Gemini 3.1 Pro (42% против 58%) — не разгромно, но уступаем. И это, пожалуй, самый полезный замер из всех: он не даёт расслабиться и показывает нам путь, куда бежать в следующих релизах.

Приятно, что даже здесь видна динамика: против того же Qwen в режиме thinking апрельский разрыв был куда больше. Омни свела всё в единую модель. Теперь задача — превратить это в качество, которое выигрывает у лучших не «в среднем по больнице», а «в лоб».

Выводы

Полгода работы с алайнментом омнимодели свелись к нескольким важным мыслям:

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

• Обучение омни — это последовательный алгоритм, а не «влить всё сразу». Претрейн → SFT → RL, и порядок имеет значение.

• RL — главная точка роста мультимодальных моделей. Омни‑RL позволяет декомпозировать сигнал на независимые аспекты и качать их по отдельности — при условии, что все важные для прода сигналы в нём присутствуют.

• RLVR и RLHF переносятся по‑разному. Проверяемые реворды доезжают до большой модели легко, обучение на предпочтениях — тяжело и неустойчиво. Планируйте сроки с учётом этого.

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

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