Почему цена токена не отвечает на вопрос об окупаемости агента

У обычного чат-бота экономику ещё можно приблизительно оценить по одному запросу: входные токены, выходные токены и время модели. AI-агент устроен иначе. Он читает контекст, выбирает инструмент, вызывает CRM или поиск, проверяет результат, повторяет неудачный шаг, ждёт подтверждения человека и снова обращается к модели.

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

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

Что подтверждают источники

FinOps Foundation в разборе token economics прямо разделяет маржинальную цену инференса и полную экономику инициативы. В расход входят системные инструкции, контекст и память, выбор модели, длина ответа, повторы и оркестрация. Авторы предлагают смотреть на стоимость inference, workflow и результата с учётом полезного выхода — goodput.

Документация LangGraph показывает, почему траектория может повторяться. После остановки выполнение возобновляется от контрольной точки, а затронутый узел может стартовать заново; побочные эффекты должны быть идемпотентными. Механизм human-in-the-loop сохраняет состояние и ждёт решения человека. Это полезные свойства, но они создают реальные операции, задержку и стоимость.

OpenTelemetry определяет атрибуты для входных, выходных, reasoning- и cache-токенов, модели, workflow и инструментов. Значит, расходы можно собирать по одной траектории, не сводя всё к счёту провайдера. При этом спецификация предупреждает: содержимое запросов, ответов и аргументов инструментов может содержать персональные или чувствительные данные.

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

Четыре уровня расходов

Полезно разделить стоимость одного запуска на четыре корзины.

1. Модель

Сюда входят:

  • входные и выходные токены каждого вызова;
  • повторно переданный контекст и история;
  • reasoning-токены, если они учитываются отдельно;
  • создание и чтение кэша;
  • эмбеддинги, reranking и вспомогательные модели;
  • локальный инференс, распределённый по фактическому времени работы.

Нужно учитывать каждый вызов внутри workflow. Финальный ответ может быть коротким, хотя до него агент трижды перечитал большой набор документов.

2. Инструменты и данные

Некоторые вызовы стоят денег напрямую: поиск, распознавание, карты, телефония, электронная подпись или отраслевой API. Бесплатный внутренний метод тоже потребляет ресурсы базы данных и может занимать очередь.

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

3. Оркестрация и инфраструктура

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

Эти затраты обычно фиксированы или ступенчаты. Их распределяют на принятые результаты за период, а не на теоретическую пропускную способность оборудования.

4. Человек и цена ошибки

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

Базовая формула

Для месяца или недели используйте простой расчёт:

`стоимость принятого результата = все расходы workflow / число принятых результатов`

В числителе:

`модели + инструменты + инфраструктура + ручная проверка + повторная обработка`

В знаменателе только результаты, прошедшие бизнес-критерий. Запуск, который завершился техническим статусом `success`, но создал неверную карточку, не считается полезным.

Рядом держите три показателя:

  • доля принятых результатов с первой попытки;
  • доля принятых после повтора или ручного исправления;
  • доля отклонённых и незавершённых задач.

Так видно, где экономия реальна, а где дешёвые вызовы маскируют длинную очередь исключений.

Модельный пример на 1 000 задач

Это иллюстрация, а не рыночная цена. Допущения:

  • 1 000 задач обработки входящих заявок в месяц;
  • первая попытка модели, инфраструктуры и инструментов — 6 рублей на задачу;
  • 20% задач требуют одного повтора стоимостью 5 рублей;
  • 10% задач требуют четырёх минут проверки сотрудника;
  • полная стоимость часа сотрудника — 900 рублей;
  • бизнес принимает 930 результатов.

Расчёт:

  • первые попытки: `1 000 × 6 = 6 000 рублей`;
  • повторы: `200 × 5 = 1 000 рублей`;
  • ручная проверка: `100 × 4/60 × 900 = 6 000 рублей`;
  • всего: `13 000 рублей`;
  • на принятый результат: `13 000 / 930 ≈ 14 рублей`.

Если смотреть только на первую попытку, получится 6 рублей за запуск. Полная единица почти в 2,3 раза выше — не из-за дорогой модели, а из-за повторов и человеческого времени.

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

Как собрать ledger одной траектории

Каждой бизнес-задаче нужен стабильный `workflow_run_id`. В журнале достаточно хранить:

  • тип задачи и версию workflow;
  • время начала и завершения;
  • итог: принят, исправлен, отклонён или не завершён;
  • модель и токены по каждому вызову;
  • число, тип и статус вызовов инструментов;
  • число повторов и причину каждого;
  • использованный кэш;
  • минуты ожидания и работы человека;
  • идентификатор проверки качества;
  • распределённую стоимость инфраструктуры.

Не записывайте содержимое промптов и документов по умолчанию. Для экономики обычно хватает метаданных. Если контент нужен для отладки, включайте его выборочно, с редактированием персональных данных, ограниченным доступом и сроком хранения.

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

Стоп-условия защищают бюджет

Агенту нельзя разрешать бесконечно «пытаться ещё раз». Для каждого класса задач задайте:

  • максимум вызовов модели;
  • максимум вызовов одного инструмента;
  • число повторов по одной ошибке;
  • максимальное время выполнения;
  • лимит входного контекста;
  • денежный бюджет запуска;
  • условия обязательной передачи человеку.

После превышения лимита задача должна перейти в понятное состояние исключения, а не продолжать цикл. Это одновременно экономическая и операционная мера: предсказуемый отказ дешевле непредсказуемой автономности.

Где агент не нужен

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

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

Практичная гибридная схема:

`классификация моделью → ограниченный план → детерминированные инструменты → проверка правил → подтверждение → действие`

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

API и локальная модель считаются одинаково

Для внешнего API цена вызова видна в счёте. Для локальной модели она скрыта, но не равна нулю. Её можно оценивать как:

`активное время ускорителя × полная стоимость часа узла + доля хранения и эксплуатации`

Полная стоимость часа узла включает амортизацию, электричество, охлаждение, простой резерва и администрирование. Если GPU загружен на 20%, нельзя делить расходы на воображаемые 100%.

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

Как провести пилот за две недели

Выберите один процесс с измеримым результатом и сохраните человеческий baseline. Затем:

1. Определите, что считается принятым результатом.
2. Соберите 100–300 характерных задач, включая исключения.
3. Инструментируйте все вызовы модели и инструментов.
4. Зафиксируйте повторы, ручные минуты и причины отказа.
5. Задайте лимиты траектории и эскалацию человеку.
6. Сравните стоимость, время и качество с текущим процессом.

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

Что взять руководителю

Попросите команду показать не «расход токенов», а одну таблицу по классам задач: запуски, принятые результаты, повторы, инструментальные вызовы, ручные минуты, стоимость и p95 времени выполнения. Если такой таблицы нет, экономика агента пока неизвестна.

Начните со стоп-условий и журнала траектории. Оптимизировать модель имеет смысл после того, как виден весь чек — особенно та его часть, которую дружелюбный агент напечатал мелким шрифтом.