Prompt Caching 2026: OpenAI, Anthropic, G…

Обновлено: 15 июля 2026

Prompt caching, это механизм повторного использования уже обработанного префикса промпта между запросами к LLM, позволяющий сократить стоимость input-токенов до 90% и снизить время до первого токена (TTFT) в 2–4 раза. В 2026 году prompt caching поддерживают все крупные провайдеры: OpenAI (автоматически), Anthropic (через явные cache_control-точки) и Google Gemini (через объект CachedContent). Их модели ценообразования, TTL и минимальные размеры кеша существенно различаются. Честно говоря, я на этом обжёгся в первом же продакшн-агенте: закешировал 15K токенов инструкций, но забыл, что динамическая дата сидит в начале system-промпта. Hit rate: 0%. В этом руководстве разбираю практическую реализацию, привожу рабочие примеры на Python и объясняю, когда экономия действительно материализуется.

OpenAI кеширует автоматически префиксы ≥1024 токенов и даёт скидку 50% на cached input; никаких изменений в коде не требуется, TTL 5–10 минут.
Anthropic требует явных cache_control-точек (до 4 breakpoint'ов), даёт скидку 90% на чтение кеша и поддерживает TTL 5 минут или 1 час (extended cache).
Google Gemini использует явный CachedContent API с минимумом 32 768 токенов для Pro и 4 096 для Flash, TTL по умолчанию 1 час, стоимость чтения 25% от базовой цены input.
Правильная структура: статический префикс (system + инструменты + примеры + большие документы) сначала, динамическая часть (пользовательский запрос) в конце.
Prompt caching совместим с function calling и структурированным выводом, но любое изменение tools-определений полностью инвалидирует кеш.
Экономия реальна только при hit rate выше 40–50%; для агентов с длинным контекстом и системными инструкциями типичный ROI составляет 3–8x.

Что такое prompt caching и зачем он нужен

Prompt caching, это оптимизация на стороне провайдера. Уже обработанное KV-состояние трансформера для префикса промпта сохраняется в горячем кеше и переиспользуется в последующих запросах с идентичным началом. С точки зрения биллинга это означает, что за токены, попавшие в кеш, вы платите значительно меньше (от 10% до 50% базовой цены input в зависимости от провайдера). А с точки зрения производительности модель пропускает фазу prefill и сразу переходит к генерации.

На практике prompt caching даёт максимальный выигрыш в трёх сценариях. Первый, чат-агенты с большим системным промптом (5–20K токенов инструкций, few-shot примеров и описаний инструментов), где префикс идентичен в каждом ходу диалога. Второй, вопросно-ответные системы поверх документов, когда пользователь задаёт серию вопросов к одному и тому же тексту (юридический контракт, спецификация, книга) объёмом 20–200K токенов. Третий, batch-обработка, где сотни задач разделяют общий шаблон с few-shot примерами.

По данным Anthropic, для типовых чат-агентов с 10K системным промптом кеширование сокращает счёт за input на 60–85%. А по замерам OpenAI, TTFT падает с 3–5 секунд до 0.5–1 секунды на GPT-4o при работе с длинным контекстом. При этом семантическое кеширование (GPTCache, semantic router), это совершенно другая техника: оно кеширует пары «запрос → ответ» на клиенте, тогда как prompt caching работает на уровне вычислений модели и сохраняет полезность даже при уникальных пользовательских запросах.

Сравнение prompt caching в OpenAI, Anthropic и Gemini

Модели ценообразования и требования к активации отличаются радикально. OpenAI кеширует автоматически без вмешательства разработчика, Anthropic требует явно расставить cache_control-точки и предлагает опциональный extended-cache на час, а Google Gemini заставляет создать отдельный объект CachedContent и явно передавать его в запросы. Ниже сводная таблица актуальных характеристик на июль 2026 года.

Характеристика	OpenAI (GPT-4o/o-series)	Anthropic Claude 4/3.7	Google Gemini 2.5
Активация	Автоматически	Явно (cache_control)	Явно (CachedContent API)
Минимальный размер	1 024 токена	1 024 (Sonnet/Opus), 2 048 (Haiku)	32 768 (Pro), 4 096 (Flash)
TTL по умолчанию	5–10 мин	5 мин	60 мин (конфигурируется)
Расширенный TTL	нет	1 час (доп. плата)	любой (плата за хранение)
Стоимость записи	Без наценки	1.25× base input (5 мин), 2× (1 час)	Плата за хранение $/M токен-час
Стоимость чтения	50% base input	10% base input	25% base input
Максимум breakpoints	N/A (auto)	4	1 (весь CachedContent)
Поддержка tools	Да	Да, включая tools-блок	Да

Ключевой вывод: Anthropic даёт самую агрессивную скидку (90%), но требует продуманного разделения префикса. OpenAI выигрывает по простоте: вы получаете экономию бесплатно, если структура промпта стабильна. Gemini оптимален для очень больших контекстов (>32K), где стоимость хранения $1/M токенов в час всё равно ниже, чем повторная передача 200K-токенного документа в каждом запросе.

Prompt caching в Anthropic Claude: cache_control breakpoints

В Anthropic API вы отмечаете конкретные блоки как «граница кеша», добавляя поле cache_control. Всё, что находится до и в этом блоке, включая всё предыдущее содержимое системного промпта, tools и messages, будет закешировано. При следующем запросе с идентичным префиксом Claude вернёт в usage-метрике поле cache_read_input_tokens, и вы заплатите за них 10% от базовой ставки.

Практический пример с двумя breakpoint'ами (стабильный системный промпт с инструкциями и большой RAG-контекст):

import anthropic

client = anthropic.Anthropic()

SYSTEM_INSTRUCTIONS = """Ты, юридический ассистент. Отвечай только на основе
предоставленных документов. При цитировании указывай раздел и параграф..."""  # ~2000 токенов инструкций

CONTRACT_TEXT = open("contract.md").read()  # ~40 000 токенов документа

def ask(question: str) -> str:
    response = client.messages.create(
        model="claude-sonnet-4-5-20250929",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": SYSTEM_INSTRUCTIONS,
                "cache_control": {"type": "ephemeral"},  # breakpoint 1: инструкции
            },
            {
                "type": "text",
                "text": f"<document>\n{CONTRACT_TEXT}\n</document>",
                "cache_control": {"type": "ephemeral"},  # breakpoint 2: документ
            },
        ],
        messages=[{"role": "user", "content": question}],
    )
    usage = response.usage
    print(f"cache_creation: {usage.cache_creation_input_tokens}, "
          f"cache_read: {usage.cache_read_input_tokens}, "
          f"input: {usage.input_tokens}")
    return response.content[0].text

