Агенты сжигают токены незаметно: рождается agent FinOps

Один агент, разбирающий входящую почту, может за ночь сделать несколько тысяч вызовов модели — и утром вы увидите в биллинге сумму, которую никто вручную не запрашивал. В отличие от чат-бота, где токены тратит человек за клавиатурой, агент работает в цикле: планирует, вызывает инструменты, проверяет результат, повторяет. Каждый шаг — это запрос к языковой модели с полным контекстом предыдущих. Расходы растут не линейно с числом задач, а с числом итераций внутри каждой задачи. Вокруг этой проблемы за 2024–2025 годы оформилась отдельная практика, которую называют agent FinOps или LLM cost management.

Почему счёт за агента ведёт себя иначе

Классический FinOps¹ вырос на облачных счетах: вы платите за виртуальные машины, хранилище, трафик. Единицы понятны, метрики стабильны, прогноз строится по историческим данным. С агентами ломается сам принцип предсказуемости.

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

Расход на агента — это не цена ответа, а цена всей цепочки рассуждений, которая привела к ответу. И длину этой цепочки вы часто не контролируете напрямую.

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

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

Практика agent FinOps сводится к нескольким рычагам, которые применяют поверх обычных вызовов моделей.

• Атрибуция. Привязать каждый токен к конкретному агенту, задаче, пользователю или клиенту. Без этого счёт от провайдера — одна общая цифра, в которой не видно, что именно её раздувает.
• Маршрутизация моделей. Дешёвая модель для простых шагов, дорогая — только там, где нужна. Часть шагов агента вообще не требует топовой модели.
• Кэширование. Многие провайдеры дают скидку на повторно используемую часть контекста (prompt caching). Для агента, который на каждом шаге посылает один и тот же системный промпт, это ощутимая экономия.
• Лимиты и бюджеты. Жёсткий потолок токенов или денег на задачу, после которого агент останавливается, а не уходит в бесконечный цикл.
• Наблюдаемость. Трассировка каждого шага: сколько токенов, какая модель, сколько времени, какой инструмент. Это фундамент для всего остального.

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

Самые частые источники перерасхода, о которых говорят команды, внедряющие агентов в продакшн:

1. Раздувающийся контекст — агент не сжимает и не обрезает историю, и к концу задачи каждый вызов стоит как небольшой документ.
2. Циклы без выхода — агент не может решить задачу, но продолжает пробовать, пока не упрётся в лимит (если лимит вообще стоит).
3. Дорогая модель на всех шагах — использование флагманской модели там, где хватило бы модели попроще.
4. Отсутствие кэша — повторная оплата одинаковых системных инструкций на каждой итерации.

Инструменты и подходы

Отдельного «стандарта» пока нет — рынок молодой. Задачу закрывают тремя типами инструментов, и часто их комбинируют.

Проверять актуальные условия — какие модели, скидки на кэш и лимиты доступны — нужно на официальных страницах провайдеров: цены и правила у OpenAI, Anthropic, Google и других меняются каждые несколько месяцев, и цифра из статьи полугодовой давности вводит в заблуждение.

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

Agent FinOps — не универсальная необходимость. Он окупается там, где агенты работают автономно и в объёме.

Пригодится, если:

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

Скорее не нужен, если:

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

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

Что это меняет для команд

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

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

¹ FinOps — практика управления облачными расходами, при которой инженеры, финансы и бизнес совместно отвечают за стоимость инфраструктуры и принимают решения с оглядкой на цену. Agent FinOps переносит тот же принцип на расходы, которые генерируют автономные ИИ-агенты.