КПД

Метод ⚙️ Задачи на вход подаются в следующем формате: - 🧩 Системная инструкция - 📚 Контекст задачи, на основе которого надо дать ответ. Разбивается на чанки примерно одного и того же размера. - ❓ Вопрос - 🧭 Инструкция по использованию Declarative Attention (DA) Определяются 3 вида внимания, размечаемых специальными хэштегами: - 🌐 <global> — модель смотрит на весь контекст задачи. - 🎯 <focus> — модель смотрит только на нужный чанк контекста. - 📍 <local> — модель смотрит только на последние сгенерированные токены. Системная инструкция, вопрос и инструкция по использованию DA всегда есть в текущем общем контексте. Текст разбивается на чанки следующим образом: - ✂️ Стремимся побить все как можно ближе к 2048 токенам. При этом стараемся найти как можно более явный логический блок — раздел, абзац, предложение, по которому проводим разбиение. На крайняк просто пытаемся хотя бы не разделить слово пополам. - 🏷️ Сегменты размечаются хэштегами — начало/конец чанка. Хэштеги подбираются так, чтобы быть непохожими на секции в оригинальном тексте. Эффективный инференс реализован через vLLM с блочно-разреженной маской. Размеры чанков паддятся до 16/32, чтобы вписаться в ограничения по размерам. Эксперименты 🧪 Свой метод они валидируют на семействах Gemma-4, Qwen-3.5/3.6. Замеряют на задачах с длинным контекстом и обычно довольно коротким ответом: Needle-in-a-Haystack из RULER, задачи из LongBench-v1 / LongBench-v2. Для ablation рассматривают версию своего метода с тем же форматом промпта и сегментированием по чанкам, но без блочно-разреженной маски. На больших моделях просадки довольно небольшие — 1–3%, но все же статзначимые. Просадка обусловлена разреженностью, а не форматом промпта. Блочная разреженность дает ускорение, но как наши вставки влияют на длину ответа? Есть ли ускорение по конечному времени обработки запроса? ⏱️ Авторы замечают, что эти вставки и специфичный формат действительно заметно увеличивают в среднем число токенов в ответе. При этом с включенной маской число сгенерированных токенов растет не так сильно. Однако end-to-end все же оказывается, что можно добиться уменьшения времени ответа до 0.73–0.77 от исходного. Эффективность метода сильно зависит от размера модели. Мелкие модели (Gemma4-E4B и Qwen3.5-4B) плохо справляются с задачей. Им не удается вписаться и строго соблюдать специфичный формат разметки. С увеличением размера модели качество следования формату и умение находить нужный чанк из контекста растет. Далее замечают, что экономия токенов растет с длиной контекста, но становятся более ярко выраженными и просадки качества. Кроме того, на длинных контекстах модель дольше считает, что ей надо проводить время в `<global>`-режиме, что ограничивает достижимое ускорение. В среднем модель делает 1–2 попытки `<focus>`-контекста. Выводы 💭 Идея концептуально интересная и красивая. Однако область применимости ограничена. Авторы сами замечают, что их метод не работает с включенным ризонингом. В текущей постановке есть реальный профит, если контекст большой, а ответ короткий. Да и задачи в основном сводятся к иголкам в сене. На задачах по типу «много иголок» или со сложным образом распределенной информацией такой метод, скорее всего, не заведется. Кроме того, современные разреженные внимания, как в DeepSeek-V4.1-Flash и Qwen-3.8-Flash-Next, в процессе обучения, скорее всего, находят нужные паттерны, причем более надежно и эффективно, чем такая вот эвристика.

Language Models Can Control Their Own Attention 🧠 📄 Статья В современных LLM большинство слоев, смешивающих токены, представляют собой более дешевые (в сравнении с классическим attention) по длине последовательности GDN, SSM-ки или внимание со скользящим окном. Тем не менее, full attention-слои пока еще не полностью канули в Лету и все еще перетягивают на себя значительную часть объема вычислений на длинных последовательностях. Однако для предсказания следующего токена редко нужен весь прошлый контекст: внимая малому числу токенов, можно дать верный ответ. Но как найти это малое число токенов? Есть обучаемые селекторы, как в последних DeepSeek, MiniMax и Qwen. Но что, если сама LLM знает, что ей надо? 🤔 И авторы предлагают модели самой выбрать, куда смотреть (Declarative Attention), и при этом без специального обучения.

