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

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

Счет растет не только из-за длинных ответов. Часто деньги уходят на входе, когда приложение снова и снова отправляет один и тот же большой кусок текста: роль модели, правила ответа, JSON-формат, примеры, политику безопасности и фрагменты базы знаний.

Для API каждый такой запрос новый. Если вы 10 000 раз отправили один и тот же system prompt на 2 000 токенов, модель 10 000 раз получила и обработала эти 2 000 токенов. Для биллинга это не "тот же текст", а 20 млн входных токенов.

Это особенно заметно там, где вопрос пользователя короткий. Человек пишет: "Статус заказа?" или "Сделай сводку". Снаружи запрос выглядит маленьким. Но внутри к нему часто добавлен длинный служебный пролог, и именно он съедает большую часть бюджета.

Где прячутся расходы

Обычно счет раздувают четыре вещи: длинный system prompt с ролью и ограничениями, few-shot примеры в каждом вызове, повторяющиеся инструкции по формату ответа и один и тот же контекст, который пересылают между сессиями и задачами.

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

Представьте бота поддержки. Вопрос клиента занимает 8-15 токенов. Ответ модели - около 120 токенов. Зато system prompt, правила тона, список запрещенных действий и схема ответа тянут на 2 500 токенов. В такой схеме вы платите в основном не за "умный ответ", а за постоянную пересылку одних и тех же инструкций.

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

Если провайдер ускоряет обработку, но не снижает цену на cached input, вы выигрываете во времени, а не в счете. Если скидка есть, но ответы остаются длинными, кэш уменьшает только входные расходы. Выходные токены, вызовы инструментов и лишние повторы в ответах он сам по себе не исправит.

Когда кэш срабатывает

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

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

Полное совпадение и общий префикс

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

Но на практике чаще помогает не полное совпадение, а общий префикс. Это значит, что первые, например, 1 000-2 000 токенов у запросов одинаковые, а меняется только хвост. Так бывает в поддержке, когда команда держит длинную инструкцию для бота, а в конце подставляет новый вопрос клиента.

В простом сценарии первые 1 500 токенов - это роль, правила, справка и формат ответа, а последние 100 токенов - новый вопрос пользователя. Здесь кэш экономит деньги именно на общей начальной части. Ответ при этом не портится, потому что модель все равно видит новый хвост и строит ответ заново.

Что чаще всего ломает попадание в кэш

Мелкие вставки ломают повторяемость сильнее, чем кажется. Особенно если они появляются в начале запроса, а не в конце.

Обычно мешают такие детали:

• текущая дата и время в первой строке
• случайный request id
• имя пользователя внутри системной инструкции
• перестановка одинаковых по смыслу блоков
• лишний пробел, перевод строки или другой формат JSON

Если команда меняет модель или провайдера, кэш тоже часто обнуляется. Одна и та же инструкция, отправленная через OpenAI и через другую модель у другого провайдера, не даст того же результата. В шлюзе вроде AI Router это тоже важно учитывать: единый API упрощает маршрутизацию, но сам кэш все равно зависит от конкретной модели и от того, как она обрабатывает префикс.

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

Как посчитать это на своих данных

Берите логи за 1-2 недели, а не за один удачный день. Иначе легко поймать случайный всплеск и решить, что кэш выгоден всегда, хотя в обычные дни картина совсем другая.

Смотрите не только на полный запрос, но и на его части. Обычно повторяется не весь промпт, а длинная статичная основа: system prompt, правила, описание роли, шаблон ответа, инструкции по формату и фрагменты RAG-контекста.

Удобно делить каждый запрос на несколько элементов:

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

Дальше считайте повторы не "в среднем по системе", а по маршрутам. Один и тот же шаблон может часто встречаться на дешевой модели и почти не повторяться на дорогой. Если смешать все вместе, цифра получится красивой, но бесполезной.

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

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

