КПД
Open in Telegram
Квантование & Прунинг & Дистилляция Блог про сжатие сетей и не только. От древнейших времен по настоящее время.
Show more3 315
Subscribers
+324 hours
+57 days
+6430 days
Data loading in progress...
Similar Channels
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
July '26
July '26
+20
in 2 channels
June '26
+115
in 1 channels
Get PRO
May '26
+109
in 4 channels
Get PRO
April '26
+122
in 2 channels
Get PRO
March '26
+144
in 2 channels
Get PRO
February '26
+83
in 0 channels
Get PRO
January '26
+105
in 5 channels
Get PRO
December '25
+67
in 1 channels
Get PRO
November '25
+224
in 11 channels
Get PRO
October '25
+57
in 2 channels
Get PRO
September '25
+158
in 4 channels
Get PRO
August '25
+105
in 5 channels
Get PRO
July '25
+59
in 0 channels
Get PRO
June '25
+125
in 3 channels
Get PRO
May '25
+67
in 1 channels
Get PRO
April '25
+105
in 3 channels
Get PRO
March '25
+118
in 5 channels
Get PRO
February '25
+276
in 3 channels
Get PRO
January '25
+77
in 2 channels
Get PRO
December '24
+229
in 7 channels
Get PRO
November '24
+138
in 3 channels
Get PRO
October '24
+165
in 4 channels
Get PRO
September '24
+137
in 2 channels
Get PRO
August '24
+69
in 4 channels
Get PRO
July '24
+135
in 5 channels
Get PRO
June '24
+61
in 3 channels
Get PRO
May '24
+268
in 5 channels
Get PRO
April '24
+105
in 2 channels
Get PRO
March '24
+94
in 2 channels
Get PRO
February '24
+119
in 4 channels
Get PRO
January '24
+327
in 6 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 08 July | +6 | |||
| 07 July | +4 | |||
| 06 July | 0 | |||
| 05 July | +1 | |||
| 04 July | +2 | |||
| 03 July | +2 | |||
| 02 July | +2 | |||
| 01 July | +3 |
Channel Posts
🛠 Метод
🎯 Авторы ставят своей целью эффективный инференс на 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 из недавней работы https://arxiv.org/abs/2605.00649, который подбирает оптимальную битность под каждый слой из некоего набора пресетов через Риманову оптимизацию. Причём сначала подбирают оптимальные битности, а затем переквантовывают модель снова (чтобы калибровка учитывала степень сжатия прошлых слоёв). Оптимизированная конфигурация также выдаёт гораздо более близкие выходы к исходной модели.
🧪 Эксперименты
📉 По соотношению 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.
📦 Чекпоинты моделей выложены на лицехватс, и их можно запускать на яблочных чипах при помощи либы https://github.com/TheStageAI/edge-lm.
| 2 | 7x size reduction for Gemma4 Edge models
📝 Блогпост
Команда из Stage.AI выпустила занятный блогпост про сжатие Gemma-4 в 6,4 раза с умеренной просадкой качества.
Работа примечательна тем, что комбинирует многие классические и свежие практики, чтобы выдать наилучший trade-off между размером модели и качеством. | 1 634 |
| 3 | 🛠 Метод
Работа фокусируется на ускорении трех ключевых типов операций в 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. Хоть она и довольно нишевая и на любителя, тем не менее импакт более чем серьезный. Интересно, где еще есть низковисящие фрукты для оптимизации? | 726 |
| 4 | On Efficient Scaling of GNNs via IO-Aware Layers Implementations
📄 Статья
💻 Код
Засветилось уже много где в русскоязычных тг-каналах про ML, но оно заслуживает отдельного разбора.
Графовые нейронные сети имеют ряд небесполезных приложений — всякий там дизайн новых молекул, физика, анализ транзакций и социальных сетей.
Однако их оптимизации уделялось сравнительно мало внимания по сравнению с LLM, потому существующие реализации в популярных фреймворках (DGL, PyG) далеки от оптимального потребления памяти и вычислительных ресурсов.
Существенной сложностью при работе с графами являются нерегулярная/разреженная структура данных и нерегулярные паттерны доступа. И в работе наших соотечественников (Spotlight на ICML, между прочим) сделали куда более эффективную реализацию стандартных графовых операций. | 757 |
| 5 | Оооо дооодоо ДипСик выпустил новую крутую модель дооодоо, короче все уже написали про DSpark в том числе канал «Islam Insights» и «AI Beauty» ну куда мне с такими игроками тягаться, ладно и я напишу, потому что как минимум пишу его реализацию в vllm
Архитектура - спиздили, взяли бекбон Dflash добавили калибровку логитов сверху Марков 🎩(FlexDraft, Domino) и ещё реализовали Конфиденс 🎩 (SpecDec+), чтобы ну давать некую уверенность в токене. Зачем это нужно? Важно? ну вот зачем? Чтобы потом было удобно делать динамический драфт о чем писал выше
Бля просто обидно за дифлеш пиздец про него писали буквально я и боты в тг, ну и вот он только только начал быть виральным (я к нему даже мультимодалку прикрутил) и Опа Дспарк дооо доо, вот реально обидно как за братишку с вуза которого на работу не берут, а потом чел с 0 опыта идёт тимлидить написание промптов в сбере, выступает на датафесте и лутает 1к в тгк, бля вот хотите быть реально нишевыми юзайте дфлэш либо лукахед, а вот это вот хуйня для зумеров сидеть у помойки есть оверхайп бейглы
Вот вам инсайт на подумать: оригинальный дфлеш жмёт 5/7 токенов, дспарк 6/7, но если убрать рекурсию сверху то 1.5/7, и этого мы добивались? Бек ту зе рутс? А может Редрафтер от эппла? Игл? Типа сверху неиронично цикл лупанули и сидят довольные, а может цикл в цикле? Вы собесы Яндекса вообще проходили?
Нет бы реализовать динамический драфтинг нормально в граф моде сидят хуйней страдают - немощь блин | 1 337 |
| 6 | 🔧 Метод
Параллельный драфтинг хорош тем, что он действительно параллелен, но не учитывает последовательную зависимость между токенами. А авторегрессионную модель нужно гонять каждый раз для каждого токена.
Отсюда предлагают гибридное решение — такую же параллельную тушку, как в 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 не так много ручек, которые нужно крутить, чтобы выжать максимальный перф. | 1 230 |
| 7 | DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation
📄 Статья
💻 Код (DeepSpec)
С начала текущего года вышел ряд работ (DFlash и follow-up research), предлагающих различные варианты параллельного драфтинга, когда драфт-модель предсказывает несколько токенов за один раз. Такие подходы позволяют использовать более сильную модель в качестве черновой и могут выдавать acceptance на уровне или даже лучше, чем SOTA AR-методы спекдека. Но будто бы потенциал для дальнейшего улучшения все еще есть.
Ребята из DeepSeek проделали кропотливую инженерную работу, внесли определенные архитектурные изменения, а заодно предложили динамически подбирать длину драфта, чтобы оптимизировать производительность под разные типы запросов и текущую нагрузку. | 1 214 |
| 8 | 🔧 Метод
Параллельный драфтинг хорош тем, что он действительно параллелен, но не учитывает последовательную зависимость между токенами. А авторегрессионную модель нужно гонять каждый раз для каждого токена.
Отсюда предлагают гибридное решение — такую же параллельную тушку, как в 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% по сравнению с DFlash).
Далее авторы исследуют 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 не так много ручек, которые нужно крутить, чтобы выжать максимальный перф. | 1 |
| 9 | 🔬 Метод
Авторы замечают, что обновления весов в радиальном и угловом направлениях не являются независимыми. Для оптимизаторов типа Адама/Мюона величина шага не зависит от нормы весов, поэтому изменение угла обратно пропорционально норме весов. Аналогично, при движении вдоль касательной (по радиальному градиенту) растет норма весов. И чтобы она не улетела в космос, приходится накладывать 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% у Мюона).
💡 Выводы
Выглядит как многообещающий и интересный результат. Интересно, насколько скоро данная техника будет внедрена в обучение больших моделей и станет ли она такой же стандартной практикой, как Мюон. | 1 450 |
| 10 | Improving Neural Network Training by Decoupling the Magnitude and Direction of Weight Vectors
📄 [Статья]
💻 [Кода нет]
Обыкновенно оптимизаторы, будь то Адам, Мюон или любой другой, оптимизируют матрицы весов как единое целое. Однако бывает полезно разделить радиальную динамику (изменение величины весов) и угловую.
И в данной работе авторы предлагают факторизовать вес как произведение компоненты единичной нормы (лежащей на сфере) и обучаемых масштабов (gains), что в итоге дает ускорение сходимости по сравнению с базовыми оптимизаторами. | 1 220 |
| 11 | Когда просят реализовать какую-то фичу | 1 299 |
| 12 | 🔬 Метод
Разобьем последовательность на префикс 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 сравнений по скорости. | 1 284 |
| 13 | MAC-Attention: a Match-Amend-Complete Scheme for Fast and Accurate Attention Computation
📄 [Статья]
💻 [Код]
В стандартной реализации для каждой новой query мы проходимся по всем посчитанным ранее парам ключей и значений и считаем результат.
Но можно ли как-то переиспользовать прошлые вычисления?
И работа, рассматриваемая ниже, предлагает интересный подход по переиспользованию вычислений для похожих query. | 1 084 |
| 14 | 🔬 Метод и эксперименты
📚 В качестве бенчей берут стандартную выборку задач на математику (AIME, LiveMath), программирование, знания (MMLU-Pro) и агентские бенчи (GAIA, CyBench).
🤖 Сравнивают Claude, GPT, Gemini, Kimi и Minimax.
💰 Замечают, что конечная стоимость включает в себя обработку промпта, генерацию, а также кэширование.
📈 Причина обнаруженного явления довольно проста — более слабые модели часто генерируют больше токенов. Особенно заметен эффект на MMLU-Pro, где крупные фронтирные модели выдают ответ почти сразу, а маленькие запускают цепочки рассуждений на десятки тысяч токенов.
⚡ На ArenaHard явление выражено слабее всего.
🧠 Вероятность price reversal (ожидаемо) зависит от сложности задачи. Простые задачи даже слабые модели решают быстро, а с ростом сложности «малютки» закапываются в многошаговые рассуждения и совершают много лишних действий.
📌 Выводы
Мораль такова: не всегда более дешёвая по API модель оказывается дешевле в итоге, даже если корректно решает задачу.
Впрочем, рекомендация давать простые задачи более слабым моделям, а более сложные — сильным, очевидна и без этой работы. Вопрос лишь в том, как нащупать эту грань. | 1 197 |
| 15 | The Price Reversal Phenomenon: When Cheaper Reasoning Models Cost More
📄 [Статья]
💻 [Кода нет]
Интуитивно более дешёвые по цене за миллион токенов модели должны обходиться дешевле при решении задач.
Но так ли это на самом деле?
Авторы оценили стоимость замеров на выборке из стандартных бенчей, и оказалось, что нередко (в 32% случаев) более «дешёвые» модели в итоге выходят дороже. В частности, Gemini 3 Flash на 80% дешевле на токен, чем GPT-5.4, но замеры с ней обходятся на 38% дороже. | 1 132 |
| 16 | 🔬 Метод
Анализ сначала проводят на dense-трансформере против nanoGPT-бейзлайна.
В качестве меры точности рассматривают SNR (signal-to-noise ratio). Как нетрудно догадаться, это отношение сигнала к шуму, и чем оно выше, тем точнее приближение.
📊 Замечают следующее: если по отдельности отслеживать ошибку квантизации весов W и активаций X в ненормализованном и нормализованном случае, то особой разницы нет. Но если рассматривать уже скалярное произведение WX, то для nGPT ошибка на 7 дБ меньше.
❓ Возникает вопрос: почему?
Авторы рассматривают числитель (сигнал) и знаменатель (шум) по отдельности. Для GPT и nGPT шум примерно одинаков, но сигнал у nGPT заметно выше. Авторы предполагают, что данный эффект вызван тем, что без нормализации для получения большого скалярного произведения достаточно иметь большой вес или активацию на данной позиции. Для nGPT же необходимы сильные корреляции между параметрами.
📈 Далее авторы строят корреляции скалярных произведений (WX) и обнаруживают, что у nGPT они действительно больше.
Кроме того, оказывается, что отношение SNR масштабируется с размерностью: чем жирнее модель, тем больше выигрыш. На типичных размерах современных моделей (hidden_dim ~ 1k–10k) отношение SNR порядка 4–6, а в пределе бесконечной размерности уходит в 14.2.
🛡️ Также проверяют прирост валидационного лосса при наложении гауссова шума, и у nGPT этот прирост в 3.5 раза меньше, чем у GPT.
🧪 Эксперименты
Сначала обучают плотные GPT/nGPT на 1.2B параметров с AdamW на 1T токенах. Сама nGPT немного лучше GPT, и просадка качества при переходе к NVFP4 у nGPT тоже заметно меньше, чем у GPT. GPT-бейзлайн использует Адамаровы вращения и per-tensor scaling.
Затем обучают маленькую MoE Mamba-hybrid модель и модель побольше. nGPT немного плохеет на первых итерациях, но затем по лоссу почти сравнивается с бейзлайном.
⚙️ Еще из приятного: learning rate для nGPT хорошо переносится с bf16-модели на NVFP4, а для GPT требуется отдельно тюнить его (ставить в 16 раз больше). Кроме того, модель устойчивее к выбору самого значения learning rate: в достаточно широком диапазоне качество не сильно страдает при уходе от оптимума.
📝 Выводы
Претрейн с нормализацией весов выглядит достаточно привлекательной идеей и несложен в реализации. Вопрос в том, насколько велик потенциальный оверхед при обучении от нормализаций. Также нет сравнения с Quartet II (полагаю, что бейзлайновый рецепт слабее). | 1 140 |
| 17 | Normalized Architectures are Natively 4-Bit
📄 [Статья]
💻 [Код]
Наличие выбросов в весах и активациях является характерной сложностью при квантизации LLM. Отсюда возникает вопрос: а можно ли избавиться от них на уровне самой архитектуры, и как это взаимодействует с квантизацией?
Пару лет назад вышла статья nGPT, где веса и активации лежат на гиперсфере, и предложенная модификация позволила добиться более быстрой сходимости.
Но как это взаимодействует с квантизацией, и в частности с обучением в низкой точности? В рассматриваемой работе авторы провели теоретический и эмпирический анализ, показывающий, что можно стабильно обучать модели в NVFP4 без необходимости применения специальных техник, как в Quartet II. | 1 187 |
| 18 | 🔬 Метод
За основу берётся фреймворк flow matching со стохастическим интерполянтом на непрерывных данных.
Однако вместо стандартного v-prediction предлагают перейти к x-prediction, мотивируя это аналогично работе JiT из картиночного мира: мол, оно лежит на многообразии, а скорость — нет.
Потом они получают лемму о том, что оптимальный денойзер есть потокенное апостериорное распределение, откуда следует, что оптимальный денойзер есть минимум кросс-энтропии (т.е. получают совпадение оптимизации диффузионного лосса и правдоподобия).
Далее в статье вводят формулировку Flow Map — отображения, которое переводит из заданной точки в любую другую. Целевое отображение параметризуют в виде two-time денойзера, обладающего следующими свойствами:
🔹 Выход денойзера лежит на вероятностном симплексе.
🔹 Если оба времени совпадают, получаем обычный денойзер для x0-prediction.
🔹 Полугрупповое свойство: попасть в точку t из s — то же самое, что из s в u посередине, а затем из u в t.
Авторы показывают, что подобная формулировка для дискретной диффузии нереализуема.
⚠️ Ещё из важных аспектов следует отметить следующее
🔸 Равномерные шаги сэмплирования работают плохо. Авторы замеряют decoding error rate (долю неправильно предсказанных токенов) в зависимости от времени и замечают, что она держится в районе 1 (всегда ошибаемся) большую часть траектории, а в конце резко падает в 0. Поэтому шаги подбираются так, чтобы равномерно улучшать данную метрику. То есть шаги сконцентрированы в районе переходной зоны.
🔸 В отличие от дискретной диффузии, на непрерывную легко переносятся известные техники гайденса. Автогайденс с плохой моделью или гайденс на некоторый реворд.
📊 Эксперименты
Обучают модель на 179M параметров на LM1B и OpenWebText. Сравнивают с RDLM, CANDI, MDLM, Duo.
На большом числе шагов сэмплирования FLM (без дистилляции) достигает более низкой перплексии, чем конкурентные подходы. Но при малом числе шагов уступает Duo. Энтропия примерно у всех подходов на одном уровне.
А если сравнивать дистиллированную версию FMLM, то на малом числе шагов (1–8) она оказывается заметно лучше конкурентов.
Затем сравнивают guidance. MDLM и Duo, начиная с какого-то момента (силы guidance), разваливаются, и перплексия уходит в стратосферу. У FLM перплексия только убывает с ростом гайденса, но энтропия тоже убывает.
🎯 Гайденс на реворд улучшает целевую метрику.
Затем проводят ablation метода:
🔹 x0-prediction гораздо лучше, чем v-prediction.
🔹 CE loss с softmax на логитах даёт лучший результат.
🔹 Диффузия в евклидовом пространстве лучше различных римановых и симплексных вариантов.
Для FMLM:
🔹 two-time параметризация оптимальна.
🔹 Лучше стартовать с предобученной диффузии, а не с нуля.
🔹 Полугрупповой дистилляционный objective лучше, чем эйлеров или лагранжев (что есть что прекрасно разобрано у Sander Dieleman: https://sander.ai/2026/05/06/flow-maps.html).
📝 Выводы
Небезынтересный подход с неплохой теоретической подоплёкой. Но, как и везде, встаёт вопрос масштабирования и обобщаемости. | 1 192 |
| 19 | Flow Map Language Models: One-step Language Modeling via Continuous Denoising
📄 [Статья]
💻 [Код]
Статья старше ELF и LDLM, тем не менее интересна с точки зрения самого подхода и теоретических результатов.
На текущий момент в текстовой диффузии преобладают дискретные подходы, итеративно расшумляющие токены в связный текст. Однако при таком подходе распределение токенов всё равно получается факторизованным, и нет возможности итеративно обновлять состояние уже предсказанных токенов.
В непрерывной диффузии этого можно добиться, но на практике она обычно уступает дискретной. И в этой работе предложили подход к генерации текста, основанный на непрерывных потоках, к которому ещё прикрутили flow map-дистилляцию, позволяющую получать адекватное качество на малом числе шагов сэмплирования. | 1 061 |
| 20 | Как мне кажется, есть некоторая несправедливость в том, что на разные инкрементальные улучшения авторегрессии (yet another sparse attention, новые residual connections, gating в аттеншене) и их ablation находится ресурс на обучение более-менее практически релевантной постановке (модели размером 10B-100B параметров на бюджетах порядка триллиона токенов), а куда концептуально более интересные работы по текстовой диффузии в основном обучаются в игрушечной постановке а-ля ~100M модель на нескольких миллиардах токенов.
Впрочем, возможно, лучше синица в руке, чем журавль в небе... | 1 302 |
