Кеширование промптов Оптимизация стоимости OpenAI API Claude API Gemini API

Кеширование промптов в OpenAI, Claude и Gemini

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

AveMujica API 15 июл. 2026 г. 9 мин чтения

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

Последняя проверка: 2026-07-15. Минимумы, TTL и множители цен по моделям меняются; сверяйтесь с привязанными страницами цен и кеширования каждого провайдера, прежде чем полагаться на конкретное число.

Единое правило для всех троих: кешируйте префикс, варьируйте суффикс

Каждый провайдер кеширует префикс промпта и сопоставляет по точным байтам. Практическое следствие идентично у всех вендоров: поместите части, которые остаются неизменными, первыми, а части, которые меняются, — последними. Системный промпт, few-shot-примеры, определения инструментов и большой справочный документ принадлежат наверху; текущий вопрос пользователя принадлежит внизу. Переставьте это — и вы сдвинете границу между «кешируемым» и «нет», а единственная ранняя правка — даже метка времени, вставленная в системное сообщение, — инвалидирует всё после неё. Это самое высокорычажное изменение, которое вы можете сделать, и оно бесплатно.

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

OpenAI: автоматически, по префиксу, с подсказкой через `prompt_cache_key`

Кеширование у OpenAI автоматическое — вы не подписываетесь на него. Кеширование включается автоматически для промптов длиной 1024 токена или больше, а сопоставление работает по префиксу промпта. Когда запрос переиспользует префикс, который уже закеширован, переиспользованные токены выставляются по сниженной ставке за закешированный вход и появляются в объекте использования как cached_tokens: под usage.prompt_tokens_details в Chat Completions и под usage.input_tokens_details в Responses API. Запросы ниже порога сообщают cached_tokens как ноль.

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

Удержание управляемо. Новые модели принимают prompt_cache_options с ttl (30 минут — поддерживаемое минимальное время жизни и значение по умолчанию), тогда как более ранние модели используют prompt_cache_retention, чьи записи в памяти обычно остаются активными несколько минут бездействия и могут быть продлены до 24 часов. На новейших моделях токены, записанные в кеш, сообщаются отдельно как cache_write_tokens и оцениваются в 1.25× от незакешированной ставки за вход; более старые модели не добавляют плату за запись. Шлюз пробрасывает prompt_cache_key и prompt_cache_retention напрямую к вышестоящей стороне, так что вы сохраняете те же ручки за одним базовым URL.

Anthropic: маркер `cache_control`, автоматический или явный

Anthropic кеширует только то, что охватывает маркер cache_control, но вам не обязательно вручную расставлять каждую точку. Есть два режима. Автоматическое кеширование добавляет одно поле cache_control на верхнем уровне запроса; система ставит точку останова на последнем кешируемом блоке и сдвигает её вперёд по мере роста беседы, что удобно для многоходовых чатов. Явные точки останова размещают cache_control прямо на отдельных блоках контента, чтобы точно контролировать, что кешируется. В примере ниже явная точка стоит на стабильном регламенте:

import anthropic
client = anthropic.Anthropic(base_url="https://your-gateway.example.com", api_key="AVE_GATEWAY_API_KEY")

client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system=[
        {"type": "text", "text": "You are a contract analyst."},
        {
            "type": "text",
            "text": LONG_STATIC_PLAYBOOK,        # the expensive, stable prefix
            "cache_control": {"type": "ephemeral"},
        },
    ],
    messages=[{"role": "user", "content": "Summarize the indemnity clause."}],
)

Вы можете определить до 4 точек останова кеша (автоматический маркер верхнего уровня занимает одну из четырёх), что позволяет кешировать секции, меняющиеся с разной частотой: редко редактируемый системный промпт за одной точкой, документ на сессию за другой. Минимальная кешируемая длина зависит от модели: многие текущие модели, включая Claude Opus 4.8 и Sonnet 5, начинают с 1 024 токенов, а некоторым уровням требуется 2 048 или 4 096. Промпт короче минимума молча обрабатывается без кеширования — без ошибки, просто без скидки.

Учёт использования явный, и его стоит читать внимательно. Ответы возвращают три отдельных счётчика: cache_creation_input_tokens (токены, записанные в новую запись кеша), cache_read_input_tokens (токены, обслуженные из кеша) и input_tokens (всё после последней точки останова). Общий вход — сумма всех трёх, и если оба счётчика кеша нулевые, ничего не закешировалось. Время жизни кеша по умолчанию — 5 минут, обновляемое бесплатно каждый раз, когда запись используется, так что активно попадаемый кеш фактически остаётся тёплым; опция "ttl": "1h" продлевает его при более высокой стоимости записи. Множители цен публичны: запись в 5-минутный кеш стоит 1.25× базового входа, запись на 1 час — 2×, а каждое чтение из кеша стоит 0.1× базового входа. Эта 10-кратная скидка на чтение — причина вообще заморачиваться.

Gemini: неявно по умолчанию, явно когда нужен контроль

