Егорка думает, что

GigaChat 3.5 Ultra 432B Выпустили в опенсорс новое поколение нашей модели. Уникального в этом релизе — своя собственная архитектура (MLA + GatedDeltaNet + Gated Normalization — GN это наша придумка), новый претрейн на другом миксе данных, фулл fp8 обучение, не только дпо степ, наконец-то завезли онлайн рл и сильно улучшили арены. Модель похудела на 40% (теперь влезает в одну ноду без tp16) и сильно ускорилась из-за MTP2 и гибридной архитектуры — мы смогли выбить 260 тпс на 8xH100. В этот раз мы решили не ограничиваться только финальным чекпом, выложив еще и кучу служебных — четыре чекпа с разных степов претрейна, два с мидтрейна, один с расширения контекста, один после дпо и два финальных, после онлайн рл — в fp8 и bf16. Теперь вы можете взять нашу модель и доучить её самостоятельно — передаём эстафету коллегам из Яндекса, ждём новую Алису на зелёной базе :) По метрикам — претрейн идёт ноздря в ноздрю с DeepSeek V4 Flash Base, а финальный наш чекп сравним с DeepSeek V3.2. По сравнению с гигой 3.1 у нас сильно улучшились арены, код, агентность, тулколлинг и математика — в общем, меньше, быстрее, сильнее. Из смешных историй, связанных с разработкой, не вошедших в хабр — в какой-то момент на онлайн рл этапе модель смекнула, что можно хакнуть судью, если писать более эротичные ответы. Слава богу отучили, а то получилось бы неловко. В этом релизе я ушёл из SFT команды гигачата, став главой команды метрик. На мне были задачи по выстраиванию нашей инфраструктуры замеров и придумыванию новых бенчмарков — так что если вам не нравится выбор бенчей, который мы замерили, как обычно, приходите к нам его чинить :) HF: https://huggingface.co/collections/ai-sage/gigachat-35 Habr: https://habr.com/ru/companies/sberbank/articles/1055826/

В планах на ближайшее время у меня дописать пост про пд дизагрегацию, потом, думаю, либо про all-to-all с all-reduce напишу, либо elastic EP, либо про overlap scheduler поговорим. Это я так, чтобы себя в какие-то рамки по срокам загнать и чтобы вы про то что мой канал существует не забывали

Это кстати считается за 3 поста

Ребята из Thinking Machines Labs эту всю проблему решили, придумав batch-invariant computation. Суть в чем, давайте сделаем так, чтобы ядра для матмула, рмснорма и атеншена давали одинаковый результат вне зависимости от размера батча путём того, что мы фиксируем порядок операций внутри ядра. Конкретно мысль какая: матмул по дефолту при малых батчах использует сплит-к, это когда K-размерность (по которой идёт скалярное произведение) разбивается на куски, считается параллельно, потом складывается. Batch-invariant matmul от сплит-к отказывается вообще, всегда использует один и тот же data-parallel тайлинг. С рмснормом ситуация аналогичная, фиксированное разбиение по hidden dim независимо от количества активных SM. Атеншен — фиксированный размер KV-splits, никакой адаптации под длину последовательности или загрузку GPU. Всё это впихнули в sglang под флаг —enable-deterministic-inference и получили детерминизм ценой того, что производительность пупупу. Больше чем вполовину теряем по скорости, это грусть-печаль. Я вот это всё к чему. Я для себя недавно открыл LLM-42, Майкрософт рисерч придумал. Ребята увидели, что дивергенция, то есть расхождение, это не такое уж частое событие, большинство токенов генерируются с такой уверенностью, что даже при разных схемах редукции аргмакс возвращает одно и то же, а проблемными остаются те токены, у которых два-три кандидата с примерно одинаковыми логитами. Но в силу того, что даже один токен уже меняет контекст, последовательности начинают расходиться сильнее и все это yet again аккумулируется. Собсна, идея простая. Генерируем последовательности обычными ядрами, проверяем раз в N времени не случилась ли дивергенция, если случилась - откатываемся, исправляем. Decode-Verify-Rollback. Реализация вот так выглядит: есть два пути, fast-path с обычным динамическим батчингом и верификатор, форвард с фиксированным батчсайзом, который дает ground truth. Фастпасс дает кандидатные токены, верификатор параллельно проверяет их, беря за точку отсчёта последний известно-корректный токен, первый токен из префилла, детерминированный по конструкции потому что префилл всегда обрабатывается одним запросом с фиксированным батчем. При этом помним что у фастпасса кв нестабилен, он был посчитан при одном батчсайзе, если его оставить, то форварды будут наследовать численный дрейф, поэтому при каждой верификации мы перезаписываем кв фастпасса консистентными значениями от верификатора. Для того, чтобы верификатор не боттлнэчил, вместо того чтобы накапливать W (где W - батч-сайз верификатора и количество токенов, что верификатор проверяет) токенов одного запроса, мы набираем K токенов от каждого из N запросов, получая W = N * K. Таким образом верификатор работает над нормальным батчем, мы нормально утилим гпу и выигрываем в несколько (!) раз по производительности от стандартной реализации детерминизма в сгланге. Вывод простой, люди опять изобрели спекдек и он опять великолепен.

