Салют, хабр!

В ноябре мы выложили в open source preview-версии GigaChat-3-Ultra (702B MoE) и GigaChat-3-Lightning (10B MoE). С тех пор мы провели большую работу над нашими моделями, и сегодня выпускаем обновлённые GigaChat-3.1-Ultra и GigaChat-3.1-Lightning. По нашим замерам, Ultra обходит non-reasoning Qwen3-235B-A22B и DeepSeek-V3-0324 в математике и general reasoning, а Lightning на аренах с судьёй GPT-4.1 играет на уровне GPT-4o — при 1,8 млрд активных параметров. Модели, как и раньше, лежат на HuggingFace и GitVerse под MIT.

Но этот пост — не только про числа в таблицах. Переезд на новую архитектуру дался нам нелегко: переход от Dense-моделей к MoE вскрыл несколько проблем, о которых мы раньше не думали. По дороге к релизу мы полностью победили проблему зацикливания генераций (и придумали для этого метрику на основе BPE-сжатия хвоста), перевели DPO-этап в нативный FP8, получив качество выше bf16 при вдвое меньшем потреблении памяти, нашли критичный баг в SGLang при dp > 1, который роняет качество, и выяснили, что GPT-OSS-120b — неожиданно хорошая замена проприетарным судьям на аренах. Под катом — подробности о каждом из этих сюжетов: что ломалось, какие гипотезы не сработали, и что в итоге помогло.

Как боролись с циклами

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

…Тропики. Обжигающее солнце. Пальмы. Пальмы. Пальмы. И жара, жара, жара. И океан, океан, океан. И песок, песок, песок. И кокосы, кокосы, кокосы. И ананасы, ананасы, ананасы. И бананы, бананы, бананы…

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

Про метрики

Мы не можем решать проблему, которую нельзя измерить. Изначально у нас было несколько метрик для измерения циклов, но целевой метрикой была CYCLES. Эта метрика состояла из набора семплов, на которых модели часто циклились, и скрипта, вычисляющего число циклов на основе z-функции. Пока вопрос с циклами не стоял так остро, метрика CYCLES работала неплохо, но не отображала всей картины целиком. Из-за этого мы решили сделать другую метрику, которая была бы и быстрее (z-функция на длинных последовательностях могла работать ОЧЕНЬ долго), и репрезентативнее.

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

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

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

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

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

Как искали проблему

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

Проблемы в данных. Первое что приходит в голову — в данных есть семплы, которые заставляют модель циклить; или наоборот, в данных нет семплов, которые заставляют модель не циклить. После нескольких перепроверок наших наборов SFT и DPO мы пришли к выводу, что в данных проблемы нет. Более того, в наборе DPO есть «антициклин»-семплы, которые помогали модели циклить меньше, поэтому именно этот этап оказался ключевым для решения проблемы зацикливания, а с данными было всё хорошо.

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

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

Одна из гипотез, почему наши модели начинали циклиться, была в том, что SFT-этап приводил к нарушению баланса экспертов. Всё же на этапе SFT по сравнению с pretrain распределение меняется очень сильно: текст перестаёт быть неструктурированным. Кроме того, при SFT появляются паддинги, наличие которых надо тоже учитывать при расчёте статистик балансировки. Например, для подсчета статистик под специализированный loss для балансировки нагрузки по экспертом внутри одного запроса (sequence auxillary loss) в SFT-режиме при использовании sequence_parallelism-а не хватает простого all_reduce для усреднения по всем рангам, необходимо учитывать количество токенов с каждого ранга при взвешивании среднего.

Наконец, на SFT-этапе loss считается не по всем токенам, префикс в виде запроса маскируется и обучение происходит только на желаемых ответах модели. Более того, необучаемые префиксы обычно имеют схожие паттерны (системный промпт, например). Всё это заставляет задуматься, а стоит ли балансировать нагрузку экспертов по всем токенам, или лучше балансировать loss только по обучаемым токенам, игнорируя системные промпты?

