GigaChat 3.5 Reasoning — первая в России открытая модель с рассуждениями

Мы выпускаем GigaChat 3.5 Reasoning, первую модель GigaChat с полноценным рассуждением, обученную на технологии online RL. Веса и код запуска на huggingface, также модель можно попробовать в API и giga.chat.

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

Где прирост больше всего относительно GigaChat 3.5 Instant:

• GPQA-Diamond: 61,11 → 82,32

• AIME-2026, mean@32: 67 → 92

• IFBench Loose Prompt: 43,66 → 77,00

Полная таблица с внешними моделями и eval-конфигами приведена в разделе 3.

Если вам нужен только запуск, то сразу переходите к разделу 4. Если интересно, как учить reasoning-модель на RL и почему это заняло у нас больше 9 месяцев, то читайте по порядку.

1. Как мы учили модель

Если коротко, то обучение выглядело так: взяли SFT-чекпоинт, из него вырастили шесть отдельных моделей (по одной на домен), и каждую учили online RL со своей наградой; потом собрали шесть моделей обратно в одну через on-policy distillation. 

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

1.1 Зачем вообще нужен online RL

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

Online RL устроен иначе. Мы даём модели задачу, она решает её сама, мы оцениваем результат и сдвигаем веса в сторону тех попыток, которые сработали. Повторяем тысячи раз. Слово «online» означает, что обучающие данные модель производит сама по ходу дела, а не берёт из собранного заранее датасета. Постепенно закрепляются приёмы, которые повышают шанс дойти до ответа: перепроверить промежуточный результат, вернуться на шаг назад, зайти с другой стороны. Это и называют рассуждением.

1.2 Шесть экспертов и одна конструкция награды

1.2.1 Почему не одна модель?

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

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

1.2.2 Алгоритм: CISPO

Учили алгоритмом CISPO из работы MiniMax-M1. Он близкий родственник GRPO, и суть у обоих одна: на каждую задачу модель пишет несколько ответов; ответы лучше среднего по группе подкрепляются, хуже среднего — подавляются. Различие в одной детали, но для рассуждения она оказалась важной.

Любой RL-алгоритм ограничивает размер шага, чтобы модель не разнесло за одно обновление. GRPO делает это грубо: если какой-то токен после обновления стал слишком вероятным или слишком редким, то обучение на нём просто выключается. Беда в том, что у рассуждающей модели самые важные токены как раз редкие. «Однако», «проверим», «стоп, здесь ошибка», всё, что заставляет модель усомниться и вернуться назад. SFT-модель такие слова почти не пишет, и когда RL начинает их поднимать, они первыми выпадают за границу и перестают усваиваться. Модель, которую мы учим сомневаться, не получает сигнала именно там, где сомневается.

CISPO ограничивает шаг иначе: не выключает токены, а придавливает вклад тех, что слишком далеко ушли. Обучение остаётся устойчивым, а сигнал доходит до всех токенов, включая редкие развилки. Результат простой: CISPO сходится быстрее, чем GRPO. Авторы MiniMax показали это на AIME 2024, у нас то же самое повторилось на наших экспертах. 

1.2.3 Расписание: задачи становятся сложнее вместе с моделью

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

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

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

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

Побочный эффект, который мы не планировали, но оценили: такое расписание экономит GPU. Задачи с нулевым градиентом не занимают место в батче, роллауты на них не генерируются, и таким образом мы экономим 50% вычислений на inference.

1.2.4 Награда

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

Ворота (gated rewards). Бинарные проверки, которые ответ должен пройти до того, как его начнут оценивать по существу: ответ завершён и в нужном формате, написан на нужном языке без мусора и смешения алфавитов, не нарушает жёстких ограничений инструкции. Не прошёл ворота — награда нулевая, каким бы умным ни было рассуждение внутри. Набор ворот у экспертов разный: правило компилируемости для кода не имеет смысла в математике.

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

Сумма (additive rewards). Ответы, прошедшие ворота, оцениваем по нескольким осям с весами: корректность, полнота, следование инструкции. Здесь оценка уже с градациями, и модель различает посредственный ответ и хороший. 

1.2.5 Штраф за длину

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

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

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

1.3 Код: два эксперта и фабрика агентских роллаутов

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

1.3.1 Эксперт Code: алгоритмы, правки, тесты

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

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

