Unit-экономика агента: как считать стоимость одного запуска

Компания подключает агента для обработки входящих заявок. На демо всё выглядит красиво: агент читает письмо, лезет в базу, формулирует ответ. А через месяц бухгалтерия показывает счёт от провайдера модели на сумму, которая перекрывает экономию на операторе. Причина почти всегда одна — никто не посчитал, во сколько обходится один прогон агента до того, как включили его на весь поток.

Агентный процесс отличается от одиночного запроса к чат-боту тем, что за один пользовательский запрос модель вызывается несколько раз: планирование, вызовы инструментов, обработка результатов, финальный ответ. Каждый шаг — это токены, а токены — деньги. Ниже — как разложить это на цифры.

Из чего складывается стоимость одного запуска

Базовая единица расчёта — не месяц и не пользователь, а один полный проход процесса от входа до результата. Для агента¹ в стоимость входит всё, что произошло между «пришёл запрос» и «отдали ответ».

• Токены на входе (input). Системный промпт, описания инструментов, история диалога, результаты вызовов — всё, что модель читает на каждом шаге.
• Токены на выходе (output). То, что модель генерирует: рассуждения, аргументы функций, текст ответа. Обычно дороже входных в 3–5 раз.
• Число вызовов модели за проход. Ключевой множитель. Агент с циклом «подумал — вызвал инструмент — прочитал ответ — подумал снова» легко делает 5–10 обращений там, где чат-бот делает одно.
• Вызовы внешних сервисов. Поиск, база данных, сторонние API — у них своя тарификация за запрос.
• Инфраструктура. Оркестратор, очереди, логирование, векторная база под RAG². Часто копейки на запрос, но при миллионах прогонов набегает.

Формула, которую стоит держать перед глазами

Себестоимость одного прохода считается так:

Стоимость_прохода =
  Σ (input_токены_шага × цена_input +
     output_токены_шага × цена_output)
  по всем шагам агента
  + Σ вызовы_внешних_API × цена_вызова
  + инфраструктура_на_прогон

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

Как замерить реальные цифры, а не гадать

Оценка на глаз почти всегда занижает стоимость: люди помнят про финальный ответ и забывают про промежуточные рассуждения и раздувание контекста³. Порядок действий:

1. Включите логирование токенов на каждом вызове модели. У большинства провайдеров в ответе API возвращается объект usage с числом входных и выходных токенов — сохраняйте его.
2. Прогоните 50–100 реальных запросов, а не синтетических. Синтетика короче и чище, чем то, что пишут живые пользователи.
3. Посчитайте распределение, а не среднее. Один тяжёлый запрос с длинной историей может стоить в 20 раз дороже медианного. Смотрите на 90-й и 95-й перцентиль.
4. Отдельно учтите неудачные проходы: агент ушёл в цикл, не смог вызвать инструмент, повторил попытку. Это тоже оплаченные токены.

Средняя стоимость запроса врёт. Считайте медиану и хвост распределения: именно длинные тяжёлые запросы съедают бюджет, и именно они приходят от самых активных пользователей.

Что дороже: длинный контекст или много шагов

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

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

Где обычно утекают деньги

• История диалога передаётся целиком. На десятом сообщении вы каждый раз оплачиваете первые девять. Обрезайте или суммаризируйте.
• Описания инструментов дублируются на каждом шаге. Если у агента 30 функций с подробными схемами, это тысячи входных токенов в каждом вызове.
• Одна дорогая модель на все задачи. Классификацию «это жалоба или вопрос» не обязательно делать топовой моделью.
• Отсутствие кеширования. Многие провайдеры дают скидку на повторно используемую часть промпта (prompt caching) — системный промпт и описания инструментов кешируются между запросами.

Кому это пригодится, а кому нет

Пригодится:

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

Можно не заморачиваться:

• Если агент запускается вручную несколько раз в день для внутренних задач — счёт будет в единицы долларов в месяц, и точный расчёт не окупит времени на него.
• На стадии прототипа, где вы ещё не знаете, полетит ли идея вообще. Сначала докажите ценность, потом оптимизируйте себестоимость.

Порядок цен у провайдеров меняется каждые несколько месяцев, и новые модели часто выходят дешевле предыдущих при том же качестве. Поэтому не фиксируйте цену за токен в коде и в расчётах намертво — сверяйтесь с актуальным прайсом на странице провайдера перед каждым серьёзным решением о масштабировании.

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

² RAG (retrieval-augmented generation) — подход, при котором модель перед ответом достаёт релевантные документы из базы и использует их как контекст.

³ Контекстное окно — максимальный объём токенов, который модель обрабатывает за один вызов; чем больше вы в него кладёте, тем дороже каждый запрос.