Сегодня мы делимся техрепортом, в котором разобран полный цикл создания нового семейства моделей Alice AI: базовая текстовая Alice AI LLM и специализированная LLM Search, мультимодальная Alice AI VLM и картиночная Alice AI ART. 

В части про Alice AI LLM расскажем, как сделали упор в Alignment на RL и Reward Modeling: мы минимизируем число разрозненных RL-стадий, собирая «общий RL». Вместо хрупкого «суперсигнала» используем аспектную формулировку качества и агрегируем её в целевую функцию, чтобы изменения критериев не требовали пересборки всей разметки. В главе про Alice AI LLM Search расскажем про многократные последовательные походы в Поиск с последующей фильтрацией/ранжированием источников. А также о том, как готовим ответы с использованием документов разной модальности (веб-документы, картинки, видео, гео).

Чтобы «вывезти» MoE-модель на сотни миллиардов параметров, мы целенаправленно сняли инфраструктурные ограничения обучения и инференса: в обучении используется YaFSDP (которую мы выложили в опенсорс) и собственная библиотека коллективных коммуникаций YCCL. В прод-инференсе мы работаем под SLA (avg TPOT ≤ 70 ms, p95 TTFT ≤ 2 s) и достигаем их комбинацией TP Attention/EP FFN, KV cache reuse, FP8 w8a8kv8 (в т. ч. сжатие KV cache ~3,05→~1,52 GB) и спекулятивного декодинга EAGLE‑3, что в сумме даёт 5.8× ускорение относительно BF16 (и 1,32× относительно лучшего open-source). Параллельно для Alice AI VLM нарастили в 1,5 раза объём претрейна, контекст до 32k и обновили OCR-датасет; VLM-генератор работает «из коробки», а для математики/геометрии выделен специализированный VLM‑решатель. В пайплайне Alice AI ART повышение релевантности к промпту начинается с диагностики смещений в датасете с помощью VLM и последующей адресной коррекции обнаруженных проблем.

Недавно все эти модели и решения легли в основу нашего нового ИИ-ассистента, и уже к ноябрю, согласно исследованию Mediascope, Алиса AI вышла на первое место по используемости среди россиян (14,3%), обойдя ранее доминировавший DeepSeek (9,4%). Кроме того, модель Alice AI LLM теперь доступна и для разработки собственных AI-решений на платформе Yandex AI Studio.

Содержание

Alice AI LLM
Архитектура модели и инициализация обучения
Этап Pretrain: подход и результаты
Alignment: фокусируемся на RL
Замеры

Alice AI LLM Search
Разметки
Модель поиска
Модель генерации
Замеры

Инфраструктура обучения Alice AI LLM
YaFSDP + YCCL
Blockwise FP8 и MoE
Critical batch size
Context Parallelism
Итоги

Инфраструктура инференса Alice AI LLM
Системные оптимизации
Чем больше sparsity, тем больше ответственность батч
Квантизация
EAGLE3
Итоги

Alice AI VLM
Инфраструктура Фотоинпута
Обучение Alice AI VLM
Pretrain
Alignment
VLM-решатель

Alice AI ART
Finetune
Рефразер

---

Alice AI LLM

Рассказывают Николай Скачков и Андрей Бут @andbout

Архитектура модели и инициализация обучения

Alice AI LLM — наша модель, которая прошла полный цикл обучения на данных и инфраструктуре Яндекса. Её обучение было инициировано весами открытой модели — этот факт многие путают с обычным дообучением моделей, поэтому расскажем чуть подробнее. Дообучение сторонних моделей и инициализация обучения собственной модели весами открытой — два совершенно разных процесса.

При дообучении внешней модели её поведение лишь немного корректируется на ограниченном объёме данных с невысоким потреблением вычислительных ресурсов (стадии SFT или RL). При этом основные возможности и особенности модели определяются именно исходными весами. Такой путь нам не подходит.

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

Полный цикл обучения нашей модели Alice AI LLM, инициализированной весами Qwen3-235B, занимает на порядок меньше времени, чем если бы мы инициализировали её случайными весами. Это позволяет нам провести в разы больше экспериментов.

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

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

Этап Pretrain: подход и результаты

Обучение нашей модели после инициализации состоит из нескольких этапов:

• обучение подходящего для русского языка токенизатора;

• обучение эмбеддингов;

• Pretrain на большом объёме текстовых данных;

• двухэтапный Midtrain, в ходе которого модель обучается на высококачественных данных для разных срезов, а также выучивает длинный контекст;

• Alignment (но об этом этапе поговорим уже в следующей главе).

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

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

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

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

Отбор наиболее полезных источников является одной из ключевых задач при формировании претрейн-датасета. Поскольку новый фактологический бенчмарк HardQA не опирался на фиксированный набор документов, нам удалось отдельно проанализировать качество фильтрации документов, полезных для развития фактологических знаний. Анализ показал, что традиционные критерии фильтрации веб-данных плохо применимы к отбору фактологической информации и приводят к потере от 20 до 40% потенциально полезных данных. Для повышения качества отбора мы использовали предобученные LLM большого размера, а также небольшой классификатор, обученный на их основе. При этом удалось сократить размер датасета за счёт дополнительной фильтрации документов, содержащих избыточно общие знания, которые модель и так усваивает из широкого круга базовых источников.

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

Использование вышеописанных техник позволило получить от 4 до 7% роста доли верных ответов по внутреннему фактологическому бенчмарку на размере модели Alice AI LLM и превзойти такие открытые модели, как DeepSeek V3.1 и модели линейки Qwen3.

Образование
Для того чтобы улучшить знания модели на более узком срезе школьных предметов, мы с помощью AI-тренеров составили реестр хостов с обучающей информацией по ключевым школьным предметам. Работа со специализированными доменами потребовала создания специализированных классификаторов, которые позволили нам более точечно найти и распарсить обучающие задания и решения, а также теоретическую учебную информацию. Благодаря этому, новая модель показала себя лучше по метрикам школьных предметов, состоящим из тестов и задач, характерных для школьных занятий. Здесь и далее будем ссылаться на них как на бенчмарки образования.

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

1. учимся генерировать инструкции на заданный срез задач (извлечение информации или переформулировка);

2. обучение специальной модели, которая хорошо справляется с решением данной узкой задачи;

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

Контекст
Для ускорения обучения на претрейн-стадии необходимо уменьшать длину контекста. В наших обучениях на стадии претрейна используется длина контекста 8k. Из-за этого за время обучения качество на более длинном контексте очень сильно деградирует, несмотря на то, что в качестве инициализации использовался Qwen-235B. Например, качество на некоторых бенчмарках 32к после стадии Pretrain от двух до пяти раз хуже, чем после Midtrain.

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

Кроме этого, полезным оказалось увеличивать длину видимого при обучении контекста. Так, в экспериментах при обучении с контекстом длиной 64к качество на некоторых ключевых бенчмарках длины 32к выросло от 2% до 4% по сравнению с обучением с контекстом 32к. Хотя многие игроки на рынке сильно поднимают долю длинных данных в обучении, мы обнаружили, что чрезмерное завышение убивает остальные домены. При этом небольшое увеличение улучшает длинный контекст и не влияет на остальное.

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

Код и математика
Математика и код являются одними из наиболее востребованных навыков LLM среди пользователей, особенно среди профессиональных диалогов. Поэтому мы уделяем особое внимание развитию кодовых способностей Алисы.

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

