Ускорение E2E-инференса через оптимизацию KV-кэша. Часть II

В первой части разбора мы говорили о методах оптимизации KV-кэша в принципе. А сегодня речь пойдёт об одном конкретном подходе — ShadowKV.

В его основе наблюдение, что post-RoPE key cache обладает attention locality — соседние токены часто имеют высокую cosine similarity, и только небольшая часть токенов выбивается из этого паттерна. Поэтому их режут на чанки по 8 токенов и строят landmarks — репрезентативные средние ключи для чанка. Это значительно ускоряет этап выбора ключей на шаге декодирования, а также улучшает доступ к памяти и позволяет лучше насыщать шину.

Ключевой момент в том, что лучше всего сжимается именно pre-RoPE K: он хорошо раскладывается в низкий ранг с минимальной ошибкой, заметно лучше, чем V. Поэтому ShadowKV делает так: pre-RoPE K сжимается через SVD, а V не сжимается, а уезжает в CPU (RAM), чтобы экономить GPU память и bandwidth.

При этом небольшое число токенов, которые плохо объясняются landmark’ами, выделяются как outliers (выбросы) и сохраняются полнорангово. В статье отмечают, что значимая доля outliers — это sink tokens. Достаточно порядка 0,049% бюджета на выбросы, чтобы попасть в точку diminishing returns: это минимальное количество outliers, которое почти полностью закрывает деградацию качества, а дальнейшее увеличение бюджета даёт лишь пренебрежимо малый дополнительный вклад.

На этапе prefill пайплайн строится так: параллельно с основным префиллом быстро вычисляются landmarks и outliers, и это вычисление перекрывается с отгрузкой V на CPU. В результате дополнительные шаги минимально увеличивают critical path, потому что большая часть работы делается в overlap-режиме.

Q на decode скорится не по всем токенам, а по landmarks каждого чанка. Затем выбираются лучшие чанки, и уже все токены из выбранных чанков отправляются в kernel attention. Для этого K восстанавливаются обратно из low-rank пространства, а соответствующие V подгружаются из CPU.

Дополнительно используется оптимизация в духе branch prediction или speculative-подходов. Между двумя соседними шагами декодирования выбранный набор токенов обычно меняется незначительно, потому что запросы на соседних шагах похожи. Поэтому можно кэшировать уже подгруженные токены для каждого слоя и на следующем шаге считать разность множеств, догружая только те токены, которых ещё нет в рабочем наборе. Эта оптимизация lossless относительно ShadowKV, потому что сохраняется инвариант: на каждом шаге в аттеншн всё равно попадает актуальный набор токенов — просто часть из них переиспользуется без повторной загрузки.

На бенчмарках деградация остаётся минимальной при бюджете около 1,56% от полного объёма KV. При этом в практических сценариях ShadowKV обеспечивает заметный прирост скорости и позволяет поддерживать существенно больший размер батча — за счёт снижения нагрузки на VRAM и уменьшения стоимости аттеншн на длинных контекстах.

Отдельно важно понимать, почему вообще имеет смысл оптимизировать именно аттеншн. Его вычислительная стоимость растёт с длиной последовательности, и на длинных контекстах он начинает доминировать по времени, тогда как FFN от длины контекста почти не зависит. Поэтому на коротких последовательностях в профиле часто доминирует FFN, и ускорение аттеншена даёт небольшой выигрыш.

Зато на длинных контекстах бутылочным горлышком становится аттеншн, и тогда по закону Амдала даже частичное ускорение этой части даёт заметную экономию общего E2E-времени инференса.

Разбор подготовил❣ Владислав Кругликов

Душный NLP

Превращаем decoder-only в encoder-decoder

Несмотря на то, что decoder-only-модели сейчас популярнее, encoder-decoder-модели по-прежнему остаются актуальными в некоторых задачах. В сегодняшней статье — техника адаптации предобученных decoder-only-моделей в encoder-decoder с сохранением преимуществ обоих подходов.

Суть метода: берут предобученную decoder-only и из её весов собирают encoder-decoder. В энкодере self-attention и FFN инициализируются из соответствующих self-attention и FFN исходной модели, но сам self-attention переключают с causal на двунаправленный. В декодере self-attention (он остаётся causal) и FFN тоже берутся из decoder-only (изображение 1).

