Half-Quadratic Quantization of Large Machine Learning Models

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

получается этакое обучение под датасет, только чтобы квантизовать веса. однако этим делом не ограничивается и есть идеи без таких данных. обычно они хуже по перформансу, но в этот раз постарались такое исправить (не оч получилось имхо)

классическую лосс функцию (lp норму, 0 < p < 1) дополняют вспомогательной обучаемой переменной которую называют W_e в нотации. по сути она приближает ошибку между оригинальными весами и теми, которые прошли квантизацию-деквантизацию + это все при фиксированном скейле (то есть из двух основных параметров zero_point & scale для квантизации фиттится только первое)

авторы обосновывают такой выбор тем, что таким образом получается моделировать аутлаеры в весах (из-за которых в принципе и встает остро необходимость в существующих методах квантизации в таком виде, в котором они есть сейчас) через гипер-Лапласовское распределение (красный график на последней картинке)

есть интересный нюанс, что методу не нужен автоград (никаких активаций слоев нет, только вес как они есть), так еще и за несколько минут на цпу half-quadratic солверы (в честь которых и назван метод) сходятся к решению

евалятся на перплексии с лламой 2, так еще зацепляют ViT + CLIP (проверяют линейную пробу и зеро шот). методы без калибровочных данных обгоняют, показывают что и GPTQ типо тоже курит в сторонке на аж 2 битах

но тут есть момент, который они сами упомянули, что не везде скейл так же квантуется в 8 бит, в остальных местах у него 16 бит → получается то не 2 бита а 3 на модельку то

в целом - не перегоняет, но нет оснований полностью откидывать. пишу это постфактум, ибо просто увидел, что HQQ используется в сота компрессии КВ кэшей (пирамид кв)

👀LINK

PyramidKV: Dynamic KV Cache Compression based on Pyramidal Information Funneling

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

после очередных пристальных взглядов в аттеншп мапы авторы заметили, как и творцы LayerSkip, что количество токенов (в ключах), на которые приходит почти все внимание аттеншна, резко падает в более глубоких слоях → почему бы не оставлять эти самые токены и все? потребление по памяти на кв кэш тогда вообще значительно снизится

окей, а как выбирать эти самые токены и как определить степень снижения количества токенов на каждом слою? тут авторы сильно не парились и просто определили гипером alpha количество последних токенов в последовательности, для которых кэш будет сохраняться (они так же называются instruction tokens or local window) и далее

- оставляют из других токенов только те, у которых аттеншн скоры очень высокие с local window, при том это общее количество не превосходит заранее заданный “бюджет” на кэшированные токены для данного слоя
- а эти самые бюджеты для каждого слоя определяются арифметической прогрессией, где есть тоже отдельный гипер beta, интуитивно задает степень агрессивности в снижении бюджета. при том для первого слоя могут оставлять все токены, а чем дальше в лес, тем меньше токенов

и все это они назвали пирамид кв, потому что при визуализации для интуиции количество кэшированных токенов напоминает пирамидку (ну или воронку смотря где у вас голова модели на картинке)

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

по евалу конечно что-то супер жесткое, одновременно вызывающее удивление и сомнение: где-то 12%, где-то 0.7% (!) можно хранить от кэша и не получать деградации в перформанске (из евала был лонгбенч, иголка в сене и еще и few-show question задача) + говорят что получше и бейзлайна может перформить (когда мы все кэши храним) в случае LlaMa-3-8B-Instruct

ну а HQQ используется уже в коде как доп метод квантизации непосредственно оставшегося кэша (то есть комбинируется квантизация с компрессией, которая заключается именно в отсечении “исчерпывающей” части), в статье про это ни слова, да там и в принципе спустя время репа расширилась до размеров, что реализованы имплементации хайповых методов

👀 link, code

ReMoE: Fully Differentiable Mixture-of-Experts with ReLU Routing

китайцы сделали интересное нововведение для МоЕ, которую мы не так уж и часто упоминали (и еще чуть-чуть здесь)

обычно используется как классика ТопК над софтмаксом (который в последнее время используется и в разреженных автоэнкодерах), и вот в этом как раз заключается загвоздка по заверениям авторов, ибо топ-к сильно так ограничивает по бекворду обновление сетки и количество активированных экспертов всегда одинаково