В коде был сделан упор на данные, которые содержат решения алгоритмических задач или ответы на реальные пользовательские запросы. Не всегда эти данные имеют удобный instruct-вид, который мог бы использоваться на этапе SFT, зато они имеют большие объёмы, что помогает модели в том или ином виде лучше подготовиться к решению реальных задач. На этом этапе мы смогли получить +4.5 п.п. на LiveCodeBench.

В математике для релиза Alice AI LLM, кроме роста общепринятых бенчмарков по математике, мы ставили себе цель улучшиться на срезе школьных задач. Для этого в Midtrain мы продолжили расширение корпуса за счёт модифицированного подхода из OpenMathInstruct-2 для генерации синтетических данных по разделам математики, таким как геометрия. Финальные данные перед добавлением в корпус фильтровались PRM-моделью и по согласованности ответов. В экспериментах увеличение количества синтетики давало +2-3% на бенчмарке MATH-CoT.

Alignment: фокусируемся на RL

Процесс Alignment включает в себя несколько стадий. На первой стадии, которая называется SFT (Supervised Fine-Tuning), модель обучается на парах «запрос — ответ». На следующей стадии RLHF модель обучается выдавать более качественные ответы, самостоятельно генерируя ответы на запросы и получая обратную связь от reward-модели в режиме реального времени, что позволяет непрерывно улучшать политику на основе собственного опыта. Ранее мы писали подробнее о процессе тут.

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

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

Аспектная разметка
Для начала давайте вспомним, что ревордом в контексте RLHF называется функция R(запрос, ответ), которая оценивает числом качество ответа на данный вопрос.

Если говорить про качество ответа, то таких ревордов может быть множество, каждый из которых оценивает ответ с разных позиций, например:

• качество языка;

• корректность логики;

• оформление ответа (таблицы, жирный текст, заголовки);

• общая полезность ответа (смог ли задающий вопрос решить свою проблему).

А также всевозможные комбинации этих и других критериев.

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

Допустим, что для себя мы решили, что на первом месте для нас находится полезность, затем качество языка и так далее. Мы написали людям детальную инструкцию для оценки ответов в соответствии с этими правилами. Собрали разметку, достаточную для обучения классификатора, и обучили сам классификатор.

Классическая схема, однако она таит в себе опасность — представьте теперь, что требования к модели изменились, например, после A/B-тестирования стало понятно, что модели не хватает одного аспекта и его значимость стоит увеличить. Классическая схема начиналась с выбора весов аспектов, и все последующие шаги, включая разметку, зависели от этого решения. В результате при таком простом и, скорее всего, периодическом изменении ТЗ потребовалось переделать длительную и дорогостоящую разметку.

Для того чтобы эту проблему избежать, лучше формулировать реворд в аспектной форме: R(запрос, ответ) = F(R_полезность(запрос, ответ), …, R_красивость(запрос, ответ)), где R_полезность, …, R_красивость – «аспектные» реворды, которые не затрагивают частые изменения в ТЗ – не так часто мы реформулируем, что такое полезность, красивость или длина ответа. А F(...) в свою очередь будет правилом, по которому из значений аспектных ревордов будет оцениваться общее качество ответа.

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

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

На момент релиза Alice AI мы использовали несколько аспектных ревордов, включающих:

• полезность;

• красивость;

• фактологичность;

• b2c;

• b2b;

• антигаллюцинации;

• гуманитарная.

Смотря на приведенные выше головы ревордов, можно заметить, что они не все «аспектные». Например, полезность, красивость и фактчек явно оценивают разные аспекты качества ответа. В то время как b2c и b2b — это скорее про специальные срезы данных, которые были собраны в прошлых версиях моделей. Нам ещё предстоит порефлексировать, как правильно, а пока давайте разберемся, откуда возникла идея аспектных ревордов.

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

OpenAI в своей фундаментальной статье про RLHF описывала процесс разметки следующим образом: сгенерируйте двумя моделями ответы и наймите людей эти ответы сравнить. Для аспектного реворда такая схема несёт некоторую опасность (классическая тоже, только менее выраженную).

Давайте сначала взглянем на пример правильной разметки. На нем мы сгенерировали ответы, в которых равномерно распределены критерии полезности и фактологичности, и равномерно распределены пары, которые мы ранжируем при помощи разметчиков. Чтобы не загромождать рисунок, мы без ограничения общности проведем анализ лишь обучения реворда полезности. Выученный нами аспектный реворд полезности на таком датасете совпадает с идеальным и зависит только от настоящей полезности.

Теперь перенесем наш взгляд на неправильный пример разметки, где мы сгенерировали ответы, например, моделью, в которой априори заложен размен полезности на фактологичность. Если из такого датасета мы равномерно просэмплируем пары для разметчиков полезности, в итоге большинство ранжирований будут в одном направлении, и обученный реворд полезности на самом деле будет моделировать R = R_настоящая_полезность - R_настоящая_фактологичность, несмотря на то, что сам процесс разметки построен абсолютно верно.

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

Значит ли это, что если для всех пар метрик доля в районе ½, то датасет сбалансированный? Конечно, нет, но это хороший инструмент для обнаружения проблемы.

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

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

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

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

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

Выбор класса линейных функций не единственный правильный, но обладает двумя существенными преимуществами:

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

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

Как подобрать веса? Можно выбрать их «на глазок» из соображений потребностей бизнеса. Но намного правильнее и умнее подобрать их по данным. Решать будем ту же самую задачу, что решается при обучении самих RM:

Читатель, глубоко знакомый с классическим машинным обучением, может заметить, что функционал выпуклый. Т. е. задача оптимизации имеет одно решение, которое несложно найти, применив методы оптимизации второго порядка (L-BFGS, например). Для подбора весов также нужны данные — мы используем отложенный репрезентативный набор данных, составленный из различных срезов.

Всё, реворд обучен, и… он даёт субоптимальные результаты для RL. Давайте разберёмся, почему.

Дело в том, что мы оптимизируем аспекты обучаемой модели не напрямую, а через изменение весов модели, а для неё, в свою очередь, улучшить один из аспектов может оказаться намного проще, чем остальные. Например, улучшить оформление ответа несравненно проще, чем сделать его полезнее. Поэтому, когда мы выбрали по нашему отложенному датасету оптимальное с точки зрения ТЗ направление улучшения аспектов w, само обучение будет проходить по неоптимальному, смещённому вектору – Kw.

Чтобы правильно обучить RL, следует запускать обучение с поправкой на сложность аспектов u = K^-1 w. Тут матрица K^-1 имеет простую интерпретацию – она поднимает вес сложным аспектам, чтобы RL уделял им больше внимания, и уменьшает вес простым, чтобы не переобучаться под них.

С матрицей К, однако, есть несколько серьёзных проблем:

• Искушённый читатель заметит, что K – базируется на NTK, а вопрос его стационарности на практике открыт. Для одних экспериментов K будет меняться во время обучения, в других нет. Поэтому поправка u = K^-1 w не всегда будет иметь ожидаемый эффект.

• Считать эту матрицу на практике довольно проблемно. Зато оценить в силу малой размерности очень просто.

• До этого момента мы игнорировали тот факт, что не все комбинации метрик могут быть реализуемы моделью. Если такие ограничения имеют место быть, то траектории, по которым происходит оптимизация, могут стать кривыми, сделав наш анализ K бесполезным. На практике RLHF эти ограничения обычно существуют только сверху (реворд перестает расти к концу обучения) и на форму траектории почти не влияют.

