GigaChat 3.5 — меньше, быстрее, сильнее

Салют, Хабр!

Сегодня мы выкладываем в open source GigaChat 3.5 Ultra — нашу новую 432B-модель. В этом релизе мы впервые для нашей линейки масштабировали собственную гибридную архитектуру на сотни миллиардов параметров, ускорили инференс и усилили модель в коде, агентных сценариях и сложных областях.

GigaChat 3.5 Ultra компактнее прошлого флагмана: 432 млрд параметров вместо 700 млрд у GigaChat 3.1 Ultra. Но это не компромисс «меньше, зато дешевле»: за счёт новых данных, обновлённого рецепта обучения и архитектурных изменений модель стала сильнее, а также эффективнее по памяти и скорости генерации.

Интересно? Добро пожаловать под кат.

Что нового?

GigaChat 3.5 — результат более чем 1500 экспериментов с данными, архитектурой, пайплайном обучения и гиперпараметрами. Главное:

• Собственная гибридная архитектура. Мы совместили MLA-слои с GatedDeltaNet и добавили стабилизирующие механизмы, чтобы всe это устойчиво обучалось на масштабе сотен миллиардов параметров.

• Более дешёвый инференс. В 432B-модели используется примерно в четыре раза меньше KV-кеша на токен, в ту же память помещается более чем в два раза больше контекста, а throughput вырос примерно на 20%.

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

• Ускорение генерации через MTP. Мы добавили дополнительные MTP-головы для self-speculative decoding: основной выигрыш дают первые две, ускоряя greedy decoding в 2,2 раза.

• FP8 на всех этапах обучения. Пониженная точность ускорила обучение на десятки процентов и снизила потребление памяти без потери качества относительно bf16.а

• Online RL в alignment. Новый этап после Pretrain → Stage 1.5 → SFT → DPO улучшил Instruction Following, математику и качество модели на аренах.

Как мы его делали?

Данные для pretrain

В прошлых релизах фундамент pretrain мы во многом строили на синтетике: модель сама генерировала данные. На небольших моделях это работает отлично, но при сотнях миллиардов параметров и триллионах токенов синтетика со временем «схлопывается» в однотипность: разнообразие падает, покрытие реальных сценариев неполное. Поэтому в 3.5 мы переосмыслили подход, и для основы pretrain-данных используем органические, натуральные тексты.

Главный прорыв — веб. Мы прогнали HTML-документы через LLM-парсинг (да, это огромный объём вычислений), и на выходе получили чистый Markdown с сохранением формул, таблиц и структуры вместо привычной мешанины из тегов и мусора. В экспериментах это дало значительный прирост MMLU, MATH и других метрик.

Сильно прокачали код: было 16 языков программирования, стало больше 600.

Чтобы добывать математику и код из веба (форумы, разборы алгоритмов, руководства), мы обучили отдельные классификаторы. Сначала прогоняем легкий fasttext с высоким recall, он дёшево отсекает основную массу мусора, а уже отобранное докручиваем LLM-классификатором. 

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

Раньше мы итерировались по данным на небольших сетапах (3 млрд на 200 млрд токенов, 7 млрд на 40 млрд). Для 3.5 мы от этого не отказались – но для экспериментов с заваркой всего датасета мы перешли на значительно большие размеры моделей – 120 млрд MoE на 2 трлн токенов. У такого сетапа заметно выше разрешающая способность, и на нём видны эффекты, которые на маленьких моделях просто не достигаются. На новом датасете по сравнению с прошлым мы получили +6% MMLU-PRO, +6% MATH и рост по остальным pretrain-метрикам.

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

Итоговый pretrain-корпус состоит из ~52% веба, ~16% кода, ~6% математики, ~26% качественных источников (научные статьи и пр.). На midtrain состав другой — там доля синтетики заметно выше.

Пока что в качестве основного источника сырых данных мы используем Common Crawl, но хотим скачивать интернет самостоятельно — это даст кратно больше данных. Также планируем проводить больше экспериментов в сетапе 120B/2T (это довольно дорого) и прокачивать дальше математику и код.

Этап pretrain

Зачем менять архитектуру и рецепт претрейна

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

На практике этого недостаточно, особенно когда речь идёт о MoE-системах с сотнями миллиардов параметров, длинным контекстом и высокими требованиями к скорости инференса. При таком масштабе архитектура и рецепт обучения становятся не менее важны, чем данные и compute.

