Как контролировать стоимость AI-агента: токены, модели, кэш и лимиты

Коротко

Чтобы расходы AI-агента оставались предсказуемыми:

1. Считайте стоимость каждого запуска и каждого бизнес-результата.
2. Не отправляйте сильной модели задачи, с которыми справится дешёвая.
3. Ограничивайте длину контекста, число шагов и повторных попыток.
4. Кэшируйте неизменные данные и повторяющиеся ответы.
5. Разделяйте генерацию текста и действия в CRM, Telegram, WB или Ozon.
6. Настройте дневные и месячные лимиты, а также алерты на аномалии.
7. Проверяйте не только экономию, но и качество: ошибки дешёвой модели иногда обходятся дороже токенов.

Главный принцип: оптимизировать нужно стоимость корректно выполненного процесса, а не цену отдельного ответа.

Почему расходы AI-агента оказываются выше ожидаемых

На тесте всё выглядит просто. Пользователь задаёт вопрос, модель отвечает, в панели API появляется небольшая сумма.

В рабочем процессе один запрос может превратиться в цепочку:

1. Агент получает сообщение из Telegram.
2. Загружает историю диалога.
3. Ищет клиента в CRM.
4. Читает базу знаний.
5. Определяет намерение пользователя.
6. Формирует черновик ответа.
7. Проверяет его по правилам.
8. Записывает результат в CRM.
9. Отправляет сообщение.
10. При ошибке повторяет часть шагов.

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

Особенно опасны три ситуации:

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

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

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

Входные и выходные токены

Входные токены — это всё, что отправляется модели:

• системная инструкция;
• сообщение пользователя;
• история диалога;
• найденные фрагменты базы знаний;
• данные из CRM;
• описания доступных инструментов;
• результаты предыдущих шагов.

Выходные токены — ответ модели: текст клиенту, JSON для интеграции, план действий, отчёт или промежуточное рассуждение.

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

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

Обращения к инструментам

AI-агент отличается от обычного чат-бота тем, что может выполнять действия: читать CRM, создавать задачу, проверять остатки, получать данные из API, отправлять сообщение.

Сам вызов инструмента может быть недорогим, но его описание и результат снова попадают в контекст модели. Если API возвращает огромный JSON, агент платит за чтение полей, которые ему не нужны.

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

До передачи в LLM данные лучше сократить обычным кодом: выбрать нужные поля, привести даты к единому формату, удалить служебную информацию.

Повторные попытки и циклы

Агент может не получить ответ от CRM, сформировать невалидный JSON или выбрать неправильный инструмент. Если система автоматически повторяет запрос, каждый retry увеличивает стоимость.

Без верхнего лимита одна ошибка интеграции способна вызвать цикл:

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

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

Инфраструктура и внешние сервисы

Токены — только часть TCO, то есть полной стоимости владения системой. В расчёт также входят:

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

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

Как считать стоимость правильно

Базовая формула выглядит так:

> Стоимость запуска = входные токены + выходные токены + вызовы моделей и сервисов + инфраструктура + стоимость проверки человеком.

Но для бизнеса важнее другая метрика:

> Стоимость результата = все расходы за период / количество корректно выполненных операций.

Допустим, агент поддержки обработал 10 000 обращений. API, сервер и мониторинг стоили 45 000 рублей. Ещё 15 000 рублей составило время операторов на проверку сложных случаев.

Если 8 000 обращений были решены корректно, стоимость результата равна не 4,5 рубля, а 7,5 рубля:

> 60 000 / 8 000 = 7,5 рубля за решённое обращение.

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

Для агента продаж полезно измерять стоимость квалифицированного лида. Для отчётности — стоимость одного корректно собранного отчёта. Для маркетплейса — стоимость анализа одного SKU или одной проверенной рекомендации.

Model routing: дорогая модель нужна не везде

Использовать одну сильную модель на всём маршруте удобно, но дорого. Большинство бизнес-процессов состоит из задач разной сложности.

Простая модель обычно справится с тем, чтобы:

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

Более сильная модель может потребоваться, когда нужно:

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

Такой подход называется model routing: система выбирает модель по сложности и риску задачи.

Практическая схема может выглядеть так:

1. Правила или небольшая модель классифицируют запрос.
2. Типовые обращения идут по дешёвому маршруту.
3. Сложные случаи передаются более сильной модели.
4. Финансовые, юридические и необратимые действия требуют подтверждения человека.
5. Если уверенность ниже порога, агент не угадывает, а запрашивает уточнение или создаёт задачу сотруднику.

Маршрутизация не должна строиться только на длине сообщения. Короткое «верните деньги» может быть рискованнее длинного вопроса о характеристиках товара.

Как сократить контекст без потери качества

Не передавать всю переписку

История диалога растёт с каждым сообщением. Если отправлять её целиком, стоимость поздних запросов может быть в несколько раз выше первых.

Рабочий вариант:

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

Например:

• клиент: ООО «Ромашка»;
• интерес: интеграция Telegram с CRM;
• бюджет: до 200 000 рублей;
• ограничение: данные нельзя передавать за пределы российского контура;
• следующий шаг: технический созвон.

Такое резюме полезнее и дешевле двадцати экранов диалога.

Загружать только нужные фрагменты базы знаний

Базу знаний не нужно целиком помещать в промпт. Сначала выполняется поиск, затем модели передаются несколько релевантных фрагментов.

Важно контролировать:

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

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

Сокращать описания инструментов

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

Лучше выдавать инструменты по роли и этапу процесса. Это одновременно снижает стоимость и уменьшает риск ошибочного действия.

Кэширование: за что не нужно платить повторно

Кэш полезен, когда одинаковые или почти одинаковые данные обрабатываются много раз.

Кэшировать можно:

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

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

Но кэш нельзя считать вечным. У каждой записи должны быть:

• срок действия;
• версия промпта;
• версия источника;
• идентификатор клиента или проекта;
• правило принудительного сброса.

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

Лимиты, без которых агент нельзя выпускать в production

Лимит на один запуск

Для каждого сценария задаются:

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

Если лимит достигнут, процесс должен завершиться контролируемо: сохранить лог, уведомить ответственного и передать задачу человеку.

Лимит на пользователя и клиента

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

Полезно ограничить:

• запросы в минуту;
• операции в сутки;
• расходы по клиенту;
• расходы по проекту;
• параллельные запуски;
• размер входного файла.

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

Дневной и месячный бюджет

У системы должны быть как минимум два порога:

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

Например, при достижении 70% дневного бюджета отправляется алерт. При 90% отключается пакетная генерация описаний, но продолжают работать критичные ответы поддержки. После достижения жёсткого лимита дорогие задачи ставятся в очередь до проверки.

Просто заблокировать весь API — плохой вариант. Бюджет нужно распределять по приоритетам процесса.

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

Алерт «потрачено много токенов» не объясняет причину. Нужны сигналы, по которым можно найти проблему.

Стоит отслеживать:

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

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

Сами персональные данные и секреты в логи без необходимости записывать не нужно. Токены доступа, пароли, полные реквизиты и содержимое закрытых документов должны маскироваться.

Пример: AI-агент для квалификации заявок

Допустим, заявки приходят с сайта и в Telegram. Агент должен определить услугу, собрать недостающие данные, создать сделку в CRM и подготовить менеджеру резюме.

Дорогая реализация выглядит так:

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

Управляемая реализация устроена иначе:

1. Код проверяет формат телефона и email без LLM.
2. Небольшая модель классифицирует заявку.
3. В CRM передаются только разрешённые поля.
4. Сильная модель подключается для сложных описаний задачи.
5. История заменяется кратким резюме.
6. Создание сделки выполняется один раз по уникальному идентификатору.
7. После двух ошибок заявка уходит менеджеру.
8. В отчёте видна стоимость каждой квалифицированной заявки.

Экономия возникает не из-за одного «дешёвого промпта», а из-за правильного разделения процесса.

Как оценить ROI и экономию времени

Сравните стоимость агента с текущим процессом:

> Экономия = стоимость ручной работы до внедрения − стоимость агента − стоимость человеческой проверки − поддержка системы.

Если менеджер тратит 12 минут на разбор одной заявки, а после внедрения — 3 минуты на проверку резюме, экономия составляет 9 минут. При 1 000 заявок это 150 часов в месяц.