Новая часть — cross-attention: если энкодер и декодер получены из одного и того же decoder-only-чекпойнта (с одинаковой конфигурацией и весами), то cross-attention инициализируют из SA. В противном случае инициализируется рандомно с дополнительным обучением в начале.

Далее авторы используют два варианта претрейн-обджектива encoder-decoder-моделей — PrefixLM и UL2 — и сравнивают их. Первый предполагает разбивку последовательностей на две равные части: первую половину текста подают в энкодер как префикс, а вторую должен генерировать декодер. Такой подход облегчает имплементацию дистилляции, где исходная decoder-only выступает «учителем». В рамках UL2 модель решает denoising-задачи: часть токенов заменяется на пропуски; в энкодер подаётся текст с пропущенными токенами, а в декодер — сами пропущенные токены. Дистилляция здесь не используется.

Авторы отмечают, что PrefixLM даёт лучшие результаты за счёт дистилляции, но у UL2-моделей оказались лучшие энкодер-представления. В целом, как показывают эксперименты, модели, полученные с помощью адаптации показывают лучшее качество, чем обученные с нуля.

Всё проверяли на Gemma 2 на 2B и 9B параметров. Сбалансированная адаптация — 2B-2B и 9B-9B — выходят на сопоставимое с decoder-only-моделями качество довольно быстро. 9B-2B растёт медленнее из-за нового cross-attention (результаты для итоговых моделей — на изображении 2).

Разбор подготовил ❣ Антон Викторов

Душный NLP

Как заставить агентов делать работу над ошибками

Сегодня разбираем статью об обучении агентов. Проблема такая: реворд-модели оценивают только результат в конце траектории, а если агент сделал ошибку и исправил её, нельзя сказать, когда это произошло. Если бы у нас была такая возможность, то мы могли бы раньше направить обучаемую LLM по нужному пути. Есть способы фиксировать ошибки и делать реворд по шагам, но это дорого и сложно в реализации.

Авторы предлагают метод Agent-R, суть которого заключается в обучении агентов не на правильных траекториях, а на тех, где есть явная ошибка и её исправление. Такие траектории получаются через Monte Carlo Tree Search. Берутся пары из одной стартовой точки (инструкции): одна траектория успешная, а другая — нет. На инференсе момент расхождения должна определить сама модель, а при обучении к началу провальной траектории добавляется фраза-рефлексия, которую генерирует агент, понимая, что он ошибся (CoT). Следом «приклеивается» хвост удачной траектории и на всём этом делают SFT. Такой подход, соединеняющий рефлексии и «хороший» хвост, снижает риск склейки не связанных траекторий.

В статье выводят следующие типы траекторий:

Initial Trajectory — общий начальный префикс.
Bad Trajectory — субоптимальные действия c низкой наградой.
Good Trajectory — оптимальные действия с высокой наградой.
Revision Trajectory — траектория, в которой агент совершил ошибку и исправил её.

Для получения Revision Trajectory можно брать плохие траектории, дожидаться их финала и переписывать. Однако так не получится обучить агента ловить ошибки на лету. Вместо этого авторы заставляют модель самостоятельно анализировать траектории и пытаться определить первый шаг, где совершена ошибка. На этом месте траектория обрезается, вставляется этап рефлексии и следом — правильная траектория.

Monte Carlo Tree Search позволяет собрать много разных траекторий с одним началом. Это удобно, так как можно сравнивать хорошие и плохие продолжения. Финальный реворд используется не для обучения напрямую, а для классификации траекторий по качеству — то есть, по сути, чтобы понять, что пойдёт в SFT-датасет. У реворда есть два порога: один отделяет плохие траектории от хороших, а другой выбирает уже из хороших лучшие.

Авторы отмечают, что обучаться только на Revision Trajectory нельзя — это мешает агенту определять правильные траектории. Поэтому изначально в датасет добавляют много Good Trajectory и постепенно в процессе SFT повышают порог реворда оптимальных решений, чтобы в конце оставались только лучшие из них. Кроме того, в датасет подмешивают обычные языковые данные, что помогает агенту не забывать, чему он обучался ранее.

Эксперименты проводили на Llama-3.1-8B, которую обучили на собранных Revision Trajectory. Результаты можно посмотреть в таблице, приложенной к посту. Авторы заявляют, что исправленные траектории оказываются даже лучше идеальных.

Разбор подготовила ❣ Карина Романова

Подписывайтесь на канал Карины «что-то на DL-ском» — там познавательно и можно ставить реакт кота в парике.