Мощное обновление DeepGEMM 👨‍💻 PR Добавляют: • Sparse Indexer из DeepSeek-V4.1-Flash • Mega Gate - слияние гейтов и GroupedGEMM (дает 30–75% ускорения против чего-то) • Mega mHC - слияние mHC и RMSNorm в единый кернел • Интеграцию с DeepJIT Оптимизировали: • Backward в GroupedGEMM на 20% • Mega MoE оптимизации под V4.1 Само обсуждение, как с участием кожаных мешков, так и ИИшки, на китайском, чтобы варвары ничего не поняли.

Когда гуманитарий шарит в теме)

🎭 Ещё следует отметить мультимодальную балансировку. Ибо обучаем сразу на данных как текстовой, так и картиночной/видео-природы — экспертов учат нужным образом балансировать активность. 🧪 Эксперименты Учат всё хозяйство на 45T токенов на претрейне. ViT-модуль сначала отдельно, а потом совместно. На RL-стадии используют как реальные собранные задачи и human feedback, так и синтетические, сгенерированные самой же моделью. Разные reasoning effort учатся с разными length penalty, убывающими экспоненциально от силы effort. Потом ещё гоняют On-Policy Distillation (OPD) поверх 40 учителей-специалистов на разных доменах. 📊 По метрикам DeepSeek-V4.1-Flash заметно опережает предшественницу, а также нередко оказывается лучше Pro-версии. На задачах по кодингу / агентским сценариям якобы тягается местами с Sol и Фаблой. Выводы Выдающаяся инженерная работа. Сложно сказать, всё ли это самим им пришло в голову или тут уже агенты многое додумали за них. Впечатляет фантастически малый размер KV-кэша — менее гигабайта на миллион токенов, что выглядит просто как сказка. Действительно ли этого объёма хватает на все практически интересные сценарии? Ну и модель реально быстрая.

