Кэш API срабатывает, а расходы не падают: проверка чтения, записи и списаний
Как считать долю кэшированных токенов, учитывать запись в кэш и сверять начисления по отдельным запросам.
Если кэш срабатывает, а стоимость почти не меняется, это ещё не доказывает ошибку списания. Кэш влияет на определённые входные данные; выход, запись в кэш и дополнительные функции могут оплачиваться отдельно. Посредник также устанавливает свои правила передачи скидки клиенту.
Материал описывает проверку, которую можно провести самостоятельно. Он не содержит результатов тестирования конкретных сервисов. Все числа условные.
Разделите типы входа
| Тип | Что означает | Что сверить |
|---|---|---|
| Обычный вход | Токены по обычному правилу | Количество и тариф |
| Чтение кэша | Повторное использование кэшированной части | Объём чтения и цена |
| Запись кэша | Подготовка данных к последующему использованию | Объём, наличие отдельной платы и тариф |
Модели различаются минимальной длиной кэшируемого содержимого, сроком хранения, параметрами и полями статистики. Не переносите правила одного семейства на другое и не считайте скидку фиксированной для всех моделей.
Сохраните записи по каждому запросу
Зафиксируйте модель, группу, ключ и протокол. Для каждого обращения нужны время, ID, общий вход, чтение и запись кэша, выход и списанная сумма.
В совместимых API может встречаться cached_tokens, но путь к полю и его смысл надо проверить по документации интерфейса. Кэшированные токены могут уже входить в общий показатель входа. Повторное прибавление приведёт к неверному расчёту.
Сохраняйте и ответ API, и запись кабинета посредника. Если полей не хватает, вывод должен быть «недостаточно данных», а не «всё кэшируется» или «кэша нет».
Небольшой тест с ограниченным бюджетом
Подготовьте несекретный стабильный материал, отвечающий условиям кэширования конкретной модели. Настройте поддерживаемые параметры и префикс или контрольную точку по документации.
Выполните несколько запросов, меняя только короткий вопрос после постоянной части. Затем сделайте контроль с изменённым префиксом. Сохраните статистику и стоимость всех обращений.
Неудачный повтор может объясняться длиной, маршрутизацией, сроком хранения или настройкой контрольной точки. Результат относится к этим запросам и времени проверки, а не к вечной характеристике провайдера.
Доля запросов и доля токенов различаются
У трёх запросов вход — 10 000, 10 000 и 80 000 токенов. Чтение из кэша — 9 000, 9 000 и 0.
По числу запросов кэш сработал в двух случаях из трёх: около 66,7%. По токенам доля чтения равна 18 000 / 100 000 = 18%. Первая цифра завышает впечатление об экономии на всей входной нагрузке.
Можно отдельно считать долю повторно использованного префикса, но тогда явно укажите другой знаменатель.
Пример расчёта без двойного учёта
Допустим, общий вход — 10 000 токенов: 1 000 обычных, 8 000 прочитанных из кэша и 1 000 записанных. Категории не пересекаются. Условные цены за миллион: 10, 1 и 12,5 денежных единицы. Выход — 1 000 токенов по цене 30.
Расход = 0,01 + 0,008 + 0,0125 + 0,03 = 0,0605 денежной единицы.
В примере нет других услуг, пересчёта баланса и коэффициентов. Если поля API определены иначе, сначала приведите их к непересекающимся категориям. Не умножайте повторно цену, уже включающую коэффициент.
Что проверить при расхождении
Сопоставьте ID, часовой пояс и канал; проверьте валюту баланса, изменение цены, округление, задержку журнала и дополнительные запросы из-за повторов.
Длинный выход может скрыть экономию на входе. Стоимость записи также учитывайте вместе с последующими чтениями, а не исключайте первую попытку.
Одинаковые ответы доказывают попадание в кэш? Нет: кэширование входа не равно повторной выдаче готового ответа.
Кэш доказывает подлинность модели? Нет, происхождение модели требует других доказательств.
Источник: документация OpenAI по Prompt Caching, проверена 08.09.2026. Она описывает соответствующий официальный API; реализация посредника требует отдельной проверки.
Далее: основы тарификации и цены моделей.