Кеширование промптов может уменьшить расходы на повторные запросы к большой языковой модели, если API повторно использует общий префикс и применяет к нему более низкую цену. Однако включённая функция сама по себе не доказывает экономию. В расчёте важны фактическое количество кешированных токенов, доля успешных попаданий, срок жизни кеша и возможная плата за его создание.
Ниже — методика для команды, которая использует LLM через API и хочет проверить эффект на собственных данных. Она помогает сравнить обычную обработку с кешированной, найти точку безубыточности и понять, совпадает ли локальная оценка с суммой в счёте провайдера.
За что платит приложение
Упрощённая стоимость запроса без кеша рассчитывается так:
Стоимость = входные токены × цена входа + выходные токены × цена выхода.
У конкретного провайдера могут быть отдельные категории для обычного ввода, кешированного ввода, записи кеша, пакетной обработки и разных режимов скорости. Поэтому перед расчётом нужно зафиксировать:
- название и версию модели;
- используемый endpoint;
- валюту тарифа;
- цены за миллион входных и выходных токенов;
- правила оплаты записи и хранения кеша;
- дату, на которую актуален тариф.
Для периода с несколькими запросами удобно использовать такие обозначения:
- I — общее число входных токенов;
- C — число токенов, фактически обработанных из кеша;
- O — число выходных токенов;
- Pi — цена обычного входа за миллион токенов;
- Pc — цена кешированного входа;
- Po — цена выхода;
- W — отдельная плата за создание или хранение кеша.
Тогда приблизительная стоимость выглядит так:
Стоимость = (I − C) × Pi / 1 000 000 + C × Pc / 1 000 000 + O × Po / 1 000 000 + W.
Если API не показывает кешированные токены, значение C нельзя достоверно восстановить по длине шаблона. В этом случае сначала нужно добавить наблюдаемость или провести отдельное сравнение с контрольной группой.
Как работает общий префикс
Кеширование обычно рассчитано на повторное использование неизменной начальной части запроса. Это может быть системная инструкция, формат ответа, описание инструментов или большой справочный блок. Переменный вопрос пользователя размещается после стабильного контекста.
OpenAI описывает кеширование повторяющихся префиксов и показывает сведения о кешированных входных токенах в данных использования. Anthropic разделяет операции создания и чтения кеша и указывает для них отдельные условия. Gemini API использует собственный механизм кеширования контекста с правилами, зависящими от выбранной модели и способа вызова.
Эти реализации нельзя считать взаимозаменяемыми. Перед внедрением проверьте в документации конкретного API:
- минимальный размер префикса;
- способ активации кеширования;
- время жизни записи;
- условия продления;
- цену записи, чтения и хранения;
- поле ответа, где отражается использование кеша;
- ограничения для модели и endpoint.
Если динамические данные стоят в начале запроса, общий префикс может перестать совпадать. Изменение инструкции, порядка блоков или формата передаваемого текста также способно снизить долю попаданий.
Рассчитайте точку безубыточности
Пусть один кешируемый префикс содержит C токенов, а за период происходит r повторных чтений. Тогда экономию на чтении можно оценить так:
Экономия = r × C × (Pi − Pc) / 1 000 000 − W.
Кеширование выгодно, когда результат выше нуля и не создаёт неприемлемых расходов на задержку, хранение или сопровождение. При бесплатной записи W равен нулю. Если провайдер отдельно взимает плату за создание кеша, её нужно включить в формулу.
Условный пример:
- общий префикс — 2 000 токенов;
- повторные чтения — 100;
- обычный ввод — 2 доллара за миллион токенов;
- кешированный ввод — 0,50 доллара за миллион токенов;
- отдельная плата за запись не учитывается.
Расчёт:
100 × 2 000 × (2 − 0,50) / 1 000 000 = 0,30 доллара.
Это максимальная экономия при условии, что все 100 запросов действительно использовали весь префикс. При доле попаданий 50% результат будет примерно вдвое меньше. Поэтому в рабочем отчёте нужно использовать C из ответа API, а не размер блока в исходном шаблоне.
Сравните варианты по одной формуле
Перед тестом составьте таблицу с одинаковыми параметрами. Она помогает не смешать скидку на входные токены с изменением модели, длины ответа или числа запросов.
| Показатель | Обычный ввод | Кешированный ввод | Что проверить |
|---|---|---|---|
| Входные токены | I | I − C и C | Счётчики из ответа API |
| Цена обычного ввода | Pi | Pi | Тариф выбранной модели |
| Цена кешированного ввода | — | Pc | Условия чтения кеша |
| Выходные токены | O | O | Одинаковые настройки генерации |
| Дополнительные сборы | — | W | Запись, хранение, повторные операции |
Для каждого варианта рассчитайте:
- среднюю стоимость запроса;
- медианную стоимость;
- общую стоимость серии;
- долю запросов с попаданием;
- среднее число кешированных токенов;
- задержку до первого фрагмента и полный срок ответа;
- качество результата на одинаковых задачах.
Среднее значение показывает расход бюджета, а медиана помогает увидеть влияние отдельных крупных запросов. Если ответы генерируются с высокой вариативностью, сравнивать следует расходы и метрики качества, а не буквальное совпадение текста.
Соберите базовую линию
До изменения приложения сохраните данные за период с обычной нагрузкой. Для каждой операции достаточно записывать технические поля:
провайдер и модель;
идентификатор сценария;
3. время запроса;
4. число входных токенов;
5. число выходных токенов;
6. число кешированных токенов;
7. статус ответа;
8. идентификатор запроса;
9. рассчитанную стоимость;
10. задержку.
Секретные ключи и полный текст промпта в такой журнал включать не следует. Для анализа обычно хватает размера стабильного префикса, версии шаблона и счётчиков токенов. Персональные данные нужно удалить или заменить техническими идентификаторами.
Если приложение обращается к нескольким моделям, разделите статистику по каждой из них. Иначе средняя стоимость скроет разницу между тарифами и размерами контекста.
Проведите контрольный эксперимент
Подготовьте набор реальных сценариев: вопросы к базе знаний, вызовы инструментов, классификацию документов или генерацию структурированных ответов. Для каждого сценария создайте две группы.
Контрольная группа отправляет запросы без расчёта на повторное использование префикса. Экспериментальная группа получает тот же стабильный блок в начале запроса, а переменная часть добавляется после него.
Сохраняйте неизменными:
- модель и endpoint;
- системные инструкции;
- параметры генерации;
- набор входных задач;
- требования к формату ответа;
- число повторов;
- правила обработки ошибок.
Первое обращение может создать запись, а следующие — использовать её. Поэтому один запуск недостаточен. Проведите серию повторов и отдельно отметьте первый запрос. Долю попаданий считайте по полю ответа API, а не по визуальному сходству текстов.
Если изменение структуры запроса ухудшило качество ответа, экономию нельзя считать достаточным основанием для внедрения. Для агентных систем отдельно проверьте вызовы инструментов: динамические параметры, результаты поиска и состояние диалога часто меняются от запроса к запросу и могут разрушать общий префикс.
Сверьте расчёт с биллингом
После теста сопоставьте локальную сумму с данными провайдера за тот же временной интервал. Разница может появиться из-за:
- округления токенов или стоимости;
- повторных попыток после ошибок;
- нескольких моделей в одном проекте;
- платы за запись или хранение кеша;
- обновления тарифа;
- дополнительных категорий входных токенов;
- запросов, которые не попали в локальный журнал.
Проверяйте совпадение по проекту, модели и часовому интервалу. Если провайдер показывает стоимость с задержкой, дождитесь полной выгрузки перед окончательным выводом.
Документация, с которой стоит начать:
- Google Gemini API: https://ai.google.dev/gemini-api/docs/caching
- Anthropic Prompt Caching: https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
- OpenAI Prompt Caching: https://platform.openai.com/docs/guides/prompt-caching
- OpenAI Pricing: https://platform.openai.com/docs/pricing
Эти страницы описывают механизмы и тарифы на момент проверки. Перед запуском расчёта сохраните дату и используемую версию документации.
Учитывайте ограничения метода
Самая частая ошибка — считать кешируемым весь исходный шаблон. В рабочей нагрузке совпасть может лишь часть префикса. Другая ошибка — сравнивать разные модели или серии запросов с разной длиной ответа. В таком случае изменение счета нельзя уверенно связать с кешированием.
Есть и эксплуатационные ограничения:
- короткий срок жизни кеша снижает число попаданий;
- обновление инструкций создаёт новый префикс;
- динамический контекст может менять начало запроса;
- задержка записи может повлиять на первые обращения;
- чувствительные данные могут попасть в повторно используемый блок;
- большие стабильные блоки увеличивают требования к контролю версий.
Для конфиденциальных сценариев отдельно изучите правила хранения данных и доступ к кешу. Не помещайте в общий префикс секреты, персональные данные и информацию, которая не должна использоваться в других обращениях того же механизма.
Примите решение по результатам
Оставляйте кеширование в рабочем контуре, если выполнены четыре условия:
фактическая стоимость запроса снизилась;
доля попаданий стабильна на реальной нагрузке;
3. качество ответов не ухудшилось;
4. условия хранения и обработки данных подходят для продукта.
Если API не сообщает число кешированных токенов, не приписывайте снижение счета кешу автоматически. Сначала исключите уменьшение нагрузки, изменение длины ответов, переход на другую модель и сокращение числа повторов.
Практический следующий шаг — выгрузить данные за один полный рабочий цикл, разделить запросы на контрольные и экспериментальные, затем пересчитать стоимость по фактическому C. После этого сравните результат с биллингом и зафиксируйте порог, при котором кеширование остаётся выгодным. Такой порог стоит пересматривать при смене модели, тарифа, шаблона инструкций или структуры агентного сценария.
