Повторный контекст без повторных вычислений: как AWS предлагает экономить на ИИ-агентах

Что сообщила AWS: сохранять обработанный контекст

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

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

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

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

В описанном AWS испытании на GPT-6 Astra неявное кеширование снизило стоимость ввода примерно на 62 процента, а перемещаемые явные границы — примерно на 61 процент. Компания прямо ограничивает эти результаты конкретной нагрузкой и рекомендует измерять собственный сценарий.

Бизнес-сценарий: редакционное предложение для поддержки

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

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

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

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

Редакционный критерий выбора пилота — повторяемость контекста. Сначала стоит найти процесс, где инструкции действительно стабильны, а работа продолжается несколькими шагами. Затем сравнить стоимость ввода и задержку с кешированием и без него, не распространяя выводы на остальные процессы заранее.

Ограничения и контроль: совпадение важнее названия задачи

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

Минимальная длина кешируемого префикса составляет 1 024 токена. Он остаётся доступным для повторного использования не менее 30 минут после записи или успешного чтения. Фактическое наличие подходящей записи необходимо проверять: одинаковые параметры сами по себе не подтверждают попадание в кеш.

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

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

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

Практический чек-лист: проверять весь рабочий процесс

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

Для промышленного наблюдения AWS различает точки доступа. На Amazon Bedrock Runtime предусмотрены метрики Amazon CloudWatch и журналирование вызовов. Для Amazon Bedrock Mantle компания рекомендует записывать показатели использования из ответов в журналы приложения: отдельных счётчиков кеша в его пространстве CloudWatch пока нет.

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

Сцена по теме: Служба поддержки →