Prompt caching может снизить стоимость и задержку повторяющихся запросов к LLM, но только если рабочий процесс формирует стабильные префиксы, обеспечивает достаточное повторное использование и приемлемое поведение cache-hit. Просто включить функцию — это не то же самое, что доказать окупаемость инвестиций.
Это руководство дает инженерным и FinOps-командам практический workflow prompt caching: найти подходящий трафик, сформировать промпты для повторного использования, настроить метрики кэша, рассчитать чистую экономию и внедрить решение, не скрывая регрессии качества или надежности. Также включен семидневный аудит, который превращает поля использования провайдера в решение go, fix или stop.
Prompt caching ROI: краткий ответ
Prompt caching обычно стоит тестировать, когда рабочий процесс многократно отправляет большой, побайтно идентичный префикс в пределах окна хранения провайдера. Это не становится автоматически выгодным только потому, что модель рекламирует скидку на cached tokens.
Используйте этот трехступенчатый фильтр перед изменением production-промптов:
| Фильтр | Условие прохождения | Условие остановки |
|---|---|---|
| Повторное использование | Один и тот же префикс используется несколько раз до истечения срока | Большинство префиксов используются однократно или уникальны для пользователя |
| Экономика | Наблюдаемая экономия на чтении превышает затраты на записи, хранение и эксплуатацию | Кэш создается чаще, чем повторно используется |
| Результат | Стоимость на одну принятую задачу улучшается без регрессии качества или надежности | Снижение стоимости токенов приводит к большему числу повторных попыток, отклоненным ответам или небезопасному fallback |
Основной расчет:
net_savings = uncached_baseline_cost
- observed_cached_workflow_cost
- incremental_engineering_and_operations_cost
roi_percent = net_savings
/ incremental_engineering_and_operations_cost
× 100
Если стоимость внедрения распределяется между многими cache identities, амортизируйте ее на ожидаемый период оценки вместо того, чтобы относить всю стоимость проекта к одной записи.
Что изменилось в prompt caching в 2026 году?
Prompt caching больше не является одним унифицированным механизмом скидок. Дизайны провайдеров теперь отличаются настолько, что универсальная таблица "cached tokens дешевле" может дать неверный ответ.
Например, текущая документация OpenAI для GPT-5.6 описывает автоматическое сопоставление префиксов, явные элементы управления prompt_cache_key и cache_control, а также отдельный учет cache-read и cache-write. Cache writes для этой модели могут иметь премию, поэтому расчет точки безубыточности должен включать стоимость создания или продления кэша, а не только скидку на чтение. OpenAI также предоставляет сведения о cached, uncached и cache-write токенах в полях usage для поддерживаемых запросов.
Anthropic использует явные точки разрыва кэша и выбор времени жизни (time-to-live). Gemini explicit context caching может добавлять плату за хранение. DeepSeek документирует автоматическое context caching с отдельными показателями hit и miss. Все эти схемы могут давать экономию, но им нужны разные телеметрия и формулы.
Что такое prompt caching?
Prompt caching позволяет провайдеру LLM повторно использовать вычисления для содержимого промпта, которое он недавно обработал. Вместо того чтобы выставлять счет и обрабатывать каждый повторяющийся входной токен по стандартной ставке, провайдер может применить более низкую ставку для cached-input или отдельную цену cache-read к повторно используемой части.
Повторно используемый контент обычно представляет собой стабильный префикс запроса. Распространённые примеры:
- Длинный системный prompt и блок политик.
- Определения инструментов, общие для каждого хода агента.
- Большой документ, карта репозитория или каталог продуктов, которые запрашиваются повторно.
- Несколько примеров few-shot, повторно используемых в задаче классификации или извлечения.
- История разговора, общая для нескольких возможных следующих действий.
Реализации у провайдеров различаются. OpenAI документирует автоматическое кэширование для подходящих префиксов запросов и показывает сведения о cached-token в использовании API; поддерживаемые более новые модели также могут отображать детали cache-write. Anthropic поддерживает явные точки разрыва кэша и несколько вариантов времени жизни. Google Gemini поддерживает явные context caches с платой за хранение, а DeepSeek документирует автоматическое дисковое кэширование контекста с отдельными тарифами на входные данные для cache-hit и cache-miss. Всегда проверяйте текущую поддержку моделей и цены в официальной документации провайдера, прежде чем закладывать экономию в прогноз.
Ошибка в ROI: измерять скидку, а не рабочий процесс
Скидка на cached-token — это не то же самое, что чистая экономия. Рабочий процесс также может создавать charges за cache-write, charges за хранение, дополнительные запросы, операционную сложность или ухудшение качества, если команды слишком агрессивно оптимизируют структуру prompt.
Измеряйте ту единицу, которая имеет значение:
Чистый ROI prompt caching = избегаемая стоимость не кэшированных входных данных - стоимость cache write/storage - стоимость внедрения и эксплуатации
Для производственных решений свяжите этот результат с принятым итогом:
Стоимость на одну принятую задачу = общая стоимость запросов / подтверждённые успешные задачи
Это позволяет избежать вводящего в заблуждение результата, когда расходы на токены падают, но количество повторных попыток, отклонённых ответов или ручной проверки растёт. Это также согласует prompt caching с более широкой программой оптимизации стоимости AI API, а не рассматривает кэширование как изолированный трюк с биллингом.
Шестиэтапный рабочий процесс prompt caching
1. Найдите рабочие нагрузки с реальным повторным использованием префикса
Начинайте с трасс запросов, а не с интуиции. Сгруппируйте трафик по рабочему процессу и оцените, сколько входных токенов остаются идентичными от начала одного запроса к началу следующего.
Хорошие кандидаты обычно обладают четырьмя свойствами:
- Большой повторяющийся ввод: повторно используемый префикс значим по сравнению с динамическим суффиксом.
- Частое повторное использование: несколько запросов ссылаются на один и тот же префикс в пределах эффективного срока жизни кэша провайдера.
- Стабильный порядок: системные инструкции, инструменты, примеры и справочные материалы идут в одном и том же порядке.
- Низкая кардинальность: приложение повторно использует управляемое число вариантов prompt, а не создаёт уникальный префикс для каждого пользователя.
Типичные рабочие процессы с высоким потенциалом включают агентов для кодинга со стабильными схемами инструментов, ассистентов поддержки, опирающихся на общий пакет знаний, сеансы Q&A по документам, пакетное извлечение с повторяющимися примерами и многоходовых исследовательских агентов.
Плохие кандидаты включают одноразовые короткие запросы, сильно персонализированные префиксы, запросы, которые меняют определения инструментов при каждом вызове, и малонагруженные задачи, которые редко повторно используют запись кэша.
Постройте базовую таблицу для каждого рабочего процесса:
| Метрика | Почему это важно |
|---|---|
| Запросов в день | Определяет объем повторного использования |
| Среднее количество входных токенов | Определяет общую стоимость входных данных |
| Повторно используемые токены префикса | Определяет поверхность, пригодную для кэширования |
| Варианты префикса | Показывает фрагментацию |
| Интервал повторного использования | Проверяет, остаются ли записи полезными |
| Доля принятых задач | Защищает качество и бизнес-ценность |
| P50/P95 задержка | Измеряет влияние на производительность |
2. Помещайте статический контент перед динамическим
Кэширование prompt обычно зависит от совпадения prompt с самого начала. Небольшое отличие в начале может помешать повторному использованию всего, что следует далее.
Используйте такой порядок, если это позволяют провайдер и SDK:
1. Стабильные системные инструкции
2. Стабильные правила политики и безопасности
3. Стабильные определения инструментов
4. Стабильные справочные материалы или примеры
5. Полустабильный контекст разговора
6. Динамический ввод пользователя и значения времени выполнения
Не размещайте метки времени, идентификаторы запросов, пользовательские ярлыки, JSON со случайным порядком или часто меняющиеся флаги функций в начале prompt. Нормализуйте схемы инструментов и сериализуйте структурированный контент детерминированным образом.
Это не дает разрешения объединять несвязанные данные в слишком большой префикс. Сохраняйте границы арендаторов, правила авторизации и требования к хранению данных. Более дешевый prompt не стоит сбоев в конфиденциальности или изоляции.
3. Определите идентичность кэша и политику инвалидации
Вашему приложению нужен явный способ рассуждать о версиях prompt, даже если провайдер автоматически управляет кэшем.
Практическая идентичность кэша может включать:
workflow + prompt_version + tool_schema_version + knowledge_version + model_family
Отслеживайте эту идентичность в телеметрии. Когда меняются инструкции, контракты инструментов или справочные данные, увеличивайте соответствующую версию. Это делает изменения стоимости объяснимыми и помогает командам не путать ожидаемую инвалидацию со сбоем у провайдера.
Задайте окно повторного использования на основе поведения рабочей нагрузки и поддержки со стороны провайдера. Краткоживущий интерактивный агент может выиграть от повторного использования в течение минут. Регулярный исследовательский workflow может оправдать более долгий явный кэш, если стоимость хранения остается ниже, чем повторная обработка входных данных.
4. Инструментируйте попадания, промахи, записи и принятые результаты
Как минимум логируйте следующие поля для каждой попытки:
- Провайдер, модель и workflow.
- Версия prompt и идентичность кэша.
- Общее количество входных, кэшированных/прочитанных, записанных в кэш и выходных токенов, если они доступны.
- Состояние попадания в кэш или вывод о попадании.
- Оценочная стоимость входных данных, кэша, выхода и общая стоимость.
- Задержка, статус, номер повтора и путь fallback.
- Проверенный успех или результат принятой задачи.
Используйте поля использования, возвращаемые провайдером, как источник истины для биллинга, когда это возможно. Если провайдер не возвращает четкий признак попадания в кэш, аккуратно делайте вывод по количеству кэшированных токенов или по billing records и помечайте метрику как inferred.
Телеметрия prompt caching должна находиться в том же trace, что и retries и fallback модели. Иначе шторм повторных попыток может выглядеть как успешная оптимизация кэша. Чеклист внедрения AI observability показывает, как связать стоимость каждой попытки с результатами работы приложения.
5. Рассчитайте экономию и объем безубыточности
Используйте модель, соответствующую структуре тарификации провайдера.
Для автоматического кэширования со сниженной ставкой чтения:
gross_savings = cache_read_tokens × (uncached_input_rate - cached_input_rate)
net_savings = gross_savings - incremental_operating_cost
Для явного кэширования с оплатой записи и хранения:
net_savings = avoided_uncached_cost
- cache_write_cost
- cache_storage_cost
- incremental_operating_cost
Для провайдера или модели, у которой разные токеновые ставки для записи и чтения кэша, рассчитайте жизненный цикл одного повторно используемого префикса:
uncached_scenario = prefix_tokens × total_uses × uncached_rate
cached_scenario = prefix_tokens × cache_writes × write_rate
+ prefix_tokens × cache_reads × read_rate
+ storage_cost
prefix_net_savings = uncached_scenario - cached_scenario
Не предполагается, что cache_writes = 1. Измененный префикс, истекшая запись, изменение маршрутизации или явное обновление могут создать еще одну запись.
Можно оценить число повторных использований, необходимое для безубыточности, для одного закэшированного префикса:
break_even_reuses =
(cache_write_cost + storage_cost + implementation_cost_per_entry)
/ savings_per_cache_read
Округлите вверх до ближайшего целого числа повторного использования. Затем добавьте запас на пропуски, инвалидации и вариативность трафика.
Пример расчета ROI
Предположим, рабочий процесс имеет:
- 40 000 запросов в месяц.
- 18 000 входных токенов на запрос.
- Стабильный префикс на 12 000 токенов.
- Эффективную долю попаданий в кэш 70%.
- Ставку для некэшированного ввода $3 за миллион токенов.
- Ставку для кэшированного ввода $0.30 за миллион токенов.
- $350 в месяц в виде амортизированных затрат на инженерную поддержку и мониторинг.
Ежемесячные кэшированные токены:
40,000 × 12,000 × 70% = 336,000,000 cached input tokens
Валовая экономия:
336 million × ($3.00 - $0.30) / 1 million = $907.20
Чистая ежемесячная экономия:
$907.20 - $350 = $557.20
Если рабочий процесс создает 32 000 принятых задач, кэширование обеспечивает примерно $0.017 экономии на одну принятую задачу. На масштабе это может быть существенно, но результат гораздо скромнее, чем просто указать скидку 90% на кэшированный ввод.
Приведенные выше ставки носят иллюстративный характер и не являются текущей котировкой провайдера. Замените их на ваши контрактные или опубликованные ставки и учитывайте записи кэша, хранение, региональное ценообразование, уровни сервиса и комиссии шлюза, где это применимо.
Готовый к использованию рабочий лист ROI для prompt caching
Составляйте рабочий лист на уровне workflow и версии prompt. Смешанная доля попаданий на уровне аккаунта может скрыть один прибыльный кэш и множество убыточных.
| Вход | Символ | Пример вопроса |
|---|---|---|
| Допустимые запросы | R |
Сколько запросов могли бы повторно использовать этот префикс? |
| Токены префикса | P |
Сколько начальных токенов стабильны? |
| Чтения из кэша | H |
Сколько допустимых запросов фактически прочитали токены из кэша? |
| Записи в кэш | W |
Сколько раз префикс был создан или расширен? |
| Ставка для некэшированного ввода | U |
Сколько бы стоили эти токены без кэширования? |
| Ставка за чтение из кэша | C |
Сколько провайдер взимает за hit? |
| Ставка за запись в кэш | CW |
Создание тарифицируется по стандартной ставке ввода или с премией? |
| Стоимость хранения | S |
Тарифицируется ли хранение по token-hour или по другой единице? |
| Операционные расходы | O |
Какие расходы на мониторинг и обслуживание относятся к этому рабочему процессу? |
| Принятые задачи | A |
Сколько выходов прошло проверку на приемку в production? |
Используйте такие формулы:
eligible_prefix_tokens = R × P
observed_cached_tokens = H × P
baseline_prefix_cost = eligible_prefix_tokens × U
observed_prefix_cost = (H × P × C)
+ (W × P × CW)
+ S
net_savings = baseline_prefix_cost - observed_prefix_cost - O
net_savings_per_accepted_task = net_savings / A
Используйте согласованные единицы ставок, например доллары за токен или доллары за миллион токенов. Если только часть префикса указана как закэшированная, замените H × P на общее число закэшированных токенов, указанное провайдером.
Быстрый расчет точки безубыточности для одной записи в кэш
Когда есть одна начальная запись, нет отдельной платы за хранение и каждое последующее использование является hit:
break_even_reads = (write_rate - uncached_rate)
/ (uncached_rate - read_rate)
Округлите вверх до следующего целого числа чтений. Если ставка за запись равна обычной ставке некэшированного ввода, первое успешное повторное использование уже дает валовую экономию. Если записи идут с премией, потребуется больше чтений. Реальная точка безубыточности в production будет выше после промахов, инвалидирований, хранения и инженерных затрат.
6. Разверните с контролируемым экспериментом
Запускайте кэширование как инженерное изменение с измеримой контрольной группой.
- Выберите один workflow с высоким уровнем повторного использования.
- Зафиксируйте набор для оценки и критерии приемки.
- Определите базовые показатели стоимости без кэша, задержки и качества.
- Перестройте только стабильный префикс.
- Направьте небольшую долю production-трафика по закэшированному пути.
- Сравните hit rate, стоимость на принятый task, P95 latency, ошибки и fallback-ы.
- Расширяйте масштаб только тогда, когда экономия остается положительной после учета операционных затрат.
Запускайте control и treatment на эквивалентном трафике. По возможности фиксируйте model, service tier, maximum output, sampling settings, набор tools и policy fallback. Иначе изменение модели или маршрутизации можно ошибочно принять за выгоду от кэша.
Перед широким запуском выполните три преднамеренных теста на invalidation:
- Измените версию запроса и подтвердите, что старый кэш неверно не отнесён к новому рабочему процессу.
- Измените или переупорядочьте схему инструмента и проверьте, что соответствующий промах виден в телеметрии.
- Запустите утверждённый путь резервного перехода и подтвердите, что потеря кэша и инкрементальные затраты отнесены к попытке резервного перехода.
Держите политики повторных попыток и резервного перехода отдельно от логики кэша. Неудачный запрос может быть безопасно повторён, небезопасен для воспроизведения после частичной потоковой передачи или лучше обслуживаться эквивалентной моделью. Используйте определённую стратегию резервного перехода модели, а не рассматривайте каждый промах кэша или тайм-аут как одну и ту же ошибку.
Семидневный аудит ROI кэширования запросов
Краткий производственный аудит надёжнее прогноза, построенного на заявленной скидке за кэш. Цель не в том, чтобы доказать, что кэширование в целом работает. Цель — определить, даёт ли один конкретный рабочий процесс, версия запроса, маршрут модели и политика хранения повторяемую ценность.
Создавайте по одной строке аудита на каждый день и поддерживайте некэшируемый контроль на протяжении всего теста. Если трафик в будни и выходные различается, продлите тест, пока не проявятся оба паттерна. Не сравнивайте загруженный день с лечением с тихой исторической базовой линией.
| День | Действие | Какие данные собрать | Вопрос для решения |
|---|---|---|---|
| 0 | Зафиксировать эксперимент | ID рабочего процесса, версия запроса, модель, маршрут провайдера, политика резервного перехода, тест приёмки | Может ли другой инженер воспроизвести настройку? |
| 1 | Измерить контроль | Запросы, входные токены, выходные токены, стоимость, задержка P50/P95, принятые задачи | Сколько стоит рабочий процесс без кэширования? |
| 2 | Включить ограниченное лечение | Записи кэша, чтения, промахи, режим хранения, уровень ошибок | Поля использования полны и корректно разобраны? |
| 3 | Диагностировать локальность | Кардинальность префиксов, идентичности кэша, причины промахов, версии схемы инструментов | Промахи вызваны низким повторным использованием или фрагментацией реализации? |
| 4 | Проверить инвалидацию | Изменение версии запроса, изменение инструмента, истечение срока хранения | Отличает ли телеметрия намеренную инвалидацию от необъяснимых промахов? |
| 5 | Проверить надёжность | Сценарии повторных попыток и утверждённого резервного перехода | Сколько локальности кэша теряется при сбоях? |
| 6 | Сопоставить экономику | Базовая стоимость, фактическая стоимость, стоимость записи/хранения, операционная стоимость | Положительна ли чистая экономия после всех релевантных начислений? |
| 7 | Принять решение | Экономия с учётом качества, диапазон уверенности, ответственный, дата следующего пересмотра | Должна ли команда масштабировать, исправлять или остановить? |
Используйте сопоставимые когорты, а не средние по всему аккаунту
Назначайте сопоставимые запросы в контроль и лечение с помощью стабильного правила, например хэша от ID рабочего процесса плюс ID арендатора. Это снижает вероятность того, что результат объясняется составом клиентов, длиной запроса или сложностью задачи. Не исключайте из итогов затрат ни сбои, ни повторные попытки; они являются частью производственной экономики.
Как минимум сегментируйте аудит по:
- Поток работ и версия промпта.
- Маршрут модели и провайдера.
- Режим хранения кэша или TTL.
- Класс тенанта, если промпты существенно различаются.
- Исход выполнения: успех, повторная попытка, fallback и отклонённый результат.
Общая по аккаунту доля попаданий в кэш полезна для мониторинга, но слабо подходит для инвестиционных решений. Один высоконагруженный workflow может скрывать десятки идентификаторов кэша, которые постоянно записываются и редко читаются.
Добавьте проверки на доверие и вариативность
Не считайте один день положительной экономии сигналом к развёртыванию. Рассчитывайте ежедневную чистую экономию и анализируйте диапазон, а не только итог.
daily_net_savings = daily_uncached_baseline_cost
- daily_observed_cached_cost
- daily_operating_cost
quality_adjusted_savings = daily_net_savings
/ daily_accepted_tasks
Используйте медиану ежедневной скорректированной по качеству экономии как основной сводный показатель, затем укажите худший день и долю дней, которые остались положительными. Workflow с сильной средней экономией, но повторяющимися отрицательными днями может быть чувствителен к форме трафика, времени истечения или поведению fallback.
Если трафик низкий, определите минимальное число наблюдений до начала аудита. Практическое правило — ждать, пока в каждом когорте накопится достаточно принятых задач, чтобы включить обычные повторы, промахи и как минимум один цикл истечения хранения. Точное число зависит от вариативности workflow; не выдавайте универсальный размер выборки за статистически значимый для любого приложения.
Рубрика: запускать, исправлять или остановить
| Решение | Требуемые доказательства | Следующее действие |
|---|---|---|
| Запускать | Чистая экономия положительна в большинстве измеренных дней; стоимость на принятый task снижается; качество, ошибки и P95 latency остаются в пределах утверждённых guardrails | Постепенно увеличьте трафик и запланируйте 30-дневный обзор |
| Исправлять | Валовая экономия есть, но записи, фрагментация префикса, истечение срока или потеря кэша при fallback делают результаты нестабильными | Исправьте выявленную причину и повторите тот же аудит |
| Остановить | Чистая экономия остаётся отрицательной, стоимость на принятый task ухудшается, или workflow не может соответствовать требованиям качества, безопасности или надёжности | Удалите кэширование для этого workflow и сохраните доказательства |
Задайте правила stop-loss до запуска. Примеры включают недопустимый рост отклонённых результатов, регрессию по error-rate, значимое увеличение P95 latency, неожиданную кросс-тенантную идентичность кэша или рост ежедневных затрат выше допустимого для команды бюджета. Пороги stop-loss должны исходить из существующих целей сервиса и политики рисков продукта, а не из общего блогового бенчмарка.
Какой audit record сохранить
Сохраняйте итоговое решение рядом с конфигурацией промпта и маршрутизации, а не в отдельной таблице. Полезная запись аудита включает владельца, даты эксперимента, хэш промпта, хэш схемы tool, маршрут модели, используемые ставки, сопоставление сырых полей использования, определение принятой задачи, исключения, чистую экономию, результаты guardrail, решение и дату следующего пересмотра.
Эта запись становится особенно важной, когда меняются цены, версии модели, поведение хранения или маршруты fallback. Пересматривайте решение, когда меняется любое предположение, которое существенно влияет на записи, чтения, хранение или принятые результаты.
Панель KPI для prompt caching
Отслеживайте следующие метрики по рабочему процессу и версии промпта:
| KPI | Формула или определение | Сигнал для принятия решения |
|---|---|---|
| Доля токенов, пригодных для кэширования | Повторно используемые токены префикса / общее количество входных токенов | Достаточно ли велика область для оптимизации? |
| Уровень попаданий в кэш | Запросы на чтение кэша / подходящие запросы | Действительно ли происходит повторное использование? |
| Доля закэшированных токенов | Закэшированные входные токены / общее количество входных токенов | Какая часть входных данных получает более низкую ставку? |
| Экономия на запрос | Стоимость без кэша по базовому сценарию - наблюдаемая стоимость | Каждый ли запрос обходится дешевле? |
| Чистая экономия | Валовая экономия - затраты на записи, хранение и эксплуатацию | Положителен ли проект с финансовой точки зрения? |
| Стоимость на принятую задачу | Общая стоимость / принятые задачи | Улучшилась ли экономика с учетом качества? |
| Дельта P95 задержки | Кэшированный P95 - базовый P95 | Улучшилась ли видимая пользователю производительность? |
| Уровень причин промаха | Промахи по версии, порядку, TTL или провайдеру | Что инженерной команде следует исправить следующим? |
| Соотношение записей к чтениям кэша | Записи кэша / чтения кэша | Не создаются ли записи слишком часто? |
| Кардинальность префикса | Уникальные идентичности кэша / подходящие запросы | Не фрагментирует ли персонализация повторное использование? |
| Уровень потерь кэша при fallback | Попытки fallback, которые теряют ожидаемое повторное использование кэша / fallback-попытки | Во что обходится политика надежности с точки зрения локальности кэша |
Высокий уровень попаданий при слабой экономии может наблюдаться, когда повторяющийся префикс мал. Низкий уровень попаданий при большом префиксе все же может указывать на ценную возможность, если фрагментацию промпта можно устранить. Рассматривайте метрики вместе.
Распространенные режимы отказа prompt caching
Динамические значения в начале
Временные метки, идентификаторы и метаданные для каждого пользователя в начале фрагментируют кэш. По возможности переносите их после стабильного префикса.
Схемы инструментов меняются между запросами
Агенты часто динамически перестраивают или переупорядочивают определения инструментов. Нормализуйте порядок, удаляйте нерелевантные инструменты и намеренно версионируйте схему.
Записи кэша создаются, но редко используются повторно
Явное создание кэша может стоить дороже, чем приносит пользы, когда трафик редкий или TTL слишком длинный. Измеряйте повторное использование по каждой идентичности кэша, прежде чем увеличивать срок хранения.
Команды оптимизируют токены, но игнорируют выходные данные
Токены вывода, повторы и ручная проверка могут доминировать в общей стоимости. Продолжайте измерять весь запрос и принятое результативное состояние.
Поведение провайдера считается переносимым
Автоматическое кэширование префиксов, явные точки разрыва, биллинг за хранение, минимальная длина промпта, подходящие модели и поля использования зависят от провайдера. Создайте адаптер провайдера и держите бизнес-метрику независимой от провайдера.
Fallback разрушает локальность кэша
Переключение провайдеров или семейств моделей может устранить повторное использование, поскольку кэши не переносятся. Это не означает, что fallback следует отключить. Это означает, что надежность и стоимость требуют общей политики: при необходимости выполняйте failover, а затем корректно учитывайте промах и дополнительную стоимость.
Контрольный список реализации у провайдера
Используйте адаптер провайдера, а не пытайтесь свести каждую реализацию к одному булевому полю cache_hit:
| Паттерн провайдера | Поля ROI для отслеживания | Основной риск моделирования |
|---|---|---|
| Автоматическое кэширование префикса | Кэшированные токены, некэшированные токены, режим хранения, ключ кэша, если поддерживается | Несовпадение префикса невидимо без версионированных трассировок |
| Явные точки разрыва | Токены создания кэша, токены чтения из кэша, TTL | Слишком много точек разрыва или записей может свести экономию на нет |
| Явно сохранённый контекст | Стоимость создания, количество кэшированных токенов, срок хранения и плата | Хранение без использования может стоить дороже, чем повторный ввод |
| Автоматическое ценообразование по попаданию/промаху | Токены cache-hit и cache-miss | Маршрутизация или смена модели сбрасывают локальность |
Перед включением prompt caching для модели подтвердите:
- Кэширование автоматическое, явное или и то и другое?
- Какие модели и API endpoint'ы это поддерживают?
- Какой минимальный размер prompt'а применяется?
- Как определяется совпадающий префикс?
- Какие существуют варианты TTL или хранения?
- Взимаются ли отдельно плата за запись в кэш, чтение из кэша и хранение?
- Какие поля ответа показывают кэшированные токены или создание кэша?
- Меняются ли поведение из-за service tier, региона, data residency или настроек zero-retention?
- Изолированы ли кэши по проекту, аккаунту, организации или другой границе?
- Что происходит, когда запрос переходит на другую модель или провайдера?
Используйте официальные материалы руководство OpenAI по prompt caching, документацию Anthropic по prompt caching, руководство Google Gemini по кэшированию контекста и руководство DeepSeek по кэшированию контекста для актуальных сведений о реализации. Цены и доступность моделей могут меняться, поэтому перепроверяйте эти источники при каждом существенном пересмотре затрат.
Проверка миграции 2026 для существующих дашбордов кэширования OpenAI
Если ваш дашборд создан до поддержки GPT-5.6, убедитесь, что он не объединяет все некэшированные токены префикса в обычную стоимость входных данных. Для поддерживаемых запросов GPT-5.6 отдельно проверяйте использование cache-write, фиксируйте режим хранения и различайте явные записи в кэш и автоматические чтения из кэша. Дашборд, который отслеживает только cached_tokens, может завышать экономию, если создание кэша оплачивается по более высокой ставке.
Где уместен AI gateway
Унифицированный AI gateway не делает кэши провайдеров переносимыми. Каждый провайдер по-прежнему контролирует собственную семантику кэширования и биллинг. Однако gateway может дать командам единое место для нормализации идентификаторов моделей, маршрутизации подходящих нагрузок, записи использования на уровне провайдера, сравнения стоимости на одну принятую задачу и применения политик fallback или бюджета.
Flatkey предоставляет один endpoint, совместимый с OpenAI, и единый баланс для доступа к нескольким семействам моделей. Это упрощает сравнение рабочих процессов с кэшем и без кэша, не перестраивая каждую интеграцию. Перед тем как считать маршрут поддерживающим кэш, подтвердите текущую поддержку кэширования и поведение провайдера для выбранной модели.
Если вы сначала консолидируете существующих клиентов, используйте контрольный список миграции на OpenAI-compatible API gateway и ознакомьтесь с текущими возможностями доступа к моделям и ценами Flatkey.
Часто задаваемые вопросы
Сколько может сэкономить prompt caching?
Экономия зависит от повторно используемого префикса, доли попаданий в кэш, тарифов провайдера, платы за запись или хранение и стоимости внедрения. Рассчитывайте чистую экономию на основе наблюдаемых кэшированных токенов, а не применяйте заявленную скидку ко всем входным токенам.
Сколько попаданий в кэш нужно для окупаемости?
Это зависит от надбавки за запись, скидки на чтение, платы за хранение и операционных затрат. Если запись тарифицируется по обычной цене без кэша и платы за хранение нет, первое успешное чтение уже дает валовую экономию токенов. Платные записи или удержание требуют большего повторного использования. Рассчитывайте точку безубыточности по точным ставкам и фактическому числу записей в кэш для выбранной модели.
Какая доля попаданий в кэш считается хорошей?
Универсального целевого значения нет. Полезная доля попаданий — это та, которая дает положительную чистую экономию и улучшает или сохраняет стоимость на одну принятую задачу. Большие префиксы могут оправдывать более низкую долю попаданий; небольшим префиксам может потребоваться очень высокий уровень повторного использования.
Ускоряет ли prompt caching задержку?
Он может снизить задержку обработки входных данных при попаданиях в кэш, но эффект зависит от провайдера, модели, размера промпта, сетевого пути и нагрузки. Отслеживайте задержку P50 и P95, а не предполагаемое фиксированное улучшение.
Стоит ли кэшировать весь разговор?
Обычно следует максимально использовать стабильный префикс, а не бездумно кэшировать все подряд. Ходы беседы растут и меняются. Сначала сохраняйте стабильные инструкции, инструменты и справочный контент, а затем добавляйте изменяющуюся историю и ввод пользователя.
Можно ли использовать кэшированные промпты у разных провайдеров?
Нет. Кэши промптов на стороне провайдера специфичны для каждого провайдера. Если при маршрутизации меняется провайдер или модель, считайте запрос, скорее всего, промахом кэша, если только провайдер прямо не документирует совместимое повторное использование.
Безопасен ли prompt caching для конфиденциальных данных?
Изучите обработку данных провайдером, изоляцию кэша, сроки хранения, регион хранения и условия zero-retention для вашего аккаунта и модели. Не используйте оптимизацию затрат, чтобы обходить требования безопасности, конфиденциальности или изоляции арендаторов.
Начните с одного повторяющегося префикса
Лучший рабочий процесс prompt caching намеренно узок: выберите одну дорогую нагрузку с высоким уровнем повторного использования; перенесите стабильный контент в начало; версионируйте его; измеряйте попадания, промахи, задержку, качество и стоимость; затем рассчитывайте чистый ROI.
Когда результат улучшает стоимость на одну принятую задачу, расширяйте подход на следующий рабочий процесс. Когда этого не происходит, телеметрия покажет, в чем проблема: фрагментация промпта, недостаточный объем, короткий срок хранения, цены провайдера или нагрузка, которая изначально не была хорошим кандидатом для кэширования.