Замеры

Итак, модель обучена, правда ли, что все эти манипуляции стоили затраченных сил? Пусть нас рассудят замеры.

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

Мы уделили особое внимание росту качества нашей модели на задачах образования. И видим рост качества на бенчмарках образования:

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

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

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

Alice AI LLM Search

Рассказывает Александр Юшкевич

Alice AI LLM Search — это система LLM, объединяющая технологии Поиска и Alice AI. Поиск расширяет и актуализирует знания модели, а также позволяет использовать различные дополнительные данные. С представленным обновлением мы значительно улучшили и расширили поисковые возможности Alice AI.

Во-первых, система научилась делать многократные последовательные походы в Поиск. Это позволяет глубже исследовать тему и находить ответы на более сложные запросы.

Во-вторых, система научилась получать и эффективно использовать в ответе не только текстовые веб-документы, но и данные других модальностей — картинок, видео и гео-объектов.

За счет этого пользователь может эффективнее и быстрее решать свои задачи.

Чтобы хорошо ответить на такой запрос, нужно собрать информацию о локации, найти фото и геоточки важных объектов, отобрать из них наиболее релевантные и построить ответ.

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

• Планер — модель поиска, собирающая информацию, — некоторый «агент», работающий с интернетом и различными API.

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

• Генератор — модель генерации ответа, которая пишет ответ, структурирует информацию, делает выводы, вставляет где нужно изображения, видео, гео-объекты и т. д.

Разметки

Ключ к успешному LLM-проекту — разметки. В проекте мы уделяем много внимания качеству и объёмам разметок, комбинируем человеческую разметку и LLM-judge подходы. Используемую разметку можно разбить на две категории:

• Оценка качества ответов — она позволяет оценивать улучшения и ухудшения, задает «вектор обучения» для RL.

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

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

Наша модель сильно расширяла свойства обычной LLM-модели, например, должна уместно использовать картинки, или ходить в поиск несколько раз, или, наоборот, использовать собственные знания при наличии высокой уверенности. Поначалу мы пытались уместить их в два сигнала, по аналогии с тем, как оно было устроено раньше. Можно сказать, что мы двигались по пути создания единого суперсигнала, который объединял свойства текста, её умность, достоверность, проактивность, уместность и качество картинок, видео и т. д. Но довольно быстро стало очевидно, что создание такого суперсигнала очень замедляет скорость работы: один и тот же пример нужно оценить по разным свойствам и каким-то образом агрегировать каждое из свойств для идеального размена. При изменении критерия оценки какого-то из аспектов весь собранный баланс разрушался, и нужно было начинать сначала.

Чтобы избежать этого, мы пошли по пути параллельности: сохранили главный сигнал SbS — качество текста (его умность), но начали создавать сигналы на отдельные аспекты качества ответа, например, с точки зрения уместности и правильного использования картинок в ответе.

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

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

Конечно, LLM-judge все ещё уступает людям, по нашим замерам точность хороших разметчиков на 5-10 п. п. выше, чем у моделей, но этого достаточно, чтобы развивать проект и масштабировать разработку.

Для более сложных аспектов, например текста, мы продолжили использовать разметку асессоров и AI-тренеров, снабдив их LLM-хинтами — различными моделями, обученными на задачу поиска проблем и несостыковок в ответах. В этой части проекта мы используем классическую схему с SbS-разметкой, где сравниваем пару ответов по критериям общетекстового качества. После этого мы обучаем pointwise reward на эту разметку, который используем для RL и оценки различных экспериментов.

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

Создание базовых ответов
В качестве инициализации наших моделей мы используем Pretrain-версию Alice AI LLM. По нашим экспериментам, это наиболее эффективный процесс — общий Pretrain и отдельный Alignment для Alice AI LLM Search. Отдельный процесс Alignment позволяет нам распараллелить работу над проектом, а также эффективнее растить качество на крайне специализированном срезе, поддерживая высокую достоверность и улучшая в модели способности RAG. А чтобы собрать Alignment, нужно начать с SFT, т. е. нам нужны «инициализирующие ответы» для обучения.

Для получения инициализирующих ответов мы тоже активно используем комбинацию LLM и людей: в первую очередь мы используем подход «улучшения ответов». Это означает, что AI-тренеры улучшают ответы, а не создают их с нуля. Это экономит время и позволяет точечно работать над проблемными ответами.

Более подробно процесс выглядит так:

• мы берем ответ текущего пайплайна и по ревордам находим «плохие» ответы;

• следующим шагом мы просим AI-тренеров улучшить и переписать ответ;

• далее улучшенный ответ мы снова прогоняем через реворды и LLM-judge и проверяем, есть ли рост качества;

• проводим такие итерации до улучшения качества.

Такой процесс ускоряет получение качественного ответа с 8 часов до 2, что в конечном счёте конвертируется в лёрн большего размера.

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

К релизу мы собрали тысячи эталонных ответов, которые легли в основу нашего SFT, что дало нам очень хорошую инициализирующую точку для RL.

Модель поиска

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

Например, когда мы ищем рыбный ресторан возле станции метро «Смоленская», нам нужно сначала понять, какие есть объекты в этой области, а потом про каждый из них проверить, удовлетворяет ли он критериям пользователя.

Наиболее сложными аспектами этой модели является инит (первые «траектории») и RL.

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

Для получения инита мы используем смесь различных методов, объединяя их через rejection sampling-like подходы: тут есть и модели предыдущих версий проекта для простых запросов, промпты под конкретные срезы для множества более сложных сценариев, отдельные пайплайны под узкие срезы. Всё это объединяется через сэмплинг и мерж пула, позволяя модели получить «базовое представление» про паттерны поиска и дальше развивать их в RL.

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

С чем мы столкнулись:

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

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

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

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

Мы провели сотни экспериментов в поисках решений этих проблем и улучшений алгоритмов :)

В результате сейчас для получения наилучшего качества мы обучаем оффлайн RL (rejection sampling + DPO) с прунингом неэффективных веток, обрезая их через модель оценки промежуточного качества (реворд качества собранных источников). Такой подход очень похож на подход с Value Head в классическом алгоритме PPO, который оценивает промежуточные шаги в некотором пространстве действий.

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

Модель генерации

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

В прошлых итерациях поисковых LLM мы использовали многостадийную комбинацию методов CE RL (он же rejection sampling) и синтетический DPO. Такой метод позволял получать высокое качество, но имел существенный недостаток!

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

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

К сожалению, GRPO тоже не лишён особенностей:

• Он быстрее оверфитит реворды, это значит, что если ваш реворд имеет слабость, смещающую ответы, то GRPO найдет это. Особенно часто в этом месте стреляет длина, так как она во многих ревордах дает сдвиг в ту или иную сторону. С другой стороны, это является плюсом, так как после этого вы такое смещение исправляете и снова запускаете GRPO…

• Для него требуется хорошая инфраструктура, online RL по сути требует сервер, где сможет ходить в реворды (по сути тоже отдельные API), вызывать разные API-инструменты и т. д.

• Он более капризный: мы оптимизируем большую многокомпонентную формулу ревордов (суммарно там 18 (!) слагаемых и индикаторов), чтобы учесть разные аспекты качества, а сбалансировать такое непросто, и при попытке подобраться в самом GRPO мы получали взрывы модели.

