Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Apple научила LLM выбирать способ сжатия KV-кэша под конкретный запрос, не выбрасывая токены заранее. На Qwen2.5-14B метод вместе с удалением части токенов сократил кэш при декодировании в 32 раза без статистически значимой потери точности; препринт не рецензирован, и числа получили сами авторы. Для сервисов с длинным контекстом это открывает путь к более крупным пакетам запросов без перехода на меньшую модель.
Почему одинаковое сжатие всех слоёв теряет точность
KV-кэш хранит промежуточные представления всех обработанных токенов, чтобы модель не вычисляла их заново при генерации каждого следующего токена. Чем длиннее контекст и больше параллельных запросов, тем больше памяти занимает кэш. При декодировании модель постоянно читает его, поэтому скорость часто ограничивает пропускная способность памяти, а не вычисления GPU.
Один распространённый способ сократить кэш — оставить только токены, которые алгоритм считает важными. Такое удаление необратимо: фрагмент, бесполезный для текущего шага, может понадобиться модели позднее. KV-Kaizen сначала сжимает представления, не удаляя позиции из контекста.
Метод комбинирует три решения. Соседние слои могут совместно использовать один кэш; представления можно хранить с меньшей разрядностью; низкоранговое представление можно обрезать до меньшей размерности. Если применить одно решение одинаково ко всем слоям, точность быстро падает. Умеренное сочетание трёх способов распределяет потерю информации и даёт больший общий коэффициент сжатия.
Небольшой селектор читает исходный запрос и назначает каждому слою конфигурацию в рамках общего бюджета памяти. Он запускается один раз перед первичной обработкой контекста, после чего конфигурация не меняется до конца генерации. В эксперименте выбор занимал около 3 мс, поэтому его стоимость приходится на начало запроса, а экономия действует на каждом шаге декодирования.
Селектор обучают вместе с основной моделью. Функция потерь одновременно учит модель продолжать текст и удерживает размер кэша около заданного бюджета. Это существенная часть метода: если перенести найденную конфигурацию на модель, которая не училась работать с таким кэшем, точность резко падает.
Обученный выбор выигрывает у единой конфигурации
При четырёхкратном сокращении кэша модели размером от 7B сохраняли точность несжатого варианта на задачах следования инструкциям и математического рассуждения. На одинаковом объёме кэша сжатая крупная модель также отвечала точнее, чем меньшая модель с обычным кэшем.
Авторы сравнили селектор с одинаковыми настройками для всех слоёв, случайным распределением настроек и сжатием после обучения. Примерно до пятикратного сокращения специализированное квантование ещё оставалось на границе лучшего соотношения размера и точности. При более сильном сжатии лучшие результаты давали конфигурации, которым модель обучалась заранее.
KV-Kaizen не заменяет удаление токенов, а дополняет его: сначала метод уменьшает представление каждой сохранённой позиции, затем отдельный алгоритм может сократить число позиций. Именно сочетание этих подходов дало результат из лида. Это полезнее единственного агрессивного приёма, потому что бюджет памяти распределяется между несколькими источниками экономии.
Проверка охватила модели от 1,5B до 32B из нескольких семейств. Точность измеряли на IFEval, GSM8K и длинных контекстах RULER до 16k токенов; сравнение включало статические и случайные конфигурации, сжатие после обучения, меньшие несжатые модели и удаление токенов. Выводы работы относятся к следованию инструкциям, арифметическому рассуждению, поиску информации и ответам по длинному контексту.
Когда KV-Kaizen меняет планы разработки
Работа меняет выбор для команд, которые размещают модели на собственных GPU и упираются в память KV-кэша. Вместо раннего перехода на меньшую модель можно заложить совместное дообучение крупной модели и адаптивного кэша. Такой вариант особенно уместен, когда запросы различаются по содержанию и длине, а единая конфигурация оставляет часть слоёв недосжатой или портит точность.
Это не готовая надстройка для любого сервера. Смешанные размерности и разрядности по слоям требуют специализированных вычислительных ядер, а сжатие по рангу — перевода модели на архитектуру MLA. Совместное обучение модели и селектора занимало до 3,1 раза больше времени, чем обычное дообучение.
Для команды, которая вызывает чужую модель только через API, метод не меняет архитектурный план: он требует доступа к весам, процессу обучения и серверной реализации. Для разработчиков собственного контура вывод практичнее: при выборе между меньшей моделью и сжатием кэша стоит сначала проверить второй вариант на целевых запросах. Работа показывает, что одинаковый бюджет памяти ещё не означает одинаковую точность.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
