Сколько стоит ИИ-агент: расчёт рабочего результата

В прайсе модельного API указана цена объёма входного и выходного текста. В рабочем процессе оплачивается последовательность обращений: прочитать документ, получить сведения из системы, уточнить ответ и проверить итог. Две модели с похожим тарифом могут выполнять эту последовательность по-разному. Разница становится заметна в расходе на весь сценарий.

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

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

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

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

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

OpenRouter описывает кэширование повторяющейся части запроса: инструкции и другие стабильные материалы могут повторно читаться по условиям выбранного провайдера. Запись и чтение кэша тарифицируются по-разному; эффект зависит от повторного использования и маршрута запросов. Сам факт включённой настройки ещё не доказывает экономию.

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

Работа с кэшем не отменяет требований к данным. Нужно знать, где обрабатывается контекст и какие условия хранения действуют. Для локального ИИ в своём контуре кэш и модельные сервисы проектируют внутри согласованной инфраструктуры. Внешний агрегатор подходит только для разрешённых маршрутов; эти схемы имеют разный состав расходов и ограничений.

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

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

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

• Объём входящих задач. Считайте реальные единицы процесса, а не только сообщения. Один запрос клиента может породить несколько запусков помощника.
• Доля принятых результатов. Фиксируйте правило принятия и причины отказов. Изменение этого правила меняет сопоставимость периодов.
• Расход на сценарий. Связывайте модельные обращения, инструменты и повторные попытки с одной задачей. Длинные цепочки должны быть видны отдельно.
• Время человека. Измеряйте чтение, проверку, исправление и возврат к ручной работе. Ускорение генерации не равняется сокращению всего процесса.
• Задержка и очередь. Для пользователя важен срок получения принятого результата. Медленная обработка может нарушать рабочий ритм даже при дешёвых токенах.
• Лимиты и исключения. Определите бюджет запуска, число повторов и условия остановки. При достижении границы нужна понятная передача сотруднику.

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

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

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

На пилоте фиксируют исходное время ручной операции и набор критериев качества. Затем запускают помощника на сопоставимых задачах, включая исключения. Период должен отражать обычную работу отдела, а не только несколько удачных демонстраций. Результаты разбирают с владельцем процесса и проверяющими сотрудниками.

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

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

• OpenRouter: учёт расходов по агентам, моделям и запросам
• OpenRouter: кэширование запросов и стоимость чтения и записи кэша
• Николай Хлебинский: обсуждение стоимости моделей, источник темы