Расскажем про одну ошибку. В первых итерациях мы давали награду за каждый пройденный тест, а не за задачу целиком: прошёл семь тестов из десяти, получи 0,7. Идея казалась разумной, частичный сигнал должен помогать в сложных задачах, где полное решение модели пока не по силам. Но помогло не то, что мы ждали. В олимпиадных задачах примеры из условия почти всегда попадают в тесты. Модель это заметила и в самых сложных задачах перестала решать вообще: писала if на входные данные из примера, печатала ожидаемый ответ и забирала свою долю награды. От частичной награды за тесты пришлось отказаться: прошла либо все тесты, либо ноль.

1.3.2 Эксперт Code Agent: задачи в духе SWE-bench

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

Чтобы всё это делать, модель работает через harness— программу-обёртку вокруг модели: она даёт ей инструменты (терминал, чтение и правку файлов, запуск тестов), крутит цикл «модель сказала, harness выполнил, вернул результат» и следит, чтобы агент не ушёл в бесконечный цикл. Таких harness много: Claude Code, Codex, OpenHands, mini-SWE-agent и десятки других. Написаны они на разных языках, устроены по-разному и обновляются каждую неделю.

1.3.3 Развилка: переписывать harness или обучать сквозь них

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

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

2. Не трогать harness вообще и учить модель сквозь него. Для этого между harness и моделью ставится прокси, который записывает каждый запрос и ответ. Harness работает как обычно и не знает, что участвует в обучении, а из записанных запросов и ответов собирается траектория, которую можно использовать в обучении. Модель при этом учится в том же окружении, в котором её потом будут использовать, а не в его упрощённой копии.

Мы с самого начала хотели учить модель на как можно большем количестве harness, поэтому первый путь нам не подходил. Пошли по второму и взяли за основу Polar, open-source-фреймворк от NVIDIA, который ровно так и устроен: прокси перед моделью, отдельный сервер для роллаутов, конвейер, в котором поднимаются контейнеры под следующие задачи, пока модель ещё думает над текущими. Сделали форк под наш стек и развернули полностью локально, включая виртуализацию контейнеров.

1.3.4 Цена вопроса

Теперь честно про недостатки. На поднятие у себя Polar ушло два месяца, и полноценно он заработал за неделю до релизного обучения. Поэтому в этом релизе Code Agent учился на одной обвязке — mini-SWE-agent. Вся инфраструктура для десятков обвязок уже стоит, в следующем релизе мы её загрузим.

1.4 Агенты: вызов функций, память, поиск

Отдельный эксперт учился вызывать функции и вести агентные сценарии. Целевые бенчмарки: Function Calling V4 (вызов функций, память, поиск) и τ²-bench (многошаговые диалоги агента с пользователем).

1.4.1 Диалоговые агенты

τ²-bench оценивает, доводит ли модель задачу до конца в разговоре с симулированным пользователем. В доменах airlines и retail агент сам ходит в базу, смотрит бронирования и заказы и предлагает допустимые варианты. В telecom у него нет прямого доступа к устройству, поэтому он ведёт пользователя по шагам диагностики теми инструментами, что есть у самого пользователя. В реальных диалогах оба паттерна встречаются вместе.

Главная сложность оказалась в данных, а не в алгоритме. SFT-примеров для таких задач в открытом доступе много, а для RL нет почти ничего: нужна база с согласованными данными, сценарии поверх неё и проверяемое целевое состояние, чтобы разыгрывать диалог online и выдавать награду. Поэтому среды мы строили сами, двумя конвейерами.

Среды из существующих проектов. За основу берём реальный фреймворк с открытым кодом и документацией, например, проект с GitHub: электронную библиотеку, систему управления учебными курсами и подобные. LLM по коду и документации восстанавливает методы API, описания сущностей и схему базы, а также пишет текстовые шаблоны для промптов user-model. Дальше всё процедурно. Из методов API строим граф зависимостей: какой метод потребляет результат какого. Сэмплируем путь в этом графе, и он становится скелетом задачи: под путь генерируем обстоятельства в базе, её желаемое конечное состояние со способом его проверки и промпт для user-model. Несколько таких задач склеиваем в одну сессию, получая сценарий из большого количества событий. Так получилось пять сред и восемь тысяч задач. Базы здесь крупные и глубокие, поэтому одна среда покрывает много разных сценариев.

