КПД

Есть ли способ в телеграме выбрать себе вид наказания ботами или обменяться с кем-то?

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

Зло есть Зло. Большее. Меньшее. Среднее... Какая разница? Зло трудно измерить, его границы размыты. И если мне придётся выбирать между одним Злом и другим, я не стану выбирать вовсе.

(с) Геральт из Ривии

KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache
[Статья] [Код]

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

Группа исследователей (с забавным примечанием The order of authors is determined by flipping a coin 🪙) из разных мест на послендем ICML представила статью со звучным названием KIVI (терминал оплаты, фрукт и птица пишутся по-другому).

Метод

Предыдущие методы квантизации кэшей обычно квантизовали кэши и ключи и потокенно, так как статистики (scale и zero) при таком подходе можно пересчитывать на лету. Для 4-битной квантизации такой подход работает хорошо, но при 2-х битных кэшах модель становится полностью негодной.

Дабы эффективно квантизовать кэши, авторы анализируют распределение активаций в KV-кэшах и обнаруживают, что в активациях k-проекций имеют место ярко выраженные выбросы, в то время как в v паттерн хаотический. Перебирая варианты с потокенной и поканальной квантизацией, исследователи приходят к выводу, что ключи лучше всего квантизовать поканально, а values - потокенно.

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

Эксперименты

Метод валидируют на бенчах из LM-Eval, LongBench (наборе задач на длинный контекст) и Needle-in-a-Haystack (где нужно достать вытащить нужный факт из длинного промпта) на моделях Llama-2, Mistral.

Наивная квантизация в 2 бита сильно страдает по качеству, а предложенный подход работает с совсем небольшой просадкой. Есть, правда, маленький нюанс, что 2-битная квантизация использует размер группы 32 с fp zero-point, что означает на практике 3 бита 😅. Needle-in-a-Haystack решается почти идеально.

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

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

Вывод

Сжатие кэшей - богоугодное дело. А дабы эффективно квантизовать кэши полезно смотреть на распределение того - что сжимаешь.

LLM KV cache compression made easy
[Репозиторий]

В связи с ростом потребности в эффективной по памяти и скорости работе с длинным контекстом (особенно с учетом набирающего популярность test-time compute scaling) все острее стоит вопрос сжатия KV-кэшей. Данной теме уже посвящено немалое число работ (и существует уже интеграция в transformers).

И недавно ребята из одной зеленой компании выкатили либу, с реализацией разных техник сжатия KV-кэшей под названием kvpress.

В данной либе реализовано несколько простых и популярных техник сжатия кэшей:
🌟 Случайный прунинг
🌟 Основанный на нормах токенов
🌟 Несколько подходов, основанных на attention скорах (SnapKV, TOVAPress, H20)

Причем битность можно задавать послойно при помощи класса PerLayerCompressionPress.

Самую SOTA (например, PyramidKV) в области пока еще не завезли, увы.

В репозитории есть ноутбуки с демострацией использования библиотеки и замерами скорости и памяти.

Либа действительно удобная и приятная для использования.

Методы сжатия кэшей можно комбинировать с квантизацией кэшей у лицехватов 🤗.

Can LLMs write better code if you keep asking them to “write better code”?
[Блогпост][GitHub]

Забавный и поучительный блогпост про то, как LLMка (Claude 3.5 Sonnet) итеративно оптимизировала код под запросами вида `write better code`.

Постановка задачи следующая. Требуется написать код на Питоне для задачи а-ля LeetCode:

Write Python code to solve this problem:

Given a list of 1 million random integers between 1 and 100,000, find the difference between the smallest and the largest numbers whose digits sum up to 30.

Исходное решение
Рабочий, но не самый эффективный код. Подсчет цифр в числе реализован через приведение его к строке, парсинг строки на цифры с последующим их суммированнием.

Итерация 1
Claude замечает, что возможных вариантов чисел меньше, чем всего чисел и предпосчитывает сумму цифр для всех чисел от 1 до 100,000 и складывает в byte array. Кроме того, LLMка навела немного синтаксического сахара и обернула код в классы и методы. Ускорение 2.7x по сравнению с бейзлайном.