🧩 Метод Наиболее примечательны архитектурные изменения, позволяющие выжимать максимум из ёмкости модели при минимальных накладных расходах на активные вычисления и KV-кэш. Каузальный энкодер-декодер Вместо привычной декодерной архитектуры используют энкодер-декодер а-ля трансформер из статьи Vaswani и T5. Однако мотивация за этим — экономить активные параметры на префилле, а также уменьшить размер KV-кэша. На префилле работает только энкодер, а декодер активизируется на генерации. Размеры энкодера и декодера примерно одинаковы. Декодер переиспользует кэш из энкодера, спроектированный через обучаемые линейные проекции, тем самым освобождаясь от необходимости держать собственный KV-кэш. В отличие от BERT и тому подобных архитектур, энкодер каузальный — внимание направлено только в прошлое, что делает его совместимым с авторегрессионной генерацией. Compressed Sparse Attention 2 В DeepSeek-V4 чередовались HCA (Heavily Compressed Attention) и CSA (Compressed Sparse Attention): одно сильно сжимало токены и делало полный аттеншен, а другое сжимало не так сильно и делало спарсный. Теперь аттеншен только один. ⚙️ Устроено оно так: поддерживается SWA (внимание со скользящим окном), которое внимает на последние токены, и иерархический sparse attention, который отбирает важные токены по всей последовательности с помощью обучаемой подсети, а потом компонуется со SWA. TopK считается на основе query/key-индексеров. Существуют три режима слоя: - 🔵 Full mode. Слой считает полный KV-кэш и сам определяет, какие токены ему нужны в спарсном attention. Самый гибкий, но дорогой случай. - 🟡 Reindex mode. Используем KV-кэш с другого слоя, но считаем свой TopK, используя специфичные для данного слоя query. - 🟢 Reuse mode. Переиспользуем как KV-кэш, так и TopK-индексы. В энкодере на 1 Full Mode приходится 5 Reuse. В декодере — только Reuse и Reindex. Reuse к Reindex — в отношении 3:1. Потому кэш нужно хранить по факту лишь в небольшой доле слоёв. Иерархический attention в данном слое оценивает все токены по важности, а также непрерывные блоки некоторой длины для оценки перспективных кандидатов будущими слоями. Full mode-слой отбирает перспективные блоки, а последующие Reindex mode-слои ищут TopK уже среди этого сильно порезанного пула кандидатов. Single-pass mHC Дабы немного повысить эффективность mHC, матрицу смешивания входов для текущего блока считают в прошлом блоке. Это позволяет лучше перекрывать передачу с вычислениями и почти не теряет в качестве. Engram 🧠 Дабы обогатить представления признаков условной памятью, накатывают Engram с 2-, 3- и 4-граммами. Наивно накатывать их выйдет слишком накладно — ни в какую память не влезет. Потому нужный эмбед достаётся через хэширование. Дабы уменьшить риск коллизий, используют восемь независимых хэш-таблиц. Размер каждой из них — примерно 16M токенов, но берут разные простые числа, чтобы головы были более независимы. В Engram-таблице 198B параметров, распределённых между двумя слоями. Такой распил таблицы нужен для эффективного pipeline parallelism, чтобы не было перекоса в конкретную часть модели. На выходы модуля энграмм навешивается гейт, который решает, надо ли и с какой силой добавлять информацию от Engram-эмбеддингов в данный токен. Хранится всё в FP8. DSpark Отдельные MTP-головы не учат, а вместо этого поверх предобученной модели тренируют драфтер. DSpark-драфт-модель обновляется в процессе посттрейна и используется для ускорения генерации роллаутов на RL. FP4 Cache 💾 Чтобы сэкономить на хранении KV-кэша, его квантизуют в FP4. За основу берут NVFP4, но без global scale. Вместо этого данные нормализуют так, чтобы они укладывались в целевой диапазон. Оптимизация Учат в основном через Muon. Для голов attention используется headwise Muon, который отдельно оптимизирует головы, потому что так лучше. Учить Engram через Adam накладно по памяти. Поэтому вместо этого предлагают Синкхорн-сбалансированные обновления параметров с моментом. Это позволяет не хранить тяжеловесные статистики Адама для Engram и вроде сходится хорошо.

DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression 📄 Техрепорт Ребята из Дипсика выкатили новую версию своей мультимодальной МоЕшки с сопутствующим техрепортом. И, как это любят и умеют делать только китайцы, нагородили всяческой инженерии по самое мама не балуй.

Design Docs Are All You Need: An AI-native Machine-Learning Performance Tool 📄 Статья Концептуально интересная мысль - железо и архитектуры меняются слишком быстро, патчить ML-либы под каждый новый сетап доволенно болезненно, разрастается всякое legacy. В то же время, агенты сильно удешевили разработку и на основе ТЗ неплохо варганят целостный репозиторий. Может быть так, что проще не разбираться в том что уже есть и адаптировать под новые реалии, а взять и написать ML-либу с нуля на основе некоего скелета. Авторы предлагают реализацию ML-либы в виде набора документов, образующих направленный ациклический граф (DAG), где расписывается структуру библиотеки, формат входов и выходов для отдельных операций. Более высокоуровневые операции можно делегировать моделям посильнее, нишевые куски - более дешевым. Все в итоге состоит из 50 файликов и 9000 строк спецификаций. Написание либы через Claude Code поверх их документации требует примерно 100 токенов на API и 1.5-3 часа работы агента. 💡 Выводы Сама либа из документов не выложена, нет примера реализации поверх документов агентов, бенчмарков, поэтому из статьи непонятно, насколько это хорошо работает. Но звучит прикольно.

[Блог] Мы сделали что-то очень крутое. Не скажем что, но оно очень крутое. Ставьте лайки и пишите комментарии.

