Articles

    Финансово масштабируемые AI-продукты: маржа 90% на ста пользователях ничего не доказывает

    Как оптимизация затрат и управление инференсом повышают финансовую устойчивость AI-продуктов

    Опубликовано
    6 мин чтения
    Автор: Lenka Drevandale
    Обновлено

    Один запрос к модели среднего класса стоит около цента. На ста пользователях этот цент никто не замечает. Поэтому финансовую модель AI-продукта обычно строят, когда счёт за работу модели (его называют инференсом) почти нулевой. И строят на неверных предположениях. Ошибка всплывает под нагрузкой, когда маржа уже упала с 72% до 41%. Новыми тарифами её не исправить: экономику определяет то, как продукт устроен внутри.

    Маржа при 100 пользователях ничего не доказывает

    У молодого AI-продукта счёт за модель так мал, что его никто не разбирает. Сто пользователей, по три запроса в день, и за месяц модель обходится в несколько десятков долларов. Это дешевле, чем домен с мониторингом. На этом этапе любая команда хвалится маржой 90%. Но постоянные расходы ещё не нагружены, а переменные просто не успели вырасти.

    Настоящий вопрос всплывает через два года, когда трафик вырастает в тысячу раз: во сколько раз вырос счёт? Ответ зависит от того, что вы зашили в продукт в те полгода, когда стоимость никого не волновала.

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

    Какие расходы растут быстрее пользователей

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

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

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

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

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

    Посчитаем одну сессию до конца

    Пусть на входе 1800 токенов, на выходе 400, модель среднего класса: вход по 3 доллара за миллион токенов, выход по 15. Тогда одно обращение стоит 1800 / 1 000 000 × 3 + 400 / 1 000 000 × 15 = 0,0054 + 0,006 = 0,0114 доллара. Выглядит несущественно. Но средний активный пользователь делает 12 обращений в день, 360 в месяц, и это уже 4,10 доллара инференса на человека. При подписке в 19 долларов модель съедает 21,6% ещё до поиска по базе, хранилища и комиссии платёжного канала.

    Средний пользователь при этом фигура условная. Возьмём базу в 1000 платных подписчиков по 19 долларов: выручка 19 000 долларов в месяц. Пусть 950 человек пользуются продуктом умеренно и обходятся в среднем в 1,5 доллара инференса, а 50 тяжёлых пользователей в 48 долларов каждый. Первые стоят 1425 долларов, вторые 2400. Пять процентов базы съедают 63% бюджета на модель, а валовая маржа по инференсу падает до 79,9%. Ограничьте тяжёлых пользователей так, чтобы они обходились в 20 долларов, и расход снизится до 2425 долларов, а маржа поднимется до 87,2%. Семь пунктов маржи получены без единого изменения для остальных 950 человек.

    Пока вы не проделали этот расчёт для своего распределения нагрузки, разговор про маржу беспредметен. Из него же видно, за какие рычаги браться и в каком порядке.

    Сначала замер, потом кеш, маршрутизация последней

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

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

    Второй шаг: сократить то, что модель читает на входе. Дешевле всего это сделать в самом запросе (промпте). Уберите лишний контекст, вынесите неизменную часть в системную инструкцию, просите ответ в строгом формате. Только проверьте сокращение на задачах, где важна полнота ответа. Здесь же помогает кеш начала запроса. Если из 1800 входных токенов 1200 приходятся на неизменную системную инструкцию, при попадании в кеш эта часть стоит 10% цены. Вход дешевеет с 0,0054 до 0,0022 доллара, а вся сессия на 28%. 10% здесь взяты для примера: крупные поставщики дают на кешированный вход скидку от половины цены и больше, а первую запись в кеш иногда берут дороже обычного входа.

    Порог окупаемости кеша легко посчитать. При наценке на запись в 25% те же 1200 токенов обходятся примерно на 0,0009 доллара дороже обычного входа, а каждое попадание экономит около 0,0032 доллара. Значит, префикс окупается со второго обращения в пределах срока жизни кеша. На редких разовых запросах кеш проигрывает: вы платите наценку за запись и не успеваете снять скидку за чтение.

    Третий множитель, ответ модели, недооценивают чаще всего. В нашем примере токен ответа в пять раз дороже токена входа. А если пользователь бросил ответ на середине, платите вы всё равно полностью, хотя пользы ноль. Посчитайте, какая доля ответов брошена на полпути. Если больше 15%, разбейте длинные ответы на шаги: сначала короткий план на 200 токенов, полный текст по кнопке. Жёсткий предел длины ответа в системной инструкции занимает одну строку и почти не влияет на качество.

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

    Только после этого стоит браться за распределение запросов между моделями (маршрутизацию). По эффекту это самый сильный рычаг, но внедрять его нужно последним, и расчёт объясняет почему. Отдайте 70% запросов модели, которая в десять раз дешевле, и счёт станет 0,7 × 0,1 + 0,3 × 1 = 0,37: экономия 63%. Но когда дешёвая модель не уверена в ответе, запрос приходится отдавать большой. Если так уходит 12% запросов, за них платят дважды. Реальная себестоимость 0,49, чистая экономия 51%. 12 пунктов съедает сама схема. Сверху добавляются два набора промптов, две системы проверки и неприятный вопрос: если в работе случилась ошибка, виновата модель или схема распределения?

    Поэтому маршрутизацию включают только при готовом наборе оценки: нескольких сотнях размеченных примеров, которые покрывают и частые запросы, и редкие. Без него нельзя ответить на вопрос «сэкономили 40%, сколько потеряли в качестве», и ответ приходит через тикеты поддержки, с опозданием на месяц.

    Модель ценообразования решает больше, чем любая оптимизация

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

    Оплата по факту чинит эту связь, потому что выручка растёт вместе с затратами. Зато она пугает нового пользователя, который не может оценить свой объём: никто не знает, на что хватит миллиона токенов. Поэтому для большинства AI-продуктов оптимален гибрид: фиксированная цена с явной квотой плюс оплата сверх неё, и остаток квоты вынесен в интерфейс как цифра, которую пользователь видит постоянно.

    Квота работает, когда она не похожа на наказание. Пользователь видит остаток до того, как упрётся в потолок. После потолка функция деградирует (меньшая модель, короче ответ, очередь), но не исчезает. Сброс квоты совпадает с днём списания. Потолок разумно ставить заметно выше, чем тратят 95% пользователей. Тогда он задевает единицы процентов аудитории и срезает самых дорогих. Тихое ограничение скорости с сообщением «система перегружена» работает хуже всего, потому что пользователь считает продукт сломанным.

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

    Сколько на самом деле приносит клиент

    Доход с клиента за всё время (LTV) в AI считают за вычетом переменных затрат:

    LTV_net = LTV_revenue минус Total Variable Cost,

    где в переменные входят вычисления, поддержка и инфраструктура. Разница бывает большой. Допустим, подписка стоит 19 долларов, клиент живёт в среднем 14 месяцев и приносит за это время 266 долларов. Если инференс, поиск и поддержка обходятся в 6 долларов в месяц, переменные затраты за тот же срок составят 84 доллара, и LTV_net равен 182 долларам. При CAC в 70 долларов отношение по выручке выглядит как 3,8, а по чистому LTV уже 2,6. По выручке продукт выглядит здоровым, а по чистому LTV запас прочности тает почти на треть, и решение о бюджете на привлечение стоит принимать по второму числу.

    CAC тоже специфичен: новый пользователь сразу нагружает вычисления, а интенсивное использование бесплатного тарифа удлиняет окупаемость. Ориентиры по сроку возврата: B2C AI до 6 месяцев, продвинутые одиночные пользователи 6-9, B2B AI SaaS 12-18. Окупаемость задаёт допустимую скорость масштабирования: пока LTV_net нестабилен, наращивать продажи и маркетинг рано.

    Маржу считают по когортам. Слить в один показатель самообслуживание с ценником 19 долларов и enterprise с ценником 2000 значит обмануть себя самым распространённым способом: усреднённые 86% прячут то, что самообслуживание после CAC уходит в минус. У корпоративных клиентов к тому же главный расход связан с внедрением, аудитом и выделенной поддержкой. Давить на них стоимостью модели бессмысленно.

    Сценарии важнее точечного прогноза

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

    Многие команды рассуждают иначе: цены на модели падают так быстро, что любая оптимизация устареет раньше, чем окупится, и проще подождать.

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

    У маржи должен быть конкретный владелец

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

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

    Несколько неудобных ответов

    Стоит ли делать AI-продукт с маржой 55%

    Стоит, если вы можете объяснить, за счёт чего она вырастет, и назвать срок. «Подрастёт с масштабом» не считается: масштаб делает хуже именно суперлинейные строки бюджета. Полезно помнить, что для AI-сегмента такая маржа давно описана как норма. Вопрос в другом: стабильна ли маржа по когортам и покрывает ли она CAC. 55% при предсказуемой стоимости задачи здоровее, чем номинальные 80%, которые держатся только пока трафик мал.

    Что за метрика у финансово масштабируемого AI

    Стоимость успешно выполненной задачи: в знаменателе только успешные задачи, деньги за повторы после сбоя идут в числитель. Слепое пятно: она нечувствительна к сложности, и при сдвиге структуры пользователей искажается. Поэтому рядом держат второе число: во сколько раз пользователь из самых тяжёлых 5% дороже типичного. Когда разница больше 20 раз, пора пересматривать квоты.

    Главный финансовый риск при масштабировании

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

    Похожие статьи