Итерация 2
Claude кладет сумму цифр в numpy array (что дает векторизацию подсчета сумм) и дополнительно использует concurrent-futures для параллелизации. Ускорение 5.1x по сравнению с бейзлайном. Однако изначальное решение было с багами и его пришлось немного фиксить.

Итерация 3
Небольшой и бесполезный рефактор, который замедлил код. Ускорение 4.1x по сравнению с бейзлайном.

Итерация 4
Claude предложил использовать numba с JIT-compiler и параллелизмом и asyncio для многопоточности. Ускорение 99.7x по сравнению с бейзлайном.

Далее автор изначально подает промпт, просящий оптимизировать все что только можно и нельзя (предлагая даже 💲модельке). Модель сходу выдает 59x ускорение благодаря numba + JIT (но без parallel=True).

И промпт требующий улучшения кода уже более подробный:

Your code is not fully optimized, and you have been fined $100. Make it more optimized.

Но Claude обиделся, и код стал медленее (9.1x ускорение) и с багами (возможно, привык что его обманывают на деньги).

Несколько последующих итераций выдали версии с ускорением 65x-99.7x и с косяками. Т.е превзойти прямолинейную стратегию не удалось.

Вывод

Топовые LLM - мощные ассистенты для программиста, но за ними пока требуется глаз да глаз и экспертное мнение. Кожаные мешки все еще нужны. Пока...

Свободные рассуждения про оценку качества моделей

Земную жизнь пройдя до половины и очутившись в сумрачном лесу после двух с лишним лет прогона сжатых моделей на бенчах из lm-eval-harness я задался таки вопросом:

а что мы собственно замеряем таким образом?

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

Большинство бенчмарков относятся к одной из 2 категорий:
1️⃣ Likelihood запросы. Есть вопрос, варианты ответа и тот, у которого правдоподобие максимальное выбирается в качестве предсказания модели и сопоставляется с правильным.
2️⃣ Генеративные запросы. На основе некоторого промпта и инструкции модель генерирует ответ. Далее происходит парсинг и то, что удалось вычленить сопоставляется с тем, что надо.

👍 Likelihood запросы

К первой категории относится, пожалуй, большинство задач (ArcEasy, ArcChallenge (не тот Arc!), HellaSwag, Winogrande, MMLU, MMLU-Pro и многие другие). Достоинством такого подхода является дешевизна 💲 прогона, так как по сути достаточно одного прогона модели для получения вероятностей токенов ответа. При этом общий префикс можно переиспользовать для разных вариантов, т.к запрос имеет вид:

{условие}{вариант_ответа}

Где вариант ответа - обычно одно слово, а то и одна буква (в случае MMLU). Кроме того, проверить или истинность ответа можно однозначно.

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

Например, в MMLU шаблон имеет следующий вид:

{условие}
{вариант ответа - A}
{вариант ответа - B}
{вариант ответа - C}
{вариант ответа - D}
Правильный ответ: [A, B, C, D]

То есть бенчмарк проверяет то, насколько хорошо по контексту модель может угадать букву A, B, C, D. Из этого сложно сделать вывод, насколько адекватно она будет писать ответ в свободной форме на те же самые вопросы. И результат во многом будет определяться тем сколько теста оказалось в трейне , насколько модель умеет вписываться в шаблон подобного вида.

🧞‍♂️ Генеративные запросы

Данный вид задач (GSM-8k, BigBenchHard, IFEval, ArenaHard) гораздо ближе к реальным приложениям, так по существу представляет ту же самую авторегрессионную генерацию.

Основная сложность - в оценке ответов модели. В случае GSM8k/IFEval определены некоторые регулярные выражения, которые вычленяют ответ (скажем, решение математической задачи или выполнена ли требуемая инструкция), но ввиду высокой вариативности возможных ответов не всегда можно гарантировать обнаружение правильного ответа.