Небольшой пример помогает не ошибиться. Допустим, в среднем запросе 1 000 входных токенов, из них 700 токенов - стабильный шаблон. Если этот шаблон повторяется в 35% вызовов, а чтение из кэша стоит заметно дешевле обычного входа, экономия уже видна. Но счет снизится не на 35%, а примерно на 700 x 35% от входной части, минус плата за запись и чтение.

Как проверить без большого риска

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

Запустите A/B-проверку на несколько дней. Сравните среднюю цену запроса, долю попаданий в кэш и качество ответа. Если счет падает, а ответы не меняются по точности и формату, можно масштабировать дальше. Если доля попаданий низкая, проблема обычно не в самом кэше, а в том, что вы кэшируете слишком переменную часть промпта.

С каких порогов экономия становится заметной

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

Повторы на уровне 5-10% обычно почти не видны в деньгах. Это типичная картина для коротких чатов, где общий префикс занимает 30-80 токенов, а остальное меняется от запроса к запросу. Даже если кэш иногда срабатывает, он экономит слишком мало токенов, чтобы месячный счет заметно просел.

Ниже - грубый ориентир, от которого уже можно отталкиваться:

• 5-10% повторов - экономия чаще всего слабая, иногда в пределах погрешности
• 20-30% - эффект уже заметен, если общий префикс длинный, хотя бы 300-500 токенов
• 40-60% - кэш обычно уже стоит включать и считать всерьез
• выше 70% - это часто один из самых простых способов снизить затраты без потери качества

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

Практическое правило такое: при повторяемости 20-30% кэш уже стоит тестировать, если совпадающая часть длиннее примерно трети всего входа. При 40-60% он почти всегда окупается на длинных шаблонах. Если повторы выше 70%, заметную экономию часто дает даже средний по длине префикс.

Короткий чат и длинная инструкция ведут себя по-разному. В коротком чате вы можете сэкономить 20-40 токенов на запрос и почти не увидеть разницу в счете. В длинной инструкции экономия легко доходит до сотен, а иногда и тысяч токенов на один вызов. Поэтому один и тот же процент повторов нельзя оценивать без длины префикса.

Есть еще одна оговорка: провайдеры считают кэш по-разному. У одних выше скидка на cached input, у других строже правила совпадения, срок жизни кэша или набор поддерживаемых моделей. Поэтому смотреть нужно не на абстрактный порог, а на фактическую цену токена и реальную долю попаданий в логах. Коротко: 5-10% редко радуют, 20-30% уже интересно, 40% и выше обычно дают эффект, который видно в отчете по расходам.

Пример на простом сценарии

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

В каждом запросе повторяются три блока: системная инструкция на 700 токенов, правила возврата и доставки на 500 токенов, а также формат ответа и JSON-схема на 250 токенов. Итого 1 450 токенов почти всегда одинаковы. Меняется только короткая часть: сообщение клиента, номер заказа, город и несколько полей из CRM. Обычно это еще 100-150 токенов.

Допустим, поддержка отправляет 20 000 запросов в месяц. Средний запрос без кэша - 1 570 входных токенов. Это 31,4 млн входных токенов в месяц.

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

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

Но тот же прием почти не помогает в другом сценарии. Если оператор каждый раз подставляет длинную историю диалога, свежую карточку клиента, список прошлых заказов и заметки менеджера, повторяющаяся часть сжимается, скажем, до 200-300 токенов. Остальные 1 500-2 000 токенов уникальны. Тогда скидка есть, но в общем счете она почти теряется.

На практике разница видна быстро. Если у вас повторяется длинный префикс, кэш заметен уже в первом месяце. Если повторяется только короткая шапка вроде "Ты помощник службы поддержки", эффект обычно слишком мал, чтобы ради него менять логику запросов.

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

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

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

Лучше делить запрос на две части. Первая часть стабильная: системная инструкция, общий стиль, правила безопасности, длинное описание продукта или процесса. Вторая часть живая: вопрос пользователя, свежие данные, ID, суммы, сроки и личные данные.

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

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

