KV-cache: почему длинные диалоги съедают память GPU

После загрузки модели расход памяти не остаётся постоянным. При генерации Transformer сохраняет промежуточные ключи и значения для уже обработанных токенов. Этот KV-cache помогает не пересчитывать всё заново, но занимает память, которая растёт вместе с рабочим контекстом. Механизм описан в документации Transformers. 1

Cache принадлежит выполняющейся последовательности

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

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

Оцените обычный attention

Для одинаковых слоёв приближение выглядит так:

2 × число слоёв × KV-heads × размер головы × токены × параллельные последовательности × байт на элемент.

Возьмём условную архитектуру с 32 слоями, 8 KV-heads и головой 128. При двухбайтовом cache один контекст на 8192 токена занимает 1 GiB. Четыре таких контекста потребуют 4 GiB. Это иллюстративная арифметика, а не измерение конкретной модели.

Формула не универсальна для MLA, sliding window и гибридных архитектур. Не подставляйте в неё параметры автоматически, если модель использует другой механизм. Для tensor parallelism также проверьте, какие структуры реально делятся между устройствами.

Способы уменьшить расход

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

Снизить число одновременно активных запросов. Это экономит память, но может увеличить очередь. Следите за задержкой, а не только за отсутствием OOM.

Использовать другой тип cache. Quantization и offload имеют отдельные компромиссы. vLLM документирует FP8 KV-cache, а Transformers описывает несколько стратегий хранения. 2 3 Их полезность проверяется на выбранном движке и контрольных примерах.

Сократить повторяющийся контекст. В RAG можно уменьшить число нерелевантных фрагментов. В диалоге можно пересматривать политику истории. Это изменение приложения, поэтому его качество нужно оценить отдельно.

Prefix caching не является бесплатной памятью

Если запросы имеют одинаковый префикс, некоторые реализации могут повторно использовать вычисленное состояние. Эффект зависит от реального совпадения токенов и политики cache. Нельзя закладывать максимальную экономию в гарантированную конфигурацию, когда запросы пользователей ещё не изучены.

Для оценки полезно измерять попадания в cache и отдельно запускать тест с холодным состоянием. Иначе демонстрация на постоянно повторяемом вопросе может выглядеть намного лучше реальной нагрузки.

Как найти причину OOM

Сначала запишите модель, формат весов, параметры cache, максимальный контекст и одновременно активные запросы. Затем повторите ошибку с минимальным набором. Меняйте по одному параметру, фиксируя пик памяти и задержки. Бесконтрольное уменьшение всех лимитов одновременно затруднит понимание причины.

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

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