Разбор стоимости ИИ: почему цена токена не равна цене готового результата

Считать нужно принятый результат

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

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

Соберите пять категорий затрат

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

2. Оркестрация. У агентов бывают вызовы инструментов, планирование, поиск, повтор после ошибки и верификация. Один пользовательский вопрос может превратиться в несколько запросов к модели. Храните trace ID и считайте полный путь, а не только первый ответ.

3. Человеческая проверка. Запишите время на просмотр, исправление и эскалацию. Умножайте минуты на полную стоимость рабочего времени, а не на оклад без налогов и накладных расходов. Если специалист только подтверждает правильный результат, это тоже часть процесса, а не бесплатный фон.

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

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

Пример без выдуманных тарифов

Представим обработку входящих писем. У команды есть ручной базовый процесс, модель Alpha и модель Beta. Не придумывайте цены: возьмите реальные данные из счетов за одинаковый тестовый период и замерьте трудозатраты. Для каждой модели посчитайте количество обработанных писем, число принятых без правки, минуты редактора, повторные запросы и ошибки, которые пришлось исправлять.

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

Для сравнения используйте две базы. Первая — текущая ручная работа. Вторая — автоматизированный путь вместе с проверкой. Не учитывайте экономию времени, если фактически сотрудник тратит его на дополнительное ревью в соседнем окне. И не объявляйте «сэкономленными» часы, если они не высвободили ресурс для других задач.

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

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

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

Как не обмануться итоговой таблицей

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

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

FAQ

Какая метрика главная?

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

Как сравнить с ручной работой?

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

Нужно ли учитывать ошибки?

Да. Учитывайте вероятность, стоимость исправления и последствия, особенно если модель влияет на деньги, безопасность или решения о людях.

Что сделать перед запуском?

Подготовьте одинаковую выборку для сравнения моделей и ограниченный тестовый контур для агента.

Вывод

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