Сбрасывать кэш нужно сразу после смены правил, схемы ответа или модели. Это частая ловушка: команда меняет модель через тот же API-шлюз, а кэш остается прежним. Если вы переключили модель в AI Router или обновили внутренние правила, старые записи могут давать уже не тот результат.

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

Проверка на свежих примерах нужна всегда. Возьмите 20-30 недавних запросов, прогоните их с кэшем и без него, а потом сравните ответы. Смотрите не только на стоимость. Важно проверить, не пропали ли свежие детали, не стал ли ответ слишком общим и не сломался ли формат.

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

Частые ошибки

Самая частая ошибка проста: команды кэшируют все подряд, даже очень короткие промпты. Если шаблон занимает 30-80 токенов, выигрыш часто почти незаметен. Вы добавляете логику кэша, следите за инвалидацией, ловите странные промахи, а экономите совсем немного.

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

Еще одна ошибка - смотреть только на общий процент попаданий в кэш и радоваться числу вроде 35%. Это средняя температура по системе. Важно понять, на каких именно запросах срабатывает кэш: на длинных и дорогих или на мелких служебных шаблонах, которые почти не влияют на расходы.

Полезно хотя бы разрезать данные по нескольким признакам:

• по модели
• по длине входного промпта
• по типу шаблона
• по доле повторов внутри каждого шаблона
• по деньгам, а не только по проценту попаданий

Еще одна частая проблема выглядит скучно, но ломает весь результат. Шаблон вроде бы один и тот же, но на деле меняется каждый час. В него попадает текущая дата, имя менеджера, ID сессии, версия эксперимента или случайная строка для отладки. Для кэша это уже другой запрос. На графике вы видите слабый эффект и решаете, что идея не работает, хотя все портит одна переменная в середине шаблона.

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

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

Быстрая проверка перед запуском

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

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

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

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

После этого проверьте качество ответов. Возьмите набор из 50-100 реальных запросов и сравните результат до и после включения кэша. Смотрите не только на цену, но и на точность, свежесть данных и персонализацию.

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

На практике этого мини-аудита обычно хватает. Допустим, поддержка каждый день обрабатывает 800 обращений, и в каждом запросе есть одинаковая инструкция на 1 200 токенов. Даже при умеренной доле попаданий экономия становится заметной уже в первом месяце.

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

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

Что делать дальше

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

Сначала снимите базу без кэша. Нужны не общие ощущения, а простые цифры за один и тот же период: сколько токенов ушло, сколько стоил трафик, какая была задержка и как часто пользователи жаловались на странные ответы. Даже 5-7 дней уже дают нормальную картину, если поток не слишком маленький.

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

Рабочий порядок простой:

• выбрать один сценарий с заметной повторяемостью
• замерить стоимость, долю попаданий, задержку и качество до запуска
• включить кэш на 1-2 недели и собрать те же цифры после
• прогнать тот же сценарий на 2-3 моделях, а не на одной

Сравнение по нескольким моделям полезно почти всегда. Одна модель может давать высокий процент попаданий, но съедать экономию из-за дорогого вывода. Другая может отвечать чуть проще, зато держать цену ниже и спокойнее переносить агрессивный кэш.

Для проверки качества не нужен большой исследовательский проект. Возьмите 50-100 реальных запросов, попросите команду оценить точность и уместность ответов до и после, а потом отдельно посмотрите на промахи. Часто проблема не в кэше, а в том, что в него попала персональная часть запроса, которая должна меняться каждый раз.

Если вы тестируете сразу нескольких провайдеров, пилот удобнее делать там, где не нужно переписывать интеграцию под каждый запуск. В OpenAI-совместимом шлюзе вроде AI Router можно поменять base_url на api.airouter.kz и прогонять один и тот же сценарий через разные модели и провайдеров без смены SDK, кода и промптов. Это сокращает время на тест и убирает лишние различия между сравнениями.

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