Счёт за инференс в Amazon Bedrock растёт при той же модели, том же промпте и том же числе вызовов. Причина обычно в параметрах запроса, которых не видно в тексте промпта: длительность кэша промптов, service tier, reasoning effort и maxTokens. Tier и TTL кэша меняют применяемый тариф, reasoning effort и maxTokens меняют объём токенов, который попадает в счёт.
Тарифицируются входные токены, выходные токены, отдельные счётчики записи и чтения кэша и reasoning-токены, которые считаются выходными. Каждый ответ Bedrock несёт usage metadata: вход и выход считаются по ставке модели и того tier, который обслужил запрос. Разбор AWS про четыре настройки инференса описывает эту механику и разбирает каждый параметр отдельно.
Дальше по порядку: кэш промптов, tier Flex, reasoning effort, maxTokens, в конце методика проверки. Ставки и проценты ниже взяты из опубликованных материалов AWS, страницы цен Bedrock для Claude Sonnet 5 и Claude Opus 5 и примеров документации. Собственных замеров AI-Manual в тексте нет. Поддержку конкретного параметра для вашей версии модели и региона придётся сверять отдельно, по матрице поддержки и справочнику Models at a glance.
Почему счёт за Bedrock растёт, хотя модель и промпт не менялись
Модель задаёт ставку. Состав счёта задаёт запрос: сколько токенов уходит в префикс, попал ли префикс в кэш и читается ли он оттуда, сколько модель потратила на рассуждения, сколько отдала в ответ и не обрезал ли вывод лимит maxTokens.
Что именно попадает в счёт: вход, выход, кэш и reasoning-токены
| Категория | Что входит | Как учитывается |
|---|---|---|
| Входные токены | промпт, системные инструкции, история диалога, определения инструментов | по ставке модели и tier, обслужившего запрос |
| Выходные токены | сгенерированный текст | по ставке модели и tier |
| Запись в кэш | префикс, который сохраняется для повторного использования | отдельная ставка: 1.25x для 5 минут, 2x для 1 часа (Sonnet 5, Opus 5) |
| Чтение кэша | повторное использование сохранённого префикса | 0.1x входного тарифа (Sonnet 5, Opus 5) |
| Reasoning-токены | внутренние рассуждения модели | считаются выходными |
Практический эффект: агентный вызов с большим системным промптом, каталогом инструментов и историей может записать в кэш больше токенов, чем потратить на сам ответ. Если смотреть только на текст ответа, расходы выглядят необъяснимыми.
Reasoning-токены усиливают ту же картину. В ответе их не видно, но тарифицируются они как выходные, а выход обычно дороже входа. Поэтому смена уровня рассуждений меняет счёт сильнее, чем можно предположить по длине финального текста.
Кэш промптов: как TTL на 5 минут и 1 час меняет тариф
Руководство AWS по prompt caching перечисляет для поддерживаемых моделей Anthropic два значения TTL: 5 минут и 1 час. Для поддерживаемых моделей GPT-5.6 указан минимум 30 минут. Ставки за запись различаются: у Claude Sonnet 5 и Claude Opus 5 пятиминутная запись стоит 1.25x входного тарифа, часовая 2x, чтение кэша 0.1x. Страница цен и разбор AWS держат для этих случаев отдельные строки, так что длинный TTL не бывает бесплатной страховкой.
Логика окупаемости простая. Пятиминутный кэш отбивается при первом переиспользовании в пределах 5 минут. Если запросы с тем же префиксом приходят реже, кэш успевает истечь, и каждый следующий запрос снова пишется по 1.25x. В таком режиме часовой кэш выгоднее со второго запроса в течение часа.
Посчитаем в единицах входного тарифа: 10 000 входных токенов = 10 000 единиц. Расчёт предполагает точное совпадение префикса и то, что каждое чтение кэша обновляет TTL.
| Сценарий (10 000 входных токенов) | 5-минутный TTL | 1-часовой TTL |
|---|---|---|
| 2 запроса, пауза 20 минут | 25 000 | 21 000 |
| 3 запроса, пауза 20 минут | 37 500 | 22 000 |
| 3 запроса, пауза 2-3 минуты | 14 500 | 22 000 |
Вторая строка описывает типичный сценарий «документ открыт, вопросы задаются по мере чтения». Третья показывает обратную сторону: при частых запросах часовой TTL превращается в переплату 2x вместо 1.25x. Поддержка TTL и полей API зависит от модели, поэтому перед выбором длительности стоит открыть актуальную матрицу поддержки.
Где задать TTL: cachePoint в Converse API и cache_control в InvokeModel
В Converse API часовая запись кэша задаётся точкой кэша:
{
"cachePoint": { "type": "default", "ttl": "1h" }
}Для поддерживаемых моделей Anthropic в InvokeModel то же значение ttl помещается в cache_control. Каждый пример в документации задаёт собственный model ID, поэтому его и параметры инференса нужно менять под ту модель, которую вы вызываете. Расстановка точек кэша, пороги токенов и сценарии для Converse API разобраны в материале prompt caching в Amazon Bedrock.
Implicit caching: почему на него нельзя рассчитывать в расчётах
Bedrock умеет и implicit prompt caching: для поддерживаемых моделей сервис сам пытается переиспользовать подходящий префикс, без элементов управления кэшем в запросе. Механизм работает best effort и попадание не гарантирует. Все расчёты по TTL выше относятся к explicit caching, а implicit остаётся бонусом, а не основой бюджета. Разница между режимами и проверка эффекта по счётчикам кэша разобраны в статье про prompt caching для AI-агентов на Amazon Bedrock.
Service tier Flex: вдвое дешевле, но не для всех моделей и задач
Flex это tier для нагрузки, которой не важна задержка. На Nova 2 Lite он опубликован вдвое дешевле Standard. Дальше начинаются ограничения: Flex поддерживается не всеми моделями, требует собственного дедлайна запроса и обработки ValidationException. Экономия относится к ставке модели и тому tier, который реально обслужил вызов, поэтому её подтверждают по биллингу, а не по предположению.
Кому подходит: батчевая обработка, офлайн-суммаризация, ночные джобы, генерация черновиков, разметка накопленных логов. Кому нет: интерактивный чат, агентные циклы с ожиданием пользователя, любые вызовы внутри пользовательской сессии. Там выигрыш в цене съедается задержкой, которая ломает сценарий.
Как не сломать прод при переключении на Flex
Задайте собственный дедлайн с запасом относительно обычного времени ответа, иначе вызов упрётся в таймаут раньше, чем модель закончит. Обрабатывайте ValidationException как штатную ветку: модель или регион Flex не поддерживает, значит нужен фолбэк на Standard. Логируйте, какой tier фактически обслужил запрос, иначе через месяц никто не вспомнит, где включён дешёвый режим. Весь трафик сразу не переключайте: вынесите latency-tolerant часть в отдельный пул, сравните счёт до и после на одинаковом наборе задач.
Reasoning effort: когда рост токенов не покупает корректность
На агентской задаче с Opus 5 переход с low на high увеличил медианные выходные токены на 169%, а с low на max на 302%, и прироста корректности не дал. Reasoning-токены тарифицируются как выходные, поэтому такой рост переносится в счёт почти один к одному. Плата выросла втрое, результат остался тем же.
На генерации кода разница между low и high оказалась в пределах вариативности. Повышенный effort не дал измеримого выигрыша, за который стоило бы платить.
Агентные цепочки vs генерация кода: где effort реально помогает
Многошаговые задачи с планированием, ветвлением и проверкой промежуточных результатов выглядят кандидатом на повышение effort, но только с замером на своём наборе. Генерация кода по приведённым данным выигрыша не показывает. Это данные опубликованного разбора, а не универсальный закон: набор задач у каждого свой, и переносить проценты на чужой workload без проверки нельзя.
Рабочая эвристика: стартуйте с low, фиксируйте метрику качества и медианные выходные токены, поднимайте уровень только когда качество на конкретном наборе падает измеримо. Если метрика не двигается, а токены растут, шаг вверх это чистая переплата.
maxTokens: потолок вывода, который не защищает от расходов
maxTokens ограничивает длину ответа. На счёт он влияет частично: обрезает выходные токены, но не трогает вход, запись в кэш и reasoning-токены. Как страховка от большого счёта параметр не работает.
Пример из разбора: лимит в 155 токенов срезал 1 893 токена, при этом оба ответа оказались усечены. Главный риск здесь не деньги, а качество. В агентной цепочке обрезанный результат уходит на следующий шаг, и дальше цепочка ломается или выдаёт мусор, который ещё дороже переигрывать.
Правила: ставьте лимит с запасом относительно типичной длины ответа на вашем workload; держите разные значения для интерактивных и фоновых вызовов; считайте усечение инцидентом, а не нормой.
Как поймать усечение до того, как оно сломает цепочку
Смотрите на признак остановки по лимиту в метаданных ответа, сравнивайте длину вывода с заданным maxTokens, считайте долю усечённых ответов и алертите на её рост. Перед передачей результата следующему шагу агента валидируйте структуру: отсутствующие поля или оборванный JSON видны раньше, чем итоговая ошибка.
Как проверить, какая настройка реально влияет на ваш счёт
Метод один: менять по одной настройке и мерить. Зафиксируйте базовую линию на стабильном наборе запросов, затем гипотеза, изменение одного параметра, замер, откат при отсутствии выигрыша. Сравнение «до/после» на разном трафике бессмысленно: разница в токенах утонет в разнице нагрузки. Переход от цены токена к стоимости завершённой задачи разобран в статье стоимость задачи вместо цены токена.
Источник проверки это три слоя: метаданные ответа (счётчики чтения и записи кэша, reasoning-токены, признак усечения), логи приложения и данные биллинга. Разбор AWS описывает такой порядок проверки для каждой из четырёх настроек.
Чек-лист аудита счёта за инференс в Bedrock
- Выпишите текущие значения TTL, tier, reasoning effort и maxTokens по каждому вызову в проекте.
- Определите фактический интервал между запросами с одинаковым префиксом: по логам, а не по ожиданиям.
- Проверьте, поддерживают ли ваша модель и регион выбранные TTL и Flex, по матрице поддержки и справочнику Models at a glance.
- Посмотрите соотношение чтений и записей кэша в usage metadata: частые записи при редких чтениях означают, что TTL выбран неверно.
- Замерьте долю reasoning-токенов в выходе на разных уровнях effort.
- Посчитайте долю усечённых ответов и стоимость переигранных шагов агента.
- Сверьте полученные категории токенов с биллингом: расхождение покажет, что часть параметров вы не учли.
- Меняйте по одному параметру и повторяйте замер на том же наборе запросов.
Что в итоге менять в первую очередь
Сначала TTL кэша: сверьте его с реальным интервалом между запросами. Если паузы стабильно больше 5 минут, пятиминутный кэш переписывается по 1.25x на каждом вызове, и это самая незаметная переплата из четырёх. Часовой TTL в таком режиме отбивается со второго запроса.
Затем reasoning effort: по последствиям это самый дорогой рычаг, потому что он двигает выходные токены на 169-302%, а reasoning тарифицируется как выход. Поднимайте уровень только при измеримом падении качества на своём наборе задач.
Flex идёт третьим: только для latency-tolerant нагрузки, только после проверки поддержки моделью и регионом, с собственным дедлайном и фолбэком на Standard при ValidationException. maxTokens замыкает список: это гигиена вывода и способ ловить усечение, а не инструмент бюджета.
Ставки и поддержка параметров зависят от модели и региона, поэтому финальное решение принимайте по своим метаданным ответа и биллингу, а не по чужому примеру с другими моделями.