KV-кэш в LLM: от обработки промпта до экономии на API

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

Сохраняйте полезные префиксы и отдельно следите за объёмом истории. Это две разные задачи. Префикс — неизменное начало запроса; его кэширование позволяет сократить обработку ввода, но не избавляет агента от остальной работы.

Приведённые ниже цены и правила кэширования сверены с действующими страницами тарифов и документацией провайдеров 15 октября 2026 года. Расчёты памяти основаны на документированных размерностях тензоров, а не на измерениях на конкретном GPU.

Что такое KV-кэш и зачем он нужен при повторных запросах?

KV-кэш — это сохранённое состояние механизма внимания. Внимание позволяет трансформеру учитывать релевантную предыдущую информацию при текущем предсказании. Токен — единица текста или другого ввода модели — получает числовые представления внутри каждого слоя внимания. Кэш сохраняет ключи и значения этого слоя для дальнейшего использования. Такое послойное хранение описано в объяснении кэширования от Hugging Face.

Три роли в механизме внимания проще представить на примере исследовательской библиотеки:

• Запрос (query) выражает, что ищет текущая позиция.
• Ключ (key) позволяет сопоставить запрос с предыдущей позицией.
• Значение (value) содержит информацию, которую может дать найденное соответствие.

Представьте, что перед написанием отчёта вы подготовили заметки и указатель к ним. Работая над каждым новым предложением, можно обращаться к готовым материалам. Заново составлять указатель и заметки для каждого предложения — лишняя работа; хранить их — значит занимать место. На уровне реализации аналогия заканчивается: модель хранит числовые массивы, а не читаемые карточки или краткий пересказ ваших документов.

Текущий запрос сравнивается с предыдущими ключами, а полученные веса внимания используются для объединения соответствующих значений. В каузальном трансформере предыдущие позиции не могут заглядывать в будущее. Поэтому добавление следующего токена не требует менять уже вычисленные состояния предыдущих позиций. Именно это позволяет использовать их повторно. Вычисления внимания и процесс генерации описаны в исходной статье о PagedAttention.

По той же причине обычный кэш хранит K и V, а не все предыдущие запросы. Для следующего предсказания нужны текущий запрос и накопленные ключи и значения; предыдущие запросы свою работу уже выполнили.

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

Кэшированный префикс — не то же самое, что кэшированный ответ. Модель по-прежнему генерирует новое продолжение. Новый вопрос по тому же документу позволяет использовать его подготовленное состояние, а не возвращать прежний ответ.

Как работает KV-кэш на этапах prefill и decode?

Prefill подготавливает ввод, а decode строит продолжение. Различие между этими этапами объясняет, почему при попадании в кэш ответ может начать поступать быстрее, хотя на его завершение всё равно нужно время.

Для обычного авторегрессионного трансформера схема выглядит так:

Prefill: токены промпта → обработка промпта → сохранение ключей и значений каждого слоя → предсказание первого выходного токена.

Decode: последний сгенерированный токен + сохранённые ключи и значения → обработка этого токена с учётом контекста через механизм внимания → предсказание следующего токена; добавление новых вычисленных ключей и значений.

Повторение decode: использование растущего кэша до конца генерации.

На этапе prefill известные позиции промпта можно обрабатывать совместно. На этапе decode продолжение строится последовательно: будущие токены ещё не выбраны. Это различие описано в разделах статьи о PagedAttention, посвящённых генерации и выполнению запросов.

KV-кэш удешевляет получение следующего токена по сравнению с повторным вычислением всего префикса. Но стоимость этого шага по-прежнему зависит от длины контекста. При обычном полном внимании запрос нового токена всё ещё взаимодействует с сохранёнными ключами и значениями. Чем больше сохранённый контекст, тем больше данных приходится обрабатывать механизму внимания. Hugging Face описывает эту работу, которая остаётся на каждом шаге.

