“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.
Вывод
Квантовать модели полезно? 😝
[Статья] [Нет кода]
Введение
Квантизаций за последние годы вышло мерено-немерено разного качества и степени сжатия. В идеале, конечно же, хочется не просесть по качеству, и при этом добиться снижения издержек на инференс 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.
Вывод
Квантовать модели полезно? 😝
😁3✍1
Наткнулся на репозиторий, красиво и наглядно иллюстрирующий mode collapse для различных формулировок GANов на 2-мерных игрушечных задачах.
👍16
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 генерации или редактирования изображения, целевое распределение, по всей видимости, достаточно узкое.
В начале декабря группа чуваков из Глубокого Разума, среди коих признанные аксакалы, как 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 генерации или редактирования изображения, целевое распределение, по всей видимости, достаточно узкое.
👍11🔥6❤3
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-шотов на
[Статья] [Код]
Введение
Низкоранговые приближения хорошо себя зарекомендовали при дообучении моделей, но их выразительности не хватает при обучении модели с нуля. Ранее было предложено по ходу обучения вливать 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).👍6❤1
Прошедший год был насыщенным на события и прогресс в области ИИ, глубокого обучения, машинки и разнообразных приложений.
Ключевые моменты и достижения области за 2️⃣0️⃣2️⃣4️⃣ превосходно отметил у себя на канале Григорий Сапунов (https://www.tgoop.com/gonzo_ML/3175).
Со своей стороны могу лишь добавить, что уходяший год, был интересным и примечательным в том числе и точки зрения техник сжатия и ускорения моделей:
🌟 Появились 2️⃣-битные квантизации, которые не приводят LLM в полную негодность. (AQLM, QuiP#, PV-Tuning, QTIP)
🌟 Спекулятивный декодинг подарил ряд интересных работ (до коих у вашего покорного слуги не дошли руки на разбор, но в следующем году планирую наверстать упущенное).
🌟 Ряд интересных решений по сжатию активаций и KV-кэшей.
В связи с запросом научного сообщества, энтузиастов и простых пользователей на эффективный инференс, полагаю, что и в следующем году мы увидим немало интересного. И в особенности, значительные усилия будут потрачены на удешевление цепочек рассуждений а-ля o3.
Спасибо всем присутствующим здесь (кроме NFT-ботов 🤖) за то, что вы здесь, за вашу поддержку и комментарии.
Будем стараться и дальше делать полезный (и, надеюсь, интересный ) контент.
Быть добру!
Ключевые моменты и достижения области за 2️⃣0️⃣2️⃣4️⃣ превосходно отметил у себя на канале Григорий Сапунов (https://www.tgoop.com/gonzo_ML/3175).
Со своей стороны могу лишь добавить, что уходяший год, был интересным и примечательным в том числе и точки зрения техник сжатия и ускорения моделей:
🌟 Появились 2️⃣-битные квантизации, которые не приводят LLM в полную негодность. (AQLM, QuiP#, PV-Tuning, QTIP)
🌟 Спекулятивный декодинг подарил ряд интересных работ (до коих у вашего покорного слуги не дошли руки на разбор, но в следующем году планирую наверстать упущенное).
🌟 Ряд интересных решений по сжатию активаций и KV-кэшей.
В связи с запросом научного сообщества, энтузиастов и простых пользователей на эффективный инференс, полагаю, что и в следующем году мы увидим немало интересного. И в особенности, значительные усилия будут потрачены на удешевление цепочек рассуждений а-ля o3.
Спасибо всем присутствующим здесь (кроме NFT-ботов 🤖) за то, что вы здесь, за вашу поддержку и комментарии.
Будем стараться и дальше делать полезный (и, надеюсь, интересный ) контент.
Быть добру!
🙏15👍4❤3
Какое направление будет активнее всего развиваться в 2025 году?
Anonymous Poll
13%
Мультимодальность
21%
Reasoning
9%
Диффузионные видео модели
12%
Альтернативные варианты токенизации в LLM (Byte Latent Transformer, Large Concept Model)
3%
Механистическая интерпретируемость
2%
VAR-like генеративные модели для изображений и видео
30%
Агенты
7%
World Models
2%
Свой вариант (в комментариях)
✍3
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. Я в полном восхищении 😱, в любом случае.
[Манускрипт] [Репозиторий]
Введение
Первый пост данного года будет несколько комедийного содержания, как раз в самый раз для прочтения после нескольких бокалов шампанского 🥂 (или чего покрепче 🥃).
Некто Уилл Брикнер выложил на гитхаб презанятнейший опус про обучение тернарной сети в 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. Я в полном восхищении 😱, в любом случае.
❤9😁5👍4🤡2
Свободные рассуждения про оценку качества моделей
Земную жизнь пройдя до половины и очутившись в сумрачном лесу после двух с лишним лет прогона сжатых моделей на бенчах из lm-eval-harness я задался таки вопросом:
В нижеприведенных рассуждениях я не планирую погружаться в дебри дискуссий про то, что есть AGI, а чем он не является, а лишь сугубо попытаться соотнести академические бенчмарки применению на практике.
Большинство бенчмарков относятся к одной из 2 категорий:
1️⃣ Likelihood запросы. Есть вопрос, варианты ответа и тот, у которого правдоподобие максимальное выбирается в качестве предсказания модели и сопоставляется с правильным.
2️⃣ Генеративные запросы. На основе некоторого промпта и инструкции модель генерирует ответ. Далее происходит парсинг и то, что удалось вычленить сопоставляется с тем, что надо.
👍 Likelihood запросы
К первой категории относится, пожалуй, большинство задач (ArcEasy, ArcChallenge (не тот Arc!), HellaSwag, Winogrande, MMLU, MMLU-Pro и многие другие). Достоинством такого подхода является дешевизна 💲 прогона, так как по сути достаточно одного прогона модели для получения вероятностей токенов ответа. При этом общий префикс можно переиспользовать для разных вариантов, т.к запрос имеет вид:
{условие}{вариант_ответа}
Существенным недостатком данного подхода же является неочевидная связь между умением модели справляться с данными задачами и генерацией текста в свободной форме.
Например, в MMLU шаблон имеет следующий вид:
То есть бенчмарк проверяет то, насколько хорошо по контексту модель может угадать букву A, B, C, D. Из этого сложно сделать вывод, насколько адекватно она будет писать ответ в свободной форме на те же самые вопросы. И результат во многом будет определяться темсколько теста оказалось в трейне , насколько модель умеет вписываться в шаблон подобного вида.
🧞♂️ Генеративные запросы
Данный вид задач (GSM-8k, BigBenchHard, IFEval, ArenaHard) гораздо ближе к реальным приложениям, так по существу представляет ту же самую авторегрессионную генерацию.
Основная сложность - в оценке ответов модели. В случае GSM8k/IFEval определены некоторые регулярные выражения, которые вычленяют ответ (скажем, решение математической задачи или выполнена ли требуемая инструкция), но ввиду высокой вариативности возможных ответов не всегда можно гарантировать обнаружение правильного ответа.
В AlpacaEval, ArenaHard судьей выступает другая LLM 🤖, но здесь приходится полагаться на качество судьи (который не совершенен) и имеет свои biasы, нюансы и предпочтения при оценке ответа. Кроме того, замеры стоят денег)
И в конце концов - LMSYS arena (и иные side-by-side comparison), где качество оценивают уже человеки. Такая стратегия оценивает широкий спектр способностей модели, и вроде бы ориентирована на конечного пользователя. Но таким образом можно оценивать уже конечную модель, а для промежуточных экспериментов выходит чрезмерно накладно. Кроме того, даже LMSYS хакается ввиду предпочтений пользователей к более длинными ответам, удовлетвоояющим некоторому формату.
Вывод
Оценка качества моделей - сложный вопрос, и цифры на бенчах могут служить лишь первым приближением при выборе LLMки для своих нужд. Окончательный выбор стоит делать исходя из целевой задачи, протестировав самому на релевантных примерах. А в идеале собрать собственный бенч и регулярно его обновлять. Рекомендую отличный пост от Игоря Котенкова на данную тему.
а что мы собственно замеряем таким образом?
В нижеприведенных рассуждениях я не планирую погружаться в дебри дискуссий про то, что есть AGI, а чем он не является, а лишь сугубо попытаться соотнести академические бенчмарки применению на практике.
Большинство бенчмарков относятся к одной из 2 категорий:
1️⃣ Likelihood запросы. Есть вопрос, варианты ответа и тот, у которого правдоподобие максимальное выбирается в качестве предсказания модели и сопоставляется с правильным.
2️⃣ Генеративные запросы. На основе некоторого промпта и инструкции модель генерирует ответ. Далее происходит парсинг и то, что удалось вычленить сопоставляется с тем, что надо.
👍 Likelihood запросы
К первой категории относится, пожалуй, большинство задач (ArcEasy, ArcChallenge (не тот Arc!), HellaSwag, Winogrande, MMLU, MMLU-Pro и многие другие). Достоинством такого подхода является дешевизна 💲 прогона, так как по сути достаточно одного прогона модели для получения вероятностей токенов ответа. При этом общий префикс можно переиспользовать для разных вариантов, т.к запрос имеет вид:
{условие}{вариант_ответа}
Существенным недостатком данного подхода же является неочевидная связь между умением модели справляться с данными задачами и генерацией текста в свободной форме.
Например, в 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ки для своих нужд. Окончательный выбор стоит делать исходя из целевой задачи, протестировав самому на релевантных примерах. А в идеале собрать собственный бенч и регулярно его обновлять. Рекомендую отличный пост от Игоря Котенкова на данную тему.
👍10
Can LLMs write better code if you keep asking them to “write better code”?
[Блогпост][GitHub]
Забавный и поучительный блогпост про то, как LLMка (Claude 3.5 Sonnet) итеративно оптимизировала код под запросами вида
Постановка задачи следующая. Требуется написать код на Питоне для задачи а-ля LeetCode:
Исходное решение
Рабочий, но не самый эффективный код. Подсчет цифр в числе реализован через приведение его к строке, парсинг строки на цифры с последующим их суммированнием.
Итерация 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 (но без
И промпт требующий улучшения кода уже более подробный:
Но Claude обиделся, и код стал медленее (9.1x ускорение) и с багами (возможно, привык что его обманывают на деньги).
Несколько последующих итераций выдали версии с ускорением 65x-99.7x и с косяками. Т.е превзойти прямолинейную стратегию не удалось.
Вывод
Топовые LLM - мощные ассистенты для программиста, но за ними пока требуется глаз да глаз и экспертное мнение. Кожаные мешки все еще нужны. Пока...
[Блогпост][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 - мощные ассистенты для программиста, но за ними пока требуется глаз да глаз и экспертное мнение. Кожаные мешки все еще нужны. Пока...
❤15😁11
LLM KV cache compression made easy
[Репозиторий]
В связи с ростом потребности в эффективной по памяти и скорости работе с длинным контекстом (особенно с учетом набирающего популярность test-time compute scaling) все острее стоит вопрос сжатия KV-кэшей. Данной теме уже посвящено немалое число работ (и существует уже интеграция в transformers).
И недавно ребята из одной зеленой компании выкатили либу, с реализацией разных техник сжатия KV-кэшей под названием kvpress.
В данной либе реализовано несколько простых и популярных техник сжатия кэшей:
🌟 Случайный прунинг
🌟 Основанный на нормах токенов
🌟 Несколько подходов, основанных на attention скорах (SnapKV, TOVAPress, H20)
Причем битность можно задавать послойно при помощи класса
Самую SOTA (например, PyramidKV) в области пока еще не завезли, увы.
В репозитории есть ноутбуки с демострацией использования библиотеки и замерами скорости и памяти.
Либа действительно удобная и приятная для использования.
Методы сжатия кэшей можно комбинировать с квантизацией кэшей у лицехватов 🤗.
[Репозиторий]
В связи с ростом потребности в эффективной по памяти и скорости работе с длинным контекстом (особенно с учетом набирающего популярность test-time compute scaling) все острее стоит вопрос сжатия KV-кэшей. Данной теме уже посвящено немалое число работ (и существует уже интеграция в transformers).
И недавно ребята из одной зеленой компании выкатили либу, с реализацией разных техник сжатия KV-кэшей под названием kvpress.
В данной либе реализовано несколько простых и популярных техник сжатия кэшей:
🌟 Случайный прунинг
🌟 Основанный на нормах токенов
🌟 Несколько подходов, основанных на attention скорах (SnapKV, TOVAPress, H20)
Причем битность можно задавать послойно при помощи класса
PerLayerCompressionPress.Самую SOTA (например, PyramidKV) в области пока еще не завезли, увы.
В репозитории есть ноутбуки с демострацией использования библиотеки и замерами скорости и памяти.
Либа действительно удобная и приятная для использования.
Методы сжатия кэшей можно комбинировать с квантизацией кэшей у лицехватов 🤗.
👍7
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 раз.
Вывод
Сжатие кэшей - богоугодное дело. А дабы эффективно квантизовать кэши полезно смотреть на распределение того - что сжимаешь.
[Статья] [Код]
Для того, чтобы работать с большим контекстом в условии ограниченных ресурсов необходимо как-нибудь да сжимать 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 раз.
Вывод
Сжатие кэшей - богоугодное дело. А дабы эффективно квантизовать кэши полезно смотреть на распределение того - что сжимаешь.
🔥8👍1
Есть ли способ в телеграме выбрать себе вид наказания ботами или обменяться с кем-то?
Если уж выбирать зло, я бы предпочел шлюхоботов вместо дурацких NFT-ботов.
Зло есть Зло. Большее. Меньшее. Среднее... Какая разница? Зло трудно измерить, его границы размыты. И если мне придётся выбирать между одним Злом и другим, я не стану выбирать вовсе.
(с) Геральт из Ривии
Если уж выбирать зло, я бы предпочел шлюхоботов вместо дурацких NFT-ботов.
(с) Геральт из Ривии
😁21
Наткнулся на проект "Математические Этюды" где в формате красочных постов с визуализациями рассказывают про интересные факты и концепции из математики. С красивыми иллюстрациями, видосиками, ползунками.
В частности, внимания заслуживают:
📐 Пост про модель Пуанкаре Геометрии Лобачевского
🤔 Исчезающая клетка и числа Фибонначи
🌌 Три геометрии: сходства и различия
Жаль, что в те времена, когда я учился, такой красоты еще не было...
В частности, внимания заслуживают:
📐 Пост про модель Пуанкаре Геометрии Лобачевского
🤔 Исчезающая клетка и числа Фибонначи
🌌 Три геометрии: сходства и различия
Жаль, что в те времена, когда я учился, такой красоты еще не было...
👍12🔥8
KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization
[Статья][Код на месте]
И снова про квантизацию KV-кэшей.
Про это тему можно говорить бесконечно, но не буду утруждать себя, иначе вы потонете в потоке этой информации.
Примерно в одно время с KIVI другая команда выпустила статью, которая так же целится в сохранение приемлемого качества при квантизации ниже 4-бит.
[Статья][Код на месте]
И снова про квантизацию KV-кэшей.
Про это тему можно говорить бесконечно, но не буду утруждать себя, иначе вы потонете в потоке этой информации.
Примерно в одно время с KIVI другая команда выпустила статью, которая так же целится в сохранение приемлемого качества при квантизации ниже 4-бит.
🔥1
Метод
1️⃣ Первое наблюдение полностью идентично KIVI - ключи обладают ярко выраженными выбросами, а значения - нет. Потому ключи квантизуются поканально, значения - потокенно.
2️⃣ Далее замечают, что RoPE перемешивает соседние каналы и делает выбросы и channel-specific поведение не столько ярко выраженным, потому предлагают квантизовать ключи до применения RoPE и каждый раз применять его уже к квантизованным кэшам.
3️⃣ Однородная квантизация приятна и удобна в использовании, но обычно далека от оптимальной в плане ошибки. И не мудрствуя лукаво предлагают использовать 1-мерный k-means, но используя в качестве метрики не стандарную Евклидову, а диагональ матрицы Фишера, которую оценивают по маленькой выборке.
4️⃣ Некоторые значения сильно выбиваются среди остальных, потому их предлагается не квантизовать, а держать в виде разреженной матрицы (CSR, CSC). На практике берут 1% самых больших по модулю значений.
5️⃣ Модели чувствительны к изменениям attention sinks, отличающихся большими нормами активаций, потому предлагается их не квантизовать - все равно их мало, и на общей битности не скажется. Не квантизуют только первый токен.
6️⃣ Динамическое определение диапазона значений на лету дорого, и для поканального квантования требует пересчета значений всех токенов. По этой причине предлагают калибровку констант квантизации для ключей проводить offline, на небольшой выборке, а потокенную квантизацию кэшей на лету.
И для всей этой навороченной красоты пишут специальный кернел, что работало все с адекватной скоростью.
Эксперименты
Метод валидируют на перплексии на стандартной длине контекста на 🦙-1.
- В 4 бита просадка порядка 0.01 ppl
- В 3 бита просадка порядка 0.1 ppl
- В 2 бита - десятые
Затем метод проверяют на версиях Llama-2, адаптированных под длинный контекст, где KVQuant почти не просаживает метрики в 4 битах, и умеренно в 3 бита. На Passkey 🗝 retrieval метод не просаживается по качеству, в отличие от KIVI.
Далее KVQuant прогоняют на LongBench/RULER (где одна из задач - “иголка в сене”, вытащить нужный факт из далекого прошлого) - популярных бенчах на длинный контекст.
KVQuant снова лучше KIVI, на RULER KIVI (эффективно 3-битный) заметно страдает (56%->40%), но KVQuant теряет 3% качества (56->53%).
Метод совместим с квантизацией весов. Так как авторы KVQuant - авторы еще и SqueezeLLM, то совмещают именно с этим подходом. Квантизация кэшей почти не меняет метрики квантизованной модели.
В ablation показывают, что все компоненты важны для успеха:
1️⃣ Выбор размерностей для квантизации
2️⃣ Pre-RoPE квантизация
3️⃣ Неоднородная квантизация
4️⃣ Учет выбросов
Итоговое ускорение операций умножения в KV - 1.2x-1.7x (не end-to-end latency). При 2-битной квантизации удается впихнуть на одну A100 1M токенов для Llama-2-7b, и на 8 - 10M токенов.
Вывод
Метод композитный, солидный, заточенный под выбивание хорошего качества. Однако сложность имеет свою цену - и в данном случае это достаточно дорогая деквантизация, из-за которой ускорение инференса меньше, чем у конкуретных подходов (того же KIVI).
1️⃣ Первое наблюдение полностью идентично KIVI - ключи обладают ярко выраженными выбросами, а значения - нет. Потому ключи квантизуются поканально, значения - потокенно.
2️⃣ Далее замечают, что RoPE перемешивает соседние каналы и делает выбросы и channel-specific поведение не столько ярко выраженным, потому предлагают квантизовать ключи до применения RoPE и каждый раз применять его уже к квантизованным кэшам.
3️⃣ Однородная квантизация приятна и удобна в использовании, но обычно далека от оптимальной в плане ошибки. И не мудрствуя лукаво предлагают использовать 1-мерный k-means, но используя в качестве метрики не стандарную Евклидову, а диагональ матрицы Фишера, которую оценивают по маленькой выборке.
4️⃣ Некоторые значения сильно выбиваются среди остальных, потому их предлагается не квантизовать, а держать в виде разреженной матрицы (CSR, CSC). На практике берут 1% самых больших по модулю значений.
5️⃣ Модели чувствительны к изменениям attention sinks, отличающихся большими нормами активаций, потому предлагается их не квантизовать - все равно их мало, и на общей битности не скажется. Не квантизуют только первый токен.
6️⃣ Динамическое определение диапазона значений на лету дорого, и для поканального квантования требует пересчета значений всех токенов. По этой причине предлагают калибровку констант квантизации для ключей проводить offline, на небольшой выборке, а потокенную квантизацию кэшей на лету.
И для всей этой навороченной красоты пишут специальный кернел, что работало все с адекватной скоростью.
Эксперименты
Метод валидируют на перплексии на стандартной длине контекста на 🦙-1.
- В 4 бита просадка порядка 0.01 ppl
- В 3 бита просадка порядка 0.1 ppl
- В 2 бита - десятые
Затем метод проверяют на версиях Llama-2, адаптированных под длинный контекст, где KVQuant почти не просаживает метрики в 4 битах, и умеренно в 3 бита. На Passkey 🗝 retrieval метод не просаживается по качеству, в отличие от KIVI.
Далее KVQuant прогоняют на LongBench/RULER (где одна из задач - “иголка в сене”, вытащить нужный факт из далекого прошлого) - популярных бенчах на длинный контекст.
KVQuant снова лучше KIVI, на RULER KIVI (эффективно 3-битный) заметно страдает (56%->40%), но KVQuant теряет 3% качества (56->53%).
Метод совместим с квантизацией весов. Так как авторы KVQuant - авторы еще и SqueezeLLM, то совмещают именно с этим подходом. Квантизация кэшей почти не меняет метрики квантизованной модели.
В ablation показывают, что все компоненты важны для успеха:
1️⃣ Выбор размерностей для квантизации
2️⃣ Pre-RoPE квантизация
3️⃣ Неоднородная квантизация
4️⃣ Учет выбросов
Итоговое ускорение операций умножения в KV - 1.2x-1.7x (не end-to-end latency). При 2-битной квантизации удается впихнуть на одну A100 1M токенов для Llama-2-7b, и на 8 - 10M токенов.
Вывод
Метод композитный, солидный, заточенный под выбивание хорошего качества. Однако сложность имеет свою цену - и в данном случае это достаточно дорогая деквантизация, из-за которой ускорение инференса меньше, чем у конкуретных подходов (того же KIVI).
👍6🔥4
[Model page]
DeepSeek 🐳 выкатили пару часов назад на лицехватах 🤗 веса DeepSeek-R1 в публичный доступ!
Напомню, что это Reasoning модель, под цепоцки рассуждений а-ля o1, o1-mini, o3.
В модели 685B параметров и веса выложены в fp8-E4M3.
Архитектура почти идентична DeepSeek-V3.
Так что, счастливые обладатели 8+1 H100, развлекайтесь на здоровье)
DeepSeek 🐳 выкатили пару часов назад на лицехватах 🤗 веса DeepSeek-R1 в публичный доступ!
Напомню, что это Reasoning модель, под цепоцки рассуждений а-ля o1, o1-mini, o3.
В модели 685B параметров и веса выложены в fp8-E4M3.
Архитектура почти идентична DeepSeek-V3.
Так что, счастливые обладатели 8+1 H100, развлекайтесь на здоровье)
👍14😁6❤1
Inference-Time Scaling for Diffusion Models beyond Scaling Denoising Steps
[Статья][DeepMind не часто публикует код]
Введение
Данная статья уже появлялась на Love. Death. Transformers и была разобрана у Сиолошной . Тем не менее, выскажу свое скромное мнение 😉.
Inference-time scaling уже продемонстрировал впечатляющие результаты в контексте языковых моделей, где длинные цепочки рассуждений позволяют значительно улучшать качество на сложных задачах.
У диффузионных моделей механизм улучшения качества генераций за счет большего объема вычислений есть “из 📦” - выбор количества шагов сэмплирования. С ростом количества шагов расшумления качество полученных генераций и их соответствие запросу 🔼, но начиная с какого-то момента происходит насыщение, и дальнейшее повышение не приводит к значимым улучшениям, а иногда даже наоборот.
Поэтому в данной статье предлагают улучшать генерации за счет сэмплирования разных случайных шумов, начальных точек в процессе генерации, и выборе лучшего случайного зерна 🌱.
[Статья][DeepMind не часто публикует код]
Введение
Данная статья уже появлялась на Love. Death. Transformers и была разобрана у Сиолошной . Тем не менее, выскажу свое скромное мнение 😉.
Inference-time scaling уже продемонстрировал впечатляющие результаты в контексте языковых моделей, где длинные цепочки рассуждений позволяют значительно улучшать качество на сложных задачах.
У диффузионных моделей механизм улучшения качества генераций за счет большего объема вычислений есть “из 📦” - выбор количества шагов сэмплирования. С ростом количества шагов расшумления качество полученных генераций и их соответствие запросу 🔼, но начиная с какого-то момента происходит насыщение, и дальнейшее повышение не приводит к значимым улучшениям, а иногда даже наоборот.
Поэтому в данной статье предлагают улучшать генерации за счет сэмплирования разных случайных шумов, начальных точек в процессе генерации, и выборе лучшего случайного зерна 🌱.
👍7
Метод
В статье рассматривают две постановки:
1️⃣ Class-conditional генерация SiT-B/L/XL (какой-то трансформер с приблудами)
2️⃣ 📝-2-🖥 генерация c FLUX
В данной статье исследуют разные стратегии отбора лучших сэмплов и модели для оценки качества.
Стратегии отбора
1️⃣ Random Search. Просто сэмплируем независимо N кандидатов и берем лучшего (с точки зрения модели-оценщика).
2️⃣ Zero-Order Search. Стартуя со случайного шума, сэмплируем несколько шумов в его окрестности. Оцениваем их, находим лучший, и используем в качестве начальной точки на новой итерации. (Градиентная оптимизация требует проброса градиентов через всю цепочку сэмплирования, потому очень дорогая, и не очень хорошо работает, как показано в приложении)
3️⃣ Search over Paths. Сэмплируем несколько начальных шумов (траекторий), и с некоторого уровня шума генерируем несколько конечных сэмплов. Отбираем лучшие для каждой траектории, зашумляем до меньшего уровня шума и запускаем генерацию уже оттуда.
В качестве верификаторов для оценки качества class-conditional генерации используют:
1️⃣ Inception Score напрямую
2️⃣ CLIP (где эмбеддят класс в промпт вида “a photo of <class>” )
3️⃣ Линейный классификатор поверх DINOv2
При фиксированном (достаточно большом числе шагов) увеличивают количество случайных шумов. Метрика Inception Score (оценивающая точность распознавания сгенерированного изображения Inception-V3) монотонно растет с увеличением количества сэмплов (для supervised классификаторов ожидаемо сильнее). Однако, FID (тоже хреновая метрика, к слову), начиная с какого-то момента начинает расти (т.е ухудшаться). По всей видимости, это связано с тем, что строгий отбор снижает разнообразие генераций и имеет место переобучение под верификаторы.
В качестве альтернативы авторы предлагают self-supervised верификаторы - косинусную близость между логитами классификаторов x0-предсказания на малом уровне шума, и конечного сэмпла. И показывают, что она неплохо коррелирует с исходными классификаторами. Метрика не самая интуитивная. Предположительно, идея в том, что если сэмпл хороший получается, то на последнем участке генерации x0-предсказание слабо меняется.
Далее пробуют разные стратегии отбора, увеличивая число кандидатов. Метрики монотонно растут, но будто бы результаты мало зависят от гиперпараметров каждого из вариантов - размера окрестности в случае Zero-Order Search и числа траекторий для Search over Paths.
В статье рассматривают две постановки:
1️⃣ Class-conditional генерация SiT-B/L/XL (какой-то трансформер с приблудами)
2️⃣ 📝-2-🖥 генерация c FLUX
В данной статье исследуют разные стратегии отбора лучших сэмплов и модели для оценки качества.
Стратегии отбора
1️⃣ Random Search. Просто сэмплируем независимо N кандидатов и берем лучшего (с точки зрения модели-оценщика).
2️⃣ Zero-Order Search. Стартуя со случайного шума, сэмплируем несколько шумов в его окрестности. Оцениваем их, находим лучший, и используем в качестве начальной точки на новой итерации. (Градиентная оптимизация требует проброса градиентов через всю цепочку сэмплирования, потому очень дорогая, и не очень хорошо работает, как показано в приложении)
3️⃣ Search over Paths. Сэмплируем несколько начальных шумов (траекторий), и с некоторого уровня шума генерируем несколько конечных сэмплов. Отбираем лучшие для каждой траектории, зашумляем до меньшего уровня шума и запускаем генерацию уже оттуда.
В качестве верификаторов для оценки качества class-conditional генерации используют:
1️⃣ Inception Score напрямую
2️⃣ CLIP (где эмбеддят класс в промпт вида “a photo of <class>” )
3️⃣ Линейный классификатор поверх DINOv2
При фиксированном (достаточно большом числе шагов) увеличивают количество случайных шумов. Метрика Inception Score (оценивающая точность распознавания сгенерированного изображения Inception-V3) монотонно растет с увеличением количества сэмплов (для supervised классификаторов ожидаемо сильнее). Однако, FID (тоже хреновая метрика, к слову), начиная с какого-то момента начинает расти (т.е ухудшаться). По всей видимости, это связано с тем, что строгий отбор снижает разнообразие генераций и имеет место переобучение под верификаторы.
В качестве альтернативы авторы предлагают self-supervised верификаторы - косинусную близость между логитами классификаторов x0-предсказания на малом уровне шума, и конечного сэмпла. И показывают, что она неплохо коррелирует с исходными классификаторами. Метрика не самая интуитивная. Предположительно, идея в том, что если сэмпл хороший получается, то на последнем участке генерации x0-предсказание слабо меняется.
Далее пробуют разные стратегии отбора, увеличивая число кандидатов. Метрики монотонно растут, но будто бы результаты мало зависят от гиперпараметров каждого из вариантов - размера окрестности в случае Zero-Order Search и числа траекторий для Search over Paths.
Эксперименты
Для Text-2-Image генерации с FLUX в качестве верификаторов используют:
1️⃣ Классификатор эстетичности 💃 поверх OpenCLIP
2️⃣ CLIP Score
3️⃣ ImageReward
4️⃣ Ансамбль всех трех (с одинаковыми весами)
FLUXом гененируют по умолчанию в 30 шагов сэмплирования, SiT в 250.
Для оценки качества (не доверяя субъективного мнению кожаных мешков) используют Gemini-1.5-Flash, которая оценивает качество по 5 аспектам:
⚡️Accuracy to Prompt (соответствие запросу)
⚡️Originality (оригинальность)
⚡️Visual Quality (визуальное качество)
⚡️Internal Consistency (внутренняя консистентность)
⚡️Emotional Resonance (в душе не ебу, что это, возможно, степень шатания смотрящего от эмоций при взгляде на картинку )
Для валидации используют DrawBench и T2I-CompBench.
Сначала исследуют взаимные корреляции между разными верификаторами на DrawBench.
Эстетичность коррелирует с ImageReward, но слегка понижает CLIP Score. Общее качество (по мнению Gemini) немного растет.
CLIP Score повышает ImageReward, но слегка понижает эстетичность. Общее качество слегка улучшается.
ImageReward повышает CLIP Score и оценку Gemini более существенно, эстетичность почти не меняется.
Ансамбль всех трех метрик улучшает все три метрики.
При увеличении количества сэмплов в ансамбле все метрики растут, но ImageReward значительнее всего (вероятно, из-за шкалы).
На максимуме ставят суммарное число прогонов через модель (2880 = 96 сэмплов х 30 шагов). Весьма забавно, что лучше всего себя показывает наивная стратегия независимой генерации случайных шумов, а остальные две, более заумные стратегии, не приносят пользы.
На T2I-CompBench, где оценивается соответствие промпту - взаимоотношения между объектами, формы, их положение, а не эстетичность, классификатор эстетичности слегка просаживает метрики, а CLIP Score и ImageReward улучшает. Причем ImageReward лучше ансамбля, по всей видимости, из-за наличия Aesthetic Score.
Предложенный метод работает и поверх DPO дообученной SDXL.
При фиксированном бюджете (если он мал) для SiT-XL выгоднее нагенерить несколько траекторий с меньшим количеством шагов, чем одну “дорогую”. Но с ростом доступного бюджета становится полезным повышать число шагов сэмплера.
Кроме того, на малых бюджетах меньшие версии SiT-B/L, генерирующее нескольких кандидатов, лучше чем один прогон через большую SiT-XL.
Выводы
С идейной точки зрения - направление исследований довольно интересное, однако польза пока еще не столь очевидна, как для LLM, где сложный reasoning процесс позволяет решать сложные задачи (недоступные без него), а здесь же приводит к некоторому улучшению метрик. На текущий момент процесс слишком дорогой для большинства практических приложений (ибо ждать несколько минут вместо нескольких секунд для создания немного более хорошей картинки не каждый готов, да и стоить сие будет у провайдеров недешево). Тем не менее, подход может быть использован для генерации высококачественной синтетики.
Для Text-2-Image генерации с FLUX в качестве верификаторов используют:
1️⃣ Классификатор эстетичности 💃 поверх OpenCLIP
2️⃣ CLIP Score
3️⃣ ImageReward
4️⃣ Ансамбль всех трех (с одинаковыми весами)
FLUXом гененируют по умолчанию в 30 шагов сэмплирования, SiT в 250.
Для оценки качества (не доверяя субъективного мнению кожаных мешков) используют Gemini-1.5-Flash, которая оценивает качество по 5 аспектам:
⚡️Accuracy to Prompt (соответствие запросу)
⚡️Originality (оригинальность)
⚡️Visual Quality (визуальное качество)
⚡️Internal Consistency (внутренняя консистентность)
⚡️Emotional Resonance (
Для валидации используют DrawBench и T2I-CompBench.
Сначала исследуют взаимные корреляции между разными верификаторами на DrawBench.
Эстетичность коррелирует с ImageReward, но слегка понижает CLIP Score. Общее качество (по мнению Gemini) немного растет.
CLIP Score повышает ImageReward, но слегка понижает эстетичность. Общее качество слегка улучшается.
ImageReward повышает CLIP Score и оценку Gemini более существенно, эстетичность почти не меняется.
Ансамбль всех трех метрик улучшает все три метрики.
При увеличении количества сэмплов в ансамбле все метрики растут, но ImageReward значительнее всего (вероятно, из-за шкалы).
На максимуме ставят суммарное число прогонов через модель (2880 = 96 сэмплов х 30 шагов). Весьма забавно, что лучше всего себя показывает наивная стратегия независимой генерации случайных шумов, а остальные две, более заумные стратегии, не приносят пользы.
На T2I-CompBench, где оценивается соответствие промпту - взаимоотношения между объектами, формы, их положение, а не эстетичность, классификатор эстетичности слегка просаживает метрики, а CLIP Score и ImageReward улучшает. Причем ImageReward лучше ансамбля, по всей видимости, из-за наличия Aesthetic Score.
Предложенный метод работает и поверх DPO дообученной SDXL.
При фиксированном бюджете (если он мал) для SiT-XL выгоднее нагенерить несколько траекторий с меньшим количеством шагов, чем одну “дорогую”. Но с ростом доступного бюджета становится полезным повышать число шагов сэмплера.
Кроме того, на малых бюджетах меньшие версии SiT-B/L, генерирующее нескольких кандидатов, лучше чем один прогон через большую SiT-XL.
Выводы
С идейной точки зрения - направление исследований довольно интересное, однако польза пока еще не столь очевидна, как для LLM, где сложный reasoning процесс позволяет решать сложные задачи (недоступные без него), а здесь же приводит к некоторому улучшению метрик. На текущий момент процесс слишком дорогой для большинства практических приложений (ибо ждать несколько минут вместо нескольких секунд для создания немного более хорошей картинки не каждый готов, да и стоить сие будет у провайдеров недешево). Тем не менее, подход может быть использован для генерации высококачественной синтетики.
arXiv.org
ImageReward: Learning and Evaluating Human Preferences for...
We present a comprehensive solution to learn and improve text-to-image models from human preference feedback. To begin with, we build ImageReward -- the first general-purpose text-to-image human...
❤9👍1
Visual Autoregressive Modeling for Image Super-Resolution
[Статья][Рыдми]
Введение
VAR и его производные в прошлом году произвели некоторый ажиотаж, показав вполне достойные результаты в задачах class-conditional и text-to-image генерации.
Ранее было показано, что дообучение text-2-image диффузионных моделей (так называемый SR c generative prior) на задачу Blind Super Resolution (с произвольными деградациями входных изображений) неплохо себя показывает в случае сильно шакальных картинок.
В этой же статье предложили по существу перенести данную идею на VARы - а именно, дообучить class-conditional VAR на задачу Super Resolution. И не особо заморачиваясь с оригинальностью и звучностью назвали свое детище VARSR 🥱.
[Статья][Рыдми]
Введение
VAR и его производные в прошлом году произвели некоторый ажиотаж, показав вполне достойные результаты в задачах class-conditional и text-to-image генерации.
Ранее было показано, что дообучение text-2-image диффузионных моделей (так называемый SR c generative prior) на задачу Blind Super Resolution (с произвольными деградациями входных изображений) неплохо себя показывает в случае сильно шакальных картинок.
В этой же статье предложили по существу перенести данную идею на VARы - а именно, дообучить class-conditional VAR на задачу Super Resolution. И не особо заморачиваясь с оригинальностью и звучностью назвали свое детище VARSR 🥱.
❤4🔥2