А еще бывает ситуация, когда нужно получить гарантированно воспроизводимый одинаковый результат, детерминированный то есть. И вот чудо - даже гриди не решает эту задачу. Дело в том, что в зависимости от размера батча, результат может быть разный - потому что форвард-пасс на батчах численно нестабилен. В вычислительной схеме трансформера куча мест, где мы сравниваем циферки сильно разного масштаба, в матрицах весов, в атеншене, в РМСнорме. В числах с плавающей точкой ограниченный размер мантиссы, в bf16 у нас 7 бит, в fp16 - 10. Это значит, что число в таком формате может хранить не больше определенного количества значих цифр. Придумаем ситуацию, с 3 корзинами с яблоками. Если у нас есть две корзинки, в которых у нас по 0.01 яблоку, ну то есть по очень маленькому кусочку, у нас теперь два кусочка яблока. В третьей корзинке, что нам дают, лежит 10 тысяч яблок, и теперь у нас 10 тысяч яблок и еще два кусочка. Но если бы мы изначально получили 10 тысяч яблок, эти два кусочка, согласитесь, были бы уже не так важны. 10000 - это 5 значащих цифр только для целой части, если мы прибавим еще 0.01, бит для новой части просто не хватит, они потеряются в округлении, то есть в bf16 10000 + 0.01 ~ 10000.0, при этом если сначала сложить все мелкие части, то они соберутся в что-то достаточно крупное, чтобы выжить рядом с большим числом. Это все называется catastrophic cancellation и это причина, почему в вычислениях с плавающей точкой (a + b) + c != a + (b + c). Стандарт IEEE 754, почитайте. Собсна, вот вам пример: import torch a = torch.tensor(10000.0, dtype=torch.float16) b = torch.tensor(0.01, dtype=torch.float16) c = torch.tensor(0.01, dtype=torch.float16) print((a + b) + c) # tensor(10000., dtype=torch.float16) print(a + (b + c)) # tensor(10000., dtype=torch.float16) a = torch.tensor(1000.0, dtype=torch.bfloat16) b = torch.tensor(0.1, dtype=torch.bfloat16) c = torch.tensor(0.2, dtype=torch.bfloat16) print((a + b) + c) # tensor(1000., dtype=torch.bfloat16) print(b + c + a) # tensor(1000.2500, dtype=torch.bfloat16) А теперь имаджинируйте, что циферки не три, а 4096, собранных в вектор - как раз размер хиддена в какой-нибудь лламе 3. И нужно нам в рмснорме посчитать среднее квадратов по этому вектору: сложить 4096 циферки в произвольном порядке. На видеокарточках мы это делаем редукцией, делим вектор на блоки, суммируем блоки параллельно, затем суммируем суммы блоков между собой. Разбиение на блоки зависит от размера матча и количества активных SM (Streaming Multiprocessor, мини-процессор внутри видеокарточки). На малых батчах занимать, скажем, 132/132 SM на карточке это тупо, соответственно схема разбиения меняется, получаем другой порядок сложений. Разница в конкретных числах будет мизерной, типа 1e-3 относительной ошибки на уровне одного оператора. Вот только таких операторов типа сотни на один форвард. Получаем аккумулирующуюся ошибку и достаточное изменение логитов для того, чтобы аргмакс возвращал уже другой токен. Почему батчи разные при одинаковых запросах? Потому что в реальном проде есть continuous batching. Человеков, общающихся с моделькой, много, запросы от них приходят асинхронно, размер батчей постоянно гуляет. Зафиксировать батчи - значит, падать запросы до единого размера, значит терять вычисления, либо ждать накопления матча, то есть ловить латенси. Детерминизм очень нужен, но в достаточно редких сценариях. Помимо тестов, CI и всяких аудитов, у нас есть новомодный on-policy RL, GRPO всякий и всё в таком духе. Суть его в том, что модель сама генерирует ответы, эти ответы получают ревард, модель учится делать лучше. On-policy в названии как раз и означает, что градиент мы считаем по тем токенам, которые модель сгенерировала прямо сейчас. Собственно, трейнинг луп видит токены, которые моделька сгенерила на батчсайзе 47, считает их вероятность при батчсайзе 8, получает другие логиты, вот оно уже и не on-policy. PPO-клиппинг частично спасает от большого дрейфа, но не от маленькой системной аккумуляции.