Среды «под ключ». Второй конвейер полностью агентный и ничего готового не использует. Сначала создаётся пул бытовых ситуаций: доставка еды, стойка администратора гостиницы и так далее. Под каждую ситуацию агенты проектируют базу и API-ручки к ней, наполняют её сущностями, прописывают политику агента, генерируют сценарии пользователя и, наконец, генерируют и фильтруют ground truth так, чтобы конечное состояние базы существовало и было единственным. Отличий от первого конвейера два: документацию агенты придумывают сами, а не берут готовую, и задачи генерируют напрямую каждый раз, без предсгенерированных шаблонов. Так получилось 50 сред по 80 задач, всего четыре тысячи сэмплов. Базы тут мельче и сценарии проще, зато всё целиком на русском.

1.4.2 Разнообразие в cold start важнее точности

Это главный вывод из агентного эксперта. Эффективность RL сильно зависит от SFT cold start. Если на этапе SFT модель не видела достаточно разных ответов пользователю (уточняющие вопросы, альтернативы, отказ с объяснением), то в RL ей не хватает exploration, чтобы этому научиться. Такая политика застревает в повторяющихся репликах и не доводит сценарий до конца, а награда за завершённые эпизоды приходит слишком редко, чтобы обучение сдвинулось.

Качество cold start удобно измерять через pass@k на стартовом чекпоинте: эта метрика показывает, какую долю задач модель способна решить хотя бы в одном из k сэмплов, то есть насколько её разнообразие покрывает пространство сценариев. Именно это покрытие RL потом и использует: если правильная траектория не встречается ни в одном сэмпле, то награда не приходит и учиться нечему. В наших экспериментах на моделях меньшего размера (10B) cold start без сценариев conversational agent давал pass@32 порядка 0,4 на средах τ²-типа. После добавления таких сценариев в SFT pass@32 того же стартового чекпоинта вырастал до 0,8-0,9, и RL на нём шёл заметно быстрее.

1.4.3 Память: хорошее чтение невозможно без хорошей записи

Открытых данных для персонализированной памяти почти нет: RL-сред нет вовсе, а SFT-датасеты либо слишком немногочисленны, либо в них нет рассуждений перед вызовом инструментов памяти. И SFT, и RL-данные мы готовили сами.

У памяти две разные способности, и Function Calling V4 проверяет обе. Чтение — это работа с внешним хранилищем: найти информацию инструментами, собрать из нескольких мест, подытожить/суммаризировать. Запись — отдельный навык: оценить важность факта и его уникальность относительно уже сохранённого, не засорять память дублями. В RL фазы учились раздельно: для чтения подготовили среды с информацией о пользователях и пары вопрос-ответ по ним, награду за корректность ответа; для записи разметили, стоит ли сохранять факт после конкретной реплики, награду за согласованность с разметкой.

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

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

1.4.4 Агентный поиск

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

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

Ниже приведён пример вопроса средней сложности и примерное ожидаемое решение от модели.

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

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

Чтобы дойти до эталонного ответа head of music, нужно найти шоу по паре «британское и его австралийский аналог», достать состав жюри, по двум признакам опознать дирижёра, расшифровать «национальную оперную компанию» как English National Opera, а не Royal Opera House, и только потом выйти на нужного человека и его должность. Но на втором шаге выясняется, что в жюри было не двое, а пятеро, и в ENO работал не только Энтони Легг, но и Мэри Кинг, руководившая программой The Knack. Формально у вопроса два ответа. Именно такие вопросы отбраковываются на уровне агентной валидации: проверка единственности ответа не даёт им попасть в обучающую выборку, как бы хорошо ни была построена сама цепочка.

Фильтры отсекают большую часть сгенерированного. Около 30% вопросов отбрасываются сразу после усложнения как слишком простые: их не удаётся усложнить дальше, а сильная референсная модель отвечает на них без поиска [GPT-5.6-luna без доступа к поиску]. Из оставшихся ещё 70% не проходят отбор по pass rate для RL: примерно половина из них решается либо во всех восьми сэмплах, либо ни в одном, и сигнала для обучения не даёт. На том, что осталось, проверяется однозначность ответа, и она снимает ещё около 7%. В итоге до обучающей выборки доходит примерно каждый пятый сгенерированный вопрос.

1.5 Диалог и инструкции 

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

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

