Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
KV-кэш длинного контекста научились одновременно сокращать по числу сохранённых состояний и по размеру каждого состояния, не разворачивая сжатые ключи перед вычислением внимания. SlimKV сохранил более 96% результата несжатой модели при умеренном сжатии, хотя препринт не рецензирован и все числа получили сами авторы. Метод позволяет один раз сжать контекст и затем использовать его для разных запросов.
Токены-маяки сжимают историю сразу по двум осям
Кэш ключей и значений (KV-кэш) хранит промежуточные векторы для предыдущих токенов, чтобы модель не вычисляла их заново при каждом следующем токене. Чем длиннее контекст, тем больше таких векторов приходится держать в памяти и читать во время декодирования.
Обычные методы уменьшают кэш одним из двух способов. Сжатие по токенам удаляет часть состояний или объединяет их, рискуя потерять нужный фрагмент. Сжатие по признакам сокращает каждый вектор, но затем часто восстанавливает его до исходного размера перед вычислением внимания — из-за этого экономия памяти не полностью превращается в ускорение.
SlimKV совмещает оба подхода. Вход делят на фрагменты и через заданные интервалы добавляют токены-маяки. Каждый маяк обращается к обычным токенам текущего фрагмента и к маякам из предыдущих фрагментов, поэтому постепенно впитывает содержание истории. После обработки фрагмента обычные состояния удаляют, а в кэше оставляют только маяки.
Для каждого маяка модель сразу строит компактные ключи и значения с меньшим числом координат. Это не разложение уже готового полного вектора: проекции маяков обучают в целевом компактном виде, тогда как основную модель замораживают.
Одинаковый размер представления подходит слоям по-разному. SlimKV анализирует исходные проекции ключей и значений и выделяет каждому слою собственный размер в рамках общего бюджета. Нижняя граница не позволяет отдельному слою получить слишком узкое представление и стать узким местом для всей модели.
Отказ от RoPE для маяков убирает обратное разворачивание
Одного компактного кэша недостаточно для быстрого декодирования. RoPE кодирует порядок токенов, поворачивая координаты запросов и ключей в зависимости от позиции. Такое преобразование нельзя заранее включить в одну общую проекцию компактных ключей: угол различается для каждой позиции. Поэтому многие методы сначала восстанавливают полный ключ, а уже затем применяют RoPE.
У SlimKV зависимость оказалась разной для обычных токенов и маяков. Обычный токен соответствует конкретной позиции и заметно страдает без RoPE на стороне ключа. Маяк суммирует целый фрагмент и хуже привязан к одной позиции, поэтому удаление RoPE меняет его внимание слабее.
Позиционная информация при этом не исчезает полностью. Во время формирования маяка его запросы и ключи обычных токенов по-прежнему используют RoPE. Маяк получает содержание через внимание, которое уже учитывало порядок, и переносит часть этих сигналов в своё компактное состояние.
Проекции маяков специально обучают без RoPE на стороне ключа. При декодировании текущий запрос можно сразу спроецировать в компактное пространство и сопоставить с сохранёнными ключами. Взвешенную сумму также сначала считают над компактными значениями и только результат переводят в полное пространство. Стоимость такого перехода не растёт вместе с числом сохранённых маяков.
Новые токены ответа остаются в обычном формате, поэтому внимание работает гибридно: сжатая история хранится как маяки, а недавно сгенерированный хвост — как стандартные ключи и значения.
Метод подходит для повторного использования длинного контекста, но требует обучения
На LongBench SlimKV показал лучший средний результат среди сравнений с KVZip, PALU, SnapKV и Activation Beacon в самых жёстких режимах сжатия. Проверка Needle-in-a-Haystack также показала, что поиск фрагмента сохраняется при разных позициях внутри контекста.
На контексте 128K вычисление внимания ускорилось до 7,34 раза, а полное декодирование одного токена — до 3,38 раза относительно несжатой Llama-3.1-8B-Instruct. Замеры провели на одной A100 в BF16, с одиночными запросами и PyTorch eager, поэтому они показывают выигрыш механизма, а не пропускную способность готового сервера с пакетной обработкой.
Качество в основном проверяли на Llama-3.1-8B-Instruct и Qwen2.5-14B-Instruct, а перенос на Qwen3 с разреженной архитектурой исследовали отдельно. Выводы относятся к текстовым моделям с RoPE; тесты охватывают ответы по документам, суммаризацию, обучение по примерам, код и поиск факта в длинной последовательности.
Для команд, которые обслуживают много запросов к одному документу или истории диалога, меняется выбор способа сжатия. SlimKV не использует будущий вопрос при подготовке кэша, поэтому сжатое состояние можно сохранить один раз и применять к новым вопросам. В отдельном тесте с несколькими запросами к одному контексту оно оказалось устойчивее вопросо-зависимого SnapKV.
Это не замена формата кэша одной настройкой. Для выбранной базовой модели нужно обучить проекции маяков, встроить их состояния в обработку фрагментов и поддержать отдельный путь внимания для сжатой истории. Основные веса остаются замороженными, что сокращает объём обучения, но перед изменением инфраструктурного плана результат всё равно стоит воспроизвести на своей модели, длинах контекста и режиме нагрузки.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