Преамбула раз. Я решил, что мне очень нравится тот формат, в котором пишет Никита Сушко - aka полотно текста на 10 000 строк без логического разделения прям в стандартном редакторе ТГ. Преамбула два. В моём канале вообще-то не особо много технических постов (вообще, не очень много постов в принципе, но это мы опустим), но я очень хотел бы писать что-то такое, что было бы действительно интересно с точки зрения не только обывателя, но и человека разбирающегося. Собственно, вокруг этой идеи и построен мой канал, который я стабильно забрасываю раз в полгода - писать что-то вроде бы сложное вроде бы просто. Обычно, получается плохо и я очень сложно описываю что-то, что вообще-то очень просто для понимания и даже в этом умудряюсь фактологически ошибаться. Этот пост не станет исключением Про детерминизм и сгланг Есть в статистической механике такая штука, называется распределение Больцмана. Это распределение вероятностей, которое демонстрирует вероятность пребывания системы в определенном состоянии в зависимости от энергии этого состояния и от температуры системы. При низкой температуре частицы оседают в минимумах энергии, при высоких температурах они занимают любые состояния. Сформулировал эту штуку, собственно, Людвиг Больцман в 1868 году. Этот же механизм применяют и в нейросетях, в софтмаксе, причем до авторегрессионок он появился еще аж в классификационных моделях. На каждом шаге декодирования модель выдает вектор логитов, по одному числу на каждый токен в словаре. Это сырые оценки, которые нужно превратить в вероятности, для чего мы и используем софтмакс p(xᵢ) = e^(xᵢ/T) / Σⱼ e^(xⱼ/T). Собсна, буковка T - это температура, она отвечает за смещение распределений. При T = 1 распределение равно тому, что выучила модель, при T < 1 распределение заостряется, хвосты сжимаются, мы получаем более высокие вероятности для топ-токенов. Нулевая температура превращает софтмакс в аргмакс, один токен получает вероятность в единицу, остальные - ноль. Это все оч сложно. Очень просто я пытался переписать этот абзац раза примерно 4 и у меня не получилось, так что вам придется довольствоваться вот таким объяснением: логит - это логарифм шансов для токенов, буквально любая циферка. Чтобы предугадать, какой токен надо выбрать следующим, мы берем все эти логарифмы шансов, мы должны привести их к вероятностям, шансам - собственно, для этого и используется софтмакс. Софтмакс работает следующим образом, мы берем каждую циферку и делаем e^x, все значения становятся положительными и усиливается разрыв между маленькими циферками и большими циферками, затем мы нормализуем циферки, деля каждое значение на сумму всех. Получаем значения в диапазоне (0, 1), все значения в сумме дадут 1. Если логит перед экспонентой поделить на параметр температуры, то поведение несколько поменяется: при маленькой температуре модель становится уверенне, распределение резче, вплоть до того, что у одного класса может вероятность быть практически 1, большая температура делает модель мягче, вероятности выравниваются. Аргмакс, температура в 0, означает, что мы ВСЕГДА берем самый вероятный токен. Оно, собственно, поэтому и называется жадным декодингом. Почему на инференсе мы не используем нулевую температуру? Потому что нулевая температура приводит к text degeneration. Авторегрессия жадна локально, но не оптимальна глобально, модель, выбирая каждый раз самые вероятные токены, загоняет себя в тривиальность, вплоть до того, что начинает зацикливаться. Ненулевая температура - это способ добить достаточно стохастики, чтобы из этих проблем выбраться, добавить необходимого буквально в большинстве сценариев креатива в то, что модель генерирует. Гриди, при этом, все ещё нужен. Его используют для математики, кода, фактических вопросов - где нужен один правильный ответ. Стохастика для таких задач дает шанс промахнуться. Собсна, вот вам линк на рисерч, почитайте.

Чета давно я ничего не писал, надо бы исправлять ситуацию

GigaChat-3.1-Ultra и Lightning Обновили наши модели. Теперь ультра обходит по бенчмаркам Deepseek V3 0324 и Qwen-235B. Кроме того, очень сильно подросли арены и function calling — как сказал мой коллега про 10б модель, "я бы с ней дружил". Из смешного — один из чекпов ультры назывался ...-low-lr. Какое-то время он являлся релизным кандидатом и, если у тебя выставлена верная роль, можно было поболтать с ним прямо через веб-морду гигачата. Чекпоинт уже тогда был довольно крутой и с моей лёгкой руки low lr превратился в милую девушку Лоу Леру. Вайбчек модель вполне себе проходит, я посравнивал её на разных запросах с аналогами — например, закинул в неё пост про странные петли и спросил, что она думает. Лоулера ответила лучше, чем сопоставимая по размеру Mistral-3-Large, которая вообще не вдуплила что я её спросил, причём даже на английском. С тех пор лоулера заменилась на ещё более хорошую модель, так что я думаю, что как general помощник гигачат будет полезным. В этот раз моя роль была обширнее, чем в прошлый. Сейчас я покрывал весь пайплайн от обучения до релиза: запускал и дебажил трейны, переводил арены на локальных судей, курировал внос новых метрик и замерял их, находил баги в инференсе, писал хабр-статью. В статье мы описали все эксперименты, которые мы провели за последние 4 месяца. Там есть куча технических деталей, замеров, рабочих анекдотов и милые пёсики: https://habr.com/ru/companies/sberbank/articles/1014146/ Веса и ггуфы уже доступны на хф: https://huggingface.co/collections/ai-sage/gigachat-31 Ну а если вы тоже хотите поработать над действительно большими ллмками (ха, тавтология), то кидайте мне резюме — поработаем вместе.

