Почему цена одного вызова вводит в заблуждение

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

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

Сначала определите, что считать успехом

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

Запишите для пилота:
- число попыток обработать задачу;
- число задач, принятых по заранее заданным критериям качества;
- долю ошибок, повторов и передач человеку;
- время сотрудника на обычную проверку и исправление;
- расходы на модель, инструменты, инфраструктуру и поддержку.

Знаменатель в формуле — только принятые успешные задачи. Если агент сделал тысячу попыток, но лишь 920 результатов прошли проверку, нельзя делить расходы на тысячу.

Что попадает в полную стоимость

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

  • **Модель.** Учитывайте все вызовы в цепочке, включая классификацию, планирование, извлечение данных, проверку и повторные попытки. Входные, выходные, кэшированные и reasoning-токены могут иметь разные тарифы. Смотрите фактическое поле usage в ответе API и сверяйте агрегаты с кабинетом поставщика.
  • **Инструменты и данные.** OCR, распознавание речи, поиск, векторное хранилище, внешние API и платные коннекторы не исчезают из сметы только потому, что их вызвал агент.
  • **Человеческое участие.** Включайте первичную проверку, разбор исключений, исправление неверных результатов и поддержку процесса. Измеряйте минуты, а не только число «эскалаций»: короткое исправление десятков записей тоже превращается в часы.
  • **Эксплуатация.** Разнесите по сценарию долю затрат на серверы или облако, журналы, мониторинг, резервирование, обновление промптов и интеграций. Для локального запуска добавьте амортизацию ускорителей, электричество, резервную ёмкость и работу администратора.
  • **Разработка и контроль качества.** Учитывайте регулярную проверку выборки, тестовый набор, контроль изменений модели и время инженера. Разовые работы можно распределять на ожидаемый срок жизни решения, но отдельно показывайте этот расчёт.

Формула для управленческого сравнения:

**Стоимость успешной задачи = (модель + инструменты + ручной труд + эксплуатация + доля внедрения) / число принятых задач.**

Показывайте также p50 и p95 стоимости: среднее значение прячет редкие, но дорогие циклы, когда агент повторяет действия или долго ждёт внешний сервис.

Модельный пример: обработка входящей заявки

Представим пилот для 1 000 заявок в месяц. Все цифры ниже — условные допущения для демонстрации метода, а не тарифы конкретного поставщика и не измеренный результат компании.

Допустим, на одну попытку приходится в среднем пять вызовов модели. Каждый потребляет 3 000 входных и 500 выходных токенов. Получается 15 000 входных и 2 500 выходных токенов на попытку. Для арифметики условно зададим цену 2 доллара за миллион входных и 10 долларов за миллион выходных токенов:
- модель: 0,015 × $2 + 0,0025 × $10 = $0,055 на попытку;
- при условном курсе 90 рублей за доллар — около 4,95 рубля.

Теперь добавим процесс. Предположим, 10% заявок требуют четырёх минут проверки, 8% не проходят критерии и требуют шести минут ручной обработки. При условной полной стоимости часа сотрудника 900 рублей:
- обычная проверка: 100 × 4/60 × 900 = 6 000 рублей;
- обработка исключений: 80 × 6/60 × 900 = 7 200 рублей;
- модель для 1 000 попыток: около 4 950 рублей;
- условные ежемесячные расходы на интеграцию, журналирование и четыре часа сопровождения: 8 500 рублей.

Если успешными признаны 92% попыток, итоговая стоимость составляет примерно (6 000 + 7 200 + 4 950 + 8 500) / 920 = **29 рублей за принятую задачу**. В этих допущениях ручная обработка всех заявок по шесть минут обошлась бы в 90 рублей на заявку. Это не прогноз экономии: до решения о внедрении нужно проверить качество, время сотрудников и все затраты на своих данных. Например, не включённые в пример платный OCR или ночное дежурство изменят результат.

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

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

В облачном API часть usage возвращается в ответе на вызов, а агрегированные расходы видны в панели поставщика. Для локального сервера нужны собственные метрики. Например, vLLM публикует показатели через Prometheus endpoint /metrics; по ним можно наблюдать загрузку запросами и токенами, задержки и очередь. Система наблюдаемости вроде Langfuse умеет собирать токены и стоимость, но для собственной модели цену за единицу и правила учёта надо задать самостоятельно. Инструмент мониторинга помогает собрать данные, но не определяет бизнес-критерий успешной задачи за вас.

Сопоставляйте три уровня:
1. **Счёт поставщика:** сколько фактически списано за период.
2. **Трасса задачи:** какие этапы и повторные вызовы создали расход.
3. **Результат процесса:** принят ли результат и сколько минут человека он потребовал.

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

Что меняет выбор локальной модели

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

Сравнивайте варианты на одинаковом тестовом наборе и при сопоставимом качестве:
- сколько успешных задач в час выдерживает доступная конфигурация;
- как меняются p95 задержки и доля повторов под реальной нагрузкой;
- сколько людей потребуется для обслуживания;
- что происходит при отказе GPU или сети;
- допустимо ли отправлять данные во внешний API.

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

Риски, которые искажают расчёт

  • **Считать вызовы вместо завершённых задач.** Агент может выглядеть дешёвым на один вызов и дорогим на длинный хвост неуспешных попыток.
  • **Считать только среднее.** p95 и максимальная стоимость покажут циклы, которые съедают бюджет.
  • **Забыть оценку качества.** Если больше задач уходит на исправление, дешёвый токеновый тариф не компенсирует ручную работу.
  • **Не учитывать рост контекста.** Повторная отправка истории, найденных документов и инструкций увеличивает входной расход. Кэширование может изменить цену, но его эффект следует подтверждать данными провайдера.
  • **Сравнивать пилот и промышленный режим без одинаковых условий.** В пилоте мало параллельных обращений, нет пиков и может отсутствовать резервирование.
  • **Не отделять расходы разработки от переменных расходов.** Разделите ежемесячную операционную смету и стоимость запуска решения; затем покажите срок окупаемости на ожидаемом объёме.

Практический план на неделю

1. Выберите один повторяющийся процесс с понятным входом и проверяемым выходом.
2. Зафиксируйте критерии успеха и ручную стоимость текущего процесса до демонстрации модели.
3. На 100–300 реальных, обезличенных или разрешённых к обработке примерах замерьте все вызовы, повторы, инструменты и ручные минуты.
4. Рассчитайте стоимость успешной задачи, долю успешных завершений, p50 и p95 стоимости, а также экономию времени сотрудников.
5. Сравните результат с ручным процессом и определите порог, при котором автоматизация перестаёт быть выгодной.
6. Только после этого решайте, нужен ли локальный контур, другой тариф, более простая схема или отказ от агента в пользу обычной автоматизации.

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