Теперь важно разделить два вида повторного использования. Внутри одного ответа KV-кэш избавляет от повторных вычислений в ходе генерации. Между запросами кэширование префикса, которое в облачных API также называют кэшированием промптов, сохраняет подходящие состояния, чтобы следующий вызов мог пропустить часть работы на этапе prefill. Сам по себе идентификатор диалога не означает, что эти состояния доступны.

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

Разработчику, работающему с API, стоит измерять и задержку до первого токена, и время генерации ответа. Сокращение первой не доказывает, что decode тоже ускорился. В документации Automatic Prefix Caching движка vLLM прямо разделяются экономия на prefill и время decode.

Как повторное использование вычислений отражается в цене ввода?

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

Для API, которые отдельно тарифицируют обычный ввод, запись в кэш и чтение из кэша, стоимость ввода можно записать так:

Стоимость ввода = (U × p_input + W × p_write + R × p_read) / 1,000,000

Здесь U — токены обычного ввода, W — токены, оплачиваемые как запись в кэш, а R — токены, оплачиваемые как чтение из кэша. Каждая p — цена соответствующей категории за миллион токенов. Категории не должны пересекаться: токен записи не нужно повторно оплачивать по обычному тарифу ввода. Это расчёт с учётом единиц измерения на основе категорий тарифов OpenAI и Anthropic.

Затем добавляются стоимость вывода, применимые платежи за инструменты и отдельно тарифицируемое хранение кэша. Явное кэширование Google учитывает ещё и время хранения, поэтому одной модели записи и чтения здесь недостаточно. Ниже — примеры правил тарификации, а не рейтинг моделей.

Anthropic: обозначьте границу повторно используемого префикса

Anthropic позволяет управлять кэшированием промптов через cache_control: на верхнем уровне запроса для автоматического управления границами кэширования либо на уровне отдельных блоков контента. Такая граница отмечает конец префикса, который нужно сохранить. Оба подхода описаны в документации по тарифам.

Пример цен для стандартного Claude API: у Claude Sonnet 5.5 ввод стоит $2, чтение из кэша — $0.10, запись на 5 минут — $2.50, запись на 1 час — $4. Все цены указаны за миллион токенов. Тарифы Anthropic.

Для этой модели минимальная длина кэшируемого префикса — 512 токенов. Содержимое должно точно совпадать вплоть до границы кэширования. Чтение продлевает срок хранения без новой платы за запись, однако отсчёт начинается с начала запроса: генерация ответа расходует часть этого времени. У других моделей Claude минимальная длина и скидки на чтение отличаются. Правила кэширования промптов Anthropic.

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

OpenAI: проверьте правила записи для выбранной модели

OpenAI по умолчанию включает кэширование промптов на поддерживаемых моделях, а новые модели поддерживают как неявные, так и явно заданные границы кэширования. Конкретное поведение зависит от модели. Кэширование промптов OpenAI.

Пример цен для тарифа Standard с коротким контекстом: у GPT-6.1 Sol ввод стоит $2.00, кэшированный ввод — $0.10, запись в кэш — $2.50 за миллион токенов. При превышении 272K входных токенов ставки ввода и кэширования удваиваются для всего запроса. Тарифы OpenAI, порог для модели.

Для GPT-5.6 и более поздних моделей минимум составляет 1,024 видимых входных токена, а документированный срок хранения кэша — не менее 30 минут после последней записи или повторного использования. Для записываемых токенов тариф записи заменяет обычный тариф ввода, а не добавляет ещё одну оплату всего ввода. У более ранних моделей другие правила записи и хранения. Действующие условия кэширования.

В Responses API проверяйте usage.input_tokens_details.cached_tokens и cache_write_tokens. Сохранение сессии не гарантирует попадания в кэш. Если нужно разобраться в структуре запроса и статистике использования, обратитесь к руководству по диагностике кэширования промптов GPT-6 на этом сайте.

Google Gemini: автоматическое повторное использование и явное хранение

