Спасибо за пост! Обожаю энкдеки, считаю, что они были незаслуженно забыты — отдельное спасибо за Apache 2.0 в лицензии :)
У меня два вопроса:
Очевидно, при мультитерне у энкдеков будут проблемы из-за кв кеширования. Я слышал, что вы решаете эту проблему засчет того, что ставите на мультитерн диалоги декодерную модель. Если это так, то перечитывание контекста декодером для ответа не факт, что будет быстрее, чем перечитывание того же контекста энкдеком — получается, такое решение было сделано из-за низкого качества ответов энкдека в мультитерне. Это так? Это фундаментальное свойство энкдека или практика обучения?
Веса это хорошо, но где их запускать? Нет ли у вас планов опенсорсить движок для инференса ваших энкдеков?
Не очень понимаю в чём заключаются догадки -- архитектура != общая база в виде одной и той же базовой модели. Повторюсь, претрейн шёл с нуля, в отличие от коллег из Яндекса, которые действительно инитятся квенами.
Это было сделано для двух вещей: максимальной совместимости с существующим инструментарием и из-за проверенности архитектуры в сообществе. Kimi K2/2.5, Mistral Large 3 и Small 4 -- всё это модели с полностью такой же архитектурой, как и DeepSeek V3. Идея MLA крайне удачная, fine grained expert segmentation повышает эффективность и скейлинг у такой архитектуры очень удачный. При этом, данные у нас свои и претрейн свой -- мы не инициализируем наши модели весами других моделей и обучение нашей модели начинается с заполнения весов шумом.
В линейке GigaChat-2 были модели Lite, Pro и Max, то есть маленькая модель для простых задач типа классификации (аналогичная по мощности Lightning), средняя по мощности модель и флагманская для самых сложных задач. Из-за изменения архитектуры с Dense на MoE, мы смогли увеличить скорость генерации и эффективность инференса Ultra модели по сравнению с Max в два раза, увеличив мощность модели.
GigaChat-2 был dense моделью, DeepSeek V3 Instruct это MoE модель, причём очень большого размера -- 671B, это сильно больше, чем GigaChat-2, так что это предположение абсолютно неверно.
Мы не обфусцируем веса, потому что обфусцировать нечего -- мы делаем претрейн моделей с нуля. Наши модели инициализируются шумом и имеют уникальные сетапы, хотя и имеющую с ними общую архитектурную базу в виде DeepSeek V3 MoE.
Архитектурное сравнение GigaChat V3 Ultra с DeepSeek V3.1 и Kimi K2
Насчёт V3.2 и V4 -- работа над развитием нашей линейки моделей уже идёт и нам не терпится показать, что мы готовим дальше, но всему своё время.
MXFP4 и NVFP4 поддерживается только на Blackwell (и Vera Rubin), но их пока очень мало, адопшен не начался.
В опенсорс контрибьютят в основном китайцы, у них нет Blackwell. У китайцев есть H200, они выкручиваются тем, что делают QAT в int4, который на хопперах поддерживается.
Учить модели в FP4 сложно, обучение очень нестабильное и там приходится придумывать дофига хаков, чтобы оно хоть как то завелось. Из прикольного -- округление там делается в рандомную, а не более близкую сторону для стабилизации обучения, хотя казалось бы.
Как только адопшен начнётся (я ожидаю, что это будет к лету-осени), сразу полетят модели в NVFP4. И, кстати, покупка DGX Spark как домашней хоумлабы, станет гораздо более выгодным приобретением :)
Я не уверен, но кажется, llama.cpp это не про скорость, а про то, что модель можно будет запустить на любом чайнике. Например, новые модели можно гонять через llama.cpp даже на nvidia p100, которая вышла ещё до того, как я пошёл в универ.
Sglang же это штука, которая предназначена для максимизации throughput на новых картах. Volta там, например, поддерживается очень плохо.
Исходя из этого, если есть GPU, используйте SGLang. Если нет -- llama.cpp будет оптимальным вариантом.
>Также наследуют «ценности» модели-донора с запретом говорить на определенные темы, которые не нарушают законы РФ и наоборот
А вы на каком-то другом c4 учили что ли? С чего бы гигачату лайт не выучить ценности с условного реддита, всё равно данных в претрейне на английском больше, чем на русском. Или нет?
А будет PR в llama.cpp? 20b модель в консумерские (24 гб) карты не влезет, а на цпу не получится гонять, потому что, как я понял, там кастомный код. Или там просто дипсик и можно запускать и так?
Планируются ли замеры моделей на других бенчмарках? Кроме меры интересно, например, видеть результаты на IfEval, той или иной вариации MMLU.
Как модель себя показывает в сравнении с базовой Qwen-2.5-1.5B?
Пробовали её в speculative decoding? Насколько она ускоряет генерацию (e.g. насколько много сгенерированных токенов отбрасываются моделью большего размера как некорректные) в сравнению с базовой моделью?
И, самое главное, как она отвечает на вопрос о видах столовых приборов?)
Переход с архитектуры Decoder на Encoder‑Decoder. Если кратко, то раньше модель состояла из одного основного элемента — декодера. Он пытался сделать два дела одновременно: понять суть текста с ошибками и исправить их.
Но при этом,
Мы дообучили модель редактора на задачи, которые отличались от базовых. Это позволило заинферить модель на основе YandexGPT 3 Light, но при этом не просесть в качестве относительно результатов работы модели версии YandexGPT 3 Pro.
Правильно я понимаю, что YaGPT тут для дописывания, генерации и фактчека, а для парафразы, исправления и улучшения энкдек?
Есть ли подробности об архитектуре энкдека? Учили полностью своё, резали mt0/aya-101, тюнили FRED-T5? Есть ли итоговые метрики? Будет ли модель где-то доступна, кроме внутреннего продукта (подозреваю, что я уже знаю ответ, но чем чёрт не шутит)?
Спасибо за пост! Обожаю энкдеки, считаю, что они были незаслуженно забыты — отдельное спасибо за Apache 2.0 в лицензии :)
У меня два вопроса:
Очевидно, при мультитерне у энкдеков будут проблемы из-за кв кеширования. Я слышал, что вы решаете эту проблему засчет того, что ставите на мультитерн диалоги декодерную модель. Если это так, то перечитывание контекста декодером для ответа не факт, что будет быстрее, чем перечитывание того же контекста энкдеком — получается, такое решение было сделано из-за низкого качества ответов энкдека в мультитерне. Это так? Это фундаментальное свойство энкдека или практика обучения?
Веса это хорошо, но где их запускать? Нет ли у вас планов опенсорсить движок для инференса ваших энкдеков?
Спасибо за ответы)
На giga.chat и тг/etc уже раскатили, да
В конце статьи есть ссылки на HF и GitVerse:
https://huggingface.co/collections/ai-sage/gigachat-35
https://gitverse.ru/GigaTeam/gigachat3.5
В ноябре мы выложили базовую модель только для 10b версии: https://huggingface.co/collections/ai-sage/gigachat3. Планов выкладывать базовую модель для Ultra, насколько я знаю, нет.
В статье описан лишь посттрейн, потому что процесс претрейнинга со времён предыдущего релиза в ноябре не менялся. Больше про ноябрьский релиз можно прочитать в статье: https://habr.com/ru/companies/sberdevices/articles/968904/
Не очень понимаю в чём заключаются догадки -- архитектура != общая база в виде одной и той же базовой модели. Повторюсь, претрейн шёл с нуля, в отличие от коллег из Яндекса, которые действительно инитятся квенами.
Привет!
Это было сделано для двух вещей: максимальной совместимости с существующим инструментарием и из-за проверенности архитектуры в сообществе. Kimi K2/2.5, Mistral Large 3 и Small 4 -- всё это модели с полностью такой же архитектурой, как и DeepSeek V3. Идея MLA крайне удачная, fine grained expert segmentation повышает эффективность и скейлинг у такой архитектуры очень удачный. При этом, данные у нас свои и претрейн свой -- мы не инициализируем наши модели весами других моделей и обучение нашей модели начинается с заполнения весов шумом.
В линейке GigaChat-2 были модели Lite, Pro и Max, то есть маленькая модель для простых задач типа классификации (аналогичная по мощности Lightning), средняя по мощности модель и флагманская для самых сложных задач. Из-за изменения архитектуры с Dense на MoE, мы смогли увеличить скорость генерации и эффективность инференса Ultra модели по сравнению с Max в два раза, увеличив мощность модели.
Привет!
GigaChat-2 был dense моделью, DeepSeek V3 Instruct это MoE модель, причём очень большого размера -- 671B, это сильно больше, чем GigaChat-2, так что это предположение абсолютно неверно.
Мы не обфусцируем веса, потому что обфусцировать нечего -- мы делаем претрейн моделей с нуля. Наши модели инициализируются шумом и имеют уникальные сетапы, хотя и имеющую с ними общую архитектурную базу в виде DeepSeek V3 MoE.
Насчёт V3.2 и V4 -- работа над развитием нашей линейки моделей уже идёт и нам не терпится показать, что мы готовим дальше, но всему своё время.
Мне кажется, что это по трём причинам:
MXFP4 и NVFP4 поддерживается только на Blackwell (и Vera Rubin), но их пока очень мало, адопшен не начался.
В опенсорс контрибьютят в основном китайцы, у них нет Blackwell. У китайцев есть H200, они выкручиваются тем, что делают QAT в int4, который на хопперах поддерживается.
Учить модели в FP4 сложно, обучение очень нестабильное и там приходится придумывать дофига хаков, чтобы оно хоть как то завелось. Из прикольного -- округление там делается в рандомную, а не более близкую сторону для стабилизации обучения, хотя казалось бы.
Как только адопшен начнётся (я ожидаю, что это будет к лету-осени), сразу полетят модели в NVFP4. И, кстати, покупка DGX Spark как домашней хоумлабы, станет гораздо более выгодным приобретением :)
Я не уверен, но кажется, llama.cpp это не про скорость, а про то, что модель можно будет запустить на любом чайнике. Например, новые модели можно гонять через llama.cpp даже на nvidia p100, которая вышла ещё до того, как я пошёл в универ.
Sglang же это штука, которая предназначена для максимизации throughput на новых картах. Volta там, например, поддерживается очень плохо.
Исходя из этого, если есть GPU, используйте SGLang. Если нет -- llama.cpp будет оптимальным вариантом.
Ещё вроде бы у сберклауда была бесплатная виртуалка, к которой надо было докупить публичный айпишник за 150 рублей в месяц. Вроде бы вполне бюджетно.
>Также наследуют «ценности» модели-донора с запретом говорить на определенные темы, которые не нарушают законы РФ и наоборот
А вы на каком-то другом c4 учили что ли? С чего бы гигачату лайт не выучить ценности с условного реддита, всё равно данных в претрейне на английском больше, чем на русском. Или нет?
А будет PR в llama.cpp? 20b модель в консумерские (24 гб) карты не влезет, а на цпу не получится гонять, потому что, как я понял, там кастомный код. Или там просто дипсик и можно запускать и так?
Тут gemma-2-9b или gemma-9b? Судя по метрикам, это gemma-2, но мало ли, вдруг я что-то перепутал...
Планируются ли замеры моделей на других бенчмарках? Кроме меры интересно, например, видеть результаты на IfEval, той или иной вариации MMLU.
Как модель себя показывает в сравнении с базовой Qwen-2.5-1.5B?
Пробовали её в speculative decoding? Насколько она ускоряет генерацию (e.g. насколько много сгенерированных токенов отбрасываются моделью большего размера как некорректные) в сравнению с базовой моделью?
И, самое главное, как она отвечает на вопрос о видах столовых приборов?)
Но при этом,
Правильно я понимаю, что YaGPT тут для дописывания, генерации и фактчека, а для парафразы, исправления и улучшения энкдек?
Есть ли подробности об архитектуре энкдека? Учили полностью своё, резали mt0/aya-101, тюнили FRED-T5? Есть ли итоговые метрики? Будет ли модель где-то доступна, кроме внутреннего продукта (подозреваю, что я уже знаю ответ, но чем чёрт не шутит)?