Но из расчёта нужно вычесть:

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

Также важно проверить, не ухудшился ли результат. Если автоматизация экономит 100 часов, но из-за ошибок теряет несколько ценных лидов, она может быть убыточной.

Полезно сравнивать четыре показателя до и после внедрения:

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

Пошаговое внедрение контроля расходов

Шаг 1. Выберите единицу результата

Не «один запрос к модели», а понятный итог:

• обработанная заявка;
• закрытый вопрос поддержки;
• проверенный SKU;
• сформированный отчёт;
• заполненная карточка CRM.

Шаг 2. Разбейте процесс на этапы

Зафиксируйте, где используется модель, где достаточно обычного кода, а где требуется человек.

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

Шаг 3. Добавьте технический учёт

Для каждого запуска записывайте:

• сценарий;
• модель;
• входные и выходные токены;
• стоимость;
• инструменты;
• retries;
• длительность;
• результат;
• участие человека.

Без этих данных оптимизация превращается в догадки.

Шаг 4. Настройте базовый маршрут моделей

Начните с понятных правил: типовые задачи — дешёвая модель, сложные — сильная, рискованные действия — подтверждение человеком.

Не стоит сразу строить сложный автоматический маршрутизатор. Сначала соберите статистику на реальных запросах.

Шаг 5. Введите лимиты и аварийное завершение

Ограничьте количество шагов, повторов, токенов и стоимость запуска. Проверьте, что происходит при недоступности CRM, тайм-ауте API и невалидном ответе модели.

Агент должен завершать процесс предсказуемо, а не пытаться бесконечно «разобраться».

Шаг 6. Оптимизируйте самые дорогие сценарии

Сначала найдите 10–20% операций, которые создают основную часть расходов. Обычно это длинные диалоги, пакетные задачи, ошибки интеграций или неоправданное использование сильной модели.

Оптимизация редкого дешёвого сценария почти не повлияет на общий бюджет.

Шаг 7. Проверяйте стоимость вместе с качеством

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

Если более дешёвая модель чаще ошибается в классификации, экономия на API может увеличить нагрузку на сотрудников. Побеждает не минимальная цена, а минимальная стоимость корректного результата.

Чек-лист контроля стоимости AI-агента

• [ ] Определена единица полезного результата.
• [ ] Токены и стоимость записываются по каждому запуску.
• [ ] Видны расходы по клиентам, процессам и версиям промпта.
• [ ] Простые задачи не отправляются сильной модели.
• [ ] История диалогов сокращается или резюмируется.
• [ ] Из API-ответов удаляются ненужные поля.
• [ ] База знаний передаёт только релевантные фрагменты.
• [ ] Настроен кэш и правила его обновления.
• [ ] Ограничены шаги, retries, время и стоимость запуска.
• [ ] Есть мягкий и жёсткий бюджетные пороги.
• [ ] Критичные процессы отделены от необязательных.
• [ ] Ошибки и превышения лимитов передаются человеку.
• [ ] В логах нет паролей, ключей и лишних персональных данных.
• [ ] Экономия сравнивается с качеством и ручной нагрузкой.

FAQ

Сколько стоит AI-агент в месяц?

Единой цены нет. Она зависит от количества операций, размера контекста, моделей, числа вызовов инструментов, внешних API и доли человеческой проверки. Корректнее сначала посчитать стоимость одного результата, а затем умножить её на ожидаемый объём.

Можно ли заранее установить жёсткий лимит расходов?

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

Всегда ли дешёвая модель снижает расходы?

Нет. Если она чаще ошибается, повторяет запросы или требует проверки сотрудником, итоговая стоимость может вырасти. Сравнивать нужно стоимость корректно выполненной задачи, а не тариф модели.

Что сильнее влияет на расход: запрос или ответ?

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

Что можно безопасно кэшировать?

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

Нужно ли показывать сотрудникам стоимость каждого запроса?

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

Когда нужно передавать задачу человеку?

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

Что делать дальше

Если хочешь понять, что автоматизировать у себя — напиши Дмитрию в Telegram @dmkosik / опиши процесс для диагностики Paramiko.