Страница цен Amazon Bedrock показывает стоимость одного токена. Счёт за месяц показывает стоимость завершённых задач. Между этими числами стоят четыре фактора, которых в прайсе нет: плотность токенизации, длина ответа, число итераций агентного цикла и объём reasoning-токенов. Модель с более высокой ценой за токен может обойтись дешевле, если ей хватает одного прохода и она не льёт воду в ответе.
Рабочая метрика здесь одна: cost per task, стоимость одной полной единицы работы со всеми вызовами модели. Дальше - как её считать по логам, где ошибаются при определении границ задачи, какие приёмы реально снижают счёт и как связать расходы с долей успешных попыток.
Короткий ответ: cost per successful task = суммарные затраты на все попытки / число задач с пригодным результатом. Остальной текст раскладывает числитель и знаменатель этой дроби.
Почему цена за токен не говорит, сколько стоит ваш агент
В блоге AWS это различие сформулировано прямо: опубликованная ставка описывает стоимость одного токена, а счёт компании отражает стоимость завершения задачи (Optimizing cost per task and proving agent ROI on Amazon Bedrock). Ставка живёт в договоре, стоимость задачи живёт в вашем приложении. И зависит она не только от модели.
Что считать одной задачей
Задача: одна полная единица работы, которую приложение просит модель выполнить. Разобрать одно обращение в поддержку. Извлечь поля из одного счёта. Ответить на один вопрос пользователя. Отсчёт идёт от запроса до результата, пригодного к использованию, и все промежуточные вызовы модели входят внутрь.
Что попадает в задачу:
- все вызовы модели в рамках этой единицы работы, включая повторные после ошибки формата;
- вызовы инструментов и повторную отправку их результатов в контекст;
- reasoning-токены, если модель их генерирует перед ответом;
- токены чтения и записи кэша, если он использовался.
Что считается новой задачей: следующее письмо, следующий счёт, следующий вопрос. Повторный запуск после ручного исправления входных данных тоже новая задача: на вход подали другой текст, сравнивать его с предыдущим бессмысленно.
Отдельный случай - частичный результат. Агент извлёк половину полей и запросил уточнение. Задача не закрыта: её стоимость уходит в числитель, но в знаменателе успешных задач её нет.
Граница задачи чаще всего ошибочна в одну сторону: за задачу берут один вызов модели. В агентском сценарии на одно письмо или один счёт приходится несколько вызовов, и разница между «один вызов» и «одно письмо» измеряется кратно. Отчёт, построенный по вызовам, занижает стоимость агентных сценариев и завышает вес решений, которые делают один запрос и один ответ.
Формула стоимости задачи
Считается по логу вызовов. Для каждой задачи суммируем токены по типам и умножаем на соответствующие ставки:
cost_per_task = Σ (input_tokens × input_price
+ output_tokens × output_price
+ reasoning_tokens × reasoning_price)
cost_per_successful_task = Σ cost_per_task (все попытки)
/ число задач с пригодным результатомВходные и выходные токены тарифицируются по разным ставкам, поэтому формула не сводится к «всего токенов × одна цена». Как именно учитываются reasoning-токены в счёте Bedrock, зависит от модели: в доступных источниках нет единого подтверждённого правила, поэтому ставку и способ учёта нужно сверять со страницей цен Bedrock и документацией по конкретной модели, а не с пересказом в чужом калькуляторе.
Практическое следствие: храните формулу отдельно от ставок. Токены берите из логов, ставки подставляйте из конфига с датой. Когда провайдер меняет цены, вы пересчитываете отчёт одной правкой, а не переписываете пайплайн.
Как такой пересчёт выглядит на реальных замерах, видно на открытом харнессе, который сравнивает модели не по цене за миллион токенов, а по стоимости успешного результата: разбор бенчмарка стоимости успешного результата на Amazon Bedrock.
Четыре скрытых драйвера, которые определяют реальный счёт
Все четыре эффекта умножаются друг на друга, поэтому модель с низким прайсом проигрывает не в одном месте, а сразу в нескольких.
Токенизатор: почему русский текст стоит дороже английского
Токенизатор - это словарь и правила разбиения текста на токены. К качеству рассуждений он отношения не имеет, к счёту - прямое.
Одно и то же содержимое разные семейства моделей режут на разное число токенов. Если у модели A цена на 15% ниже, а её токенизатору нужно на 40% больше токенов на ваших данных, дешевле оказывается модель B. Чаще всего разрыв вылезает на структурированных схемах и числовых массивах: JSON с длинными ключами, таблицы, выгрузки логов.
Для русскоязычных сценариев эффект сильнее. Многие токенизаторы дробят нелатинские алфавиты в два-три раза мельче, чем эквивалентный английский текст, и ставка за токен этого не компенсирует. Одна и та же инструкция на русском и на английском может стоить по-разному при одинаковом прайсе. Оба эффекта AWS разбирает в том же материале про стоимость задачи (источник).
Проверка занимает полчаса: прогнать свой корпус через токенизаторы сравниваемых семейств и сравнить число токенов на одинаковых документах. Именно на своих письмах, счетах и логах, а не на демо-примерах из документации. Заявления вендоров об экономии токенов проверяются так же - собственным замером, а не пресс-релизом: что известно о токен-эффективности DeepSeek V4.1-Flash.
Многословность и цена выходных токенов
Выходные токены на Bedrock часто стоят дороже входных, но соотношение зависит от модели: у некоторых моделей вход и выход тарифицируются одинаково, а сторонние обзоры приводят разные диапазоны — от трёх-пяти до трёх-восьми раз. Точное соотношение для вашей модели берите со страницы цен Bedrock, а не из обзора. Следствие от этого не меняется: слово-наполнитель в ответе обходится дороже того же слова в промпте.
Модель, которая перед JSON пишет «Конечно, вот результат в нужном формате», оплачивается по премиальной ставке за преамбулу. На тысячах задач это заметная строка в счёте. Жёсткое ограничение формата, few-shot с чистым выводом и валидация схемы на стороне приложения снимают большую часть этого налога.
Ограничение: слишком тесные рамки повышают долю невалидных ответов. Модель обрезает JSON на середине или теряет поле, приложение делает ретрай, и экономия на выходных токенах съедается повторным проходом. Считать нужно вместе с success rate.
Ставки на выходные токены меняются от модели к модели и от версии к версии, поэтому цифры из прошлогодних калькуляторов устаревают. Актуальные значения сверяйте со страницей цен Bedrock: что изменилось в Opus 5.5 и как считать стоимость задачи.
Агентный цикл: итерации дороже, чем кажется
На каждом шаге агент отправляет модели весь контекст заново: системную инструкцию, описания инструментов, историю вызовов и их результаты. Стоимость растёт нелинейно. Три итерации при прочих равных - это примерно тройной объём входных токенов на одну задачу.
Вторая проблема - качество схем. Неоднозначное описание параметра или лишний инструмент в каталоге приводят к неверному вызову, затем к сообщению об ошибке, затем к попытке исправить. Каждый такой цикл оплачивается полностью, включая уже прочитанный контекст.
Что помогает на уровне инженерии:
- держать в контексте минимальный набор инструментов под конкретную роль;
- описывать схемы строго: типы, обязательные поля, пример валидного вызова;
- задавать лимит итераций и завершать задачу с явной ошибкой вместо бесконечных попыток;
- логировать номер итерации, на которой задача закрылась: медиана по этому полю показывает, где именно утекает бюджет.
Недетерминизм усложняет картину: при повторе агент может пойти другим маршрутом и потратить другое число шагов на ту же задачу (как заставить агента повторять задачу одинаково).
Reasoning-токены: платить за размышления
Reasoning-токены тарифицируются и могут составлять тысячи единиц до первого видимого символа ответа. В прайс-листе видна ставка, но не видно, сколько модель потратит на размышления в вашей задаче. Отдельная это строка в счёте или reasoning-токены учитываются как выходные, зависит от модели; в доступных источниках единого правила нет, поэтому способ учёта нужно проверять по документации Bedrock и странице цен для конкретной модели.
Разделение простое. Сложная логика, многошаговые проверки, разбор противоречивых условий - рассуждение повышает долю успешных задач, и за него имеет смысл платить. Классификация, извлечение полей, маршрутизация - рассуждение там обычно не меняет результат, зато удваивает или утраивает выходные токены.
Правило: сравнивать модели по cost per successful task, а не по наличию reasoning-режима. Отключение или ограничение рассуждений - рычаг, который проверяется экспериментом на своём наборе задач: экономия есть, но падение success rate может её перекрыть.
Иллюстративный расчёт: дороже по прайсу, дешевле по задаче
Числа ниже вымышлены для наглядности, это не замер конкретных моделей. Модель A дешевле по прайсу, но её токенизатору нужно на 40% больше токенов, ответы многословнее, а на задачу уходит три прохода вместо одного.
| Параметр | Модель A | Модель B |
|---|---|---|
| Цена входных токенов за 1 млн | $1 | $2 |
| Цена выходных токенов за 1 млн | $4 | $8 |
| Входных токенов за проход | 2800 | 2000 |
| Проходов на задачу | 3 | 1 |
| Итого входных токенов | 8400 | 2000 |
| Выходных токенов на задачу | 3600 | 500 |
| Стоимость входа | $0,0084 | $0,0040 |
| Стоимость выхода | $0,0144 | $0,0040 |
| Итого за задачу | $0,0228 | $0,0080 |
Модель B дороже по прайсу вдвое и дешевле по задаче примерно на 65%. Причина в двух множителях: меньше токенов на тот же смысл и один проход вместо трёх. Именно поэтому рейтинг моделей по цене за миллион токенов и рейтинг по стоимости задачи могут не совпадать.
Как снизить стоимость задачи: четыре рычага и их ограничения
Все четыре приёма двигают числитель формулы, но каждый способен испортить знаменатель. Проверять эффект нужно на одинаковом наборе задач.
Prompt caching: на чём именно экономия
Экономия появляется там, где заметная часть входного контекста повторяется от запроса к запросу. Типичные кандидаты: системная инструкция, каталог инструментов, справочные документы, few-shot примеры.
Ограничения: кэш не бесплатен и не вечен, у него есть время жизни и правила инвалидации, а при уникальном контексте на каждый запрос выигрыша не будет. Проверка простая: посчитайте долю повторяющегося префикса в общем объёме входных токенов за сутки. Если она невелика, кэширование счёт не изменит.
Отдельный подвох - стабильность префикса. Правка системного промпта или порядка инструментов обнуляет накопленный кэш, и следующая серия запросов платит заново. Механика повторной отправки контекста и работа кэша в агентских сессиях разобраны подробно: почему агентная разработка платит за контекст.
Маршрутизация: дешёвая модель там, где она справляется
Смысл: простые задачи отправлять на дешёвую модель, сложные на дорогую. Риск в том, что классификатор сложности ошибается, провал на дешёвой модели ведёт к повтору на дорогой, и стоимость такой задачи складывается из двух попыток.
Условия применимости: есть надёжный признак сложности (длина входа, тип задачи, наличие инструментов, история обращений), и по каждой ветке success rate считается отдельно. Эффект проверяется на cost per successful task, а не на средней цене вызова. Средняя цена легко падает при росте провалов.
Ограничения на вывод и batch inference
Ограничения: max output tokens, строгая схема ответа, запрет преамбул, валидация формата на стороне приложения. Включается быстро и даёт эффект сразу. Цена - рост доли обрезанных и невалидных ответов, особенно на моделях, которые любят длинные рассуждения.
Batch inference подходит для офлайн-пакетов: массовое извлечение полей, разметка, пересчёт исторических данных. По данным сторонних обзоров, batch на Bedrock тарифицируется примерно на 50% ниже on-demand для отдельных поддерживаемых моделей и рассчитан на рабочие нагрузки с окном обработки до 24 часов; точные условия и список моделей нужно сверять со страницей цен и документацией Bedrock. Для интерактивного агента, где пользователь ждёт ответа, он не годится: выигрыш в цене не компенсирует задержку.
Для обоих приёмов эффект измеряется одинаково: один и тот же набор задач, cost per successful task до и после, отдельно success rate. Если метрика улучшилась только за счёт отброшенных сложных задач, это не экономия.
Cost per successful task: метрика, которая не врёт
Cost per task считает все попытки. Cost per successful task делит суммарные затраты на число задач, закончившихся пригодным результатом. Первая метрика отвечает на вопрос «сколько стоит активность», вторая - «сколько стоит результат».
| Модель | Стоимость попытки | Success rate | Cost per successful task |
|---|---|---|---|
| X | $0,008 | 45% | $0,0178 |
| Y | $0,015 | 92% | $0,0163 |
Y дороже за попытку почти вдвое и дешевле за результат на 8%. При success rate 45% больше половины денег уходит в мусор, и прайс этого не показывает. Числа условные, арифметика от этого не меняется.
Критерий успеха определяется до замера: валидация схемы, проверка бизнес-правил, ручная приёмка на выборке, downstream-метрика вроде закрытого тикета или проведённого платежа. Для задач с нечётким критерием метрику нужно назвать явно, иначе она превращается в самообман: под «успехом» легко начать понимать «модель что-то ответила».
Без логов это не посчитать. Нужны записи по каждому вызову: типы токенов, их количество, номер шага, идентификатор задачи и её финальный статус. Model invocation logging в Bedrock по умолчанию отключён и настраивается отдельно для каждого региона; записи включают количество токенов, модель, идентичность вызывающей стороны и метаданные, переданные приложением. Этого хватает для расчёта стоимости вызова, но не для статуса задачи: идентификатор задачи и её финальный результат нужно добавлять на стороне приложения. Учтите и ограничение: логирование фиксирует только runtime-вызовы, поэтому асинхронные batch-задания в него не попадают и их затраты придётся учитывать отдельно.
Где это стыкуется с контролем расходов Bedrock
Атрибуция через IAM principal tags и Cost and Usage Report 2.0 отвечает на вопрос «кто потратил». Model invocation logging даёт сырьё для расчёта cost per task. Принуждение на нескольких уровнях и регулярный обзор ограничивают худшие сценарии вроде забытого эксперимента с дорогой моделью.
Cost per successful task - следующий слой, он отвечает на вопрос «были ли траты оправданны». Смешивать слои в одном отчёте без пояснений не стоит: руководство увидит таблицу с токенами и решит, что проблема в цене за токен, хотя проблема может быть в схеме инструментов.
Как доказать окупаемость агента: от человеческой базовой линии до scorecard
Окупаемость доказывается не расчётом токенов, а сравнением с человеческим процессом. Метод, который AWS описывает для этого, состоит из трёх частей: базовая линия, holdout-эксперименты и scorecard из пяти измерений с порогами решений (материал AWS).
Базовая линия человеческого процесса
До запуска агента нужно зафиксировать, как задача решается людьми. Минимальный набор:
- время на одну задачу, включая подготовку и проверку результата;
- полная стоимость часа специалиста с накладными расходами;
- доля ошибок и переделок;
- пропускная способность за период: сколько задач закрывается за смену;
- стоимость эскалации, если задача уходит на второй уровень.
Замер делается до запуска. Восстанавливать цифры по памяти после пилота бессмысленно: люди запоминают лучшие дни. Базовая линия должна относиться к тем же типам задач и тому же периоду, что и эксперимент, иначе сравнение поедет на сезонности.
Holdout-эксперимент: как не обмануть себя
Схема: задачи распределяются между агентом и контролем случайно или стратифицированно, назначение фиксируется до обработки, метрики успеха в обеих группах одинаковые.
Типичные ловушки:
- команда отдаёт агенту простые задачи, и сравнение льстит проекту;
- holdout со временем размывается, часть задач из контроля незаметно уходит агенту;
- для групп считаются разные метрики успеха;
- выборка мала для редких типов задач, и выводы держатся на десятке случаев.
Последний пункт лечится длительностью: редкие категории набираются месяцами, и торопить этот процесс значит получить красивое, но случайное число.
Пятимерная scorecard и пороги scale / tune / retire
Пять измерений, по которым принимается решение:
- Стоимость успешной задачи. Cost per successful task агента против стоимости успешной задачи у человека.
- Качество результата. Доля задач, принятых без правок, и характер правок.
- Скорость и пропускная способность. Время до результата и число задач за период.
- Доля успешных попыток. Отношение закрытых задач к общему числу попыток.
- Операционная нагрузка. Сколько времени команда тратит на промпты, инструменты, разбор инцидентов и поддержку агента.
Пороги задаются до эксперимента. Решение scale означает расширять охват, tune - дорабатывать промпты, маршрутизацию и инструменты, retire - сворачивать. Если пороги назначаются после того, как увидели цифры, scorecard превращается в оправдание заранее принятого решения.
Порог по стоимости бессмысленно смотреть в отрыве от качества. Агент, который стоит вдвое дешевле человека и требует правок в половине случаев, не экономит ничего.
Что показать руководству и где метод ломается
Для разговора с продуктом и FinOps хватает одной страницы: базовая линия, результаты holdout, cost per successful task по обеим группам и вывод по scorecard с явным решением. Формулировки - про деньги за результат, например: «одна закрытая заявка стоит $0,41 у агента и $2,10 у человека, доля принятых без правок 88%». Токены остаются в приложении к отчёту.
Ограничения метода стоит назвать самому, до вопросов:
- малые выборки дают широкие доверительные интервалы, и разница в 5% на сотне задач ничего не доказывает;
- holdout загрязняется со временем, его нужно охранять организационно;
- задачи с субъективным качеством требуют разметки, а разметка стоит денег и несёт собственную ошибку;
- цены на модели меняются, новые версии ведут себя иначе, расчёт устаревает;
- reasoning-режимы и настройки меняют стоимость и качество одновременно, пересчитывать нужно оба конца.
Точной цифры ROI метод не даёт. Он даёт обоснованное решение и защищает от самообмана в обе стороны: и от отчёта, который приукрашивает агента, и от сворачивания проекта, который на самом деле работает.
Начать стоит с одного шага: взять неделю логов вызовов, разметить задачи и посчитать cost per successful task по одной модели. Эта цифра почти всегда отличается от того, что показывал прайс за токен, и именно с неё начинается разговор про окупаемость.