В процессе подготовки к новому SFT этапу мы учли все описанные выше особенности и провели серию экспериментов, попробовав снижать (и даже полностью выключать!) deepseek-like балансировки (подход loss free и sequence auxillary loss) и исключать из балансировки паддинг- и префикс токены. В результате выяснилось, что модель достаточно быстро адаптируется к новому распределению данных, стабилизируя балансировку самостоятельно, а дополнительные балансировки ухудшают качество финальной модели, поэтому мы их не использовали. Баланс в итоге работал отлично, и это не было причиной появления циклов.

На каком этапе появляются циклы? Следующим шагом была проверка, на каком этапе обучения возникает проблема циклов. Мы замерили CYCLES после каждого этапа пайплайна (pretrain → stage 1.5 → SFT → DPO), включая претрейн с простым chat template, которому могла следовать базовая модель. Ключевое наблюдение: корнем проблемы является этап расширения контекста на претрейне. SFT на контексте в 4096 токенов практически не циклит, тогда как SFT на 32 тыс. циклит заметно: больше контекст, больше вероятность зациклиться. Все последующие этапы обучения эту проблему только уменьшают, причём с выраженным эффектом холодного запуска: чем меньше циклов было на предыдущем этапе, тем меньше их остаётся на следующем. Отдельно стоит отметить, что грамотный выбор гиперпараметров на каждом этапе влиял на циклы даже сильнее, чем выбор данных.

Баг в SGLang. Во время отладки циклов и замеров метрик мы заметили интересную особенность: при повышении DP количество циклов у моделей (причём не только наших!) росло, а скорость инференса значительно падала. После небольшого расследования выяснилось, что мы нашли критичный баг в SGLang, который проявляется при dp > 1 в сочетании с batched-запросами к API. На всех версиях, начиная с 0.5.3 вплоть до актуальной 0.5.9, модель начинает зацикливаться, повторяя куски генераций, а вычисления дублируются на всех DP-рангах, что искажает результаты замеров. Особенно это было заметно в кодовых задачах, где на Qwen3-8B результаты на HumanEval падали с 0,63 аж до 0,43. Кроме того, этот баг сводит на нет выигрыш от горизонтального масштабирования на одной ноде, а в случае небольших моделей с DP=8 доля лишнего вычисления в общем времени выполнения становится критической.

python -m SGLang.launch_server \
  --model-path Qwen/Qwen3-8B-Base \
  --tp 1 \
  --dp 8 \
  --host 0.0.0.0 \
  --port 30000

import requests
URL = "http://localhost:30000/generate"
TOKENS = [
    1499, 19496, 1159, 1759, 1406, 750, 8651, 620, 9151, 21148, 49622, 3904,
    25, 607, 8, 1464, 1759, 17303, 10343, 262, 4210, 5571, 311, 419, 729, 374,
    264, 914, 8482, 5248, 5203, 315, 24034, 73975, 13, 4615, 5795, 374, 311,
    198, 262, 8651, 1846, 1874, 1119, 8651, 9069, 323, 470, 279, 1140, 315,
    1846, 624, 262, 76140, 5203, 525, 23831, 320, 9547, 1787, 32864, 374,
    10277, 7877, 8, 323, 537, 24034, 2878, 1817, 1008, 198, 262, 38971, 894,
    12621, 304, 279, 1946, 914, 624, 262, 12109, 8651, 620, 9151, 21148, 69963,
    873, 1781, 11985, 1781, 40612, 11985, 1305, 262, 2509, 61413, 22022, 2140,
    516, 364, 5065, 2140, 4432, 262, 3190, 257
]
SAMPLING_PARAMS = {
    "max_new_tokens": 1024,
    "temperature": 0.0,
    "stop": ["\nclass", "\ndef", "\n#", "\nif", "\nprint", "<|endoftext|>"],
}
def send_request(batched: bool = False):
    payload = {
        "input_ids": [TOKENS] if batched else TOKENS,
        "sampling_params": SAMPLING_PARAMS,
    }
    resp = requests.post(URL, json=payload, timeout=300)
    print("status_code:", resp.status_code)
    print(resp.text)