• Некоторые запуски GRPO нестабильны с самого начала обучения, т. е. как бы мы ни упрощали формулу, модель все равно разваливалась. Эту нестабильность мы связывали с особенностями использования методов мержа в SFT (таких как Ties и Widen), и она сильно мешала :)

Мы обнаружили, что последние 2 проблемы можно решить, введя небольшую промежуточную стадию стабилизирующего rejection sampling обучения, причём она не только делала GRPO стабильнее на старте, но и задавала базовый вектор обучения — исходные веса для формулы оптимизации наших ревордов — а это решало проблему два :)

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

Этот релиз собрал большое число изменений Alice AI LLM Search, а впереди ещё большой ресёрч, новые умения моделей и рост «умности» ответов на более сложных запросах.

Замеры

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

Инфраструктура обучения Alice AI LLM

Рассказывает Михаил Хрущев @MichaelEk

Alice AI LLM — это MoE-модель. Типичный подход обучения с FSDP в MoE работает плохо: вычислений в MoE мало, GPU сложно нагрузить полностью из-за того, что всё обучение упирается в коммуникации.

Что делать? Как эффективно обучать модели таких размеров?

Есть 2 подхода:

1. Усиливать инфраструктуру: добавлять экспертный параллелизм, пайплайн-параллелизм. Это путь, по которому пошли многие игроки, вроде OpenAI, DeepSeek.

2. Менять соотношение времён коммуникаций и вычислений так, чтобы простой GPU был минимальным.

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

При обучении Alice AI мы исследовали и внедрили такие основные оптимизации:

1. YaFSDP + YCCL — наша альтернатива NCCL;

2. Blockwise FP8 — FP8 в духе DeepSeek v3;

3. различные оптимизации вокруг интеграции MoE и FP8;

4. исследование Critical Batch Size для MoE;

5. Context Parallelism.

YaFSDP + YCCL

При обучении больших моделей и при проведении экспериментов мы используем наш фреймворк YaFSDP. Важно заметить, что с момента релиза YaFSDP FSDP 2.0 сильно улучшился и ускорился, но в нём всё же есть один критический недостаток: он шардирует параметры независимо, перед коммуникациями требуется дополнительная операция копирования, которая достаточно дорогая в случае MoE и может замедлять обучение на 10-15%.

Обычно для коммуникаций в обучениях LLM используется NCCL. Но у него есть несколько недостатков:

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

  

• NCCL-коммуникации требуют дополнительную операцию копирования, которая занимает некоторое время.

• Reduce-scatter требуется делать в fp32, чтобы ошибка при вычислении по кольцу не стала слишком большой. В случае, если в кольце 1024 GPU, каждое итоговое значение операции — это результат последовательных 1024 сложений в пересылаемом типе, в bf16 ошибка становится огромной и ломает обучение модели.

• NCCL запускается на GPU и требует единицы SM (streaming multiprocessor) для коммуникаций. При неправильной настройке NCCL коммуникации могут полностью остановить матричные умножения (GEMM), так как они требуют все SM по умолчанию. Можно ограничить использование SM в GEMM, но это приведёт к их замедлению на единицы процентов.

Для решения этой задачи мы разработали свой инструмент: YCCL — Yet Another Collective Communication Library. За базу мы взяли алгоритм qgZ, который предлагался в статье ZeRO++ от DeepSpeed.

Идея подхода простая:

• Вместо ring-based коммуникаций мы делаем all2all-коммуникацию, которая пересылает от каждой GPU каждой соответствующий номеру получателя кусочек данных:

• Суммирование мы производим уже на GPU-получателе, что позволяет избежать ошибки и при пересылке в меньшем типе данных.

• Узким местом такой коммуникации будут сетевые пересылки между хостами. Для того, чтобы добиться максимальной пропускной способности, мы делим all2all на 2 стадии: intra- и inter-:

• Для того чтобы избежать дополнительных копирований, мы выделяем общие между YCCL и YaFSDP буферы.

• Все коммуникации контролируем с CPU.

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

Главные преимущества YCCL:

• масштабирование на тысячи GPU без потерь пропускной способности;

• reduce-scatter в bf16 — коммуникации в 2 раза дешевле;

• отсутствие дополнительных копирований;

• YCCL управляет коммуникациями с CPU, что позволяет освободить SM'ки для вычислений.

Blockwise FP8 и MoE

Для обучения мы используем FP8. Обучение в пониженной размерности позволя��т делать более быстрые матричные умножения, но может привести к дестабилизации обучения. Для стабильного обучения мы внесли Blockwise FP8, аналогичный тому, который использовался в DeepSeek v3, а также библиотеку DeepGEMM для одновременного подсчёта различных экспертов. Blockwise FP8 хорошо зарекомендовал себя в наших обучениях и по качеству не уступает BF16.

Текущая схема квантизации совпадает с предложенной DeepSeek:

В Blockwise-квантизации активации и промежуточные градиенты скалируются блоками 1x128, что позволяет минимизировать вред от выбросов. Веса квантуются блоками 128x128:

Квантизация позволяет сильно ускорить GEMM и коммуникации, но наивная реализация может не привести к ускорению: операции квантизации и деквантизации могут занимать до 30% времени матричных умножений. Поэтому число таких операций надо минимизировать.

Особенности нашей реализации MoE + FP8:

1. Округляем скейлы вверх до степеней двоек — это существенно повышает стабильность обучения.

2. Минимизируем число квантизаций/деквантизаций при помощи Triton-кернелов.

3. DeepGEMM для более быстрой работы с памятью требует, чтобы число токенов, которое идёт в каждого эксперта, делилось на 128. Это потребовало реализации permute с выравниванием входов до кратности 128.

4. Для того чтобы уменьшить объём хранимых активаций на слой, мы домножаем вероятности роутера прямо в кернеле SwiGLU. Иначе для подсчета градиентов в роутере необходимо хранить выходы MLP, которые нигде больше не используются.

5. Веса мы храним в FP8, поэтому можно удешевить all-gather коммуникации в 2 раза и собирать сразу FP8-тензоры.

Финальная схема:

Результаты внедрения FP8:

1. Обучение e2e ускорено на 30%.

2. All-gather коммуникации ускорены x2.

Critical batch size

В FSDP/YaFSDP на каждый шаг forward-backward модель нужно собрать только 2 раза. Поэтому имеет смысл за один шаг делать обучение на как можно большем числе токенов.

Но исследования (статья 1, статья 2) показывают: иногда при увеличении размера батча модель начинает сходиться к худшему оптимуму. Поэтому его нельзя растить бесконечно.

Critical batch size — оптимальный размер батча, он зависит от типа модели, от числа токенов в обучении, от оптимизатора. Ранее мы подбирали размер батча для Dense-моделей и остановились на значении в 1-4M токенов. Но в MoE каждый эксперт получает меньше токенов за один шаг, поэтому мы решили попробовать CBS переподобрать. Оказалось, что сходимость MoE не деградирует при в 4 раза большем размере батча. В наших обучениях мы используем батчи в 16M–32M токенов в зависимости от сценария.

Context Parallelism

Иногда возникает необходимость одну строку обрабатывать сразу в нескольких процессах. Зачем это нужно:

1. Можно обрабатывать строки в сотни тысяч токенов.

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

Для решения этой задачи есть 3 подхода:

1. Tensor parallelism + Sequence parallelism — объём хранимых активаций уменьшается в разы, но появляются дополнительные тяжелые коммуникации.