Метод Сам метод донельзя прост: - 📝 Не сжимаем промпт. - 🎲 В каждом слое и голове случайно выбираем токены для выбрасывания. И все! Почему это работает? Увидим ниже. Эксперименты 🧪 Эксперименты гоняют на семействе Qwen3 / Phi-4 (новые модели сжимать не так интересно, у них гребаные GDN-ы и SWA). 📊 Замеряют на бенчах по математике / STEM — где промпт короткий, а генерация довольно длинная. 🔍 Сравниваются с SnapKV, R-KV, Vase, TriAttention. Первое, что замечают: на разных бюджетах ничто из эвристик явно не побеждает случайный выбор. А что-то прямо себя плохо показывает. Анализируя токены, которые были выбраны, замечают, что лучше всего себя показывает то, что сохраняет как можно больше промпта. Если явно наложить требование не прунить промпт, то некоторым методам становится заметно лучше. Почему так? Промпт подается однажды и важен на протяжении всей генерации. В ризонинге же модель часто повторяет одно и то же, потому там больше избыточности. Кроме того, если попрунить информацию о токене даже в одной голове, то она может сохраниться в другой. Потом проводят синтетический эксперимент со вставкой простого факта (число = тому-то) и делают его ретривал. По отдельности головы плохо предсказывают факт, но в совокупности, как оказывается, уже 2–3, а чем больше, тем лучше. Кроме того, оказывается, что каждой голове не нужно держать непрерывный факт: если он разбросан по головам, качество ретривала почти не меняется. Токены можно прунить не поодиночке, а группами по несколько токенов. Казалось бы, более грубый выбор должен отрицательно сказаться на точности, но до поры до времени, пока размер блока не доходит до 256, результат почти не меняется. Это говорит о том, что модели достаточно иметь довольно неполную информацию, как-то разнесенную по головам, чтобы все еще успешно решать задачу. Где эвристики оказываются важны — это в задаче доставания passkey: если факт указывается в начале и не повторяется в процессе. Тогда случайный прунинг и все бейзлайны, кроме R-KV, лажают. 🚀 По throughput при сервинге (1k токенов на вход, 32k токенов на выход) на H200 через vLLM они оказываются быстрее TriAttention на 30–40%. Ускорение за счет того, что скоринг не требуется. Выводы Довольно интересный результат про сжимаемость KV-кэшей: как будто attention-based и прочие эвристики все равно не угадывают ничего лучшего, чем случайный выбор. Да и про размазывание информации по головам тоже интересное наблюдение, было бы интересно связать это как-то с interpretability. Однако у подхода есть серьезное ограничение — он не очень полезен, если сам промпт длинный.

Random Attention: Rethinking KV Cache Eviction for Efficient Reasoning 📄 Статья С увеличением характерной длины контекстов в LLM все острее стал вставать вопрос о сжатии KV-кэша. Длинный KV-кэш занимает много места в памяти, а еще и замедляет инференс. Исследователи за последние несколько лет придумали много эвристик по прунингу / слиянию токенов разной степени безумия — одна якобы лучше другой. А тут вот ребята из Salesforce Research заметили, что рандомный прунинг работает, вообще говоря, не хуже всех этих хитроумных идей, а кроме того, предлагает более быстрый инференс ввиду отсутствия необходимости оценивать важность токенов.

Я разочарован Астрой. Дал, как мне казалось, сложную задачку, думал, полчаса попыхтит, я пока почитаю архив. А она, собака такая, за пару минут управилась.

Еще дедлайн подачи заявок не прошел, а чуваков уже приняли на ICLR 27. Респект! 📄 Статья

А могли бы Joseph Redmon нанять для рисования графиков)

Сам дисклеймер

