Prompt caching: как работает кэширование промптов

Prompt caching: как работает кэширование промптов — это переиспользование уже посчитанных промежуточных состояний модели для неизменного начала запроса. Модель хранит key-value тензоры обработанного префикса, и следующая просьба с тем же началом читает их из кэша. Готовый текст ответа при этом не сохраняется.

Что именно переиспользуется

Когда модель обрабатывает входные токены, она вычисляет промежуточные состояния — key-value (KV) состояния. Эти состояния позволяют модели ссылаться на более ранние токены, пока она обрабатывает новый вход и порождает выходные токены. В документации OpenAI это описано прямо: кэш промпта хранит промежуточные key-value тензоры обработанного префикса.

Кэшируется результат вычисления по префиксу. Префикс — это неизменённые токены в начале запроса. Когда более поздний запрос имеет тот же префикс и находит совпадающую запись кэша, модель переиспользует сохранённое состояние вместо повторной обработки этих токенов. Новый вход она всё равно обрабатывает, чтобы породить новый ответ.

Отсюда следуют три практических вывода. Первый: переиспользуются промежуточные вычисления. Второй: экономия касается входных токенов, выходные токены считаются как обычно. Третий: запрос всё равно уходит в API, и ответ всё равно генерируется заново.

Документация Microsoft для Azure OpenAI формулирует это так: сервис сохраняет временный кэш вычислений обработанных входных токенов, чтобы повысить общую производительность. Там же сказано, что кэширование промпта не влияет на содержание ответа модели помимо снижения задержки и стоимости.

Что попадает в кэшируемый префикс. По документации OpenAI кэшируется полный отрендеренный контекст: инструкции, которые добавляет сам провайдер, сообщения разработчика, определения инструментов и история переписки с текстом, изображениями, документами и поддерживаемым аудио. По документации Claude кэш промпта ссылается на весь промпт: инструменты, системные сообщения и сообщения — именно в этом порядке, вплоть до блока, помеченного cache_control.

Порядок уровней важен, потому что он образует иерархию. В документации Claude сказано: префиксы кэша создаются в порядке tools, system, затем messages, и каждый уровень надстраивается над предыдущими. Изменение на уровне инвалидирует этот уровень и все последующие.

Практический смысл для читателя простой. Если вы хотите переиспользовать вычисление, вам нужно, чтобы байты начала запроса совпадали между вызовами. Всё, что меняется от запроса к запросу, должно стоять после неизменной части.

Кэш префикса и готовый ответ

Три механизма часто называют одним словом «кэш», и это порождает путаницу в расчётах и ожиданиях.

Кэш префикса хранит KV-тензоры обработанного начала запроса. Совпадение должно быть точным по префиксу. Модель всё равно генерирует новый ответ.

Кэш готового ответа хранит сам текст ответа и отдаёт его при совпадении запроса. Такой механизм экономит и выходные токены, и вызов модели.

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

Память агента и дообучение модели — отдельные вещи. Память хранит факты о пользователе или сессии и подмешивает их в промпт. Дообучение меняет веса модели. Ни то, ни другое не является кэшем префикса.

Различие видно на бытовом примере. Кэш префикса — это как заранее разогретый станок: заготовка уже закреплена, но деталь вытачивается заново. Кэш готового ответа — это склад готовых деталей: нужную берут и отдают.

Документация OpenAI отдельно предупреждает: кэширование промпта не меняет то, как модель порождает выходные токены, и одинаковые запросы не гарантируют одинаковый результат. Это прямо опровергает ожидание «ответ придёт из кэша дословно».

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

Практический тест для читателя. Нулевые выходные токены сами по себе не определяют вид кэша: проверьте режим и завершение запроса. Например, документация OpenAI описывает prewarm, который готовит кэш промпта без генерации ответа. Кэш префикса переиспользует входные вычисления и не подменяет генерацию сохранённым текстом.

Общие инструкции впереди, вопрос в конце

Основное правило структуры: стабильное содержимое идёт в начало промпта, изменяемое — в конец. Документация OpenAI называет это первым пунктом оптимизации: сохраняйте префикс стабильным, размещайте стабильные инструкции разработчика и общий справочный материал в начале.

