«Чтение из кэша дешевле на 90%»: AWS разобрала шесть сценариев prompt caching в Amazon Bedrock

Задача: один и тот же контекст в каждом запросе

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

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

Prompt caching решает задачу на уровне инфраструктуры. Когда в запросе есть маркер cachePoint, Amazon Bedrock проверяет, совпадает ли содержимое перед маркером с существующей записью кэша: при попадании (cache hit) модель пропускает повторную обработку этих токенов и может начать генерацию из закэшированного состояния, при промахе (cache miss) контент обрабатывается полностью и записывается в кэш для будущих запросов. По данным AWS это снижает время до первого токена (TTFT) и стоимость кэшированных входных токенов — вплоть до 90% на попаданиях, без изменения модели и качества промпта.

Правила игры: область, пороги и время жизни

Поведение кэша определяют четыре параметра. Область кэша: записи привязаны к конкретному аккаунту AWS и региону. Порог токенов: каждый чекпойнт должен его превысить, чтобы кэширование вообще включилось, — для Anthropic Claude Sonnet 4.5 и Sonnet 4.6 это не меньше 1 024 токенов на чекпойнт, для моделей Opus — не меньше 4 096.

Два оставшихся параметра — срок жизни записи и синтаксис. TTL по умолчанию равен 5 минутам, а отдельные модели поддерживают до 1 часа. Маркер cachePoint при этом одинаков для поддерживаемых семейств моделей, включая Anthropic Claude и Amazon Nova, поэтому переключение между ними не требует менять код кэширования.

Документация Amazon Bedrock добавляет важное различие. Implicit caching — режим, в котором Bedrock и модель сами пытаются переиспользовать подходящие префиксы промпта без каких-либо маркеров в запросе; он работает по принципу best effort, и повторение идентичного промпта не гарантирует попадание, а доля попаданий может меняться. Explicit caching — режим разбора: переиспользуемые префиксы задаются вручную через cache checkpoint, а сами префиксы должны оставаться неизменными между запросами, иначе получается промах.

Ещё одна деталь из документации касается срока жизни записи: TTL сбрасывается при каждом успешном попадании в кэш, и если запросов в окне не было, запись истекает.

Экономика: +25% за запись, −90% за чтение

Кэширование добавляет к обычным входным и выходным токенам две категории. cacheWriteInputTokens — токены, записанные в кэш на первом запросе, — стоят на 25% дороже стандартного входа; cacheReadInputTokens — токены, прочитанные из кэша на последующих запросах, — на 90% дешевле. Запись с часовым TTL обходится вдвое дороже стандартного входа.

На повторяющемся контексте выигрыш получается около 75% по входным токенам: в примере AWS первый из десяти запросов с документом на 10 000 токенов платит за запись, а остальные девять читают из кэша со скидкой 90%. Оговорка одна и она важная — окно TTL: запросы после истечения записи запускают новую запись и уменьшают итоговую экономию.

Шесть сценариев из разбора

Первый сценарий — кэширование содержимого сообщения: cachePoint ставится между статическим документом и динамическим вопросом, и в кэш уходит всё, что выше маркера. Второй — системный промпт: маркер добавляется внутрь параметра system, отдельно от сообщений пользователя. Третий — описания инструментов: cachePoint становится последним элементом массива tools внутри toolConfig, а сами схемы должны совместно превышать порог токенов.

Четвёртый — смешанный TTL: у каждого чекпойнта может быть своё поле ttl, но с ограничением по порядку — более долгие записи обязаны идти раньше коротких, то есть часовые перед пятиминутными. Пятый — изоляция арендаторов: к кэшируемому содержимому добавляют префикс из SHA-256-хэша идентификатора арендатора, поэтому у каждого арендатора появляется отдельная запись кэша, а накладные расходы составляют 64 символа, примерно 16 токенов. Шестой — интеграция с LangChain: метод ChatBedrockConverse.create_cache_point() сам формирует нужный блок cachePoint внутри сообщения или шаблона промпта.

Чем отличаются API и что советует AWS

Разбор собран на Converse API, где синтаксис маркера одинаков для разных моделей: {"cachePoint": {"type": "default"}}. В InvokeModel API у Anthropic маркер другой — cache_control с типом ephemeral и полем ttl, — и различия есть в деталях: блок cacheDetails в ответе доступен только в Converse API, а ключи в usage называются по-разному — cacheWriteInputTokens против cache_creation_input_tokens. Именно из-за переносимости синтаксиса AWS советует Converse API для новых приложений.

В рекомендациях для продакшена — профилировать промпты и кэшировать статические части, соблюдать порог токенов, подбирать TTL по частоте использования (час для редко меняющихся описаний инструментов, пять минут для контекста сессии), следить за метриками cacheWriteInputTokens и cacheReadInputTokens, подключать Amazon Bedrock Guardrails, изолировать кэш арендаторов в мультитенантных системах и учитывать, что у моделей Anthropic один cachePoint может накрывать несколько предшествующих блоков, а системный промпт, содержимое сообщения и описания инструментов можно кэшировать в одном запросе, складывая экономию.

Примеры в разборе рассчитаны на модель global.anthropic.claude-sonnet-4-5-20250929-v1:0 в регионе us-west-2, Python 3.10 и новее, boto3 не ниже 1.43.0 — эта версия нужна для параметра ttl — и langchain-aws не ниже 0.2.12. Готовые ноутбуки и скрипты AWS обещает в репозитории amazon-bedrock-samples.