if __name__ == "__main__":
    print("=== single [] ===")
    send_request(batched=False)
    print("\n=== batched [[]] ===")
    send_request(batched=True)

Перебор гиперпараметров. Переход на MoE потребовал пересмотра гиперпараметров на каждом этапе обучения — scaling laws из обучения dense моделей оказались неприменимы напрямую. На этапе SFT и Stage 1.5 кроме вышеописанного перебора параметров балансировки мы перебрали другие варианты LR и шедулеров. Одно из ключевых отличий от dense моделей оказалась чувствительность моделей к числу эпох. Рост был очень медленный — один из экспериментов добрался до целевого значения CYCLES только спустя двадцать (!) эпох — но он был. По результатам экспериментов, мы выяснили, что под нашу модель и датасеты оптимально было увеличить lr в сравнении с нашими dense моделями и сделать менее затухающий constant scheduler. Это и помогло нам улучшить холодный старт для DPO этапа в плане метрик, и уменьшило число циклов. Вывод: гиперпараметры, которые кажутся оптимальными по метрикам на бенчмарках, могут давать артефакты, например, в виде циклов и для MoE таких ловушек может быть больше.

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

• Чем больше global batch size, тем лучше. Финальные модели мы учили со значением global batch size 1024 или 512. По сравнению с меньшими значениями у нас росли и арены, и обычные метрики, и, что важнее всего, метрики циклов.

• Чем больший вклад вносит DPO (через больший LR, dpo_loss_coef или beta_chosen), тем меньше модель циклит — но и тем проще ломается.

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

Это, разумеется, не все гипотезы и эксперименты, которые мы провели. Были и гипотезы, которые не «выстрелили». Мы переучивали претрейны на разных сабсетах, пытаясь улучшить холодный запуск и понять влияние данных на циклы. Мы сравнивали наши alignment-пайплайны с open source и нашими прошлогодними. Мы исправляли баги в замерах метрик и в наших темплейтах. Мы пытались поправить циклы через изменение параметров семплирования — repetition/frequency penalty и температуры. Но ничто из этого не дало значимого прироста, и лишь более тонкий подбор гиперпараметров под каждый этап обучения модели позволил нам почти полностью решить проблему циклов. Мы выбили метрику 97,6 на CYCLES и улучшили результат на BPE_CYCLES с 0,75 до 0,9. Это означает практически полное отсутствие зацикливаний, даже на сложных примерах.

Ускорение обучения

Учить большие модели дорого, поэтому всегда ведётся работа по повышению утилизации карт и уменьшению времени экспериментов. Мы поработали над оптимизацией наших пайплайнов SFT, ускорив обучение в три раза по сравнению с «наивным обучением», используя по-умному настроенный sequence packing, dynamic SP и ещё один секретный трюк. На контексте размером 256 тыс. токенов скорость может возрастать десятикратно.

Короткие и средние диалоги упаковывали в пакеты до 32 тыс. токенов, что резко уменьшало padding и повышало потребление GPU. Мы сознательно не переводили весь датасет в режим 128k/256k, потому что для большинства примеров это не даёт дополнительного сигнала, но заметно увеличивает стоимость шага по памяти и коммуникациям. Поэтому окно большого размера использовали только там, где оно действительно нужно — для диалогов длиннее 32 тыс. токенов.

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

Итоговая комбинация этих двух трюков ускоряет обучение приблизительно в три раза. Но гораздо сильнее ускорение мы почувствовали, когда в дополнение к dynamic sp и sequence packing отказались от использования длинных (1000 токенов) devsystem-ов в пользу коротких (300 токенов). Иногда банальная работа с данными помогает не меньше, чем сложные и красивые инженерные решения :) 

DPO

Десять месяцев назад, в посте про GigaChat-2-Max, мы уже писали про используемую нами вариацию DPO:

Относительно стандартной формулировки DPO, в нашем loss-е мы можем использовать различные значения beta_chosen и beta_rejected для лучшей балансировки зазора между плохим и хорошим ответами и добавляем отношения NLL референсной и обучаемой модели для лучшей балансировки. 

В GigaChat-3-Ultra-Preview и GigaChat-3-Lightning-Preview DPO не было, но в этом релизе мы вернулись к этому этапу с некоторыми улучшениями, вызванными в том числе переходом на новую архитектуру:

• MTP: на претрейне и на SFT модель обучается с MTP-блоками для ускорения инференса. Для лучшей консистентности основных предсказаний модели и MTP мы добавили обучение MTP-голов также на этапе DPO. Коэффициент мы использовали тот же, что и на pretrain- и SFT-этапах.

• Weighted gamma: мы добавили экспоненциальное затухание по мере удлинения последовательности. Важно, что уменьшение веса токенов начиналось только с первых различающихся токенов у chosen- и rejected-примеров.

В результате наш loss стал выглядеть так:

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

Обучение в FP8

Когда мы начинали экспериментировать с квантованием наших языковых моделей, мы использовали post training quantization (PTQ) в FP8. Это позволяло нам без особых сложностей уменьшать размер моделей в два раза и ускорять инференс. В случае с 702-миллиардным титаном в лице GigaChat-3-Ultra это особенно важно, ведь чем меньше памяти занимает чекпоинт модели, тем меньший expert/tensor parallel мы можем выставить, минимизировав пересылки между нодами и ещё сильнее ускорив инференс. При этом метрики на бенчмарках, казалось бы, практически не проседали.

Однако, когда мы начали измерять наши модели на аренах, выяснилось, что судьи гораздо реже предпочитают модели с FP8 PTQ моделям в BF16. Архитектурно это объясняется очень просто: трансформеры — это resnet-модели, то есть каждый трансформерный блок добавляет в общий residual stream свою часть сигнала. Если этот сигнал квантованный до FP8 — а мы используем W8A8 квантизацию, — то неизбежно накапливается ошибка, которая приводит к изменениям в генерации.

На структурно простых бенчмарках, вроде MMLU, модели хватает уверенности в top-1 токене, чтобы не понизить качество. Но если мы оцениваем длинные генерации с помощью нечёткой оценки судьями, то там ошибка копится, качество «плывёт» и модель опускается в списке лидеров.

Чтобы побороть этот эффект, мы решили обучать DPO-этап в FP8-качестве, причём даже на 10-миллиардной модели. Так как наши модели архитектурно схожи с Deepseek, мы решили обучать и квантовать их полностью аналогично их подходу. Основной стек состоит из библиотеки DeepGEMM от DeepSeek, адаптированной под нашу инфраструктуру, самописных Triton- и CUDA-ядер для квантования, реквантования rowwise-to-columnwise , fused-операций (un-)permute и (un-)padding и оптимизированного SwiGLU.

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

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

Локальные арены

Для того, чтобы можно было отслеживать качество DPO модели, можно воспользоваться автоматическими замерами кандидатов на аренах. Работает это так: мы сравниваем генерацию нашей модели-кандидата с некоторым бейзлайном с помощью LLM-as-a-Judge, а потом с помощью бутстрапирования получаем результат, в скольких случаях наша модель побеждает. Для того, чтобы избежать position bias, такая оценка проводится в двух вариантах: бейзлайн против кандидата и кандидат против бейзлайна. Оба сравнения учитываем как отдельные «битвы» внутри арены и можем выкинуть при бутстрапировании.

В оригинальных репозиториях arena-hard-auto для замеров арен используются судьи от OpenAI: GPT-4.1, GPT-4 и так далее. При этом использовать судей через API получается достаточно накладно, ведь один замер четырёх целевых арен стоит в районе 180 долларов. Поэтому мы решили попробовать исследовать, какие локальные модели мы можем использовать вместо проприетарных судей.

