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

В планах на ближайшее время у меня дописать пост про пд дизагрегацию, потом, думаю, либо про 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. Авторегрессия жадна локально, но не оптимальна глобально, модель, выбирая каждый раз самые вероятные токены, загоняет себя в тривиальность, вплоть до того, что начинает зацикливаться. Ненулевая температура - это способ добить достаточно стохастики, чтобы из этих проблем выбраться, добавить необходимого буквально в большинстве сценариев креатива в то, что модель генерирует.

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

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

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

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

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

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

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