2. Алгоритмы из семейства RingAttention/ZigZag: бьём строки на процессы, перед attention синхронизируем только KV — единственную информацию, которую необходимо передавать между токенами.

3. Ulysses attention:

   1. Бьём строки между процессами.

   2. После вычисления QKV делаем all2all: теперь на каждом процессе присутствуют QKV всей строки, но только для части голов.

   3. Вычисляем Attention.

   4. Делаем all2all для того, чтобы на каждом процессе оказались выходы attention для всех токенов.

На данный момент мы остановились на Ulysses attention. У него есть существенные достоинства:

• Он очень простой в реализации, в том числе подходит и для мультимодальных сценариев.

• Коммуникации относительно дешёвые и не увеличиваются с числом процессов, на которые мы бьём строки, при том, что скорость сети не меняется.

• Все коммуникации можно перекрыть вычислениями в случае, если коммуникации проходят в быстрой сети.

Ulysses позволил нам провести Midtrain-стадию обучения и увеличить контекст с хорошим ускорением за счёт перебалансировки нагрузки между процессами.

Важно отметить, что Ulysses становится довольно дорогим при межхостовых коммуникациях, поэтому мы будём продолжать работу над улучшением алгоритмов Context Parallelism.

Итоги по ускорению

Мы уменьшили соотношение коммуникаций и вычислений следующими трюками:

1. YaFSDP + YCCL — в 2 раза быстрее reduce-scatter, идеальное масштабирование на большое число GPU.

2. FP8 в MoE: ускорение all-gather в 2 раза, ускорение e2e обучений x1.3.

3. CBS x4 — в 4 раза больше вычислений на forward-backward при том же числе активаций.

В итоге наша инфраструктура сейчас не упирается в сеть, и мы можем быстро учить модели со sparsity 1/32.

Итоговое ускорение по сравнению с сетапом expert parallelism + YaFSDP, которым мы пользовались полгода назад, — в 1,5 раза. Если брать сетап без экспертного параллелизма, то выигрыш во времени колоссальный — в 4 раза!

Инфраструктура инференса

Рассказывает Роман Горб @roman-gorb

Новое поколение моделей Alice AI показало значительный рост относительно предыдущего не только с точки зрения качества, но и с точки зрения сложности масштабирования во время инференса. Из-за своего размера и архитектуры флагманская модель добавила челленджи буквально в каждый инфраструктурный элемент пайплайна ускорения. Решение этих проблем потребовало иного подхода к реализации некоторых этапов обработки модели и внедрения нескольких важных оптимизаций в остальные.

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

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

• avg TPOT (time per output token) <= 70 ms. Такое ограничение при токенизации с нашим словарем соответствует средней скорости чтения у самых быстрых людей-читателей. Мы решили взять именно среднее как оценку, потому что абсолютные значения уже достаточно малы и скорость реакции человека не позволяет видеть разницу между квантильными оценками.

• p95 TTFT (time to first token) <= 2 sec. Это ограничение необходимо, чтобы не создавалось ощущение, что модель зависает на этапе обработки результатов поиска (95-й перцентиль здесь взят для стабильности). В конце оказалось, что мы уложились в это ограничение с кратным запасом.

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

• max input seqlen = 15k, avg input seqlen = 6k;

• max output seqlen = 2k, avg output seqlen = 0.5k.

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

Для реализации всех наших «хотелок» нам были доступны следующие вариации железных машинок:

• GPU с доступными >= 140 GB видеопамяти.

• Конфигурация на 8 карточек, т. е. cуммарно >= 1120 GB.

• Конфигурация на 4 карточки, т. е. cуммарно >= 560 GB.

Вписаться в такие довольно жесткие технические ограничения нам удалось благодаря следующим техникам:

• TensorParallel Attention / ExpertParallel FFN на 4 GPU.

• KV cache reuse общей части промпта.

• FP8 квантизация w8a8kv8 полностью в static per-tensor режиме.

• Спекулятивный декодинг в режиме EAGLE-3.

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

Системные оптимизации

Для моделей на сотни миллиардов параметров в первую очередь встаёт вопрос о правильной стратегии параллелизма, потому что в одну карточку модель просто не помещается. Тут возникает множество вопросов:

1. А сколько GPU оптимально? 

2. А какой тип параллелизма? 

3. А нужен ли мультихостовый инференс?

На все эти вопросы хочется получить ответ, но делать это нужно по порядку. Начнем с последнего. Как и любое другое техническое решение, мультихостовый инференс обладает плюсами и минусами. Верхнеуровнево подход разделяется на 2 фичи: Disaggregated Prefill/Decode и Large Scale EP. Первая позволяет дать строгие ограничения на квантили TTFT/TPOT и не растит общий throughput. Вторая позволяет на экстра больших моделях и экстра длинных контекстах держать большой batch_size.

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

Далее мы решили сравнить разные стратегии параллелизма для нашей архитектуры. Такой вопрос декомпозируется на сравнение стратегий DataParallel vs TensorParallel для блока attention и TensorParallel vs ExpertParallel для блока FFN.

Начнем с FFN. Ниже приведены 2 таблицы, иллюстрирующие, как скейлятся оба параллелизма в зависимости от количества вычислителей в разрезе двух сценариев: prefill и decode. Невооруженным глазом видно, что EP делает это ощутимо лучше, причем это более заметно становится с ростом группы. Причиной такого результата на самом деле является слишком малый размер матриц в экспертах при нарезке в TP-режиме – на современных видеокартах это не позволяет эффективно использовать compute. Но у EP тоже есть скрытая проблема – балансировка нагрузки. Напоминаем, что между экспертами именно роутер распределяет токены и вычислительную нагрузку. На практике это приводит к тому, что чем больше размер EP-группы, тем больше дизбаланс между ранками по нагрузке. К счастью, на EP=2/4/8 это пока не является острой проблемой (чего не скажешь про Large Scale EP), и все ещё позволяет явно сказать, что переход с TP на EP в FFN дает ощутимый прирост в 10-13% e2e-перфа.

Возвращаясь к attention, стоит вспомнить про важный нюанс работы TP-режима для этого блока. Он параллелится по головам. Это означает, что для моделей с большим GQA-фактором это может стать проблемой. Например, если kv голов всего 4, то использовать чистый TP=8 на практике неэффективно, потому что головы приходится дублировать и невозможно увеличить батч. Это приводит нас к мысли, что чистый TP можно использовать в группе не более чем на 4 карты.

С другой стороны, DP-схема тоже обладает недостатками балансировки нагрузки. Действительно, в разных DP-рангах генерации могут заканчиваться неравномерно, что вынудит нас потерять эффективность либо на prefill, либо на decode, т. к. размер батча на одной из этих стадий будет отличаться, и это приведет к ожиданию на барьерах. Более того, проблема только усиливается с ростом DP-группы, что делает очень затруднительным использование DP=4/8. Напротив, TP=4 схема абсолютно лишена проблем с балансировкой и позволяет получать стабильный TTFT в районе нескольких сотен миллисекунд, который оказался ощутимо лучше наших требований.

Поэтому мы решили остановиться именно на схеме TP=4 для attention + EP=4 для FFN, которая при необходимости может быть усилена в схему DP=2/TP=4 для более длинных контекстов в комбинации с EP=8.