Документация Claude даёт ту же рекомендацию в разделе о структуре промпта: размещайте статическое содержимое — определения инструментов, системные инструкции, контекст, примеры — в начале промпта и отмечайте конец переиспользуемого содержимого параметром cache_control.

Разберём учебную структуру. В этой ручной трассе задан порядок блоков; запросы к API не отправлялись.

Инструкция: отвечай только по справочнику ниже. Если ответа нет, напиши: В справочнике нет ответа.
Справочник product-v1:
Возврат возможен в течение 14 дней после покупки.
Для возврата нужен номер заказа.
Гарантия на товар — 12 месяцев с даты покупки.
Доставка занимает 3 рабочих дня.

Между этим префиксом и вопросом ставится один перенос строки. Дальше идут четыре варианта запроса.

R1: префикс плюс «Как вернуть товар?». Ожидаемый смысл ответа — 14 дней и номер заказа.

R2: префикс плюс «Какая гарантия?». Ожидаемый смысл — 12 месяцев. Общий префикс структурно сохранён, попадание возможно при выполнении условий провайдера.

R3: «Текущее время 09:01», перенос строки, префикс, перенос строки, «Какая гарантия?». Начало запроса изменено, и совпадение прежнего префикса внутри текста не гарантирует переиспользование.

R4: версия справочника product-v2 плюс «Какая гарантия?». Ожидаемый смысл — 6 месяцев, потому что новая версия источника заменяет старую политику.

Полный изменённый префикс для R4:

Инструкция: отвечай только по справочнику ниже. Если ответа нет, напиши: В справочнике нет ответа.
Справочник product-v2:
Возврат возможен в течение 14 дней после покупки.
Для возврата нужен номер заказа.
Гарантия на товар — 6 месяцев с даты покупки.
Доставка занимает 3 рабочих дня.

Что здесь видно. R1 и R2 делят общий префикс, поэтому у них есть шанс на переиспользование. R3 ломает начало и теряет это преимущество. R4 меняет сам справочник, поэтому прежняя запись кэша к нему не относится.

Порядок блоков в реальном запросе. Документация OpenAI перечисляет уровни отрендеренного контекста: скрытое системное сообщение провайдера, определения инструментов, сообщение разработчика, затем история контекста. Стабильные инструкции и справочный материал размещаются в сообщении разработчика, а изменяемые сведения — в последующих сообщениях.

Документация Claude описывает ту же иерархию и добавляет важное уточнение: если в системных инструкциях или общем материале есть метки времени, пользовательские данные или другой динамический контент, размещайте их после стабильного содержимого.

Частая ошибка новичка — положить текущую дату или идентификатор сессии в системное сообщение. Это сдвигает всё, что идёт после, и делает префикс уникальным для каждого запроса.

Четыре изменения входа

Проверим, что происходит с переиспользованием при разных правках. Результат везде потенциальный: он зависит от условий провайдера, модели и настроек.

Изменение первое: правка в стабильной части. Документация Claude показывает таблицу инвалидации. Изменение определений инструментов — имён, описаний, параметров — инвалидирует весь кэш. Включение или выключение веб-поиска меняет системный промпт и инвалидирует системный и пользовательский кэш. Переключение между быстрым и стандартным режимом инвалидирует системный кэш и кэш сообщений.

Изменение второе: правка в переменной части. Здесь переиспользование возможно. Документация Azure OpenAI описывает явные точки останова: содержимое после точки останова может меняться, не инвалидируя кэшированный префикс. Документация OpenAI говорит то же про явный режим: содержимое после последней выбранной точки останова обрабатывается по обычной ставке входных токенов без платы за запись в кэш.

Изменение третье: сдвиг начала. Если вы добавляете что-то перед стабильным блоком, прежний префикс перестаёт быть префиксом. Документация OpenAI разбирает этот случай отдельно: расширение сообщения может помешать переиспользованию его кэшированного префикса. Если запрос 1 заканчивался сообщением с содержимым A, а запрос 2 расширяет то же сообщение до A плюс B, старая граница оказалась внутри сообщения, и без явной точки останова на этой границе запрос 2 не переиспользует сохранённый префикс.

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

