Prompt Cache: стоимость первого и повторных запросов

Стоимость Prompt Cache проверяют серией одинаковых запросов: первый создаёт или подготавливает кэшируемый префикс, последующие пытаются его прочитать, а контрольный запрос меняет префикс и вызывает miss. Сравнивать нужно usage-категории и фактическое списание одной модели. Фиксированная «экономия в процентах» без Model ID, TTL, длины prefix и текущих цен ничего не доказывает.

Что именно измеряет эксперимент

Prompt Cache уменьшает повторную обработку неизменной части входа. Это может быть system prompt, набор инструкций, большой документ или стабильная история. Изменяемый вопрос помещают после общего prefix.

В эксперименте нужны три состояния:

A. first request: stable prefix + question 1
B. cache hit:     stable prefix + question 2
C. cache miss:    changed prefix + question 3

Запросы A и B используют одну модель, одинаковые настройки и один cache policy. C меняет один символ в кэшируемой области либо выполняется после подтверждённого истечения TTL. Если одновременно изменить модель, длину output и prompt, результат нельзя объяснить только кэшем.

Хотите проверить формулу на собственном usage? Можно создать аккаунт BetterToken и API Key, взять актуальные ставки со страницы цен и выполнить первый и повторный запросы с одинаковым префиксом. Затем сопоставьте input, output, применимые cache Token и расход в Dashboard, а правила cache и TTL предварительно сверьте с API reference и документацией провайдера.

OpenAI и Anthropic считают кэш по-разному

Одинаковое слово cache не означает одинаковый механизм.

OpenAI prompt caching

В поддерживаемых OpenAI API и моделях caching применяется автоматически к подходящему prefix. Usage показывает cached tokens внутри деталей input. Код обычно не создаёт отдельный cache object, но должен сохранять общий prefix без изменений. Точные пороги, retention и скидки проверяются на официальной странице Prompt Caching.

Anthropic prompt caching

Anthropic Messages позволяет отметить cache boundary через cache_control. Usage может отдельно показывать создание и чтение cache. Минимальный размер, TTL, порядок блоков и стоимость зависят от текущего контракта и модели; их нужно сверить в официальной документации Anthropic.

Не переносите названия usage-полей или коэффициенты между двумя протоколами. В таблицу эксперимента записывайте именно те категории, которые вернул текущий endpoint.

Подготовка стабильного prefix

Соберите input из двух частей:

STABLE_PREFIX
  system instructions
  tool definitions, если они действительно нужны
  unchanged reference document

DYNAMIC_SUFFIX
  current user question

Для первого опыта лучше убрать tools и streaming. Они не мешают cache автоматически, но добавляют переменные в usage и output.

Prefix должен быть достаточно длинным по правилам выбранной модели. Если он короче минимального порога, отсутствие cache hit будет ожидаемым результатом. Не удлиняйте его бессмысленным текстом в production; для эксперимента используйте реальный документ, который и так повторяется в задаче.

Перед вызовом сохраните hash кэшируемой части:

import hashlib

prefix_hash = hashlib.sha256(STABLE_PREFIX.encode("utf-8")).hexdigest()
print(prefix_hash)

Hash подтверждает, что A и B получили одинаковый prefix, не публикуя его содержимое.

Какие поля записать

Для каждого запроса сохраните:

  • timestamp и request ID;
  • Model ID и протокол;
  • prefix_hash;
  • обычные input tokens;
  • cache creation/write tokens, если контракт их выделяет;
  • cache read/cached tokens, если контракт их выделяет;
  • output tokens;
  • фактический расход;
  • status и latency только как диагностические поля.

Latency не является доказательством цены. Быстрый ответ может оказаться cache miss, а cache hit — ждать очереди. Вывод о стоимости делается по usage и тарифу.

Формула первого запроса

Обозначим:

I  — обычные input tokens
W  — cache write / creation tokens
R  — cache read / cached tokens
O  — output tokens
Pi — цена обычного input за 1 000 000 tokens
Pw — цена cache write за 1 000 000 tokens
Pr — цена cache read за 1 000 000 tokens
Po — цена output за 1 000 000 tokens

Тогда расчёт для endpoint, который разделяет эти категории:

cost = I / 1_000_000 × Pi
     + W / 1_000_000 × Pw
     + R / 1_000_000 × Pr
     + O / 1_000_000 × Po

В первом запросе W может быть больше нуля, а R — нулём. У автоматического caching набор полей может отличаться: используйте uncached и cached input из фактического usage, не создавайте несуществующую категорию.

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

Формула повторного запроса и точка окупаемости

Пусть:

C0 — стоимость первого запроса с созданием cache
Ch — стоимость одного запроса с cache hit
Cu — стоимость одного аналогичного запроса без cache
n  — общее число запросов

Серия с одним созданием и n - 1 hits:

C_cached(n) = C0 + (n - 1) × Ch
C_uncached(n) = n × Cu

Минимальное n, при котором кэш окупился, — первое целое число с условием:

C_cached(n) < C_uncached(n)

Не подставляйте в формулу цены другой модели. Если Ch >= Cu, текущая конфигурация не даёт экономии; проверьте cache hit, размер prefix и тарифные категории.

Контрольный cache miss

После A и B выполните C. Измените только кэшируемый prefix, сохранив модель и длину ожидаемого ответа. Cache-read категория должна уменьшиться или исчезнуть согласно контракту, а обычная обработка или cache creation — измениться.

Причины неожиданного miss:

  • изменился символ или пробел внутри prefix;
  • tool definitions пришли в другом порядке;
  • system block переместился;
  • модель или endpoint сменились;
  • запрос попал за пределы TTL;
  • prefix оказался короче минимального порога;
  • клиент сериализует одинаковые данные в другом порядке.

Изменение вопроса после стабильного prefix обычно является ожидаемым сценарием. Изменение внутри prefix создаёт другую cache identity.

Почему мы не публикуем «результат в долларах»

У этой статьи нет доступа к API Key и usage конкретного аккаунта, поэтому она не выдаёт расчётный пример за проведённый тест. Цены, модели и caching rules меняются. Публикация случайного числа быстро превратила бы воспроизводимый эксперимент в устаревшую рекламу.

Чтобы получить собственный результат:

  1. выберите одну модель и один протокол;
  2. откройте текущую страницу цен BetterToken;
  3. выполните A, B и C;
  4. перепишите usage и расход из Dashboard;
  5. посчитайте C0, Ch, Cu и точку окупаемости;
  6. сохраните дату проверки и prefix_hash.

FAQ

Почему первый запрос с cache может стоить дороже?

Некоторые протоколы отдельно тарифицируют cache creation/write. Первоначальная надбавка компенсируется только повторными cache reads. Смотрите текущую цену конкретной модели.

Почему повторный запрос не получил cache hit?

Проверьте длину и неизменность prefix, порядок блоков, модель, endpoint, TTL и минимальный порог. Сравните prefix_hash.

Можно ли сравнить OpenAI и Anthropic одним usage-полем?

Нет. У них различаются механизм, конфигурация и названия категорий. Сначала нормализуйте значения в собственные I, W, R, O, сохраняя исходные поля.

Cache всегда уменьшает стоимость?

Нет. Короткий prefix, редкие повторы, частые изменения и малый cache hit rate могут не окупить создание cache.

Где проверить фактическое списание BetterToken?

В Dashboard по времени, модели и status запроса. Тариф берите со страницы цен, а caching rules — из документации соответствующего протокола.