ask("Каков срок действия договора?")   # первый запрос, write в кеш
ask("Кто отвечает за форс-мажор?")     # cache hit ≈ 42 000 токенов

Для extended-cache на 1 час замените {"type": "ephemeral"} на {"type": "ephemeral", "ttl": "1h"} и добавьте заголовок anthropic-beta: extended-cache-ttl-2025-04-11. Extended TTL полезен, когда паузы между запросами превышают 5 минут (типично для дашбордов и аналитических инструментов). Подробности есть в официальной документации Anthropic по prompt caching. Если вы также используете function calling и tool use в LLM-агентах, cache_control можно ставить на tools-блок. Это, кстати, самый недооценённый способ снизить стоимость мультиагентных систем.

Автоматический prompt caching в OpenAI API

OpenAI включила автоматический prompt caching в октябре 2024 года, и с тех пор он расширился на все модели семейств GPT-4o, GPT-5, o1, o3 и o4. Разработчику ничего делать не нужно: система ищет самый длинный общий префикс (кратный 128 токенам) между вашим текущим запросом и недавно обработанными. Если он ≥1024 токенов, часть input автоматически идёт по льготной ставке в 50% от базовой цены.

Проверить, попал ли ваш запрос в кеш, можно по полю usage.prompt_tokens_details.cached_tokens. Пример:

from openai import OpenAI

client = OpenAI()

SYSTEM = "Ты, эксперт по SQL. Всегда объясняй план выполнения запроса..." * 200  # >1024 токенов

def query(user_message: str):
    resp = client.chat.completions.create(
        model="gpt-4o-2024-11-20",
        messages=[
            {"role": "system", "content": SYSTEM},
            {"role": "user", "content": user_message},
        ],
    )
    cached = resp.usage.prompt_tokens_details.cached_tokens
    total = resp.usage.prompt_tokens
    print(f"cached: {cached}/{total} ({100*cached/total:.1f}%)")
    return resp.choices[0].message.content

query("Оптимизируй SELECT ... FROM orders ...")
query("Оптимизируй SELECT ... FROM users ...")  # cache hit на SYSTEM

Важное правило: OpenAI матчит только префиксы, поэтому любые динамические данные (timestamp, user_id, session-контекст) должны идти после статической части. Классическая ошибка (та самая, о которой я упомянул в начале): вставить дату в system-промпт, и тогда кеш не пробьётся никогда. TTL составляет 5–10 минут в пиковые часы и может доходить до часа при низкой нагрузке, но полагаться на это в SLA нельзя. Официальные детали смотрите в OpenAI Prompt Caching Guide.

Context caching в Google Gemini: явная модель

Google Gemini реализует наиболее «тяжёлую» модель кеширования: вы создаёте отдельный объект CachedContent, получаете его ID, и потом передаёте этот ID в каждый запрос вместо повторной передачи содержимого. Это удобно для очень больших документов (>32K токенов), потому что вы явно контролируете, что и как долго хранится в кеше. Правда, требует управления жизненным циклом объекта.

from google import genai
from google.genai import types

client = genai.Client(api_key="YOUR_API_KEY")

# Загружаем большой файл (например, 200-страничный PDF ≈ 100K токенов)
pdf_file = client.files.upload(file="research_paper.pdf")

# Создаём кеш с TTL = 2 часа
cache = client.caches.create(
    model="gemini-2.5-pro",
    config=types.CreateCachedContentConfig(
        display_name="research_paper_v1",
        system_instruction="Ты, научный ассистент. Отвечай только по документу.",
        contents=[pdf_file],
        ttl="7200s",  # 2 часа
    ),
)

print(f"cache_name: {cache.name}, tokens: {cache.usage_metadata.total_token_count}")

# Используем кеш в запросах, платим только за пользовательский вопрос + read
def ask(question: str):
    resp = client.models.generate_content(
        model="gemini-2.5-pro",
        contents=question,
        config=types.GenerateContentConfig(cached_content=cache.name),
    )
    print(resp.usage_metadata)  # включает cached_content_token_count
    return resp.text

ask("Какова основная гипотеза статьи?")
ask("Перечисли все использованные датасеты.")

# Не забудьте удалить кеш, когда он больше не нужен
client.caches.delete(cache.name)

Экономика Gemini caching отличается: вы платите $1 за миллион токенов в час хранения (для Gemini 2.5 Pro) плюс 25% базовой цены за каждый read. Точка безубыточности примерно 4 запроса в час к одному и тому же кешу, если каждый запрос был бы full-size. Полный ценник и детали TTL см. в документации Google по context caching. Для чат-агентов с меняющимся контекстом Anthropic обычно выгоднее; для стабильных RAG-баз на десятки тысяч токенов Gemini часто оптимальнее. Я подробно разбирал выбор между провайдерами и векторными хранилищами в статье сравнение векторных баз данных 2026.

Как структурировать промпт для максимального hit rate

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