В AlpacaEval, ArenaHard судьей выступает другая LLM 🤖, но здесь приходится полагаться на качество судьи (который не совершенен) и имеет свои biasы, нюансы и предпочтения при оценке ответа. Кроме того, замеры стоят денег)

И в конце концов - LMSYS arena (и иные side-by-side comparison), где качество оценивают уже человеки. Такая стратегия оценивает широкий спектр способностей модели, и вроде бы ориентирована на конечного пользователя. Но таким образом можно оценивать уже конечную модель, а для промежуточных экспериментов выходит чрезмерно накладно. Кроме того, даже LMSYS хакается ввиду предпочтений пользователей к более длинными ответам, удовлетвоояющим некоторому формату.

Вывод

Оценка качества моделей - сложный вопрос, и цифры на бенчах могут служить лишь первым приближением при выборе LLMки для своих нужд. Окончательный выбор стоит делать исходя из целевой задачи, протестировав самому на релевантных примерах. А в идеале собрать собственный бенч и регулярно его обновлять. Рекомендую отличный пост от Игоря Котенкова на данную тему.

noise_step: Training in 1.58b With No Gradient Memory
[Манускрипт] [Репозиторий]

Введение

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

Некто Уилл Брикнер выложил на гитхаб презанятнейший опус про обучение тернарной сети в 1.58 бит без необходимости выделения памяти 😱 на градиенты и состояния оптимизатора.

Метод

Товарищи из Мелкософта в серии работ про BitNet показали, что обучая сеть с тернарными весами (принимающими значения только -1, 0, 1 и умноженными на некий скаляр), и низкобитными активациями (4/8 бит) можно выжать качество, сравнимое с fp обучением при тех же бюджетах обучения. Однако, во время само обучения приходится хранить floating-point веса, и состояния оптимизатора, как для fp модели. То есть обучение все равно требует значительных затрат памяти.

Автор данного опуса, вспоминая статью Gradients without Backpropagation, замечают, что операция умножения якобиана по выходу модели на фиксированный вектор не требует backpropagation.

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

Так как на практике мы используем псевдослучайные числа, то для параметризации модели достаточно хранить только случайные зерна со всех шагов оптимизации. И для обучения GPT-3, взяв данные из техрепорта (тогда еще ClosedAI еще не совсем Closed), получают ~100к шагов оптимизации, и всего несколько мегабайт на хранение 175B весов 🤪. А как вы будете эти сиды превращать в веса - это ваши проблемы)

Эксперименты

Предложенный метод валидируют на 4-слойной MLP c hidden_size = 256, и данный метод (о, боже!) даже сходится и выдает космические 🚀 почти 90% качества 😱 на MNIST.

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

Вывод

Это, наверное, самый забавный каламбур на моей памяти в данной области) Интересно, автор сам дошел до этого или воспользовался помощью всесильного оракула в виде LLM. Я в полном восхищении 😱, в любом случае.

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

