Основатель компании, разрабатывающей AI-ассистента для письма, рассказал мне, что его "расходы на софт" составляют $40,000 в месяц. Когда мы разложили эту сумму по полочкам, оказалось, что $34,000 из неё — это счета за API OpenAI и Anthropic, и ни цента из этой суммы не было учтено в себестоимости продаж. Всё это сидело в общей строке "Софт и подписки" прямо рядом с его системой управления проектами за $19 в месяц. Заявленная валовая маржа составляла 91%. Реальная валовая маржа — после того как инференс был перенесён туда, где ему и место, — оказалась 58%.
Это не бухгалтерская формальность. Это разница между бизнесом, который выглядит как софт, и бизнесом, который ведёт себя как завод, — где каждая проданная единица потребляет реальный, переменный ресурс. Если вы строите продукт поверх GPT-5, Claude, Gemini или любой другой размещённой модели, ваш счёт за LLM — это не накладные расходы. Это себестоимость продаж (COGS), и если относиться к нему иначе, вы попросту не будете знать, сколько денег на самом деле зарабатываете.
Почему эту ошибку так легко совершить
Традиционный SaaS приучил целое поколение основателей воспринимать расходы на софт как фиксированные. Вы платите за хостинг, платите за CRM, платите за Slack — и ни один из этих счетов не движется синхронно с тем, насколько активно ваш продукт использует тот или иной конкретный клиент. Поэтому когда приходит первый счёт от OpenAI, естественно занести его в тот же мысленный ящик: "инструменты, за которые мы платим, чтобы вести бизнес".
Проблема в том, что счёт за API LLM ведёт себя не как подписка на SaaS. Он ведёт себя как сырьё. Каждый раз, когда клиент отправляет запрос, вы расходуете токены, и у каждого токена есть цена. Клиент, который делает 50 запросов в день, обходится вам заметно дороже в обслуживании, чем клиент, который делает 2. Это классическое определение себестоимости продаж: затрата, которая масштабируется напрямую вместе с доставкой вашего продукта конкретному клиенту, в отличие от затраты, которую вы платили бы просто для того, чтобы бизнес функционировал, независимо от использования.
Отраслевые данные подтверждают, насколько существенной стала эта статья расходов. Отчёт ICONIQ о состоянии AI за январь 2026 года показал, что инференс теперь в среднем составляет 23% от общей выручки AI-компаний B2B на стадии масштабирования, а 84% этих компаний сообщили об эрозии валовой маржи на шесть процентных пунктов или более, напрямую связанной с затратами на AI-инфраструктуру. Это не погрешность округления, которую можно спрятать в "прочих операционных расходах". Зачастую это крупнейшая статья затрат в бизнесе, и относиться к ней нужно соответственно.
Где правильно провести черту между COGS и OpEx
Правило, которое отделяет COGS от операционных расходов, не изменилось только потому, что теперь входным ресурсом является API модели, а не склад, полный деталей: затраты на доставку продукта платящему клиенту относятся к COGS; затраты на создание продукта относятся к R&D в составе OpEx. Применительно к AI-обёртке это разделение выглядит так:
Относится к COGS:
- Производственные затраты на инференс — каждый вызов API, который ваш работающий продукт делает от имени платящего клиента, будь то завершение чата, вызов эмбеддинга, проход классификации или цикл вызова инструментов агента
- Хостинг модели / вычисления на GPU — если вы запускаете модель с открытыми весами на собственной или арендованной инфраструктуре вместо обращения к размещённому API, время вычислений, приходящееся на обслуживание клиентских запросов
- Вспомогательная инфраструктура инференса — запросы к векторной базе данных, прогоны конвейера эмбеддингов и оркестрационные накладные расходы, которые существуют специально для обслуживания продакшн-запросов
- AI-специфичные затраты на поддержку — инженер поддержки, чья работа заключается в разборе проблем с выводом модели для клиентов, — это затрата на доставку продукта, а не общая статья SG&A
Относится к OpEx (обычно R&D):
- Инференс на этапе разработки и тестирования — каждый промпт, который инженер отправляет, дорабатывая функцию, отлаживая регрессию или оценивая новую версию модели
- Дообучение (fine-tuning) и оценочные прогоны — создание или улучшение модели — это R&D, а не доставка
- Внутренние AI-инструменты — корпоративные места ChatGPT Enterprise или лицензии GitHub Copilot вашей команды — это расходы на продуктивность, а не затраты на обслуживание клиентов
Практический шаг, который делает это разделение возможным, скучен, но необходим: используйте отдельные API-ключи или биллинговые проекты для продакшн- и dev-трафика с первого дня. Если ваши инженеры тестируют промпты через тот же ключ, который использует ваш продукт в продакшне, у вас нет способа корректно распределить счёт постфактум, и в итоге вы будете либо завышать, либо занижать вашу реальную маржу каждый месяц.
Как выглядит "реальная" валовая маржа для AI-продуктов
Как только вы сделаете это разделение, ожидайте, что итоговая цифра будет отличаться от привычной. Традиционные SaaS-компании почти как само собой разумеющееся ориентируются на валовую маржу 70–80%. AI-продукты так просто до этого уровня не добираются. Согласно февральскому 2026 года руководству по ценообразованию Bessemer Venture Partners, типичная валовая маржа AI-продуктов составляет 50–60%, что значительно ниже диапазона 80–90%, характерного для традиционного SaaS, а данные ICONIQ показывают, что средняя по отрасли валовая маржа AI-продукта растёт — но лишь до 52%, по сравнению с 41% в 2024 году и 45% в 2025 году.
Полезное практическое правило, выработанное операторами, которые пристально следят за этим вопросом: удерживайте затраты на LLM на уровне примерно ниже 20% от общей себестоимости, если вы хотите устойчивую, масштабируемую бизнес-модель. Как только этот порог пройден, сжатие маржи, как правило, ускоряется по мере роста, а не ослабевает, потому что крупные клиенты используют продукт больше, а не меньше. Некоторые AI-интенсивные категории — ассистенты для написания кода, агенты для обработки документов — работают с долей затрат на LLM 30–40% от себестоимости и всё равно остаются жизнеспособными, но лишь потому, что они осознанно выстроили ценообразование с учётом этой реальности, а не пришли к ней задним числом.
Цифра, которая на самом деле имеет значение, — это не смешанная, общекорпоративная валовая маржа, а стоимость на одного клиента. Активные пользователи AI-функции могут обходиться в обслуживании в 50–100 раз дороже по сырому инференсу, чем лёгкие пользователи на том же самом тарифном плане. Если вы это не отслеживаете, вы не знаете, какие клиенты прибыльны, а каких вы незаметно субсидируете каждый месяц. Тариф с фиксированной ставкой, который выглядел нормально на первых десяти клиентах, может начать приносить убытки в тот момент, когда один из них внедряет рабочий процесс в продакшн и увеличивает объём своих запросов в 20 раз.
Построение модели стоимости на один запрос
Чтобы начать, вам не нужны сложные инструменты — вам нужна дисциплина в логировании правильных цифр по каждому запросу. Базовая формула проста:
request_cost = (input_tokens / 1,000,000) × input_price_per_million
+ (output_tokens / 1,000,000) × output_price_per_millionВыходные токены обычно стоят в 2–5 раз дороже входных за единицу, потому что генерация требует больше вычислений, чем чтение промпта, — поэтому модель стоимости запроса, которая отслеживает только общее число токенов без разделения на входные и выходные, будет систематически неверно оценивать любые запросы с длинными ответами. В качестве рабочего примера при ценах середины 2026 года: запрос с 2 000 входных токенов и ответом на 500 токенов к массовой модели среднего уровня (примерно $3 за вход / $15 за выход на миллион токенов) стоит около $0.0135. Выполните запрос такой же формы 50 000 раз в месяц, и вы получите около $675 затрат на инференс для одной-единственной функции — цифра, которая незаметна, если она погребена в шестизначной строке "облачные расходы", но становится очень заметной, как только её привязывают к функции и сегменту клиентов, который её сгенерировал.
Чтобы сделать это применимым на практике:
- Логируйте число токенов по каждому запросу, а не только стоимость — большинство провайдеров моделей возвращают число входных/выходных токенов прямо в ответе API, так что это изменение в логировании, а не новый источник данных.
- Помечайте каждый запрос идентификатором клиента и функции, чтобы можно было агрегировать затраты по аккаунтам и по продуктовым поверхностям, а не только по месяцам.
- Считайте стоимость на клиента за расчётный период и сравнивайте её с тем, сколько этот клиент вам платит. Именно эта цифра показывает, действительно ли ваши тарифные планы соответствуют вашей себестоимости доставки, а не ваша смешанная средняя маржа.
- Направляйте запросы к более дешёвым моделям там, где это позволяет качество. Не каждому запросу нужна ваша самая мощная (и самая дорогая) модель — классификация, извлечение данных и простое форматирование часто приемлемо работают на более компактной, дешёвой модели, а маршрутизация моделей — один из немногих рычагов маржи, который полностью в ваших руках, в отличие от цен провайдера.
Ценообразование, защищающее найденную вами маржу
Как только инференс правильно классифицирован как COGS, ваш разговор о ценообразовании меняется. Распространённый ориентир, который используют операторы, — устанавливать цену примерно в 3–5 раз выше стоимости на единицу токена, так что задача стоимостью $0.30 оценивается в $1.00 или больше — не потому, что этот множитель магический, а потому что он оставляет запас на колебания использования, волатильность цен провайдеров модели и затраты на поддержку и инфраструктуру, которые сопутствуют сырому инференсу.
Биллинг по факту использования стал стандартным способом, которым AI-компании удерживают ценообразование и себестоимость движущимися синхронно: берите плату за токен, за запрос или за выполненную задачу, и ваша выручка масштабируется вместе с той же переменной, которая определяет вашу затрату, вместо того чтобы расходиться с ней, как это происходит с фиксированной подпиской при всплеске использования. Если вы ещё не готовы полностью перейти на биллинг по факту использования, как минимум выстройте тарифы с гарантированным минимумом плюс доплата за превышение, чтобы клиент, который резко превышает типичное использование, незаметно не превращался в убыточного на весь оставшийся месяц.
Держите свою структуру затрат такой же прозрачной для аудита, как и ваш код
Всё это не факультативная бухгалтерская гигиена — это разница между тем, чтобы знать, что ваша бизнес-модель работает, и обнаружить, что это не так, во время due diligence при привлечении инвестиций, когда ассистент инвестора строит модель стоимости на клиента, которую вам следовало построить на полгода раньше. Основатели, которым удаётся избежать такого разговора, — это те, кто помечает затраты на инференс по клиентам и функциям с самого первого вызова API, а не те, кто ждёт, пока счёт от OpenAI не станет слишком большим, чтобы его игнорировать.
Beancount.io даёт вам учёт в виде обычного текста с контролем версий, который упрощает привязку расходов на инференс к нужному счёту, разделение продакшн- и dev-использования API и сверку вашей реальной себестоимости с выручкой каждый месяц — без чёрного ящика категоризации, без привязки к одному поставщику. Начните бесплатно и узнайте, почему разработчики и AI-native основатели переходят на учёт в виде обычного текста.