Как рассчитать расходы на API ИИ и юнит-экономику продукта

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

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

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

1. Вычислительное оборудование: чипы, ускорители и сетевое оборудование для обучения и работы моделей.
2. Облачная инфраструктура: доступ к вычислительным мощностям по мере потребности или по предварительному резервированию.
3. Базовые модели: разработка и обучение универсальных и специализированных моделей текста, кода, изображений, аудио и видео.
4. Доступ к моделям и MLOps: размещение, выбор модели для задачи, оценка качества, мониторинг и управление запросами.
5. Приложения: ассистенты, отраслевые продукты и ИИ-функции внутри привычных сервисов.
6. Услуги и интеграция: внедрение, настройка процессов и обучение сотрудников.

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

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

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

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

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

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

Это могут быть помощники для писем и документов, отраслевые инструменты для маркетологов и инженеров или ИИ-функции внутри CRM, службы поддержки и аналитического сервиса. Монетизация обычно знакомая: месячная или годовая подписка, плата за пользователей и объём действий, бесплатный тариф с ограничениями либо корпоративная лицензия.

Выручка рассчитывается по обычной логике SaaS. Дополнительная сложность появляется в себестоимости: одинаковая подписка может порождать очень разные расходы в зависимости от частоты и сложности запросов.

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

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

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

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

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

Разделите бесплатных и платящих пользователей. Для каждой группы задайте долю тех, кто использует ИИ в течение месяца. Например, в сценарии можно предположить 10–20% среди бесплатных активных пользователей и 60–80% среди платящих. Это допущения для проверки, а не универсальные ориентиры.

Для бесплатного тарифа задайте жёсткий месячный лимит и отдельно — ожидаемое использование. Лимит показывает максимальные расходы, но не означает, что каждый пользователь его исчерпает. Для платных тарифов оцените среднее количество действий на активного пользователя ИИ и проверьте сценарий более интенсивного использования.

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

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

При цене $2 за миллион входных и $10 за миллион выходных токенов получаем:

При 100 запросах в месяц активный пользователь ИИ обходится в $0,34. Допустим, подписка стоит $20, прочие прямые расходы — $2 на пользователя, а целевая валовая маржа — 80%. Тогда допустимая общая себестоимость составляет $4, фактическая в этом примере — $2,34, а маржа — 88,3%.

Теперь увеличим контекст до 600 входных токенов, ответ — до 1 000 выходных, а использование — до 200 запросов в месяц. При тех же ценах один запрос стоит $0,0112, расходы на ИИ — $2,24 в месяц, общая себестоимость — $4,24. Маржа снижается до 78,8% без изменения зарплат или маркетингового бюджета.

Это расчёт на пользователя, который активно пользуется ИИ. Для всего платного сегмента учитывайте долю таких пользователей. Расходы бесплатного сегмента моделируйте отдельно и последовательно отражайте в принятой структуре отчётности.

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

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

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

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

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

Блок расходов на API связывается с прогнозом активных пользователей, распределением по тарифам и отчётом о прибыли. Храните допущения о запросах, токенах и ценах отдельно от формул, чтобы обновление данных не требовало перестраивать модель.

Регулярно сопоставляйте прогноз с фактическими счетами провайдера и поведением клиентов. Так модель станет инструментом выбора тарифов и управления маржой, а не разовым расчётом для презентации.