потому авторы решили заменить это на релу → получаем (почти) дифференцируемый оператор выбора экспертов, да и к тому же при каждом форварде это количество экспертов нефиксировано

но релу сама по себе не обеспечивает разреженности, потому на обучении пришлось добавить л1 регуляризацию + коэффициент к ней адаптивный и высчитывается в соответствии с понятиями average sparsity & target sparsity

- average sparsity высчитывается на каждом степе (ну или раз в N степов) и определяется просто через количество нулевых релу активаций
- а target sparsity задается через гиперпараметры. да, количество экспертов при каждом запуске модели правда динамичное, но мы все равно должны задавать сколько примерно экспертов должно быть активировано, иначе ниче не получится (можеть быть и момент в котором статья не является breathtaking)
- так же они еще добавили эксперименты о том как в эту регуляризацию добавили Load Balancing, чтобы инпуты равномерно разделялись между экспертами, через аналогичное высчитывание средней активации по отношению к целевой. но на экспах (и оч небольшом скейле) load balancing может появляться и без этого

по экспам трудно что-то сказать, ибо все до 1б параметров, но хотя бы тут выигрывает. в принципе пейпер отличителен всякими прикольными замечаниями, которые подтверждают интуитивное понимание аллоцирования динамического количества экспертов во время форварда - естественным образом во время обучения сначала все эксперты активируются, потом разреженность повышается и достигает таргета в конечном счет + так же естественно количество активирующихся экспертов повышается со снижением частоты токена (авторы проводят аналогию с деревом Хаффмана, где нужна меньшая длина для кодировки более частого объекта)

👀LINK

Lightning Attention-2: A Free Lunch for Handling Unlimited Sequence Lengths in Large Language Models

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

при том второй аттеншн не абы какой, а лайтнинг (не тот слава Богу). в минимаксе используется первая версия, а почти одновременно с этой моделькой успела выйти и вторая версия

в чем вообще суть - вот у нас есть

softmax(Q @ K^T) @ V, где иннер продукт между запросами и ключами выдает матрицу seq_len x seq_len, что довольно много

→ приходит в голову идея линеаризовать аттеншн, то есть делаем просто из softmax(Q @ K^T) ~= phi(Q) @ phi(K^T) ⇒ [phi(Q) @ phi(K^T)] @ V, что можно переписать как из left product в right product

phi(Q) @ [ phi(K^T) @ V ], где не будем напрямую высчитывать seq_len x seq_len матрицу, а будет только hidden_dim x hidden_dim. profit?

не совсем, когда в дело приходит понятие каузальности, ибо тогда формула становится (phi убрал для удобства) снова left product

[Q @ K^T * causal_mask] @ V

снова получаем seq_len x seq_len момент, это дело можно исправить алгоритмом Linear Attention Right Product (на предпоследней фотке), но тогда встревает кумулятивная сумма, которую не распараллелить

ну и авторы довольно красивое решение предлагают в виде того, что как раз и называется Lightning Attention

- во-первых, го вычислять аттеншн по блокам, по которым и будет идти цикл как обычно
- а в каждом блоке будем одновременно вычислять аттеншны и первым, и вторым способом: через left product с каузальной маской будет вычисляться intra block (как я понял потому что он находится рядом с диагональными элементами как раз, где и нужна каузальная маска), а через right product inter block (который/которые не соприкасаются с диагональю и можно без каузальной маски их использовать, да еще и этот блок вычислить можно через накопленную кумулятивную сумму KV), а в конце просто просуммируем, не забыв обновить KV
- тут получаем трейдофф между лево- и правоматричным умножениями, который еще и к тому же нетяжело под хардвейр оптимизировать - перетаскивать поочередно блоки между High Bandwidth Memory & SRAM (последняя картинка для иллюстрации отсюда, по всем правилам - чем больше по памяти вмещается, тем медленее работает)

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

реализовано все на тритоне, метод в принципе применим не только к их ТрансНормеру

👀 link, code

О неочевидном поведении DPO и улучшениях SMPO в новой SLM от VIkhrModels

