Себестоимость AI-фичи: считаем цену генерации на пользователя

Фича почти готова, а цифры в голове нет

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

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

Почему нельзя запускать фичу с генерацией вслепую

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

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

Шаг первый: разобраться, за что вообще платишь

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

Проще всего это делать там, где тарификация уже унифицирована. В каталоге Most AI все модели — больше 63 штук, от текстовых до генераторов изображений, видео и голоса — тарифицируются кредитами, и оплата идёт по факту использования, без ежемесячной подписки "про запас". Например, у текстовых моделей цена одного запроса известна заранее: GPT-5.4 Mini стоит 1 кредит, Claude Sonnet 4.6 — 5 кредитов, а GPT-5.5 — 9 кредитов за запрос. Это удобно именно для расчёта unit-экономики: не нужно самому переводить токены в рубли и гадать про длину ответа, цена уже привязана к запросу.

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

Шаг второй: выбрать модель под задачу, а не под хайп

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

Для черновых операций — классификации, коротких ответов, промежуточных шагов пайплайна — не нужен самый дорогой инструмент. Модели вроде Gemini 3.1 Flash Lite или Claude Haiku 4.5 стоят заметно меньше кредитов за запрос, чем топовые версии, и для рутинных задач их точности достаточно. А дорогую модель — например, Claude Opus 4.8 или GPT-5.5 — есть смысл вызывать только там, где от неё реально зависит воспринимаемое пользователем качество: финальный текст, сложное рассуждение, генерация, которую пользователь увидит и оценит напрямую.

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

Шаг третий: посчитать не среднего, а активного пользователя

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

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

Шаг четвёртый: свести всё в одну таблицу

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

Отдельная строка в таблице — буфер на непредвиденное. Опыт команды показал, что реальное потребление почти всегда выше прогноза: пользователи запускают генерацию заново, если результат не устроил с первого раза, тестируют разные формулировки, возвращаются к фиче чаще, чем показывало пилотное тестирование на своей команде. Закладывать буфер в 30-50% к расчётной цифре — не перестраховка, а поправка на то, что реальное поведение пользователей отличается от поведения тестировщиков.

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

Шаг пятый: решить, что делать с цифрой

Получив цифру себестоимости на активного пользователя в месяц, команда не остановилась на "ну ладно, вроде терпимо". Цифра напрямую повлияла на три решения о запуске.

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

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

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

Что в итоге получила команда

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

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

Частые вопросы

С чего начать расчёт себестоимости, если фича ещё не запущена и статистики использования нет?

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

Стоит ли всегда выбирать самую дешёвую модель, чтобы снизить себестоимость?

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

Как учитывать бесплатную дневную квоту при расчёте себестоимости?

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

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

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

Нужно ли пересчитывать себестоимость, если в фичу добавляется новая модель?

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

Как выбрать буфер на пиковую нагрузку, если данных о реальном трафике ещё нет?

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