System prompt (стабильный): роль, стиль, ограничения. Никаких дат, user_id, session_data.
Tools/function definitions: вынесите в отдельный кешируемый блок, если провайдер это поддерживает.
Few-shot примеры: 3–10 примеров, покрывающих edge cases. Идут после инструкций.
RAG-контекст / базовые документы: крупные документы, редко меняющиеся между запросами.
История диалога: предыдущие ходы (в Anthropic ставьте cache_control на последнее сообщение ассистента, чтобы кешировать всю историю).
Текущий пользовательский запрос: единственная гарантированно уникальная часть.

Второе правило, стабильность tools-определений. В агентных системах на LangChain или CrewAI разработчики часто динамически формируют список инструментов через if-ветки. Даже перестановка порядка двух функций ломает кеш. Заведите фиксированный порядок и один источник истины для описаний. Третье правило, согласованность форматирования: пробелы, регистр, порядок ключей в JSON-примерах должны быть идентичны между запусками.

Prompt caching с function calling и tool use

Prompt caching и tool use полностью совместимы у всех трёх провайдеров, но с оговорками. У Anthropic tools кешируются, если cache_control поставлен на последний элемент tools-массива или на первый блок system. У OpenAI cached_tokens автоматически учитывает и токены tools-определений: они входят в общий префикс. У Gemini tools можно передать в CachedContent при создании.

# Anthropic: кешируем большой пакет инструментов
import anthropic
client = anthropic.Anthropic()

TOOLS = [
    {"name": "search_docs", "description": "...", "input_schema": {}},
    {"name": "run_sql", "description": "...", "input_schema": {}},
    # ... 20+ инструментов, суммарно ~3000 токенов
]
# Помечаем последний tool как границу кеша
TOOLS[-1]["cache_control"] = {"type": "ephemeral"}

response = client.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=1024,
    tools=TOOLS,
    messages=[{"role": "user", "content": "Найди все заказы за 2025 год"}],
)

Критично: любое изменение любого инструмента (описание, схема параметров, порядок) инвалидирует весь кеш. Это часто ломается в системах с автоматической регистрацией функций через декораторы. Решение простое: сериализовать tools в фиксированный JSON один раз и переиспользовать во всех запросах. Хорошая практика, покрыть это интеграционным тестом, который сравнивает хэш от tools-схемы с золотым эталоном.

Мониторинг hit rate и расчёт экономии

Без наблюдаемости prompt caching превращается в оптимизацию с непредсказуемым эффектом. Минимум, что нужно логировать в продакшене, это три метрики: cache_read_tokens, cache_write_tokens, total_input_tokens. Формула фактической экономии по сравнению с полной оплатой input:

# Anthropic
saving_pct = (cache_read * 0.9 - cache_write * 0.25) / total_input * 100
# где 0.9 = 100% - 10% (скидка на read), 0.25 = наценка 25% на write (5min TTL)

# OpenAI
saving_pct = cached_tokens * 0.5 / total_input * 100

# Gemini (без учёта storage)
saving_pct = cached_tokens * 0.75 / total_input * 100

Целевой hit rate для окупаемости у Anthropic составляет 30% и выше (при 5-минутном TTL), у OpenAI — 40% (из-за меньшей скидки), у Gemini — 20–25% (плюс необходимо учитывать storage-фи). Все три провайдера отдают эти метрики в поле usage ответа, и правильный способ их агрегировать, это через систему LLM Observability на базе Langfuse или LangSmith. Оба инструмента из коробки поддерживают дашборды по cached-токенам для всех трёх провайдеров.

Практический чек-лист для алертов: (1) сигнал, если hit rate за час упал ниже 20% (обычно это означает, что кто-то поменял system-промпт или tools); (2) сигнал, если cache_write за сутки превысил cache_read в 3+ раза (вы платите за создание кеша, но не пользуетесь им); (3) еженедельный отчёт по разбивке экономии на топ-10 промпт-шаблонов, чтобы приоритизировать оптимизацию.

Когда prompt caching не работает: подводные камни

Первый и самый частый, слишком короткий префикс. Если ваши системные промпты меньше 1024 токенов, у OpenAI и Anthropic (Sonnet/Opus) кеш вообще не активируется, а у Gemini минимум ещё выше — 32 768 токенов для Pro. Решение: либо укрупнить system-инструкцию (добавить few-shot примеры), либо не пытаться выжать кеш из коротких промптов.