Как ортогональную, но очень важную фичу, стоит упомянуть использование техники KV cache reuse. Она позволила нам добиться 20% e2e-ускорения и ощутимо сняла prefill нагрузку, что очень важно для чатового сценария с точки зрения таймингов и эффективности. Такое большое ускорение получилось из-за наличия большого системного промпта размером в ~1200 токенов при средней длине входа в 6k токенов, поэтому каждый prefill ускорился на эти 20%, что при нашем профиле нагрузки переносится в e2e.

Чем больше sparsity, тем больше батч

Как и все современные LLM на сотни млрд параметров, наша модель построена на основе MoE-архитектуры. Это означает, что FFN-блок имеет sparse природу, т. е. каждый конкретный токен обрабатывается не всеми total (e.g. 128) экспертами, а лишь малой их active (e.g. 8) частью, которые выбирает роутер. Это означает, что на этапе decode в каждого конкретно взятого эксперта прилетает в среднем batch_size * active / total токенов (e.g. batch_size / 16).

Как одну из важных метрик эффективности использования видеокарты мы рассмотрели утилизацию тензорных ядер (Tensor Active). В действительности оказывается, что эта метрика на фиксированном размере весов в операции GeMM/GroupedGeMM (далее для простоты просто GeMM) в первую очередь зависит от соотношения memory и compute операций, т. е. чем больше токенов обрабатывается за вызов кернела – тем лучше утилизация, и в какой-то момент она насыщается. Естественно, с увеличением количества токенов в GeMM растет и TPOT. Поэтому важно найти максимальное количество токенов, которое влезает по таймингам и при этом достаточно хорошо утилизирует compute. Для примера в таблице ниже показано, как меняется утилизация с ростом числа токенов на эксперта для DeepSeek V3.

Хотя метрика в изоляции не даёт гарантии, что инференс проводится эффективно, но для себя мы решили, что для нашей модели значение в 128 токенов на эксперта в среднем будет гарантировать нам хорошую утилизацию ресурсов GPU. Это означает, что реальный batch_size из-за наличия sparsity в модели должен быть в total / active раз больше (e.g. 128 * 16 = 2048). А точно ли мы можем уместить такой большой батч в видеопамять? Для этого подсчитаем теоретически, из каких частей состоит потребление VRAM.

1. Веса 235B модели: в базовой точности bfloat16 занимают ~470 GB.

2. Промежуточные буферы для активаций. Scratches ~= num_prefills * max_seqlen * hidden_size. 

   1. По умолчанию num_prefills в continuous batching режиме ограничен максимальным значением batch_size. Поэтому память на скрэтчи может очень сильно раздувать. Чтоб побороть эту проблему, можно обрабатывать <= 1 префила на итерацию декодинга. В такой схеме никак не меняется throughput, потому что даже 1 prefill насыщает compute, но зато сильно уменьшается TTFT + экономится память на скрэтчи. 

   2. ChunkedPrefill позволяет заменить max_seqlen на chunk_size. Путем тюнинга этого параметра можно также ограниченно уменьшить q95 TPOT.

   3. В итоге: Scratches ~= 1 * chunk_size * hidden_size. Это значение ограничено и не зависит от seqlen и batch_size, и на практике занимает <= 20 GB.

3. KV cache. На 1 пример в точности bfloat16 для 235B.

   1. 2 * 4 (kv_heads) * 128 (head_size) * 94 (num_layers) * 17000 (seqlen) * 2 (bytes_precision) = 3.05 GB.

Итого, подставим наши значения для различных конфигураций железа:

1. 8 x GPU: 470 + bs * 3.05 + 20 <= 1120, значит bs <= 209 – сильно меньше ожидаемых 2048.

2. 4 x GPU: 470 + bs * 3.05 + 20 <= 560, значит bs <= 24 – тоже.

Как видим, во всех конфигурациях нам сильно недостаточно VRAM для хорошей утилизации, поэтому будем сжиматься!

Квантизация

Есть слона мы начнем с самой простой части – сожмём веса. Стандартным подходом для этого является FP8-квантизация. Помимо весов в базовой её версии квантуются ещё и активации. Такой подход позволяет добиться незначимой просадки в качестве, но сжать веса модели до размера ~253 GB и даёт ускорение x1.4 на том же размере батча.

w8a8kv8
На этом мы не остановились и добавили FP8 квантизацию для Attention и KV cache. А если быть точным, то мы использовали static per-tensor режим. Такой подход позволяет получить небольшую просадку в качестве – до 1 п. п. на бенчмарках и статистически незначимый проигрыш в замере SbS. Потребление памяти на KV cache снизилось с ~3.05 GB до ~1.52 GB, а сам кернел attention ускорился x1.25 на prefill стадии.

Почему именно per-tensor? Как базовый кернел attention мы, как и подавляющее большинство, используем FlashAttention3. На момент дизайна в нём была поддержка только per-tensor режима обсчёта, и даже она была достаточно сырой (мы значимо улучшили её позднее).

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

По итогу, уже на этом этапе для нашей целевой конфигурации 4xGPU:

• 253 + bs * 1.52 + 20 <= 560, значит, bs <= 191. Стало гораздо лучше, но все ещё недостаточно.

• Ускорение ~x3 относительно bfloat16-модельки.

EAGLE3

Конечно же, помимо квантизации есть огромный класс методов спекулятивного декодинга, которые помогают увеличить количество токенов внутри GeMM. Достигается это за счёт использования какой-то draft-модели для генерации цепочки (в базовой версии) из n_spec_tokens токенов вперед, после чего происходит этап верификации основной моделью, где реальное число токенов в GeMM домножается на n_spec_tokens, который на практике часто принимает значение 3 или 5 (e.g. батч 191 превращается в 191 * 5 = 955).

На момент написания этого репорта SOTA-результаты показывает метод EAGLE3. Поддержка данного метода заявляется в opensource-фреймворках SGLang и TRT-LLM, а обучение EAGLE3-головы поддержано в фреймворке SpecForge. В целом для интересующей нас архитектуры и размера поддержка в opensource оказалась довольно сырой (дисклеймер: могло измениться на момент чтения статьи).

В частности, SpecForge требовал нескольких патчей для правильной работы, не имел поддержки разных архитектур для EAGLE-головы (мы хотели поэкспериментировать с dense/moe/мультислойными вариациями) и по итогу показал точность угадывания на спекуляции ощутимо ниже нашего внутреннего решения.

Со стороны движков инференса нам бы хотелось иметь поддержку квантизации головы, которая, по нашим замерам, в комбинации с FrSpec на практике может давать x1.1+ ускорение в части сценариев. На тот момент такая фича вовсе не упоминалась в документациях фреймворков и либо отсутствовала, либо была не оттестирована,  включалась нетривиальными хаками и приводила к ощутимой просадке точности угадывания.

Строго говоря, поддержка EAGLE1 в нашей инфраструктуре появилась ощутимо раньше всего open-source, поэтому свежие версии EAGLE2/3 мы разбирали и тестировали буквально сразу же после их публикации в github/arxiv. Поэтому все важные оптимизации для обучения и скорости инференса EAGLE3 мы дотащили вовремя. Для понимания сути этих решений мы предлагаем разобраться, чем отличается EAGLE 3-й версии от 1-й.