Читательский вывод: планируйте точки останова по частоте изменений. Инструменты меняются редко, справочник — раз в день, вопрос — каждый запрос. Документация Claude приводит именно такой пример: системные инструкции меняются редко, контекст RAG обновляется ежедневно, и две точки останова кэшируют их раздельно.

Поддержка модели, минимум, TTL, write и read

Здесь начинаются различия между провайдерами, и переносить правила одного на другого нельзя.

Минимальный объём. Документация Azure OpenAI требует не менее 1 024 токенов в длине запроса и совпадения первых 1 024 токенов. Документация OpenAI называет минимум 1 024 токена для GPT-5.6 и более поздних моделей; для более ранних моделей минимум зависит от настроек запроса, включая инструменты, изображения, схемы вывода, усилие рассуждения и подробность. Документация Claude приводит разные пороги по моделям: 512 токенов для Claude Fable 5.1, Claude Mythos 5.1, Claude Opus 5.5, Claude Opus 5, Claude Sonnet 5.5, Claude Fable 5, Claude Mythos 5 и Claude Haiku 5.5; 2 048 токенов для Claude Mythos Preview и Claude Opus 4.7; 4 096 токенов для Claude Opus 4.6 и Claude Opus 4.5; 1 024 токена для Claude Opus 4.8, Claude Sonnet 5, Claude Sonnet 4.6, Claude Sonnet 4.5, Claude Opus 4.1, Claude Opus 4 и Claude Sonnet 4; 4 096 токенов для Claude Haiku 4.5. Документация Amazon Bedrock указывает, что минимумы по моделям лежат в диапазоне от 512 до 4 096 токенов на контрольную точку.

TTL и правила записи. Документация Claude: по умолчанию кэш живёт 5 минут, время отсчитывается от начала запроса, который пишет или читает запись, и каждый раз при использовании кэш обновляется без дополнительной платы. Есть вариант на 1 час за дополнительную плату. Документация Azure OpenAI для моделей GPT-5.6 и новее задаёт минимальное время жизни через prompt_cache_options.ttl со значениями 30 минут по умолчанию и 12 часов на поддерживаемых развёртываниях Responses API. Документация OpenAI для GPT-5.6 и новее даёт те же значения: 30 минут по умолчанию и 12 часов в Responses API.

Ставки записи и чтения. Документация Claude: запись с TTL 5 минут стоит 1,25 от базовой цены входных токенов, запись с TTL 1 час — 2 от базовой цены, чтение — 0,1 от базовой цены с исключениями по моделям. Документация OpenAI: для GPT-5.6 и новее запись стоит 1,25 от обычной ставки входных токенов при времени жизни 30 минут и 2,5 при времени жизни 12 часов; чтение — 0,1 от обычной ставки на большинстве этих моделей и 0,05 на GPT-6.1 Sol и GPT-6.1 Terra. Документация Azure OpenAI отмечает, что для моделей до семейства GPT-5.6 запись в кэш не тарифицируется дополнительно, а на GPT-5.6 и новее может тарифицироваться.

Правила чтения и записи. Документация Azure OpenAI: каждый запрос может создать до четырёх новых записей в кэш; в неявном режиме точка останова на последнем сообщении занимает один слот записи, поэтому запрос может записать до трёх последних явных точек останова; в явном режиме — до четырёх последних явных точек останова. Документация Claude: можно определить до четырёх точек останова, а окно поиска назад составляет 20 блоков.

Проверка перед внедрением. Возьмите документацию вашего провайдера и вашей модели, выпишите четыре числа: минимальный объём, TTL, ставку записи, ставку чтения. Без этих четырёх чисел расчёт расхода остаётся догадкой.

Cache usage в ответе

Смотреть на скорость — ненадёжный способ судить о попадании. Документация OpenAI прямо говорит: минимальное время жизни определяет право на ставку чтения из кэша и не гарантирует, что каждый запрос переиспользует сохранённые KV-тензоры или получит меньшую задержку.

Свидетельство лежит в поле usage. Документация Azure OpenAI: попадания показываются как cached_tokens внутри prompt_tokens_details в ответе chat completions. На GPT-5.6 и новее стандартные развёртывания с оплатой по мере использования показывают чтения из кэша в cached_tokens, а записи — в cache_write_tokens.