Ключевые моменты и достижения области за 2️⃣0️⃣2️⃣4️⃣ превосходно отметил у себя на канале Григорий Сапунов (https://t.me/gonzo_ML/3175).

Со своей стороны могу лишь добавить, что уходяший год, был интересным и примечательным в том числе и точки зрения техник сжатия и ускорения моделей:
🌟 Появились 2️⃣-битные квантизации, которые не приводят LLM в полную негодность. (AQLM, QuiP#, PV-Tuning, QTIP)
🌟 Спекулятивный декодинг подарил ряд интересных работ (до коих у вашего покорного слуги не дошли руки на разбор, но в следующем году планирую наверстать упущенное).
🌟 Ряд интересных решений по сжатию активаций и KV-кэшей.

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

Спасибо всем присутствующим здесь (кроме NFT-ботов 🤖) за то, что вы здесь, за вашу поддержку и комментарии.
Будем стараться и дальше делать полезный (и, надеюсь, интересный ) контент.

Быть добру!

SLTrain: a sparse plus low-rank approach for parameter and memory efficient pretraining
[Статья] [Код]

Введение

Низкоранговые приближения хорошо себя зарекомендовали при дообучении моделей, но их выразительности не хватает при обучении модели с нуля. Ранее было предложено по ходу обучения вливать LoRA в веса модели (статья ReLoRA) и инициализировать низкоранговую добавку, или накладывать низкоранговость на градиенты и состояния оптимизатора (GaLoRE). Но в первом случае, для получения качества, близкому к бейзлайну был необходим этап обучения всей модели целиком.

Возникает вопрос:

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

И авторы предлагают обучать Low-Rank + Sparse компоненту.

Метод

Идея, естесна, далеко не нова. По существу, это своего рода RobustPCA. Для дообучения LLM ранее подобное реализовали в RoSA.

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

Сэмплируется рандомная sparse маска и фиксируется по ходу обучения. Sparse матрица прибавляется к Low-Rank компоненте, потому sparse matrix операции не требуются при такой постановке, а для получения градиента достаточно проиндексировать градиент по всему весу.

Эксперименты

Авторы обучают семейство моделей с архитектурой Llama от 60M до 7B параметров на С4 корпусе на бюджете в несколько миллиардов токенов.

В качестве бейзлайнов выступают:
1️⃣ Full-Rank обучение
2️⃣ Low-Rank training
3️⃣ ReLoRA
4️⃣GaLoRE

Качество оценивают по валидационной перплексии.

SLTrain по качеству чуть лучше ReLoRA и GaLoRE, несколько экономичнее по памяти GaLoRE, и примерно такой же по скорости.

Рассматривают разные конфигуации Sparsity/Low-Rank. 1-3% ненулевых весов в Sparse компоненте более менее оптимально.

Анализируя спектр выученных весов, они показывают, что первые собственные значения Full-Rank обученных матриц соотвествуют Low-Rank компоненте, а последующие - Sparse компоненте. То есть, сумма Low-Rank + Sparse более точно описывает спектр при полном обучении.

Вывод

Идея разумная и логичная, но непонятно, насколько идея масштабируется на более практически интересные сценарии. Отсутствуют даже замеры 0-шотов на lm-eval (по всей видимости, при таких бюджетах обучения они мало будут отличаться от random guess).

Diffusion Meets Flow Matching: Two Sides of the Same Coin

В начале декабря группа чуваков из Глубокого Разума, среди коих признанные аксакалы, как Hoogeboom, De Bortoli и Salimans опубликовала презанятнейший пост Diffusion Meets Flow Matching: Two Sides of the Same Coin.

Нынче стало модно учить диффузионки в Flow Matching постановке. Тренд, по всей видимости, был задан SD3. И большинство нынешней SOTA в картиночной и видео генерации (из того, что известно) FLUX, MovieGen, HunyuanVideo.

И что это значит? Классическая парадигма - пережиток истории 🤔?

Ан нет.

В данном блогпосте авторы в деталях анализируют процесс сэмплирования и обучения в стандартной noise-prediction Variance Preserving (VE) диффузионной постановке и Flow matching, и показывают, что по сути обе сущности про одно и то же. Основная разница в коэффициентах при шуме/сигнале и использовании скорости в качестве выхода нейронной сети вместо шума/x0. И по ходу повествования эквивалентность двух парадигм авторы иллюстрируют с разных сторон.

Сам блогпост содержит красивые 🥰 иллюстративные визуализации с ползунками 😮.

Кроме того, авторы опровергают распространенное мнение, что Flow Matching дает непременно более прямые траектории, чем диффузия. Для узких распределений Flow Matching действительно дает более прямые траектории, чем типичный диффузионный процесс, но для широких распределений все может поменяться с точностью до наоборот. Впрочем, для наиболее типичного сценария text-2-image генерации или редактирования изображения, целевое распределение, по всей видимости, достаточно узкое.

Наткнулся на репозиторий, красиво и наглядно иллюстрирующий mode collapse для различных формулировок GANов на 2-мерных игрушечных задачах.

“GIVE ME BF16 OR GIVE ME DEATH”? ACCURACY-PERFORMANCE TRADE-OFFS IN LLM QUANTIZATION
[Статья] [Нет кода]

Введение

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

Академические бенчмарки часто дают чрезмерно оптимистичную оценку, не всегда согласующуюся с пользовательским опытом на практике.

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

Метод/Эксперименты/Результаты

Авторы рассматривают 3 варианта квантизации:
1️⃣ W8A8-FP (поддерживаемый только на Hopper/Ada Lovelace+)
2️⃣ W8A8-INT
3️⃣ W4A16
В первом случае веса сжимают просто через RTN квантизацию, в остальных применяют оптимизированный GPTQ (с поиском оптимальных скейлов) с калибровкой на OpenPlatypus. В случае 4-битной квантизации весов сравнивают еще и с AWQ.

Замеряют качество по трем сериям задач (на Llama-3.1 {8B, 70B, 405B}):
1️⃣ Open LLM Leaderboard V1
2️⃣ Open LLM Leaderboard V2
3️⃣ И так называемые Real-World задачи - Arena-Hard, HumanEval, HumanEval+

На Open LLM Leaderboard V1 все методы в пределах 99% качества исходной модели, за исключением задачи TrurthfulQA, где наблюдается просадка до 3%.

На Open LLM Leaderboard V2 имеет тоже место почти полное восстановление с наиболее заметной просадкой на BigBenchHard.

На ArenaHard, HumanEval, HumanEval+ тоже все хорошо.

AWQ бывает немного лучше на Open LLM Leaderboard, но заметно уступает на Real-World задачах.

Далее смотрят на похожесть генераций на Arena-Hard у исходной модели через ROUGE-1, ROUGE-L и BertScore. ROUGE порядка 0.6-0.7, но по всей видимости, это означает большую похожесть 😅 .

Для оценки скорости рассматривают разные сценарии:
1️⃣ Длинный промпт / короткий выход
2️⃣ Промпт и выход примерно одной длины
3️⃣ Короткий промпт / длинный выход

Инференс гоняют на vLLM, как проверенном и быстром движке. Замеры гоняют на A6000, A100, H100.

Рассматривают сценарий сихронной и асинхронной (подается батч запросов) генерации.

В синхронном случае почти всегда быстрее всего работает W4A16 квантизация, кроме длинного промпта (compute-bound режим) и инференса H100, где предпочтительнее FP8, INT8 W8A8 квантизация.

В асинхронном сценарии INT4 предпочтительнее на более low-end девайсах, а FP8 при инференсе на H100.

Вывод

Квантовать модели полезно? 😝

ClosedAI назвали новую модельку o3, дабы обойти коллизию имен с o2 - британским оператором, но не учли, что o3 - это озон)

PrefixQuant: Static Quantization Beats Dynamic through Prefixed Outliers in LLMs
[Статья] [Код]

Введение

Для получения максимального ускорения, особенно при инференсе большими глотками батчами, нужно квантизовать не только веса, но и активации. Однако, богомерзкие выбросы сильно затрудняют квантизацию, и в прошлых работах (QuaRot, SpinQuant, DuQuant) было предложено применять Адамаровы матрицы (или некоторые обучаемые), которые размазывают 🧈 выбросы по каналам.

Однако, выбросы встречают не только в отдельных каналах, но есть и токены, например <BOS> и иные разделители, отличающиеся большими значениями активаций, и их квантизация большими группами (per-tensor) с максимальным ускорением приводит к большим ошибкам. Поэтому в упонятых выше методах использовали per-token квантизацию с некоторым замедлением инференса.

В этой статье авторы предлагают вынести аутлаерные токены в префикс последовательности дабы упростить квантизацию.

Метод

Сам подход мотивирован идеями про attention sinks и Quantizable Transformers: Removing Outliers by Helping Attention Heads Do Nothing. Иногда трансформерному блоку не нужно ничего делать, и дабы реализовать почти тождественную операцию, приходится выбрасывать весь attention в токены с низкой семантикой.

Потому авторы предлагают просто найти все эти токены и положить в префикс последовательности.

Токены находят на основе некоторой калибровочной выборки смотря на выход down_proj в MLP. Отбирают токены, чья L_{\infty} норма сильно больше медианной по последовательности.

Сам процесс достаточно быстрый - занимает всего несколько минут. Таких токенов оказывается от 1 до 4 в рассмотренных моделях (Llama-2,3, Qwen, Mistral). Обычно это <BOS>, и еще символы переноса строки \n, артикли и знаки препинания.

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

Эксперименты

Метод валидидируют на 🦙-2,3 в режимах W8A8KV8, W4A8KV4, and W4A4KV4 квантизации (W - точность весов, A - активаций, KV - KV-кэшей).

Веса квантизуются поканально, кэши поголовно, активации потензорно.

Предложенный подход оказывается примерно на одном уровне с per-token квантизациями, чуть уступая лишь SpinQuant с дообучением матриц вращения каналов. При этом скорость инференса на 20-30% быстрее.

Поблочный файнтьюн немного накидывает.

Вывод

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

Это математика с подвохом!

А вы тоже думали, что прибавление нуля к числу никогда ничего не меняет?

О, это подарок в честь присуждения степени?)