Ускорение генерации почти всегда требует компромиссов. Линейное внимание, Multi-Token Prediction и другие подходы помогают быстрее генерировать текст и эффективнее использовать память, но они меняют путь сигнала внутри модели, влияют на масштаб активаций и могут сделать обучение менее стабильным.

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

С этим мы столкнулись при создании GigaChat 3.0. Мы опирались на опубликованный рецепт DeepSeek V3, но на нашем пайплайне обучение оказалось нестабильным. Дело было не только в данных: при таком масштабе начинают играть роль недосказанности технического отчёта и подробности реализации пайплайна обучения. Чтобы довести обучение до конца, нам потребовались дополнительные стабилизирующие механизмы, в том числе hidden_z_loss, о котором мы писали в предыдущей статье.

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

Поэтому в GigaChat 3.5 мы не просто добавили линейное внимание и MTP, а собрали собственную гибридную архитектуру и собственный рецепт обучения вокруг неё. Ускоряющие фичи шли вместе со стабилизирующими: Gated Attention, GatedNorm, сэндвич-нормализацией и клиппингом активаций. Эта связка позволила нам обучить крупную open source-модель с GatedDeltaNet и линейным вниманием без потери стабильности.

Как мы стабилизировали обучение

Все ключевые архитектурные правки решали одну задачу: удержать активации под контролем при  432 млрд и 700 млрд параметров.

Масштабирование через gating

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

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

• Gated Attention: выход attention-слоя умножается на сигмоидальный гейт. Так модель может локально напрямую приглушить слишком сильный сигнал.

• GatedNorm: похожая идея применяется в нормализации. Сеть может явно масштабировать сигнал между признаками, а не полагаться на неявные «якоря». Это наше нововведение — в open source подобной архитектуры ещё не было.

attn = softmax(q @ k.T / sqrt(d)) @ vattn_gate = torch.sigmoid(x @ W_gate)attn_out = (attn * attn_gate) @ W_O

x_norm = x * torch.rsqrt(x.pow(2).mean(-1, keepdim=True) + eps)x_norm = x_norm * (1.0 + norm_weight)# gatingnorm_gate = torch.sigmoid(MLP_gate(x_norm))# scale-neutral at initnorm_out = x_norm * 2.0 * norm_gate

Обычный sigmoid(...) при инициализации даёт значение около 0,5, потому что вход в гейт близок к нулю. Если сразу умножать сигнал на такой гейт, то модель стартует с вдвое заниженным масштабом.

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

Сэндвич-нормализация

Классическая pre-norm защищает вход блока attention или MLP, но не контролирует его выход. Если блок сгенерировал вектор большой амплитуды, то он сразу попадает в residual stream и проходит через следующие слои.

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

# attention blockh = h + post_attn_norm(attn(pre_attn_norm(h)))# mlp blockh = h + post_mlp_norm(mlp(pre_mlp_norm(h)))

Клиппинг активаций

В MoE-слоях есть отдельная точка риска — SwiGLU. Внутри эксперта перемножаются silu(gate) и up, и редкий сильный выброс может резко усилиться перед финальной проекцией w2.

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

gate = self.w1(x).float()up = self.w3(x).float()up = torch.clamp(up, min=-10, max=10)gate = torch.clamp(gate, max=10)x = F.silu(gate) * upout = self.w2(x.to(dtype))

Как мы сделали модель эффективнее на инференсе

Линейное внимание

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

В GigaChat 3.5 мы впервые завели гибридную архитектуру: часть слоёв осталась обычными MLA, а часть стала линейными слоями на основе GatedDeltaNet в духе Qwen Next. Так мы сохранили сильные стороны обычного attention и снизили стоимость длинного контекста.

Главный выигрыш — память. Обычное внимание хранит историю токенов, а линейное сворачивает её в состояние фиксированного размера. В 432B-модели гибридная архитектура тратит примерно в четыре раза меньше кеша на токен. В тот же объём памяти помещается в 2,14 раза больше токенов контекста.

Линейное внимание помогает и со скоростью. Когда KV-cache становится узким местом, гибридная модель обрабатывает больше запросов одновременно и обгоняет all-MLA по throughput: на контексте 4-128 тыс. прирост составляет около 20%. Ускорение генерации тоже растёт с длиной: от 1,15x на коротком контексте до 1,25x на 131 тыс.

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

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

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

