DeepSeek, Google, and Meta: 10 Techniques for LLM KV-Cache Compression to Reduce Inference Memory

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

Где упираются LLM

Чем длиннее контекст и чем больше одновременных запросов обслуживает модель, тем быстрее раздувается KV-кэш — промежуточное хранилище ключей и значений attention-механизма. В обзоре приводится показательный пример: у модели на 30 млрд параметров при batch size 128 и входе в 1024 токена KV-кэш может занимать до 180 ГБ памяти. Даже у 7B-модели веса занимают около 14 ГБ GPU-памяти, а кэш — примерно 72 ГБ, то есть сам механизм генерации начинает стоить дороже, чем хранение параметров.

Из-за этого оптимизация KV-кэша стала отдельным направлением, а не мелким тюнингом. Если сжать кэш, можно поднять batch size, обслуживать больше пользователей на том же GPU и не упираться в лимиты памяти при длинных промптах. Важный плюс в том, что значительная часть методов работает прямо на этапе инференса: базовую модель не нужно заново обучать, а эффект виден сразу в пропускной способности и стоимости сервинга.

Как его сжимают

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

По сути, речь уже идёт не о процентах экономии, а о возможности запускать длинный контекст на том же железе. * Выбрасывание токенов: H2O, StreamingLLM и SnapKV сохраняют только часть состояний. H2O держит «тяжёлые» токены с высоким вкладом в attention, StreamingLLM оставляет первые токены и недавнее окно, а SnapKV выбирает важные позиции по attention в конце промпта.

Послойное распределение бюджета: PyramidKV и PyramidInfer исходят из того, что глубоким слоям нужен не такой богатый контекст, как ранним, поэтому память выделяется неравномерно. Квантизация: KIVI, KVQuant и TurboQuant уменьшают точность представления KV-кэша, но стараются не потерять качество генерации. * Архитектурные изменения: MQA, GQA и MLA уменьшают размер кэша на уровне самой attention-схемы, а не поверх уже готовой модели.

* Низкоранговое сжатие: Palu, LoRC и близкие методы режут скрытое измерение KV-тензоров, а не длину последовательности. Самые простые в эксплуатации — методы без дообучения. H2O находит токены, которые собирают основную массу attention, и выбрасывает слабые позиции.

StreamingLLM держит первые токены как «якоря внимания» плюс недавнее окно, поэтому подходит для бесконечных диалогов, но рискует потерять важный фрагмент из середины. SnapKV работает на стадии prefill и отбирает важные позиции отдельно по attention-головам, поэтому обычно выигрывает у более грубых схем при том же лимите кэша.

Распределение attention-весов часто похоже на степенной закон, поэтому

удаление токенов с низким вкладом не всегда сильно бьёт по качеству.

Кто даёт лучший выигрыш В квантизации заметно выделяются KIVI, KVQuant и TurboQuant.

KIVI переводит KV-кэш в 2-битное представление без fine-tuning и, по данным обзора, даёт до 2,6 раза меньший пиковый расход памяти в связке «веса плюс кэш», а также позволяет запускать батчи до четырёх раз больше. KVQuant идёт дальше: использует калибровку, смешанную точность и отдельную обработку выбросов, чтобы удерживать качество даже на экстремально длинных контекстах. Самый агрессивный результат в материале приписан TurboQuant от Google Research.

Этот метод сначала выравнивает распределение значений случайным ортогональным поворотом, а затем корректирует ошибку квантизации так, чтобы оценка скалярных произведений оставалась несмещённой. На H100 он показывает как минимум 6-кратное сокращение памяти и до 8 раз более быстрый attention при 3-битной точности. Для инфраструктурных команд это уже не локальная оптимизация, а заявка на новый стандарт сервинга.

Отдельная линия — изменение самой архитектуры модели. GQA уже де-факто стал нормой для современных open-weight LLM: если в Llama 2 он использовался только в версии 70B, то в Llama 3 распространился и на 8B, и на 70B. Ещё дальше идёт MLA от DeepSeek, где вместо полноразмерных key и value на каждый токен хранится сжатое латентное представление.

В обзоре говорится, что DeepSeek-V2 за счёт MLA сократил KV-кэш на 93,3% относительно предыдущей плотной 67B-модели.

Что это значит

Рынок LLM всё меньше упирается только в размер весов и всё больше — в цену памяти на длинном контексте. Для команд, которые строят inference-сервисы, вывод простой: выигрыш теперь даёт не одна волшебная техника, а грамотный выбор между eviction, квантизацией и архитектурой под конкретную нагрузку, SLA и бюджет GPU.