Кэширование промптов: как срезать счёт за агентов вдвое

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

OpenAI, Anthropic и Google к 2024–2025 году выкатили механики кэширования, но устроены они по-разному: где-то скидка включается сама и требует только правильного порядка токенов, где-то её нужно объявлять вручную и следить за временем жизни кэша. Ошибка в структуре промпта — и вы платите полную цену, даже думая, что экономите.

Что вообще кэшируется

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

В агентных пайплайнах стабильного много: системная инструкция, описания доступных инструментов¹, справочные документы, few-shot примеры. Это как раз то, что тянется через всю сессию без изменений. А переменная часть — новое сообщение пользователя или результат вызова инструмента — приписывается в хвост.

Кэш работает по префиксу. Поменяли один символ в начале системного промпта — и весь кэш ниже этой точки сгорает. Порядок токенов важнее их количества.

Три подхода: авто, ручной и гибридный

У крупных провайдеров кэширование включается по-разному, и от этого зависит, сколько кода вам придётся написать.

OpenAI: автоматически по префиксу

У OpenAI prompt caching для длинных промптов включается автоматически на моделях, где он поддерживается, — специальных полей в запросе объявлять не нужно. Система сама находит совпадающий префикс. Кэшированные входные токены тарифицируются со скидкой относительно обычной входной цены. Точные проценты скидки и минимальную длину префикса, с которой кэш вообще срабатывает, сверяйте на актуальной странице цен OpenAI — они менялись.

Anthropic: явные точки останова

У Anthropic (модели Claude) кэширование объявляется вручную: вы помечаете блоки контента атрибутом cache_control и тем самым ставите «точки останова» кэша. Запись в кэш стоит дороже обычного входного токена (наценка за создание кэша), а чтение из кэша — заметно дешевле. Есть время жизни записи; по умолчанию оно короткое, но доступна и продлённая опция за отдельную цену. Конкретные множители и TTL уточняйте в документации Anthropic.

Google Gemini: контекстный кэш как объект

У Google в Gemini API кэширование оформлено как отдельная сущность — context caching: вы создаёте объект кэша с контентом и TTL, получаете идентификатор и ссылаетесь на него в последующих запросах. Оплата складывается из хранения кэша (за время жизни) и сниженной цены за использованные из него токены. Это удобно, когда один большой корпус — документация, кодовая база — переиспользуется многими запросами.

Сравнение механик

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

Как перестроить пайплайн под кэш

Кэширование не включается «галочкой» — его нужно заложить в архитектуру промпта. Порядок действий примерно такой:

1. Разложите промпт на слои от самого стабильного к самому изменчивому: системная инструкция → описания инструментов → справочные документы → история диалога → текущий ввод.
2. Убедитесь, что стабильные слои не меняются между вызовами ни на символ — включая пробелы, метки времени и случайные идентификаторы.
3. Для Anthropic расставьте cache_control на границах стабильных блоков; для Gemini создайте объект кэша под большой общий корпус; для OpenAI просто держите префикс неизменным.
4. Уберите из начала промпта всё, что содержит текущее время, счётчики и рандом — эти вставки убивают совпадение префикса.
5. Замерьте: провайдеры возвращают в ответе поля с числом кэшированных и некэшированных входных токенов. Если кэшированных нулей — префикс где-то ломается.

Кому это пригодится, а кому нет

Пригодится:

• Агенты с длинным системным промптом и десятками описаний инструментов, которые дёргают модель много раз за сессию.
• Чат-ассистенты поверх большой документации или базы знаний, где один и тот же корпус подставляется в каждый запрос.
• Пайплайны с многошаговым рассуждением, где история диалога растёт, но начало остаётся стабильным.
• Пакетная обработка однотипных запросов с общим большим контекстом — тут особенно выигрывает Gemini с объектом кэша.

Не даст эффекта:

• Редкие одиночные запросы: кэш успевает протухнуть между вызовами, а у Anthropic вы ещё и переплатите за запись, которой никто не воспользуется.
• Короткие промпты ниже минимальной длины срабатывания кэша — экономить попросту не на чем.
• Пайплайны, где начало промпта каждый раз разное (персонализация в первом абзаце, динамические инструкции) — совпадения префикса не будет.
• Сценарии с меткой времени или уникальным ID в шапке запроса, пока вы их оттуда не уберёте.

Подводные камни

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

Вторая — TTL. Кэш живёт недолго. Если между шагами агента проходит больше времени жизни записи (ожидание внешнего API, действие пользователя), кэш истекает, и следующий вызов идёт по полной цене. Для медленных пайплайнов продлённый TTL может окупиться, для быстрых — нет.

Третья — у Anthropic запись в кэш дороже обычного токена. Если блок кэшируется, но переиспользуется всего раз-два, вы уходите в минус по сравнению с отсутствием кэша. Кэшировать имеет смысл то, что прочитают многократно.

¹ Описание инструментов (tool definitions) — структурированный список функций, которые агент может вызвать: имя, назначение и схема параметров. Модель читает эти описания в каждом запросе, чтобы решить, какой инструмент дёрнуть, поэтому они и составляют львиную долю стабильного, кэшируемого контекста.