Multi-Token Prediction

MTP — ещё один способ ускорить инференс GigaChat 3.5. Одна MTP-голова была у модели уже в версии 3.0: вместе с очередным токеном она предсказывала следующий. В 3.5 мы добавили ещё две дополнительные головы.

На инференсе MTP работает как self-speculative decoding. За один forward-проход модель предлагает черновик на несколько токенов вперёд, а основная голова проверяет его и принимает корректную часть. Отдельная draft-модель не нужна.

Ключевая метрика — accept length, среднее число токенов, которые модель принимает за один шаг. Без MTP accept length равен 1. Старый вариант с одной головой давал около 1,8 токена за шаг. Новый вариант даёт около 2,3-2,5.

По скорости жадный декодинг ускоряется в 1,5 раза с одной головой и до 2,2 раза с двумя. Третья голова даёт небольшой дополнительный эффект по сравнению с двумя, поэтому основной практический выигрыш дают первые две. С ростом температуры ускорение снижается, но даже при t = 1,0 остаётся около 1,5x.

Обучение MTP-голов обходится недорого и почти не влияет на качество модели. Ещё один полезный эффект: accept length хорошо переносится с base-версии на instruct-версию.

MTP особенно полезен на крупной модели. На 432 миллиардах параметров каждый шаг генерации дорогой, а без MTP он даёт только один токен. MTP позволяет за тот же шаг принять несколько токенов и распределить стоимость forward-прохода между ними.

Что поменяли в рецепте обучения

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

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

Подозрение пало на параметры AdamW. Ближе к концу обучения шаги становились настолько маленькими, что вторые моменты градиентов по масштабу оказывались сравнимы с eps — параметром, который добавляют в знаменатель для численной стабильности. Для более чем 90% параметров eps становился доминирующим слагаемым. Это означало, что модель фактически теряла информацию о вторых моментах. Вместо AdamW оптимизация начинала вести себя ближе к SGD with Momentum. В новых моделях мы уменьшили eps, после чего метрики продолжили расти дольше и выше.

Как мы тестируем pretrain-фичи

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

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

Наивный способ выглядит так: обучили baseline, обучили модель с фичей, прогнали бенчмарки, увидели +0,7 — ура, фича победила. Проблема в том, что один запуск LLM — это не истина, а один бросок кубика. Та же конфигурация на другом seed’е может приехать к другой финальной метрике, и иногда seed noise оказывается больше самого эффекта фичи.

Поэтому мы стали смотреть не на одну точку, а на распределение. Для baseline запускаем несколько seed’ов и оцениваем естественный разброс. Потом делаем то же самое для feature-сетапа и сравниваем уже две маленькие выборки: насколько сдвинулось среднее, не выросла ли дисперсия, повторяется ли эффект на разных бенчмарках и не сломалась ли стабильность обучения.

Так как запусков мало, классический A/B здесь не очень помогает. Вместо одной «магической» p-value мы используем несколько градусников: delta, std, t-test, permutation test и Bayesian bootstrapped AB. Если все они смотрят в одну сторону, дельта больше естественного шума, а служебные метрики вроде активаций и весов ведут себя спокойно, то фичу можно обсуждать всерьёз.

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

Главный вывод простой: один benchmark score — слабое доказательство. Для нас эффект фичи — это сигнал на фоне шума. И лучше потратить немного больше времени на честный маленький эксперимент, чем унести случайную удачу в полномасштабное обучение и узнать правду слишком поздно.

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

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

Float8

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

Вычисления. Все матричные умножения в обучении делятся на обычные General Matrix Multiply (GEMM) и групповые Grouped GEMM. Первые используют в обычных проекциях, вторые — в вычислениях экспертов, и обе группы мы можем выполнять в FP8.

Для стабильного и эффективного GEMM и Grouped GEMM мы взяли рецепт квантизации от DeepSeek: веса квантуем блоками 128×128, активации — блоками 1×128. Для GEMM использовали cuBLAS от NVIDIA, а для Grouped GEMM — DeepGEMM от DeepSeek, который адаптировали под нашу инфраструктуру и дополнительно ускорили.

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