Я знаю, что это все легко гуглится, но вы меня читаете не для того, чтобы я говорил, куда вам правильно гуглить, верно?

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

Ппц

Когда я успел сказать, что РЛ не работает?

📊 Channel Analysis Results by @ScratchAuthorEgoBot 🎯 Channel: @ashnskt 💼 Professional Analysis: Кандидат является молодым специалистом в области машинного обучения (ML) и искусственного интеллекта (AI) с выраженной специализацией в больших языковых моделях (LLM). Его академический бэкграунд, подтвержденный недавним получением диплома с отличием, предположительно, в МГУ им. М.В. Ломоносова (упоминание «Профком ВМК МГУ»), свидетельствует о наличии сильной фундаментальной подготовки в области вычислительной математики, кибернетики и Computer Science. Ключевые компетенции и сильные стороны: • Глубокая предметная экспертиза: Кандидат демонстрирует свободное владение актуальной терминологией и понимание текущего ландшафта LLM. Он отслеживает и анализирует релизы ключевых игроков рынка (Mistral, OpenAI, Deepseek, Qwen), разбирается в их архитектурных особенностях (RNN, трансформеры), метриках (перплексия) и экономических аспектах (стоимость API за миллион токенов). • Практические навыки и аналитический склад ума: Автор не ограничивается теоретическим обзором; он самостоятельно тестирует модели («потыкал новый квен на опенроутере»), оценивает их производительность в конкретных задачах (генерация кода на Python, C) и делает аргументированные выводы. Его анализ поста Сэма Альтмана и статьи о Magistral показывает умение структурировать информацию, выделять главное и представлять ее в доступной форме. • Инициативность и коммуникационные навыки: Ведение собственного Telegram-канала, написание статей (Telegra.ph), структурирование контента («Репостопост») и взаимодействие с аудиторией через опросы указывают на проактивность, развитые навыки письменной коммуникации и желание делиться знаниями. Это ценно для работы в команде, менторства и ведения технической документации. • Техническая эрудиция: Помимо основной специализации, кандидат проявляет интерес к смежным областям: фреймворкам для оптимизации (DeepSparse), аппаратному обеспечению (Nvidia, AMD), истории технологий (iPod Shuffle и стандарты разъемов), что говорит о широком кругозоре. Потенциальные риски и зоны для развития: • Недостаток коммерческого опыта: Будучи недавним выпускником, кандидат может иметь ограниченный опыт работы над долгосрочными коммерческими проектами в корпоративной среде. Его фокус на SOTA-моделях и бенчмарках может превалировать над пониманием бизнес-ограничений, где часто требуются не самые передовые, а самые стабильные, дешевые и прагматичные решения. • Склонность к категоричности: В его суждениях прослеживается определенная категоричность («RL всё таки не работает», критика Habr). Хотя это свидетельствует о наличии собственного мнения, в командной работе это может потребовать развития гибкости и умения принимать компромиссные технические решения. • Академический уклон: Глубокий анализ и теоретизирование могут преобладать над скоростью реализации и ориентацией на конечный продукт. Потребуется адаптация к более быстрым и итеративным циклам разработки, принятым в индустрии. Рекомендация: Кандидат представляет собой высокопотенциального специалиста уровня Junior+/Middle- ML Engineer или AI Researcher. Он обладает исключительной теоретической базой, страстью к своей области и доказанной способностью к самообучению и анализу. Идеально подойдет для R&D-отдела или команды, работающей над инновационными продуктами. Рекомендуется назначить ему ментора для более плавной интеграции в коммерческую разработку и помощи в расстановке приоритетов между исследованием и бизнес-задачами.

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

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

Я надеялся написать небольшое ревью относительно Magistral. Все равно, ризонинг-моделей уже вышло достаточно, вряд ли она могла впечатлить меня чем-то. Проблема в том, что Magistral - это как раз то, что пропустить, как оказалось, никак нельзя. Написал для вас статью, буду рад замечаниям в комментариях, потому что до этого на телетайп не писал никогда: https://telegra.ph/Kak-frontir-startap-sdelal-Magistral-06-17