Кеширование промпта: когда приём экономит, а когда нет
Если в каждом вашем запросе есть большой неизменный кусок — инструкция, справочник, описание схемы базы, свод правил, — вы оплачиваете его заново при каждом обращении. Кеширование решает ровно эту задачу: неизменная часть запоминается на стороне сервиса и при следующих обращениях считается по сниженной ставке.
Как это устроено
Механика простая: вы помечаете, где заканчивается стабильная часть запроса. Поддержка приёма есть не везде: у вендора она штатная, у посредников — по-разному, и у anthropic api через российский сервис это стоит проверить до того, как перестраивать запросы. Первое обращение стоит чуть дороже обычного — сервис не только обрабатывает запрос, но и записывает эту часть. Все последующие обращения, где начало запроса совпадает символ в символ, читают её из кеша.
Отсюда первое и главное ограничение: совпадать должно именно начало. Кеш работает по префиксу. Если стабильный кусок стоит в середине, а перед ним подставляется дата или имя пользователя, совпадения не будет никогда — и вы получите только наценку за первое обращение, повторяемую до бесконечности.
Второе ограничение — время жизни. Записанная часть хранится недолго: минуты, а не часы. Для потока запросов это несущественно, для трёх обращений в день — приём не работает вовсе, каждый запрос будет первым.
Когда экономия заметна
Разрыв между двумя кривыми растёт линейно, и это главный аргумент в пользу приёма. Чем больше стабильная часть и чем плотнее поток запросов, тем сильнее расходятся линии. На сотне обращений к одному справочнику разница перестаёт быть теоретической.
Полезно прикинуть порог заранее: если стабильная часть меньше нескольких сотен токенов, возиться не стоит — экономия утонет в накладных расходах и усложнении кода.
Типичные причины, по которым не сработало
Команды часто включают кеширование, смотрят в счёт и не видят разницы. Почти всегда причина в одном из четырёх.
В начале запроса стоит переменное значение. Текущее время, идентификатор сессии, случайный номер — любая мелочь в первых строках обнуляет совпадение. Лечится переносом переменных ближе к концу.
Справочник собирается из словаря заново при каждом запросе. Порядок ключей меняется, строка получается другая, префикс не совпадает. Лечится фиксацией порядка при сборке.
Запросы идут редко. Между обращениями проходит больше времени, чем живёт запись. Здесь помогает только изменение схемы работы — например, группировка задач.
Стабильная часть на самом деле не стабильна. Кто-то правит справочник по ходу дела, и каждая правка сбрасывает кеш. Если правки частые, приём даёт отрицательный эффект: вы платите наценку за запись чаще, чем читаете.
Как проверить, что кеш читается
Не на глаз и не по счёту за месяц. В ответе приходит разбивка расхода токенов, и в ней видно, сколько токенов записано в кеш и сколько прочитано из него. Если поле чтения стабильно равно нулю — приём не работает, и дальше надо искать причину, а не надеяться.
Полезно вывести эти два числа в собственные метрики рядом с обычным расходом. Тогда поломка префикса — например, после невинной правки в сборке запроса — будет видна в тот же день, а не в конце месяца.
Что стоит кешировать в первую очередь
По убыванию отдачи:
- Большой справочник или свод правил, общий для всех пользователей.
- Системную инструкцию, если она длиннее пары абзацев.
- Описание схемы данных или список доступных инструментов.
- Длинный документ, к которому задаётся серия вопросов подряд.
Четвёртый случай особенно нагляден: разбор одного договора на двадцать вопросов без кеша означает двадцать оплат за весь текст договора.
Сколько живёт запись
Время жизни у разных поставщиков отличается и обычно измеряется минутами. Это делает приём чувствительным к неравномерности потока: в час пик кеш читается почти всегда, ночью — почти никогда, и средняя экономия за сутки оказывается вдвое ниже расчётной.
Если поток неравномерный, считайте выгоду по пиковым часам, а не по суточному среднему — иначе легко разочароваться в работающем приёме.
Как перестроить запрос под кеш
Если приём не работает из-за порядка частей, запрос обычно можно переложить без потери смысла.
Общая схема: сначала неизменное, потом переменное. Системная инструкция, справочник, описание схемы, список инструментов — в начало. Дата, имя пользователя, идентификатор сессии, сам вопрос — в конец, в сообщение пользователя.
Проверить порядок проще всего так: сохраните собранные запросы за несколько обращений в файлы и сравните их построчно. Место, где они начинают расходиться, и есть граница кеша. Если расхождение начинается на третьей строке, кешировать нечего.
Отдельная ловушка — сериализация. Если справочник собирается из словаря и порядок ключей не зафиксирован, строка будет разной при каждом запуске процесса. Внешне запрос выглядит одинаково, а по символам — нет.
Кеш и несколько пользователей
Запись общая для ключа, а не для конкретного диалога. Это значит, что общий справочник, одинаковый для всех пользователей, кешируется один раз и работает на весь поток — самый выгодный случай из возможных.
Обратное тоже верно: если вы подставляете в начало запроса данные конкретного пользователя, кеш становится персональным и почти бесполезным. Персональные данные логичнее держать ближе к вопросу.
Здесь же стоит помнить про изоляцию. Не кладите в кешируемую часть ничего, что относится к одному клиенту, если сервис многопользовательский. Это вопрос не столько эффективности, сколько аккуратности в обращении с чужими данными.
Чего кеширование не делает
Оно не ускоряет генерацию ответа и почти не влияет на время до первого символа в коротких запросах. Оно не уменьшает выходные токены — а именно они обычно дороже. И оно не спасает плохо написанную инструкцию: дешёвая передача сорока противоречивых правил остаётся передачей сорока противоречивых правил.
Коротко
Кеш работает по неизменному началу запроса и живёт минуты. Экономия прямо пропорциональна размеру стабильной части и плотности потока обращений. Главная причина неудач — переменное значение в первых строках, которое ломает совпадение префикса. Проверять надо по разбивке токенов в ответе, а не по ощущению от счёта.