Документация Claude даёт три поля и формулу. cache_creation_input_tokens — число токенов, записанных в кэш при создании новой записи. cache_read_input_tokens — число токенов, прочитанных из кэша в этом запросе. input_tokens — число входных токенов, которые не были прочитаны из кэша и не использованы для его создания, то есть токены после последней точки останова. Общее число входных токенов считается как сумма этих трёх полей.

Важное следствие: input_tokens не равно всем отправленным входным токенам. Документация Claude приводит пример: при 100 000 токенов кэшированного содержимого, нуле новых токенов записи и 50 токенах в сообщении пользователя общее число обработанных входных токенов составит 100 050.

Документация Amazon Bedrock приводит ту же формулу для Converse API: общее число входных токенов равно сумме inputTokens, cacheReadInputTokens и cacheWriteInputTokens. Там же сказано, что при включённом кэшировании поле inputTokens представляет только некэшированные входные токены.

Как читать usage на практике. Нулевое cached_tokens при ненулевом cache_write_tokens означает, что запись произошла, а чтения не было. Ненулевое cached_tokens при нулевом cache_write_tokens означает полное совпадение с существующей записью. Оба поля нулевые означают, что кэширование не сработало вовсе.

Документация Claude добавляет: если оба поля cache_creation_input_tokens и cache_read_input_tokens равны нулю, промпт не был закэширован, вероятно из-за недостижения минимальной длины.

Журнал проверки в живом API. Записывайте провайдера, модель, версию, хеш префикса, время, значения cache_write и cache_read из usage, новый вопрос и правильность ответа. Такой журнал отделяет факт попадания от впечатления о скорости.

Отрицательный контроль. Два вывода неверны: «ответ одинаковый, значит было попадание» и «быстро, значит бесплатно». Попадание не доказывает истинность документа и не означает, что готовый ответ сохранён.

Обновление справочника и версионирование

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

Отсюда практика версионирования. В учебном примере справочник помечен как product-v1 и product-v2. Версия входит в сам текст префикса, поэтому новая версия даёт новый префикс, а старая запись кэша к ней не применяется.

Документация Azure OpenAI показывает это в примере с ключом кэша: tenant:contoso:product-manual-v2. Ключ содержит версию справочника. Документация OpenAI приводит похожий пример: agent_123_v1:user_456 для раздельного учёта кэша по пользователю.

Порядок действий при обновлении справочника:

1. Соберите новый текст справочника и присвойте ему новую версию в идентификаторе.
2. Обновите версию в ключе кэша, если он используется.
3. Убедитесь, что обновлённый справочник достигает минимального кэшируемого объёма для вашей модели.
4. Отправьте первый запрос и зафиксируйте cache_write_tokens вместе с чтениями из кэша; нулевая запись сама по себе не доказывает сбой, если подходящий префикс уже доступен для чтения.
5. Отправьте второй запрос с тем же префиксом и проверьте cached_tokens.
6. Сверьте смысл ответа с новой версией справочника, чтобы старая политика не подменяла новую.

Пункт шестой важен отдельно. В учебном примере R4 ожидает 6 месяцев гарантии, потому что справочник обновлён до product-v2. Если ответ возвращает 12 месяцев, он противоречит product-v2; проверьте фактически отправленный справочник, историю и другие инструкции, прежде чем определять причину.

Документация Claude описывает разделение по частоте изменений через несколько точек останова: инструменты меняются редко, контекст обновляется ежедневно, и две точки останова кэшируют их независимо. При обновлении документов RAG с сохранением инструментов и инструкций первые два сегмента кэша остаются валидными.

Документация OpenAI добавляет про инструменты: сохраняйте определения, порядок и схемы инструментов; для отключения инструментов в запросе устанавливайте tool_choice в значение "none" вместо удаления определений; для включения только выбранных инструментов используйте allowed_tools, сохраняя переданный список tools стабильным.

Отдельная тонкость из документации Claude: ключи в блоках tool_use должны иметь стабильный порядок, поскольку некоторые языки, например Swift и Go, рандомизируют порядок ключей при преобразовании JSON, что ломает кэш.

