Пока не пришёл счёт за месяц, фича на модели кажется почти бесплатной. Ниже разбор того, из чего складывается расход на одного пользователя и на чём стартапы чаще всего теряют маржу.
Цена одного запроса
Исходная формула такая: стоимость запроса = цена входного токена × число входных токенов + цена выходного токена × число выходных. У всех провайдеров выходные токены дороже входных в несколько раз. Поэтому длина ответа двигает счёт сильнее, чем размер промпта.
Если фича пишет длинные тексты (письма, описания, код с комментариями), основная часть расхода уходит на генерацию, а не на контекст, который вы передали модели.
Один пользователь, много вызовов
Типичная ошибка на старте: взять цену одного вызова API и умножить на число пользователей. Но за сессию человек делает несколько вызовов, и расчёт расходится с реальностью.
Диалог растёт с каждой репликой. Пятый вопрос в чате тянет за собой всю историю переписки, так что вы платите уже не за короткое сообщение, а за всё накопленное. Агентный сценарий, где модель сама планирует шаги, способен выдать десяток вызовов на одну задачу пользователя.
Поэтому считать нужно не запрос, а сессию или задачу целиком. Выясните, сколько вызовов в среднем стоит одно действие пользователя, и умножайте на это число стоимость одного вызова, а не на единицу.
Что пробивает маржу
Чаще всего юнит-экономику пробивают три вещи.
Тяжёлые пользователи. Использование почти всегда распределено неравномерно: небольшая доля аккаунтов выдаёт основную массу токенов. При плоской цене фичи эти аккаунты убыточны, а покрывают их остальные, через общую цену подписки.
Повторные попытки. Модель ошиблась, приложение перезапросило, потом ещё раз. Каждая попытка оплачивается полностью, а бизнес-метрика видит только удачный итог и не замечает, сколько он стоил.
Растущий контекст в длинных сессиях. Бот поддержки, который хранит всю историю разговора, платит за неё с каждым новым сообщением. Если историю не обрезать и не сводить к краткому пересказу, одна длинная сессия обойдётся в несколько раз дороже короткой.
Как посчитать себестоимость фичи
За представительный период соберите три числа: средний расход токенов на одно действие пользователя, среднее число действий на пользователя в месяц и долю неудачных вызовов, которые пришлось повторить.
Дальше формула: себестоимость на пользователя в месяц = число действий × средняя стоимость действия × поправка на повторы. Поправка обычно лежит в пределах 1.1-1.3, если у фичи есть автоматические ретраи.
Смотрите на перцентили вместе со средним. Медианный пользователь может обходиться в копейки, а девяносто пятый перцентиль в разы дороже. Цена, выведенная из среднего, нередко прячет, сколько теряется на самой активной части аудитории.
Как назначить цену и не уйти в минус
Плоская подписка годится, пока разброс использования между пользователями невелик. Когда он большой, разумнее заложить в тариф лимит: фиксированное число запросов в месяц за фиксированную цену, а сверх него доплата или переход на тариф выше.
Есть и второй приём. Закладывайте в цену не сегодняшнюю стоимость модели, а стоимость с запасом на подорожание или на переход к модели посильнее. Маржа, рассчитанная впритык к текущему прайсу API, исчезает при первой же смене тарифов у провайдера.
Как заметить рост расходов вовремя
Одного расчёта при запуске мало. Нужен постоянный обзор: на какую фичу, какого пользователя и какую модель уходят деньги.
В codexkey статистика ведётся по каждому ключу API отдельно. Выдайте ключи под разные фичи или клиентские сегменты, и сразу видно, кто съедает бюджет. Суб-организации с отдельными лимитами пригодятся, когда команда растёт и продуктов становится больше одного: у каждого свой бюджет и свой порог предупреждения, а не общий котёл, за который лично никто не отвечает.
Коротко
Себестоимость LLM-фичи не равна цене одного вызова API. Считайте на сессию, а не на запрос, сверяйте среднее с перцентилями и закладывайте в цену запас на случай подорожания модели. Разбивка расхода по ключам и фичам заменяет гадание цифрами.