Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Один заранее обработанный контекст LLM можно сильно ужать и затем использовать для разных запросов, не пересчитывая весь исходный текст. Хотя препринт не рецензирован и все числа получили сами авторы, при сохранении 2% служебной памяти контекста — KV-кэша — KV² обошёл ближайший метод на RULER более чем на 40 процентных пунктов. Схема рассчитана на сервисы, где один документ, история диалога или состояние агента должны одновременно обслуживать много последующих обращений.
Дешёвый отбор предшествует точному пересчёту
При первом проходе по запросу трансформер сохраняет для каждого токена ключи и значения, которые затем использует механизм внимания. Благодаря этому модель генерирует продолжение без повторной обработки всего контекста, но размер KV-кэша растёт вместе с длиной текста. Для Qwen-2.5-32B контекст на 100 тысяч токенов занимает около 26 ГБ такой памяти.
Обычный способ сжатия оценивает важность позиций и удаляет те, которые меньше влияют на результат. Простые оценки работают быстро, но хуже различают полезные фрагменты. Реконструкция контекста даёт более точный сигнал, однако заставляет модель снова пропускать через себя весь исходный текст.
KV² разделяет эти операции. Сначала KeyDiff, лёгкий предварительный оценщик, ранжирует токены по тому, насколько их представления отличаются от соседних. Метод усредняет сигнал по слоям и головам внимания, а затем выбирает небольшую группу токенов с максимальными оценками.
На втором этапе модель повторно обрабатывает только выбранные токены. Они обращаются ко всему исходному KV-кэшу как пробные запросы, а каждая сохранённая позиция получает оценку по максимальному вниманию хотя бы одного такого запроса. Позиции с низкими оценками удаляются до заданного размера кэша.
Контекст делится на блоки по 4 тысячи токенов. Каждый блок предлагает свои пробные запросы, но те видят полный контекст; итоговые оценки применяются локально и затем объединяются. Начальные позиции, на которых внимание модели часто концентрируется независимо от содержания, сохраняются без отбора.
Доля пробных запросов по умолчанию следует за долей сохраняемого кэша. Чем жёстче лимит памяти, тем меньше токенов проходит дорогой второй этап. Дополнительные циклы могут уточнить выбор, но основной вариант KV² ограничивается одним проходом: последующие итерации заметнее увеличивают время обработки, чем качество.
Преимущество растёт при жёстком лимите памяти
На LongBench при доле кэша 2% Llama-3.1-8B-Instruct с KV² получил среднюю оценку 33,59 против 24,16 у KeyDiff. Для Qwen3-8B результат составил 32,97 против 16,59. При более свободном лимите реконструкция всего контекста приближалась к KV², поэтому основное преимущество нового метода проявилось именно там, где почти весь кэш приходится удалять.
KV² также показал лучший средний результат LongBench во всём исследованном диапазоне бюджетов и потребовал меньше времени и пиковой памяти на этапе сжатия, чем KVzip с полной реконструкцией. Одного дешёвого отбора оказалось недостаточно: качество зависело от того, какие токены попадали во второй этап. KeyDiff работал стабильнее структурных правил, которые сохраняют заранее заданные участки контекста.
Основные опыты прошли на Llama-3.1-8B-Instruct и Qwen3-8B. Метод проверяли на RULER, Needle-in-a-Haystack и LongBench: первый набор измеряет работу с длинным контекстом в контролируемых задачах, второй — поиск спрятанного фрагмента, третий включает ответы по документам, суммаризацию, классификацию и код. Запуски выполнялись на одном GPU A100 или H100, а среди соперников были KeyDiff, Expected Attention и KVzip.
Планы меняются только для повторно используемых контекстов
KV² имеет смысл закладывать в архитектуру, если один подготовленный контекст обслуживает много неизвестных заранее запросов. Это относится к поиску по длинным документам, общему контексту нескольких сессий и постоянной памяти агента. Здесь нельзя настроить кэш под следующий вопрос, а полная реконструкция перед каждым сжатием съедает часть выгоды.
Для одиночного запроса вывод слабее. Если последующий вопрос известен во время сжатия, метод, который учитывает именно его, может выбирать позиции точнее. KV² решает другую задачу: создаёт один универсальный сокращённый кэш до того, как станут известны будущие обращения.
Работа пока подтверждает экономию только на этапе сжатия. Реализация в kvpress использует маски и не создаёт физически компактный кэш, пригодный для полноценного серверного обслуживания. Поэтому замеры ещё не доказывают, что готовый сервис получит соответствующий выигрыш в задержке генерации и фактическом расходе GPU-памяти.
Команде, которая планирует собственный серверный контур, стоит рассматривать KV² как схему отбора, а не как готовую замену движка вывода. Для внедрения понадобятся компактное размещение кэша, поддержка разной длины по головам внимания и проверка на реальном распределении запросов. Архитектурный вывод уже полезен: точную оценку всех токенов можно заменить дешёвым поиском кандидатов и точечным пересчётом, не привязывая кэш к одному будущему вопросу.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
