Журнал · Rit.work

Почему полный повтор контекста портит сжатый KV-кэш

Attic-KV сохраняет в сжатом KV-кэше факты для будущих запросов, заменяя повтор всего контекста самопроверкой на вопросах и ответах.

Rit.work
Студия разработки
9 октября 2026 г.3 мин чтения

Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.

Сжатый KV-кэш лучше сохраняет нужные факты, если модель готовится отвечать на вероятные вопросы, а не перечитывает весь исходный текст. В работе Nanyang Technological University, которая не рецензирована и содержит замеры самих авторов, Attic-KV набрал 73,4 балла против 31,5 у полного повторения контекста при сохранении 3% кэша. Команды могут улучшить уже существующее сжатие без обучения новой модели и без замены метода, который оценивает важность записей.

Почему перечитывание вытесняет полезные факты

KV-кэш хранит промежуточные ключи и значения, которые модель вычисляет при обработке контекста. Если сохранить кэш документа заранее, его можно повторно использовать для разных запросов и не обрабатывать один и тот же текст с нуля.

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

Семейство методов, начатое KVzip, выбирает записи через репетицию. Модель ещё раз читает контекст, система измеряет, каким ключам и значениям она уделяет больше внимания, а затем сохраняет записи с наивысшими оценками. Предполагалось, что полный повтор текста даёт наиболее точную картину его содержания.

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

Проверка с известным правильным ответом показала, что проблема не в ёмкости сжатого кэша. Когда репетиция направляла внимание на сам ответ, почти весь исходный результат сохранялся. Значит, важнее не способ подсчёта оценок, а текст, на котором их считают.

Как Attic-KV готовит кэш к будущим вопросам

Attic-KV меняет только репетицию. Вместо копии документа модель составляет вопросы, которые может задать будущий пользователь, и отвечает на них цитатами из исходного текста. В репетицию обязательно входит ответ: один вопрос не заставляет механизм внимания обратиться к позициям, где хранится нужный факт.

Одних вопросов и ответов недостаточно, потому что модель может не предсказать редкий запрос. Поэтому Attic-KV добавляет опорные позиции — токены, ключи которых сильнее всего отличаются от среднего ключа фрагмента. Они помогают сохранить необычные имена, числа, заголовки и другие выделяющиеся элементы, даже если модель не включила их в самопроверку.

Объём репетиции зависит от содержания. Метод расширяет опорные позиции до предложений, в которых они находятся: связный текст получает короткую репетицию, а насыщенный фактами список — более длинную. Это отличает Attic-KV от KV2, где долю опорных токенов задают заранее для всех документов.

После подготовки репетиции базовый метод работает как раньше. Он может оценивать записи по вниманию, по градиентному вкладу или использовать обученные токены восстановления. Attic-KV не меняет формат KV-кэша, архитектуру модели и правило, по которому система оставляет записи.

Когда работа меняет архитектурный план

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

Для системы, уже построенной вокруг KVzip+, KVgrad или RestoreKV+, работа предлагает локальное изменение конвейера. Замена репетиции подняла результат KVgrad максимум на 17,1 балла, а RestoreKV+ — на 28,1 балла. Это позволяет сначала проверить новый текст репетиции, не переписывая хранение кэша и не обучая собственные параметры.

Самопроверка требует сгенерировать вопросы и ответы во время подготовки документа. Однако на LooGLE весь цикл сжатия документа и ответов на его вопросы занял 126 секунд против 154,8 у KVzip+: короткая репетиция компенсировала затраты на генерацию.

Метод проверяли на вариантах Qwen3 и Llama-3.1, на RULER с контекстами 4K и 16K, естественных текстах LongBench и документах LooGLE. Сравнение охватывает сжатие до нескольких процентов кэша и методы без обучения, с градиентной оценкой и с готовыми токенами восстановления. Эти границы совпадают с системами, где кэш создают до поступления неизвестных запросов; перенос результата на другие режимы требует отдельного замера.

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

Источники

Пауза в чтении

Похоже на вашу задачу?

Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.

Rit.work

Студия разработки

Собираем мобильные приложения и помогаем командам получать от AI реальную пользу. Основатель и команда, работаем удалённо — с клиентами в России и за рубежом.

← Ко всем материалам
Понравилось? Обсудим вашу задачу