Второй, эффект TTL-обрыва в низком трафике. При 5-минутном TTL у Anthropic и OpenAI, если ваш агент используется реже раза в 5 минут, кеш каждый раз создаётся заново, и вы платите наценку 25% (Anthropic) вместо экономии. Для таких сценариев Anthropic выпустил extended cache на 1 час: стоимость записи 100% × 2, но окупается уже при 3–4 запросах в час.

Третий, несовместимость с некоторыми параметрами. У Anthropic prompt caching не работает с параметром logprobs и рядом beta-фич; у OpenAI batch API кеш применяется по-другому и не гарантирует hit; у Gemini кеш не создаётся, если модель попросили выдать response_schema, отличающийся от того, что был при создании CachedContent.

Четвёртый, region isolation. Кеш живёт в конкретном датацентре провайдера, и запросы, попавшие в другой регион (из-за балансировки), не пробьют его. У OpenAI это иногда проявляется как «случайные» падения hit rate, обходится через закрепление за конкретным endpoint. Пятый, приватность в enterprise. Клиенты с HIPAA/GDPR-требованиями должны проверить, что провайдер соблюдает изоляцию кеша между организациями (Anthropic и OpenAI это гарантируют контрактно; на публичных Gemini-квотах это требует явного включения VPC-конфигурации).

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

Сколько денег экономит prompt caching на практике?

Для типового чат-агента с 10–20K системного промпта экономия на input-токенах составляет 60–85% у Anthropic (скидка 90% на read), 40–60% у OpenAI (скидка 50%) и 50–70% у Gemini при hit rate выше 50%. На реальных продакшн-нагрузках итоговое снижение общего счёта за LLM в 2–5 раз, потому что input обычно составляет 70–90% всей стоимости.

Как долго хранится кеш промптов и можно ли им управлять?

По умолчанию TTL составляет 5 минут у Anthropic и OpenAI и 60 минут у Google Gemini. Anthropic позволяет продлить до 1 часа через параметр ttl="1h" (доплата за запись), Gemini до нескольких часов через настройку TTL в CachedContent (плата за хранение $1/M токенов в час). OpenAI не даёт явно управлять TTL, он динамически варьируется от 5 до 60 минут в зависимости от нагрузки.

Работает ли prompt caching с function calling и tool use?

Да, все три провайдера поддерживают кеширование блока tools/functions. У Anthropic ставьте cache_control на последний элемент массива tools; у OpenAI кеширование tools происходит автоматически как часть общего префикса; у Gemini tools передаются в объект CachedContent при создании. Критично: любое изменение описания или схемы любого инструмента полностью инвалидирует весь кеш префикса.

Что лучше, prompt caching или semantic caching через GPTCache?

Это ортогональные техники, решающие разные задачи. Prompt caching (нативный у провайдера) сохраняет KV-состояние на серверах модели и работает даже для уникальных пользовательских запросов, если у них общий префикс. Semantic caching (GPTCache, Redis-based) кеширует пары запрос→ответ по эмбеддинг-близости и полезен для FAQ-подобных сценариев с повторяющимися вопросами. В зрелой системе они комбинируются: сначала проверка semantic cache, при miss запрос к LLM с prompt caching.

Может ли кеш промптов из одной организации утечь в запросы другой?

Нет, все три провайдера изолируют кеш на уровне API-ключа/организации. Anthropic и OpenAI явно гарантируют это в контрактах Enterprise и в документации по безопасности; Google Gemini использует изоляцию на уровне проекта GCP. Тем не менее для HIPAA/GDPR/финсектор-нагрузок рекомендуется дополнительно проверить, что вы работаете с корректным endpoint (например, Anthropic AWS Bedrock, Azure OpenAI с приватным VPC) и что prompt caching поддерживается на выбранном тарифе.