Amazon Bedrock теперь предлагает кэширование промптов для Claude 4.6 — функцию, которая может сократить задержку ответа и снизить затраты на инференс для приложений на базе генеративного ИИ. Эта возможность работает за счет запоминания статичной части промпта на срок до пяти минут, благодаря чему последующие вызовы позволяют избежать дорогостоящей повторной обработки этого текста.

Как кэш встраивается в цепочку запросов

Когда поступает запрос к Claude 4.6, взаимодействуют два уровня.

  • Уровень модели — Claude 4.6 поддерживает KV-кэш (ключ-значение) в памяти GPU. При первом парсинге модель обрабатывает блок инструкций и сохраняет его внутреннее представление. При последующих вызовах с использованием того же блока модель может извлечь готовое представление вместо того, чтобы вычислять его заново.

  • Уровень Bedrock — Bedrock вычисляет «отпечаток» (fingerprint) статического сегмента промпта. Если новый запрос имеет совпадающий отпечаток, Bedrock направляет его напрямую на тот GPU, который уже содержит кэшированное состояние, минуя этап «разогрева».

Представьте это как загрузку сохраненной игры, а не начало новой каждый раз.

Правила, поддерживающие актуальность кэша

  1. Минимальное количество токенов — Claude Sonnet 4.6 требует как минимум 1024 токена в кэшируемом сегменте; Claude Opus 4.6 — 4096 токенов. Все, что меньше, игнорируется.

  2. Пятиминутный срок жизни — Кэш истекает через пять минут бездействия. Каждое попадание в кэш (hit) сбрасывает таймер, поэтому непрерывный поток вызовов может поддерживать кэш активным бесконечно долго.

  3. Порядок промпта — Bedrock читает промпт последовательно. Статичные инструкции должны идти первыми, затем должен следовать маркер cachePoint, а все сообщения пользователя — после этого маркера. Изменение даже одного символа перед маркером нарушает отпечаток и вынуждает выполнять «холодное» чтение.

Применение функции на практике

Точкой входа является Bedrock Converse API. Ниже приведен минимальный фрагмент кода на Python, демонстрирующий необходимую структуру.

import boto3

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
MODEL_ID = "anthropic.claude-sonnet-4-6"

# Must be >1,024 tokens for Sonnet
BASE_SYSTEM_PROMPT = "Your long instructions here..."

system_configuration = [
    {"text": BASE_SYSTEM_PROMPT},
    {"cachePoint": {"type": "default"}}
]

conversation_history = []

def run_chat_turn(user_input):
    global conversation_history
    conversation_history.append(
        {"role": "user", "content": [{"text": user_input}]}
    )

    response = bedrock.converse(
        modelId=MODEL_ID,
        system=system_configuration,
        messages=conversation_history,
        inferenceConfig={"maxTokens": 500, "temperature": 0.4}
    )

    assistant_message = response["output"]["message"]
    conversation_history.append(assistant_message)

    metrics = response["usage"]
    print(f"Read from cache: {metrics.get('cacheReadInputTokens', 0)}")

cachePoint указывает Bedrock, где заканчивается неизменяемый сегмент. После первого вызова метрика cacheReadInputTokens должна показывать ненулевое значение, подтверждая, что кэш был использован.

Почему это важно для разработчиков

Отделение статичных инструкций от динамического пользовательского ввода переносит нагрузку с дорогостоящих циклов GPU на легкий этап маршрутизации. Для чат-ботов, конвейеров RAG (retrieval-augmented generation) или любых сервисов, повторяющих один и тот же системный промпт, результатом станут более быстрые ответы и меньшее количество оплачиваемых токенов. В сценариях с высокой пропускной способностью даже небольшое сокращение времени вычислений может привести к заметной экономии средств.

Ограничения и компромиссы

Функция полезна только тогда, когда сегмент промпта соответствует минимальному количеству токенов и остается неизменным. Приложения, которые часто меняют системные инструкции или полагаются на короткие промпты, не получат значительной выгоды. Пятиминутное окно также означает, что при всплесковом трафике с длительными периодами бездействия может постоянно происходить «холодное» чтение, что нивелирует преимущество в задержке. Наконец, кэш живет в памяти GPU; если несколько моделей используют одно и то же оборудование, конкуренция за ресурсы может повлиять на производительность, хотя Bedrock не раскрывает эти детали.

На что обратить внимание в дальнейшем

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

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