По умолчанию у Google меньше всего работы: неявное кеширование включено автоматически для Gemini 2.5 и более новых моделей, а экономия передаётся автоматически, когда запрос попадает в кеш. Вы структурируете промпт с общим контентом первым, шлёте запросы с похожим префиксом близко по времени и читаете число закешированных токенов из метаданных использования. Минимумы применяются и здесь — текущие уровни Flash и Pro начинают кешировать от нескольких тысяч токенов, а новому поколению требуется больший префикс.

Когда вам нужны гарантированное кеширование и явный контроль времени жизни, API generateContent Gemini предлагает явное кеширование контекста через объект CachedContent: вы загружаете контент один раз, получаете хендл, задаёте TTL и ссылаетесь на хендл в последующих вызовах. Явное кеширование гарантирует скидку для контента, который вы точно будете переиспользовать (длинный PDF, видео, фиксированный набор инструкций), вместо того чтобы оставлять это на неявную эвристику. Число закешированных токенов всплывает в usageMetadata (как cachedContentTokenCount в generateContent), которое шлюз нормализует в то же поле закешированных токенов, что он сообщает для других провайдеров.

Что шлюз может и не может нормализовать

За одним OpenAI-совместимым эндпоинтом шлюз пробрасывает контролы кеширования, которые понимает каждый провайдер, и сворачивает разрозненные поля использования в единую форму учёта — cached_tokens для чтений плюс счётчики создания кеша, — поэтому закешированный запрос одинаково отображается в ваших журналах использования независимо от вышестоящей стороны. Шлюз также применяет собственные настраиваемые коэффициенты биллинга: коэффициент чтения из кеша, который выставляет счёт за закешированный вход ниже обычной ставки, и коэффициент создания кеша (по умолчанию 1.25×) для записей в кеш, опубликованные по каждой модели на открытой странице тарифов.

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

Управление не отображается один-к-одному. OpenAI кеширует по префиксу без понятия явных точек останова, тогда как Anthropic требует маркер cache_control — автоматический или до четырёх явных — и не имеет неявного префиксного кеша в стиле OpenAI; prompt_cache_key ничего не значит для Gemini. Проброс пересылает то, что поддерживает вышестоящая сторона, и игнорирует остальное.
Семантика TTL различается. ttl у OpenAI — минимальное время жизни, у Anthropic — фиксированное 5-минутное (или 1-часовое) окно, обновляемое при использовании, а явный TTL у Gemini задаётся на объект кеша. «Один час» не означает одно и то же у всех троих.
Словарь использования различается. Anthropic разделяет создание 5-минутного и 1-часового кеша; OpenAI разделяет чтение и запись только на новых моделях; Gemini сообщает единый счётчик закешированного контента. Шлюз отображает это в общие поля, но не может выдумать различие, которое провайдер никогда не сообщал.

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

Как заставить кеш реально срабатывать

Четыре привычки решают, помогает кеширование или тихо ничего не делает:

Выносите стабильный контент вперёд. Инструкции, инструменты и справочный материал первыми; ход пользователя последним. Это единственное правило, которое важнее всего.
Держите префикс байт-стабильным. Никаких меток времени, идентификаторов запросов или перетасованных порядков инструментов в закешированной области. Один изменённый байт в начале инвалидирует остальное.
Шлите связанные запросы близко по времени. Кеши истекают; пакетирование похожей работы в пределах окна TTL держит записи тёплыми. Простаивающий кеш — холодный кеш.
Проверяйте по использованию, а не по ощущениям. Подтвердите, что cached_tokens (или эквивалент провайдера) ненулевой, прежде чем заявлять об экономии. Кеширование, которое вы предполагаете, но никогда не измеряете, — частый источник воображаемых снижений стоимости.

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

FAQ

Снижает ли кеширование стоимость выходных токенов тоже?

Нет. Кеширование применяется только к входным токенам (промпту) — префиксу, который провайдер может переиспользовать. Выходные токены генерируются заново каждый вызов и выставляются по обычной ставке за выход независимо от состояния кеша. Если ваша стоимость доминируется долгими генерациями, а не долгими промптами, кеширование двигает не то число; смотрите на длину вывода и выбор модели.

Если счётчики чтения и записи кеша оба нулевые, кеширование провалилось?

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

Гарантировано ли попадание в кеш, если я повторно отправлю точно тот же префикс?

Нет. Кеши работают по принципу «наилучших усилий» и ограничены во времени. Записи истекают после своего TTL, и попадание также зависит от маршрутизации — вот почему OpenAI предоставляет prompt_cache_key, чтобы направлять связанные запросы на один бэкенд. Проектируйте под кеширование как оптимизацию, которая обычно помогает, а не как гарантию, на которую можно выставлять счёт.

Может ли один запрос через шлюз использовать кеширование OpenAI, Anthropic и Gemini взаимозаменяемо?

Вы можете отправлять контролы кеширования через один эндпоинт, но каждый понимается только собственной вышестоящей стороной: cache_control доходит до Anthropic, prompt_cache_key доходит до OpenAI, явный хендл CachedContent доходит до Gemini. Шлюз нормализует сообщаемое использование в общие поля; он не может заставить одного провайдера чтить директиву кеширования другого.

Измерьте реальное «до» и «после»

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