Подробный разбор · Около 5 мин чтения
AWS объясняет кэширование промптов для агентов Bedrock: стабильные префиксы и разные примеры затрат
Руководство сочетает явный общий префикс с неявным кэшированием истории и разделяет инструменты, помощников, модельные затраты и мониторинг конечных точек.
- Опубликовано здесь
- Дата источника
- Источник проверен
В инженерном руководстве AWS от 26 октября Claudio Mazzoni описывает повторное использование вычислений агентами с моделями OpenAI в Amazon Bedrock. Это учебный материал, а не анонс новой модели. Анализ основан на полном тексте и графиках; AISubHub не запускал код и независимо не измерял стоимость, задержку или доступность.
Слушать новости
Прослушайте эту статью или включите новости подряд.
Подготовка чтения…
Голос устройства
Речь обрабатывает браузер или устройство. AISubHub не отправляет текст в аудио-API. Доступные голоса и работа при заблокированном экране зависят от устройства.
При продолжении короткая фраза может повториться.
Кратко
- Префикс должен содержать минимум 1 024 токена. AWS указывает минимум 30 минут после записи либо успешного повторного использования и стоимость записи в 1,25 раза выше обычного входа.
- На рисунке 4 относительная стоимость показанной неявной схемы равна 0,38, скользящих границ — 0,39, без кэша — 1,00. Это результаты конкретной нагрузки.
- Другой модельный пример использует префикс 8 000 токенов и шесть ходов с добавлением 2 000 на каждом: 0,87 USD без кэша, 0,50 при статической схеме и 0,32 при скользящей.
1. Повторное вычисление и постоянная память — разные вещи
Агент обычно заново отправляет инструменты, инструкции и предыдущие обмены. На этапе prefill модель строит состояние ключей и значений; кэш повторно использует совпавший префикс и обрабатывает новый суффикс. Нужны одинаковые входные токены. Поэтому сериализацию и порядок инструментов сохраняют, а меняющиеся даты, имена и идентификаторы запросов помещают после общей части.
Явный маркер задаёт общий конец после инструментов и инструкций, а неявный режим следует подходящим окончаниям разговора. Их можно сочетать; необходимы минимум 1 024 токена. Параметр store=False оставляет управление историей приложению и не отключает кэш. Такая оптимизация не создаёт постоянную память агента и не позволяет исключить необходимую запросу историю.
2. При росте истории сохранять предыдущие границы
Цикл добавляет ответы модели и соответствующие результаты инструментов, включая зашифрованное рассуждение, не меняя старые сообщения. В исключительно явном режиме отмечают последний пакет и сохраняют прежние маркеры. Одна статическая граница заставляет повторно обрабатывать последующую историю; перенос единственной границы на последний ход также может лишить повторного использования. Неявное сохранение до конца одной задачи не гарантирует отдельного короткого префикса для других задач.
Рисунок 4 относится к шести ходам инструментального цикла GPT-6 Astra с примерно 2 000 токенов результатов инструментов на ход. Относительная входная стоимость — 0,38 у показанной неявной схемы, 0,39 у скользящей, 0,61 у только статической, 0,72 при отметке лишь последнего хода и 1,00 без кэша. Снижение примерно на 62% и 61% относится к этим конфигурациям, а не к модельным 64% на рисунке 9.
3. Менять доступные вызовы, не переписывая исходный каталог
Для известных инструментов руководство сохраняет одинаковый отсортированный TOOLS и меняет allowed_tools через tool_choice. auto оставляет решение о разрешённом вызове модели, required требует хотя бы одного разрешённого вызова. Сам кэшируемый каталог не меняется. AISubHub рассматривает это как организацию промпта, а не доказательство безопасной авторизации приложения или исполнения инструментов.
При добавлении инструментов внутри сеанса AWS указывает поддержку additional_tools в Runtime и Mantle для GPT-6 Astra, GPT-6.1 Sol и GPT-5.6 Luna. Схему добавляют в историю, исходный каталог не меняют, а новый элемент сохраняют в следующих запросах. Сам additional_tools не может содержать границу: в исключительно явном примере она ставится в последующем input_text, старые сохраняются. Разным ролям подходят отдельные стабильные каталоги; доступность всех моделей и регионов не утверждается.
4. Прогревать общий контекст до параллельных помощников
Обычный запрос прогрева должен завершиться до параллельного запуска. Прогрев и помощники отмечают общий префикс даже в неявном режиме, используют те же инструменты, модель и ключ и сначала проверяют активность по usage. Помощник-суммаризатор копирует полную историю родителя и добавляет инструкцию, не изменяя оригинал. Новая инструкция автоматически не создаёт дополнительную кэшируемую границу.
Повторное использование требует одинаковых модели, аккаунта AWS, Region, ключа и совпадающего префикса, причём запись должна оставаться доступной. Отдельный ключ сеанса разделяет даже одинаковые сеансы; стабильный групповой ключ позволяет предусмотренное совместное использование. AWS указывает минимум 30 минут после последней записи или успешного чтения с повторным использованием, иногда дольше. Обновление тоже стоит денег. Это не обещание вечного хранения или безопасности за счёт разделения учёта затрат.
5. Отделять модельную экономию входа от рабочего счёта
На рисунке 9 смоделирован агент поддержки GPT-6 Astra с начальным префиксом 8 000 токенов и шестью ходами, каждый добавляет 2 000. При принятых в руководстве тарифах по запросу накопленная входная стоимость составляет 0,87 USD без кэша, 0,50 со статической границей и 0,32 со скользящими. Снижение на 64% относится к этому модельному примеру, не к рисунку 4 и не к испытанному AISubHub развёртыванию.
Запись стоит 1,25 обычного входного тарифа, чтение зависит от модели. Короткая задача или часто меняющийся префикс могут не окупить запись и прогрев. Автор рекомендует сопоставлять эти расходы с экономией чтения. Выходные токены исключают при расчёте долей входной стоимости, но отдельно включают в полный счёт. Иллюстративные суммы не являются актуальным предложением цены или гарантией снижения всех расходов.
6. Использовать нужные счётчики и сохранять управление рисками
Ответ usage содержит cached_tokens и cache_write_tokens. Runtime также предоставляет CloudWatch CacheReadInputTokenCount и CacheWriteInputTokenCount; журналы вызовов позволяют проверять отдельные запросы. Согласно руководству, пространство CloudWatch для Mantle пока не имеет отдельных счётчиков кэша, поэтому приложение записывает usage. Cost Explorer группирует по Usage type чтение, запись и некэшированный вход.
Автор предупреждает о возможной утечке или эксплуатации определений инструментов и системных промптов и включает кэш в управление рисками. По нашему мнению, область совместного использования, разрешения и наблюдение требуют отдельной проверки; статья не доказывает конкретную утечку или полноценную защиту. Связанные дополнительные документы независимо не читались, примеры не запускались. Модель, конечную точку, регион, стоимость и задержку ещё необходимо проверять в своей среде.
Почему это важно
Полезный подход разделяет стабильный общий префикс, историю только с добавлениями и намеренное совместное использование помощниками. Экономия зависит от соблюдения границ и реальных показателей чтения и записи, а не только от включения кэша.
Ограничения и доступность
Основа — полное официальное руководство и необходимые графики. Результаты нагрузки AWS и модельные затраты являются разными видами свидетельств. Код, дополнительные документы, актуальные цены и развёртывание независимо не испытывались.
Источники и подтверждения
Дата источника: · Источник проверен:
Материалы подготовлены с помощью ИИ и сверены с указанными первоисточниками. Заявления поставщиков атрибутированы; публикация не означает рекомендацию.