Коммуникации. Все коммуникации в обучении можно разделить по типу того, что мы пересылаем — веса или активации. Первые — это fsdp, вторые — это expert parallelism-коммуникации, когда эксперты расположены на разных картах и мы пересылаем токены между устройствами. Оба вида коммуникаций мы выполняем преимущественно в FP8.

Память. С точки зрения памяти мы тоже выиграли. Поскольку мы используем activation checkpointing, то часть промежуточных активаций мы сохраняем в FP8 для пересчёта на backward-проходе. Этим мы снизили пиковое использование видеопамяти аж на 20%.

Чтобы вся инфраструктура работала слаженно и эффективно, мы написали множество ядер на Triton, а некоторые затем переписали на CUDA — там, где упёрлись в ограничения Triton.

CPU offload

На больших моделях памяти не хватает даже с activation checkpointing. Расскажем, как CPU offload отыграл нам до двух десятков гигабайт на устройство и при этом не замедлил, а ускорил обучение.

Используя activation checkpointing на больших моделях, мы столкнулись с неочевидной проблемой. Даже когда активации внутри блока не сохраняются, PyTorch всё равно должен сохранить входы в checkpointing-блоки, чтобы на backward заново выполнить forward. При сотнях миллиардов параметров эти входы сами по себе начинают занимать десятки гигабайтов GPU-памяти, поэтому мы добавили для них CPU offloading: во время forward выгружаем часть тензоров на CPU, а перед backward возвращаем обратно.

MoE decoder layer мы разбили на три checkpointing-блока: attention, MoE-блок и post norm после MoE, но перед residual. Такое разбиение оказалось важным не только для памяти, но и для производительности. Если включить post norm внутрь MoE-блока, то во время backward PyTorch пересчитает весь этот фрагмент, включая дорогую combine-операцию после экспертов. Поэтому мы вынесли post norm отдельно: так мы экономим память, но не заставляем autograd повторно выполнять дорогую коммуникационную часть MoE.

С offload пик из растущих активаций исчезает. На этом прогоне освободилось ~16 ГБ; вдобавок входы MoE-блока переведены в fp8 — 3,2 ГБ вместо 6,4 ГБ.

На бумаге CPU offloading выглядит просто: положили тензор на CPU, потом вернули обратно. На практике главная сложность возникла из-за коммуникаций. Мы копировали GPU→CPU в отдельном CUDA stream и по трейсам видели, что коммуникации, на которые накладывался offloading, иногда заметно растягиваются. Особенно это было заметно на DeepEP, слабее — на NCCL all-gather. Вывод получился практический: управлять нужно не только тем, какие тензоры выгружать, но и моментом начала выгрузки. Мы построили общее расписание выгрузок активаций и коммуникаций так, чтобы они не конкурировали, и растягивание коммуникаций ушло.

CPU offload оказался не просто ручкой для управления памятью, а рычагом ускорения обучения. Можно гибко выбирать, входы каких блоков выгружать — attention, MoE или post norm, — так что экономия настраивается примерно от 7 до 20 ГБ на устройство (432 млрд, 40 слоeв). Освободившаяся память позволила увеличить размер микробатча, это дало десятки процентов ускорения, а на длинных контекстах позволило снизить sequence parallelism и не использовать дорогие internode-коммуникации.

Alignment

Мы выстроили поэтапный пайплайн обучения: сначала SFT, чтобы модель запомнила способ общения и базовые форматы; следом DPO для первичной калибровки предпочтений; и только затем — online RL для обобщения знаний модели. Такой порядок обучения дал наиболее высокие итоговые метрики.

Обучение запускали в асинхронном режиме: train/inference-части процесса работали на разных группах вычислительных ресурсов, чтобы не простаивать и быстрее проходить шаги обучения. Для экономии памяти и ускорения использовали FP8-точность как при генерации ответов моделью, так и при её обучении. Дополнительно мы ускорили генерацию с помощью MTP.

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

На стабильность сильнее всего повлияли несколько доработок: использование R3, расчёт финальных logits в lm_head в FP32, согласованная FP8-квантизация в train- и inference-частях, а также перевод наиболее чувствительных операций в более высокую точность.

Для более стабильного обучения мы использовали skip-фильтрацию. Идея простая. В нашем алгоритме модель учится на разнице оценок между несколькими ответами на один и тот же вопрос. Но бывают вопросы, где все ответы модели оказались одинаково хороши или одинаково плохи — разницы нет, а значит, и учиться на них нечему: такой пример не несёт полезного сигнала и только зря отъедает вычисления. Skip-фильтрация отбрасывает подобные «пустые» примеры на шаге обновления весов. При этом мы сделали это аккуратно, чтобы не терять в скорости — модель просто не тратит время на то, что её ничему не учит.