Если совсем вкратце, то ключевое отличие в процедуре самого обучения draft-модели: в первой и второй версии голова учится в режиме teacher forcing, т. е. не учится самостоятельно моделировать цепочки в глубину, у неё просто нет такого сигнала в loss-функции. Из-за этого точность угадывания в EAGLE1 стремительно падает с ростом длины цепочки. Для решения этой проблемы EAGLE3 в процессе обучения запускает генерацию draft-цепочки и полностью пропускает через неё градиенты. Это позволяет прокинуть сигнал на «моделирование вглубь» внутрь draft-головы и добиться равномерной точности угадывания на 1-ом и всех последующих токенах в драфтинге. Такое изменение значительно помогает нарастить acceptance на длинных цепочках и хорошо масштабируется по размеру датасета для обучения EAGLE-головы.

Естественно, запуск генерации во время обучения — совсем не дешёвая операция. Например, в SpecForge от этой идеи просто-напросто отказались и генерируют такой тяжелый датасет в офлайне. Нам такой подход не понравился, потому что он забирает возможность обучаться в онлайне на лету и требует по факту дополнительных приседаний в инфраструктуре. Поэтому мы по-честному запускаем генерацию. Однозначно, чем больше токенов генерируется при обучении, тем сильнее в ванильной реализации раздувается demand по памяти для хранения градиентов/активаций и т. д. В первых версиях нашего обучения нам требовались довольно большие ресурсы (128 x 12 GPU часов) для обучения головы размером всего лишь в 1 трансформерный слой!

Но со временем мы внедрили 3 важных техники для оптимизации обучения EAGLE3:

1. KV cache для генерации на этапе обучения.

2. По пути пару раз выстрелили себе в ногу при поддержке TensorParallel, но по итогу смогли всё отладить.

3. Поддержали чекпоинтинг активаций.

Полученное решение уже требует всего 32 x 12 GPU часов и дает возможность без проблем скейлиться на бОльшие длины контекстов.

С точки зрения нашего движка инференса мы тоже нашли большой простор для оптимизации. Мы сконцентрировались на кернеле Attention для сценария SpecDec:

• Оказалось, что использовать decode-версию attention для сценария с достаточно большим числом draft-овых токенов неэффективно.

• Поэтому мы переехали на FlashAttention3 и закопались внутрь этого кернела.

• Ожидаемо выяснилось, что тайлинги в этом кернеле подобраны в первую очередь для оптимизации сценариев обучения или prefill-а, а для SpecDec-а можно вынуть дополнительный профит через их тюнинг.

• По итогу:

  • TRT-LLM decode with MTP: 225 mcs

  • Наш движок инференса: 120 mcs

Далее мы хотим поделиться верхнеуровневыми результатами и неочевидными выводами:

• Итоговое ускорение от метода – x1.45.

• EAGLE3 помог кратно уменьшить тайминг avg TPOT: 140 ms -> 67 ms.

• На 3-х draft-токенах EAGLE3 acceptance = 2.5 против EAGLE1 acceptance = 2.1, что выливается в x1.15 ускорение e2e:

  • на момент экспериментов со SpecForge максимальный полученный acceptance = 1.8.

• EAGLE сильно перетягивает сценарий в сторону prefill-heavy режима:

  • допустим batch_size = 100;

  • avg output seqlen = 500, тогда при acceptance = 2.5 нужно примерно 200 итераций decode для завершения работы с примером;

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

  • как результат – сценарий становится сильно смещённым в сторону compute bound, что хорошо, но внезапно может возникнуть проблема с таймингами TPOT (потому что частые prefil-ы очевидно утягивают q95 TPOT наверх);

  • в таком случае можно тюнить ChunkSize или уменьшать общий размер батча.

Итоги

Наша инфраструктура инференса научилась без проблем обрабатывать произвольные модели размером в сотни миллиарды параметров. Небольшими модификациями пайплайна мы сможем достичь схожего результата на моделях размера 0.5T-0.7T параметров.

Мы разработали собственный дизайн инференса нашего продукта и добились его эффективности следующими методами:

• x3 – w8a8kv8 квантизация в static per-tensor режиме;

• x1.45 – EAGLE3 + квантизация draft-головы;

• x1.13 – TP/EP=4;

• x1.2 – KV cache reuse.

Общее ускорение:

• относительно базовой неускоренной версии (bfloat16) — в 5.8 раз; 

• относительно лучшего решения в opensource — в 1.32 раза.

Alice AI VLM

Рассказывают Роман Исаченко @isachenkoroma и Антон Клочков @Toshiksvg

Этот рассказ будет про Alice AI VLM, над которой последние несколько месяцев работала вся наша команда компьютерного зрения. Мы постарались сделать Алису действительно полезным ассистентом в сценариях, когда пользователь отправляет изображение в чат (или, как мы называем это направление, — Фотоинпут).

Disclaimer
Алиса AI — это ассистент, с которым пользователь взаимодействует в диалоговом режиме. Но для упрощения восприятия информации я не буду рассказывать про диалоги, т. е. про ситуации, когда пользователь отправляет в чат больше, чем одну реплику:

• Это достаточно сложный технический элемент реализации (например, на каком шаге диалога должна отвечать Alice AI VLM, а на каком Alice AI LLM или Alice AI ART).

• Нужно будет глубоко погрузиться в инфраструктуру, чтобы полноценно рассказать, как работают сценарии в Алисе AI.

• Да и с точки зрения ML там вагон и маленькая тележка нюансов!

Но если вдруг вам очень интересно, пишите в комментариях, и мы с командой постараемся для вас написать ещё одну статью — только про диалоги!

Инфраструктура Фотоинпута

Весной в статье на Хабре мы рассказывали, как работает Алиса с картинками. Но для полноты изложения напомню, как выглядела схема работы сервиса раньше:

• Визуальный поиск — это сервис, который умеет извлекать из картинки большое количество информации: какие объекты есть на картинке (тэги), распознанный текст (OCR).

• VLM-рефразер — это модель, которая, опираясь на выход визуального поиска, переформулирует запрос пользователя так, чтобы его понял текстовый поиск (тот самый, который на главной Яндекса).

• ИК (инфо-контексты) — текстовая информация из релевантных веб-документов, которые выдает текстовый поиск.

• VLM-генератор — модель, которая отвечает за то, чтобы сформировать финальный ответ пользователю.

А почему так сложно? Можно ведь одну ��одель оставить!

На самом деле, все современные сервисы устроены не из одной модели. На это есть, как минимум, следующие причины: 

1. У моделей нет информации о настоящем: они не знают, что случилось сегодня, какая погода или какой актуальный товар из Маркета подходит под тот, что скинул пользователь.

2. Практика показывает, что если мы дадим модели релевантную информацию из Поиска и других различных инструментов, то её ответ качественно улучшится.

К моменту запуска Alice AI VLM схема преобразилась и стала чуточку сложнее:

Основные изменения, которые произошли:

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

• VLM-рефразер наделили способностью маршрутизации: теперь он умеет ходить в разные модели, не только VLM-генератор.

• VLM-генератор теперь работает «из коробки»: нам не нужно доучивать модель под Алису, её свойства теперь заложены в основное обучение.

• Появилось ещё два выхода:

  • VLM-решатель — специализированная модель для решения задач по математике и геометрии.

  • Alice AI LLM — в эту часть мы отправляем часть потока, связанную с гуманитарными предметами (т. к. ребята прицельно растили эти срезы).

За эти полгода команда улучшила каждый из этих блоков. В рамках этой статьи я затрону вниманием улучшения только двух из них: Alice AI VLM и VLM-решатель.

Обучение Alice AI VLM

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