Недавно вышедшая QVikhr-2.5-1.5B-Instruct-SMPO, отличается не только лучшим качеством среди наших небольших тюнов, сопоставимым местами с 7B моделями, но и улучшениями в нашем методе алайнмента SMPO.

В ходе большого количества экспериментов я заметил, что офлайновая DPO-like (любая, в том числе и SMPO, ORPO, SimPO и тд) тренировка, часто при обучении может приводить к вырожденным решениям, например, таким, где модель теряет EOS токен при генерации и уходит в повторения или просто в генерацию сломанных токенов.

После небольшого расследования выяснилось, что частично такое поведение объяснимо поведением логарифма при вычислении логпробов токенов (картинка 1), которые в свою очередь участвуют в вычислении ревордов, разница между которыми и оптимизируется в DPO. Вычисляя логарифм чисел в районе 0, вы легко можете получить неограниченное падение логпроба в минус бесконечность. В случае DPO вы эти логпробы потом складываете, в случае SMPO они усредяются по всему комплишену. И в том и в другом случае, вы не спасаетесь от возможных значений-выбросов на конкретных токенах.

Если говорить более простыми словами - если ваш rejected содержит какието очевидные закономерности в токенах, которые его отличают от chosen, то модель через DPO может научится занижать логпробы именно этих токенов в минус бесконечность (т.е. обнулять вероятность) и выигрывать тем самым objective DPO, при этом для более "умных" последовательностей токенов, которые вы хотели бы тоже выучить, оптимизация может вобще не произойти, приводя к довольно тупым результатам, частое из которых это занизить логпроб EOS токена на всех rejected, тем самым почти уничтожив вероятность его генерации на OOD примерах - получаем проблему бесконечных повторений.

Конечно, такое поведение связано с плохой регуляризацией в RL. Выбор меньшего lr, уменьшение гипермараметра beta (в dpo), использование KL (как в DPO) или rejected и chosen SFT амортизации (как в SMPO), лучший выбор модели (какие-то меньше подвержены), использование model merging между SFT и PO стадиями тренировки, в целом обучение не до конца, частично помогает бороться с таким хаком обжектива. При тренировке Vikhr-Nemo было проведено немало экспериментов с гиперпараметрами, но проблема не была полностью вылечена.

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

Модифицированный SMPO и конфиги обучения уже доступны в нашей библиотеке Effective LLM Alignment

Vintix: Action Model via In-Context Reinforcement Learning

не дипсиком единым жив рл, а всем исходящем из дуно живет отечественный In-Context RL

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

и из этого и рождается винтикс на основе ДимДимычей в виде AD, TinyLLaMa (откуда много из архитектуры бралось) и частично JAT (стоит упомянуть, что основной автор этого агента сейчас в основном занимается в хф трл и опен-р1)

в общей сумме тренились на 87 тасках в симуляторах (что очень мало для ин-контекст рл, где это количество от сотен до тысяч)

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

поскольку акншы и обсервейшны в этих симуляторах разные, то для каждого использовались отдельные энкодеры/декодеры, чтобы подгонять под нужную размерность для трансформера + насколько я понял, каждый батч - семплы из одной среды (как это было сделано и в JAT)

данные собирали при помощи расшумления траекторий от политик ппо или взятых с JAT + обобщили эту идею на непрерывные действия

- посколькуо в изначальной папире этот метод предлагался в дискретном пространстве → реализовывался epsilon-greedy алгоритм, где действия политики сразу были оптимальны (был взят оракул)
- то здесь пришлось линейно интерполировать каждый раз между действием полиси и рандомным вектором. но при том сам коэффициент влияния шума пришлось подбирать нелинейным способом, чтобы уже в таких более-менее сложных задачах траектории обучения как датасет был “гладким”

тренировали каузальный трансформер в 300М параметров на 8 картах, что для рл сейчас более-менее. по итогу что-то да получилось - на трейн тасках есть прогресс получше JAT (где это уместно сравнивать) + если варьировать в трейн тасках конфигурацию среды (например в муджоко потыкать гравитацию или уровень вязкости), то агент может адаптироваться к таким изменениям, что довольно круто (авторы назвали это self-correction, в последнее время это слово часто всплывает)

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

👀 link, code coming soon (датасет тоже планируют релизить)