Расход по фактическим writes и reads

Расчёт строится на трёх числах из usage и ставках вашего провайдера. Универсальной скидки не существует: множители зависят от модели и выбранного времени жизни.

Документация OpenAI приводит пример расчёта. При цене входных токенов 1 доллар за миллион токенов и цене кэшированного входа 0,10 доллара за миллион расход для конкретного usage считается как сумма обычных входных токенов по обычной цене, кэшированных токенов по цене кэшированного входа, токенов записи с TTL 30 минут по ставке 1,25 и токенов записи с TTL 12 часов по ставке 2,5. В примере это даёт 0,01515 доллара за вход.

Документация OpenAI предупреждает: не добавляйте cache_write_tokens повторно после учёта двух его компонентов. Поля ttl_30m_tokens и ttl_12h_tokens не пересекаются и в сумме дают cache_write_tokens.

Сравнение сценариев из документации OpenAI. При ставке чтения 0,1 и записи 30 минут однократная запись префикса с однократным полным переиспользованием стоит 1,35 от обычной стоимости входа против 2 при двукратной обработке без кэширования. На десяти запросах одна запись и девять полных чтений стоят 2,15 против 10 без кэширования.

Ловушка минимального объёма. Документация OpenAI описывает её так: если множество запросов переиспользует одни и те же инструкции разработчика и определения инструментов, но общий префикс не достигает минимальной кэшируемой длины, стоит рассмотреть сокращение или расширение префикса полезными стабильными инструкциями, примерами или справочным материалом. Там же приведена формула точки безубыточности: при минимальной длине 1 024 токена, ставке чтения 0,1 и ставке записи 1,25 точка безубыточности равна 102,4 плюс 1 177,6, делённое на число запросов. На десяти запросах расширение исходного префикса не менее 221 токена до 1 024 токенов дешевле. При росте переиспользования порог приближается к 102,4 токена. Префикс в 103 токена требует не менее 1 963 запросов для выгоды, а префикс в 102 токена и меньше не даёт выгоды при этих допущениях.

Оговорка из той же документации: это сравнение исключает производительность, выходные токены и неизменные расходы запроса; дополнительные промахи, записи или другие ставки модели меняют результат.

Что делать читателю. Возьмите фактические cached_tokens, cache_write_tokens и обычные входные токены за период. Умножьте каждую группу на ставку вашей модели. Сложите. Сравните с тем, что было бы без кэширования, то есть со всей суммой входных токенов по обычной ставке. Разница и есть эффект.

Документация Claude добавляет про смешивание TTL: можно использовать оба контроля в одном запросе, но записи с более длинным TTL должны идти перед более короткими. При смешивании API определяет три позиции выставления счёта: последнее попадание в кэш, последний блок с часовым TTL после него и последний блок cache_control. Читаются токены до первой позиции, часовые записи считаются для разницы между первой и второй, пятиминутные — между второй и третьей.

Как разобрать неверный ответ после обновления

Разберём условный сбой: приложение должно отвечать по product-v2, но в ответе снова появились двенадцать месяцев гарантии. Сам ответ пока ничего не доказывает о кэше. Начните с того, какой материал действительно попал в запрос. Откройте сохранённый вход проблемного обращения и найдите строку о гарантии. Если там осталась старая политика, сначала исправьте выбор справочника. Настройка кэширования не исправит документ, который приложение само отправляет в модель.

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

Следующий шаг — отделить содержимое запроса от его отображения в интерфейсе. Приложение может показывать в карточке одну версию документа, а передавать другую. Для расследования нужен фактический отправленный текст с сохранённым порядком блоков. Сравните его с тем файлом, который вы считаете новым справочником. Если копировать данные вручную, легко пропустить дополнительный пробел, прежний заголовок или старую вставку. Поэтому сохраняйте исходный материал и собранный запрос раздельно.

Теперь сверьте ответ с допустимым эталоном. Для product-v2 правильный смысл — шесть месяцев с даты покупки. Наличие слов о гарантии без срока не закрывает вопрос пользователя. Ответ про двенадцать месяцев противоречит новой политике. Фраза об отсутствии ответа тоже требует проверки: нужная строка в справочнике есть. Эти решения выносит содержательная проверка, и они остаются такими же при попадании в кэш и при промахе.

