Что такое KV cache и зачем он модели

Что такое KV cache и зачем он модели: это кэш ключей и значений для уже обработанных токенов. Он нужен модели, чтобы при генерации каждого следующего токена переиспользовать прошлые вычисления вместо повторного прогона всего контекста. Документация Hugging Face описывает это через бытовую аналогию: собеседник каждый раз начинает с нуля и не помнит сказанного ранее, поэтому отвечает медленно. Кэш убирает эту неэффективность.

Основной механизм и его пределы

Авторегрессионная генерация устроена так, что модель предсказывает по одному токену за шаг, и каждое новое предсказание опирается на весь предыдущий контекст. Документация Hugging Face приводит конкретный масштаб: чтобы предсказать тысячный токен, модели нужна информация от предыдущих 999 токенов, а эта информация представлена матричными умножениями по представлениям токенов. Для тысяча первого токена нужна та же информация от 999 токенов плюс сведения от тысячного. Без кэша эти умножения выполняются заново на каждом шаге.

Внутри внимания для каждого токена формируются три вектора: query, key и value. Документация Hugging Face уточняет, что матрицы Q, K и V — это проекции входных эмбеддингов формы (b, h, T, d_head), где b — размер батча, h — число голов внимания, T — длина последовательности к этому моменту, d_head — размерность на голову. На этапе инференса нужен только query последнего токена, а новые векторы key и value дописываются в кэш и присоединяются к прошлым значениям.

Механизм работает по слоям. Документация Hugging Face отмечает, что внимание вычисляется в каждом слое независимо, и кэширование ведётся отдельно для каждого слоя. Базовый интерфейс кэша принимает тензоры key и value для текущего токена и возвращает обновлённые K и V; этим управляет метод forward модели.

Пределы у механизма есть, и они прямо следуют из устройства. Кэш хранит промежуточное состояние внимания. Он не хранит готовый ответ, не меняет веса модели и не работает как база знаний. Документация Hugging Face отдельно предупреждает: кэширование применяется на инференсе, а при включении во время обучения возможны неожиданные ошибки. Ещё один предел — рост памяти. Блог NVIDIA формулирует его так: KV cache растёт линейно с размером языковой модели, числом запросов в батче и длиной контекста, что ведёт к растущим требованиям к памяти. Этот рост относится к самому кэшу. Удвоение длины контекста увеличивает условный объём KV, и оно не обязано удваивать всю память машины, где живут веса, активации и накладные расходы аллокатора.

Отдельно стоит развести два похожих понятия. Память пользователя в чате — это сохранённые факты о вас, которые подставляются в промпт. KV cache — это техническое состояние внимания внутри одного прохода генерации. Первое влияет на содержание ответа, второе на скорость и расход памяти.

Учебный вход, артефакт и эталон проверки

Разберём условную карточку абстрактной модели. Параметры заданы для учебного расчёта; реальный продукт не измерялся. Параметры: L = 2 слоя, H = 2 KV-головы, D = 4 элемента на голову, T = 3 токена, B = 1 запрос, элемент занимает 2 байта.

Формула для объёма только ключей и значений:

KV = 2 × L × H × D × T × B × 2 байта

Подставим значения: 2 × 2 × 2 × 4 × 3 × 1 × 2 = 192 байта. При T = 6 получаем 384 байта. При T = 3 и B = 2 тоже 384 байта. В расчёт не входят веса, активации, padding, работа аллокатора и накладные расходы. Эти параметры не принадлежат реальной модели и служат только для тренировки счёта.

Теперь учебная трасса без запуска модели. Вход — последовательность [А, Б, В]. После prefill в кэше лежат K/V трёх позиций. Prefill по А, Б и В предсказывает токен Г. На следующем шаге модель обрабатывает уже выбранный Г: вычисляет его Q/K/V, использует прошлые K/V из кэша, добавляет новые K/V до четырёх позиций и предсказывает следующий токен. Так выглядит цикл decode: один новый токен за шаг, кэш растёт на одну позицию.

Эталон проверки состоит из трёх пунктов. Первый: переиспользуется промежуточное состояние внимания. Второй: готовый ответ при этом не обещается. Третий: рассчитанные 192 байта относятся только к условным ключам и значениям. Общая память машины в этот расчёт не входит. Если поменять Б в исходном префиксе, старое продолжение нельзя использовать без проверки: кэш привязан к конкретным токенам, и изменение префикса делает прошлые K/V несоответствующими.

Структурная корректность и фактическая правильность

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

