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

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

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

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

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

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

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

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

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

Проще всего это делать там, где тарификация уже унифицирована. В каталоге Most AI все модели — больше 63 штук, от текстовых до генераторов изображений, видео и голоса — тарифицируются в рублях по факту использования, без ежемесячной подписки "про запас". Например, у текстовых моделей цена считается за 1000 токенов, отдельно за вход (запрос) и выход (ответ): GPT-5.4 Mini — 0,13 ₽ за запрос (вход) и 0,76 ₽ за ответ (выход) за 1000 токенов, Claude Sonnet 4.6 — 0,50 ₽ (вход) и 2,52 ₽ (выход), а GPT-5.5 — 0,84 ₽ (вход) и 5,04 ₽ (выход). Цены указаны на дату публикации; актуальные — на странице цен Most AI. Это удобно именно для расчёта unit-экономики: стоимость прозрачна и оплачивается по факту, без абонентской платы про запас.

Для команды это стало отправной точкой: прежде чем спорить, какая модель "качественнее", стоило прикинуть, во сколько обходится каждая из них при ожидаемой нагрузке. Разница между самой дешёвой и самой дорогой текстовой моделью — это разница в разы в итоговой себестоимости: выход GPT-5.5 (5,04 ₽ за 1000 токенов) обходится примерно в 6–7 раз дороже, чем выход GPT-5.4 Mini (0,76 ₽), и при заметном трафике это решает, останется фича прибыльной или начнёт съедать маржу продукта.

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

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

Для черновых операций — классификации, коротких ответов, промежуточных шагов пайплайна — не нужен самый дорогой инструмент. Модели вроде 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% лучше, чем расчёт без буфера вообще, — важно не точное число, а сам факт, что лимиты и цена подписки посчитаны, а не выбраны интуитивно.

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

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

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

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

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

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

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

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

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

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