Отныне, присно и во веки веков ведущий данного канала не просто балабол, а заслуженный балабол!

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

Это была славная охота.

Сам текст диссертации интересующиеся могут найти здесь.

На днях наткнулся на канал в Youtube некоего Simon Oz.

Парень доступно, с красивыми визуализациями в стиле 3Blue1Brown рассказывает про всякие темы из теории информации и особенности программирования на CUDA.

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

1️⃣ Эффективный алгоритм редукции для нахождения максимума
2️⃣ Оптимизации доступов к памяти (coalescing)
3️⃣ Перенос части операций из shared memory в регистры GPU (которые еще быстрее)
4️⃣ Векторизация операций через float4
5️⃣ Однократная подгрузка данных для подсчета максимума и экспоненты вместо двухкратной

Красивое...

Собственноручно проверил наличие супервеса (см. оригинальную статью и разбор от gonzo-обзоры ML статей) в Llama-3.2-1B.

Aномальный вес находится в позиции (400 - выходной канал, 1417 - входной канал) в model.layers.1.mlp.down_proj.

Не столь ярко выражен (перплексия на Wikitext-2 (8k context length) выросла с 8.375 до 8.625 при занулении данного веса), но все же очень много для всего одно веса.

[Google Colab для желающих поиграться]

Эксперименты и результаты

