Найдите промах кэша в счёте OpenAI

Обновлено September 26, 2026 · впервые опубликовано September 26, 2026

Дашборд кэша промптов может сказать, что повторное использование упало. Сам по себе он не скажет, какое изменение запроса вызвало падение и сколько оно стоило. Релиз OpenAI от 8 сентября 2026 года сделал Prompt Cache Diagnostics общедоступным в Responses API для GPT-5.6 и более поздних поддерживаемых моделей. Полезный ход для FinOps — превратить падение кэшированных токенов в короткое, повторяемое расследование.

Сравните запрос, который промахнулся

Сохраните ID недавнего завершённого ответа, префикс которого вы ожидали переиспользовать. В следующем сопоставимом запросе к Responses API из той же организации задайте prompt_cache_options.comparison_response_id равным этому ID. Затем прочитайте prompt_cache_diagnostics в новом ответе вместе с usage.input_tokens_details.cached_tokens. Опция сравнения запрашивает диагностику; она не загружает прошлый диалог и не меняет поведение кэша. В руководстве по диагностике OpenAI есть рабочие примеры запросов.

const next = await client.responses.create({
  model: model,
  instructions: stableInstructions,
  input: nextInput,
  tools: stableTools,
  prompt_cache_options: { comparison_response_id: baseline.id }
});
console.log(next.prompt_cache_diagnostics);
console.log(next.usage.input_tokens_details.cached_tokens);

Фрагмент предполагает, что baseline — недавний завершённый ответ, а остальные переменные — ваши данные запроса. Держите стабильный префикс достаточно длинным для кэширования: OpenAI документирует минимум 1,024 токена для GPT-5.6 и более поздних моделей. Маленький или радикально отличающийся промпт не является содержательным тестом промаха кэша.

Исправляйте причину, а не метрику

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

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

Переведите находку в деньги

cache_missed_tokens оценивает потерянные переиспользуемые токены относительно сравниваемого ответа. Это не количество оплаченных токенов. Результат cache_hit тоже не доказывает экономию в долларах. Для фактической стоимости входа соберите суммарные input_tokens, cached_tokens и cache_write_tokens каждого ответа, затем примените текущий тариф для этой модели и уровня обработки. Для GPT-5.6 и более поздних моделей руководство по кэшированию промптов OpenAI указывает, что чтение из кэша стоит 0.1 от тарифа некэшированного входа, а запись в кэш — 1.25 от этого тарифа.

ordinary = input_tokens - cached_tokens - cache_write_tokens
weighted_input = ordinary + 0.1 * cached_tokens + 1.25 * cache_write_tokens
input_cost = weighted_input * input_price_per_million / 1_000_000

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

Полезная еженедельная проверка

1. Группируйте сопоставимый трафик по нагрузке, модели и уровню сервиса; постройте график доли кэшированных токенов и стоимости входа на завершённую задачу.
2. Возьмите выборку внезапного ухудшения, сравните её с недавней базовой точкой и зафиксируйте причину диагностики и ответственное изменение кода.
3. Исправляйте случайный дрейф префикса или конфигурации; сохраняйте намеренные изменения качества или маршрутизации, если общая экономика задачи улучшилась.
4. Проверьте результат на репрезентативном производственном трафике и сверьте наблюдаемую экономию с биллингом.

Сами диагностики не имеют дополнительной платы за функцию, но дополнительные тестовые запросы оплачиваются обычным образом. Выигрыш — не красивый график процента попаданий. Это обоснованное объяснение, почему стоимость входа конкретной нагрузки изменилась и действительно ли предложенное исправление снизило счёт.

Вопросы, которые задают команды

Доказывает ли диагноз попадания в кэш, что запрос был дешевле?

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

Могут ли диагностики сравнить любые два запроса OpenAI?

Нет. Используйте недавнюю завершённую базовую точку той же организации и ожидайте этот процесс только для поддерживаемых моделей Responses API начиная с GPT-5.6. Запись сравнения может истечь.

Нужно ли устранять каждый промах кэша?

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

По теме

• Экономика prompt caching
• Атрибуция кэша промптов
• Стоимость успешной задачи

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

Вернуться на finopsllm.com