Google Gemini поддерживает автоматическое неявное кэширование: при попадании в кэш стоимость снижается. Для рассматриваемой Gemini 3.8 Flash документированный минимум — 4,096 входных токенов. Общий контент в начале запросов и короткие интервалы между ними повышают вероятность повторного использования. Руководство Google по кэшированию контекста.

Пример цен для платного тарифа Standard в Gemini Developer API: у Gemini 3.8 Flash ввод стоит $0.75, кэшированный ввод — $0.075 за миллион токенов, а хранение явного кэша — $0.50 за миллион токенов в час. Эти цены действуют до 31 декабря 2026 года. Тарифы Google.

При явном кэшировании создаётся именованный ресурс с кэшированным содержимым и заданным сроком действия; последующие запросы generateContent ссылаются на него. Из-за платы за хранение даже неиспользуемый документ может продолжать приносить расходы. Справочник Google по API кэширования.

Выбор API имеет значение: Interactions API поддерживает только неявное кэширование. Действующее руководство Google также исключает явное кэширование для Gemini 4 Argon и последующих моделей; поддерживаемые модели Gemini 3 и 2.5 работают с явными кэшами через generateContent. В Interactions API проверяйте usage.total_cached_tokens, как указано в руководстве. Правила Google для разных API.

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

Как объём KV-кэша зависит от сохранённого контекста?

В обычных слоях с полным вниманием объём памяти под сами данные KV-кэша растёт линейно с числом сохранённых токенов. Длинный диалог увеличивает рабочий набор данных, даже если обработка его начала оплачивается со скидкой.

Для последовательностей одинаковой длины и слоёв внимания с одинаковыми размерностями:

KV bytes ≈ 2 × B × T × L × H_kv × D × S

• 2: один массив ключей и один массив значений.
• B: число одновременно обрабатываемых последовательностей, если их данные кэша не используются совместно.
• T: число сохранённых обработанных токенов в каждой последовательности, включая токены промпта и сгенерированные токены.
• L: число слоёв внимания, хранящих такой кэш.
• H_kv: число голов ключей и значений на слой.
• D: число скалярных значений на голову.
• S: число байт для хранения одного скалярного значения.

Формула получена подсчётом элементов на основе документированной формы кэша каждого слоя и организации голов ключей и значений в vLLM. Она оценивает объём самих тензоров, а не всю память устройства.

Число голов здесь принципиально. При grouped-query attention несколько голов запросов используют общие головы ключей и значений, поэтому в формулу нужно подставлять число KV-голов. Если вместо него взять большее число голов запросов, оценка объёма кэша окажется завышенной.

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

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

В документации Hugging Face по стратегиям кэширования описан предел для слоёв с оконным вниманием, а в описании устройства кэша префиксов vLLM — повторно используемые физические блоки. Если архитектура хранит состояние иначе, чем обычные плотные массивы ключей и значений, опирайтесь на её документированную структуру данных.

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

Оптимизация KV-кэша в vLLM

vLLM — движок обслуживания LLM с открытым исходным кодом — позволяет управлять выделением памяти, повторным использованием и представлением данных на собственной инфраструктуре. Прежде чем менять развёртывание, выберите механизм, который решает именно вашу проблему с производительностью.

PagedAttention: выделяйте блоки по мере роста диалога

PagedAttention позволяет механизму внимания работать с KV-данными, размещёнными в отдельных физических блоках. Логической последовательности не требуется один большой непрерывный участок памяти на весь возможный будущий рост. Исходный подход сокращает неэффективно выделенную память и позволяет совместно использовать данные. Статья о PagedAttention.

Здесь снова подходит аналогия с библиотекой: растущему исследовательскому проекту выделяют свободные секции стеллажей и ведут карту их порядка. Не нужно заранее резервировать целый огромный пустой ряд, пока ещё неизвестно, сколько материалов появится.

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

Кэширование префиксов: используйте вычисления предыдущего запроса

Automatic Prefix Caching повторно использует KV-состояние совпадающего префикса. В документации vLLM указана настройка enable_prefix_caching=True. Именно эта функция нужна, когда вопросы по одному документу или последовательные обращения агента снова и снова содержат одинаковое начало. Automatic Prefix Caching.

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