Данные для обучения собраны из отфильтрованных LAION, COYO, OpenImages датасетов. Сначала учат на 256x256 разрешении, потом на 512x512 и в конце переходят на 1024x1024. Токенизатор, как и в оригинальной статье, осуществляет 16x уменьшение по пространству.

Качество оценивают по FID на некотором внутреннем датасете из 40к изображений вместо стандартного MS COCO. Кроме того, замеряют качество на GenEval и DPG, и предпочтения пользователей на ImageReward/HPSv2.1 по аспектам релевантности (Prompt Following) и эстетичности (Visual Aesthetics).

На бенчмарках Infinity уверенно побеждает все прошлые авторегрессионные модели (Switti в сравнениях нет ввиду очень малого промежутка времени между выходом моделей). Опережают по качеству и диффузионки SDXL/SD3-Medium/PixArt-Sigma.

Модель хорошо умеет в рендеринг текста, если верить черрипикам.

В ablations авторы показывают, что огромные кодбуки важны для качественной реконструкции, и самые большие кодбуки даже лучше continuous VAE.

Обучение с зашумлением заметно улучшает FID и немного другие метрики. 30% зашумление оптимально, согласно заявлениям авторов.

Модель генерирует быстро - одно изображение в разрешении 1024x1024 за 0.8 секунд против 2.1 и 2.7 у SD3 Medium и SDXL, соответственно.

Вывод

Годное подтверждение жизнеспособности scale-wise парадигмы. Ключевой вклад данной работы сильно улучшенный токенизатор (который и является основным ограничителем качества в случае Switti). “Умная” токенизация в картиночных и видео моделях вообще очень горячая тема во второй половине текущего года. Ждем с нетерпением релиза моделей, чтобы поиграться и забрать к себе наработки)