Отдельно поработали над ML-частью. Главной задачей было стабилизировать асинхронный режим — когда генерация ответов и обновление модели идут параллельно, а не строго по очереди. Для этого мы взяли алгоритм CISPO (Clipped Importance Sampling Policy Optimization). Если упростить, он не даёт модели слишком резко менять поведение за один шаг. Именно такие «рывки» часто разваливают длинное обучение; CISPO их сглаживает и помогает уверенно сходиться даже на долгих прогонах. Ещё мы добавили curriculum-сэмплер — по сути, «умного преподавателя», который подбирает сложность задач под текущий этап: сначала попроще, потом сложнее. Процесс стал ровнее, а метрики — стабильно растущими.

Мы сосредоточились на пяти областях: математика, код, естественные и общественные науки и общение на русском. Для оценки диалогов использовали подход GRM (Generative Reward Models): отдельную модель-«судью», которая оценивает ответы текущей версии обучаемой модели.

Хорошая функция награды — это половина успеха. Награда должна давать модели чёткий сигнал «что такое хорошо», иначе развиваться не на чем. И здесь есть главная ловушка — reward hacking: модель находит лазейку, которая резко повышает награду, но при этом ломает адекватность ответов. Формально «оценка» растёт, по факту качество падает.

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

Решили эту проблему двумя штрафами. Доменный штраф за длину (domain overlong penalty) наказывает за многословие там, где оно не нужно, но оставляет свободу рассуждать в математике и коде, а штраф за повторы (repetition penalty) отучает модель ходить по кругу. В итоге удалось гибко управлять поведением и отучить модель «лить воду», как студент, растягивающий диплом до нужного объёма.

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

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

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

Метрики

Весь рецепт из предыдущих глав — органический датасет, доливка кодовых семплов, стабилизирующие правки архитектуры и почищенный оптимизатор — помог нам сделать значительно более сильный pretrain, на котором будут строиться модели линейки GigaChat 3.5. В общих задачах GigaChat-3.5-Ultra-Base обходит и DeepSeek V3.2 Exp Base и DeepSeek V4 Flash Base.

Математика — одна из самых сильных областей базы. В среднем на MinervaMATH, GSM8K и MGSM модель занимает первое место, уверенно опережая DeepSeek V4 Flash и DeepSeek V3.2 Exp Base.

Отдельно отметим большой прогресс в кодовых задачах. За счёт обновлённого pretrain-датасета (было 16 языков — стало более 600), модель вырывается на уверенное первое место в кодовых задачах, далеко обходя и DeepSeek V4 Flash, и DeepSeek V3.2 Exp Base. Это самый наглядный пример того, как переработка датасета влияет на финальные метрики модели.

Выше мы уже рассказывали про новинку в этом релизе — этап Online RL, который сильно помог улучшить метрики в Instruction Following и аренах. Итоговая модель, пройдя все четыре этапа посттрейнинга, сравнима с DeepSeek V3.2 по метрикам, будучи меньше её в полтора раза:

Благодаря обновлённому рецепту сборки данных и добавлению online RL наша модель стала значительно лучше предыдущей версии по мнению MiniMax-M2.7, который мы использовали в качестве LLM-судьи.

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

Вывод

GigaChat 3.5 Ultra для нас — не просто следующее число в линейке, а проверка гипотезы, что гибридную архитектуру с линейным вниманием можно довести до сотен миллиардов параметров, не разменивая качество на скорость. Проверка удалась: модель на 40% компактнее прошлого флагмана, тратит в четыре раза меньше кеша на токен, ускоряется до 2,2 раза за счёт MTP — и при этом стала сильнее в коде, математике и агентных сценариях. Ключевым оказался не какой-то один трюк, а дисциплина: каждая ускоряющая фича шла в связке со стабилизирующей, каждое изменение проверяли на распределении запусков, а не на одной удачной точке.

Мы выкладываем модель в open source, потому что верим, что такие рецепты нужно проверять сообществом, а не только внутренними бенчмарками. Веса доступны на HuggingFace и GitVerse под MIT.

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