Предел пользы задаёт сама нагрузка: у несвязанных промптов мало общих вычислений, а при длинных ответах основное время всё ещё может уходить на decode. Если вы выбираете сам движок, более широкий круг вопросов разобран в сравнении vLLM и SGLang.

Квантование KV-кэша: меньше байт на каждое значение

Квантование KV-кэша снижает точность хранения числовых значений. vLLM поддерживает хранение кэша в FP8 через kv_cache_dtype="fp8" и для сохранения качества рекомендует калибровать коэффициенты масштабирования на наборе данных. Доступные варианты зависят от бэкенда внимания. Документация vLLM по квантованному кэшу.

Переход с 16-битных на 8-битные значения вдвое сокращает объём самих скалярных данных в формуле — до учёта метаданных масштабирования и накладных расходов на выделение памяти. Он не уменьшает вдвое всю память сервера и не доказывает измеренного ускорения. Квантование весов модели и квантование состояния внимания — отдельные решения.

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

Сжатие KV-кэша: не путайте точность с составом контекста

Хранить менее точные значения и сохранять меньше позиций — разные компромиссы. Квантование меняет представление значений. Ограниченное окно внимания меняет набор позиций, доступных конкретному слою. Риски этих подходов нельзя объединять общим обещанием «сжатия». Стратегии кэширования Hugging Face.

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

Выгрузка KV-кэша: больше сохранённых данных ценой пересылок

Выгрузка, или offloading, переносит повторно используемое состояние на другой уровень памяти. OffloadingConnector в vLLM может хранить завершённые блоки в оперативной памяти хоста и на поддерживаемых дополнительных уровнях хранения, а при попадании в кэш возвращать нужные блоки на GPU. Руководство vLLM по выгрузке кэша.

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

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

Почему долю попаданий в кэш переоценивают?

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

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

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

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

Частые вопросы о KV-кэше в LLM

Использует ли ChatGPT KV-кэш?

OpenAI описывает кэширование промптов на основе KV для своих API. Это объясняет работу публичной функции API, но не раскрывает все детали внутренней инфраструктуры ChatGPT. При разработке опирайтесь на опубликованные правила кэширования и поля статистики выбранной модели API. Документация OpenAI.

Нужно ли выгружать KV-кэш в память GPU?

При инференсе на GPU активное состояние внимания используется на GPU. Механизм выгрузки vLLM переносит повторно используемые блоки в память хоста или на другие поддерживаемые уровни, а по запросу возвращает их обратно. Этот вариант стоит рассмотреть, если сохранение большего числа префиксов оправдывает затраты на пересылку. Выгрузка кэша в vLLM.

Что происходит, когда KV-кэш заполнен?

vLLM может удалять неиспользуемые блоки кэша, а при нехватке памяти для активных запросов — приостанавливать работу и позже выполнять вычисления заново. Это влияет на задержку. Такая ситуация отличается от превышения лимита контекстного окна модели. Управление кэшем, вытеснение запросов.

Как уменьшить объём KV-кэша?

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

Три привычки, которые помогают агенту чаще попадать в кэш

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

1. 1

   Размещайте стабильный системный промпт в начале

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

2. 2

   Дополняйте историю, а не переписывайте её

   Сохраняйте предыдущие сообщения и добавляйте новый ход пользователя, вызов инструмента ассистентом или результат инструмента. Не пересобирайте прошлые ходы при каждом вызове, меняя сводки или форматирование. Когда историю нужно сократить, делайте это в явно выбранный момент, а затем формируйте новый стабильный префикс. Такой подход следует из зависимости каждого блока от предшествующих токенов. Определение совпадения префикса в vLLM.

3. 3

   Убирайте временные метки из начала запроса

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

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

Подпишитесь на рассылку, чтобы получать практические объяснения технологий, на которых работают ИИ-агенты.