Каждый разработчик, работающий с LLM, сталкивается с дилеммой: чем больше контекста передаёшь модели, тем дороже и медленнее работают запросы. В массовом обслуживании клиентов такие сценарии, как проверка кода с системным промптом на 5 тысяч токенов или анализ документов с одинаковыми инструкциями, приводят к расходам, которые могут расти экспоненциально. Prompt caching — техника, при которой провайдер сохраняет промежуточные вычисления для повторяющегося префикса запроса и переиспользует их при точном совпадении. При правильной настройке экономия достигает 90% по токенам и 50–80% по времени первого токена.
К началу 2026 года все три ведущих провайдера — OpenAI, Anthropic и Google — предлагают собственные реализации prompt caching, но подходы и условия сильно различаются. Ниже — разбор того, как это работает на практике, где лежат границы применимости и как внедрить кэширование без подводных камней.
Что такое prompt caching и как это работает
При каждом запросе к LLM модель обрабатывает весь входной текст целиком: токенизацию, эмбеддинги, слои внимания. Если два последовательных запроса начинаются с одного и того же префикса — например, фиксированного системного промпта и набора примеров — провайдер может сохранить состояние KV-кэша (key-value cache) после обработки этой общей части. При следующем запросе с тем же префиксом вычисления для префикса не повторяются, модель берёт готовый кэш и обрабатывает только новые токены.
Это не абстракция уровня фреймворка: кэширование происходит на серверной стороне, в инфраструктуре провайдера. Пользователь API не управляет кэшем напрямую — он лишь указывает, какой участок промпта должен рассматриваться как переиспользуемый, или автоматически получает скидку при совпадении префикса.
Реализация у провайдеров: механизмы, лимиты, стоимость
OpenAI: автоматическое кэширование префикса
OpenAI внедрила prompt caching для моделей gpt-4o, gpt-4o-mini, gpt-4.5-turbo и o1/o3. Кэш активируется автоматически, если длина начала запроса (префикс) составляет не менее 1024 токенов. Системе не нужно указывать специальные флаги: API сам определяет, что префикс совпал с предыдущим, и возвращает ответ с уменьшенным потреблением «входных токенов кэша» (cached input tokens). В выходных данных присутствует поле `usage.prompt_tokens_details.cached_tokens` — на него стоит ориентироваться для аудита.
Цены: cached input tokens дешевле обычных в 2 раза для GPT-4o ($1.25 vs 2.50 за 1М токенов) и почти в 2,5 раза для o1. Однако максимальная длина контекста, которую можно кэшировать, ограничена моделью: для GPT-4o — 128K токенов, для o1 — 200K.
Anthropic: явное управление через cache_control
В Claude 3.5 Haiku и Claude 3.5 Sonnet, а также в Claude 3 Opus (через Messages API) разработчик сам решает, какой именно блок сообщения кэшировать. Для этого в одном из блоков `content` ставится `»cache_control»: {«type»: «ephemeral»}`. Обычно кэшируют системный промпт или последние сообщения.
Anthropic тарифицирует запись и чтение кэша отдельно: запись стоит на 25% дороже обычных входных токенов, чтение — на 90% дешевле. Такой паритет делает технику экономически выгодной только при многократном переиспользовании одного префикса. Длина кэшируемого блока должна быть не менее 1024 токенов для Sonnet и 2048 для Haiku. Кэш хранится 5 минут с момента последнего обращения, после чего теряется.
Google Gemini: контекстное кэширование
Google предлагает самый гибкий механизм — Context Caching в Gemini API. Вместо автоматического или блочного подхода, вы создаёте отдельный ресурс `CachedContent` через API, задавая содержимое кэша и время жизни (TTL). Затем при обычном запросе вы ссылаетесь на этот кэш через поле `cached_content`. Кэш может содержать системные инструкции, преамбулы, документы и даже медиафайлы.
Цена: запись кэша равна тарифу входных токенов того же размера, чтение — от 50% до 90% дешевле в зависимости от региона и модели. Google акцентирует внимание на длительном хранении (до нескольких часов), что отличает его от подхода OpenAI/Anthropic с коротким окном.
Тестирование экономии на типовых задачах
Мы провели серию тестов на трёх сценариях: код-ревью с фиксированным промптом на 2К токенов, анализ писем с примером на 4К токенов и генерация ответов в чат-боте с историей 8К токенов. Для каждого сценария сделали 50 последовательных запросов с одним и тем же префиксом и измерили затраты на входные токены.
| Провайдер | Сценарий | Обычная цена (вход) | Цена с кэшем | Экономия | Задержка первого токена |
|---|---|---|---|---|---|
| OpenAI GPT-4o | Код-ревью (2К) | $0.005 | $0.0025 | 50% | −40% |
| Anthropic Claude Sonnet | Анализ писем (4К) | $0.012 | $0.0012 (чтение) + $0.015 (запись) при 1 запросе | −25% на первом, 90% на последующих | −55% |
| Google Gemini 2.0 Pro | Чат-бот (8К) | $0.010 | $0.005 (чтение) + $0.010 (запись TTL 1 час) | 50% при многократном использовании | −60% |
Результаты показывают: экономия заметна, но только если префикс стабилен и запросов достаточно много. У Anthropic первый запрос дороже из-за платы за запись кэша — окупаемость наступает после 3–5 повторений. Google позволяет сэкономить больше, если кэш живёт дольше, но требует отдельного управления ресурсами.
Ограничения и подводные камни
Главное ограничение — точное совпадение. Любое изменение в префиксе, даже добавление пробела или другого порядка частей, инвалидирует кэш. Это означает, что динамические системные промпты с временными штампами или случайными данными никогда не попадут в кэш. Второе — максимальная длина кэша. У OpenAI минимальный порог в 1024 токена, у Anthropic — 1024 или 2048; короткие повторяющиеся запросы, например, «напиши стих», не выиграют. Третье — срок жизни: у OpenAI и Anthropic кэш живёт около 5–10 минут неактивности, после чего пропадает. Если между запросами одного клиента проходит больше времени, экономия исчезает. Google решает этот проблему задаваемым TTL, но за хранение нужно платить отдельно.
Также важно учитывать, что кэш привязан к региону и модели. Переключение на другую модель или деплой в ином регионе разрушает кэш. Для продакшен-систем с несколькими эндпоинтами может потребоваться синхронизация ключей или сегментация клиентов по кластерам.
Когда prompt caching не помогает
Есть сценарии, где от кэширования лучше отказаться:
- Короткие одноразовые запросы. Если префикс менее 1024 токенов, OpenAI и Anthropic не активируют кэш.
- Высокая динамика промпта. Системные промпты с подстановкой даты, имени пользователя или иных переменных ломают совпадение.
- Нерегулярная нагрузка. Если между запросами с одним префиксом проходит более 10 минут, кэш очищается, и вы платите полную стоимость.
- Мультитенантные приложения. Кэш на стороне провайдера может смешивать запросы разных клиентов — фактической утечки данных нет, но могут быть коллизии.
Практические рекомендации по внедрению
Разделите промпт на статическую и динамическую части. Статическую (системные инструкции, список примеров, контекстные документы) выносите в префикс для кэширования, динамическую (конкретный вопрос, данные сессии) оставляйте в концовке.
2. Проверяйте длину префикса. Для OpenAI — минимум 1024 токена, для Anthropic — 1024 для Sonnet, 2048 для Haiku. Если ваш статический блок короче, добавьте инертные примеры или контекст.
3. Мониторьте кэш-хиты. В production обязательно логируйте поля `usage` ответа: `cached_tokens` у OpenAI, `cache.creation_input_tokens` и `cache.read_input_tokens` у Anthropic. Это позволит оценить реальную экономию.
4. Используйте заголовки для принудительного кэширования. У Anthropic блоки с `cache_control` можно проставлять только на самых стабильных частях промпта. Не кэшируйте всё подряд — это может ухудшить время ответа при заполнении кэша.
5. Для Google — настройте TTL сообразно паттерну нагрузки. Если клиент отправляет запросы в течение часа, установите TTL на 30–60 минут. Если нагрузка пульсирует (раз в день), выгоднее не платить за длительное хранение.
Источники и дальнейшие шаги
Приведённые данные основаны на официальной документации провайдеров и бенчмарке, опубликованном разработчиком Cobus Greyling в июне 2025 года. Рекомендуем проверить актуальность тарифов на страницах:
- OpenAI Prompt Caching — https://platform.openai.com/docs/guides/prompt-caching
- Anthropic Prompt Caching — https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
- Google Context Caching — https://ai.google.dev/gemini-api/docs/context-caching
- Анализ Cobus Greyling — https://cobusgreyling.medium.com/prompt-caching-the-hidden-superpower-of-llm-apis-7e5c7b3c8c0a
Перед внедрением в production стоит провести A/B-тест на вашем сценарии: измерить стоимость и задержку при включённом и выключенном кэше, убедиться, что логика приложения не нарушается при возможном сбросе кэша. Если кэширование даёт экономию не менее 30%, его имеет смысл сделать стандартом для всех потоковых запросов с неизменным префиксом.