Представьте двух клиентов на одном тарифе за 25 евро в месяц. Первый приносит стартапу 20 евро маржинального вклада, второй уносит 11 (расчёт ниже). Разница только в нагрузке: второй гоняет модель в двенадцать раз чаще.
В классическом SaaS такой проблемы не было, потому что предельная стоимость пользователя близка к нулю. AI-бизнес платит за инференс на каждом запросе, несёт расходы на память и быстрый отклик и теряет качество, когда меняются данные или условия задачи. Дообучение превращается в постоянную работу: после каждой итерации качество проверяют на тестовых наборах.
Спроектировать устойчивую модель значит найти, где AI создаёт ценность, которую клиент может измерить, выбрать механизм монетизации под реальный характер использования и просчитать юнит-экономику до того, как масштаб вскроет маржу, которую никто не проверял.
Почему у AI-стартапа кончается маржа раньше, чем спрос
Проще всего увидеть проблему на одном тяжёлом пользователе. Он платит тот же тариф, что и все, но гоняет крупную модель в разы чаще соседей, и при неограниченном использовании валовая маржа разрушается именно так, по одному такому аккаунту за раз.
Защититься от этого качеством модели не получится: базовые модели улучшаются ежемесячно, голое качество перестаёт отличать продукт, и дифференциацию приходится строить на доменной экспертизе, собственных данных или встроенности в рабочий процесс.
Удерживать даже такую дифференциацию дорого. Клиент ждёт, что продукт будет становиться лучше, поэтому пайплайны дообучения и петли обратной связи из разовой затраты превращаются в регулярную статью операционных расходов. Сэкономить на них тоже не выйдет: галлюцинации, дрейф и нестабильная работа бьют прямо по удержанию и воспринимаемой ценности.
В пилоте, где нагрузка мала и предсказуема, ни одно из этих давлений не заметно. Поэтому модель, которая генерирует выручку, но не стабилизирует экономику под переменной нагрузкой, выглядит здоровой ровно до масштаба.
Если разложить, куда уходит маржа, получится три статьи расходов, которых у классического SaaS почти нет: вычисления на каждый запрос, люди в контуре разметки и исправления ошибок, доработки под каждого крупного клиента. Модели с каждым годом дешевеют, но это касается только первой статьи. Разметчикам и инженерам, которые подгоняют продукт под банк или клинику, цена токена безразлична.
Кто несёт переменный счёт: шесть способов брать деньги
Все три статьи расходов переменные, и схема оплаты по сути решает, кто их несёт: поставщик, клиент или обе стороны по заранее оговорённому правилу. Отсюда и разница между архетипами ниже, причём у каждого своя цена за выбранное распределение риска.
Тарификация по использованию стала стандартом для AI-first компаний, потому что измеряет ровно то, что стоит денег: токены или символы, API-запросы, обработанные изображения или документы, минуты инференса, действия внутри рабочего процесса. Плюсы понятны. Цена идёт за себестоимостью, выручка растёт вместе с использованием, и никому не нужно заново договариваться, чтобы попробовать больший объём. Последнее весит больше, чем кажется: оплата по использованию снижает для клиента цену эксперимента, а это ровно то, что нужно в начале кривой внедрения.
Платить за это приходится предсказуемостью. Клиенту труднее прогнозировать свои расходы, и крупные компании дольше согласуют покупку. А у поставщика выручка скачет вместе с нагрузкой. Поэтому модель работает только при жёстком контроле затрат. Маржу напрямую защищают три приёма: хранить готовые ответы на частые запросы (кэш), отправлять простые запросы на модели подешевле и обрабатывать запросы пачками.
Гибрид «подписка плюс использование» соединяет базовый тариф и включённый лимит с оплатой перерасхода по счётчику. Схема проста; вся проектная работа в том, где поставить этот лимит. Слишком щедро, и тяжёлые аккаунты тихо съедают валовую маржу; слишком скупо, и клиенты сами урезают использование, что противоположно тому, что нужно растущему продукту. Модель подходит генеративным инструментам письма, поисковым и RAG-процессам, вертикальным ассистентам для юристов, медицины или инженерии, то есть случаям, где покупателю нужна предсказуемая строка в счёте, хотя использование реально скачет от месяца к месяцу.
Оплата за результат продаёт эффект вместо генераций: сэкономленные часы, автоматизированные задачи, решённые кейсы, квалифицированные лиды, предотвращённые случаи мошенничества. Это работает, потому что переносит разговор на язык покупателя: на финансовом ревью никто не спорит о числе токенов, но все понимают «решённых кейсов в месяц». Цена, привязанная к бизнес-результату, ещё и переживает смену моделей: если инференс подешевеет вдвое в следующем квартале, результат для клиента, а с ним и цену, не нужно пересогласовывать.
Условие одно: измеримость. Архетип держится, только когда метрика наблюдаема, атрибутируема и её трудно оспорить; там, где это так, удержание и LTV обычно сильнее, чем у любой другой модели.
Вертикальные AI-платформы работают на одну отрасль. Их отличают особые данные, знание отрасли и встроенность в её процессы. Зарабатывают они на платном доступе к данным, отраслевых моделях, пакетах для соответствия требованиям регуляторов и отраслевых ассистентах. Универсальный конкурент не скопирует это, просто взяв модель получше. Именно поэтому они защищены: данные, встроенные процессы и институциональное доверие набираются годами. За такую позицию платят меньшим адресуемым рынком и более длинным циклом продаж. Размен разумный, пока готовность платить достаточно высока, чтобы его покрыть.
Модели на данных и сетевых эффектах зарабатывают на данных и выводах, которые накапливаются при использовании продукта. Это аналитические платформы и системы, которые учатся на каждом клиенте. Деньги приходят через подписку, платную аналитику и улучшения модели, за которые клиент готов платить. Важнее прайс-листа здесь петля: каждый новый клиент улучшает модель, а это делает продукт ценнее для следующего. Такие сетевые эффекты складываются в защищённость, которую одним ценообразованием не купить, но остаются слабыми, пока маховик данных реально не раскрутится, поэтому этот архетип редко бывает первой бизнес-моделью компании.
Model-as-a-Service отдаёт дообученные или оптимизированные под эффективность модели по API. Выигрывает обычно модель, подходящая под задачу, и редко самая большая: компактные и быстрые для запуска на устройствах, регуляторно совместимые варианты для медицины, права и финансов, архитектуры с приоритетом приватности, экономичные альтернативы универсальным базовым моделям. Поскольку покупатель технический, а сравнивать легко, архетип требует необычно чёткого моделирования затрат и надёжных SLA: обязательства по задержке и аптайму покупатель оценивает как часть продукта.
Во что реально обходится один клиент
От стоимости обслуживания (cost-to-serve) зависит, держится ли вся остальная модель, и у AI она меняется с нагрузкой. В неё входят генерация ответов, серверы и видеокарты, поиск по базе документов, память, кэш и пакетная обработка, а также проверки безопасности и модерация, которых не видно в демо. Маржинальный вклад равен выручке с клиента минус cost-to-serve. Он и показывает, может ли бизнес вообще себя окупать, и считать его нужно заново по мере роста использования.
Если cost-to-serve отвечает на вопрос, сколько клиент съедает, то пожизненная ценность отвечает на встречный вопрос о том, сколько он вернёт за всё время. Она складывается из выручки за использование, удержания, валовой маржи и потенциала расширения, и AI-продукты часто дают сильное расширение выручки, как только процесс встроен и переключение становится болезненным.
За сколько окупается привлечение клиента, зависит от типа продукта, канала и вычислительной нагрузки. Единой нормы нет: срок сравнивают с тем, на сколько хватит денег, и с риском потерять клиента.
Главная ловушка, которую должна вскрыть юнит-экономика, сидит в тяжёлых пользователях: лёгкие стоят мало и платят стабильно, enterprise-аккаунты предсказуемы, но требуют своих SLA, а тяжёлые без тарифных ступеней тихо становятся убыточными. Если самые активные клиенты оказываются самыми невыгодными, у модели структурный дефект, который нужно чинить ступенями или лимитами до масштабирования.
Как это считается
Маржинальный вклад = Выручка с клиента минус Cost-to-serve
Cost-to-serve = инференс + хостинг и GPU + эмбеддинги и запросы к векторной БД
+ память, кэш и батчинг + модерация и безопасность
Смотреть здесь нужно на разрез по нагрузке. У лёгкого пользователя Cost-to-serve мал, и вклад положителен; у тяжёлого на том же тарифе он способен превысить выручку и увести вклад в минус. Поэтому маржу считают по каждой тарифной ступени и по тяжёлому сегменту отдельно. Усреднение по «среднему клиенту» как раз и прячет убыточные аккаунты до масштабирования.
Возьмём тариф из начала статьи, 25 евро в месяц; суммы ниже подобраны для наглядности. Лёгкому клиенту инференс обходится в 3 евро, хостинг, эмбеддинги и модерация ещё в 2: Cost-to-serve 5 евро, вклад 20 евро, или 80%. Тяжёлый клиент создаёт двенадцатикратную нагрузку. Кэш и батчинг немного смягчают счёт, но инференс всё равно выходит около 29 евро, плюс 7 евро прочих расходов. Итого 36 евро при выручке 25, вклад минус 11 евро.
Лечится это лимитом. Примем за единицу месячную нагрузку лёгкого клиента: на объёме тяжёлого она стоит около 2,4 евро инференса (29 евро на 12 единиц). Включим в тариф 4 единицы: 9,6 евро инференса плюс примерно 2,5 евро прочего дают 12,1 евро затрат и вклад около 52%. Каждую сверх лимита продаём за 3 евро. Тяжёлый клиент теперь платит 25 евро плюс 8 единиц по 3, всего 49 евро, против тех же 36 евро затрат: минус 11 превратился в плюс 13. Лёгкий клиент изменения не заметит, его единица нагрузки целиком внутри лимита.
Цена токена при этом сама по себе переменная, и не только в сторону удешевления. В августе 2026 года DeepSeek подняла цены на API для моделей V4: в зависимости от модели, типа токенов и времени суток рост составил от 50% до 1100%. Поэтому расчёт выше стоит прогнать ещё дважды, с ценой инференса выше на 50% и на 100%. Если во втором прогоне вклад включённого лимита уходит в минус, в договоре с клиентом нужны право сменить базовую модель или пункт о пересмотре цены.
Порядок, в котором требуют считать сами цифры
Порядок важен, потому что каждый шаг ограничивает следующий. Сначала найдите, где AI даёт измеримый результат, а не эффектную картинку, и выберите под него, за что брать деньги. Затем посчитайте все затраты по цепочке (генерация, поиск по документам, проверки безопасности), чтобы цена их покрывала. Определите метрику ценности, понятную клиенту без объяснений. И только потом прогоняйте финансовые сценарии по тарифам, объёму, размеру модели и росту затрат, чтобы увидеть, где ломается маржа.
Два шага замыкают круг. Расширение выручки обычно приходит с ростом использования внутри первого контракта, второй подписывают редко: апселлы в старшие ступени, новые места, бóльшие лимиты, аддоны, вертикальные модули; и каждая механика должна цепляться за то, что клиент считает добавленной ценностью; снятие искусственно введённого ограничения к ней не относится.
А модель на слайде остаётся гипотезой, пока её не подтвердит поведение: ценовые эксперименты показывают, где на самом деле кончается готовность платить, A/B-тесты сравнивают разные упаковки одной и той же возможности, а когортный анализ показывает, сдвинула ли ценовая правка удержание за несколько месяцев. Конверсия за одну неделю этого не покажет.
Чего не делать в первый год
Почти все типичные ошибки вырастают из одной: AI-нагрузку тарифицируют как SaaS, с фиксированной ценой за место, и маржа держится, пока использование не пошло вверх. Следом идёт привычка не смотреть на динамику затрат модели. Пока счёт за инференс никто не разбирает по сегментам, масштабирование работает как способ терять деньги быстрее. Особенно больно это бьёт, если расходы на безопасность и соответствие требованиям недооценены, а худший сценарий затрат ни разу не просчитан: бизнес оказывается незащищённым ровно в тот месяц, когда нагрузка скачет.
Списывать фиксированную подписку при этом рано. Корпоративный отдел закупок согласует понятную годовую сумму один раз, а счёт, который меняется каждый месяц, отправляет на повторное согласование и может сдвинуть сделку на целый бюджетный цикл.
Этот аргумент перевешивает в двух случаях. Первый: нагрузка распределена узко, и самые тяжёлые 10% клиентов потребляют не больше трёх медианных. Второй: инференс настолько дёшев, что даже самый тяжёлый правдоподобный аккаунт тратит меньше десятой части своей подписки.
Если выполнено хотя бы одно условие, оставляйте фиксированный тариф и тратьте силы на удержание. Если ни одно, фиксированная цена превращается в ставку на то, что лучшие клиенты так и останутся маленькими.
Две другие ошибки касаются уже языка. Продукт выходит без ясной value-метрики, а команда предполагает, что клиент мыслит токенами. Покупателю же важен результат. Тот, кто привязывает цену к результату, который покупатель и так отслеживает, заодно избавляет себя от спора о токенах на каждом продлении.
Что менять до PMF и после
До product-market fit скорость обучения важнее оптимизации маржи. Начните с простой оплаты по использованию или за рабочий процесс, которую можно объяснить одной фразой, и итерируйте часто: клиенты сами покажут настоящую value-метрику тем, на что жалуются и что расширяют. Маленькие модели на этой стадии выбирают осознанно: так cost-to-serve остаётся в диапазоне, который компания способна покрыть, пока характер использования ещё неизвестен.
С ростом базы дифференциация начинает окупаться. Тарифные ступени и enterprise-готовность разводят платёжеспособные сегменты и чувствительные к цене, а защита через данные из побочного эффекта превращается в то, что строят намеренно через встроенность в процесс. Здесь важнее всего ритм: пересчитывать кривые маржи ежеквартально, до того как сегмент станет убыточным незаметно для всех.
На поздней стадии рычаг смещается с ценообразования на инфраструктуру, где кэширование, выбор модели и роутинг ложатся прямо на валовую маржу. Вертикальные варианты продукта расширяют франшизу в смежные отрасли, а петли улучшения качества автоматизируются, чтобы качество вывода больше не зависело от отдельных ручных проверок.
Короткие ответы на вопросы основателей
Какая модель лучше сегодня? Тарификация по использованию остаётся доминирующей, но гибридные модели и оплата за рабочий процесс дают самую сильную маржу.
Чем юнит-экономика отличается от SaaS? Предельная стоимость не близка к нулю: затраты на инференс и ограничения по памяти с первого дня закладываются в основную модель.
Тарифицировать ли по токенам? Только при продаже разработчикам. Конечным пользователям понятнее цена за результат или за рабочий процесс.
Как проверять цифры на прочность? Сценарным и стоимостным моделированием по росту, ступеням и кривой затрат, чтобы плохой квартал был заложен заранее.
У всех этих ответов есть общий предел: они верны, пока тяжёлые аккаунты остаются меньшинством. Когда на них приходится основная часть выручки, средняя маржа по базе перестаёт что-либо объяснять, и решает маржинальный вклад именно этой группы на текущем тарифе, посчитанный по value-метрике, которую клиент узнаёт без пояснений.
Отрицательный вклад значит, что ступени или лимиты нужны до следующего раунда роста, иначе каждый новый тяжёлый клиент только углубляет минус. Положительный оставляет свободу экспериментировать с упаковкой и ценой: вычислительный счёт рост уже не съест.