Только после проверки входа и ответа переходите к сведениям о переиспользовании. Возьмите usage именно проблемного запроса и сопоставьте его с выбранным провайдером. Если данные недоступны, зафиксируйте неизвестный статус. В таком случае можно установить ошибку ответа, но нельзя утверждать, что причиной был cache hit. Разделение вывода о качестве и вывода о вычислениях помогает не менять настройки наугад.

Как подготовить рабочую проверку своего справочника

Перенесите учебный приём на небольшой фрагмент собственного документа. Выберите правило, которое можно проверить однозначно: срок, условие обращения или перечень обязательных данных. Сформулируйте вопрос словами пользователя. Рядом запишите ожидаемый смысл и допустимые варианты формулировки. Если в документе сказано, что нужен номер заказа, ответ должен сохранить это условие; вежливый ответ без него неполон. Такой эталон пригодится и для сравнения версий документа.

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

Для проверки новой редакции поменяйте одно осмысленное правило и сохраните оба текста целиком. Заранее запишите, какие вопросы должны получить другой ответ, а какие сохраняют прежний смысл. В нашем случае изменение гарантии не меняет условия возврата. Если после обновления изменились оба ответа, откройте фактические входы и проверьте, не поменялись ли другие инструкции. Так вы отделите последствия выбранной правки от случайных различий между обращениями.

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

При передаче проверки коллеге приложите исходный документ, собранный запрос и ожидаемый смысл ответа. Попросите сначала найти опору каждого условия в документе, затем оценить результат. Если проверяющие расходятся, уточните эталон: возможно, вопрос допускает несколько толкований или документ не объясняет исключение. Уточнение критерия полезнее бесконечного изменения температуры, порядка сообщений или параметров кэша без понимания причины расхождения.

Наконец, заранее определите условие завершения проверки. Вход должен содержать выбранную версию, ответ должен соответствовать её правилам, а сведения о расходе должны относиться к тому же обращению. При неизвестном usage оставьте вывод об экономии открытым. При неверном ответе исправьте содержательную причину и повторите тот же вопрос. При верном ответе и подтверждённом переиспользовании сохраните обе части доказательства отдельно: правильность документа и факт чтения кэша.

Частые вопросы

Что такое prompt caching простыми словами?

Это переиспользование уже посчитанных промежуточных состояний модели для неизменного начала запроса. Модель хранит KV-тензоры обработанного префикса, и следующий запрос с тем же началом читает их вместо повторного счёта. Готовый текст ответа при этом не сохраняется, и модель всё равно генерирует новый ответ. Экономия касается входных токенов и времени обработки входа.

Чем prompt caching отличается от response caching?

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

Как работает prompt caching в Claude?

Документация Claude описывает два способа включения. Автоматический: одно поле cache_control на верхнем уровне запроса, система сама ставит точку останова на последнем кэшируемом блоке и двигает её вперёд по мере роста переписки. Явный: cache_control ставится на отдельные блоки содержимого для точного контроля. По умолчанию кэш живёт 5 минут и обновляется при каждом использовании без дополнительной платы.

Почему кэш не срабатывает при одинаковом промпте?

Причин несколько. Префикс может не достигать минимального кэшируемого объёма для вашей модели. Точка останова может стоять на блоке, который меняется каждый запрос, например на метке времени. Между запросами могло пройти больше времени, чем TTL. Документация Claude разбирает случай, когда точка останова стоит на изменяющемся блоке: поиск назад не находит стабильное содержимое за точкой останова, он находит только записи, сделанные предыдущими запросами.

Как проверить, что кэш действительно сработал?

Смотрите поля usage в ответе. Документация Azure OpenAI указывает cached_tokens внутри prompt_tokens_details для чтений и cache_write_tokens для записей. Документация Claude даёт три поля: cache_creation_input_tokens, cache_read_input_tokens и input_tokens, а общее число входных токенов считается как их сумма. Ненулевое cached_tokens при нулевой записи означает полное совпадение с существующей записью. Скорость ответа свидетельством не является.