Кэш может быть структурно корректен и фактически бесполезен. Пример: вы посчитали K/V для префикса [А, Б, В], затем изменили Б на другую букву, а кэш оставили. Форма тензоров и число позиций могут совпасть, поэтому одной проверки размерностей недостаточно. Старые K/V после изменённой позиции уже не соответствуют новому префиксу; результат такой подстановки нельзя считать корректным. Проверка здесь одна: сверить, что кэш построен на том же префиксе, который вы подаёте.

Второй случай — переиспользование между запросами. Документация TensorRT LLM описывает, что блоки с KV-состоянием прошлых запросов складываются в radix-дерево поиска, и новый запрос ищет совпадающий префикс. Совпадение префикса — необходимое условие reuse в описанной схеме. Прикладная система также должна сохранять совместимость модели, адаптеров и конфигурации кэша и учитывать допустимую область совместного использования. Само совпадение текста не подтверждает истинность сгенерированного ответа. Документация TensorRT LLM добавляет, что переиспользуемые блоки могут делиться между несколькими запросами, поэтому экономится и память, и вычисления.

Третий случай — окно внимания. Документация Hugging Face отмечает, что у моделей со скользящим окном (Mistral, Gemma2) и с чанковым вниманием (Llama4) кэш перестаёт расти, когда слои с таким вниманием достигают максимального размера окна или чанка. Даже если заданная максимальная длина больше, кэш на этих слоях не превысит размер окна. Ограничение относится к прямому вниманию соответствующего слоя. Оно не означает, что все слои модели используют одно окно: архитектура может сочетать оконное и полное внимание.

Первоисточники и границы продуктов

Внешние утверждения в этом разборе опираются на конкретные документы, и у каждого свои границы. Документация Hugging Face по кэшированию описывает механизм внимания и предупреждение про обучение. Документация Hugging Face по стратегиям кэша описывает классы кэша: DynamicCache растёт динамически и является кэшем по умолчанию, StaticCache включается настройкой cache_implementation=»static» в generate() и запускает автоматическую компиляцию стадии декодирования для жадной и сэмплирующей стратегий. Там же сказано, что DynamicCache мешает большинству JIT-оптимизаций, потому что размер кэша не фиксирован, Для StaticCache документация отдельно описывает совместимость с torch.compile; свойства каждого другого типа нужно сверять по его разделу и таблице.

Документация TensorRT LLM описывает блочный пул: кэш — это пул блоков, вмещающих KV-состояние для фиксированного числа токенов, несколько слоёв упакованы в один блок, что требует одинакового числа голов и одинакового размера окна внимания у всех слоёв. Отдельный пул создаётся под каждую комбинацию размера окна и числа голов. Число токенов в блоке задаёт пользователь при создании движка модели, и оно должно быть степенью двойки больше единицы. Там же указано, что при нескольких пулах доступная память делится между ними, доля задаётся при инициализации и остаётся статичной.

Блог NVIDIA для разработчиков описывает приоритетное вытеснение блоков: пользователь задаёт приоритет и длительность для диапазонов токенов и блоков декодирования. В том же материале сказано, что Executor API даёт тонкий контроль над тем, какие блоки остаются, и что в внутренних бенчмарках это повысило долю попаданий в кэш примерно на 20%. Эти данные относятся к TensorRT LLM на GPU NVIDIA. Переносить их на другие библиотеки, другие модели и другие ускорители нельзя: у каждого продукта свои классы кэша, свои настройки и свои ограничения.

Глоссарий Micron описывает кэш как технику оптимизации памяти в больших языковых моделях на трансформерах: она ускоряет инференс за счёт хранения и переиспользования ранее вычисленных значений внимания. Там же приведена аналогия с заметками при чтении длинной книги: вместо перечитывания всех страниц вы держите важные детали рядом. Эти формулировки общие и не привязаны к конкретной библиотеке.

Случай, где кэш не решает задачу

Кэш помогает переиспользовать вычисления. Есть задачи, где это не даёт нужного результата.

Первый случай — короткий одиночный запрос. Если модель генерирует один токен и завершает работу, кэш почти не успевает пригодиться: переиспользовать нечего. Выигрыш появляется на длинной генерации, где шагов много.

Второй случай — меняющийся префикс. Изменение системного промпта или порядка блоков может сократить общий начальный префикс. Переиспользовать можно только совпавшие допустимые блоки до первого расхождения; остальное состояние нужно пересчитать. Документация TensorRT LLM описывает приоритетное вытеснение именно для того, чтобы удерживать блоки, которые с большой вероятностью понадобятся снова: например, блоки системного промпта. Без такой настройки вытеснение идёт по схеме LRU, и нужные блоки могут уйти.