Эксперт Инструкции отвечает за управляемость: ограничения в запросе, форматы, structured output, длинный контекст. Здесь ответ проверяем так: либо ограничение выполнено, либо нет.

1.5.1 Награда 

Для обучения разговорного эксперта мы используем несколько наград, но основная отвечает за качество обычного диалога. Мы используем SBS-сравнение: для фиксированного набора запросов берём ответ нашей модели и ответ сильной модели (GPT-5.6 Sol, Gemini 3.7 Flash и так далее), а MiniMax M2.7 как судья выбирает лучший по следованию запросу, полноте и качеству формулировок. Из этого попарного сравнения и строится награда. Такой подход хорошо поднимал метрики, но после разбора одного из запусков мы заметили, что средняя длина ответа выросла почти в три раза: судья систематически предпочитал длинные ответы, считая их более подробными и качественными.

Чтобы убрать такое поведение, мы добавили штраф за длину, зависящий от типа запроса и средней длины ответов сильных моделей. После этого средняя длина выросла лишь на 8%, а SBS-метрики продолжили стабильно улучшаться и дошли до того же высокого уровня без раздувания ответов.

1.5.2 Curriculum

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

1.5.3 Данные

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

Отдельно переработали structured output: улучшили примеры, системный промпт и схемы для JSON, добавили другие форматы, чтобы модель воспринимала структуру ответа как часть инструкции.

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

1.5.4 Что пошло не так?

Например, при работе с JSON мы ориентировались в том числе на JSONSchemaBench, но на ранних запусках метрика оставалась около нуля, хотя вручную ответы выглядели правильными. Причина оказалась в том, что модель привыкла объяснять свои действия: перед JSON она писала что-то вроде: «Конечно, вот результат», а после добавляла комментарий. Для человека это выглядело нормально, но строгий парсер уже считал весь ответ некорректным.

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

1.6 Как собрать шесть моделей в одну

После RL у нас шесть экспертов, а нужна одна модель. Склеивали через on-policy distillation (OPD). Ученик сам генерирует ответ, а учитель — эксперт того домена, к которому относится задача, — оценивает каждый токен: «здесь я бы сказал так же», «а здесь иначе». Сигнал приходит по траектории ученика, на его собственных ошибках, как в RL, но обратная связь гораздо плотнее: не одно число за весь ответ, а оценка на каждом шаге.

2 Инфраструктура обучения

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

2.1 Согласованность движков

Почти все исследования на эту тему сходятся в одном: train- и inference-движки должны быть хорошо выровнены, иначе в обучение попадает лишний шум. Роллауты генерирует один движок, градиенты считает другой, и если они расходятся в вероятностях одних и тех же токенов, то обучение, которое мы считаем on-policy, на деле оказывается off-policy.

Для MoE-моделей проблема стоит особенно остро. MoE-роутер работает недетерминированно: на одних и тех же данных train и inference выбирают разные эксперты, и расхождение между движками получается заметно больше, чем у dense-моделей.

Особенно полезной оказалась техника rollout routing replay (R3). Идея простая: во время генерации мы запоминаем, какие эксперты выбрал роутер на инференсе, и на обучении переиспользуем ровно этот выбор. Главный источник рассинхронизации при этом просто исчезает. Помимо этого часть операций мы считаем в более высокой точности fp32 — вычисление логитов, нормировки, хранение и аккумуляцию mamba-слотов и другое.

2.2 Асинхронный конвейер

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

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

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

2.3 Синхронизация весов

Отдельный этап, который становится узким местом при масштабировании обучения на большие модели, — синхронизация весов. После каждого шага обучения новые веса нужно доставить в инференс-движок, и в случае модели такого размера это уже недёшево. Реализаций, ускоряющих этот этап, много, и устроены они похоже; мы остановились на реализации из репозитория miles — она эффективная, но при этом гибкая и почти не добавляет накладных расходов. Мы адаптировали её под verl и сократили длительность синхронизации с нескольких минут до 8 секунд на шаг обучения.

2.4 Ускорение инференса

Генерация роллаутов — самая дорогая часть RL-обучения, поэтому ускорение инференса даёт самый большой прирост эффективности. Здесь помогает сама модель: она нативно поддерживает MTP (multi-token prediction), то есть предсказывает несколько токенов за шаг, и генерация ускоряется без отдельной draft-модели. В сумме это даёт около 30% ускорения обучения.