Душный NLP

Рекурсивные языковые модели

В последнее время всё чаще обсуждают проблему длинного контекста. Большое количество токенов просто физически не помещается в модели, а с увеличением контекста зачастую падает качество. Авторы сегодняшней статьи предлагают решение: дать моделям правильные инструменты.

Как это устроено: у модели есть промпт с описанием задачи и доступных тулов. Первый — это Python REPL. Модель может исполнить произвольный код, где в переменной prompt сохранён весь длинный промпт.

Второй тул — это вызов языковой модели на глубине 1 (depth=1) с поданным фрагментом длинного промпта. Это напоминает субагентов в агентах для написания кода (Claude Code, Codex), но есть важное отличие. Вызов llm_query живёт «внутри» REPL, а значит модель может встроить его в цикл, условие или любую другую программную конструкцию. В Claude Code или Codex субагент — это отдельный тул-колл, который модель вызывает из контекста напрямую, без программного контроля. Такая модель называется рекурсивной (RLM), и их может быть несколько в рамках одного цикла. RLM не обязательно должна быть идентична изначальной. Главное, что у неё пустой контекст.

Суть метода, предложенного авторами статьи, в том, чтобы дать модели возможность запускать себя рекурсивно в той же программной среде (изображение 1). Среди бейзлайнов авторы рассматривают вариант без самовызовов (только модель с большим промптом и REPL), summary agent (суммаризация контекста, не поместившегося в модель) и CodeAct (код плюс ретривал через BM25).

Нюансы разницы RLM и типичных кодовых агентов до сих пор вызывают дискуссии с авторами в твиттере, и хайп вокруг статьи и идеи только растёт. Примеры тут, тут и тут.

Эксперименты проводили на Qwen3 и GPT-5 (изображение 2). На бенчмарке BrowseComp+ (контекст 6–11 миллиона токенов, нужно найти один релевантный документ из тысячи и ответить на вопрос) базовые модели невозможно запустить — контекст просто не влезает. RLM здесь работает.

Но поиск по длинному контексту — не единственная задача, которую решают RLM. Бенчмарк OOLONG требует семантической обработки фрагментов текста и их агрегации. Сложность линейная относительно длины входа. Здесь RLM без самовызовов уступает даже базовой модели, потому что задача требует «видеть» весь контекст. RLM с самовызовами заметно выигрывает у всех бейзлайнов.

Самый показательный результат на OOLONG-Pairs. Здесь нужно сравнивать пары фрагментов, то есть сложность задачи квадратичная. Базовая модель и summary agent выдают результат около нуля. RLM с самовызовами решает эту задачу, программно организуя квадратичное число вызовов через код в REPL. Это класс задач, недоступный другим подходам.

По стоимости RLM с самовызовами зачастую сопоставима с базовой моделью, хотя со сложностью задачи стоимость растёт (изображение 3).

Разбор подготовил ❣ Иван Рубачёв

Душный NLP

Mercury — диффузионная модель для написания кода

Сегодня разберём статью о диффузионной модели Mercury. На Copilot Arena она занимала второе место по качеству и первое — по скорости.

Диффузионные модели уже зарекомендовали себя в сфере генерации изображений. Авторы сегодняшней работы, в свою очередь, предлагают модель, ориентированную на решение задач программирования. Это объяснимо: диффузионные модели не очень хорошо подходят для генерации свободных коротких текстов, а код структурирован, в нём как правило много токенов.

Существует две версии Mercury Coder — Mini и Small. Подробности о них в публикации не раскрываются: мы не знаем их параметры и размеры. Заявлено, что Mini способна обрабатывать более 1100 токенов в секунду, а Small — 700. На претрейне использовали датасет объёмом в триллионы токенов, состоящий из интернет-данных, а также реальных и синтетических данных из проприетарных источников.

Что касается архитектуры, то, по сути — это трасформер, но с иным подходом к генерации. Модель стартует с зашумлённой версии ответа и на каждом шаге параллельно поправляет много позиций, постепенно «денойзя» последовательность. Длинны контекста модели — 32 тысячи токенов с расширением до 128 тысяч.

В большинстве бенчмарков Mercury Coder показывает себя лучше опенсорсных моделей, но уступает самым крупным и известным конкурентам вроде DeepSeek, GPT и Claude (таблица 1). То же самое касается и знания разных языков программирования — Mercury лучше опенсорсных решений, но хуже закрытых (таблица 2). При этом в плане скорости и при оценке fill-in-the-middle Mercury обходит даже именитых соперников (таблица 3).