# 🔄 Recirculation 📄 Статья: [https://arxiv.org/abs/2608.17981](https://arxiv.org/abs/2608.17981) Возможности трансформеров по обновлению скрытого состояния ограничены глубиной, и, дабы повысить выразительность, можно либо stack more layers, либо делать адаптивную глубину а-ля looped transformers, когда какие-то слои прогоняются по нескольку раз. В данной же работе исследователи из глубокого разума предложили добавлять с каким-то весом скрытое состояние с прошлого шага, с более глубокого слоя, в текущий шаг, дабы обогатить его знанием после глубокой обработки. ## 🧩 Метод Мотивация следующая. Омонимы пишутся одинаково, а могут иметь совершенно различный смысл в зависимости от контекста. Bank в английском — это банк и берег реки. В следующем примере из статьи по смыслу имеется в виду второе, но, увидев ATM, модель триггерится на первое и дает неверный ответ: > User: Fred took the day off work and pulled out his fishing pole. He drove > to the bank. When he reaches the bank, should he wear boots or flip flops? > > Model: While flip flops may be more comfortable for a casual day, they are > not the best choice for fishing, especially at a river bank. Here’s why: > ... > > User: Is it likely that Fred will find an ATM at this bank? > > Model: It is highly likely that Fred will find an ATM at the bank. Most > banks, especially those located near bodies of water popular for fishing, > have ATMs on-site for customer convenience. В более ранних работах показывали, что причина этого кроется, по всей видимости, в том, что эмбед нужного концепта проявляется в более глубоких слоях, а до этого есть неопределенность. Следующий токен аттендится на эмбед, где еще есть неопределенность, и может запутаться. Если подменить эмбед с текущего слоя на более поздний, то оказалось, что модель с большей вероятностью начинает верно разрешать такие ситуации. Однако, если такую интервенцию делать для всех токенов, это сломает модель, ибо она на это не училась. Потому авторы предлагают добавлять эмбед с прошлого токена более позднего слоя с каким-то небольшим весом, пробросив информацию и не сломав модель. Оптимальный выбор пары source/target слоев гридсерчат на некой калибровочной выборке и берут ту, где больше всего улучшается перплексия. Коэффициенты смешивания source/target слоев тоже перебирают по сетке. 🧪 Эксперименты Метод валидируют в основном на моделях семейства Gemma-3 (потому что там эффект наиболее выражен, ха-ха-ха) и самые удачные конфигурации дают улучшение перплексии до 5%. На Ministral / Qwen3 / Pythia / Phi2 эффект куда слабее — максимум 0,5% улучшения. В ablation показывают, что максимальное улучшение — если добавлять предыдущий токен; вставка более старых работает хуже. Основное улучшение перплексии идет за счет прилагательных и наречий. Потом тестируют метод на бенчмарке по контекстуализации, и recirculation дает значимый прирост против исходной модели. Правда, при увеличении числа дистракторов в Racing Thoughts эффективность метода будто ухудшается, и он сравнивается с базовой моделью. На бенчах с коротким ответом статзначимого улучшения метод не дает. На GSM8k якобы есть прирост от recirculation. Но базовое качество претрейна Gemma3-4B — 29,3%, с которым сравниваются, — не соответствует 38,4% из техрепорта, потому есть здесь вопросики. ⚠️ Ах да, и самое веселое: в текущей ревизии перед секцией 4 авторы написали большой дисклеймер про то, что замеры перплексии в Gemma3 сломаны из-за того, что был неправильно учтен BOS-токен. Из-за этого, по всей видимости, такое хорошее улучшение перплексии у Gemma3 вышло. ## 💡 Выводы Концептуально идея интересная, но насколько оно на реальных задачах работает из коробки и актуально ли для более современных моделей (обогащенных mHC / attention residuals), остается открытым. И методология / результаты экспериментов довольно спорные.

🔄 Recirculation 📄 Статья Возможности трансформеров по обновлению скрытого состояния ограничены глубиной, и, дабы повысить выразительность, можно либо stack more layers, либо делать адаптивную глубину а-ля looped transformers, когда какие-то слои прогоняются по нескольку раз. В данной же работе исследователи из глубокого разума 🧠 предложили добавлять с каким-то весом скрытое состояние с прошлого шага, с более глубокого слоя, в текущий шаг, дабы обогатить его знанием после глубокой обработки.

Слова не мальчика, а мужа. https://github.com/hao-ai-lab/flash-attention-fp4/issues/1