2.5 FP8

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

Результат стоит усилий. Переход на FP8 ускоряет обучение в 1,3-2 раза и сейчас является у нас стандартом для всех обучений. Снижения качества мы при этом не видим: результаты сопоставимы с обучением в bf16.

Стоит отметить, что GigaChat 3.5 430B Reasoning — модель, обученная нативно в FP8 на всех этапах.

3. Результаты и что дальше?

Теперь самое сладкое: а зачем нам вообще нужно это самое рассуждение и что нам дал полный пересбор нашего конвейера алаймента. Чтобы понять, что улучшилось, давайте сравним GigaChat 3.5 в Instant- и Reasoning-версиях:

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

По среднему баллу в бенчмарках GigaChat-3.5-Reasoning вплотную приблизилась к DeepSeek V4 Flash Preview. В Instruction Following и в структурированном ответе мы даже обходим модель от DeepSeek, но всё ещё немного проигрываем в агентном программировании и олимпиадной математике. Оставим эти домены как домашку для GigaChat-4 :)

Отдельно отметим эффективность нашей модели. На решение сложных математических задач из AIME 2025/2026, HMMT и IMO Answer Bench GigaChat-3.5-Reasoning тратит в среднем на 37% меньше токенов, а значит, отвечать GigaChat-3.5-Reasoning будет быстрее и дешевле.

4. Как запустить

Доступны два репозитория:

4.1 SGLang

Модель содержит три MTP-головы (speculative decoding) и поддерживает контекст до 262 тыс.

1. Загрузка PR:

git clone https://github.com/sgl-project/sglang.git

cd sglang

git fetch origin pull/29189/head:pr-29189

git checkout pr-29189

2. Установка:

pip install --upgrade pip

SGLANG_BUILD_RUST_EXTS=none pip install -e "python[all]"

SGLANG_BUILD_RUST_EXTS=none отключает сборку опционального Rust-роутера, для инференс-сервера он не нужен. Без этой переменной установка упадёт с ошибкой «cargo is required to discover the Rust extension modules». 

Альтернатива: поставить Rust-инструментарий: curl https://sh.rustup.rs -sSf | sh.

3. Запуск сервера (fp-8, 8×H100):

python -m sglang.launch_server 
 --model-path ai-sage/GigaChat3.5-432B-A28B-Reasoning 
 --trust-remote-code 
 --tp-size 8 --ep-size 8 
 --mem-fraction-static 0.8 
 --tool-call-parser gigachat35 
 --reasoning-parser gigachat35 
 --speculative-algorithm EAGLE 
 --speculative-num-steps 3 
 --speculative-eagle-topk 1 
 --speculative-num-draft-tokens 4 
 --host 0.0.0.0 --port 8000

• --reasoning-parser gigachat35 выносит рассуждение в отдельное поле reasoning_content, а финальный ответ — в content;

• --tool-call-parser gigachat35 включает парсинг вызовов функций;

•  блок --speculative включает в себя MTP (три головы) и ускоряет генерацию.

Если при запуске возникает ошибка захвата CUDA-графа на этапе префилла, то добавьте --cuda-graph-backend-prefill disabled.

4. Пример запроса:

curl http://localhost:8000/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{
    "model": "ai-sage/GigaChat3.5-432B-A28B-Reasoning",
    "messages": [
      {"role": "user", "content": "Докажи теорему о неподвижной точке"}
    ],
    "max_tokens": 2000,
    "temperature": 0.6
  }'

Вместо заключения

Мы обещали объяснить, почему это заняло больше девяти месяцев. Алгоритм — наименьшая часть работы: CISPO, расписание по pass rate и каскад наград воспроизводятся за недели. Время ушло на среды с проверяемой наградой и на инфраструктуру, в которой online RL на MoE такого размера вообще сходится.

О чём мы хотели бы знать вначале:

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

• Cold start задаёт потолок RL. Если правильная траектория не встречается ни в одном из k сэмплов, то учиться нечему. Разнообразие SFT важнее его точности.

• Рассинхрон движков — скрытый off-policy. Для MoE без R3 остальные оптимизации не имели смысла.

Веса и код запуска на huggingface, также можно попробовать в API и giga.chat. Ждём отзывов и примеров, где модель ведёт себя не так, как вы ожидали, — в комментариях или в нашем канале.