Кэширование промптов: как снизить расходы на API

Если вы платите за обращения к языковой модели по токенам, скорее всего значительная часть счёта уходит на одно и то же. Системная инструкция, описание инструментов, примеры для few-shot, большой документ из базы знаний — этот «префикс» уезжает в модель почти в каждом запросе без изменений, и вы оплачиваете его снова и снова. Кэширование промптов (prompt caching) как раз решает эту проблему: провайдер запоминает уже обработанную часть промпта и при повторном запросе берёт её из кэша по цене в несколько раз ниже обычной. На типичных сценариях это снижает расходы на входные токены на 50–90%, а заодно ускоряет ответ. Разберёмся, как это устроено у Anthropic, OpenAI и Google и как перестроить промпты, чтобы кэш действительно срабатывал.

Почему повторный контекст стоит денег

Языковая модель тарифицируется отдельно за входные (то, что вы отправляете) и выходные (то, что она генерирует) токены. Проблема в том, что входная часть в реальных приложениях редко бывает маленькой. Чат-бот поддержки тащит с собой инструкцию на пару тысяч токенов и десяток примеров. AI-агент передаёт описания всех доступных инструментов. RAG-приложение подкладывает в контекст найденные фрагменты документов. Всё это — статический «фундамент», который меняется редко, а оплачивается в каждом запросе диалога.

Внутри модели обработка входных токенов — это тяжёлый этап: значения внутренних представлений (так называемый KV-кэш) вычисляются для каждого токена префикса. Идея кэширования проста: если начало промпта в точности совпадает с тем, что уже считали недавно, эти вычисления можно не повторять, а результат — переиспользовать. Провайдер экономит вычисления и делится этой экономией с вами через сниженную цену на кэшированные токены.

Ключевое правило: кэшируется только префикс

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

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

Anthropic Claude: явное кэширование через cache_control

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

Экономика у Anthropic устроена так. Первая запись в кэш стоит дороже обычного входного токена: коэффициент 1,25× для стандартного времени жизни и 2× для расширенного. Зато последующее чтение из кэша обходится всего в 0,1× от базовой цены — то есть на 90% дешевле. Стандартное время жизни кэша (TTL) — 5 минут и обновляется при каждом обращении; при необходимости его можно продлить до 1 часа. Есть и порог: кэшировать имеет смысл достаточно длинные блоки — например, для актуальных моделей Sonnet минимум составляет 1024 токена, у части моделей — 2048 или 4096. Более короткий блок система просто не станет кэшировать.

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

OpenAI: кэширование включено само

У OpenAI подход противоположный — кэширование автоматическое. Никаких маркеров расставлять не нужно: система сама распознаёт повторяющиеся префиксы (системный промпт, определения инструментов, общий контекст) и применяет скидку. Кэшированные входные токены тарифицируются существенно дешевле обычных — в зависимости от модели скидка составляет от примерно половины до 90% от базовой цены входа, а на новых моделях повторный префикс биллится всего по 10% ставки. Записи в кэш при этом, как правило, не создают отдельной наценки.

Кэш срабатывает автоматически для достаточно длинных запросов (ориентир — от 1024 токенов и выше, дальше — с шагом), а сохраняется недолго: обычно несколько минут неактивности, в спокойные часы — дольше. Поскольку управлять этим напрямую нельзя, вся оптимизация сводится к дисциплине структуры: держите стабильную часть промпта неизменной и в самом начале, а всё динамическое выносите в конец. Тогда автоматика будет попадать в кэш максимально часто.

Google Gemini: неявный и явный кэш

У Gemini есть оба режима. Неявное (implicit) кэширование включено по умолчанию для моделей поколения 2.5 и новее и работает похоже на OpenAI: система сама находит повторяющийся префикс и автоматически передаёт экономию — порядка 75% на кэшированных токенах. От вас требуется всё то же — стабильный контент в начале запроса.

Второй режим — явное (explicit) кэширование: вы заранее создаёте объект кэша из большого контекста (например, объёмный документ или свод правил), получаете на него ссылку и переиспользуете в запросах. Здесь скидка на чтение гарантирована, но есть нюанс — за хранение кэша берётся отдельная плата за время его жизни, а TTL вы задаёте сами. Поэтому явный кэш выгоден, когда один и тот же большой контекст нужен многократно в течение известного отрезка времени; если обращений мало, плата за хранение может съесть выгоду. Пороги минимального размера у Gemini тоже зависят от модели — примерно от 1–2 тысяч токенов и выше.

Что стоит кэшировать в первую очередь

Наибольшую отдачу дают самые крупные и самые стабильные блоки. В типичном приложении это: системная инструкция и правила поведения; описания инструментов (function calling) у агентов; наборы примеров для few-shot; большие справочные документы, регламенты, схемы БД; и найденный контекст в RAG, если он переиспользуется между запросами. Если вы строите ассистента поверх собственных данных, загляните в наш разбор что такое RAG простыми словами — кэширование хорошо ложится на статическую часть такого пайплайна.

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

Типичные ошибки, из-за которых кэш не работает

Первая и самая частая — переменные в начале промпта. Дата со временем, имя клиента, случайный идентификатор в системной инструкции обнуляют кэш при каждом обращении. Вторая — незаметное изменение стабильной части: правка одного слова в системном промпте, другой порядок инструментов, лишний пробел. Совпадение требуется точное, поэтому даже мелочь сбрасывает кэш. Третья — слишком короткие блоки: если префикс не дотягивает до минимального порога модели, кэширование просто не включится. Четвёртая — большие паузы: если между запросами прошло больше TTL, запись уже вытеснена, и следующий запрос снова платит полную цену (а у Claude ещё и по повышенному тарифу записи).

Когда это реально окупается

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

Практический порядок действий такой: посмотрите, какая доля промпта повторяется от запроса к запросу; вынесите всё стабильное в начало, а динамику — в конец; у Claude расставьте cache_control на крупных блоках, у OpenAI и Gemini просто не трогайте порядок; затем сверьте по счетам, что доля кэшированных токенов растёт. Кэширование — один из самых дешёвых способов снизить расходы: оно не требует менять модель или ужимать качество, только аккуратнее собрать промпт. Если хотите комплексно поработать над стоимостью, полезно параллельно освежить базовые приёмы из заметки о практическом промпт-инжиниринге и сверить тарифы разных провайдеров в нашем сравнении API Gemini, Claude и OpenAI.