Amazon Bedrock: как кэширование промптов снижает затраты и задержки
AWS Machine Learning · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
Функция кэширования промптов в Amazon Bedrock позволяет сократить расходы на входные токены до 90% при повторной отправке одинакового контекста. Механизм работает на уровне инфраструктуры, сохраняя качество модели и снижая время ожидания первого токена.
Ценность: Для разработчиков, работающих с LLM, оптимизация стоимости и латентности критична при масштабировании приложений. Кэширование промптов в Amazon Bedrock предлагает инфраструктурное решение, которое устраняет необходимость в компромиссах между длиной контекста и ценой, позволяя эффективно обрабатывать большие объемы статических данных, таких как документы, системные инструкции и схемы инструментов.
При работе с большими языковыми моделями через Amazon Bedrock разработчики часто сталкиваются с дублированием затрат. Если в запросе используется длинный контекст — например, юридический договор или база знаний — и к нему последовательно применяются разные вопросы, модель каждый раз перерабатывает одни и те же входные токены. Традиционные методы оптимизации, такие как укорачивание промптов или сокращение окна контекста, часто приводят к потере качества анализа. Кэширование промптов в Amazon Bedrock решает эту проблему на инфраструктурном уровне: система сохраняет обработанный префикс запроса и переиспользует его при последующих обращениях. По данным AWS, это снижает стоимость входных токенов до 90% при попадании в кэш (cache hit), не требуя изменений в коде модели или качестве промпта.
Механизм работает через специальный маркер cachePoint в API Converse. При отправке запроса Bedrock проверяет, совпадает ли контент перед маркером с существующим кэшем. Если совпадение найдено, модель пропускает повторную обработку этих токенов и начинает генерацию ответа из сохраненного состояния. Это не только экономит деньги, но и сокращает время до первого токена (TTFT). Для небольших документов эффект на латентности может быть незаметным, однако для контекстов свыше 10 000 токенов снижение задержки становится значительным. Важно учитывать, что кэши привязаны к конкретному AWS-аккаунту и региону, а также имеют минимальный порог в токенах: например, для моделей Anthropic Claude Sonnet 4.5 и 4.6 он составляет 1024 токена, а для Opus — 4096.
В материале рассматриваются шесть практических сценариев применения технологии. Первый — кэширование содержимого сообщений: размещение маркера после статического документа и перед динамическим вопросом позволяет переиспользовать документ при серии запросов. Второй сценарий касается системных промптов: детальные инструкции по роли ассистента или правила поведения остаются неизменными между диалогами, что делает их идеальными кандидатами для кэширования. Третий вариант — кэширование определений инструментов (tool definitions). В агентных сценариях схемы API и базы данных могут занимать тысячи токенов; их кэширование предотвращает повторную обработку этих структур на каждом шаге диалога.
Более сложные паттерны включают смешанное время жизни кэша (Mixed TTL). Разработчики могут назначать разные периоды истечения для различных слоев контента: например, 1 час для неизменяемых справочных данных и 5 минут для сессионного контекста. API требует строгого порядка: чекпоинты с более длительным TTL должны идти перед теми, у которых он короче. Для многопользовательских приложений критична изоляция данных. Поскольку кэш внутри одного аккаунта может быть общим, AWS рекомендует использовать префикс SHA-256 хэша идентификатора арендатора (tenant_id) перед кэшируемым контентом. Это создает отдельные записи кэша для каждого пользователя с минимальными накладными расходами — около 16 токенов.
Интеграция доступна через стандартные инструменты, включая фреймворк LangChain, где метод create_cache_point() упрощает работу с сырым API. При выборе между Converse API и InvokeModel API рекомендуется использовать первый: синтаксис cachePoint в нем универсален для разных семейств моделей (Anthropic Claude и Amazon Nova), что облегчает миграцию между провайдерами без переписывания кода кэширования. Для максимальной эффективности AWS советует профилировать промпты, четко разделяя статические и динамические компоненты, а также выбирать TTL в зависимости от частоты обновления данных. При расчете итоговой экономии следует учитывать стоимость записи в кэш при первом запросе: при десяти последовательных обращениях к одному документу общая экономия на входных токенах составляет примерно 75%.