Себестоимость ИИ-сервиса: как считать затраты

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

Суммы за оборудование, облака и лицензии здесь не называются: они зависят от нагрузки и выбранных продуктов, а конфигурацию мы рассчитываем на обследовании. Статья даёт метод и таблицы; пример построен на условных единицах. Как собирается сам сервис, описано на странице «Создать ИИ-сервис».

Из чего складывается себестоимость

Часть расходов растёт с каждым запросом, часть растёт ступенями, часть постоянна. Для тарифа важно разделять их: переменные расходы переносят на клиента через пакеты и лимиты, постоянные покрывают общим числом клиентов.

Пакеты сопровождения взяты со страницы «Тарифы», сверх пакета час стоит 5 000 ₽. Стоимость владения ИТ-системой в целом разобрана в статье «Как считать стоимость владения».

Стоимость принятого результата: формула и три определения

Формула проста:

стоимость принятого результата = (расход на модель + расход на файлы и хранение + стоимость часов людей + доля эксплуатации) за период ÷ число принятых результатов за период

Чтобы формула работала, заранее записываются три определения.

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

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

Условный пример: три организации на одном тарифе

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

По среднему расходу сервис выглядит нормально: общий расход 500 единиц на 150 принятых результатов, примерно 3,3 единицы на результат. Но организация B обходится втрое дороже A и C. Если тариф рассчитан на 2–3 единицы, B убыточна, а убыток скрыт средним значением.

Дальше проверяют причины. Для B это может быть неверный сценарий (документы не подходят под шаблон), плохо подготовленные файлы (сканы низкого качества), отсутствие лимита на массовую загрузку или реально более трудная задача, которую надо продавать по другому тарифу. Каждая причина имеет свою меру: помощь с подготовкой файлов, потолок на загрузку, отдельный пакет. Без разбивки по организациям эти решения принимаются вслепую.

Внешний API и своя модель: как меняется структура затрат

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

На раннем этапе внешний API часто дешевле для проверки спроса, а своя модель выгоднее при стабильной нагрузке и требованиях клиентов к хранению данных. Но это зависит от ваших чисел, и универсального порога у нас нет. Общий разбор выбора — в статье «Своя LLM или ChatGPT API», оборудование — в статье про видеопамять для LLM.

От себестоимости к тарифу

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

1. Берём распределение, а не среднее. По журналу пилота смотрим стоимость принятого результата у типичного, лёгкого и тяжёлого клиентов.
2. Определяем единицу учёта. «Действие ИИ» с весом: ответ на вопрос, разбор файла и подготовка отчёта расходуют разное.
3. Задаём пакет под типичного клиента и запас на разброс. Порядок докупки и цену сверх пакета определяет ваш рынок; мы цены тарифов не называем.
4. Предупреждаем клиента при приближении к пределу пакета, а не отключаем молча и не снижаем качество незаметно.
5. Ставим потолки: на одну задачу, на пользователя и на организацию в сутки. Фоновая обработка и повторные попытки не должны съесть бюджет за ночь.
6. Пересчитываем после смены модели, шаблонов запросов и условий поставщика.

Модели тарифов (по местам, объектам, обращениям, пакет с превышением) и их слабые места сравнены на странице SaaS-платформы; ИИ-функции с лимитами по тарифам описаны в статье «Как добавить ИИ в SaaS-продукт».

Что снижает стоимость и в каком порядке это проверять

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

1. Убрать повторы и отказы. Часто главная потеря — запросы, после которых результат не принят. Причины ищут в журнале: неподходящие входы, неясные инструкции, слабый поиск.
2. Ограничить размер контекста. Меньше найденных фрагментов и их длина, если эталон не показывает потери качества.
3. Сократить шаблоны запросов. Лишние инструкции и примеры убрать, проверив на эталоне.
4. Кэшировать повторяющиеся запросы. Организация и набор прав пользователя входят в ключ кэша, иначе кэш отдаст чужой ответ.
5. Раздать шаги разным моделям. Классификацию и извлечение полей — малой модели, сложные ответы — сильной.
6. Только потом менять модель или оборудование, когда простые меры исчерпаны.

Подробнее об управлении стоимостью запросов в архитектуре — в статье «Архитектура LLM-приложения». Окупаемость самого проекта считают отдельно: «Как посчитать ROI от внедрения ИИ».

Сигналы, по которым видно, что расчёт устарел

Себестоимость нельзя посчитать один раз: она меняется вместе с моделью, данными и поведением клиентов. Достаточно недельного отчёта с несколькими сигналами.

Пять признаков расчёта, которому верить нельзя

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

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

Что делаем мы и с чего начать

Начинаем с обследования: 200 000 ₽ и 2–3 недели за один-два процесса, 350 000 ₽ и 3–4 недели, если сервис связан с несколькими системами. В него входят определение принятого результата, схема журнала и единица учёта, ориентир стоимости запроса на вашем эталоне, гипотеза тарифа и вилка бюджета. Оплата вычитается из первого этапа, если продолжаете с нами.

На пилоте (150 000–400 000 ₽, 2–8 недель) и в первой версии (400 000–1 200 000 ₽, 2–3 месяца) журнал и отчёт по организациям работают в боевом виде, и тариф уточняется по первым клиентам. Дальше вывод в эксплуатацию от 1 500 000 ₽ этапами по 300 000–700 000 ₽ и сопровождение от 20 000 ₽ в месяц; часы пакета идут в том числе на проверку расходов. Остановиться можно после любой ступени. Цены — на странице «Тарифы».