Третий случай — нехватка памяти. Кэш растёт с длиной контекста и числом запросов в батче, и при большом контексте он сам становится узким местом. Документация TensorRT LLM перечисляет оптимизации для этого баланса: paged KV cache, quantized KV cache, circular buffer KV cache и переиспользование кэша. Каждая из них меняет поведение, и универсального улучшения здесь нет.

Четвёртый случай — обучение. Документация Hugging Face прямо указывает, что кэширование применяется на инференсе, а при обучении возможны неожиданные ошибки. Для обучения нужен другой режим работы.

Пятый случай — ограничение по слоям. Документация TensorRT LLM отмечает особенность текущего кода: вытесняться могут только листовые блоки, то есть блоки без потомков в radix-дереве. Это хорошо работает для слоёв с полным вниманием и плохо для слоёв с ограниченным вниманием. Обещания, что подход улучшит всё сразу, здесь не будет.

Как проверить свой случай

Порядок действий для проверки, нужен ли вам кэш и как он себя ведёт.

Шаг первый: определите длину генерации. Если ответ короткий и одношаговый, выигрыш от кэша мал. Если генерация длинная, кэш экономит повторные вычисления на каждом шаге.

Шаг второй: проверьте стабильность префикса. Выпишите, какая часть входа остаётся неизменной между запросами. Совпадающий префикс — условие переиспользования.

Шаг третий: посчитайте условный объём KV, подставив свои L, число KV-голов H, D, T, B и размер одного элемента в байтах. В учебной формуле последний множитель равен двум байтам; для другой точности замените его фактическим размером элемента. Дополнительно учтите ограничения окна по слоям и накладные расходы выбранного способа хранения. Полную формулу всей VRAM здесь не приводим: она зависит от весов, активаций, аллокатора и накладных расходов.

Шаг четвёртый: выберите тип кэша под задачу. Динамический кэш подходит для общего случая. Фиксированный кэш включается настройкой и даёт компиляцию стадии декодирования. Блочный пул с приоритетами подходит для серверной нагрузки с повторяющимися префиксами.

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

Промпт для разбора своего случая с моделью:

Ты помогаешь разобрать работу KV cache в трансформерной модели.
Мой случай: модель [название], длина контекста [число токенов],
число одновременных запросов [число], длина генерации [короткая/длинная].
Префикс между запросами [меняется/остаётся тем же].
Объясни по шагам: 1) что происходит на prefill, 2) что происходит на каждом шаге decode,
3) какие тензоры хранятся в кэше, 4) как оценить объём только KV при моих параметрах,
5) где мой случай упрётся в память. Приведи расчёт с моими числами и отметь,
какие данные тебе нужны дополнительно.

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

Частые вопросы

Что такое kv cache простыми словами?

Это сохранённые ключи и значения для уже обработанных токенов. Модель не пересчитывает их заново на каждом шаге генерации, а берёт готовые из кэша. Документация Hugging Face сравнивает это с собеседником, который помнит сказанное ранее. Без кэша каждый новый токен требовал бы повторного прогона всего контекста.

Чем kv cache отличается от памяти модели?

Память модели — это веса, они фиксированы после обучения. KV cache — промежуточное состояние внимания, которое живёт во время генерации и растёт с длиной контекста. Кэш не хранит готовый ответ и не является базой знаний. Память пользователя в чате — отдельная сущность: сохранённые факты подставляются в промпт.

Почему kv cache растёт с длиной контекста?

В динамическом кэше каждый новый токен добавляет свои key и value. При фиксированной архитектуре расход KV растёт с длиной контекста и числом запросов. У слоёв со скользящим окном рост ограничен размером окна. В смешанной архитектуре нужно отдельно учитывать слои с полным вниманием, где кэш продолжает расти.

Что такое kv cache quantization и compression?

Это способы уменьшить объём кэша. Документация TensorRT LLM перечисляет quantized KV cache и circular buffer KV cache среди оптимизаций. Квантование снижает точность хранения элементов. Compression — более широкое название подходов к уменьшению представления; circular buffer относится к хранению ограниченного окна. Эти механизмы имеют разные ограничения и не взаимозаменяемы; качество и задержку проверяют отдельно.

Можно ли использовать kv cache при обучении?

Документация Hugging Face указывает, что кэширование применяется на инференсе, а при обучении возможны неожиданные ошибки. Рекомендация относится к описанному механизму инференса. Режим обучения и его совместимость с кэшированием проверяют по документации конкретного training-процесса.