Skip to main content
В этом руководстве описано, как создавать и повторно использовать контекстный кэш Gemini (Context Cache) через OpenAI-совместимый Chat Completions API или нативный Gemini API. Перед началом работы:
В примерах этого руководства используется gemini-3.6-flash. Сведения о поддержке Context Cache другими моделями см. в описании моделей и на странице цен платформы.

Сценарии использования

Если в нескольких запросах многократно передаётся один и тот же большой фрагмент контента, можно кэшировать его стабильный префикс, например:
  • очень длинный системный промпт
  • неизменяемую базу знаний или документацию продукта
  • стабильную историю сообщений в многошаговом диалоге
  • многократно используемые определения и описания инструментов
Context Cache подходит для запросов, в которых «начальный контент остаётся неизменным, а последний вопрос постоянно меняется».

Основное использование

Добавьте cache_control в content block последнего сообщения стабильного префикса:
Поддерживаемые значения TTL:
Если ttl не указан, по умолчанию используется 5m.

Структура сообщений

Рекомендуется следующая структура:
Сообщение с cache_control и все предшествующие ему сообщения образуют префикс кэша. После него должно оставаться как минимум одно актуальное сообщение.

Пример OpenAI-совместимого запроса

При первой отправке система попытается создать кэш и обработает текущий запрос с использованием нового кэша.
Отдельно вызывать API создания кэша не нужно. cache_control одновременно задаёт «границу кэша» и «срок действия кэша».

Пример нативного запроса Gemini

Нативный интерфейс Gemini generateContent также позволяет добавлять cache_control в contents[].parts[]:
cache_control — это поле, которым платформа расширяет формат запросов Gemini. Распознав границу, платформа удаляет это поле перед переадресацией и автоматически создаёт либо повторно использует кэшированный контент (cachedContent). Для потокового интерфейса используется то же тело запроса; достаточно изменить URL:
При повторном использовании не изменяйте systemInstruction, contents перед границей, TTL и tools; изменяйте только актуальный контент после границы.

Процесс создания и повторного использования

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

Повторное использование кэша

При повторном запросе не изменяйте:
  • модель
  • все сообщения перед cache_control
  • cache_control.ttl
  • определения инструментов (если используются tools)
  • systemInstruction в нативном запросе Gemini
Изменяйте только актуальный вопрос после границы:
Если стабильный префикс совпадает, а срок действия кэша не истёк, система повторно использует существующий кэш. Следующие изменения приведут к созданию другого кэша:
  • изменение текста или порядка сообщений в стабильном префиксе
  • смена модели
  • изменение 5m на 1h
  • изменение tools или определений параметров инструментов
  • использование другого пользователя API или канала

Пример на Python

В последующих запросах повторно используйте тот же stable_messages, заменяя только последнее сообщение user.

Проверка попадания в кэш

OpenAI-совместимый ответ

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

Нативный ответ Gemini

Проверьте usageMetadata.cachedContentTokenCount в ответе:
Описание полей: streamGenerateContent возвращает те же данные usageMetadata в кадре SSE-ответа. Клиент должен прочитать кадр ответа, содержащий это поле, а не проверять только первый текстовый фрагмент.

Рекомендации

  1. Кэшируйте только действительно стабильный длинный контент, который будет использоваться многократно.
  2. Размещайте изменяющийся при каждом запросе вопрос после границы cache_control.
  3. Не добавляйте в стабильный префикс временные метки, случайные ID или динамические сведения о пользователе.
  4. Если ожидаются повторные вызовы в течение короткого времени, используйте 5m.
  5. Если требуется более длительный период повторного использования, выберите 1h.
  6. Если префикс слишком короткий, модель не поддерживается или кэш временно недоступен, запрос может быть автоматически выполнен в обычном режиме.
  7. В нативном формате Gemini граница кэша должна находиться в contents[].parts[], а не в systemInstruction.

Часто задаваемые вопросы

Да. generateContent и streamGenerateContent используют одну и ту же структуру cache_control. Граница должна находиться в contents[].parts[], а после content с границей должен оставаться как минимум один актуальный content.Если в запросе явно указано имя нативного ресурса cachedContent, платформа отдаёт приоритет предоставленному пользователем ресурсу и не выполняет автоматическое создание кэша.
Распространённые причины:
  • стабильный префикс не полностью совпадает с предыдущим запросом
  • срок действия TTL истёк
  • модель или tools были изменены
  • объём кэшируемого контента не достиг минимального количества токенов, требуемого моделью
  • cache_control находится в последнем сообщении, поэтому актуального вопроса после него нет
Не рекомендуется. Последнее сообщение обычно содержит текущий актуальный вопрос и не должно кэшироваться. Если после границы нет актуального сообщения, запрос выполняется в обычном режиме.
Нет. Сейчас поддерживаются только 5m и 1h. Другие значения приводят к ответу HTTP 400.
Да, но для всех границ должен использоваться один и тот же TTL, а система выберет последнюю границу. Обычно рекомендуется задавать только одну границу на запрос, чтобы сохранить понятную структуру.
Обычно нет. Если условия создания или повторного использования кэша не выполнены, система автоматически отправляет обычный запрос. Исключения — ошибки параметров, такие как недопустимый TTL или одновременное использование разных TTL.
Запрос автоматически выполняется в обычном режиме без создания явного кэша и платы за его хранение. Обычные входные и выходные данные, а также возможный неявный кэш продолжают тарифицироваться по стандартным правилам этой модели.
Это нормальное поведение контекстного кэша Gemini. Стоимость создания кэша учитывается как отдельная плата за его хранение; для обозначения объёма созданного кэша не используется cache_write_tokens в стиле OpenAI/Claude.
Не обязательно. Может сработать и собственный неявный кэш системы. Обычный пользователь может определить применение чтения из кэша по количеству прочитанных из него токенов. Чтобы проверить стоимость создания явного кэша, найдите запись Context Cache storage в журнале расходов платформы.
При создании кэша может однократно взиматься плата за его хранение. При использовании кэша попавшие в него токены тарифицируются по цене чтения из кэша. Актуальные цены указаны в тарифах соответствующей модели на платформе.