Казалось бы, задача очень простая: берём Qwen-3-30b и используем его. Он быстрый, неплохо знает русский язык, влезает в одну карту и хорошо зарекомендовал себя в сообществе. Однако, после ряда экспериментов выяснилось, что Qwen-3-30b сильно завышает метрики относительно эталонного судьи в лице GPT-4.1, и в ряде случаев даже меняет ранжирование моделей в списке.

Также мы попробовали использовать Kimi-K2 и DeepSeek-V3.2, но они оказались слишком большими и неповоротливыми: для подъёма этих моделей нужно было занимать до четырёх нод (!) и ждать развёртывания 30-60 минут. Внезапным фаворитом оказалась GPT-OSS-120b. Она очень быстрая, из-за MXFP4 QAT умещается в одну карту (даже не ноду!) и показывает отличные корреляции с бейзлайновым судьёй.

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

Данные

В новой версии данных для GigaChat-3.1-Ultra мы провели большую работу над улучшением обучающих данных. На этапе Stage-1.5 мы существенно расширили покрытие сложных доменов через работу с данными по математике, финансам, физике, инженерии, биологии, химии и медицине, подготавливая более сильный холодный старт для дальнейших этапов обучения модели.

Мы не только собрали больше данных под сложные домены, но и усилили требования к их качеству. Сделать это нам помогла наша система строгих проверок “Ревизор”. В числе прочего, в неё мы добавили расширенные проверки корректности Markdown, LaTeX и соблюдения форматов ответов. Также мы активно использовали пайплайн LLM-судей для валидации данных на этапах SFT и DPO. Для каждого диалога в данной системе происходит подбор судей, заточенных на его специфику, с учетом типа задачи и структуры ответа. Подобный подход позволяет перейти от общей проверки данных по единым правилам к более точечной валидации.

Для этапа DPO мы генерировали ответы в on-policy режиме,  то есть на основе поведения наших preview-моделей. Благодаря этому DPO пары лучше соответствовали реальным ошибкам и давали более сильный эффект при обучения.

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

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

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

Итоговые метрики

По сравнению с нашим ноябрьским релизом модели сильно улучшились. Особенно сильно подросла математика, General Reasoning и вызов функций: по результатам наших замеров мы обошли non-reasoning версию Qwen3-235B-A22B и DeepSeek-V3-0324.

Благодаря DPO-этапу в нативном FP8 наша модель теперь не только очень быстрая, но и значительно более «вайбовая», на аренах сильно обходит DeepSeek-V3-0324 и почти сравнялась с Qwen3-235B-A22B-Non-Thinking.

GigaChat Lightning Preview всё ещё остаётся одной из лучших в своём размере моделей, играя на равных с Qwen-3-4B-Instruct-2507, но далеко обходя её по скорости за счёт MoE-архитектуры с 1,8 млрд активных параметров и MTP. Отдельно стоит отметить качество вызова функций – модель не имеет равных ни в своём размере, ни среди более тяжёлых моделей.

\В сравнении с моделями из более тяжёлой весовой категории, GigaChat-3-Lightning лучше, чем GigaChat-2-Lite, но значительно быстрее неё.

Но главным улучшением GigaChat-3.1-Lightning относительно ноябрьского релиза является её alignment. На наших аренах в сравнении с моделями аналогичного размера GigaChat-3.1-Lightning является одной из лучших, отвечая на одном уровне с бейзлайном в виде GPT-4o.

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

Все замеры выполнены на vllm 0.17.1rc1.dev158+g600a039f5, concurrency=32, 1xH100 80gb SXM5. Код для воспроизведения.

Заключение

За четыре месяца после ноябрьского preview мы пересобрали весь пайплайн постобучения: избавились от циклов, значительно улучшили результаты как на аренах, так и на обычных бенчмарках, сильно улучшили качество вызова функций, перевели DPO-этап в нативный FP8 (что дало качество выше BF16 при вдвое меньшем потреблении памяти), автоматизировали замеры арен и нашли критичный баг в SGLang. Модели, как и раньше, лежат на HuggingFace и GitVerse под MIT и доступны на всех поверхностях Гигачата.

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