КПД (комментарии)

🛠 Метод Работа фокусируется на ускорении трех ключевых типов операций в 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 и векторизованных загрузок зависит от графа. Для плотных графов с высокой степенью выигрыш значителен, для разреженных и малостепенных — мал. В пр

🛠 Метод 🎯 Авторы ставят своей целью эффективный инференс на 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-ы.

🧪 Метод и эксперименты Авторы рассматривают следующие варианты квантизации: * 🔹 weight-only AWQ в 3 и 4 бита; * 🔹 weight-only GPTQ в 3 и 4 бита; * 🔹 weight + activation + KV-cache-квантизация в 4 и 8 бит при помощи FlatQuant. Качество оценивают на задачах по математике, общим научным вопросам (GPQA-Diamond) и кодингу (LiveCodeBench). В качестве моделей рассматривают дистиллы дипсика и QwQ (почему не Квен / Квен-3.5?). Менее агрессивные квантизации не так сильно меняют выход, но 3-битная квантизация весов и 4-битная квантизация весов + активаций заметно просаживают качество и одновременно увеличивают длину ризонинга. Причём длина ризонинга и качество имеют негативную корреляцию: чем длиннее ризонинг, тем хуже качество. Анализируя ответы, авторы замечают, что сильно повышается доля токенов — overthinking markers — вида “Wait”, “But”, “Alternatively” и т. п. Кроме того, они обычно соответствуют позициям, где KL-дивергенция между выходами исходной и квантизованной моделей велика. Для того чтобы побороть явление overthinking, предлагают занижать логиты, отвечающие за 50 вручную отобранных overthinking-токенов. В качестве бейзлайнов рассматривают случайные токены и токены с низкой / высокой KL-дивергенцией между сжатой и несжатой моделями. 📈 Занижение логитов отобранных токенов консистентно улучшает качество на 5–15%, при этом длина ризонинга сокращается на 10–20%. В основном прирост качества достигается как раз за счёт решения проблемы overthinking — доля таких ошибок снижается в два и более раза. Из альтернативных стратегий пенализация high-KL-токенов тоже работает неплохо, но хуже, чем пенализация вручную отобранных. Пенализация случайных токенов ничего не даёт, а low-KL-токенов только просаживает качество и удлиняет ризонинг. 💡 Гипотеза авторов о природе явления состоит в том, что токены с высокой энтропией имеют сильно размазанное распределение вероятностей, поэтому даже малый шум может привести к выбору другого токена — чаще всего как раз одного из overthi

🧪 Метод и эксперименты В данной работе фокусируются на 2-битном weight-only-сжатии ризонящих моделей. В аппендиксе есть эксперименты с FP4, со сжатием активаций и KV-кэшей. Квантизуют модели Qwen3-8B / Qwen3-32B через GPTQ. Оказывается, что квантизация сильно меняет поведение трейсов ризонинга: 🔄 Число циклов резко возрастает, особенно для меньшей модели. 📏 Многие трейсы не вписываются в заданный лимит токенов. ⚠️ Блок <think> часто оказывается незакрытым. 💡 При этом сам ответ появляется в среднем чуть ли не раньше в трейсе, но модель его не выводит. 📈 Длина ризонинга сильно увеличивается. Из этого следует, что, кроме просадки качества, мы ещё теряем в эффективности из-за того, что генерируем больше токенов. Как и в прошлой статье, замечают, что длина ризонинга у квантизованных моделей обратно коррелирует с качеством. Причина как раз в этих зацикливаниях. При этом результат сильно зависит от выбора задачи: на ризонинг-бенчмарках типа AIME / GPQA-Diamond эффект сильно заметен. На простых задачах — ARC-C, ARC-E, PIQA, WinoGrande — просадка и в 2 битах очень умеренная. Вообще, я думал, что эти бенчмарки likelihood-based и гоняются с выключенным <think>. Вводят четыре режима деградации качества: 🟢 Стабильный. Без заметной просадки. 🟡 Заметная, но умеренная просадка. Трейсы ещё не ломаются, но есть нарушения в плане фактологии и commonsense. 🟠 Значительная деградация. Генерация часто не завершается. 🔴 Полный коллапс. В первую категорию попадает Qwen3-32B на простых задачах. По мере усложнения задач и уменьшения размера модели растёт степень деградации. Дабы как-то подлечить просадку, предлагают два решения: 📝 (+P) FP16-модель пишет план, а квантизованная исполняет. Это заметно поднимает качество и правит многие ошибки ризонинга, но точность всё ещё ощутимо ниже базовой модели. 🔁 (+L) Loop Rescue. Если модель зацикливается, но выдаёт ответ, выписываем промежуточный ответ. Если ответа нет, просим FP16-модель сгенерировать его с нуля. Стратегии комплиментарны и