• Pretrain — это первая и самая объёмная стадия обучения любых VLM. Именно здесь закладывается фундамент будущих способностей модели: она «впитывает» разнообразие визуальных и текстовых данных, учится базовым принципам взаимодействия между изображениями и текстами. Модель учится предсказывать следующие слова, исходя из предыдущего контекста (совсем как T9, только есть ещё картинки).

• Alignment (SFT + RL) — как и в LLM, после Pretrain модель умеет классно предсказывать следующие слова, но не выполнять указания пользователя. Именно на этой стадии мы учим модель слушаться инструкций.

Кратко пройдясь по стадиям, я предлагаю погрузиться в то, а что же мы сделали такого, что в новом релизе Алиса действительно стала умнее!

Pretrain

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

Большой картиночный энкодер
Долгое время и младшая, и старшая версии нашей VLM использовали энкодер одного размера. Но нам показалось, что для бОльшей модели лучше будет использовать энкодер покрупнее: таким образом визуальной информации модель сможет запомнить больше, а также обрабатывать картинки чуть-чуть больше (раньше это было 896x896 без потери качества, а теперь 1024x1024).

Обновление OCR-данных
Долгое время данные для распознавания текста в обучении лежали в формате картинка + весь распознанный текст. Такой формат не является «нативным», поскольку на первых этапах мы стараемся обучать модель описывать картинки. В новом подходе к OCR-данным мы интегрировали текст с картинок в описания за счёт добавления координат.

Оригинальная картинка

Как было

Как стало

Увеличение масштаба данных и длины контекста
Масштабирование корпуса данных до сих пор улучшало качество, и для нового претрейна мы увеличили число токенов в 1.5 раза (400B -> 600B). А для того, чтобы можно было работать с большим количеством информации в контексте (например, работать с большими текстами или несколькими картинками), мы специально проучили модель работать с контекстом вплоть до 32k токенов.

Совокупность всех изменений привела к росту по большому количеству метрик, на которые мы смотрим практически в каждом эксперименте:

Описание метрик

• AvgVLM — набор open-source бенчмарков. В основном на английском языке.

• Recognition bench — собственный бенчмарк для распознавания объектов;

• OCR bench — набор задач, где важно уметь качественно распознавать текст на картинках (например, выписать таблицу);

• OCR BoW — градусник, который отражает как качественно мы выполняем задачу распознавания текста;

• IFBench (Ru / En) — бенчмарк следования произвольному промпту

• RefCOCO — бенчмарк, который помогает нам оценивать качество детектирования и локализации объектов.

Alignment

Объединение Алисы
До сих пор мы обучали модель для Фотоинпута методом дообучения: брали готовую модель YandexVLM и во время обучения чуть корректировали поведение под Алису. Таким образом, финальное решение обладало большим количеством умений для конкретного продукта (например, использовать информацию из интернета, как это делает Alice AI LLM Search). Но были и минусы:

• Обновление базовой YandexVLM влекло за собой пересбор датасетов (или их долей) для дообучения, и это процесс не самый быстрый.

• По пути дообучения терялось качество базовых навыков: распознавание текста, следование некоторым инструкциям.

Обе эти проблемы мы решили тем, что базовая технология VLM стала той самой моделью, которая отвечает пользователю в Алисе! Мы это называем «Алиса из коробки».

Для этого нам потребовалось: 

• Объединить датасеты для обучения.

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

Более богатые ответы за счёт RL
Качество ответа Алисы определяется не только его правильностью, но и полнотой, полезностью и проактивностю – аспектами, в меньшей степени связанными с мультимодальностью.

Всему этому нам удалось научить Alice AI VLM, переняв наработки Alice AI LLM в RL. Ребята в текстовой Алисе проделали большую работу по подбору удачного сетапа RL, чтобы сильно улучшить формат и содержание ответов. Нам же удалось перенять их опыт в кратчайшие сроки, но сделать это было непросто, за этим скрывается наш длинный путь по сближению базовых технологий VLM и LLM.

Текстовый RL – очень полезная стадия обучения Alice AI VLM, которая появилась благодаря движению к будущей общей модели (VLM + LLM).

Все изменения привели к тому, что мы стали лучше отвечать на потоковой корзине, качество на которой замеряем с помощью SbS.

На что мы смотрим в SbS

Наша корзина разбита на две части:

• Продуктовая: 500 семплов различных задач из Алисы (что-то узнать, распознать, уточнить и т. д.).

• Базовые навыки: 500 семлов, проверяющие «умность» модели.

В базовых навыках у нас есть:

• Reasoning – работа с документами, мемы, дорожные знаки.

• General Knowledge – логотипы, достопримечательности, знаменитости, растения.

• Basic Perception – сравнение размеров, поиск отличий, условный подсчет объектов.

• Captioning – описание картинок, описание графиков/схем.

• Generative – комплименты, описание луков, DIY.

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

• single_image – картинка + вопрос.

• text_dialog – картинка + вопрос + ответ + вопрос.

• multi_image – картинка + картинка + вопрос.

• img_dialog – карт + вопрос + ответ + карт + вопрос.

И распределение по разным классам примерно следующее:

VLM-решатель

VLM-решатель — это отдельная VLM-модель, которая умеет хорошо решать задачи по математике и геометрии уровня 5-9 классов, при этом у неё не гарантируется хорошие ответы на общие пользовательские задачи (например, описать картинку).

Пример

А зачем нам нужен решатель и тем более отдельный?

У такого решения есть свои причины: 

• «Объединение Алисы» мы начали делать достаточно поздно, и до конца не было уверенности, что мы быстро получим хороший результат.

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

По этим же причинам все гуманитарные предметы автоматически пересылаются в Alice AI LLM — потому что коллеги фокусно занимались ростом качества на этих срезах и перенять их наработки мы бы просто не успели.

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

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

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

В итоге мы получили следующие метрики:

Alice AI ART

Рассказывает Евгений Ляпустин @unishift

Старая модель часто генерировала «пережаренные» изображения в мультяшном стиле и игнорировала стиль, указанный пользователем (например, генерация в стиле realistic была фактически невозможна). Кроме того, модель не обладала достаточным знанием многих объектов и действий — часть концептов она просто не умела генерировать.

Поэтому при разработке Alice AI ART мы сфокусировались на улучшении соответствия результата генерации исходному текстовому запросу пользователя. С чего мы начали:

1. Подготовили инструмент на основе VLM, который извлекает структурированную информацию из входного изображения в формате JSON. На основе этих JSON-описаний проанализировали датасеты для finetune и distillation и обнаружили перекос в сторону стиля realistic, а также доминирование концептов people / cars / nature (можно приложить визуализации).

2. Значительная часть датасета состояла из realistic-фотографий, поэтому во время обучения модель практически не видела текстовых запросов со стилевыми модификаторами (например, anime, cartoon, pixelart). Кроме того, промпты были преимущественно объектно-центричными — они описывали отдельные объекты, почти не затрагивая взаимодействия между объектами и окружением.

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

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

Finetune

Работу начали с подготовки инструмента для генерации текстовых описаний изображений. LLM генерирует описание на основе структурной информации в формате JSON, которую извлекает VLM (это описано в разделе про дебаг). После множества итераций по изменению структуры JSON и подбору системного промпта для LLM мы пришли к состоянию, при котором по сгенерированному промпту можно представить картинку, даже не видя её. Такой «вайб»-тест — лучшая оценка качества кепшенера, которую мы смогли получить в ограниченное время.

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

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

Изменения на этапе дистила аналогичны SFT.

Рефразер

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

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