Сколько стоит ИИ-агент в месяц: как посчитать

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

Три множителя

Разложим по порядку появления в расчёте.

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

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

Невидимые токены. Модели с рассуждением тратят выходные токены на внутренний ход мысли до того, как выдать ответ. Вы их не видите, но платите за них.

Первый множитель линейный. Второй — квадратичный. Именно он и ломает интуитивные оценки.

Почему история растёт квадратично

Стоит показать на числах, потому что словами это звучит абстрактнее, чем есть.

Пусть каждый шаг агента добавляет к истории условные 500 токенов, а задача занимает 10 шагов.

На первом шаге модель получает 500 токенов. На втором — 1000. На третьем — 1500. На десятом — 5000.

Суммарно за задачу через модель проходит не 5000 входных токенов, как можно было бы подумать по финальному размеру контекста, а сумма всех шагов: 500 + 1000 + ... + 5000 = 27 500. В пять с половиной раз больше.

Увеличим число шагов вдвое, до двадцати. Финальный контекст вырастет вдвое, до 10 000. А суммарный расход — до 105 000, то есть почти вчетверо.

Отсюда правило, которое стоит держать в голове при проектировании: удвоение числа шагов учетверяет расход на историю. Не удваивает.

Как прикинуть бюджет

Практическая часть. Хорошая новость в том, что считать вручную ничего не надо.

1. Возьмите десяток типичных задач. Не самых сложных и не самых простых — типичных.
2. Прогоните их и запишите фактический расход токенов. Вход и выход раздельно.
3. Посчитайте средний расход на задачу. Разброс между самой дешёвой и самой дорогой задачей обычно оказывается кратным — это нормально и полезно знать.
4. Умножьте на ожидаемое число задач в месяц.
5. Добавьте запас на неудачные попытки. Агент иногда уходит не туда и начинает заново; в реальной эксплуатации это заметная доля.

Считать по ставке той модели, которую вы реально зовёте. В каталоге разброс от 3 ₽ за миллион токенов у GLM до 180 ₽ у Fable 5 — шестидесятикратный. Ошибка в выборе модели для расчёта перекрывает все остальные погрешности вместе взятые.

На чём экономить, а на чём нет

Здесь много контринтуитивного, поэтому по пунктам.

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

Работает: разные модели на разных шагах. Не каждый шаг требует флагмана. Разобрать ответ инструмента и решить, что делать дальше, — задача, с которой справится модель за 3–6 ₽. Оставьте дорогую там, где действительно нужны рассуждения.

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

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

Не работает: надежда на кэш промптов. В нашем каталоге prompt_cache помечен unsupported у всех 36 текстовых моделей. У провайдеров, где кэш есть, он даёт скидку на повторяющуюся часть входа — но именно на неизменную, а история как раз меняется каждый шаг.

Что ещё попадает в счёт

Три статьи расхода, которые в первоначальной оценке обычно отсутствуют.

Повторы после сбоев. Отказ по нагрузке, неудачный вызов инструмента, некорректный ответ модели — всё это приводит к повторным обращениям. Часть отказов бесплатна, часть нет; разбор в материале про отказы маршрута.

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

Инструменты, исполняемые на стороне модели. Новая статья: серверный веб-поиск тарифицируется отдельно от токенов, за число поисков. Разбирали это на днях в материале про серверный веб-поиск.

Где расход прячется от учёта

Отдельная беда при оценке — не сам расход, а то, что его не видно в привычных местах. Четыре ситуации, в которых счётчик врёт.

Считается число запросов, а не токены. Самый частый случай. Панель показывает «1200 обращений за месяц», и из этого делается вывод о нагрузке. Но обращение на первом шаге и обращение на двадцатом отличаются по стоимости в разы, а в счётчике они одинаковые единицы.

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

Неудачные попытки не учитываются. Агент ушёл не туда, задача перезапущена — в бизнес-метрике это одна выполненная задача, а в расходах две. Отношение между ними стоит мерить отдельно: оно показывает, насколько стабильно работает ваш агент.

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

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

Пример расчёта до конца

Соберём всё вместе на сквозном примере, чтобы был ориентир.

Пусть агент решает задачу за 8 шагов, каждый шаг добавляет к истории 400 токенов, а генерирует модель по 200 токенов на шаг.

Вход. Суммарно по всем шагам: 400 + 800 + ... + 3200 = 14 400 токенов. Выход. 8 шагов по 200 = 1600 токенов.

На модели за 20 ₽ за миллион в обе стороны получаем: (14 400 + 1600) × 20 / 1 000 000 = 0,32 ₽ за задачу.

Тысяча задач в месяц — 320 ₽. Добавим 20% на неудачные попытки — около 384 ₽.

А теперь то же самое на модели за 6 ₽: 0,10 ₽ за задачу, около 115 ₽ в месяц. Разница втрое при том, что для многих шагов разницы в качестве не будет вовсе.

Та же задача по остальным позициям каталога: 16 000 токенов на задачу, тысяча задач в месяц, запас 20% на неудачные попытки.

Именно поэтому разведение шагов по моделям разной стоимости стоит в списке экономии на втором месте: оно даёт кратный эффект без ухудшения там, где ухудшения не происходит.

Чего мы не утверждаем

Числа в примере — иллюстрация механики, а не замер. Ваш агент добавляет к истории своё количество токенов на шаг, и оно может отличаться в разы.

Не утверждаем, что агент всегда дороже чата. Он дороже на задачу, но задача может стоить того: агент делает то, что чат не делает вовсе.

Не даём универсальной цифры расхода. Она зависит от задачи, от модели и от того, насколько аккуратно построена работа с историей.

Ставки актуальны на дату публикации. Каталог меняется, и текущие значения всегда в GET /v1/models.

Что держать в голове

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

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

Как мы проверяем цифры и почему у каждой стоит дата — на странице о проекте. Отдельный ключ с собственным лимитом под каждого агента заводится за минуту: keydealer.ru/login.