Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
KV-кэш удалось сжать без одинаковой обработки ключей и значений: значения восстанавливают из ключей, а ключи сокращают отдельно. В препринте Huawei и University College London, который не проходил рецензирование и содержит замеры самих авторов, LowRAM увеличил пиковую скорость генерации до пяти раз при четырёхкратном сжатии. Для систем с длинным или повторно используемым контекстом это открывает способ увеличить пакет запросов без переобучения модели.
Значения предсказывают, ключи раскладывают по общему базису
KV-кэш хранит для каждого обработанного токена ключ и значение, которые механизм внимания повторно использует при генерации. Благодаря кэшу модель не пересчитывает весь контекст на каждом шаге, но объём памяти растёт вместе с длиной контекста и размером пакета.
LowRAM исходит из того, что ключи и значения нельзя сжимать одним способом. Ошибка в ключе меняет веса внимания и может направить модель к неверным фрагментам контекста. Ошибка в значении влияет на результат уже после того, как модель выбрала нужные фрагменты.
Для значений LowRAM обучает небольшую нейросеть отдельно для каждой головы внимания. Во время первичной обработки запроса она получает ключи текущего контекста и учится восстанавливать соответствующие значения. После этого система хранит параметры предсказателя, а полные поправки оставляет только для токенов, на которых он ошибся сильнее всего.
Такой выбор поправок оказался существеннее средней ошибки восстановления. Два способа предсказания могли давать похожую среднеквадратичную ошибку, но по-разному влиять на итоговые ответы модели. Поэтому схему выбирали по результатам задач с длинным контекстом, а не только по точности реконструкции векторов.
Сами ключи LowRAM сжимает через xKV. Метод ищет небольшое число основных направлений в ключах и использует общий базис для соседних слоёв. Получается асимметричная схема: значения выводятся из ключей, а ключи хранятся в сокращённом представлении.
Во время генерации LowRAM не восстанавливает весь кэш на каждом шаге. Система разбивает контекст на фрагменты, выбирает подходящие по текущему запросу и повторно использует уже восстановленные данные. Новые ключи и значения, которые появляются после начала генерации, сохраняются без сжатия.
Качество проверяли по ответам модели, а не только по памяти
LowRAM проверяли на RULER и LongBench с моделями Mistral-7B-Instruct-v0.3, Llama-3.1-8B-Instruct и Qwen3.5-4B. У Qwen метод применяли только к слоям с обычным механизмом внимания: линейные слои этой гибридной модели не используют стандартный KV-кэш.
При умеренном сжатии результаты всех трёх семейств оставались близки к несжатой версии. Разница зависела от модели и набора задач: схема лучше сохраняла качество на длинных примерах LongBench, чем на более коротких сценариях RULER.
LowRAM можно совместить с квантованием, которое хранит числа с меньшей точностью, и удалением записей, которые модель с меньшей вероятностью использует дальше. На контекстах LongBench длиннее 10 тысяч токенов такая комбинация сократила кэш в 26,9 раза и сохранила 94,5% результата исходной модели. Это предельная конфигурация работы, а не универсальная настройка для промышленного сервера.
Селективное восстановление дало прирост скорости, потому что одной экономии памяти недостаточно: если заново строить все значения на каждом шаге, вычислительные затраты съедят выигрыш. Здесь ускорение связано одновременно с большим доступным пакетом и с тем, что модель обращается лишь к выбранной части сжатого кэша.
LowRAM меняет планы только для длинных и повторных запросов
Метод не требует переобучать базовую модель и поэтому подходит как дополнительный слой в системе вывода. Но предсказатель значений нужно подстроить под каждый новый контекст, а разложение ключей тоже выполняется при его первичной обработке. На коротких запросах эта работа и память под параметры могут стоить больше, чем дают.
Постоянные расходы окупаются примерно после нескольких тысяч токенов. Наиболее подходящие сценарии — вопросы по одному документу, поиск по большой базе в пределах общего запроса и обслуживание нескольких пользователей с одинаковым префиксом. Там подготовленный кэш используется повторно, а стоимость подстройки платится один раз.
Для одиночных запросов важен режим с заранее обученной начальной точкой: он сокращает число шагов подстройки, но немного снижает точность относительно полного обучения на контексте. Команде придётся выбирать между задержкой до первого токена и качеством, а не просто включать максимальное сжатие.
Длинную генерацию после первичной обработки контекста в работе не проверяли: для неё новые несжатые записи пришлось бы периодически упаковывать заново. Поэтому LowRAM пока сильнее влияет на планы систем с длинным входом и сравнительно коротким ответом, чем на автономных агентов, которые генерируют большие последовательности.
Практический вывод состоит не в конкретном коэффициенте сжатия, а в архитектурном разделении. Если система уже использует квантование или удаляет часть KV-кэша, LowRAM можно рассматривать как дополнительный слой: ключи сокращать по структуре между слоями, значения восстанавливать из ключей, а точные поправки хранить только там, где предсказатель ошибается сильнее.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
