MAC-Attention: a Match-Amend-Complete Scheme for Fast and Accurate Attention Computation
📄 [Статья]
💻 [Код]
В стандартной реализации для каждой новой query мы проходимся по всем посчитанным ранее парам ключей и значений и считаем результат.
Но можно ли как-то переиспользовать прошлые вычисления?
И работа, рассматриваемая ниже, предлагает интересный подход по переиспользованию вычислений для похожих query.
📄 [Статья]
💻 [Код]
В стандартной реализации для каждой новой query мы проходимся по всем посчитанным ранее парам ключей и значений и считаем результат.
Но можно ли как-то переиспользовать прошлые вычисления?
И работа, рассматриваемая ниже, предлагает интересный подход по переиспользованию вычислений для похожих query.
🔬 Метод
Разобьем последовательность на префикс P и суффикс S.
Пусть N — числитель, а D — знаменатель. Тогда выход внимания имеет следующий вид:
Предположим, что для текущей query нашлась достаточно близкая (по какой-то мере похожести).
Тогда мы можем переиспользовать предпосчитанные числитель и знаменатель от этой близкой query, и остается только посчитать члены между той query и текущей позицией.
⚙️ Важные практические соображения
Хранить целесообразно небольшой скользящий буфер query. Полный query cache (в силу распространения GQA / MLA) будет в разы дороже KV-кэша, да и выигрыш тем больше, чем больше токенов мы переиспользуем (чем ближе по позиции близкая query к текущей).
Хотим, с одной стороны, переиспользовать как можно больше вычислений, но при этом не терять в качестве.
В качестве меры похожести используется L2-расстояние между pre-RoPE ключами. pre-RoPE критично, иначе близкие семантически query разъедутся из-за позиционных эмбеддингов. Если похожая query не нашлась (минимальная ошибка выше порога), то считаем так, как считали бы при стандартном инференсе.
Под это все у них есть самописные кернелы эффективного поиска похожей query и внимания с переиспользованием вычислений.
📊 Эксперименты
Метод валидируют на моделях семейства Llama-3.1 / GLM-4 / Phi-4 и бенчах на длинный контекст LongBench v1/v2 и RULER.
На практике берут окно из 1024 последних токенов для поиска ближайшей query, а порог близости был как-то подобран вручную.
Качество якобы не просаживается, а где-то даже и растет (даже на бюджетах порядка 1%). Но похоже на скам.
Свои кернелы они интегрировали в SGLang и утверждают, что достигают 4× уменьшения latency attention против full attention и работают быстрее всяких прунингов. Подозрительно, что RocketKV такой медленный…
🚀 На больших батчах и с 99% sparsity говорят, что якобы ускоряют внимание до 40 раз.
💾 Сам метод дает примерно 5% дополнительного оверхеда по GPU-памяти (в зависимости от числа групп в GQA) на длине контекста 128k с настройками по умолчанию.
📝 Вывод
Идейка прикольная, даже удивительно, что до нее додумались сравнительно недавно — только в апреле этого года.
Не хватает замеров на более серьезных моделях и бенчах (типа математики, кода и агентских задач), а также end-to-end сравнений по скорости.
Разобьем последовательность на префикс P и суффикс S.
Пусть N — числитель, а D — знаменатель. Тогда выход внимания имеет следующий вид:
O = (N_P + N_S) / (D_P + D_S)Предположим, что для текущей query нашлась достаточно близкая (по какой-то мере похожести).
Тогда мы можем переиспользовать предпосчитанные числитель и знаменатель от этой близкой query, и остается только посчитать члены между той query и текущей позицией.
⚙️ Важные практические соображения
Хранить целесообразно небольшой скользящий буфер query. Полный query cache (в силу распространения GQA / MLA) будет в разы дороже KV-кэша, да и выигрыш тем больше, чем больше токенов мы переиспользуем (чем ближе по позиции близкая query к текущей).
Хотим, с одной стороны, переиспользовать как можно больше вычислений, но при этом не терять в качестве.
В качестве меры похожести используется L2-расстояние между pre-RoPE ключами. pre-RoPE критично, иначе близкие семантически query разъедутся из-за позиционных эмбеддингов. Если похожая query не нашлась (минимальная ошибка выше порога), то считаем так, как считали бы при стандартном инференсе.
Под это все у них есть самописные кернелы эффективного поиска похожей query и внимания с переиспользованием вычислений.
📊 Эксперименты
Метод валидируют на моделях семейства Llama-3.1 / GLM-4 / Phi-4 и бенчах на длинный контекст LongBench v1/v2 и RULER.
На практике берут окно из 1024 последних токенов для поиска ближайшей query, а порог близости был как-то подобран вручную.
Качество якобы не просаживается, а где-то даже и растет (даже на бюджетах порядка 1%). Но похоже на скам.
Свои кернелы они интегрировали в SGLang и утверждают, что достигают 4× уменьшения latency attention против full attention и работают быстрее всяких прунингов. Подозрительно, что RocketKV такой медленный…
🚀 На больших батчах и с 99% sparsity говорят, что якобы ускоряют внимание до 40 раз.
💾 Сам метод дает примерно 5% дополнительного оверхеда по GPU-памяти (в зависимости от числа групп в GQA) на длине контекста 128k с настройками по умолчанию.
📝 Вывод
Идейка прикольная, даже удивительно, что до нее додумались сравнительно недавно — только в апреле этого года.
Не хватает замеров на более серьезных моделях и бенчах (типа математики, кода и агентских задач), а также end-to-end сравнений по скорости.
🔥8
Improving Neural Network Training by Decoupling the Magnitude and Direction of Weight Vectors
📄 [Статья]
💻 [Кода нет]
Обыкновенно оптимизаторы, будь то Адам, Мюон или любой другой, оптимизируют матрицы весов как единое целое. Однако бывает полезно разделить радиальную динамику (изменение величины весов) и угловую.
И в данной работе авторы предлагают факторизовать вес как произведение компоненты единичной нормы (лежащей на сфере) и обучаемых масштабов (gains), что в итоге дает ускорение сходимости по сравнению с базовыми оптимизаторами.
📄 [Статья]
💻 [Кода нет]
Обыкновенно оптимизаторы, будь то Адам, Мюон или любой другой, оптимизируют матрицы весов как единое целое. Однако бывает полезно разделить радиальную динамику (изменение величины весов) и угловую.
И в данной работе авторы предлагают факторизовать вес как произведение компоненты единичной нормы (лежащей на сфере) и обучаемых масштабов (gains), что в итоге дает ускорение сходимости по сравнению с базовыми оптимизаторами.
🔬 Метод
Авторы замечают, что обновления весов в радиальном и угловом направлениях не являются независимыми. Для оптимизаторов типа Адама/Мюона величина шага не зависит от нормы весов, поэтому изменение угла обратно пропорционально норме весов. Аналогично, при движении вдоль касательной (по радиальному градиенту) растет норма весов. И чтобы она не улетела в космос, приходится накладывать weight decay.
🧮 Дабы обеспечить контроль над величиной веса, его можно представить в следующем виде:
Где W_hat — нормализованный вес, а γ_row и γ_col — построчные и поколоночные мультипликаторы, которые могут быть как скалярами, так и векторами. Нормализовать можно как по норме Фробениуса всей матрицы, так и по строкам или столбцам.
📊 Эксперименты
🧪 Авторы аблируют разные варианты нормализации и параметризации gains.
Вариант с нормализацией всей матрицы выглядит не хуже остальных, будучи при этом самым простым, поэтому в итоге используют именно его.
✅ γ_row и γ_col полезно иметь в виде векторов, причем оба должны быть обучаемыми. Использование row и col gains более высокого ранга не помогает. Чтобы gains не обращались в ноль, их можно параметризовать через строго положительную функцию активации, но и без такой параметризации метод работает стабильно.
📈 Хорошим свойством нормализации весов является переносимость learning rate между моделями разной ширины и глубины. Оптимальная величина шага обучения оказывается почти постоянной.
Кроме того, больше не нужен warmup в начале обучения, так как оптимизатор не взрывается по ходу обучения. Weight decay теперь тоже становится лишним, поскольку параметризация сама обеспечивает нахождение нормы весов в разумных пределах.
📉 Лучше всего работает линейное затухание learning rate вместо популярного нынче WSD.
🏆 В итоге лучший вариант MuonMD (Magnitude-Direction) сходится быстрее по числу итераций по сравнению с базовым Мюоном. Причем работает он хорошо как для Dense-, так и для MoE-моделей.
⚙️ На практике веса моделей хранятся так же, как и раньше: разбиение на величину и угол выполняется внутри оптимизатора. Замедление шага обучения при этом небольшое (около 5% у Адама и 1–2% у Мюона).
💡 Выводы
Выглядит как многообещающий и интересный результат. Интересно, насколько скоро данная техника будет внедрена в обучение больших моделей и станет ли она такой же стандартной практикой, как Мюон.
Авторы замечают, что обновления весов в радиальном и угловом направлениях не являются независимыми. Для оптимизаторов типа Адама/Мюона величина шага не зависит от нормы весов, поэтому изменение угла обратно пропорционально норме весов. Аналогично, при движении вдоль касательной (по радиальному градиенту) растет норма весов. И чтобы она не улетела в космос, приходится накладывать weight decay.
🧮 Дабы обеспечить контроль над величиной веса, его можно представить в следующем виде:
W = diag(γ_row) W_hat diag(γ_col)Где W_hat — нормализованный вес, а γ_row и γ_col — построчные и поколоночные мультипликаторы, которые могут быть как скалярами, так и векторами. Нормализовать можно как по норме Фробениуса всей матрицы, так и по строкам или столбцам.
📊 Эксперименты
🧪 Авторы аблируют разные варианты нормализации и параметризации gains.
Вариант с нормализацией всей матрицы выглядит не хуже остальных, будучи при этом самым простым, поэтому в итоге используют именно его.
✅ γ_row и γ_col полезно иметь в виде векторов, причем оба должны быть обучаемыми. Использование row и col gains более высокого ранга не помогает. Чтобы gains не обращались в ноль, их можно параметризовать через строго положительную функцию активации, но и без такой параметризации метод работает стабильно.
📈 Хорошим свойством нормализации весов является переносимость learning rate между моделями разной ширины и глубины. Оптимальная величина шага обучения оказывается почти постоянной.
Кроме того, больше не нужен warmup в начале обучения, так как оптимизатор не взрывается по ходу обучения. Weight decay теперь тоже становится лишним, поскольку параметризация сама обеспечивает нахождение нормы весов в разумных пределах.
📉 Лучше всего работает линейное затухание learning rate вместо популярного нынче WSD.
🏆 В итоге лучший вариант MuonMD (Magnitude-Direction) сходится быстрее по числу итераций по сравнению с базовым Мюоном. Причем работает он хорошо как для Dense-, так и для MoE-моделей.
⚙️ На практике веса моделей хранятся так же, как и раньше: разбиение на величину и угол выполняется внутри оптимизатора. Замедление шага обучения при этом небольшое (около 5% у Адама и 1–2% у Мюона).
💡 Выводы
Выглядит как многообещающий и интересный результат. Интересно, насколько скоро данная техника будет внедрена в обучение больших моделей и станет ли она такой же стандартной практикой, как Мюон.
🔥8
DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation
📄 Статья
💻 Код (DeepSpec)
С начала текущего года вышел ряд работ (DFlash и follow-up research), предлагающих различные варианты параллельного драфтинга, когда драфт-модель предсказывает несколько токенов за один раз. Такие подходы позволяют использовать более сильную модель в качестве черновой и могут выдавать acceptance на уровне или даже лучше, чем SOTA AR-методы спекдека. Но будто бы потенциал для дальнейшего улучшения все еще есть.
Ребята из DeepSeek проделали кропотливую инженерную работу, внесли определенные архитектурные изменения, а заодно предложили динамически подбирать длину драфта, чтобы оптимизировать производительность под разные типы запросов и текущую нагрузку.
📄 Статья
💻 Код (DeepSpec)
С начала текущего года вышел ряд работ (DFlash и follow-up research), предлагающих различные варианты параллельного драфтинга, когда драфт-модель предсказывает несколько токенов за один раз. Такие подходы позволяют использовать более сильную модель в качестве черновой и могут выдавать acceptance на уровне или даже лучше, чем SOTA AR-методы спекдека. Но будто бы потенциал для дальнейшего улучшения все еще есть.
Ребята из DeepSeek проделали кропотливую инженерную работу, внесли определенные архитектурные изменения, а заодно предложили динамически подбирать длину драфта, чтобы оптимизировать производительность под разные типы запросов и текущую нагрузку.
❤5
🔧 Метод
Параллельный драфтинг хорош тем, что он действительно параллелен, но не учитывает последовательную зависимость между токенами. А авторегрессионную модель нужно гонять каждый раз для каждого токена.
Отсюда предлагают гибридное решение — такую же параллельную тушку, как в DFlash, поверх которой обучают легковесный авторегрессионный модуль. Рассматривают два варианта:
* 🔹 Простая линейная марковская голова (с малоранговым боттлнеком), которая принимает на вход прошлый токен.
* 🔹 Небольшая RNN.
Далее, основываясь на народной мудрости и опыте, делают два важных замечания:
* 📈 Acceptance length сильно разнится между областями. У кода следующие токены более предсказуемы, и она больше; в диалогах — меньше.
* 📦 Чем больше размер батча, тем меньше выигрыш от использования спекдека и тем более заметно ощущается стоимость верификации.
Отсюда возникает идея обучить дополнительную голову, которая будет предсказывать, будет ли токен отринут или нет. За счет этого можно не утруждать таргет проверкой того, что наверняка не примется. Так как предсказания классификатора выдают уверенность выше, чем надо (overconfidence), полученные вероятности дополнительно калибруют на некоторой выборке.
Оптимальные длины драфтов подбирают при помощи некоего жадного алгоритма. На вход подаются текущий размер батча, текущие длины драфтов и предсказанные уверенности, а на выходе — оптимальные длины, достигающие максимального throughput.
🧮 Лосс-функция состоит из трех членов:
* 📌 Стандартная кросс-энтропия.
* 📌 Total Variation между драфтом и таргетом.
* 📌 Confidence Loss (бинарная кросс-энтропия).
Итоговый лосс является взвешенной суммой всего перечисленного.
📊 Эксперименты
Сначала тестируют предложенный подход на Qwen3-{4B, 8B, 14B} и Gemma4-12B против DFlash и EAGLE-3 в качестве бейзлайнов. DFlash и DSpark используют один и тот же параллельный бэкбон. Все модели обучаются на одних и тех же данных.
✅ У DSpark консистентно выше acceptance length (примерно на 16–18%).
Далее авторы исследуют acceptance в зависимости от позиции и замечают, что DFlash более уверенно предсказывает первые токены по сравнению с EAGLE-3 благодаря более мощной модели, но acceptance rate токена падает с глубиной. У EAGLE-3 он может даже расти, но из-за меньшей точности на первых токенах драфта итоговая acceptance length оказывается меньше. DSpark же имеет хороший acceptance в начале, который еще и практически не убывает.
Уже 2 слоя DSpark якобы не хуже 5 слоев DFlash. В качестве авторегрессионной части пробуют марковскую голову и RNN. RNN дает чуть больший acceptance, но имеет больший оверхед и сложнее в реализации, поэтому останавливаются на марковской голове.
📈 Повышение порога confidence (стоит ли вообще верифицировать данный токен) увеличивает acceptance length.
Потом авторы масштабируют историю на DeepSeek-V4, и DSpark выдает заметно лучшее соотношение throughput/latency по сравнению с MTP-бейзлайном.
⚙️ Из технических сложностей стоит отметить невозможность работать с CUDA-графами из-за динамических размеров входов и сложности с Zero-Overhead Scheduling. Чтобы решить вторую проблему, используют verification capacity с двух шагов назад (ZOS требует знания размера батча заранее).
💡 Выводы
Результат и наблюдения, безусловно, ценные — как любят и умеют делать ребята из DeepSeek.
В основе метода все еще лежит DFlash, так что не стоит утверждать, что это принципиально новая парадигма. И у DFlash не так много ручек, которые нужно крутить, чтобы выжать максимальный перф.
Параллельный драфтинг хорош тем, что он действительно параллелен, но не учитывает последовательную зависимость между токенами. А авторегрессионную модель нужно гонять каждый раз для каждого токена.
Отсюда предлагают гибридное решение — такую же параллельную тушку, как в DFlash, поверх которой обучают легковесный авторегрессионный модуль. Рассматривают два варианта:
* 🔹 Простая линейная марковская голова (с малоранговым боттлнеком), которая принимает на вход прошлый токен.
* 🔹 Небольшая RNN.
Далее, основываясь на народной мудрости и опыте, делают два важных замечания:
* 📈 Acceptance length сильно разнится между областями. У кода следующие токены более предсказуемы, и она больше; в диалогах — меньше.
* 📦 Чем больше размер батча, тем меньше выигрыш от использования спекдека и тем более заметно ощущается стоимость верификации.
Отсюда возникает идея обучить дополнительную голову, которая будет предсказывать, будет ли токен отринут или нет. За счет этого можно не утруждать таргет проверкой того, что наверняка не примется. Так как предсказания классификатора выдают уверенность выше, чем надо (overconfidence), полученные вероятности дополнительно калибруют на некоторой выборке.
Оптимальные длины драфтов подбирают при помощи некоего жадного алгоритма. На вход подаются текущий размер батча, текущие длины драфтов и предсказанные уверенности, а на выходе — оптимальные длины, достигающие максимального throughput.
🧮 Лосс-функция состоит из трех членов:
* 📌 Стандартная кросс-энтропия.
* 📌 Total Variation между драфтом и таргетом.
* 📌 Confidence Loss (бинарная кросс-энтропия).
Итоговый лосс является взвешенной суммой всего перечисленного.
📊 Эксперименты
Сначала тестируют предложенный подход на Qwen3-{4B, 8B, 14B} и Gemma4-12B против DFlash и EAGLE-3 в качестве бейзлайнов. DFlash и DSpark используют один и тот же параллельный бэкбон. Все модели обучаются на одних и тех же данных.
✅ У DSpark консистентно выше acceptance length (примерно на 16–18%).
Далее авторы исследуют acceptance в зависимости от позиции и замечают, что DFlash более уверенно предсказывает первые токены по сравнению с EAGLE-3 благодаря более мощной модели, но acceptance rate токена падает с глубиной. У EAGLE-3 он может даже расти, но из-за меньшей точности на первых токенах драфта итоговая acceptance length оказывается меньше. DSpark же имеет хороший acceptance в начале, который еще и практически не убывает.
Уже 2 слоя DSpark якобы не хуже 5 слоев DFlash. В качестве авторегрессионной части пробуют марковскую голову и RNN. RNN дает чуть больший acceptance, но имеет больший оверхед и сложнее в реализации, поэтому останавливаются на марковской голове.
📈 Повышение порога confidence (стоит ли вообще верифицировать данный токен) увеличивает acceptance length.
Потом авторы масштабируют историю на DeepSeek-V4, и DSpark выдает заметно лучшее соотношение throughput/latency по сравнению с MTP-бейзлайном.
⚙️ Из технических сложностей стоит отметить невозможность работать с CUDA-графами из-за динамических размеров входов и сложности с Zero-Overhead Scheduling. Чтобы решить вторую проблему, используют verification capacity с двух шагов назад (ZOS требует знания размера батча заранее).
💡 Выводы
Результат и наблюдения, безусловно, ценные — как любят и умеют делать ребята из DeepSeek.
В основе метода все еще лежит DFlash, так что не стоит утверждать, что это принципиально новая парадигма. И у DFlash не так много ручек, которые нужно крутить, чтобы выжать максимальный перф.
❤7💯7⚡2🔥1
Forwarded from Минималистик🧀
Оооо дооодоо ДипСик выпустил новую крутую модель дооодоо, короче все уже написали про DSpark в том числе канал «Islam Insights» и «AI Beauty» ну куда мне с такими игроками тягаться, ладно и я напишу, потому что как минимум пишу его реализацию в vllm
Архитектура - спиздили, взяли бекбон Dflash добавили калибровку логитов сверху Марков 🎩(FlexDraft, Domino) и ещё реализовали Конфиденс 🎩 (SpecDec+), чтобы ну давать некую уверенность в токене. Зачем этонужно? Важно? ну вот зачем? Чтобы потом было удобно делать динамический драфт о чем писал выше
Бля просто обидно за дифлеш пиздец про него писали буквально я и боты в тг, ну и вот он только только начал быть виральным (я к нему даже мультимодалку прикрутил) и Опа Дспарк дооо доо, вот реально обидно как за братишку с вуза которого на работу не берут, а потом чел с 0 опыта идёт тимлидить написание промптов в сбере, выступает на датафесте и лутает 1к в тгк, бля вот хотите быть реально нишевыми юзайте дфлэш либо лукахед, а вот это вот хуйня для зумеров сидеть у помойки есть оверхайп бейглы
Вот вам инсайт на подумать: оригинальный дфлеш жмёт 5/7 токенов, дспарк 6/7, но если убрать рекурсию сверху то 1.5/7, и этого мы добивались? Бек ту зе рутс? А может Редрафтер от эппла? Игл? Типа сверху неиронично цикл лупанули и сидят довольные, а может цикл в цикле? Вы собесы Яндекса вообще проходили?
Нет бы реализовать динамический драфтинг нормально в граф моде сидят хуйней страдают - немощь блин
Архитектура - спиздили, взяли бекбон Dflash добавили калибровку логитов сверху Марков 🎩(FlexDraft, Domino) и ещё реализовали Конфиденс 🎩 (SpecDec+), чтобы ну давать некую уверенность в токене. Зачем это
Бля просто обидно за дифлеш пиздец про него писали буквально я и боты в тг, ну и вот он только только начал быть виральным (я к нему даже мультимодалку прикрутил) и Опа Дспарк дооо доо, вот реально обидно как за братишку с вуза которого на работу не берут, а потом чел с 0 опыта идёт тимлидить написание промптов в сбере, выступает на датафесте и лутает 1к в тгк, бля вот хотите быть реально нишевыми юзайте дфлэш либо лукахед, а вот это вот хуйня для зумеров сидеть у помойки есть оверхайп бейглы
Вот вам инсайт на подумать: оригинальный дфлеш жмёт 5/7 токенов, дспарк 6/7, но если убрать рекурсию сверху то 1.5/7, и этого мы добивались? Бек ту зе рутс? А может Редрафтер от эппла? Игл? Типа сверху неиронично цикл лупанули и сидят довольные, а может цикл в цикле? Вы собесы Яндекса вообще проходили?
Нет бы реализовать динамический драфтинг нормально в граф моде сидят хуйней страдают - немощь блин
❤30😁17👎2🤡1
On Efficient Scaling of GNNs via IO-Aware Layers Implementations
📄 Статья
💻 Код
Засветилось уже много где в русскоязычных тг-каналах про ML, но оно заслуживает отдельного разбора.
Графовые нейронные сети имеют ряд небесполезных приложений — всякий там дизайн новых молекул, физика, анализ транзакций и социальных сетей.
Однако их оптимизации уделялось сравнительно мало внимания по сравнению с LLM, потому существующие реализации в популярных фреймворках (DGL, PyG) далеки от оптимального потребления памяти и вычислительных ресурсов.
Существенной сложностью при работе с графами являются нерегулярная/разреженная структура данных и нерегулярные паттерны доступа. И в работе наших соотечественников (Spotlight на ICML, между прочим) сделали куда более эффективную реализацию стандартных графовых операций.
📄 Статья
💻 Код
Засветилось уже много где в русскоязычных тг-каналах про ML, но оно заслуживает отдельного разбора.
Графовые нейронные сети имеют ряд небесполезных приложений — всякий там дизайн новых молекул, физика, анализ транзакций и социальных сетей.
Однако их оптимизации уделялось сравнительно мало внимания по сравнению с LLM, потому существующие реализации в популярных фреймворках (DGL, PyG) далеки от оптимального потребления памяти и вычислительных ресурсов.
Существенной сложностью при работе с графами являются нерегулярная/разреженная структура данных и нерегулярные паттерны доступа. И в работе наших соотечественников (Spotlight на ICML, между прочим) сделали куда более эффективную реализацию стандартных графовых операций.
❤4
🛠 Метод
Работа фокусируется на ускорении трех ключевых типов операций в GNN:
- 🔹 Разреженные свертки.
- 🔹 Редукции на графах (min/max).
- 🔹 Внимание на графах.
Замечают, что распределение вершин графов по степеням обыкновенно имеет тяжелые хвосты. Потому разделяют вершины на две группы по степени — легкие и тяжелые вершины.
Для легких вершин используют параллелизм по признакам (один threadblock на вершину). Тяжелые вершины еще разбиваются на чанки по ребрам с промежуточной агрегацией по чанкам.
Объем подгружаемых данных не меняется, но ускорение достигается за счет того, что один блок обрабатывает несколько узлов, тем самым повышая memory-level параллелизм.
Для слоев внимания реализуют кастомный вариант FlashAttention для CSR-матриц. В наивной реализации материализовали матрицы внимания, а тут оно и не нужно.
CSR-кернелы для произвольной sparsity уже неплохи, но не используют ценный ресурс современных GPU — тензорные ядра. Если запаковать окрестности вершин в тайлы 16×16, то можно воспользоваться ими и, даже выполняя некоторые лишние вычисления, выжать ускорение.
Кроме того, существующие либы почему-то не используют cuSPARSE — рабочий и мощный инструмент. Одно его накатывание + кастомные адаптации уже дает заметный профит.
📊 Эксперименты
Эффективность реализации проверяют на бенчмарке GraphLand — наборе задач с большим разнообразием структур и свойств графов.
Удается выжать медианное ускорение порядка 2× (вплоть до 8.5×) против DGL на GATv2, медианное ускорение 2.6× (вплоть до 10×) на операциях редукции. Операции разреженных сверток на cuSPARSE дают вплоть до 8× ускорения. Кроме того, пиковое потребление памяти оказывается обычно в разы меньше (а то и в десятки раз) по сравнению с DGL. PyG тоже в среднем ест меньше GPU VRAM, но при этом он куда медленнее.
В ablation показывают, что выигрыш от graph reordering и векторизованных загрузок зависит от графа. Для плотных графов с высокой степенью выигрыш значителен, для разреженных и малостепенных — мал.
В приложении много внимания уделено исследованию полезности блочной разреженности с тензорными ядрами — где накладные расходы на перестановки окупаются, а где нет.
💡 Выводы
Классная и полезная работа, дающая существенный толчок всей области GraphML. Хоть она и довольно нишевая и на любителя, тем не менее импакт более чем серьезный. Интересно, где еще есть низковисящие фрукты для оптимизации?
Работа фокусируется на ускорении трех ключевых типов операций в GNN:
- 🔹 Разреженные свертки.
- 🔹 Редукции на графах (min/max).
- 🔹 Внимание на графах.
Замечают, что распределение вершин графов по степеням обыкновенно имеет тяжелые хвосты. Потому разделяют вершины на две группы по степени — легкие и тяжелые вершины.
Для легких вершин используют параллелизм по признакам (один threadblock на вершину). Тяжелые вершины еще разбиваются на чанки по ребрам с промежуточной агрегацией по чанкам.
Объем подгружаемых данных не меняется, но ускорение достигается за счет того, что один блок обрабатывает несколько узлов, тем самым повышая memory-level параллелизм.
Для слоев внимания реализуют кастомный вариант FlashAttention для CSR-матриц. В наивной реализации материализовали матрицы внимания, а тут оно и не нужно.
CSR-кернелы для произвольной sparsity уже неплохи, но не используют ценный ресурс современных GPU — тензорные ядра. Если запаковать окрестности вершин в тайлы 16×16, то можно воспользоваться ими и, даже выполняя некоторые лишние вычисления, выжать ускорение.
Кроме того, существующие либы почему-то не используют cuSPARSE — рабочий и мощный инструмент. Одно его накатывание + кастомные адаптации уже дает заметный профит.
📊 Эксперименты
Эффективность реализации проверяют на бенчмарке GraphLand — наборе задач с большим разнообразием структур и свойств графов.
Удается выжать медианное ускорение порядка 2× (вплоть до 8.5×) против DGL на GATv2, медианное ускорение 2.6× (вплоть до 10×) на операциях редукции. Операции разреженных сверток на cuSPARSE дают вплоть до 8× ускорения. Кроме того, пиковое потребление памяти оказывается обычно в разы меньше (а то и в десятки раз) по сравнению с DGL. PyG тоже в среднем ест меньше GPU VRAM, но при этом он куда медленнее.
В ablation показывают, что выигрыш от graph reordering и векторизованных загрузок зависит от графа. Для плотных графов с высокой степенью выигрыш значителен, для разреженных и малостепенных — мал.
В приложении много внимания уделено исследованию полезности блочной разреженности с тензорными ядрами — где накладные расходы на перестановки окупаются, а где нет.
💡 Выводы
Классная и полезная работа, дающая существенный толчок всей области GraphML. Хоть она и довольно нишевая и на любителя, тем не менее импакт более чем серьезный. Интересно, где еще есть низковисящие фрукты для оптимизации?
👍8🔥6❤4
7x size reduction for Gemma4 Edge models
📝 Блогпост
Команда из thestage.ai выпустила занятный блогпост про сжатие Gemma-4 в 6,4 раза с умеренной просадкой качества.
Работа примечательна тем, что комбинирует многие классические и свежие практики, чтобы выдать наилучший trade-off между размером модели и качеством.
📝 Блогпост
Команда из thestage.ai выпустила занятный блогпост про сжатие Gemma-4 в 6,4 раза с умеренной просадкой качества.
Работа примечательна тем, что комбинирует многие классические и свежие практики, чтобы выдать наилучший trade-off между размером модели и качеством.
🔥12
🛠 Метод
🎯 Авторы ставят своей целью эффективный инференс на edge-девайсах вроде мобилок. iOS накладывает жёсткие ограничения на размер памяти, используемой приложением, — ~3 гига, поэтому чекпоинт 4B-модели туда никак не влезет без оффлоадинга.
🏗 Архитектура модели включает в себя трансформерные блоки, PLE-эмбеддинги и объединённую LM-голову / эмбеддинги. Каждая из компонент требует своего рецепта.
⚙️ Для сжатия слоёв в трансформерных блоках используют GPTQ. Но не просто GPTQ, а усиленный Quantization Error Propagation (QEP) и тюнинг скейлов, минимизирующий квадратичную ошибку на выходе. Для калибровки подбирают датасет с примерами из разных областей — самокалибровочные генерации (генерации исходной модели по каким-то промптам), многошаговые диалоги, ризонинг / safety-данные.
📊 В ablation показывают, что QEP существенно снижает KL-дивергенцию между квантизованной и исходной моделью.
🗜 PLE — самая тяжеловесная часть модели, потому требует экстремального сжатия. Скалярные квантизаторы не жмут ниже одного бита, да и сильно сажают качество. Потому используют модифицированный вариант AQLM с 8-мерными группами и кодовой книгой размера 128 (7/8 бит на параметр?). Вместо X^T X используется регуляризованная матрица Фишера. В итоге удаётся добиться сильного сжатия с умеренным отклонением от исходной модели.
🧩 Эмбеддинг, он же голова, квантизуется через RTN с тюнингом скейлов.
🔧 Равномерное сжатие не учитывает разную важность и чувствительность слоёв, потому авторы используют RCO из недавней работы , который подбирает оптимальную битность под каждый слой из некоего набора пресетов через Риманову оптимизацию. Причём сначала подбирают оптимальные битности, а затем переквантовывают модель снова (чтобы калибровка учитывала степень сжатия прошлых слоёв). Оптимизированная конфигурация также выдаёт гораздо более близкие выходы к исходной модели.
🧪 Эксперименты
📉 По соотношению KL-дивергенция / размер выпущенные чекпоинты заметно лучше по Парето-фронту, чем публичные GGUF-ы.
📋 Далее качество замеряют на MMLU Pro, IFEval, tau2 bench.
🏆 L- и M-чекпоинты со степенью сжатия в 6–7 раз по качеству даже лучше GGUF-ов с 4x-сжатием.
🚀 По скорости оно даёт увеличение TPS в 2–2,5 раза против bf16-чекпоинта и снижает потребление памяти в 5–6 раз. 4-битная скалярная квантизация при этом даёт ускорение примерно в 1,5 раза (маловато чёт).
💡 Выводы
Классный гайд про подготовку низкобитных чекпоинтов под мобилки и комбинирование рецептов из литературы. Конечно, не под всякое железо оно заведётся, но где заведётся — пробовать точно стоит.
Следующим шагом было бы отскейлить сие на здоровые MoE-шки, чтобы запускать условный GLM-5.2 хотя бы на паре H100 или одной H200.
📦 Чекпоинты моделей выложены на лицехватс, и их можно запускать на яблочных чипах при помощи либы.
🎯 Авторы ставят своей целью эффективный инференс на edge-девайсах вроде мобилок. iOS накладывает жёсткие ограничения на размер памяти, используемой приложением, — ~3 гига, поэтому чекпоинт 4B-модели туда никак не влезет без оффлоадинга.
🏗 Архитектура модели включает в себя трансформерные блоки, PLE-эмбеддинги и объединённую LM-голову / эмбеддинги. Каждая из компонент требует своего рецепта.
⚙️ Для сжатия слоёв в трансформерных блоках используют GPTQ. Но не просто GPTQ, а усиленный Quantization Error Propagation (QEP) и тюнинг скейлов, минимизирующий квадратичную ошибку на выходе. Для калибровки подбирают датасет с примерами из разных областей — самокалибровочные генерации (генерации исходной модели по каким-то промптам), многошаговые диалоги, ризонинг / safety-данные.
📊 В ablation показывают, что QEP существенно снижает KL-дивергенцию между квантизованной и исходной моделью.
🗜 PLE — самая тяжеловесная часть модели, потому требует экстремального сжатия. Скалярные квантизаторы не жмут ниже одного бита, да и сильно сажают качество. Потому используют модифицированный вариант AQLM с 8-мерными группами и кодовой книгой размера 128 (7/8 бит на параметр?). Вместо X^T X используется регуляризованная матрица Фишера. В итоге удаётся добиться сильного сжатия с умеренным отклонением от исходной модели.
🧩 Эмбеддинг, он же голова, квантизуется через RTN с тюнингом скейлов.
🔧 Равномерное сжатие не учитывает разную важность и чувствительность слоёв, потому авторы используют RCO из недавней работы , который подбирает оптимальную битность под каждый слой из некоего набора пресетов через Риманову оптимизацию. Причём сначала подбирают оптимальные битности, а затем переквантовывают модель снова (чтобы калибровка учитывала степень сжатия прошлых слоёв). Оптимизированная конфигурация также выдаёт гораздо более близкие выходы к исходной модели.
🧪 Эксперименты
📉 По соотношению KL-дивергенция / размер выпущенные чекпоинты заметно лучше по Парето-фронту, чем публичные GGUF-ы.
📋 Далее качество замеряют на MMLU Pro, IFEval, tau2 bench.
🏆 L- и M-чекпоинты со степенью сжатия в 6–7 раз по качеству даже лучше GGUF-ов с 4x-сжатием.
🚀 По скорости оно даёт увеличение TPS в 2–2,5 раза против bf16-чекпоинта и снижает потребление памяти в 5–6 раз. 4-битная скалярная квантизация при этом даёт ускорение примерно в 1,5 раза (маловато чёт).
💡 Выводы
Классный гайд про подготовку низкобитных чекпоинтов под мобилки и комбинирование рецептов из литературы. Конечно, не под всякое железо оно заведётся, но где заведётся — пробовать точно стоит.
Следующим шагом было бы отскейлить сие на здоровые MoE-шки, чтобы запускать условный GLM-5.2 хотя бы на паре H100 или одной H200.
📦 Чекпоинты моделей выложены на лицехватс, и их можно запускать на яблочных чипах при помощи либы.
🔥12😱1