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

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

Как это работает

Механизм проще, чем кажется по описаниям вендоров.

Когда модель получает запрос, она обрабатывает его целиком. Эта обработка — самая дорогая часть работы с длинным контекстом. Если следующий запрос начинается точно так же, результат обработки общего начала можно переиспользовать вместо того, чтобы считать заново.

Отсюда три свойства, из которых следует всё остальное.

Кэшируется только начало. Совпадение считается от первого символа. Если общая часть в середине запроса, а начало разное, кэш не сработает.

Совпадение должно быть точным. Не «примерно то же», а буквально те же токены. Изменение одного слова в начале обнуляет совпадение для всего остального.

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

Сколько это экономит

Цифры различаются между вендорами, но порядок стоит представлять.

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

Пример из свежего: у Anthropic в Fable 5.1 чтение из кэша подешевело вчетверо относительно предыдущей версии, при том что вход и выход остались прежними. Запись не менялась — то есть вся выгода сосредоточена в перечитывании одного и того же.

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

Когда он окупается

Три сценария, где эффект заметен.

Длинный системный промпт при большом потоке запросов. Правила, примеры, описание предметной области — всё это уходит в модель при каждом обращении и не меняется. Идеальный кандидат.

Много вопросов по одному документу. Договор загружен один раз, дальше по нему задают двадцать вопросов. Без кэша документ оплачивается двадцать раз.

Агент с постоянной частью контекста. Описания инструментов и исходная задача не меняются между шагами, а история дописывается в конец — как устроен агентский цикл.

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

Почему кэш не срабатывает

Пять причин, и первая покрывает большинство случаев.

В начало подставляется что-то меняющееся. Текущая дата, время, идентификатор запроса, имя пользователя. Классика: строка «Сегодня 3 сентября 2026 года» в первой строке системного промпта убивает кэш каждые сутки, а с временем — каждую секунду.

Блоки переставляются местами. Если ваш код собирает промпт из частей в произвольном порядке, совпадения не будет.

Общая часть не в начале. Документ подставляется после вопроса пользователя вместо того, чтобы стоять первым.

Кэш истёк. Между запросами прошло слишком много времени.

Слишком короткая общая часть. У вендоров обычно есть минимальный размер, ниже которого кэширование не включается.

Отсюда правило проектирования: всё неизменное — в начало, всё меняющееся — в конец. Это одна перестановка блоков, и она определяет, работает кэш или нет.

Как проверить, что он работает

Без проверки легко считать, что экономия идёт, когда её нет.

Вендоры, поддерживающие кэш, обычно возвращают в ответе разбивку: сколько токенов прочитано из кэша, сколько записано, сколько обработано обычным путём. Смотреть надо именно на эти поля, а не на общий счёт.

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

Заведите привычку логировать эти поля рядом с обычным расходом — что писать в логи. Без них разговор об экономии превращается в предположения.

Чего кэш не даёт

Разграничение, из-за которого возникают завышенные ожидания.

Это не память. Модель по-прежнему ничего не помнит между запросами: кэшируется результат обработки текста, а не содержание разговора. Историю всё равно надо отправлять.

Он не ускоряет генерацию. Экономится обработка входа, а выход генерируется по-прежнему по одному токену.

Он не влияет на выходную часть счёта. Скидка касается только входа. Если у вас длинные ответы, кэш их не удешевит — почему выход бывает дороже входа.

Он не отменяет пределов контекста. Кэшированная часть занимает место в окне так же, как обычная.

Как у нас

Скажем прямо, без обхода.

В каталоге KeyDealer кэша промптов нет. Скидки за повторный контекст не существует, ставка одна и не зависит от того, повторяется ли начало запроса.

Проверяется это прямо в выдаче: у каждой текстовой позиции есть поле prompt_cache со status: unsupported и текстовой оговоркой рядом. На 4 сентября 2026 года она сформулирована так: попадания в кэш возможны, но кэшированный вход и запись в кэш тарифицируются по обычной входной ставке, пока не опубликована проверенная скидка. То есть выигрыш, если он где-то и происходит технически, в цену не переносится — и мы говорим об этом прямо, а не умалчиваем.

Что это значит на практике:

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

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

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

Как считать сравнение честно

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

1. Определите долю неизменной части. Какой процент типичного запроса не меняется между обращениями.
2. Посчитайте частоту повторов. Сколько раз одна и та же неизменная часть отправляется за час.
3. Прикиньте счёт по трёхпозиционному прайсу. Запись один раз, чтения — по числу повторов, остальное по обычной ставке.
4. Сравните с одноставочной схемой. Весь объём по одной цене.
5. Проверьте, устойчива ли неизменность. Если ваш промпт правят раз в неделю, кэш будет перезаписываться, и экономия окажется меньше расчётной.

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

Как собрать промпт под кэш

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

Правильная последовательность — от самого стабильного к самому изменчивому:

1. Системные правила и тон — меняются раз в месяц.
2. Описания инструментов и схемы — меняются с релизами.
3. Справочные материалы, общие для всех запросов.
4. Найденные под конкретный запрос фрагменты.
5. История диалога.
6. Текущий вопрос пользователя.

Всё, что выше линии между третьим и четвёртым пунктом, — кандидат в кэш. Всё ниже — меняется каждый раз.

Три правила, которые к этому прилагаются:

Никаких меток времени в верхней части. Если модели нужна текущая дата, её место — рядом с вопросом, а не в первой строке правил.

Стабильный порядок сборки. Если код собирает блоки из словаря, порядок должен быть зафиксирован явно, а не зависеть от порядка ключей.

Правка промпта — это сброс кэша. Планируйте изменения пакетами, а не по одному правилу в день: каждая правка обнуляет накопленную экономию и требует новой записи.

Чего мы не утверждаем

Не приводим прайсы вендоров. Они меняются; смотрите на их страницах.

Не обещаем, что кэш есть у конкретной модели. Поддержка различается между вендорами и версиями.

Не утверждаем, что схема без кэша лучше. Она проще в расчёте и хуже на профилях с большим повторяющимся контекстом.

Что держать в голове

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

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

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Посмотреть ставки по всем позициям можно без регистрации: keydealer.ru/login.