Разбор подготовил ❣ Павел Темирчев

Душный NLP

Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models

Сегодня разбираем статью от DeepSeek на тему модификации трансформер-архитектуры.

Мотивация

У трансформеров нет native primitive для knowledge lookup, поэтому ретривал им приходится симулировать вычислениями. Идея статьи — добавить в архитектуру явный inductive bias на ретривал через Engram-модуль и улучшить метрики.

Архитектура

Engram добавляют внутрь блока трансформера, но не во все слои, а максимум в два. Выход модуля добавляется к residual stream. В аблейшенах показали, что лучше всего вставлять Engram-модуль во 2-й слой, а комбинация 2-го и 6-го слоёв даёт более низкий validation loss.

Технически Engram-модуль представляет обучаемые словари nn.Embedding, на вход которых подаются отдельные hash'ы для 2- и 3-грамм. Также в модуле обучаются параметры: context-aware gating (вдохновленный аттеншном), свёртка по seq_len и RMSNorm'ы.

Проверяют модуль в MoE-моделях. В них есть параметры, которые не активны на forward. Allocation ratio (ρ) — это доля неактивных параметров, которая содержится в блоках экспертов; в MoE ρ=1. Параметры для Engram берут, уменьшая количество неактивных экспертов, поэтому становится ρ<1. Чтобы понять, какую долю параметров экспертов оптимально перенаправить в модуль, делают grid search, — запускают несколько претрейнов и меняют только ρ.

Как работает Engram

Работа модуля начинается с обработки входных токенов. Делают tokenizer compression: применяют детерминированные преобразования, чтобы привести токены к canonical ID. Это как стемминг или лемматизация, но для токенов.

Из последовательности токенов строят 2- и 3-граммы. Напрямую индексировать n-граммы нельзя (их слишком много), поэтому используют Hash Embeddings-подход для уменьшения коллизий в рамках небольшого словаря. Для каждой n-граммы получают хеш (вариация multiplicative-XOR), т.е. одно число. Используется несколько голов, поэтому на выходе получается несколько хешей-чисел. Это буквально индексы, по которым получают вектора из nn.Embedding, где у каждой головы и n-граммы независимые вектора — и дальше их конкатенируют.

Дальше — context-aware gating. Берут механизм сродни dot product attention: входной hidden state слоя используется как query, а к эмбеддингам применяют линейные преобразования, аналогичные W_K и W_V. В отличие от аттеншна здесь нет софтмакса, вместо него используется сигмоида, а полученные скоры поэлементно перемножаются с V.

Обучение и инференс

На обучении lookup table шардируют между девайсами, для пересылки нужных эмбеддингов используют all-to-all.

На инференсе таблицу можно вынести в RAM+disk, потому что её не нужно обновлять, только читать. Чтобы не проседал throughput, подсчёты Engram накладывают на основной forward pass: на вход модуля идут токены, значит часть эмбеддингов можно заранее преподсчитывать. В итоге для lookup table на 100B параметров потери по throughput < 3%.

Дополнительной памяти на Engram-модуль не требуется, так как параметры для него берут у неактивных экспертов MoE.

Эксперименты

Минимальный лосс получается, когда четверть неактивных параметров уходит в Engram. Это протестировали на двух бюджетах FLOPs.

На большой Engram-27B-модели метрики растут не только на knowledge-intensive-задачах, но иногда ещё сильнее на reasoning, math и code. На бенчмарках с длинным контекстом тоже получаются лучшие метрики.

Также проводят sensitivity-анализ, зануляя выход Engram-модуля, и видят, что сильнее всего это бьёт по задачам, требующих factual knowledge.

Так получается, потому что у модели увеличивается effective depth: ранним слоям не нужно заниматься knowledge lookup (имитировать его), и больше слоёв теперь могут «думать».

Самыми важными компонентами Engram-модуля оказываются branch-specific fusion (свой W_K для каждой ветки в mHC-архитектуре), context-aware gating и tokenizer compression. Меньше влияют свёртка и добавление 4-граммы (при условии, что будут делить общий бюджет параметров с 2- и 3-граммами).

Разбор подготовил Никита Курдюков из Т-Банка ❣ специально для @YSDA_YR_2019

Душный NLP